CSS アイコン実装から動的引連 SVG アイコン実装に切り替えることにした。軽く実験してみたらやたら捗ったため，改めて早期実装を目指すことにした。

昨日の開発記録を書いてみて，CSS アイコンの調整にかかる時間も馬鹿にならないなと考えながら，何気なく Google 検索の素出を覗いていたら，意外に上手くアイコンが SVG で表現出来ているなとは思ったが，やはり HTML で出力している引連 SVG アイコンは気持ち悪いと感じた。ここで，「行き詰まりを防ぐための選択肢」として残すことにしていた（4月27日の開発記録）動的引連 SVG で凌ぐことを思い付いた。

これまで見てきた例や解説が悪かったか，「SVG は煩雑」という先入観がありずっと苦手意識を持っていたが，引連 SVG 関しては，<path> を中心に削ぎ落とせば十分簡潔に出来ることが分かった。例えば，従来のデライトの + アイコンは以下の記述で十分表現出来る。

<svg viewBox="0 0 32 32">
  <path d="M 4 16 H 28 M 16 4 V 28" fill="none" stroke-width="5.5" stroke-linecap="round"/>
</svg>

引連 SVG なので，CSS や JavaScript での各部分の操作も容易だ。直接編集もやたら難しいと言われているので面倒臭そうだなと思っていたが，何のことはない，すぐに習得出来てしまった。CSS アイコンの調整に比べれば直感的ですらあるし，拡縮時の品質は比べ物にならない。これで外部通類への依存という懸念も払拭出来た。あとは，HTML の肥大化と保守性の低下という引連 SVG の二大欠点をスクリプトで補えばいい。動的引連 SVG なら部品の再利用も十分柔軟に出来る。

元々 CSS アイコンを中心とした枠組みの応付だったので，作ってきた枠組みをそのまま活かせるのも嬉しい所だった。動的引連 SVG を中心に，CSS アイコンの方を応付として交代させるだけで大きな方針変更も必要なかった。

（進捗時限記録中略）

動的引連 SVG アイコン実装。

途中で終了。

SVG スプライトの手法を取り入れ，SVG アイコンの定義は icn.svg に集約することにした。

SVG 出与えも Aejs に組み込んで直接挿入してしまうことを考えていたが，舞覧隠しの適切な分離が出来なくなる，要素の再利用に必要な id 属性が使いにくい，といった問題があった。外部 SVG を <use> で利用すれば Shadow DOM になるので，id 属性の衝突などを気にせず要素を整理しやすくなる。

スプライト画像として background-image で利用しやすいというのも大きい。:target とフラグメント識別子を利用して表示要素を変化させる技術があることを知ったが，舞覧によっては効率的に隠し出来ないことがあるらしく，今回は見送った。<view> が使えればいいが，Safari の対応に難がある。当面は古典的な座標指定で行くことにした。

アイコン制作では，アイコンを並べて全体のばら成しを見ながら調整することが多いため，見本を兼ねられるのも便利だ。

SVG スプライトだけで十分かもしれないと思いかけたが，<use> 1つでも若干冗長な上に，1つのアイコンの要素を細かく制御したい場合に <use> が複数必要になるため，やはりスクリプトでの補完は欲しい。

主に CSS アイコン実装。

一つ一つ課題を解決しながら進めているので時間はかかっているが，何かと知見を深めることが出来ている。やはり総合的に CSS アイコンの利点は大きいので採用方針は変わらないが，割り切りと誤魔化しの技術が肝だなと感じている。そこを抑えられれば強力な武器になる。

CSS アイコンの欠点として，拡縮時に歪みやすいということが理解出来てきた。スマートフォンだと再現しないので，サブピクセルのレンダリング問題なのかもしれない。拡大時に1px程度のずれが生じることがあるのはともかく，縮小時に細い線が消えたりもする。これは有名な CSS アイコン集でも同様なので，そういうものなのだろう。

もっとも，ラスター画像の主要な問題である高精細画面でのぼやけに対応出来れば十分とも言える。舞覧のズーム機能を使うような人にとって多少の表示の乱れは想定内だろう。あとは歪みにくい書き方・デザインの問題か。

すぐに終わるだろうという当初想定に反してもう少し時間がかかりそうなので，明日からは別の作業にも多めに時間を割くことにした。

（進捗時限記録中略）

デライト全体における添付譜類の方針検討で終了。

添付譜類はあくまでも添え物として最小限の役割に留め，エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。

元々添付譜類は添え物として設計しているが，実際に譜類添付機能が出来，エクスポート機能を実装しようとしてみると，実質的な役割の落とし所が意外に難しい。意図に反して，変に使われ過ぎるのも問題だ。

エクスポート機能では，とりあえずは代替 HTML などで済ませ，ゆとりが出来たら実譜類にも対応するか，などと考えていた。そもそも，どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし，そこまで神経質な人が手元に抜控を持っていないということも考えにくいので，実はさほど必要性の高い付徴ではない。とはいえ，エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから，将来的に対応しないというほどの動機もない。

しかし，添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え，それに伴い譜類保全の責任が増せば，将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様，ここは割り切った用者文化を育てていくべきだろう。

これに気付いてみて，最近，添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが，これも最小限に留めることにした。拡張子制限は制危面もあるが，献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める（例えば .bmp をそのまま上信して欲しくはない）。

デライトの強みは，知番による意味符号化で文字献典の情報密度を極限まで高め，その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降，その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら，どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。

描出公開原則のように何かこの方針に名前を付けたくなったが，「譜類添付機能」という名前で趣旨は表現出来ているので，それに立ち返るということで十分だろう。

輪符補完機能などのため描写選り手で採用する予定だった contentEditable の導入について急遽再検討して終了。

contentEditable の導入はいったん保留とし，<textarea> の座標計算用の <div> を作る手法を先に試してみることにした。

前歩で再描出フォームの maxlength 属性を設定しようとして，ふと，contentEditable ではどうするのだろうと調べてみたら思いのほか面倒臭そうだった。これに限らず，どうもそこまで洗練されたものではないらしいということが分かってきた。

デライトではさほど複雑なことをする予定は無いので，よくある装体複製 <div> を使った手法で十分というかマシな気がしてきた。装体複製 <div> も初めて知った時はどうかと思ったが，それ以上に洗練された方法が無いなら仕方ない。

contentEditable はかなり前から導入する気でいたが，当初は念のため <textarea> の実装も残しておくつもりだった。contentEditable ももはや枯れた技術なので，<textarea> は切り捨てるべきか，と最近になって考えるようになった。まさかここで正反対の方向に舵を切ることになるとは思わなかった。

（進捗時限記録中略）

設定ページ整備，エクスポート機能実装からの改行交度正規化についての検討・修正作業で終了。

KNEST では，入力を適宜正規化することにより，原則として改行交度を LF として扱うことにした。これまで曖昧だったため，出場の dln にも LF と CRLF が混在しており，Dex での処理前にいちいち正規化していた。出場の CRLF は置換し，描出時に正規化することにした。

libxtd の HTTP ライブラリの仕様にすることも考えたが，低層でいちいち厳密な検査などをしていると必要性に対して高コストになる。必要な場面は限られているため，KNEST で扱うべきと判断した。改行交度正規化用の Dex::nmlz_v() は KNEST::nmlz_v() に移動した。微妙に使いにくい位置にあり適当に写し貼りして使っていたのですっきりした。

改行交度の仕様を決めておく必要があるエクスポート機能実装がきっかけとなったが，これで将来的な混乱も防げ，多少無駄な処理も削れた。

領下手定め環境では置換・交度修正・手定め済みだが，急がないため未出振るい。

エクスポート機能では LF で決め打ちにするつもりだったが，仕様の見通しも良くなったので CRLF を選択出来るようにすることにした。

Windows 向けの CRLF と Windows 以外向けの LF として，用影で簡単に初期値を切り替えておけば十分だろう。

なぜ混在していたのかと思ったら，フォーム送信では CRLF，XMLHttpRequest では LF というややこしい仕様の違いがあったらしい。前縁ではある時期から XMLHttpRequest を主に使うようになっているため，実装の変化によるものだろう。

（進捗時限記録中略）

隠し破りを KNEST の一部として体系化することにし，仕様まとめと交度修正などを一通り終えた。緊急性は低いため未出振るい。

KNEST では，%Y%m%d%H%M%S 形式の求頼変数を隠し破りとして扱い（例：?20230101000001），デライトでもこれで統一することにした。この時印形式を「詰め込み時印」（ts_jam）と呼んでおく。

隠し破り導入以後，スクリプトや装体書などの主要静的譜類には ?upd=K170101.1 のように，希哲紀元での日付と連番の形式を基本的に使ってきたが，自我アイコン隠し破り対応では ?icon&upd=[Unix 時間] になったり，添付譜類では ?[Unix 時間] になったりと，統一感がなくなってきていた。

実用上はなんでも良かったが，譜類添付機能実装以降は用者の目に触れやすくなったため，簡潔さと分かりやすさを両立させる必要性を感じていた。Unix 時間では非技術者が理解しにくいし，技術者でも意図を理解するのに時間がかかる。それが不安に繋がることは好ましくない。特に簡潔というわけでもない。

確実性を重視するならハッシュを使うのが定石だが，抽象性が低いということでもあり，擬制的に扱いにくく，融通が利かない場面が出てくる。冗長さは一部省略で何とかなるにしても，やはり分かりにくい。

総合的に，詰め込み時印のみが一番無難だろうと結論付けた。更新時印でも整合性を保つやり方はいくらでもある。用者が意図を推測しやすく，開発者も手動で扱ったり異常に気付いたりしやすい。

強いて欠点を挙げるなら，更新日時を知られたくない人もいるかもしれない，ということくらいだが，デライトでは大きな問題ではないだろう。そもそも更新履歴を見られるサービスや投稿と同時に上信される SNS なら秘密情報ではない。

ウェブ捌きの設定などで小細工しやすいように，upd= なり mod= なり ts= なりの値として表現することも再考したが，値として扱うことを想定していない文字列という特殊性を鑑みると，それはそれで違和感がある。14桁数字列の求頼変数は隠し破り，と明確に決めておけば十分だろう。

これを機に，これまでいちいち書き換えてきた主要静的譜類用の隠し破りの更新も，mk の bld-etc で自動化した。テンプレートの一箇所書き換えればいいようになっていたものの，積み重なるとそれなりの手間だった。

自動化するまでもない隠し破りの記述もいくつか残っているが，これは ?upd=K170101.1 なら ?20230101000001 というように置換しておいた。

描写の文字数制限についての仕様検討で終了。

現行の10,000字は長文を書くと割と越えられる文字数なので，100,000字に拡張することを考えていたが，これは決定とした。現実的には50,000字でも十分だろうが，中途半端だとケチくさく見える。描写後略機能も上手く機能しているので司組が重くならない程度の制限でいい。デラングの場合，単純に人が読むだけではない文字が多くなるという問題もある。

問題は，描写後略機能のような機能が無い1行あたりの文字数制限だが，これは各記法ごとに仕様を決めていくことにした。一律の文字数制限を考えてみたが，記法によって事情が異なるので難しい。全体の文字数制限が緩和した分，負荷抑制のための柔軟な処理も必要になる。

譜類添付機能の PDF 画像化では，最初 WebP 変換せず実験していたため pdftoppm の JPEG 出力（-jpeg）を使っているが，WebP 変換しているなら PNG 出力（-png）の方がいいのではないかと思い軽く実験してみた。

結果，微小な画質の向上は見られたが譜類サイズが7倍程度に増えたため現状維持とした。PNG からの WebP 変換でも十分軽いが，JPEG からの方がサイズ対画質が圧倒的に良い。