微調整。

• Chrome で輪郭小窓の中景輪符に不要なスクロールバーが表示されてしまっていた問題を修正。
• 表組み部区内でスクロール出来るようにした。
  • 表が横長になると描写部全体でスクロールするようになっていた。

無停止出振るい済み。

描写選り手を開いた時の高さに800pxの上限を加え，描写部の高さが800pxを越える場合に描写選り手先頭までスクロールするようにして終了。出振るい・手定め済み。

既存輪郭の描写選り手は高さを描写部に合わせて開くようになっているが，下限は設定していたものの上限がなく，長過ぎる描写部の場合に無駄に高い描写選り手が開いてしまっていた。描写部の高さと描写選り手の高さに差があり過ぎると見失うことがあるため，上限を越える場合に描写選り手先頭までスクロールするようにした。

これでだいぶ描写部の長い輪郭が扱いやすくなった。

（進捗時限記録中略）

数式記法，KaTeX の初回ページ読み込み時の描画処理を吹き描き単位で行うように修正して終了。

これまで初回ページ読み込み時は document.body に renderMathInElement() をかけていたため，\gdef で定義したマクロがページ全体で共有されてしまうという問題があった。かなり以前から認識していたものの，さほど使用されていなかったので後回しにしてきた。実際問題にならなかったが，描写渡括との組み合わせを推奨していきたいこともありここで対応することにした。

本来は前後景輪符毎・知名部毎・描写部毎くらいに厳密に各要素を処理すべきだが，効率の問題もあるので現時点では必要十分な対策に留めておく。

輪郭小窓を閉じてから同じ輪郭で開き直した時にも輪郭小窓描写部のスクロール位置を初期化するようにして終了。

これまでスクロール位置がそのままになっていたが，これはこれで使い道があるかもしれないと放っておいた。結局，利便性においてはどちらが良いとも言えないので，直感的な方を取ることにした。さっきスクロールしたことを覚えていれば作業に役立つこともありそうだが，忘れていて一瞬混乱することが多かった。

出振るい済み。

輪郭削除機能実装を一段落させ新生全知検索整備に戻り，全文検索機能実装に入った。

輪郭削除機能

用合いは概ね予定通り，知名欄・描写欄を空にすると表示される削除ボタンで実行する（輪郭削除ボタンの様子）。

削除済み輪郭は，全体を半透明化，中景輪符の知名部に薄く「削除済み」と表示，知番に打ち消し線を付け，描写部には「この輪郭は削除されました。」と表示する。スクリプトを複雑化させないように，前後景輪符，×輪結，全知検索窓の自我アイコン（吊るし輪郭）以外はpointer-events と filter を使って CSS のみで無効化するようにした（削除済み輪郭の様子，削除済み吊るし輪郭の様子）。

後縁では，知名・描写が同時に空文字列で送信されると削除立求と認識する。出場（dg_udrw()）では b_del を TRUE にし，n_oln，n_fg，n_bg を減算し，輪括を一括削除する。復元の問題もあるため出与え変更は最小限に留めた。

KNEST 隠しは最低限の同期をさせつつ，効率的な同期が不可能な他輪郭の前後景輪数はある程度の不一致を許容することにした。未公開輪郭のために使っていた「未公開輪郭が含まれています。」を「表示出来ない輪郭が含まれています。」に変更してある（28日3歩）。

6月27日の開発で dg_udrw() での最低限の輪郭削除は出来るようになっていたため，用合いの調整程度で終わるだろうと思っていたが，忘れていた輪括や KNEST 隠し周りの調整に時間がかかった。性質上，慎重を要する部分でもあった。とはいえ，所要日数3日で，現段階でなければここまで効率的に実装出来なかっただろうという実感があり，導入時期として最適解に近いことが分かったので，それはそれで嬉しい発見だった。

出振るいは円滑に成功した。

全文検索機能

全文検索機能実装はとんとん拍子に進み，出振るいまでもう一息というところまで来た。

不具合修正で終了。

左下吹き描きの高さが足りない時に鼻がずれる問題が以前からあったが，応急処置として，空の描写部の display: none を左下吹き描きでは無効化することで対応した。近いうちに鼻全体を見直す。

描写拡縮ボタン調整。

再描出後，描写部が低くても縮小ボタンが表示されてしまっていた問題を修正して終了。

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

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

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

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

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

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

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

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

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

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

長い間課題だった描写拡縮ボタン，輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発で最大化アイコンが出来たことをきっかけに，描写拡縮ボタンの実装イメージが固まり，実装・手定めまで概ね完了した。想像以上に早く上手くまとまった。下見機能との相性も良い。ただし輪郭選り手抜控機能整備が途中であるため未出振るい。

• 描写拡大ボタンの様子・初期状態
• 描写拡大ボタンの様子・スクロール途中
• 描写拡大ボタンの様子・スクロール完了
• 描写拡大ボタンの様子・暗い背景色
• 描写縮小ボタンの様子

描写拡縮は機能的には単純だが，用合い，特に領当てが難しかった。最近，描写部下境界に重ねる形での実装を考えていたが，描写部を飛び出すと他の要素に干渉してしまう。かといって余白を無駄に広げたくない。これは，下部の陰影に重ねつつ，初期化時点でスクロール可能な場合は下余白を追加することで解決した。文字や暗い背景色と重なっても視認出来るように，半透明の白背景を付けた。

拡大ボタンはスクロール可能であることの目印としても効果的なので，これを活かして，スクロール完了時には透明度を上げ，それと分かるようにした。

これで，外観・操作感ともにデライトに調和した描写拡縮ボタンが出来た。描写部の高さ固定は一覧性を確保するために必要なものだったが，用合い上の弊害も小さくなかった。陰影付きスクロール，最大化アイコン，そして描写拡縮ボタンによって，ようやくこの問題が解決した。

描写欄の高さの問題をきっかけに自動リサイズ機能と字数計の実装が出来た。ほか装体調整など。

出振るい済み。

自動リサイズ機能

旧輪郭選り手では，描写欄の出放りの高さを新規描出フォームで10em，再描出フォームで15emとしていたが，新輪郭選り手ではたまたま15emで統一されていた（画面撮り）。10emでは長文が書きにくいのでこれはこれでいいかと思ったが，やはり新規描出フォームは一言だけや知名だけの描出に使うことも多いためこの高さでは邪魔臭い。

ここで，予てからぼんやり検討していた自動リサイズ機能の導入を考えた。一応 resize: vertical は設定してあるが，万能ではない。10emから20em程度までの範囲で，改行毎に自動リサイズさせる。導入予定の字数計では字数情報が必要になるため，一緒に行数も保持させることにした。

実際に試してみると，1em刻みでも2em刻みでも違和感があったため，10emから19emまで1.5em刻みでリサイズするようにした（画面撮り：初期状態，最大自動リサイズ）。19emだと個人機でも低過ぎず高過ぎず，スマートフォンの縦向きで柔品キーボードを表示させてもちょうど収まる程度の高さになる。折り返しの多い1行もありうるため，厳密にするなら字数も考えるべきだが，とりあえずはこれで様子を見ることにした。

再描出フォームに関しては，さほど目立つものでもなく，描写部の高さに合わせて描写欄が開くようになっている現仕様が悪くないので，現状維持で様子見しておく。

字数計

字数・行数の保持が出来たことで字数計も難無く実装出来た。描出ボタンか時印の左側に邪魔にならないように表示させてみた（字数計の様子）。

下見の字数と分けようかと思っていたが，下見を開いている時は下見の字数に置換すれば十分であることに気付いた。一応，見分けが付くように頭に「→」を付けるようにした。

これも，厳密に考えると特殊な文字符号などを考慮する必要があるが，キリがないのでとりあえず .length による概算でよしとしておく。

字数計は，地味ながら意外に需要があることを市場調査を通して知った。自分でもたまに欲しくなることがあった。