EWBとRe:VIEW
この記事はEWBアドベントカレンダー2019の記事です。
2019年12月11日23時30分追記:
紹介あざます。layouts内はサブフォルダではなくその直下にlayout.tex.erbとlayout.html.erbとなっています(その経緯でwebmakerとepubmakerでレイアウトが分けられなくてちょっと困っています…) https://t.co/n7hYzlDrDB
— kmuto (@kmuto) 2019年12月11日
該当箇所を修正しました。ついでに出力について、EWBは印刷前チェックの目的もありましたね。
Re:VIEW
Re:VIEWは青木峰郎氏によって開発され、現在@kmuto氏によって 保守・開発されている、Ruby製の書籍用マークアップとその処理系です。
Re:VIEW公式に言及されているように、EWBにその源流があり、それは書式の他の点にも見ることができます。
というわけで、今日はファイル構成とドキュメント以外の書式比較について言及します。 Re:VIEWのバージョンは4系、EWBのバージョンは3.3のものを基準とします。
ディレクトリ構成
一般的と思われる構成です。
EWB
lst
やtbl
の中身はEWBフォーマットのプレーンテキスト。.ewb
にもできます。
doc
もEWBドキュメントであることを示すだけでMSWordではないです。
基本的にeucjpエンコーディングです。
ドキュメントは同じ箇所にまとめて配置し、画像やリスト(ソースコード)などはまとめてそれぞれのディレクトリに配置しています。これらの配置位置を
マップするのがdat
などに書かれた情報になります。
バックエンドは一択、文書用のクラスなどコマンドにより都度生成されるので、処理時に別の場所に置いてあるewbbase3_3.styなどを呼ぶものの、基本的に ディレクトリ構造がシンプルですね。
Styles内のファイルは基本的に各体裁用エディタ(フォーム)の出力dat
から生成されます。
読み込むファイルと順序などの記載されたcontents.ewbはEWB-Shelfで生成するのが恐らく基本的な方法でしょう。
root/ ┣FIG/ ┃ ┗*.eps ┣LIST/ ┃ ┗*.lst ┣Styles/ ┃ ┗triger.def //マークアップ挙動記述 ┃ ┗PDFStyle //PDF出力用設定ファイル ┃ ┗*.sty ┃ ┗*.cls ┃ ┗yakumono.sed //実質的pre(post) process ┃ ┗ewb2latex.cls //基本LaTeX体裁 ┣TABLE/ ┃ ┗*.tbl ┝ForAll.index //索引登録ファイル ┝ForAll.phy //図表登録ファイル ┝MENTUKEinfo //面付出力用設定ファイル ┝PDFinfo ┝common.dat //他メタデータ ┝psidxested.dat //索引体裁 ┝pssted.dat //体裁 ┝contents.ewb //処理ファイル登録ファイル ┝*.doc ┝*.doc ┝ ...
Re:VIEW
root/ ┣layouts/ ┃ ┗<出力形式ごと>.erb //(rubyテンプレート) ┃ ┣lib/ ┃ ┗*.rb //rake用補助ファイルその他 ┣sty/ ┃ ┗*.sty //TeX用体裁補助ファイル ┣Rakefile/ ┃ ┗*.rb ┣images/ ┃ ┗*.* // 画像ファイル ┣doc/ ┃ ┗* // usage ┝style.css //html用体裁ファイル ┝catalog.yml //処理ファイル登録ファイル ┝config.yml //メタデータ、一部体裁記述ファイル ┝*.re ┝*.re ┝ ...
catalog.ymlがcontents.ewb相当になりますが、YAML形式なのと、 体裁のマッピングはlayouts内のテンプレートとconfig.ymlにあるので かなり見た目がすっきりします。比較は明日の気力次第。
config.ymlも
また、出力のスタイルに関しては、 現代的なの使い方らしく、各場面に合わせた出力に関してもクラスファイルが担い、 必要に応じてスタイルファイルを足したりする形なので、やろうと思わなければ体裁系のファイル群は爆発しません。 EWBがと周辺の過渡期のものであるという歴史を踏まえる必要がありますが。
また、ビルド用ツールの設定がデフォルトで用意されていることで、個別コマンドで出力を調えていくコストが下がっているのも現代的ツールの特徴といえるでしょう。
体裁入力ツール
EWBのややインタラクティブな体裁入力エディタ(pssted)は長年Re:VIEWには無いものでしたが、Re:VIEW4からは ブラウザで見られる体裁入力画面が使えます! すごい! えらい!*1
出力
これを比較と書くべきか分かりませんが、フォーマットの面で触れるであろう事項なので。 EWBはプリンタレディな出力予想とPostScript出力を得るのが目的であり、(少なくとも現在の)Re:VIEWはもう少し汎用的あるいは前段階の出力を意図しています、多分。このことは組版マークアップ入力書式において、意図していたかはおいておいて、両者の違いに表れてきます。
Next
内部フォーマットと体裁フォーマットの比較を、折れていなかったら。
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
たぶん時間がとれないんで数日は茶を濁した内容になるのではないでしょうか。
テーブルと図表挿入
この記事はEWBアドベントカレンダー2019 9日目の記事です。
テーブルの記法
EWBハンドブックには
表の項目が単純に並んでいるような体裁の表を作成することができます( 各項目が連結しているような表は対象外)。表組の種類は必要に応じて増やすことができます。
とあり、アスキーにも複雑な図表のマークアップ決定版は出せなかったんだと思うと 勇気づけられますね。そもそも複雑な表組を求める人間が悪いのはそれはそう。
//table1[<トップ寄せ>(<トップ幅>)][<寄せ>(<幅>)]{ //g{項目トップ 項目トップ//g} 項目 項目 ... //table1}
//table1{...//table1}
で囲みます。項目はタブ区切り。ハードタブです。
幅指定オプションをしない場合、表組の字送りの値が使われます。
table「1」。表組の体裁種類が増やせるために数字なんですね。
//g{ ... //g}
を項目トップに書いているのはゴシック体にするためで、必須ではないですね。
項目が長くなる場合は自動で行送りが入ります。の素の表を考えるとちょっと嬉しい。
体裁で決めるのは各種書体の他、字下げと字上げ(表のインデントとデデント)、タブをスペース幾つに展開するかなどになります。 囲み罫は体裁で指定とありますね。
図表の取り込み、処理
EWBは図表の取り扱いについてその他のマークアップとは異なる処理順を取ります。
ここで言う図表はテーブル、画像、ソースコードといったものです。変わったところでは数式を
.tex
としてここに分類します。
先ず、フロートするもの、しないものに分類されます。 しないものは原稿中の指定位置に必ず出力されます。複数ページに跨がる場合は 自動改ページされます。的な対応については余裕がないので割愛します。
「フロートするもの」はhere, top, bottom, pageといった位置指定ができます。
これによる結果が気に入らない場合は組版トリガで調整することになります。
この辺りまでだと特殊性が分かりませんね。数日前に登場した物理属性さんの出番です。
先に挙げたようにテーブルはEWB形式のマークアップなので本文に挿入することが可能なはずですが、別ファイルに分けて//f<数字>
や//t<数字>
といったキャプション定義をしている箇所が呼び出しを行います。
EWB-Shelfを起動し、コンテンツ登録を行う際にオプションとしてtex2
をusephy tex2
に……tex2
ってなんだ……? EWBなんもわからん……。多分出力のがバージョン2系ってことなんかな……。
いや2系か? とりあえず書き換えます。次に物理属性エディタpast君を起動します。
本体名に.phy
をつけた名前をコマンドライン引数にするそうです。
キャプション定義した番号がリスト表示され、選択してリターンを押すと
図表の「メニュー画面」、体裁調整ができるようになります。ここで「ファイル」「EPS」「アタリ罫」から選択します。アタリ罫は所謂draft
モードのように、矩形を図表位置に置きます。
ここでの体裁調整はどちらかというとフォーム入力のソレなので、WYSIWYGというワケではないようです。こうしてできた.phyファイルに何が書かれているかというと、入力したパラメータをタブ区切りで
にこの値で突っこむんだろうなという形に変換されて載っています。
here top bottom
がhtb
となっていたりという感じですね。組版トリガでの調整はこの後なので、
\includegraphic
相当の命令のオプション値とfigure
環境のオプション値でどうにもならなかった箇所の修正を入力といった感じのようです。
NEXT
EWB文書ライクなものを書いてみる予定。パース擬きまでは間に合わないんじゃないかなあ。 もしくは索引。
*1:要出典
sphinx.styを読もう
備忘録というか作業中の外部処理装置。 必須環境をTeXLive2017くらいにしてしまうと色々楽なんだよな。 使ってもらって議論するうちにUbuntu16.04のサポートなんてきれそうだし。
\sphinxdeprecationwarning{4}
非推奨機能を使っている場合の警告。TeXのバージョンとの不整合を防ぐのに必要。
パッケージ読み込み
呼んでるパッケージ
- graphicx (画像その他)
- titlesec(notbottomltitles*オプション、まあこのままでもいいか? バージョンにより壊れるので分岐)
- fancyhdr(memoirクラス限定。柱など編集用。うーん)
- amstext (bxamstextへ移行? 2016年からはLaTeXの必須コンポーネント化してるから読明示的に読ませなくてもよい? 数式記述補助)
- textcomp(記号拡張)
- tabulary (表機能拡張。table用スタイル分けるべきか?)
- varwidth (表機能用。)
- sphinx-multicells(表機能用)
- makeidx (索引)
- framed (枠組み用)
- xcolor or color (色)
- fancyvrb (verbatim改造)
- float (図表フローティング拡張)
- wrapfig(周りこみ画像)
- parskip(バージョンにより壊れるので分岐)
- alltt (リテラル表示用等幅表示拡張)
- upquote (リテラル中のシングルクオートを本物へ)
- capt-of フロート要素以外へキャプションをつけられるように
- vspace中でのページブレークの抑制コマンド提供。
- remreset (バージョンによってはLaTeXにとりこまれているのでコマンド有無チェック。カウンタのコントロールリストからの除外を提供?)
- hyperref (kanjiskipのあるなしでオプション分岐してるので直したい)
- atbegshi (日本語endashの挙動などに使っているのでpxjahyperに変更?)
- sphinxhighlight (pygmentsでのハイライト用。中身によってはmintでもいいのでは)
- kvoptions (パッケージ補助)
table系定義
- カラムタイプ
\X
と\Y
- カラムタイプ
T
値はJ
マルチカラムでのtabularyのバグに由来するとのことなのでバージョンによっては省ける? 要調査
\sphinxtablepre
とりあえず0でおいてある\sphinxtablepost
値は\medskipamount
dim値。ユーザによる調整用?
\sphinxbelowcaptionspace{.5\sphinxbaselineskip}
キャプション位置がtopの場合のテーブルとのアキ テーブルまたはリテラルブロック用\sphinxbaselineskip
longtable内でbaselineskipが0になるので作成とある。基本はbaselineskipと同値
。theme作成時にややこしくなりそう- \sphinxatlongtablestart vskipと上のtablepreでのテーブル位置補正。llongtableのskipは0にしてsphinx側の値のみを使わせる形。longtableはlongtableのskipのためにbaselineskipきかないようにしたんだろうし単純化できないものか。
\sphinxthelongtablecaptionisattop
captionパッケージとの互換とのこと。\sphinxlongtablecapskipadjust
longtable時のcaption位置をsphinx的に正確にする\sphinxatlongtableend
A longtable does not issue `\@nobreakfalse` resulting in inconsistent spacing · Issue #173 · latex3/latex2e · GitHub 対策がついとる。アトアキ。sphinxtablepostの値を利用\sphinxattablestart
longtableでない場合\sphinxattableend
用意したもののsphinxatlongtableendの値ぶちこんでる\sphinxcapstartof
図表へのref時の位置を良い感じにするため\sphinxthecaptionisattop
\sphinxthecaptionisatbottom
captionパッケージ互換。captionパッケージがあれば調整、なければ無\sphinxtablecapwidth
longtableの幅。\sphinxcaption
上の値を使ってlongtableとtabularのキャプション幅をそろえる
EWBとpTeXのフォントの話
この記事はEWBアドベントカレンダー2019の8日目の記事です。
2019-12-09追記:
ツッコミ待ちらしいが,実際指摘対象になるような記述がない.ちょっと気になったのは
— ワトソン (@wtsnjp) 2019年12月8日
- NFSS は TeX ではなく LaTeX のフォント管理機構(緑の本によると TeX 自身には別の管理機構がある)
- 「短縮記法」を指して NFSS と呼んでいる事例は見たことがない#TeXLaTeXhttps://t.co/vAt3Rocq61
「NFSSファミリ名にやたらと短い名前を使う」
— 某ZR(ざんねん🙃) (@zr_tex8r) 2019年12月8日
理由は
「TFMのためのBerry規則のファミリ名をそのまま流用したから」
であって(「具体例」はまさにその事例)、そして
「Berry規則のファミリ名にやたらと短い名前を使う」
理由は
「昔のファイル名の長さ制限が厳しい」
から。#TeX https://t.co/Sg3UvmDc6D
ということで、NFSSはLaTeXのフォント管理機構で記法はBerry則に沿ったもの、ということで修正します。
pTeXのフォントまわり
私のように、自我を確立したときにはLiveがあったような世代だと(誇張)、 出力はPDFでフォントは全て埋め込まれているのが当然と思いがちですが、 日本語フォントは印刷時埋め込みであった頃の気持ちを想像する必要があります。
PSファイル(もしくはPDF)に出力する際、所持していないフォントについてはフォント指定のみして 実際のフォントは印刷機で引っ張ってもらうわけです。現代の端末埋め込みPDFビューアで文字が読めないときは、このフォントがない場合の代替でのフォント表示機能が無いケースがあります。 PDFビューアを作るのはPDFを作るより難しいので仕方無いですね。ただしKindleオメーは頑張れや。
EWBのユーザ側では体裁ファイル入力に各パラメータを打ち込むだけなので難しいことはないのですが (後日予定)、バックエンドというかクラスファイルでゴリゴリが動いていて この話をしないとどうしようもありません。
正直分かりが得られていないのでツッコミ待ちの部分もあります。
まずは関連用語から。
NFSS
でフォントを取り扱う際の管理機構です。名前の記法はBerry則に沿ったもの、ということです。 ランポート本にはフォント関連の詳細については「ローカルガイドを読め」くらいしか書いてなかったですね。
ということで、
zrbabbler.hatenablog.com (2019年12月09日閲覧)
例えば「日本語横書き用Ryumin-Light」だとJY1/rmn/l/n
となります。Ryumin
だから
rmn
ね、といった感じになるので、初学者にかなり厳しいつくりな気がする……。
名前空間は何語フォントタイプかということで多少分けられるしフォント名の箇所も多少長くなっても
問題無いものの、基本的に有名フォント以外の選択肢が無い時代の産物という印象を感じます。
が把握している(仮想)フォントを呼び出したりする際に使います。
VF
バーチャルフォント(VF)、混植に際して多くの無邪気な若者を沈めてきた関門ですね。 「仮想フォント」というときはTFMとVFの組を指します多分。
TFMから引っ張ったフォント情報をに渡す際の橋渡しが役割のハズ。
概略については
あたりが良いのではないでしょうか。
TFMとJFM
フォントメトリクスとその日本語拡張版です。がフォントの情報を読む際は基本的にここから読み込みます。バイナリ形式なので直接弄ることは推奨されません。
PLとJPL
「TFM、JFMの持つプロパティの視覚化」と以下のサイトであります。ここからTFM、JFMを生成できる、ハズ。
EWBの命令
まあ用語解説で分かる通り面倒臭そう、ということでEWBはよく使うフォントについてはのフォント設定を プリセットで設定を用意してくれています。標準にプラスする形だと思います、多分。 現在ではLiveでを入れたら 入ってくる中に含まれるものもあるでしょう。
# # 体裁入力ファイル # ... 基本組 書体 Ryumin-Light # 和文書体 変形 正体 # 指定項目: # 正 体 / か な / # 長 体 1/ 長 体 2/ 長 体 3/ 長 体 4/ # 平 体 1/ 平 体 2/ 平 体 3/ 平 体 4/ # 斜 体 1/ 斜 体 2/ 斜 体 3 級数 13Q # 単 位 : Q/pt 字送り 13 歯 # 単 位 : 歯 /pt/mm 強調書体 GothicBBB-Medium #和文書体 強調変形 正体 # 指定項目 : # 正 体 / か な / # 長 体 1/ 長 体 2/ 長 体 3/ 長 体 4/ # 平 体 1/ 平 体 2/ 平 体 3/ 平 体 4/ # 斜 体 1/ 斜 体 2/ 斜 体 3 強調級数 13Q # 単 位 : Q/pt 強調字送り 13 歯 # 単 位 : 歯 /pt/mm 欧文書体 PCTimes-Roman # 欧文書体 欧文級数 13Q # 単 位 : Q/pt 欧文ベー ス ラ イ ン 0.03 字 欧文強調書体 PCHelvetica # 欧文書体 ... 基本組終り ...
コピペに失敗したので、上の体裁入力がEWB-Shelfのパース可能なものかは分かりませんが、概ね日本語で設定ができます。
体裁入力で入れたフォントのパラメータは、に入るときは 例えば次のような命令になります。
\DeclareCompositFont{honmon}[0.00,0.00,0.00,1.00]{13.00Q}[13.00H]{JY1/rmn/l/n}[13.00Q]{JE1/rmn/l/n}[0.000zh]
体裁入力ファイルでの入力がどういったものであるかは都合上本日は省きますが、日本語のフォントサイズ・フォント、従属欧文のサイズ・フォント、ベースラインシフトなどの設定が書かれています。
ここで取り出しましたるはDVDメディアに入ったEWB、からewb_baseのスタイルファイル。 これewb2latex.clsと違ってハンドブックのソースには入らないEWB本体付属のスタイルファイルなんで、流石に動作を予想するのは無理があるので、見ます。
% ewbbase3_3.sty \def\DeclareCompositFont#1{% \@ifnextchar[{\@newcomposit{#1}}% {\@newcomposit{#1}[]}} \def\@newcomposit#1[#2]#3{% \@ifnextchar[{\i@newcomposit{#1}[#2]{#3}}% {\i@newcomposit{#1}[#2]{#3}[#3]}} \def\i@newcomposit#1[#2]#3[#4]#5{% \@ifnextchar[{\ii@newcomposit{#1}[#2]{#3}[#4]{#5}}% {\ii@newcomposit{#1}[#2]{#3}[#4]{#5}[#3]}} \def\ii@newcomposit#1[#2]#3[#4]#5[#6]#7{% \@ifnextchar[{\iii@newcomposit{#1}[#2]{#3}[#4]{#5}[#6]{#7}}% {\iii@newcomposit{#1}[#2]{#3}[#4]{#5}[#6]{#7}[\z@]}} \def\iii@newcomposit#1[#2]#3[#4]#5[#6]#7[#8]{% \expandafter\ewb@ifdefinable\csname cf@@#1\endcsname{}% \expandafter\ewb@definefont\csname cfj@#1\endcsname #5/#3\@nil\relax \expandafter\ewb@definefont\csname cfe@#1\endcsname #7/#6\@nil\relax \global\@namedef{cf@@#1}{% \def\cf@curj{#5}\def\cf@jsize{#3}% \def\cf@cure{#7}\def\cf@esize{#6}% \fontsize{#6}{\baselineskip}% \@nameuse{cfj@#1}\@nameuse{cfe@#1}% \hokuri=#4\relax \iftdir\tbaselineshift=#8\else\ybaselineshift=#8\fi \if#2\relax\relax\else\def\cf@color{#2}\ewbcolor{#2}\fi }} \def\ewb@definefont#1#2/#3/#4/#5/#6\@nil{% \expandafter\gdef\noexpand #1{% \DeclareFixedFont{#1}{#2}{#3}{#4}{#5}{#6}% #1}% }
という訳で、最終的?に\DeclareFixedFont
を使っています。
ベースラインシフトや縦・横での動作の違いも入っていますね(\iftdir\tbaselineshift=#8else\ybaselineshift=#8\fi
)。
体裁入力ファイルで常にフルのパラメータを入れなくても対応できるようになっている、 という理解でいいんでしょうか。で書くのとEWBからのコンバート時に 補完するのとどっちが楽かは難しいですが、側で持っていればギリギリの 調整が利くということなんでしょうか。
\DeclareFixedFont {<cmd>} {<ENC>} {<family>} {<series>} {<shape>} {<size>}
に渡されるとき、上の体裁ファイルはおおよそ以下の形と推測され
\DeclareFixedFont
は改修版です。
初期(1995)は和文フォントの定義はできなかったようです。
honmon
とあるように、各編集トリガ箇所でのフォント設定はそれぞれ独立に設定できます。
キモの部分は、これ.texじゃなくてewb2latex.clsというクラスファイルの中身として出力されるというところでしょうか。
Next
小組みもしくはテーブルあたりですかね。
明日は@hid_alma1026さんです。
組版トリガ
この記事はEWB アドベントカレンダー2019 の7日目の記事です。
組版トリガの書式
組版トリガは組版者が使うことを想定したマークアップです。基本的に関数っぽい書式になります。 ものによってはが透けて見えますが、 基本的にはの命令に全対応するわけではなく、書籍執筆で必要になるものを用意しています。
@@<文字列>()
例外的に、ブロック的に宣言する要素の終了位置を示す@@end
はパーレンを後ろに取りません。取ればいいのに。
改行
軽量マークアップとして見ると改行が2種類あるのは珍しいですね。EWBは書籍用マークアップであって、「軽量マークアップだ」と言ったわけではないので、比べるべき場所ではないのかもしれませんが。
@@break()
と@@hbreak()
では改行後の動作が異なります。前者は左右に広げ、後者は左揃えです。
@@break()
のオプションじゃあ駄目だったんでしょうか。気になりポイントですね。
@@break() @@hbreak()
改行の抑制
のテクニックである、mbox
による改行抑制がEWBでも可能です。トリガ名はなんと
@@mbox()
です! まあ組版担当はの分かり手でしょうからね。
@@mbox()
から開始し、@@end
で終了します。()
の中に要素を入れる訳ではないので注意して書きましょうね。
@@mbox() ... @@end
改ページ
パブリッシャーさん! 引数を取るトリガですよ! 引数!
動作がこの2つどう違うのか、ハンドブックだとよくわかりません。 一応後者は「白ページをつくる」トリガなのですが、書籍のことなんもわからんな。
@@clearpage(<数字>) @@siropage(<数字>)
スペースの調整
縦方向、横方向のスペース。魔の命令ですね。使える単位が「mm
」「H
(歯)」「L
(行)(vspace専用)」「W
(字)(hspace専用)」なのは地味に嬉しい人が多いのでは。
@@vspace(<dim>) @@hspace(<dim>)
揃え
揃え。それ以外に書きようがない。
@@left() @@end @@center() @@end @@right() @@end
字下げ
インデント幅は字数で1
〜9
までの指定が可能。dedentはないです。
鉤括弧はsedで対応していたようなので、それ以外の用途ですね。
@@jisage(<数字>) @@end
表組前後のアキ調整
トリガ名が命名的にはちょっと分かりづらいですね。
``ewb @@lineheight(<前アキdim>,<後アキdim>)
### NEXT 明日はフォント周りの話の予定。正直これが一番キッツいので、挫けたら別の話題です。 テーブル組の話とかもまだしてないし。
編集トリガ
この記事はEWB アドベントカレンダー2019 の6日目です。 今日から数回はドキュメントフォーマットとしてEWBをみていきます。
編集トリガ
著者、あるいは編集者が使うことを想定したマークアップが「編集トリガ」です。 この「トリガ」、「triger」の表記のようです。
基本的に編集トリガは「//
」で開始します。初めて知ったときに意外だったのは
インラインとブロックのプレフィックスに差がないことですね。Re:VIEWでは違うので、
EWB由来で違うのかと思ってたんですが。より詳細な比較は12日とかの記事でやれたらいいな。
以下、<文字列>
は基本的に任意(デリミタ以外)とします。
インライン
Re:VIEWでは@<<命令文字列>>{...}
のように書くトリガですね。本文中で使います。
インラインでオプションが入ることもないようです。
...//<命令文字列>{ ... }...
ブロック
ブロックと私が分類しましたが、表現する際に改段落が必要なものとは限りません。
//<文字列>[]{\n //<文字列>}\n 閉じる方は省略した記法が可能です。Re:VIWWのブロックと同じ形になりますね。
//<命令文字列>[<オプション文字列>]{\n
//}\n
見出しなど、要素をネストしないものも便宜上こちらに書きます。
//<命令文字列>
### 標準編集トリガ抜き出し 標準で用意されているトリガです。まあ動作自体は上書きできますが、基本的な文書を作成するだけなら拡張をせずとも綺麗にマークアップが可能ということです。 EWBハンドブックに載っているのでそちらを参照いただければ大体事足りるので、 一般的?な軽量マークアップと比較して変わった書き方のものを中心に締切時間まで書いていきます。 テーブルは後日に回します。 #### 見出し 変わってるという程ではないですが、見出しの記法であっても編集トリガのプレフィックスがつくんだという地味な感動がありますね。一貫性がある……。
//i <文字列> \n
//ii <文字列> \n
//iii <文字列> \n
#### 数字つきトリガ 数字の個数の上限は書き換え可能だそうですが、なんというか突然書籍出版との妥協点を見せつけられた気分になりますね。一般的な軽量マークアップであれば、オプション(必須)で指定しそうな箇所です。図表のリストといったものを出力する都合上、ビルド時に数字が自動で出るより決め打ちでいきたかったのかもしれません。 上はキートップです。次は図表の参照、定義に使います。オプションの`-<英数字>`は枝番号を指定できます。 1番下は索引のマークです。実体は索引エディタで記述するそうです。 これによってEWB文書は綺麗に保てそうですね。各種索引系のツールを使った人は 分かるかと思いますが生で書くと見た目がヤバいことになりがちなので。
//key<数字>{
//key<数字>}
//f<数字>[-<英数字>] //f<数字>[-<英数字>] <文字列>
//in<数字>
#### 区切りトリガ(トリガ内) 箇条書きリストやキートップトリガの内部で、区切り文字として使います。 言われれば気持ちは分かるといった感じで、0から開発するときには中々考えつかないんじゃないかな。
//|
#### 連数字トリガ plextでお世話になった方も多いであろう`\rensuji`が透けて見える「縦中横」用の命令です。
//suji{
//suji}
#### 箇条書きトリガ `kl`は箇条書きレイアウトに突入することを表わします。 箇条書き最初の記号は`・`や`(1)`のように書いてあったりします。
//kl{
//kl}
#### 脚注 `ky`。そっか。 参照と定義部が同じ文字列の命令が多いように見えるのも特徴かもしれませんね。 上から定義部、参照部、脚注文字列です。
//ky{
//ky}
//ky<数字>
//ky<数字> <文字列>
実際に用いる際は以下のような形ですね。
...である//ky1。EWB//ky2 では...
//ky{ //ky1 脚注文
//ky2 EWBはアスキーが…… //}
#### LaTeXトリガ [tex:\LaTeX{}]文字列がぶっこめます。が、組版を壊すようなことを書くのは止めましょう。
//LaTeX{
//LaTeX}
#### EWBバナー なんと、EWBのバナーが出力されます! 便利!
//ABOUTEWB