{進捗記録}{希哲16年2月18日の開発}{あれ}{文章の流れ}{左右矢印}{下矢印}{上矢印}{使うべきではない}{右矢印}{使われない}...=}(171)

{希哲16年2月18日13歩 K#F85E/A-E74C-E223}

進捗時限記録中略

前後記法」として検討していた記法を「前次記法」に改め仕様再検討して終了

<- 前 | 次 ->

<- 前
次 ->

<- 前のみ

次のみ ->

以上のように,<- 前 | 次 ->基本形とし,改行区切り<- 前次 -> のみでの記述可能にすることにした。


デルンにあった類似機能から,「時間(時印)的な前後関係」を表現する記法として「前後記法」と呼んでいたが,文書では新旧にかかわらず読ませたい順序指定出来る方が便利なので,より汎用的な前次記法」と位置付け直した

新旧表すのに「」や「」というのはよく考えるおかしいという意見もあり,私も何か良い代替表現はないかと考えていたが,慣用表現として定着しているのでこれは仕方ない前ページ次ページというように,左開きページめくっていく感覚なのだろう左開き右開き書字方向との相性問題なので,ウェブになることが多いのは一応合理的ではある)


前回の検討では,以下のように書いていた

前 <|> 後
前 <|
|> 後

これは他記法区別しやすく簡潔ではあるが,見本はともかく少し長い文字列が入ると記号埋もれがち直感的とも言い難い視認性考えると,行頭行末分かりやすい記号があってほしい。

また,<|>タグ記法使う予定</>紛らわしい|始まる長い文字列があると,初心者には表組み記法誤認される恐れもある。


他記法との区別しやすさ簡潔性直感性などを総合的に考慮した結果最も素直な記法であろう <- 前 | 次 ->落ち着きつつある

雑多な考慮点列挙しておく。

=}
{進捗記録}{英語}{希哲16年1月24日8歩}{ちなみにAsciiDocでは重山括弧で参考文献を参照できる}{希哲15年6月23日の開発}{情報の出所}{cite 要素}{希哲15年6月23日の進捗時限}{希哲15年6月23日の進捗}{希哲15年6月23日}...=}(30)

{希哲15年6月23日2歩 K#F85E/A-E74C-213B}

また良い思いつきが出来,急遽題名記法仕様を固めて終了。

引用符内先頭に > を置く行内引用記法からの連想で,任意の引用符内先頭に < を使うことにした。例えば,以下のように書き分けることが出来る。

「>我輩は猫である」から『<我輩は猫である』は始まる。

シェル論組プログラミング言語では ><入出力の流れを表現することにも使われているように,情報の出所ソース)であることが上手く表現出来ている。

ただし,書籍題名などを単に伊体にするだけの英語のような例があるため,以下のような代替表記も必要だろう。これは行内引用記法が出来る前に考えていたものだが,ギュメとの混同を避けるため3つ重ねても良いことにするか。そこまで考えるならいっそのこと1つを許容してもいいかもしれない,と思ったが,これは様々な記号の用法を考えると避けるべきか(HTML 要素名の表記など)

>> 引用文 <<
<< 題名 >>
>>> 引用文 <<<
<<< 題名 >>>

cite 要素の対応はそれほど必要でもないかと思っていたが,こうなるとこちらを「出典記法」とするべきかもしれない。このあたりは後で整理する。

{デラング}{進捗記録}{希哲15年6月22日の開発}{自動表示}{好きになれない}{行内引用記法}{q 要素}{quotes}{行内引用}{希哲15年6月22日の進捗時限}...=}(45)

{希哲15年6月22日16歩 K#F85E/A-E74C-E04E}

行内引用記法についてのまとめを終え終了。

行内引用は以下のように,任意の引用符内先頭に > (半角・全角)を置く形式で実装することにした。引用符は q 要素quotes を使って制御する。

"> 引用文"
「>引用文」

行内引用については自然かつ混同しにくい記法をずっと探していたが,なかなかこれといったものが見つからなかった。最近では既存の引用記法応用して >><< を使うかなどと考えていたが,まだすっきりしないものがあった。

そもそも引用符を勝手に追加する q 要素自体あまり好きになれなかった。稲妻形引用部区考案したのも,特定の引用符自動表示すべきではないと感じていたからだ。

やはり,どの引用符を使うかは書き手が指定出来るようにしたい,と考えた時,これに範囲指定を兼ねさせれば > 一つ置くだけで十分であるということに気付いた

最小限記号直感的理解しやすく,切り貼りもしやすく,意図も明らかだ。しいて欠点を挙げるなら,フランス語ギュメなど山形の引用符との相性が悪そうなことくらいだが,それも致命的な問題ではない。

気軽に使いやすいように,装飾最小限にする。

先日の出典記法に続き,これでデラング引用記法出揃った感がある。

=}
{開発}{デラング}{開発記録}{`letter-spacing`}{Android}{iOS}{倍角ダッシュ}{倍角ダッシュ問題}{希哲15年6月19日の日記}{複数段落引用記法}...=}(72)

{希哲15年6月19日の開発 K#F85E/A-E74C-A3FD}

デラング整備

とりあえず細かい記法実装から済ませてしまうことにし,かねてから考えていたダッシュ記法出典記法実装,概ね満足出来るものになった。当初はそれほど期待していなかったが,想像以上表現の幅が広がりそうだ(公式解説)。

ダッシュ記法

ダッシュ記法は,特に扱いにくい倍角ダッシュが簡単に扱えるようになったのが想像以上に大きい。

この問題は,昔,『道草録』記事名に使おうとしてから認識していた(「Org-Mode の機能、組み込み LaTeX — その1」)が,いまだにこれといった解決策が無く,日本語電子文書課題になっているので,それなりの宣伝効果もありそうだ。

最初,エムダッシュU+2014を2つ繋げて,CSS で何とか調整しようと考えたが,フォントによって太さ長さ統一感がなく,負の letter-spacing で間が開かないようにすると短過ぎて倍角ダッシュに見えなかったりした。しかも,環境によっては重なった部分が濃く見えて結局綺麗な倍角ダッシュにならないという問題に気付き,これは断念した。

最終的に,罫線素片U+2500を使うことにした。罫線を作るための文字である性質上,letter-spacing が 0 であれば隙間が出来ないことはほぼ保証されている。SLFSAndroidWindowsmacOSiOS確認した。

罫線素片による倍角ダッシュの表現はよく見られるものだが,同時によく指摘される問題点として,これがダッシュであるという意図表現出来ないというものがある。例えば,縦書き表示した時に横棒のままになってしまうことがある。

これを踏まえて最初にエムダッシュを利用しようとしたのだが,よく考えると,デラングであれば,ダッシュ記法という仕様によって意図保存しつつ,表示上最適化に徹することが出来る。

出典記法

ダッシュ記法と引用記法の組み合わせとも言える出典記法も実装出来た。

複数段落引用記法の終了記号との兼ね合いをどうするかと思っていたが,これは単純に,出典記法を終了記号としても扱うことで上手く解決した。

ここも意外に他の軽標記言語では面倒だったりするので,デラングの小さな売りになりそうだ。

その他

成果想像以上だったが,これらを実装するのに想像以上に多くの障害があった。

特に,正規表現周りで躓くことが多く,正規表現の扱い方について見直す良い機会にもなった。

{手定め}{出典記法}=}(2)
{開発}{開発記録}{輪郭整備}{折り畳み記法}{希哲16年1月20日8歩}{交度}{希哲15年6月18日の日記}{うっすら}{見返す}{出典記法}...=}(52)

{希哲15年6月18日の開発 K#F85E/A-E74C-080F}

デラング整備埋め込み部区実装,その他記法仕様検討など。

気になっていた細かい不具合修正を済ませ,描写埋め込み拡張子のみでの添付譜類ファイル参照実装に入れた。


ひょんなことから,急速定表テーブル記法実装方針が出来た。

最近の輪郭整備月庭の公開描出見返すことが多くなり,何となく「C++ウェブ開発向けライブラリ」を見ていると,どうも定表記法らしいものを使っていることに気付いた。昨年デライト公式デルン初描出の日として参照していたが,その時はデラング整備視野に入ってない頃だったせいか気にしなかった。

すっかり忘れていたし,DIL 0.2交度にも残っていないので,DIL 0.1 か,そんな概念もないデルン最初期実験的実装して間もなく自然消滅したのだろう。

そんなことを考えていたら,当時の実装記憶うっすらり,するする実装方針が出来上がった。1日もあればそれなりの形になりそうだ。これも自己考古学自己累新ルネサンスか。

定表記法は個人的にあまり使う機会が無く,デラング整備でも後回しにしてきた。とはいえ,標記マークアップ言語では目立つ記法の一つなので,これが出来ないことにはデラング整備を終えるわけにもいかない,というところだった。これで一気にデラング整備の終結が近付いた。


これをきっかけに,注意書き記法折り畳み記法差分記法出典記法などその他細々とした記法仕様検討も進んだ。

{出典記法}

{}