全体表示

[ リスト ]

これは「TeX & LaTeX Advent Caleandar 2018」 7日目の記事です。6日目はuwabamiさんの「毎度の TeX on Debian 的な話」です。

LuaTeXとは関係ないです。普段TeXを使うときにも,何も役に立たないです。

VFやベースライン補正,JFMなどは普段は全く意識していないですが,それぞれに経緯があることと,それを受けて今の環境になっていることを振り返ってみました。

SNSやコミュニティに参加していないので,もしかしたら一通り出尽くした話かもしれません。

TeXはASCII pTeX


これは半分ネタというか,習性です。

ずっとASCII pTeX自体をソースからコンパイルして使っています。Sierraでもコンパイルは通りましたが,現状でもkpathseaの関数がstdio.hとコンフリクトしたり,そのうち自分レベルでは対処できる限界が来そうな予感。まだYosemiteを使っているので,Sierra以降についてはコンパイルできるか分かりません。

個人的にはTeX Liveの最新のpTeXのみ独立インストールできたらいいのになぁと思います。

最近,dviconcatが欲しくなりソースをダウンロードしましたが,コンパイルできずお手上げ。TeX Liveからバイナリだけ拝借しました。

Homebrewでは「TeX環境のコンパイルは複雑すぎるのでTeX Liveをダウンロードするように」という趣旨のアナウンスが出ますし,私レベルでは到底無理そうです。

いきなり余談


この記事を校正していて思い出しましたが,Adobe製品をmacOSで使うにあたって,doraTeXさんの記事は大変有り難い情報でした。doraTeXさんは神様かと思ったくらいですが,このことを一度はどこかで表明しておきたかったので,ここに書きます。SierraとCS5.5でも問題なく起動できることを確認しました。

この記事がなければmacOSの更新はとっくに諦めていたかもしれません(でも,まだYosemite)。

CS5.5が必要な理由は,いつの頃からかPhotoshopが画像ファイルにXMPと思われる情報を(無条件に)付加するようになったためです。そのおかげで,小さなPNGにとっては釣り合わないくらいの大きなファイルサイズになります。自分はTeXで組んだPDFをPNG化して部材として納品することがあるのですが,極力コンパクトな画像が欲しいので,その目的ではAdobe CCは使いものにならないです。

ついでに言えば,Illustrator EPSもASCII85エンコードされたPrivate dataが大きすぎるし,プレビュー画像は邪魔,XMPも要らないのに。Adobeの方針にどっぷり浸れば恩恵はあるのでしょうが...。

DistillerはおそらくXの次のバージョンからだと思いますが,セキュリティを理由にrunコマンドでPSファイル内から外部のPSファイルやEPSを挿入できなくなっており,これは海外のAdobeコミュニティも覗いてみましたが,回避方法が見つけられないでいます。Acrobatに付属していたrunfileEx.psでしたっけ,あれも用済みということでしょうか。

%!PS-Adobe-3.1 EPSF-3.0
%%HiResBoundingBox: 0 0 16.7245 6.8032
%%BoundingBox: 0 0 17 7
(/Users/xxx/for/bar/bigsize.eps) run

のようなEPSを用意しておけば,重いEPSや繰り返し使うEPSがあってもdvipsは実データを一切読み込まずに済むため,桁違いに高速になります。実データを読み込むのはDistillerの一度きりで十分なはずですが,最近のDistillerではそれは許されないようです。なので,やはりCS5.5を使いたくなります。

これについては,アプローチは異なりますが,GraphicxSPパッケージなどで代替ができるのかもしれません。GraphicxSPはmunepiさんがツイートされているのを見かけて知ったばかりで,パクりです。すみません。

doraTeXさんもmunepiさんもAdvent Caleandarに寄稿される予定ですので,拝読するのを楽しみにしております(勝手にお名前を出してすみません)。

ベースラインとmin10


makejvfにある時期和文のベースライン補正の機能が入りましたが,使っている方はおられますでしょうか。omegaのツールでVFを作るという話も聞きますが,ベースライン補正はどうされているんでしょうか。

補正と言っても文字エントリごとに一律にDOWN命令を入れるだけですが,正体と平体では値が異なるし,どの程度の精度のDOWNを入れるかでわずかながら差が生まれそうです。

OCFの時代からPS和文フォントのheight:depthの比率は88:12,min10などのJFMは85:15で,例えばfboxで文字を囲んだり,picture環境でmakeboxを使ったり,細かい制御をするときにこの誤差は邪魔でした。topskipなど版面設計の根幹にも,指定した値に対して組版結果に誤差が入っていることになります。

88:12という比率(さらに言えば当時のリュウミンの従属欧文がTimesであったこと)がDTP組版の悲劇だという意見を聞き,自分は同意しますが,いまこの比率についてどのように認識されているのでしょうか。

min10はCHARHTが0.777588,CHARDPが0.138855ですが,XHEIGHTが0.916443なのでこれを1.0になるように換算すれば85:15になります。

min10はQUADが0.962216だったり扁平だったり悪口も聞かれますが,あれはTeXを日本語化する中で結果的にそういう値になったのであり,間違っても適当な理由でそうなったわけではありません。自分は偉そうに代弁する立場にありませんが,当時のアスキーの方々の名誉のためにこの機会に敢えて書いておきたいと思います。『日本語テクニカルブックI』を読むとその経緯を垣間見れますが,そういう経緯を知ってか知らずか(著書もある有名な方が)一方的な論調でmin10を非難する記事を見かけました。あの論調はいかがなものかと思います。古い話ですし,その記事がどれほど知られているかは分かりませんが。

著書のある有名な方と言っても,もちろん奥村先生ではありません。

話を戻しますが,min10のheight,depthは綺麗な循環小数になっていることは知られていますでしょうか(「汚い循環小数」があるのかどうかは知りませんが)。設計上の値は(28/33):(5/33)です。つまり,85:15。この比率が日本語TeXの設計思想であるといって良いと思います。もし和文フォントにTeXのベースラインを合わせようとするなら,それは逆で,むしろフォントをTeXに合わせるべきだと思います。VFのベースライン補正はそのためにあります。

という理由で,個人的にベースライン補正は必須だと思っています。makejvfでは補正値を整数で指定するので正体のとき「32」です。0.88−0.848485=0.031515の1,000倍を整数に丸めた値ですが,精度が許すなら小数で補正してもよいと思います。まぁ,気持ちの問題ではありますが。むしろ,makejvfにベースライン補正の機能が追加になった意義のほうが重要だと思います。

min10は扁平ですが,dviwareはJFMのheight,depthを「XHEIGHTを1.0としたとき」の比率として見ればよく(値としては使わない),QUADは1.0であるべきなので.fdファイル等でそうなるように一律に補正をかければ良いです。かつてのjsarticleもそうなっていたと思います。

DVIOUTはJFMのheight,depthを決め打ちで扱っていましたが(実質1種類しかなかったので),ある時期から比率として見るように変更されたはずです(少なくとも決め打ちではなくなった)。実際に試しましたが,縦組のように「横組みでも和文のセンターにベースラインを通したい」というとき(写研流),そのようなJFMを作ればきちんと表示されます。

jis.tfm


組版の観点から言えばjisよりjisnのほうが適しているように思いますが,jisとjisnの違いってどれくらい浸透しているのでしょうか。

と言いつつ,詳細な記憶が曖昧ですが,jisnでは行末に来た中点類は素直に「全角」で印字されるはずです。その他のJFMは,例えば中黒だとして後ろの四分アキ(グルー)は行末揃えのために捨てられるはずです。そのため,欧文を含まない和文だけの文章を組んでもjisn以外では文字が縦に揃わなくなります。

文庫本のような素直な組版で,行末の中点類が全角でないというのは「異常」なので,横組でもそのほうが自然じゃない?というためのjisnであり,「jisはいらなくてjisnだけでいいんじゃない?」という意味も込められたjisnだったはずですが,写研の流儀とも言えます。

好みもありますが,和文組版で行末の中点類を全角でなくす必然性は思い浮かびませんが,どうでしょうか。

実際には,句読点は後ろの二分アキが捨てられて行末揃えになるので,jisnでも必ず文字が縦に揃うわけではない...と思いますが,jisで大量のVFを作ってしまい,戻れることならjisnにしたいくらいです。

相対罫


写研には「相対罫」「罫巻」という機能があり,とても便利なものでした。これに着目した方,あるいは実現しておられる方はいらっしゃいますでしょうか。

随分昔に調べたきりですが,hyperrefパッケージでは,文字(など)へのリンク領域を設定するのに,2点で矩形を定義していたと思います。EPSのBoundingBoxのように左下と右上を指定し,それを結ぶ直線を対角線とみなして領域(矩形)を定める,という感じです。

TeXからはDVI上の座標を得る方法はないため,どうやっているのかと思ったら,計算式を含むPostScriptをspecialで埋め込んでDistillerなど後工程のPostscriptインタプリタに計算させていたと思います。Postscriptではcurrentpointを原点にしてページ上の座標を算出できるので,賢いなぁと思いました。

相対罫もそういう感じで,指定した2点で矩形が定まるので,4辺のうち任意の辺を描画するというのが基本です。記憶点に名前を付け(番号だったかも),必要なら同じ名前で複数箇所記憶しておき,読み出し地点でまとめて罫線を描画するので,setboxで幅を計ったりするのではなく,組版のなりゆきに任せて罫線を描画できるのが利点です。

TeXにもあったらいいのになぁと思います。別にboxで囲めばいいんじゃない?というのも分かりますが,boxは案外不便です。

まず,大きなboxを使うとbaselineskipではなくlineskipが入ります。素直にbaselineskipで組版したいので,うれしくありません。

ページをまたぐ場合はvsplitを使えばよいですが面倒ですし,分割地点がたまたまpenaltyだったというケースも配慮しないと,捨ててほしい空白が残ることがあります。先頭ページではpagetotalなどでページの残り領域を計算しないとだめですし,そこまでするならmulticolパッケージを自前で書くのと変わらなくなってきます。「自然なページ分割」からはどんどん遠ざかりますし,そもそも何をしたかったのか分からなくなります。

また,致命的なのはbox内ではフロートが使えません。例えば,marginparと本文の間に「段間罫」を引くようなデザインにしたいとき,もしboxで組み立てるならmarginpar自体を使うことができなくなります。

boxを使わず,幅も高さも計らず,「ここからここまで」という罫線の引き方ができると,何かと便利だと思うのですが。

自分は写研出身ではありませんが,写研のシステムはよくできていたなぁと,つまみ食いの知識ですらそう思います。XeTeXのように組方向を指定するなどもお手の物でしたし,今でも参考になる知見がいろいろありそうな気がします。ある時期からMicrosoft Wordに「縦中横」という機能が入り,あれも写研由来ですが,TeX界にも写研出身の人が居たらと何か面白い実装が増えたのだろうか,と思います。

相対罫の話ですが,写研の場合,記憶点はページを繰り越せますが,ずっと同じ座標に居続けます。ページが変わったからページ冒頭(版面天)に移動とか,そういう仕様にはなっていません。どうせなら移動してくれたほうが,ページをまたいだ時に罫線が引きやすいと思うのですが。必ず4辺を描画するわけではないので,矩形の右側の縦罫線だけ,とか,それだけでも使い道はあります。

hyperref流のやり方で(しかも1パスで)罫線描画を実現できるのか,あるいは別のspecialを使用するのか,いずれにしろTeX単体では実現できないですね。ただ,specialを使って実現できるなら,boxを使う不便さから解放されるので悪い案ではないと思います。

まとめ


相対罫は上の文章だけだとうまく伝わらないかもしれません。

最後になりますが,まさに「先人」としてTeXに着目し,日本におけるTeXの源流を作ってくださった当時のアスキーの方々,あるいはDVIOUTの開発に携わった方,黎明期(という表現が適切か分かりませんが)にTeXに力を注いでくださった方に,この場を借りてお礼を申し上げたいと思います。

TeX Liveや,今のTeX環境の向上や整備にご尽力されている方,美文書を変わらず改訂し続けておられる奥村先生や黒木さんにも,改めて敬意を表したいと思います。

冒頭に書いたお二方も含め,直接の面識はありませんが,感謝しております。

この記事に

閉じる コメント(0)

コメント投稿

顔アイコン

顔アイコン・表示画像の選択

名前パスワードブログ
絵文字
×
  • オリジナル
  • SoftBank1
  • SoftBank2
  • SoftBank3
  • SoftBank4
  • docomo1
  • docomo2
  • au1
  • au2
  • au3
  • au4
投稿

.


プライバシー -  利用規約 -  メディアステートメント -  ガイドライン -  順守事項 -  ご意見・ご要望 -  ヘルプ・お問い合わせ

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

みんなの更新記事