自己顕示欲の開放治療所

erg, programming and something.

別名：Laughing and Grief 雑記

Latin and Greekは習ったこともない

真面目な記事の他、特定の方には不快と思われる事柄に関して言及を行うことがあります。ちょっと頑張りますが、Blog内で解決できなかった場合要望があれば別ページに技術記事は書き直します

著者と編集者と組版者の境界

この記事はEWBアドベントカレンダー2019の5日目の記事です。

adventar.org

4日目はhid_alma1026さんでした。6日目はhid_alma1026さんです。

EWBのマークアップを語る上で前提となる、編集トリガ（マークアップ）と組版トリガに向けての助走となります。

大前提として私は商業書籍出版に携わったことがないので 突っ込みどころがありましたら修正していきたいと思います。

著者編集者組版者

ドキュメント、特に書の形をとるものを書くにあたって、

  • 書くテーマの選定
  • 書くために必要な情報の収集
  • 書の内容
  • 書の論理構成
  • 文章チェック
  • 書の組版
  • 外観のデザイン

これらがパッと浮かぶ工程です。テーマの選定は更に「プロデューサー」などのロールを登場させても良いかもしれませんし、外観のデザインは「装丁デザイナー」などを置くかもしれません。

工程 著者 編集者 組版
テーマ選定 xx x
情報の収集 xx x
内容 xx x
書の論理構成 x xx
文章チェック xx
組版 x xx
外観のデザイン x

異論反論はあるかと思いますが、 それぞれの工程の担い手の比重が例えばこのようなものとして、 それぞれが同じソースを触らなければならない状況があるとします。

このとき、組版者はセクショニングや内容について作業を行うことはないでしょう。 であれば、組版者は組版専用のコマンドを触り、それは著者や編集者が誤って触らないコマンドで あることが望ましいですね。一方著者や編集者はセクショニングや文章内容について意図通りに出力できるようコマンドが用意されていることが望ましいわけです。 図表など補足的な情報については、著者や編集者は「どのあたりにあると良いか」 は関心がありますが、本の形にしたときの物理的・具体的な位置についてはこだわりは多くの場合はないでしょう。

書籍用のフォーマットであるEWBは、これを割と明確に分離しました。 それが「編集トリガ」と「組版トリガ」になります。これらはプレフィックスが異なり、可能な操作も異なります。編集トリガの物理的組版内容についてはまた編集が可能ですが、「意図が明確に分かる」以外の要望は組版者に委ねられるべきものでしょう。著者は素朴には組版に関わるべきでないし、組版者が内容に言及することはあまり好まれないでしょう。

明日の記事では編集トリガや組版トリガの具体例について見ていきます。

蛇足

私はドキュメントの執筆において 軽量マークアップによる執筆を推奨するスタンスを取っています。 校正補助CIの高速化の他、 執筆においてある程度論理的デザインを強制するからです。 破綻したデザインの印刷物が欲しい、素の（軽量でない）マークアップからでも 論理・物理構造を問題無くイメージできるなどの場合は問題無いでしょうが。

同人出版においては表の曖昧なロールが更に曖昧になるでしょう。 工程の区分けによって得られる見通しの良さは締切によってぐちゃぐちゃになり、 全てが破綻します*1。

今日日本語技術同人誌制作において勢力を伸ばすRe:VIEWはEWBの影響を受けた書籍制作用ツールとフォーマットです。これも後日の記事に譲りますが、ソースの配置構造などに確かに似た点がありますね。「PDFの出来が想定と違うんだが」のような呟きを同人誌即売会が近づくと散見するようになります。 同人誌制作においてロールが曖昧になると、執筆者が組版の問題にぶつかるなどの状況が 発生します。ドキュメンテーションツール全般にいえることですが、これらのツールは工程を分担しますが、飽くまでロールの分離を明確にするだけであって、他のロール自体を代行してくれる訳ではないことを留意するべきです。ロール自体を代行させたいのであれば強いAIの開発などに注力すると皆が幸せになるのかもしれません。

あるいは人、人は雇うことができるのでお薦めです。

*1:By サークル Virtual Ones代表@hid_alma1026

軽量マークアップおさらい

Markdown LWML

adventar.org

軽量マークアップ言語の用語とマークアップ言語の用語の区別はしていませんので悪しからず。 多くの人はHTMLにおいてよく触れるワードもあるので必要性は薄い気もしますが。 今日はお茶濁しです。

独自というか今後記事で触れる普遍的でない要素もこの記事で書きます。あるいは書き足します。

メタデータ

記事中では、タイトルや著者名といったものを含む、それぞれのドキュメントに必ず必要ではないものをメタデータとします。 これ以外の要素は、凡そインラインとブロックに分類できます。

ブロック

この区切りの後には改行が入るような構造、というのが一番ふわっっとした解釈でしょうか。 何らかの「まとまり」で表わされるような要素を格納します。他の要素

生ブロック

内部に他のインライン・ブロックを持てないブロックです。所謂verbatim。 これ自体のスタイルをいじるのは別のレイヤの話です。

インライン

改行が入らないやつ（ry

文（ライン）中で使われるので「インライン」ですね。 軽量マークアップの多くはインラインは他のインライン・ブロックを許容しない作りのことが 多いのではないでしょうか。

生インライン

所謂verb。

オプション

ブロック・インラインの要素についての補足。属性の付与といった補助的な要素。

Headings（見出し）

ブロックとすべきかインラインとすべきかは構成によるでしょう。

まあ見出しとしか書きようがない。Sectioningとの比較としては、これは「見出し」そのものです。 意味マークアップ的にはそのSectionの内容を端的に表す文字列といったところでしょうか。 多くの（軽量）マークアップ言語では、見出し要素のある箇所によってSectionが区切られるので 混同することがあるかもしれません。それこそHTML5が分かりやすく、sectionタグとh1タグは別ですね。

Sectioning

「節」は意味マークアップ的には同じトピックについてまとめたさらに細かいマークアップの塊のブロックですね。 Headingsとこれが明示的に分かれていると、「はじめに」「おわりに」を使わなくても どの程度の深度のトピックについて話しているか（戻ってきたか）が分かりやすくなりますが、 マークアップ言語以外だと実はあんまり恩恵がないのかもしれない。

Table

忌まわしきテーブル。テーブルが悪いのではなく、人類がテーブルマークアップに 向いていないし、あとブラウザと当時のHTMLが貧弱だったためにテーブルレイアウトというものが 生まれてしまったのがいけない。

複雑なテーブルはそもそもの構成を見直すべきという説もありますが、 表現力自体は維持したいマークアップ言語実装者の大きな壁。

リスト

スニペットをListとキャプションしたりするので紛らわしいですが、箇条書き系統のことです。

マークアップ記号について

マークアップ記号、特にその接頭はは文書中に登場しない、あるいは出現頻度が少ない記号であることが期待されるのは 多分自然でしょう。かつ、できるだけ統一性があると記憶とパースがしやすくなりますね。 そして、自由度の高い文書を作るマークアップのために、使用に制限や制約がかかる記号は少なければ少ない程良いです。

SGMLの系譜は<``> </ですね。\TeX{}は\``{``}といっていいでしょう。多分。

しかし、もっと様々な記号を使った方が人間がパースするときに見易いだろうというのは皆経験したことでしょう。 更に、厳格なマークアップは、マークアップに使うタグなどが文書の本文よりも多いような状況になり 可読性が落ちますね。

軽量マークアップ言語の登場の背景の一因として今挙げたものが考えられます。 より多言語のための抽象化みたいな話はおいておいて、 この考え方に則ると、軽量マークアップ言語はマークアップ言語のSDL（ドメイン特化言語）として捉えることができます。 このへんに関する議論は後日土台を書き直すので今はインターネット読み物としてスルーしてください。

上の方で挙げた、ブロックとインライン、これらは同じ記号で記述するより別に表記した方が人間の目には優しそうですね。

他にも、頻出する構造に関して短縮記法があると便利ですね。

このバランスが難しいところで、人が覚えてすぐ使えるフレーズというのはあまり多くないことを考慮しなければなりません。

以前の参加レポート記事で、

CAS-UBがMarkdownに対して敗北したというアンテナハウス社の方の発言がありましたが、

X（HT）MLを何とか簡易にしようという思想で生まれたであろう*1CAS-UBは 記法が多すぎてそもそもの学習コストが高いというのがあります。1対1対応で全てのショートハンドを用意すると、全ての書き方を覚えなければならないということですね。

更に脱線しますが、

「Markdownはマークアップではない」

という話がありました。

ここで広義の約物（Punctuation）について考えてみましょう。 日本語であれば、句読点、 。 や「``」といったもの。文章を読み易くするために使う記号ですね。これらはプレーンテキストの文章に含まれます。この拡張として **strong** などがあるとして、それを構造としてパースしようというのが「視覚的マークアップ*2」になる訳ですね。論理構造と文章の読み易さはある程度まで共通します。 このバランスを取るのが簡易マークアップの醍醐味なのではないでしょうか。

にな

*1:要出典

*2:この用語は昨日しった

EWBのツールとフロー

adventar.org

この記事はEWBアドベントカレンダー2019の3日目の記事です。

2019年12月5日追記： ツールの用途についてコメント頂きました！

EWBのツール群にはkakasiやxemacsなどが含まれる これらのツールは、EWB本体に必要なツールではなく、エディタでマークアップするのが苦手なアスキー社員でもEWBを使えるよう、GUIツールを追加した際に含まれるようになったものだったと記憶しています。 XEmacsはマウスで範囲選択できるようにするため、KAKASIは索引作成時に候補を表示させるために使われていたんだったかな。

2日目の記事にコメントくださっていて、3日目の記事のところで私が予想していたものが大体合致していたようです。こういうレスポンスが欲しくて始めたので嬉しいですね。

EWBの構成概略

さて、2日目の記事ではEWBの歴史を軽くなぞりました。 歴史的なソフトウェアのつくりについて考えるとき、 ハードウェア事情といった時代背景を欠くことはできません。

EWBが構築されるにあたってのコンセプトは

  • 作業工程の維持
  • 作業分担の維持
  • 効率化
  • コストを下げる
  • 既存の環境を利用
  • 品質

といったことだとEWBハンドブック一部二章で書かれています。 結果、UNIX（Like）環境で、主要ツール以外は既存のアプリケーション を利用するなどしたシステムが誕生しました。また、 ビルドを行うEWBサーバと、ドキュメントの編集を行うクライアントに 分かれた構成も技術書出版会社の面目躍如といったつくりです。多分。

インストール要件

EWB3.3の動作環境と必要アプリケーションは以下のようになっています。

ツール種別 ツール名
マシン PC-UNIX系のOSがインストールされたコンピュータ
Printer UNIXから利用できるPostScriptプリンタ
ターミナル X Window対応の端末 (無くとも可)
TeX pTeX p3.0.1 (EUCバージョン)
LaTeX pLaTeX <2001/09/04> (EUCバージョン)
DVI->PS変換 dvipsk 5.86 p1. 5f
和文VF作成 makejvf 1.1a
索引整形 mendex 2.5
PSインタプリタ ghostscript (日本語対応版で5.0以降)
PSビューア ghostview または gv
漢字コード変換 nkf
文字置換フィルタ sed (日本語対応版)
テキストエディタ jvim (日本語対応 vi)
Java実行環境 jdk1.1.8以上
X Windowシステム XFree86等 (X11R6またはそれ以降)
X Window漢字端末 kterm
Tcl/Tkインタプリタ tcl8.0/tk8.0 (日本語対応版)
perlインタプリタ perl5
テキストエディタ xemacs
かな漢字逆変換 kakasi
漢字変換インターフェイス kinput2

(FreeBSD 4.9-RELEASE, RedHat Linux 8.0, Vine Linux 2.6r1 で動作確認済み)

いやー。ははは。これを維持するのは相当……。 外部に投げられるところを投げるとそれが更新 されない場合のリスクがあるということですね。皆さんはOSSの維持に貢献していますか？

EWB3.3本体はJavaですから、他が補助的に必要になる訳ですね。 なお、3日目の時点では某書についてきたバイナリEWBを開いて 確かめるなどはしていません。

LaTeX系のツール群としてp\TeX{}、p\LaTeX{}、dvipsk、makejvf、mendex。 PostScriptレベルでのの処理用にghostscriptとghostview。 EUC-JPしか処理できなかったp\TeX{}のために文字コードを変換するnkf。 置換処理用のsed。CLIでの文章編集のためのjvim。 Perlは通常のスクリプト用として、Tcl/TkがGUI操作用のインターフェース画面を 作っていたんでしょうか。 入力補助用のkakasiとkinput2があり。 そうなるとxemacsはクライアント側でのエディタでしょう。

EWBで使うファイル

どうでもいいですが、 EWBハンドブックの1部4章1節のタイトル「一般知識」ですよ。強い。

dat 体裁入力ファイル

大まかなレイアウトに関する情報を入力するファイルです。 内容については後日の記事でやりますが、ここにビルドに必要な補助情報と 全体のレイアウトを記述します。 そう、EWBを使っている人はバックエンドの\LaTeX{}を意識することなく 書籍が作れるのです！ 設定項目からどんな命令に置換されるのか透けて見えますが。

本文部分のものと、索引体裁があったようです。

doc ドキュメントファイル

ドキュメント本文が入るファイル群ですね。.docがMS-Wordの専有に近い拡張子となるのは Windows95以降くらいらしいので、 それより古い起源を持つソフトウェアが使い続けていても仕方無いですね。

最初tar.gzから解凍したとき3時間くらい悩んだよ……。

contents.ewb ファイル

docファイルをセクション順にトリガを用いて記述してあります。 このファイルを元にファイル内容を取得して全体を構成する訳ですね。

trigger.def

EWBのマークアップと\LaTeX{}のCSの橋渡しですね。 書籍毎に処理を弄れるように外に出ていたのでしょうか。

PDFStyle

PDF時の特殊処理を記述したファイルですね。dvipsの方がメジャーだった時代。

yakumono.sed

約物の処理はsed任せだったようですね。

以上に加えて、画像や、表を別ファイルに記述したものなどを合わせると EWBでドキュメントを作成するための準備ができます。 漏れがあったら後日こっそり足します。

EWB-Shelf

ツール群全体のことをEWBと称してきましたが、組版処理を担うプログラムは EWB-Shelfと呼ばれています。 「トリガ解析をして文法ミスをチェック」する作業も含まれると ありますので、p\TeX{}に処理を渡す前にエラーのほとんどを 潰せるようにしたのでしょうか。組版トリガはスルーしてた可能性もありますが。 この辺りは後半の記事にご期待ください。

私がヤベーと思うのは、コイツ体裁ファイル処理して.clsファイルを ジェネレイトするんですね。現代的な（あるいはプリミティブな思想の） \LaTeX{}ではなかなかやらないと思います。

guisted

体裁入力ファイルをGUIで作るためのツール、とのことです。 TeXWorksの初期設定的なやつや、 kmutoさんが開発中のRe:VIEWのブラウザで動作するレイアウトエディタなどが近いでしょうか。 特徴として。EPS画像を扱えるのでより装飾の強いレイアウトが可能です。 それぞれのトリガの動作詳細もGUIで調整できます。確かに強い。

past

図表の組み込みフローのところに記載された強そうな文字列。 「物理属性エディタ」なるツールによって原稿中の図表の入力、設定を行い、 「物理属性ファイルに保存」をするらしいです。 EWBの組版トリガはほぼ\LaTeX{}そのままなので、 仮組からの修正が利きやすいのでしょう。 テーブルなどが別ファイル記述な理由もここでの修正を視野に入れたものなのでしょうね。

物理属性エディタの名前はpastです。 usephyというオプションをEWB-Shelfの処理上に記載し、 pastを展開します。原稿中の図表位置につけたトリガの位置を取得し、 表れた設定画面で値を埋めていくと良い感じになるとのことです。

細かいツールはまだまだあるんですが、まあEWBハンドブックを見ましょう。

フロー

大まかなフローを更に簡略化すると

組版チーム

  1. 体裁ファイル作成

原稿チーム

  1. 原稿作成
  2. 図表作成
  3. EWBフォーマットに原稿を落としこむ

どっちかのチーム

  1. EWBフォーマットの図表リスト

組版チーム

  1. 流しこんで組版
  2. チェック
  3. 図表位置など修正

現代、特に同人誌などになると著者と編集と組版がごったになって様々な箇所で 地獄を見ていることを考えると、この分担フローを改めて考えてみるのもよいかも しれませんね。よし、綺麗に終わった*1！

Next

4日目は@hid_alma1026さんです！

adventar.org

*1:折を見て綺麗に構成を組み直そう。そうしよう

ひょっとしてSKKって日本語Markdownに最適なのでは

Markdown SKK

滑りこみPandoc Advent Calendar2019 2日目の記事。

adventar.org

1日目は@skyy_writingさんで

qiita.com

でした。

導入

人、人と会話していて、「なぜWYSIWYGが好まれるのか」などの話と、 「小説投稿サイトのマークアップ記法」の話から

「アスキー記号（ # や @ などアルファベット以外）の打ち込みコストと全角記号の入力コスト」

の話になった。日本語文書を書く際、通常のIMであれば所謂日本語モードでは記号類は全角入力を期待される。一方ASCII圏で多く開発されたマークアップはほとんどそのマークアップに半角のアスキー範囲の文字を用いる。それぞれの社の内部などのフォーマット規定はともかくとして、普及しているマークアップ・簡易マークアップはほぼそうだ。そりゃあ半角文字しか使っていないのに全角文字を態々マークアップ用に使うなんてことはないだろう。

普段からエディタでテキストを書く人間にとって、日本語キーボードであれば半角／全角キー、USキーボードであればAlt+~を叩いてモードを変えるなんてのはブラインドで行う操作であるが、そうでない人間はあるいは全角記号を 変換 キーや スペースキーで半角記号に変えて日々を過ごしているのではないだろうか*1。かな入力勢の話はしない。

であれば、強調を行うために * を押すコストは、MSWordで「強調」ボタンを押し、また戻すコストより大きいのではないだろうか。マウス操作やショートカットキーでの操作などを考えると比較可能なものかは分からないが、まあASCii語圏のマークアップより手間がかかるといっていいのではないか。

つまりSKKを使おう

SKKそのものについてはOpenLabのページを参照されたい。オリジナルはEmacs上で動作させるものであるが、あまりに使いやすいので各種移植版が存在する、日本人のためのインプットメソッドである。代わりに、誤字として急にlが挟まりやすくなったりする。

openlab.jp

WindowsであればCorvusSKK

nathancorvussolis.github.io

macOSであればAquaSKK

github.com

Ubuntuであればibus-skkなどがある。この文章もibus-skkを用いて記述されている。

で、このSKK（Like）、日本語入力モードのとき、記号類については半角（ASCII範囲の）記号を入力する。逆に全角記号を入力したいときはShift+Lを押して全角ASCII入力モードにする必要があるが、半角記号類を入れたいケースの方が多いだろう。

SKK（Like）を用いると、次のMarkdown文章は入力モードの変更なし*2に入力可能だ。

## はじめに

**この文章はエスケーケーで書かれている**。

…… SKK って入れるのに入力モード変える必要があるからね。仕方ないね。どうしても入力モードを変えたくなければ辞書登録する手もあるが。

勿論、SKKに触れる機会のあるような人間が入力モードの切り替えコストぐらいでプレーンテキストマークアップよりWYSIWYGエディタを選択するとは思っていない。MarkdownをダシにしてSKKの布教を行いたいだけである。

*1:[要出典]

*2:変換待機の「▼モード」を挟んでいるので嘘だが、ASCIIモードと日本語モードは変更していないので

EWBの歴史概略（「はじめに」を引き伸ばして）

LaTeX EWB

この記事はEWBアドベントカレンダー2019の2日目の記事となります。

adventar.org

暫くはEWBハンドブックの内容を薄く引き伸ばした内容となりますので、 本記事とEWBハンドブックを比較していただければ今後どういう記事になっていくかの 参考になるかと思われます。

予定とはずらして、2日目はEWBの歴史を書いていきます。

資料を収集する予算と期間が十分でなかったため、Wikipediaからの引用を含んでいきます。

推測的な内容も含まれますので、都度注意してお読みください。

私がEWB真っ盛りの時期に一切接点がないこともあり、何らかの関係者からの修正、補足を大変心待ちにしております。

EWBの歴史

EWBハンドブックに依れば、EWBの開発は1986年に遡ります。 といってもアスキー編集部内での工程を崩さないように文字原稿の棒打ち出力のみ サポート、とありますのでフォーマットとしてはかなり素朴なものだったと思われます。 それでも、写植での出力予想を行うことができ大幅な工程短縮になったとのこと。

Wikipedia*1 からの引用になりますが、英語圏でのマークアップ言語開発は1960年代〜1980年代に登場、進化してきました。Scribeが1980年発表、SGMLの国際標準化が1986年です。また、\TeX{}も1970年代〜1980年代になります。

publishing \TeX{}（p\TeX{}）の開発は1987年にj1.0のリリースですが、EWBハンドブックによれば組版エンジンにp\TeX{}を採用したのはEWB2.0からとのことなので、最終形である3系のハンドブックから1系のフォーマットを予想することは少し難しいでしょう。それでも、 レイアウトなどに関連する、「編集トリガ」と「組版トリガ」*2の接頭マークの分離というアイデアはこの頃のものからではないかと推測されます。

そのまま1990年登場のEWB2系の話ですが、p\TeX{}の出力が写研の写植機用の印画紙出力などに対応し、 そのまま出版クオリティのものを作れるレベルまで達したとあります。1990年のp\TeX{}はバージョンj1.7 p1.0.9、縦組みへの対応が最大の特徴ですので、かなり満を持してのものであったことが伺えます。この頃からのp\TeX{}チームとEWBチームはほぼ一緒と考えてよいのではないでしょうか。少なくともEWBコンソーシアムのお問い合わせメールアドレスはptex-staffの文字が含まれますからEWB3系は確実ですが。

1996年に登場するEWB3.0の最大の特徴はPostScriptへの対応です。印画紙への貼り込みからの脱却、面付けデータのフィルム出力が可能になるのはメジャーバージョン更新に相応しい進化です。1995年に p\TeX{}のバージョンがp2.0になり\TeX{}3に対応をしていますから、この辺りの調整が内部的には大きな変化だったのではないでしょうか。この際p\LaTeX{}はp\LaTeX{}2eとなっています。グッバイ\documentstyle。

そしてp\TeX{}の改良と合わせ1999年10月にEWB3.1がフリーソフトとして公開されます。

現在、当社の書籍の7割がEWBで作られている。

（2019年現在も稼動中という風の噂がありますね。）

さらに、多くの出版社に電子化を広めるため、企業8社と共にコンソーシアムを設立した。このコンソーシアムからも、今後さまざまな関連ツールを提供する。

EWBコンソーシアムはEWBのソースコードとLinux, FreeBSD版のバイナリ配布を行っていました。 アスキーからアスキーメディアワークスに移行した際は新URLで閲覧・情報取得可能でしたが、 いつの間にかサイト再編時に、おそらくはp\TeX{}のページと共に消失してしましました。 2015年頃にp\TeX{}のページを取得、保存されている方がいることから、 この頃までは存在していたものと思われます。私は2014年頃Linux環境でEWBを動かそうとしていた記憶があります。このときのソースを保存していれば……！

更に余談ですが、EWBコンソーシアムの更新情報のページ、2000年に第1回の年次総会を行ったことを記載してありますが、以後の年にはありません。ここの総会資料のPDFも誰か持っていませんでしょうか……。

話が戻ります。

3.2でPDF出力対応強化、3.3で体裁入力機能強化とあります。EWBにおける体裁入力は独自の形式に 記述していきます。生\LaTeX{}書くのは相当見通しが悪かったんでしょうね。後日の記事でも触れますが、EWBは書籍毎にこの体裁ファイルなどから都度クラスファイルが生成されます（！）。

EWBの最終版は2002年の3.3（とマイナーパッチ）となり、EWBは配布こそ続けられるもののメンテナンスされない状態となりました。更新情報の履歴を見る限り、2005年にはもう更新されていませんね。これも後日の記事になりますが、EWBのツール群にはkakasiやxemacsなどが含まれるため、他ソフトと連携するOSSの寿命などを考えさせられます。

EWBのインストール方法を載せているページのリンクから、EWBのp\TeX{}でない部分の本体は JVM1.4系で動作するようなソフトウェアであったことが推察されます。

ちなみに「VMware Playerですぐ使える　日本語TEX＆EWB組版システム」は2008年の発売ですから、既に何らかの形でのコード保存の意図があったと考えられます。ソースコードも入れてあれば良かったのに……。

EWBの将来

EWBコンソーシアムのページに気になる文言があったので記載しておきます。

＜ＥＷＢシステムの将来＞

EWBは現在もアスキーの主力製作システムとして使用されており、PDFへの対応や、XMLとの親和性の向上など、引き続き開発が進められています。今後も、さらに高機能で使いやすいシステムに発展して行くでしょう。

これは期待大ですね！

Next

良いタイミングがあったら他の関連物と合わせて年表化したいですね。

EWBアドベントカレンダー2019、3日目の記事は@hid_alma1026さんです*3！

adventar.org

*1:https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E8%A8%80%E8%AA%9E

*2:「トリガ」はEWBの用語で、要素のマークアップのこと

*3:（昨日やり忘れた）

インターネットの海とEWBハンドブック

この記事はEWBアドベントカレンダー2019

adventar.org

の1日目となります。

とりあえず14日あるんでね、最初はゆっくりいきます。

この記事自体のEWBの中身との関連はちょっと薄くなります。もうちょっとジェネラルな話題です。

引用元を全て用意するのは14日完走するためには辛いコストなのでご容赦ください。要望があれば載っけられるソースについては後から足します。間違っている箇所については検証の上修正していきます。

「インターネットに流出したものは消えない」のか

「インターネットに一度流出したものを消すことは難しい」という問題提起？を見たのは、P2Pソフトウェアで不適切なコンテンツを共有してしまう事件が頻発していた頃に見られたのが私の周辺での感覚である。「吐いた唾は飲み込めない」といったものも含意していたと理解しているが、逆に「インターネットに資料があるから安心」とはならないことを実感したのが私にとってのEWBコンソーシアムである。

私がEWBの存在を知った頃、未だEWBコンソーシアムのページは存在し、EWBのソースコードや 各プラットフォーム用のバイナリが配布されていた。詳しくは2日目の記事にするが、結論から書くとこの時入手することができた情報の少なくとも1部は私の手の届く範囲から欠落してしまった。KADOKAWAによるアスキー（アスキーメディアワークス）統合によるサイトの消失とサイトに掲載されていたページの消失である。

EWBコンソーシアム以外のEWBに関連したページというのは、かなり少ない。1出版社の内部で使われていただけのフォーマットとツール群と考えれば不思議なことでもないのだが。例えば秀和システムで要求されるフォーマットについて、スライドに一瞬映る以上の記述が述べられたサイトがあるだろうか*1。しかし、オープンに公開されていた情報であるにも拘わらず、EWBについて言及したブログ記事はほぼ無い*2。オープンになっている情報であるからといって、皆がアクセスし、記憶・記録をしているとは限らないのである。

リソースを保管するにはコストがかかる。自らの手以外の場所で、そこに行けば必ず得られるものを 保管するには相応の理由が要る。図書館の蔵書能力にも限界があり、個人の収蔵も没後に価値を共有されていなかったりすると悲惨だ *3。 ビルゲイツはすごいな。

Mastodonの運営からniconicoに続いてPixivも引いた。 連邦型SNSは中央型SNSの問題の軽減はできるが解消とまではいかないのでまあそうなりがち。 完全P2P型SNSは動作要件とニーズが合わないのかなかなか難しい。コンテンツの管理に関してはより混沌とするし。この辺は別のアドベントカレンダーの記事で書く予定。

Twitterのアカウントが突如削除されて故人のデータに触れることができなくなるといったケース*4についても、皆知ってはいたリスクにしても現実味がなかった。なんだったらTwitterを使っているがこのニュースを知らない人間も周囲にいた。実際2週間ほどで一斉に故人のアカウントが全て消えたとしたらどれだけの人間がそこにあった情報にアクセスできなくなるだろうか。他の問題として、個人でその情報を保管していた人間がいたとして、その情報の真正を証明できるのか。

企業に集権的に蓄積されたデータは企業の都合で消失することがある。インターネットの海は広大であるが、区切られており、様々な場所でそこにしか無い資源があったり、そこにしか無い環境であったりする。 終了したソシャゲのデータはどこかに著作権が切れるまで保管されるのだろうか。

Internet Archiveというプロジェクトがある。 Internet Archiveは膨大な数のWebページのキャッシュを保管しているが、Webページの全ての情報を保存している訳ではない。その欠落する情報の1つがpackingされたソースコードだったりバイナリだったりする。 EWBコンソーシアムのサイトに書かれていた情報は幸いこのような場所から得ることができる。改竄されていないかどうかは信じるしかないが。

web.archive.org

EWBハンドブックをみつけたかもしれない

プログラマのような職種にとって、望みをかける場所はまだある。パッケージマネージャのサイトに保存されているソースなどだ。バージョン毎のサポート期間内は少なくともソース・バイナリを保持しており、 サポートが終了してもリソースは残っていることもある。 EWBはDebianに登録されていた時期がある。当然探したが、2019年にEWB本体のコードは私には探せなかった。 代わりに、EWBコンソーシアムに載っていた情報以上のもの（実用上必要になる情報）が揃ったEWB Handbookに関してはaptのサードパーティのリポジトリを登録するLaunchpadにソースコードと見られるものが存在した。 EWB本体が見つからないのでビルドはできなかったが。

後日、大学時代の先輩から『VMware Playerですぐ使える　日本語TEX＆EWB組版システム』を紹介してもらった。アスキーのEWBの本が何故アスキーからでないのかは置いておいて、重要なのは EWBのFreeBSD版バイナリが同梱されたディスクがついてくること。本自体の内容はVMwareでのセットアップなどに重きが置かれており、知りたかった仕様や実装などではなかったが。

www.socym.co.jp

こちらに関しては後日の記事のために残しておく。

極限状態でインターネットの海を彷徨うと、意識を取り戻したときに成果物だけ持ってどこか知った場所で意識を取り戻すことがある。 普段ならこういったものを扱いたくはないが、まあ元データのライセンスを確認し、内容物のチェックも一通り行ったので再配布要件とウイルス汚染は問題ない、筈である。こうしてEWBハンドブック.pdfが手に入った。

で、

github.com

に置いた。ここから始まる14日間のアドベントカレンダーの内容はこのハンドブックの内容を薄く引き延ばしたものと大差ない内容となる予定なので、見切りをつけたい方、15日目以降に参戦を希望される方は こちらを参照してほしい。また、万一このソースとpdfの公開について各種法律的に問題が生じているようであれば申し出いただければ対応する予定である。

*1:あると嬉しいので各出版社公式から出ないものだろうか

*2:絶無でないのが難しいところで、しかしあのサイトについて言及するのは避けたい

*3:面接のときに自分が当社で考えるサービスみたいなことを訊かれたときにオタク向け死後財産オークションシステムはどうかと提案して落ちた会社があったような気がする。

*4:日本ではないし未遂

Sphinx LaTeX Translatorを読もう

LWML LaTeX Python Sphinx

Sphinx LaTeX Translatorを読もう

数年前、ドキュメント系は何もかもreSTで書いていた時期、 卒研の中間報告をreSTで書いたのをSphinxで\LaTeX{}にして 出していたことを思いだした。

中間報告用の\LaTeX{}スタイルファイルが提供されていたが、 sphinx.styの設定と競合するところがあって苦労した。当時は.styや.clsの中身を読める程 にも習熟していなかったから試行錯誤して改造しまくって、再利用性が全く無くて失敗だった。

過去の話は置いておいて、 SphinxのLaTeX出力を改造するなら「どの段階で」「どの出力を」いじるのかを考える必要がある。 Sphinxの出力に手を入れないのなら、\LaTeX{}のクラス・スタイルファイルをいじる必要が ある。簡単な調整なら適当に目についたエラー箇所を書き換えれば 何とかなるが、使い勝手を考えるとsphinx.styの中で定義されている命令群などをしっかり把握する必要がある。

その中間での課題として \LaTeX{}出力で何が辛いかといえば、「自分のドキュメントでは使わないものも決め打ちで書き込まれてしまう」ことである。この書き込まれる内容に関わるのがwriter、そしてそこで利用されるTranslatorである。

買って応援Sphinx

writersやらbuildersやらはdocutilsの構造の話で、この詳細が知りたいのであれば

がなんと無料化されたので是非ダウンロードして読んでほしい。

Sphinxでの拡張は既存の拡張を参考にすると作りやすい。 そのための拡張の読み方について事例を交えて解説されている

がたったの1000JPY！

writers/latex.py

大雑把にはこれはデフォルト設定のプリアンブル、conf.pyで設定可能なパラメータのデフォルト、 パラメータによる設定の分岐項目と\LaTeX{}固有のテーブル処理など、 そしてTranslatorを呼び出し書き込みを行うWriterと各マークアップのNodeをどう処理するかを記述したTranslatorで構成される。LaTeXWriterで読みこまれるときにデフォルトのプリアンブルをどうにかしておかないと、ビルド時に若干アレなプリアンブルが読みこまれてしまう。

sphinxhowtoとsphinxmanualとlatex_theme

HTMLに比べ貧弱とも言えるSphinxのLaTeX{}出力。これは 「\LaTeX{}のことはよくわかんないけどいい感じに望んだ出力がほしい」という素朴な欲求 の悪魔合体であるところ*1のhowtoとmanualとLaTeXBuilder（ここではWriter, Translatorを含む）の絡み合いによるところが大きいのではないか。 前回記事にしたように、\LaTeX{}側としてsphinxhowto.clsとsphinxmanual.clsで設定されていることは意外と少ない。個人の意見として、先ず「LaTeXBuilderがやりすぎ」であるのが現在の「いい感じにしたいけどよくわからん」の原因ではなかろうかと思う。つまり sphinx/writers/latex.pyなんてエンドユーザが読みにいかなさそうなところに書かれたデフォルト設定の量の多さが今となってはよくないのではないかと。

昔に比べ、現在は\TeX{}Liveの整備によって充実した\LaTeX{}のクラス・スタイルファイルを簡単に利用できるようになっている。これは人、人が\LaTeX{}を書けるようになったことを意味しないが、しかしひっそりとした場所に決め打ちになっているコードとの相性はよくなさそうである。クラスファイル・エンジンの差を吸収する方針は良いとして、\LaTeX{}の話をPython側でなんとかしようとしすぎではないか。

\LaTeX{}クラス・スタイルファイルが様々な点で独立である以上、先ずはhowtoとmanualという、いってみればthemeにすぎないものと密結合なLaTeXBuilder特に中身であるLaTeXTranslatorを 構築し直すことが必要なのかもしれない。年始くらいに何かしらできるように頑張る。

記事書いてたら拡張全然書けてへんな。jlreq.clsはエンドユーザ用のオプションだけでも設定項目異常や……。

*1:要出典