装体調整で終了。

下書き抜控一覧の行間が詰まって見えたため，前後景部輪符同様 line-height: 1.5 を設定しておいた。

交度埋め込み記法調整で終了。

5歩の検討通り，交度埋め込み記法の対応言語に tex，latex，katex を追加した。出振るい・手定め済み。

非対応言語では通常の交度記法同様の交度部区で表示するようにした。特に定義していなかったため Mermaid で使う <pre.mbd> で表示されていたが，これは交度部区にもならず，描画途中で目立たないように薄い文字色にしており普通に読みやすいものではなかった。

ついでに，<pre> に設定していた #DCDCDC の文字色を <pre.cd> に移した。これは Zenburn の文字色で，構文配灯の前後で文字色を一定させるためのものだったが，背景色を設定していない普通の <pre> がほとんど読めなかった。

さらについでに適当なマージンも設定しておいた。<pre> はタグ記法も未整備で他に大した用途が無かったので長いこと調整せず放っておいた。

（進捗時限記録中略）

ついでに新規描出フォーム固定機能についても検討して終了。

こちらは「限りなく廃案に近い保留」となった。

全知検索窓固定機能同様，デライト最初期に実装・削除したものだが，これは広告との相性以前に，用合いとしていまいちだったということが大きい。

新規描出フォームを固定出来れば，輪郭一覧を眺めながら描写を書くことも出来て便利に違いない，と素朴な期待から実装してみたが，これが帯に短し襷に長しという感じで思いのほか使えなかった。

大きな原因は，ページ遷移までのちょっとした間固定されるだけ，という中途半端さにあった。あちこち飛びながら作業しているといちいち解除されるので，自然に使わなくなっていく。

これに対処しようとすると画面分割機能に近い大掛かりな仕掛けが必要になる。画面分割機能は何度も検討したが，やはりデライトには過剰と判断して，複数窓で使いやすくする方向で単純性を保ってきた。今考えてもこれは英断だった。

自動ページ展開や輪郭一覧動的更新がある今なら当時よりは使いようがあるかもしれないが，その分，ページ遷移の条件が分かりにくくなっているので，かえってストレスかもしれない。

複数窓が使いにくいスマートフォンなどでも，新規描出フォームと柔品キーボードで画面がほとんど占有されるため恐らく使いものにならない。当時は諸場で使える状態ではなかったので想像ではあるが，複数タブで使う方がマシだろう。

結局，構造的にデライト向きではないのだろうと思うが，急いで結論を出す必要もない。そのうち適当な活用法が見つかればいいし，見つからなくても問題ない。というわけで，しばらく放置しておくことにした。

迷いが一つ消えたのは収穫と言える。

（進捗時限記録中略）

第二次用合い改良。

途中で終了。

装体調整。

• パンくず部区の折り返しがおかしかった問題を修正。
• 輪郭小窓内で前次部区装体が見にくかったため幅狭領当て同様の装体を適用。
• 輪郭小窓の無効時の引き入れボタンがグレースケールだけでは目立ち過ぎていたため半透明化。

輪郭選り手抜控機能整備を概ね終え，ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが，抜控機能整備についてはここで一段落とすることにした。

この出振るいにより，中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり，抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また，周辺の交度整理も大きく進み，理腑としての意義も大きかった。

利便性・信頼性の向上はもちろんのこと，昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか，着手して間もないので，ここから思考を整理しやすくなる。

抜控機能整備が長引いた最大の原因は，他にやりたいことが多過ぎたことだが，これ自体も決して簡単な作業ではなかった。ただ，この間に設計方針が変わったり深刻な不具合に気付いたりしたので，時間をかけたことで円滑に片付いた面もある。

再描出は知番でいいとして，新規描出の鍵をどうするか，というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので，基本的にこれを踏襲することにした。ただし，全知検索窓から未送信の検索語まで取っていたため，これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった（4月28日20歩で書いた消失不具合の原因だろう）。これは求頼文字列から取ることで回避した。

下書き抜控一覧についても，表示条件や領当てなど色々考えることが多かった。検討の結果，再描出下書きは，検索語無しの場合（上部メニュー同様）のみ輪郭一覧の上に表示（画面撮り），新規描出下書きは，他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした（画面撮り）。邪魔になり過ぎない程度に気付きやすい。また，4月10日の開発で決めた通り，一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが，やはり，用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下，消失リスクの増大（あるいはそれを補う作業コストの増大）に繋がる。目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様の設計だった。一応，鍵仕様変更時の更新方法は考えていたが，手間を考えるところころ変えるわけにもいかないので，長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時，鍵に仕様変更日時を含めることを考えていたが，これは複雑化を招くだけなので廃案とし，Aejs_DG_rev に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め，自我の切り替えにも対応した。

その他，これまで描写のみ保存していたのを知名にも対応する，消去ボタン・復元ボタンを実装する，などこまごまとした問題を片付ける必要があった。

出振るい後，軽微な不具合がいくつか見つかったが，一番気になったのが，鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが，本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に，3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。

少し迷ったが，時間が経つにつれ重要性が急速に低下する部分なので，調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから，深刻な問題は発生していないと判断した。今後，同様の処理を書く際の注意点として記憶しておく。

（進捗時限記録中略）

細かい装体調整など。

「iOS上のSafariで，横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが，確かに手元の iPhone で同様の現象があり，気になっていた。デライトの不具合にしては不可解なのでもしかしたら舞覧の稀なバグなのかと思ったが，再現性があるらしいことが分かったため調査した。

結局，諸場舞覧の自動拡大機能であり，text-size-adjust（-webkit-text-size-adjust）という制御用の CSS プロパティまで用意されていることが分かった。以下のようにして解決。

-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;

もう一つ，諸場舞覧で気になっていたことに，輪結やボタンのタップ時に妙な効果が入るというのがあったので，ついでに調べてみると，これも諸場舞覧特有の機能で，-webkit-tap-highlight-color で不可視に出来た。

スマホを弄っているうちに，iOS の Safari で全知検索ボタンの動き付けが止まっていることに気付いた。

これはフォームの送信などで描画処理が停止する Safari 特有の仕様であることが分かった。Safari の問題といえばそうだが，実用上の問題はなく，まともな解決策も無さそうなので放っておくことにした。

全知検索整備の方針も定まったことだし，そろそろページ遷移無しで輪郭一覧の更新が出来るようにしてもいい頃だろう。

（進捗時限記録中略・前後）

何気なくマイクロブログサービスの用者（ユーザー）を示せる記法が欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので，軽くまとめて終了。

とりあえず，分散型 SNS で使われている記法を拡張し，@[用者名]@[ドメイン名] の汎用記法を整備する方向で進めることにした。

要は，@user と書いたら Twitter に輪結したり，@user@example.com と書いたら分散型マイクロブログの捌き手に輪結してもいいのではないか，と考えたことがきっかけだった。

ここで一つ，@user@example.com は https://example.com/@user に必ず対応するのだろうかという疑問が湧いた。以前にもなんとなく考えたことはあったが，ActivityPub というか Webfinger で URL を引き出したり，面倒臭そうな気がして進展しなかった。このあたりの仕様がどうなっているのか，いまだによく分からない。

もっとも，ざっと見渡す限り分散型マイクロブログの捌き手は大体 https://example.com/@user になっているし，自分で Mastodon 捌きを運営していた時も出放りはこれだったので，事実上の標準とみなしていいのかもしれない。

Twitter は @user でいいかと思っていたが，いくら普及しているとはいえ，これは特定サービスに寄り過ぎだろうということで，@user@twitter.com で統一することを考えた。ただ，Twitter のプロフィールページの正規 URL は https://twitter.com/user だ。https://twitter.com/@user でも転送されるとはいえ，若干気持ち悪い。

越化（エスケープ）周りの客体表現化を考えるついでに文字参照の越化について再検討して終了。

HTML 越化仕様を決めた昨年5月20日12歩以来，越化目的で使う可能性がある文字参照のみを許容していたが，これは修正し，いったん全ての文字参照を許容することにした。

4日21歩でも再検討したが，越化記法同様，デラングにおける特殊文字を白表方式で管理するのは無理がある。損われる保守性に対して利点が乏しい。

当初は制危というより迷惑行為対策など運営上の都合で必要になるのではないかと思っていたが，Wikipedia はじめ大規模サイトで開放されている例も珍しくなく，少なくともデライトの言語仕様にするほど必要な制限とは言えない。文字参照で制危上致命的な問題があればそれは舞覧の問題だろう。迷惑行為対策としてもあまり本質的ではない。

何か問題があれば制限する，で十分なはずなので，実装都合で制限してもいいことにする。

文字参照には，表示や入力に難がある文字が記述しやすいという有用性も一応ある。