(65)越化周りの客体表現化を考えるついでに文字参照の越化について再検討して終了。
HTML 越化仕様を決めた昨年5月20日12歩以来，越化目的で使う可能性がある文字参照のみを許容していたが，これは修正し，いったん全ての文字参照を許容することにした。
4日21歩でも再検討したが，越化記法同様，デラングにおける特殊文字を白表方式で管理するのは無理がある。損われる保守性に対して利点が乏しい。
当初は制危というより迷惑行為対策など運営上の都合で必要になるのではないかと思っていたが，Wikipedia はじめ大規模サイトで開放されている例も珍しくなく，少なくともデライトの言語仕様にするほど必要な制限とは言えない。文字参照で制危上致命的な問題があればそれは舞覧の問題だろう。迷惑行為対策としてもあまり本質的ではない。
何か問題があれば制限する，で十分なはずなので，実装都合で制限してもいいことにする。
文字参照には，表示や入力に難がある文字が記述しやすいという有用性も一応ある。
(94)直書き URL（<a.URI>）を font-size: 0.9em の等幅フォントにした（URL 装体調整前後）。字間無しは昨年6月30日の開発からだが維持する。
直書き URL のある描写が読みにくい問題はずっと以前から感じていて，何度か調整しているが，一昨日の開発中にふと，「文字サイズを小さくしていない」ことに気付いた。
昨年6月30日の開発で字間無しにしているが，等幅フォントにして変に目立ち過ぎるという理由で戻したりもしている。この時になぜ文字サイズを小さくするという発想がなかったのか不思議だ。他にも問題が山積していて思考時間が割けず，灯台の下まで目が行かなかったか。
今回は <kbd> や <code> の装体について考えていたところだったので，その関連で気付けたのだろう。
文字サイズはやはり0.9emが丁度良い。0.8emにすると長い URL はともかく短い URL を提示する時に今度は目立たな過ぎる。
これにより，十分凝縮されメリハリが付いたので，予てから検討していた長い URL の省略については保留とすることにした。
長い URL の省略は，簡単なようでいざ導入しようとすると意外と難しい問題がある。
まず，デライト上の文書の傾向からいっても，「ちょっと長い」程度の URL は省略したくない。URL の全体が情報として有用な場合がしばしばある。このあたりはマイクロブログなどとは事情が異なる。
では，どこで省略すべきかという問題になるが，長い URL を許容すればするほど比較的短い URL の読みにくさが解消されないというジレンマがあった。これは装体の調整で解決した。
そもそも輪結記法（[ ... ]）もあるので，現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法を導入してもいい。
ただ，パーセント符号化の復号はしたい。これは昨年3月22日2歩で決めていたことだが，少し面倒臭い部分がありいまだに実現していない。
(31)(102)分割格納方式への移行作業前に，知番譜類における拡張子の扱いについて検討して終了。
これまでの自我台録（/kn/K#F85E/）には無接尾子の譜台がいくつかあるが，譜類添付機能に合わせ，これを全て拡張子付きに練名することを考えていた。
そもそも知番譜類は，知番を譜類名にしてデルン上で管理する譜類管理手法として始まり，デライト開発が本格化してからこの経験を元に拡張子毎の添付譜類という概念が固まった。
当初は一貫性の観点からむしろ無拡張子を基本に考えていたため，初期の知番譜類には無拡張子の実体に拡張子付きの疎輪結を置いているものがある。ただこれは煩雑な上に，Windows 仮想機で上手く扱えない問題があったため次第にやらなくなった。以後，普通に拡張子を付けることが多くなった。
いっそのこと，全て拡張子付きにして譜類添付機能との整合を取るかと考えたわけだが，全ての譜類に適当な拡張子があるわけではなく，必ず指定するとなると煩雑化の恐れがある。適当な拡張子がなければ .unk のような特殊な拡張子を使う，台録なら .d 接尾子を使うなど仕様も複雑化する。
仮に無拡張子の知番譜台を空けたところで，その使い道があまり無いという問題もある。本来輪郭情報を置くのが適当なところだが，エクスポート機能等では閲覧・編集の都合から .oln を使うことを決めている。分割格納方式を採用したことで利便性はいずれにせよ知機駒手で補うしかなくなっているので，実体の場筋に利便性を持たせる必要もなくなった。
譜類添付機能やエクスポート機能はあくまでも知番譜台の応用として，無理に統合せず，一定の相互運用性を確保しておくに留めるのが最善と結論付けた。
ただ，拡張子用の疎輪結だけは問題なので普通の拡張子付きに練名しておくことにした。
(137)昨日，KNEST 隠し実装の再開を決めたのが寝る頃で，消化不良だったため，今月の中間まとめも兼ねて頭の整理をしておくことにした。再開によってデライト収益目標達成の展望が急に明るくなったような気がしたが，それが何故なのか，理解出来ていなかった。
そもそも，今月に入ってから，新生デライト開発はまたもや不思議な軌道を描いていた。機能整備を進めようという意識とは裏腹に，実際には高速化や開発環境整備（知機駒手整備，手定め環境整備，デバッグ環境整備）に多くの時間を割いた。また脱線しつつあるなと感じてはいたが，収穫は大きかったので成り行き任せにしていた。これが KNEST 隠し実装の再開に繋がったのは，単なる偶然ではなさそうだ。
いま思えば，8月頃からデライト収益目標達成に向けた具体的な道筋がこれまでにない鮮明さで見えてきて，具体的な数字も掴めてくるにつれ，一つの不安が浮上していた。それは，デライトにおける性能面の課題だった。現実装では，収益目標達成に必要な握接量を捌けないのは明らかだった。
ただ，これまでの自分なら，そんなことは気にせず，問題が起きたらその時に乗り越えればいい，という感覚で突き進んでいただろうし，意識の上ではまだそのつもりだった。無意識下でそれに反するような行動をしていたのは，日に日に増していくデライトの成功に対する現実感のせいでもあっただろう。空想的な見通しの甘さを許容出来なくなっていた。
今のデライトは，デライト高速化の着実な進展によって性能面でも健闘しているが，それは低負荷状態の0.1秒単位でのページ表示速度を上げていくようなもので，握接集中対策への突破口は見えていなかった。
その明らかな理由が KNEST 隠し実装の停滞であるということと，いまその再開に最良の時期が訪れていることに気付いた。この時，一気に展望が明るくなったように感じた。これまでの不可解な軌跡も，ここに導かれていたのだと思えた。
現在，高速化・機能整備・文書整備を同時進行させることにしているが，KNEST 隠し実装を中断した5月から急速に発展し展望が開けていた機能整備・文書整備に対し，切り札を失ったままでいたのが高速化だった。ここでそれが復活したわけだ。
KNEST 隠し実装を中断したのは，実装方針への迷いからだった。隠しは初期設計を間違えると足枷になりやすく，早まった最適化になりかねない。しかし，7月から8月にかけて新生デライト像が固まったことで実装の見通しは劇的に改善している。これから機能整備・文書整備を進めて集客を本格化させようというところで，性能問題での機会損失は極力避けたい。確かに，再開するとしたらこれ以上ない時期だ。
10月中のデライト収益目標達成に向けて組計調整することを決めたのは7日だったが，まだ月内達成の可能性も見ていたため，ここまではあえて態勢を変えていなかった。KNEST 隠し実装の再開という大義名分も出来たところで，本格的に頭を切り替えることにした。
今月後半は雑務処理をしっかりこなしたいので外出も多くなる見通しだが，とりあえず，中旬一杯は KNEST 隠し実装に開発時間を充てて様子を見る。
(15)(19)途中で終了。
HTML の制約で，間を飛ばして見出し階層を深くすることは出来ないため，最初の見出し記号の個数は無視せざるをえない。これを利用して，Markdown 風のハッシュによる見出しは ## から始めることで許容できる可能性に気付いた。
kn sync}{デライト}{用者}{進捗記録}{上信}{デライト高速化}{希哲15年3月11日の開発}{保存方式}{譜類添付機能}{希哲15年3月11日の進捗時限}...(40)デライトではこれまで意図的に避けてきた譜類添付機能について検討。
1MB未満程度の比較的小さな譜類であれば許容してもいいかもしれない。
自我アイコン設定機能実装を通して libxtd はある程度整えてあり，拡張子を利用した保存方式は個人的にも使い慣れ，捌き手の対応も出来ている。
後は，kn sync で実現している上信をフォームで出来るようにすれば良いだけで，実装自体はすぐにでも出来る。
残る問題は，用合いと運用だ。用合いはどうとでもなるとして，特に運用上の問題を解消しておきたい。
そもそも現状，描出自体はいくらでも出来るので，用者毎に制限をかける必要は特にない。
描出公開原則があることと無料であること，デライト高速化が視野に入っていることも大きい。倉庫のような使い方はされにくいだろうし，契約ではないので，手に負えなくなればその時点で無効化するなり出来る。
出与え URI のようなものを使われるくらいなら，上信してもらった方が効率的でもある。
それによって良い献典になるのであれば積極的に使ってもらった方がいいくらいかもしれない。
