暮らしの技術

暮らしを豊かにする技術や、特に暮らしを豊かにしない技術があります

綴る: テーマ機能の実装に関して

2025年1月18日、テーマ機能と呼んでいる背景に画像を設定する機能をリリースしました。今は無地を含む4種類のテーマを選択できます。

これはそのテーマ機能に関してのメモです。



既存の実装に関して

これまでのエディタでは背景を rgb(255 255 255 / 1)で塗りつぶしたキャンバスにユーザが書き込み、保存時に

  • 記事表示用画像(オリジナル)
    • 閲覧者が記事を読む際に読み込まれる。投稿後の再編集の際にはエディタにロードされる。
    • リンクや画像などは含まれず、閲覧画面/編集画面上で組み立てられる。
      • 写真の位置などは後から調整したいため
  • OCR用画像
    • OCR処理を実施するための画像。記事表示用画像とは異なり、閲覧画面で表示される画像なども1枚に埋め込んだ画像
      • OCR時には最終的にユーザが見るものと同じものを対象とした方がいいであろう、という判断
    • canvasで作ったデータをpngで出力するとアルファを扱えるが、透明部分が rgb(0 0 0 / 0)となる。OCR の過程でアルファが取り除かれた際に rgb(0 0 0)つまり真っ黒になるため、黒い線が読み取れなくなる問題があった。既存実装では背景を白で塗りつぶすことでこの問題を回避している。
  • サムネイル画像
    • 縮小画像
    • OCR画像同様、最終的にユーザが見るものと同じ物が良いので画像などは埋め込まれている。

の三種類を生成してアップロードしていました。

テーマの実装に向けて変更した箇所

  • 表示用画像(オリジナル)
    • 背景を透明に変更
    • テーマ画像はcanvas要素の background-image として CSS で表示
  • OCR用画像
    • 新たなcanvasrgb(255 255 255 / 1)で塗りつぶして、その上にオリジナルの画像を描画してから画像などを埋め込む形に変更
    • テーマ画像も埋め込んでテストしたところ、罫線などの装飾がOCR結果に悪影響を及ぼすケースがあったため
  • サムネイル画像
    • テーマ画像を描画してからオリジナル画像を描画し、画像などを埋め込む

言葉で説明すると難しいですね。

左から表示用画像、OCR用画像、サムネイル画像

こんな感じで三枚の画像を生成しています。

その他作ってみた感想

  • OCRで縦書き認識で精度が出ない、、、
    • 絵日記テーマの本文を縦書きにするか横書きにするか結構最後まで迷った
    • 特に一行の最初がカタカナから始まるとうまく認識されないケースが多い
  • OCR時に背景を取り除くジャッジをしたので、テンプレートっぽい表現ができない
    • 例えば、絵日記だと 月 日 天気: みたいなのを作りたいが、これに書き込まれた時のOCR用データは 1 18 晴れみたいになってしまう。
  • ノートっぽいテーマは気に入っている
    • 5行ごとに罫線の端に丸がついているのがこだわりポイントです。
  • canvas って CSS で背景設定できるんだ、というのが気づきポイント
  • 古い記事との互換性について
    • テーマ機能リリース前に投稿された画像は背景が rgb(255 255 255 / 1)で塗りつぶされており、テーマ機能リリース後の投稿とは互換性がないため、古い投稿ではテーマ機能が使えない
    • 以前の投稿ではテーマ機能のボタンを無効化し、ツールチップで使えないことを伝えるように修正
  • DBに保存されている記事のメタデータに作成したエディタのバージョン情報がない!! のでこのあたりの制御がむずい!!
    • 7月ごろに作ってる時は入れよ〜っと思ってたんだけどね。完全に忘れてたね。
    • 今回修正しました。
  • テーマ変更ボタンで思い出したけどこのアイコンで通じるのか...? テーマ変更、みたいな一般的な概念あんまりないっぽくて、 material icons に一発でそれとわかりそうなアイコンなかったんだよね
    • dark mode とかのスイッチはある
    • そもそも material icons にないということは一般的な概念ではない*2ので、アイコンではなくテキストで表現した方が良いのでは?

*1:https://tsuzuru.app

*2:所説あり

LINE WORKS APIで動かしていたbotが12月4日から動かなくなっていた件

単にトラブルシュートに時間がかかっただけで酷いオチなんだけど、JSON Claim Set の iatexp を文字列で指定していたのがダメ。

RFC 7519 もこれらの値に関しては

Its value MUST be a number containing a NumericDate value.

と言っています。

トラブルシュートの過程で Base64url でエンコードるべき箇所が普通の Base64 になっていたのも見つけたのでこの機会に直しておいた。こっちはまだ受け付けてくれてるっぽいけどいつ弾かれるかわかりませんからね。

手書きブログサービス「綴る」をリリースした

しました。

5月ごろにiPad Pro と Apple Pencil を買って、それからしばらくメモアプリに色々書き込みながら過ごしていただけれど、しばしばこのままオンラインで公開したいな〜と思う瞬間があった。

同時に、お絵描きツールを自分で作ってメンテしたいという気持ちが昔からあったのを思い出し、じゃあ作るかということで形にした。

コメント機能とかもないし、色々と不足はしているけれど、最低限の機能は出来上がったのでリリースすることとした。

基本的に PC+ペンタブ か、タブレット+スタイラス での使用を想定しているけれど、PCの場合マウスでも書き込めるようになっている。

スマートフォンの場合、タッチ操作に対して編集画面のスクロールなのか線の描画なのか区別がつかない、という素朴な理由で使うことができなくなっている。

マイクロブログサービスのような気軽に投稿、という方向性のサービスではないので、これでいいかなとも思っています。

フリーハンドでの入力を前提としているので、文章以外にも簡単なイラストや手書きの地図なんかを添えても面白いと思います。

お楽しみください。


ちなみに私の日記はこちら: side_tanaの日記 | 綴る

trade-static-normalizer をリリースしました

github.com

財務省貿易統計という資料が公開されておりまして、HSコードごと、年月ごとに輸出入金額やさまざまな数量を調べることができるわけです。

HSコードというのは「商品の名称及び分類についての統一システムに関する国際条約」で定められている品目ごとのコードで、例えば 綿製のTシャツであれば 6109.10.900 が割り当てられているようですが、素材やプリントの有無でも変わるようなので、もし何か輸入しようと考えておられる方は通関士の方や関税局の方とよくよくご確認をされるのが良いでしょう。

ともかく、そういった分類ごとに輸出入の統計が出ているものですから、特に輸入に頼っているような商品であれば、国内のマーケットがどの程度あるか、と言ったことを実際のデータをベースに考える材料になります。輸出は輸出で、相手国ごとのデータもあるようですから、自社で取引のない国でも実は大きなマーケットが、、、と言ったことを調べるヒントになるかもしれません。

ともかく使い出がありそうなデータなのですが、いかんせんフォーマットが計算機で処理しにくい。

ということで正規化するためのツールを作りましたのでここに公開するものであります。よかったですね。

自分が使う前提で考えられているか

ソフトウェアを開発する上で機能要件の話に終始してしまうことがあると思う。特に開発者が利用者ではない場合は悲惨だ。

ユースケースヒアリングは合意が取りやすい一方、非機能要件、とりわけ使い勝手の部分については、担当者がどのように業務を遂行しているかつぶさに観察する必要がある。その点、開発者が利用者である場合はヒアリングもインタビューも必要なく、どうすれば自分(達)が使いやすいかを考え抜けばいいから幸いである。

このような幸いな状況は作り出すことができて、つまり開発者を実際に利用者の立場にしてしまい、半年なのか一年なのか、あるいはもっと長い時間実際に業務に取り組んでもらうのが現実的なのだと思う。逆パターンももちろん可能なのだけれど、より難易度が高い気がする。