従来はすべてのレイヤーの大きさはキャンバスの大きさであり、また背景レイヤーの完全に直上にある構造だったがこれをやめ、レイヤーごとに大きさとオフセットを独立して持てるようにした。それに合わせて、いわゆるレイヤー移動ツールを実装した。
と文章で書くとこれだけなのだが描画のあらゆるところでオフセットを意識するように書き直すのは死ぬほど大変だった…。その割に見た目は何も変わっていないと言う。
次は矩形選択ツールを作る。
言うまでもなく Ubuntu は Debian 系のディストリビューションなので、プログラムのパッケージをインストールするには apt を使い、deb パッケージを扱うのが通例だ。が、ここへ来て snap パッケージというものも使えるようになっている。
大きな違いとしては snap の方は対象がある程度の規模かつ OS からは独立したアプリケーションであるように思える。snap でインストールされるプログラムから見えるファイルシステムはサンドボックス化されていることからそれが伺える。
それから、snap の方は毎日アップデートがチェックされ、特にロックしない限り勝手に最新版に追従するとのことだ。へー。
ところで困るのが、deb と snap に両方同じアプリケーションがある場合と、あるタイミングでどちらかに移行した場合である。前者の場合は例えば gimp とか、vlc とかだ。両方入れるとどうなるんだろう？ 多分大丈夫なんだろうけど、一応念のためにあらかじめ deb 側はアンインストールするようにしている。後者の場合は例えば Ubuntu 16.x 時は画像ビューアとして comix が用意されていたが、18.x にアップグレードするとそれが問答無用で削除され、特にアナウンスもない…みたいなことが起きる。これは snap 側に後継である mcomix が存在している。このように2つのリポジトリそれぞれの相関や移行と言ったその運用があんまり考えられていないように思える。
ファイルシステムのサンドボックス化と言えば、スクリーンショットを編集したい場合、従来だととりあえず PrintScreen キーを押して、出てくるダイアログで gimp での編集を選んで実行…という流れだったが。gimp を snap で入れるとホームディレクトリ以外の場所を触れない（正確には、触れるが本来のファイルシステムから分離される）のでその流れで編集できなくなった。スクリーンショットはとりあえず /tmp/ の下に保存されるからだ。
どうするかというと、いわゆる昔ながらの Unix 的な流儀から全く離れている気がするが、gimp 自身がスクリーンショット機能を持っているのでそれを使う。うーん。まあそれでもいいけどねーいやーそれはどうなんだろうねー。
特にまとめもなく突然終わる。
ここのサーバは xrea である。xrea のサーバには、ssh でログインできる。それを利用して、ローカル上の成果物を rsync を通して xrea 上に配布することができる。楽。
ただし、どのホストからも ssh で入れるわけではない。事前にブラウザからコントロールパネルページを開き、ホストを登録する必要がある。
さてこのコントロールパネルページが最近リニューアルされてなんかおしゃれな感じになったのだが、ところが新しい方には前述のホスト登録機能がどこにも見つからないのである。以前あちこち探しまくって、こんなところにあったのか！ となったことは数回あったのでどこかにはあるんだと思うが、現在は全然見つからない。
そんなわけで、古い方のコントロールパネルに切り替えた上でホスト登録をするという作業を強いられて、実に面倒くさい。
ところでリニューアルに伴って、コントロールパネルの機能をプログラマティックに呼び出す REST API が設けられたという。この中にホスト登録機能も含まれているので、ローカルの cron でよしなにすることにした。
それにしてもホスト登録機能、どこ行っちゃったんだろ…。
キャンバスに描かれるペンのサイズを事前に図示するために、カーソルの形状を CSS の cursor プロパティにより変更している。
が、Chrome ではこのプロパティにより設定できるカスタムカーソルの最大サイズに制限がかけられることになると言う。
https://www.chromestatus.com/feature/5825971391299584
https://bugs.chromium.org/p/chromium/issues/detail?id=880863
カーソルの形状の変更はおそらくネイティブなウィンドウシステムの機能に依存しているだろうから、最小公倍数的な仕様に揃えるということなのかな？ と思ったらどうもカーソルの形状を変えることで誤クリックを誘導するような邪悪な広告対策のようだ。なんて世知辛い世の中だ。
というわけで桃缶でもそういう対応を入れることになったのであった。
ふたばの一部の画像掲示板には手書き機能が備えられている。が、赤福プラスはふたばのページを自前のページ構成で上書きしてしまうので、その備え付けの手書き機能をそのままでは利用できない。そこでだいたい同等の手書き機能を赤福プラス自身が内包している。
しかしこの手書き機能が別に使いやすくもなんともなかったりする。とはいえ手書き機能は長年 dat にも img にも関係なかったのでつまり別に困ってなかったのだが、今回 img でも手書き機能が有効化されたので、そういうわけにも行かなくなったのである。そこで改めて手書き機能を眺めてみると、いろいろと機能が欲しくなってきた。具体的にはレイヤー機能が欲しい。
とそういうことで作ってみた。とりあえず開発しやすさを鑑み、赤福プラスとは独立したブックマークレットとして仕立てた。そのほうが多くの「」やとっしーも試せるし。
桃の缶詰
https://appsweets.net/momo/
ネーミングは例によって別に意味はない。さて公開後のいろいろな不満を浚ってみると、だいたい以下の2点に集約されるようである:
書き込みに del を入れる際、いつの間にかリクエストに間を置かないといけなくなっている。そのインターバル内に複数リクエストすると「操作が早すぎます」云々と怒られる。
現状では del フォームの OK ボタンが押された際に同期的に処理していたのだが、これを改めて del リクエスト専用のグローバルなプロミスを用意し、OK ボタンのハンドラでは単にそのプロミスにリクエスト（及び 10 秒待機するディレイ）をチェインするだけにした。これにより操作が早すぎると怒られることはなくなる。また、del 済の書き込み上の del リンクはイタリック体にするようにした。ただしこれは永続化的な処理はしてないのでページをリロードすると元に戻る。
副作用として、山ほど del を入れて即ページを閉じたりすると予約されたほとんどのリクエストが水の泡となってしまう。まあ普通山ほど del を入れること自体がかなり奇妙な行動なのでこれはこれでいいか。
虹裏 (img) でレスに手書き画像を添付できるようになった。以前は逆に、手書き画像でスレッドを立てられる仕様になったことがある。しかしこれにより管理人さん曰く「板が破綻した」結果となって、撤回された…という経緯がある。しかし今回は、今のところ上手く回っているように見える。
そういうわけで、諸々に対応した。最も重要なのは、レス送信モードで手書きが有効な場合に画像の貼り付けに対応したことだ。これの何が面白いのかと言うと2点あり、
テストのために適当に手書きをしてみたものの、trackpoint で絵を描くのはとてつもなくストレスフルだ。何か適当なペンタブレットを探してみるかな。
ウィンドウを狭くした際に盛大に崩れるのでそれなりになるようにした。
そう言えば Chrome って横幅のリサイズに限度ができてたんだっけ。この最小の横幅って全てのプラットフォームで共通なのかしら。
フルリロード、差分リロードした際に読み込んだバイト数を記録しているのだが、これは実は概算であって正確な値ではない。というのは意外なことに javascript から実際に読み込んだバイト数を得る方法はけっこう限られている。特に、レスポンスボディが圧縮されているとそれが顕著になる。
まずレスポンスヘッダ内の Content-Length があれば、それが読み込んだバイト数となる。終わり。圧縮されている場合は圧縮されている状態の転送バイト数となる。ふたばのサーバでは、html ファイルを読み込むと gzip 圧縮されたものが Content-Length 付きで返ってくる。しかし、差分リロードした際のリクエスト（これも gzip 圧縮されている）には Content-Length はない。したがって差分リロードの際に何バイト読み込んだかは全くわからない。
次に XMLHttpRequest の progress イベントをリスンすると、loaded プロパティと total プロパティで転送バイト数が得られる。ただし、内容が圧縮されている場合はこのイベントは少なくとも Chrome ではあまり役に立たない。全体を読み込み終えたあとで 1 回だけ発生し、その際 total は 0、loaded は展開後のバイト数が格納されている。つまり、圧縮状態の転送バイト数は読み取れない。
また、ここまではレスポンスボディの話だったがレスポンスヘッダのサイズも javascript からは正確なその値を取得できない。XMLHttpRequest#getAllResponseHeaders() が返す値は微妙に加工されている（HTTP/1.1 云々のラインなど）。加えて書くと、プロトコルが HTTP/2 の場合はヘッダも圧縮されているのでなおのこと実際に転送されたバイト数はわからない。
ということで差分リロードの際の転送バイト数および https 上の各読み込み時のヘッダに関してはヒューリスティックな謎の係数を使って圧縮後のサイズを概算しているのであった。これがだいたいの場合だいたい合ってるようなのだが合わないときは盛大に合わない。
さてどうしたものか。
文字参照というものがある。" とか、  とか、　 とかいったアレだ。赤福プラスが html ソースを DOM ツリーに変換する前に、それらを解決してしまいたい。解決というのは文字参照の表記から文字そのものに変換するということだ。
それが必要な理由は、たまに絵文字の表現としてそのコードポイントをサロゲートペアの文字参照で表記されるケースがあるからだ。これはそのコメントを送出した UA つまりブラウザか、拡張か、あるいは専ブラか……の明らかなミスで、サロゲートペアを文字参照で表記してはいけないのである。いけない表記をすると当然ペナルティがあり、それらは DOM パーサによって U+FFFD に置換されてしまう。これを、置換される前に気を利かせて解決したい。従ってそのために必要な処理は DOM パーサに渡す前段で行わなければいけないということになる。
ただし、この不正な文字参照の修復が可能なのは自前で DOM パーサにかける処理が入るフルリロード、及び内部データを JSON で取り扱う差分リロードをした場合のみである。最初にスレッドを開いたケースは構築済みの DOM ツリーから innerHTML を得るしかないため、既に書き込まれてる不正なサロゲートペアの文字参照は修復できない。この辺ふたばの鯖側で巧いことやってくれるとうれしいのだけど、しかし前述の通り原因はへんてこな UA の動作なのでふたば側がそんなことをする筋合いもないのが難しい。