EWBの補助ツールの雑感
この記事はEWBアドベントカレンダー2019の10日目の記事です。
今どうなっているかというとf1-microでC++製VPNアプリのビルドがメモリ死で通らない。 おかしい。こんなはずでは。
何かしらの完成品を出す予定を変更して 無を語ります。
ちなみに「さっさと実アプリ動かせや」という意見はまだ15日もアドベントカレンダーがあるということを踏まえてもらえれば幸いです。
EWBの補助ツール
EWBの補助ツールには2種類あります。透けてるものと透けてないものです。
某DVDにあるパッケージのbinディレクトリの中を見るに、ほとんどが数百kb程度の
小さなアプリケーションです。EWBはプレーンテキストで、バックエンドのもまあプレーンテキストなので、文字列置換や簡単なパースをするものにGUIの皮があったりなかったりといったもののはずです。大仰な名前のpastですら、パラメータ入力フォームと四角のイラストでほぼ終わりです。xemacsやkakasiなどは失われて久しいワケですが、EWB本体の動作には別に関係ありませんし。つまり、入力と出力予想からエスパーして同様の結果のアプリケーションを作成することは可能ではないか？ という無邪気な欲求が頭をもたげます。流石にEWB本体？であるEWB-Shelf（コマンド名は
bookだったりしてもう分からん）やewb2latexの実装などは骨が折れそうではありますが、binの中の小さなやつくらいなら、と思ってしまいますね。フラグです。
今回は「再実装」という視点を持った上でツールの説明文を見てみましょう。
ちょっとEWBハンドブックに記載された動作から当時のアプリケーション動作を予想してみましょう。
明らかにツールなものは省きます。
tounix, tomac, todos
ファイルを各OS向けに変換するそうです。これだけ聞くとヤバそうですが、 変換するのがプレーンテキストで、EWBの必要ツール群にnkfがあることを考えると 察してしまいますね。改行と文字エンコーディング変換をします。
あとtodos、「TODO」じゃなくて「To DOS」なのを認識するのに少し時間がかかりました。最近の若者なので。
mamehon
翻って難敵なのは「psmentukeで作成されたpsファイルをプリンタに出力」といったもの。バックエンドたるツール群をどこまで使っていたのか、場合によってはPostScriptインタープリタやプリンタドライバの実装までして初めて完成といえるのかもしれません*1。でもpsprやfontscanは「psファイルからフォント情報を〜」のようなことが書いてあったりするので、psのパースや編集はできる必要がありそう……。
epscheck
EPS フ ァ イ ルの形式がテキスト形式、 改行コード が UNIX 形式に な っ て いる かを チェック し ます。 また、 ヘッダ部分に 漢字が入っ て いれば漢字コ ード がEUC になって いる かチェックします。
EPSの中身をフルでvalidか確認するわけではなさそうなので、幾分か楽そう。
jfontadd, efontadd
メイン部分以外の難所では1、2位を争いそうな部分です。 TFMとVFを作成して登録とか、AFMを使ってTFMを作成とか書いてあります。PSフォントから情報をエクストラクトする必要もある。
CTANで先人のツールを探してラッパを作るのが現実解っぽい気もします。
体裁入力エディタ系
psstedやpastなど。エディタを1からというほどではないにしろ、結果が体裁入力ファイルになるのは確実なので、最初から体裁入力が生で書ければ問題ないはずだ……それを言いだしたら最初からPostScriptで出力結果を生で書ければ何もいらないけど。
ちょっとずれますが、索引入力エディタもエディタ系ということでここに書いておきます。これはトリガ上書きなどで使うtriger.defも解釈できる必要があるようなので難易度高そうですね。しかし、基本的にはパースされたEWBでの出現位置、マップする索引入力ファイルを最終的にプレーンテキストで出力できれば良いのかな。
eword
最後にひょこっと載っていて毛色の違うのがこのeword。 入力はEWBフォーマットのプレーンテキストで、入力ファイル中の英単語、カタカナ語を抽出するとあります。なんかすぐできそうな気がしてきた*2。
最初は「english」かと思ったけどカタカナもなら「extract」なのかな。いややっぱりenglishだろうな。uniq sort と組み合わせれば表記揺れチェックができる、というふうに書いてあるのですが、「漢字で表記揺れなんかしないよ、もししたら埋めてもらっても構わないよ！」と言わんばかりの自信を感じませんか？ 感じませんか。
英単語はアルファベット及び- _、カタカナはー（長音）を含むとあるので、
微妙にisLetter()みたいなライブラリ関数を使うと漏らすやつですね。
おそらくこれもUnix（Like）環境を前提としたツールなんですが、単体バイナリで動いた方がトレンドじゃないですか？ 標準ライブラリでできるだけ完結した方がメンテナンスしやすいですよね？ よし、Go言語だ！ そして冒頭へ……*3。
これらのツールは基本的に入力ファイルの文字コードについて言及していないのですが、多分EUC-JPなんだろうなあ。でも書いていないからには全（主要文字コード）対応できるべきでは。そんな感じに脱線してるから今日完成してないんですけれど。
Next
たぶん時間がとれないんで数日は茶を濁した内容になるのではないでしょうか。
