（進捗時限記録中略）

設定ページ整備，エクスポート機能実装。

仕様検討で終了。

サイクリング中に良い思い付きがいくつかあり，エクスポート機能も想定以上に洗練されたものになりそうだ。

• 添付譜類の代わりに「添付譜類代替 HTML」を含めることにした。
  • 添付譜類名に .html を加えた譜類名にする（例：XX.webp.html）。
  • エクスポート譜類の肥大化は利用者にとっても好ましくない場合が少なからずあるため添付譜類の除外は決めていたが，目印くらいは欲しかった。
  • 最初，.url を付けたインターネット ショートカットにすることを考えたが，転送するにせよ説明するにせよ HTML の方がはるかに柔軟性・可搬性が高い。
  • 将来的に，容量上限などを決めて添付譜類を含められるようにする可能性もあるが，無制限は難しいので選択肢として有用であり続けるだろう。
• 期間終了日に加え，期間開始日も指定出来るようにすることにした。
  • 期間開始日は単純化のため省くつもりだったが，管理上の有用性が高い。
  • 用合い上の問題は前縁で調整すればいいとして，後縁では実装しておく。
• エクスポート譜類の譜類名は KNo.[自我番号].[作成日].[期間開始日]-[期間終了日].zip とすることにした。
  • 日付は8桁数字のみ（例：20230101）。
  • 各日付は適宜省略する。
  • .[輪数]oln を日付のあとに加えることを考えたが，情報として中途半端な上に冗長過ぎるためやめた。
• 輪数などの詳細情報を含めた README.txt を加えることにした。
  • 譜類形式などについての説明も出来る。
  • この手の譜類はあとで扱い方が分からなくなることが多いので有用だろう。

埋め込み記法で Speaker Deck 対応。

譜類添付機能における「添付代置子」の考案。

上信に時間がかかる場合や，貼り付けでの添付に対応した場合のために，埋め込み記法の挿入位置に編注記法を使った代置子を挿入しておくことを思い付いた。

<!-- +読み込み中... --> のような形式を想定。ピリオドの数で固有性を持たせることも出来る。

エクスポート機能の仕様検討。

輪括を含まないように簡素化することは決めていたが，添付譜類も含まないようにする方針を固めた。実際に譜類添付機能が出来てみると，全ての添付譜類をエクスポートするのは現実的ではないことに気付いた。重要な譜類なら各自抜控を取っていることを前提として問題ないだろう。

エクスポート機能実装は次の主要当努だったが，先に譜類添付機能実装を済ませたのは正解だった。

輪郭小窓実装の周辺作業。写し取りアイコンを完成させ，無番輪符改良に入った。

無番輪符改良の方針は6月17日6歩で決めていたが，やはり輪郭小窓実装の前にやっておきたい。比較的容易に実装出来，今後の設計方針と用者体験に与える影響は大きい。

珍しく朝から胃腸の調子（だけ）が壊滅的だった（体調記録）。昨日の時点で半休にすることは決めていたが，滅多にないことなので急遽全休に切り替えた。ギリギリのところで休養不足を解消したとも言える。自分をしっかり休ませる丁度良い動機が出来たので，早く寝支度をした。最近の課題だった入眠時間の遅さがこれで解消すれば怪我の功名だ。

映画などを観ながらのんびりデライト宣伝と軽い開発作業をしたが，思いのほか収穫も多かった。

（進捗時限記録中略）

不意に閃いた「階層区切り線」についての方針をまとめて終了。

従来の見出し未満の区切り線記法に，見出し階層を越えられる「階層区切り線」を加える。以下のように，唯一通常の区切り線と区別出来る見出し記号 #（全角 ＃ も可）を使う。

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落（# の数でも調整出来る）。

デライト装体調整，URL 装体調整で終了。

直書き 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歩で決めていたことだが，少し面倒臭い部分がありいまだに実現していない。