{デラング}{進捗記録}{Markdown}{希哲16年2月15日24歩}{希哲16年2月9日の開発}{使うこと}{維持すべき}{既存輪郭}{setext 式見出し}{希哲16年2月9日17歩}...=}(61)

{希哲16年2月9日19歩 K#F85E/A-E74C-5731}

進捗時限記録中略

Markdownsetext 式見出しをどうデラング見出し記法取り入れるかの検討終了

区切り線混乱しないようにというのが課題だったが,現在デラング実装では,段落直後に続く区切り線記法機能していないことに気付いた明確に意図していたわけではないはずだが,既存輪郭についての心配は要らなくなった。好都合偶然だ。

とはいえ,省割として空行まずに使える利便性捨て難いので,5日3歩方針維持すべきか。

=-3つ以上というのは,2つ体裁考えず省力のために使うこと多いということと,3つ以上区切り線こうとする人なら Markdownsetext 式見出しにも気を付けるだろうという狙いがある。

これと,最新の見出し装体前歩区切り線記法についての検討総合すると,以下のように破線点線加えた拡張可能性見えてきた

第1階層
=======

第2階層
-------

第3階層
- - - -

第4階層
. . . . 
=}
{出振るい}{進捗記録}{分かる}{希哲16年2月15日24歩}{希哲16年2月9日の開発}{確信が持てなかった}{領当て}{ずらせない}{他要素}{空間的に}...=}(122)

{希哲16年2月9日15歩 K#F85E/A-E74C-ABAC}

進捗時限記録中略前後

デライト装体調整昨日7歩に関する整理終了

見出し段落よりも横幅両端0.5remずつ広げ区切り線<hr>段落よりも0.5remずつ狭めることにした見出しと区切り線装体・幅調整後

当初見出し下線区切り線見分けやすくするために,区切り線両端1emずつ狭める形にしかけたが,試しに出振るいしてみたこの形が想像以上しっくり来たので,基本方針として採用してしまうことにした。

文書構造視覚的にぐっと把握しやすくなった


段落に対して僅かに字上げするような見出し装体昔から気に入っていて,現状でも「はじめに」などのデライト文書<h2>1em<h3>0.5em字上げされている長らく更新していないため描写内見出しとは全体的に乖離している)月庭でどうしていたか忘れたが,特に理由がなければ似たような装体採用していたはずだ。

やはり,見出し直感的に把握しやすいのが大きな利点だが,描写内見出し採用出来なかった理由として,無駄な余白生じやすいという領当て上の問題大きかった。特に,諸場対応から強く意識するようになった幅狭領当てでは小さくない問題だった。

今回実験意外だったのは,全ての描写内見出し0.5remずらすだけでも十分な視覚効果得られたことだった。これなら,他の装体そのままに,見出し装体マージン削るだけで一応実現出来る。

そのうち領当て上の問題起きたとしても,幅狭領当てでは0.25emにするとか区切り線だけ調整するとか,調整やりよういくらでもあるので,基本方針としては問題ないだろう。


これだけ見出し分かりやすくなれば,区切り線短くする必要はないかとも考えたが,これはこれであった方がメリハリが付いて良い従来の他要素同じ長さだと,やはり直感的に区切りの大きさ把握しにくい

新装体なら,見出し見比べるまでもなく,見出し未満小さな区切りであることが分かる

空間的に見出しずらせない場合の備えにもなる。


昨日眠気が強い時間帯思い付いたのでこの新装体良さ確信が持てなかったが,認知機能低下している時に分かりやすい思ったのだから,分かりやすさに関しても間違いないだろう。

{進捗記録}{Markdown}{部区}{希哲16年1月18日の開発}{希哲16年1月18日12歩}{行内埋め込み}{行内埋め込み記法}{書き分けられる}{視覚的な}{導入予定}...=}(161)

{希哲16年1月18日8歩 K#F85E/A-E74C-91F1}

進捗時限記録中略

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

概ね方針が固まってきた

引数風の応付子

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

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

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

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

水平方向寄せ方

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

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

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

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

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

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

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

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

行内埋め込み記法

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

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

++png++ 左上の画像に回り込む段落。
=}
{開発}{開発記録}{選り手}{編集モードと閲覧モードが切り替わる欠点}{規模的に}{欲しくなってきた}{書いてきた}{かなりの長文}{反して}{問題らしさ}...=}(65)

{希哲16年1月4日の開発 K#F85E/A-E74C-441F}

雑多な考え事


SLFS起動管理系整えたことで,そろそろ画面管理系欲しくなってきた規模的に早期独自実装視野に入る


知機における自我認証PAM採用検討画面管理系について考えていたところで気付いた


現状輪郭選り手問題として,文章においても部分編集がしにくいという問題があり,用者からも指摘されている

予てから問題だとは思いつつ,その感覚的な問題らしさ反してかなりの長文書いてきたがあまり困ったことがないのが不思議だった。よく考えてみると,長文であればあるほど誤字脱字気になる箇所増えるし,まず修正箇所一点に収まることがないので,結局,最初からざっと点検しつつあちこち修正する,という作業をしていることが多い。こういう修正仕方だと,最初から全体選り手いてしまった方が無駄な表示切り替えなどがなく,かえって効率的とも言える。

とはいえ,こればかりは書き手によるところが大きく,手段多いに越したことはないので,部品単位編集一種として段落毎の編集可能にするなどで対応することになるだろう。

{進捗記録}{廃止}{Markdown}{デライト}{希哲15年7月6日の開発}{希哲15年7月6日の進捗時限}{希哲15年7月6日の進捗}{希哲15年7月6日}{表示環境}{読み手の好み}...=}(72)

{希哲15年7月6日8歩 K#F85E/A-E74C-87B0}

デラング整備段落記法段落装体改行仕様再検討

いったん終了。

これまで,段落間の余白0.5emほど開けて1em分の字下げtext-indent設定していたが,自動字下げ廃止し,代わりに字下げ記法導入することにした。

字下げ記法では,行頭に所定のスペース(例えば日本語なら全角スペース1つ)を置くことで text-indent設定出来るようにする。Markdown 等で採用されている4つの半角スペースでの交度記法などの導入をどうするかはまだ決まっていないため,まずは衝突しないように限定的な導入に留める。

また,改行については,これまで通り1行の空行段落分けに使い,半行分の余白を開ける。2行の空行で1行分の余白,それ以降は1行分ずつ余白を追加していくように装体厳密化する。

字下げ記法により改行無しで段落を表現出来るようにすることも検討する。この場合,段落間余白無しで字下げのみを使った段落表現も出来るようにする。

これにより,多様段落装体対応出来る。


段落の字下げは,段落間の余白とともに文書の性質書き手読み手の好みによって制御出来るようにしておいた方がデライト活用範囲広がるだろう。

従来の段落装体は恐らくデルン最初期調整したもので,長い文章を書く時は便利に感じていたが,例えば,どんな表示環境でも改行されないような一言程度でも字下げが入るため,内容によっては不自然行頭が揃っていないように見える,といった問題があった。

段落間の余白を広げ過ぎると縦の空間消費し過ぎかえって視認性問題があるため,代わりに字下げ導入したような微かな記憶がある。

ただ,日本語版 Wikipedia でも英語版 Wikipedia でも0.5emの段落間余白で字下げ無しという装体なので,特別読みにくいということもない。

最初は字下げ無しを指定出来るような記法導入することを考えたが,そんなややこしいことをするくらいならこちらの方がすっきりするだろう。

{段落}

{}