描写拡縮ボタン実装。

調整と手定めを概ね終えた。

良い仕上がりになったが，遅い時間なのでまとめは明日に回すことにした。

（進捗時限記録中略）

強制録落ちについて，ほぼ原因が特定出来たため作業方針検討をして終了。

4月28日20歩で概ね見当は付いていたが，連続多量握接に繋がる下見機能出振るい後に多発するようになった状況から考えて，接渉譜類の排他制御不足でまず間違いないだろう。そもそも接渉譜類の内容は書き換えていないはず，というのが確信が持てなかった理由だったが，確認すると握接毎に同内容で接渉譜類を上書きしている。これは実装当時の手抜きだろう。

折角の下見機能が使いにくくなることも含めて深刻度が高い問題なので，最優先で修正作業に入ることにした。

パンくず部区装体調整，前次部区装体調整で終了。

前次部区装体では高さが固定されているため，ルビが含まれると下にはみだしていたが，昨日の装体調整後のパンくず記法でも似た問題があることに気付いた（区切り記号が上にずれる）。

前次部区に関しては Dex でルビ記法の有無を判定して調整するかと考えていたが，ここで，両方とも position: absolute と bottom で揃えればいいことに気付き，早速修正した。なんとなく気になって始めたパンくず部区装体調整に救われた。

ついでに，パンくず部区の中間区切り記号の色を dimgray から black に戻した（実装初期にも同じことをしていた：1月15日1歩）。表示環境によっては末尾の silver と見分けにくい。線の太さなどを変えてみてもやはりしっくり来ない。

手定め・出振るい済み。

概ね上手く行ったので，前次記法実装はここで一段落とする。

（進捗時限記録中略）

前次部区装体の調整が概ね終わった（前次部区装体・調整後）。

前次記法についてのまとめをしたかったが，もう遅い時間なのでまた明日に回す。

（進捗時限記録中略）

色見本記法と，タグ記法にも応用出来る広義の「色記法」について少し進展があったのでまとめて終了。

色記法に関しては，背景色と前景色をどう表記し分けるかが課題だったが，色見本記法でどうせ % を使うのであれば，同時指定は [fg]%[bg] として，それぞれ [fg]%，%[bg] と書けるようにするのが良いかもしれない。

さらに，[fg]% は [fg] と略してもいいことにし，CSS との整合性を考え ; も区切り文字として使えるようにすれば，%[bg];[fg] のようにも書ける。色見本を %[bg]% で書けるとすれば，%[bg];[fg]% の短縮形ともみなせる。

この考え方なら，十分な柔軟性と明示性を持たせられそうだ。以下のような記法も概ね整合的に解釈出来る。

%black%    <!-- 小さな色見本を表示 -->
%%`black`  <!-- 指定内容の前に色見本を表示 -->
`black`%%  <!-- 指定内容の後に色見本を表示 -->

%%`black;white`%% <!-- 大きな色見本を交度付きで表示 -->

%%black;white
白文字に黒背景
%%

<{white%black}>白文字に黒背景</>
<{white;%black}>白文字に黒背景</>
<{%black;white}>白文字に黒背景</>
<{black}>黒文字</>
<{black%}>黒文字</>
<{%black}>黒背景</>

ただ，まだ確信には至っていない。もう少し煮詰める必要がある。

色見本記法がどれだけ必要とされるかは分からないが，デライト装体調整に有用なことは間違いないので出来るだけ早くまとめたい。

（進捗時限記録中略）

昨日，寝る直前にまた脳爆発があり，今朝にかけて文字装飾記法とタグ記法周りの概念整理・仕様整理が急速に進んだ。

文字装飾記法は，「文字装飾を伴う慣用表現」のための記法と位置付けることにした。太字記法（##），斜体記法（//），下線記法（__），打ち消し線記法（~~，翌日のまとめで「打ち消し記法」から改称）の4記法を基本とし，それぞれ所定装体（スタイル）を伴う <b>，<i>，<u>，<s> HTML 要素に対応する。

@ を使った文字サイズ記法，% を使った色記法も検討していたが，タグ記法の概念が出来たことで中途半端なものになるため，これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つの検討方針

実装自体は容易な部類で，記法も概ね固まっていたにもかかわらず文字装飾記法の実装に踏み切れなかった理由として意味論的な問題があり，これが思いのほか難題だった。実装方針は3通り考えられる。

1. 完全に意味論的な記法にする
2. 完全に装飾的な記法にする
3. 意味論と装飾を重ね合わせた記法にする

記法の趣旨からしても，軽量標記（マークアップ）言語の特性を考えても，1つ目に無理があるのは明らかだ。対応する HTML の <b>，<i>，<u>，<s> は，私が何度解説を読んでもややこしく感じる代物だ。それを多くの人が正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系を捨てることになるが，代替案があるわけでもない。

かといって，2つ目ももったいない。要は <span> で装体指定だけにするということだが，例えば，太字にはしたいが <b> にはしたくない場合，打ち消し線は引きたいが <s> にはしたくない場合がどれだけあるのかと考えると，無難を通り越して臆病過ぎる。失う可接性（アクセシビリティ）や応用可能性と釣り合わない。

最終的に採用することになった3つ目も，全く考えなかったわけではないが，柔軟性に欠け，前の2つの悪い所が組み合わされる気もして，有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態を変えたのは，前日に概念としてまとまったばかりのタグ記法だった。

これまで，デラングにおける HTML は，どうしてもデラングで出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで，積極的に使うことを想定していなかった。実際，個人的にはほとんど使っておらず，放置している不具合も多い部分だった。

デラングのタグ記法として間接的に HTML を使うことで，略記法の導入も可能になり，HTML 側の仕様変更に対しても一定の緩衝帯を設けることが出来る。ここに来て初めて，文字装飾記法でも「書き分け」が考えられるようになった。文字装飾記法に対応しうるのが全て1文字要素だったことも幸いした。

昨日の寝る直前に，##太字的な表現## と <{font-weight:bold}>太字</> のように書き分けるよりも，##太字## と <b>太字的な表現</b> のように書き分ける方がマシであることに気付いて，1つ目の実装方針案は完全に潰せた。

これにより一時的に2つ目の実装方針案が再浮上したが，標準的に使う記法として標準的な用途に最適化不足なのはやはり否めなかった。

決着

最終的に，「文字装飾を伴う慣用表現」という用者が自然に理解出来る範囲での意味論的な位置付けを与え，逸脱する用途ならタグ記法で書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針案を洗練させた格好になる。

例えば，##太字## は「太字装体の <b>」に対応する。装体が邪魔なら <b>太字的な表現</b> と書けるし，意味が邪魔なら <{font-weight:bold}>太字</>（略記法は検討段階）のように書けるが，これらの場合が稀少なのは明らかで，記述量に上手く釣り合う。ワープロならともかく，軽量標記言語を手書きしようという人にとって難しい使い分けではないだろう。

そもそも，<b>，<i>，<u>，<s> は，古くからある視覚的要素が HTML5 で慣用的な用途を引き継いで意味論化されたものなので，「文字装飾を伴う慣用表現」と非常に相性が良い。相互変換にも全く問題ない。

何より，直感的に入力すれば構造的に出力されるというデラングの理想に適っている。

文字サイズ記法・色記法は廃案へ

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで，慣用表現を持たない文字サイズ記法・色記法は仲間外れになるが，タグ記法によって出る幕がなくなった感があるので，ここで廃案にすることとした。

第一に，タグ記法で略記法を整備した方が一貫性も応用可能性も高い。特定の値でプロパティを省略出来るようにし，<{white}>白い文字</> のように書ければ，%white%白い文字%% と書くのと記述量も大差ない。

もともとパラメーターを必要とする記法の異質感はあり，文字装飾記法の統一感を損うかという懸念はあったので丁度良かった。

波及的検討

波及的に，いくつかこまごまとした検討も進んだ。

組み合わせは「逆」ではなく「入れ子」へ

これまで，複数の文字装飾記法の組み合わせは #/太字と斜体/# のように，「記号を1つずつ逆さにした終了記号と挟む」といったややこしい説明を考えていたが，##//太字と斜体//## のような「入れ子」を #/太字と斜体/# と短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法の発展

今回の検討で，タグ記法が早くも実践的な役割を持つことになり，デラングにおける存在感が一気に増した。

タグ記法に HTML の仕様変更に対する緩衝的な役割を持たせること，要素名の省略で <span> にすることを考え始めた。

（進捗時限記録中略）

埋め込み記法（渡括記法）の応付子（オプション）などについての検討で終了。

概ね方針が固まってきた。

引数風の応付子

これまで埋め込み記法には，埋め込み方を細かく指定するような機能がなく，例えば画像埋め込みでも表示サイズや水平方向の寄せ方を指定出来なかった。この問題は当然当初から認識していたが，どうしてもごちゃごちゃしがちな部分なので，直感的で美しい記法を練るのに時間がかかった。差し当たり欲しいのは画像埋め込みで表示サイズや寄せ方を指定出来る機能だが，他の埋め込み対象でも使える汎用的な枠組みを整えておきたい。

そこで，[寄せ方指定スペース]+([応付])[埋め込み対象] の形式を採用することにした。例えば，添付譜類の PNG 画像を100x100で埋め込みたい場合，+(100x100)png と書けるようにする。

丸括弧内は，函数引数風にコンマ区切りで，埋め込み対象毎に使える応付子を設定する。引数名を指定出来るように a=x や a:x を受け取ってもいいが，柔軟性も必要なのであえて必須にはしない。スペースを含む文字列を扱いたい場合も考えられなくはないのでとりあえずコンマ区切りにしておくが，各引数の扱いは駒手欄の感覚に近い。

他の案として，+100x100 png や +100x100,png のように全てを引数的に扱うことも考えたが，あくまでも埋め込み対象を主とする応付の役割とまとまりが一番分かりやすいという点で丸括弧を採用する。また，埋め込み対象は URL など長い文字列になることも多いため，応付は + の直後に置く。あるいは，末尾に置く形と書き分けられるようにする。

水平方向の寄せ方

水平方向の寄せ方は，表組み記法で採用予定のスペースを使う方法を応用することにした。以下のように，+ 前のスペース無しは無指定，4つ未満は左寄せ，4つ以上で中央寄せ，6つ以上で右寄せとする予定。

+png            <!-- 無指定 -->
  +png          <!-- 左寄せ -->
    +png        <!-- 中央寄せ -->
      +png      <!-- 右寄せ -->

直感性でいえば矢印のような記号を導入することも考えられる。となるとまず < と > を使うことになるが，すでに多用しているため無闇に役割を広げると記号の意味が稀薄化しかねない。そうでなければ left，center，right のようなキーワードを導入するくらいしかないだろう。いずれにせよ，見た目的にもあまり美しくない。

当初，以下のようにスペースの数も表組み記法に合わせようとした（2つで中央寄せ，3つで右寄せ）が，いくつか問題がある。

+png         <!-- 無指定 -->
 +png        <!-- 左寄せ -->
  +png       <!-- 中央寄せ -->
   +png      <!-- 右寄せ -->

まず，表組みにおけるセル内での編集に比べそこまで編集効率は問題にならないためここまで短くする必要もなく，比較的長くなる後続文字列に対して目立ちにく過ぎる。単純に，スペース2つで中央寄せ，3つで右寄せの表現には見えない。

さらに致命的な問題は，いくつかの他記法との整合性だ。導入予定の字下げ記法では，行頭に全角スペースを使う。あまり好きな記法ではないが，Markdown の4つの半角スペースを使う交度記法も互換性のため導入する可能性がある。これらの記法を混ぜて書いた場合，視覚的な整合性が取れない。

そこで，行頭に使う寄せ方指定のスペースは表組み記法の倍とすることにした。交度記法にも使われる4つの半角スペースが右寄せに一致するよりは中央寄せに一致した方が違和感がずっと小さい。

行内埋め込み記法

おまけに，行内埋め込み記法についても少し考えた。

これまで埋め込み記法は部区として扱うことを主に考えてきたが，やはり行内埋め込みも必要だろう。まだ草案の段階だが，例えば以下のようにして画像に回り込む段落が作れると便利だ。

++png++ 左上の画像に回り込む段落。