譜類添付機能実装を一段落させた。出振るい・手定め済み。

• 譜類添付機能の様子

いくつか課題は残ったものの，これで譜類添付機能の基礎が出来た。輪郭選り手の領当てもほぼ完成形と言っていいだろう。本当努を通して，関連仕様検討や，中途半端だった libxtd の譜類操作関連交度の整備なども大きく進んだ。

用合いとしては，録入り中の描写選り手左下に譜類添付ボタンを置き，譜類選択と同時に上信を開始，完了したら埋め込み記法で +[拡張子] を追記，下見を開く（開いている場合は更新する）という形になった。すでに同拡張子の添付譜類が存在する場合は上書きする。予定通り，描写内の参照を消して描き出し・描き直し，または輪郭削除で削除されるようにした。

当初，譜類選択後に専用の下見機能付き小窓を開き，確認してから送信，という用合いを考えていたが，素早く描き出したい場合に煩雑になり，交度の複雑化に見合わない可能性があるため見送った。「送信中...」，「+[拡張子] を追記しました。」，「.[拡張子] で保存しました。」（上書きの場合）の3種類のメッセージを @msg で表示し，下見に関しては既存の下見機能を利用すれば十分なことに気付いた。描き出し前には上信せずスクリプトで保持することも検討したが，これもページ遷移などへの対応も考えると無駄な複雑化を招く可能性があるため見送った。

対応形式はとりあえず JPEG，PNG，GIF，WebP のみ。WebP 以外の場合は長辺が1920px以下の WebP に変換する。WebP の上信に関しては，ImageMagick の未対応パッケージがまだ多いことなどから，1MiB のサイズ上限のみで対応することにした。その他譜類のサイズ上限は原則として5MiB。サイズ上限以外は基本的に kn upl の仕様に合わせたが，cwebp が ICC プロファイルも捨ててしまう問題に気付いて kn upl ともども -metadata icc を加えた。

埋め込み記法では，拡張子のみ，知番と拡張子の組み合わせに加えて，輪符と拡張子の組み合わせにも対応した。

下見機能を利用するために添付譜類の舞覧隠し戦略も見直した。結局，譜類の更新時印から隠し破りを付与出来るようにし，隠し破りの有無で Cache-Control の public と no-cache を切り替えられるようにした（5歩。これまでは一律 no-cache だった）。Dex が実譜類に依存するのは水平拡大を考えるとどうかと思ったが，そのうち KNEST 隠し化すればいいと判断した。

最後の最後で，領下手定め環境で問題なかった新規描出フォームの添付譜類が本番環境では 404 Not Found になるという問題にはまったが，これは systemd の PrivateTmp による問題であることが分かり，一時的に無効化してから問題無いように修正し，元に戻した。新規描出フォームでは無駄に永続譜類を残さないように /tmp/ を利用していたことが原因だった。最終的に，これが大して意味を持たない設計になったので再描出フォームと同じ自我台録を利用することにした。

23日の開発から急速に進展したデライト高速化も一段落した。

テーマ切り替えボタンの用合い検討（4歩），新規描出フォームへの移動機能として吹き描き外背景のダブルクリック用合いの復活（10歩），全知検索ページャー周りの調整（16歩），こまごまとした領当て・装体調整（17歩）といった雑多ながら充実した作業を片付け，ついに描写後略機能を一段落させた（21歩）。出振るい・手定め済み。

描写後略機能により，デライト最初期から吹き描きの構造的問題だった「不必要な出与え読み込みの多さ」という問題が解消した。表示速度向上，通信量削減，SEO 強化，迷惑行為対策など多大な効果が見込める。

デライト高速化の現状と今後

昨年末の壊衝不具合修正以後，デライトは速度・安定性ともにウェブ相振りとして十分な水準に達していたが，今回の高速化を経て，明らかにもう一つ壁を越えた感がある。体感として，「ウェブ相振りなら特に不満のない速さ」から「単動相振りと比べても遜色のない速さ」になった。

一昨年4月9日に掲げた「全ページ0.3秒以内表示」という目標は埋め込み利素を考えると現実的ではない気がしてきたものの，軽いページでは200ms台，重いページでも概ね300ms台で応答出来るようになっている。実感として欲しかった速度は手に入れられたし，最適化余地はまだまだ残しているので「埋め込み利素を除いてほぼ全てのページで0.3秒以内表示」なら十分手が届く。いよいよ本格的に，速さがデライトの武器になってきた。

ここで新生デライト開発におけるデライト高速化は一段落とし，今後は機能追加やトラフィックに応じた微調整に留め，別の機能整備に集中することにした。

その先のデライト高速化については，大きなところでは CDN 導入，KNEST による水平拡大，請い手の隠し機能整備，描写 HTML 隠し以外の HTML 隠し実装，そして中途半端な状態で放置しているページ付け求頼改良があるが，どれも現時点での優先順位は低い。

（進捗時限記録中略）

全知検索ページャー周りの調整で終了。

不統一感が気になってきたため，ダブルクリック／ダブルタップでの新規描出フォームへの移動機能に合わせて基本的なページ内移動で半溶暗するようにした。これでちかちかする問題はほぼ解決した。

ついでに，全知検索ページャー周りの点検・調整。普段さほど使わないので，意外な挙動や課題を把握しておいた。

ちょっと困ったのが，更新輪結による輪郭一覧動的更新で条件によって大きくスクロール位置がずれることだった。結局，要素の削除・追加で生じるらしいことが分かり，スクロール位置を記憶しておいて復元することで解決した。

（進捗時限記録中略）

全知検索窓固定機能に吊るし輪郭への輪結と新規描出フォームへの輪結を加えるアイデアについてまとめて終了。

画像素材は，背景用の二輪鎖，上矢印と＋のアイコンといずれも既存のものを使い，自我アイコンの左側に配置する。幅狭領当てでは，入力欄への捕活時に隠れ，入力欄が伸長するようにする（開発者通類で作った案）。

新規描出フォームへの素早い握接は長いあいだ課題だったが，これも急に解決してしまった。新規描出フォーム固定機能との関連で考えることが多く，今回も先の検討中に考え始めた。

右下あたりに輪結を固定させるのがよくある方式だが，何度考えてもデザイン的なまとまりに欠ける。何より幅狭領当てでは重なりが気になる。明らかに邪魔だろう。

新規描出フォームの左上にある＋ボタンは元々新規描出フォーム固定機能を兼ねていたので，これをスクロールに追随させて，どこでも新規描出フォームを呼び出せるようにするか……等々，これまでとにかくあらゆる案を検討したが，どの案にも何かしら問題があった。さっき方針が固まった全知検索窓固定機能に合わせ，下スクロールで現れるバーにしても，せっかくの占有領域を減らす工夫が相殺されてしまう。

デライトの構造上仕方ないこと，と新規描出フォーム固定機能のように諦めかけたが，こうなったらもう全知検索窓を何とか利用するしかないのではないか，と再び考え出したのが良かった。

（進捗時限記録中略）

知名欄・描写欄の捕活（フォーカス）に関する仕様検討の結果，ともに「マウスオーバーで捕活する」仕様を確定・実装した。出振るい・手定め済み。

なお，知名欄の自動全選択については正式に廃止を決定した。

仕様というほど明確なものではなく，時期によって実装上機能しないこともあったものの，デライト初期実装からのマウスオーバー時の挙動は，知名欄では捕活・全選択，描写欄では捕活，という方針だった。これは，実用上の都合というのも大きく，こうでなければ単純に描出効率が悪かった。

昨年9月までの第二次用合い改良中の交度整理で，知名欄の捕活・全選択は機能しなくなっていた。これは確か，中景輪符の事象（イベント）を改良したことで干渉の懸念があり，再実装を後回しにしたという経緯だった気がする。もっと地味な描写欄の捕活は過去に何度か再実装した記憶があるものの，どの時点で機能しなくなっていたのかは曖昧だが，いずれにせよ，第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた。

もしかしたら，これはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが，輪郭整備のように描出効率が重要な作業になると，クリックでの捕活はやはりまどろっこしく，鈍重に感じる。そこで最近はかつての挙動を復活させる機会を窺っていた。

懸念は，他要素・他機能との干渉や誤操作だったが，これは昨日の検討から急速に氷解した。今のデライトで，マウスオーバーで捕活が移動すること自体は前提のようなところがあるので用者体験に大きな悪影響はないだろうということ，むしろほとんどの要素がマウスオーバーに反応するのに知名欄・描写欄が無反応なことが直感性を損ねているとも言えること，スクロールとの干渉も実際の舞覧（ブラウザ）では生じないこと，誤編集の問題については，そもそも閲覧・編集用合いを切り分けていることが一定の保護機能になっており，更に取り消しボタンで変更有無が分かるようになることで大きく軽減されること，などの理由で，大きな問題はないという結論に達した。

そこでまず，知名欄の全選択も含めてマウスオーバーでの捕活機能を復活させてみた。ところが，知名欄の全選択については数十分で廃止を決定することになった。実装上の問題としては，選択状態がやはり周辺要素と干渉する。干渉しないようにマウスアウトで解除すると，今度は選択状態が意図せず解除されやすくなる。もっと問題なのは，誤入力で上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態が好都合だが，知名欄での利点は写し取りが素早く行えることくらいでさほど大きくない。

これは，今のデライトで，慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても，熟練用者向け過ぎて採用出来ない。

次に，知名欄の全選択機能を外し，捕活だけにしてみると，これはむしろ想像以上に好感触だった。地味ながら，編集の軽快感は明らかに向上している。捕活さえしてくれれば Ctrl + A で写し取りも十分効率的に行える。今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお，捕活時に発生するスクロールは意図しない場合が多く考えられるため抑止する。

どこまで普遍的な現象か分からないが，常用している Linux の Firefox では，<textarea> の選択状態を残して捕活解除すると，再選択のつもりが（未捕活状態のせいで）意図しない文字列ドラッグが発生しやすいため，これがなくなったのは個人的に嬉しかった。近頃多用している複数輪符の引き入れ欄への写し貼りで障害になっていた。

とにかく，第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった。

（進捗時限記録中略）

再描出フォームの輪郭選り手の変更有無で取り消しボタン（×ボタン）の装体が変わるようにした。ついでに，新規描出フォームの取り消しボタンの不具合などを修正。

前々から変更有無の表示機能を取り消しボタンに兼ねさせたいと考えていたが，昨日の開発での輪郭削除ボタンの新装体と同時にイメージがまとまった。

変更無しの場合は従来通りに，変更有りの場合は背景色を pink，lightpink（配灯時）にし，× を少し大きくした。表現方法は輪郭削除ボタンに合わせ，注意すべき操作であることが直感的に分かるようにした。

これまで，開いた輪郭選り手の変更有無を確認するには，ページ更新をして，下書き抜控が復元されるかを試すしかなかった。小さな変更だが，用合い上の効果は大きい。

新規描出フォームの取り消しボタンは従来通り，緑色の目立たないボタンで現状維持とした。復元ボタンもあるのでさほど注意すべき操作ではなく，悪目立ちする懸念がある。

その代わり，以前から怪しかった取り消しボタン・復元ボタン間の切り替えや下書き抜控削除のタイミングなどを調整し，おかしな挙動はだいぶ減らせた。

画像生成人工知能のように，誰が見ても分かる明らかな革新，というものに欠けているのが現状の個人知識管理シーン。誰もが雰囲気止まりで使っているような歯痒さがある。

稚拙な転売批判の一例でいうと，「転売屋は作者から利益を奪っている！」というのが驚くことに少なくない。転売屋は正規に買って，高くても欲しいという人に売るだけなので，それは流石に筋悪。気持ちは分かるだけに，もう少し練ろう，と思ってしまう。転売批判がこのレベルなら転売屋は安泰だろう。

ソフトウェアに弱い日本人がなぜソフトウェアの一種であるゲームでは強いのかといえば，組織力や地道な努力といった日本人の強みが活かせるから。ツクールの類を投げ出したことがあるなら分かるはず。それも人工知能が変えてしまうのかもしれない。