Hatena::ブログ(Diary)

マクロツイーター このページをアンテナに追加 RSSフィード Twitter

2011-11-23

フィボナッチの日

…ということらしい。

\documentclass[a4paper,dvipdfmx]{article} % ドライバは適宜指定
\usepackage{pict2e,color,type1cm}
\pagestyle{empty}
\definecolor{fibspr}{rgb}{0,0.45,0} % 螺旋の色
\definecolor{fibtxt}{rgb}{0.92,0,0} % 文字の色
\newcommand*{\FibFigFont}{% 文字のフォント指定
  \usefont{OT1}{cmfib}{m}{n}\fontsize{5}{5}\selectfont}
\makeatletter%--------------------------
%
\newcommand*{\FibFigure}{\xxfb@figure}
\newcount\xxfb@n \newcount\xxfb@x \newcount\xxfb@y
\newcount\xxfb@cur \newcount\xxfb@pre \newcount\xxfb@ppre
\newcount\xxfb@xx \newcount\xxfb@yy \newcount\xxfb@dir
\newdimen\xxfb@chrm \newdimen\xxfb@dim
\def\xxfb@cbase{0.75} \def\xxfb@cstep{0.9}
\def\xxfb@figure(#1,#2)(#3,#4)#5#6#7{%
  \begingroup \setlength{\unitlength}{#5}%
    \begin{picture}(#1,#2)(#3,#4)\relax
      \linethickness{#6}\xxfb@n=#7\relax \xxfb@figure@a
  \end{picture}\endgroup}
\def\xxfb@figure@a{%
  \xxfb@x\z@ \xxfb@y\z@ \xxfb@dir\z@
  \xxfb@pre\@ne \xxfb@cur\z@ \xxfb@chrm\xxfb@cbase\p@
  \@whilenum\xxfb@n>\z@\do{\advance\xxfb@n\m@ne
    \xxfb@figure@b}}
\def\xxfb@step@param#1#2#3#4#5#6#7{%
  \advance\xxfb@x#1\advance\xxfb@y#2%
  \xxfb@xx\xxfb@x\advance\xxfb@xx\xxfb@cur
  \xxfb@yy\xxfb@y\advance\xxfb@yy\xxfb@cur
  \let\xxfb@xc#3\let\xxfb@yc#4\def\xxfb@sa{#5}\def\xxfb@ea{#6}%
  \xxfb@chrm\xxfb@cstep\xxfb@chrm\xxfb@dir#7\relax}
\def\xxfb@figure@b{%
  \xxfb@ppre\xxfb@pre \xxfb@pre\xxfb@cur \advance\xxfb@cur\xxfb@ppre
  \ifcase \xxfb@dir \xxfb@step@param
       {\z@}{-\xxfb@cur}{\xxfb@xx}{\xxfb@yy}{180}{270}{1}%
  \or \xxfb@step@param
       {\xxfb@pre}{\z@}{\xxfb@x}{\xxfb@yy}{270}{360}{2}%
  \or \xxfb@step@param
       {-\xxfb@ppre}{\xxfb@pre}{\xxfb@x}{\xxfb@y}{0}{90}{3}%
  \or \xxfb@step@param
       {-\xxfb@cur}{-\xxfb@ppre}{\xxfb@xx}{\xxfb@y}{90}{180}{0}%
  \fi
  \xxfb@dim\p@ \advance\xxfb@dim-\xxfb@chrm
  \edef\xxfb@cr{\strip@pt\xxfb@dim}%
  \xxfb@dim\xxfb@cur\unitlength \advance\xxfb@dim-0.2\unitlength
  \put(\xxfb@x,\xxfb@y){\makebox(\xxfb@cur,\xxfb@cur){%
    \color[rgb]{\xxfb@cr,\xxfb@cr,1}\rule{\xxfb@dim}{\xxfb@dim}}}%
  \put(\xxfb@xc,\xxfb@yc){\color{fibspr}
    \arc[\xxfb@sa,\xxfb@ea]{\xxfb@cur}}%
  \ifnum\xxfb@cur>4
    \put(\xxfb@x,\xxfb@y){\makebox(\xxfb@cur,\xxfb@cur){%
      \color{fibtxt}\FibFigFont \number\xxfb@cur}}%
  \fi}
%
\makeatother%---------------------------
\begin{document}

\begin{center}
\textcolor{fibtxt}{\usefont{OT1}{cmfib}{m}{n}\small
  Happy Fibonacci Day! 11/23}\par
%% \FibFigure(大きさ)(左下座標){単位長}{線幅}{個数}
\FibFigure(89,55)(-24,-40){2pt}{0.4pt}{10}
\end{center}

\end{document}
f:id:zrbabbler:20111123174008p:image

\FibFigure の最後の引数の値(10)を増やすともっと「先」まで描かれるはず。

使用フォントは当然「Computer Modern Roman Fibonacci」(OT1/cmfib)。だけど普通の CM Roman との違いが余りよく解らない。

2011-11-11

1 から始める TeX 〜1TeXの紹介〜

iamjatex パッケージに関しては、その主たる目的は十分に達成されているといえると考えている。しかし作者の発表を見ると、本質ではないものの、主張する特質で、不足があると思われるものが存在する。

わずかな文字数で組版ができる!
壊れているキーがあっても大丈夫! 「わたしのやてふ環境」(山本 宗宏)

少数の種類の文字で入力できる*1というが、この点に関しては大いに改善の余地があることを指摘したい。

発表資料の iamjatex 環境の中の記述を見ると、既におよそ十種もの文字が使われている。この数は確かに多くはないが、例えば Brainfuck 言語が 8 種類の文字からなることを考えると、決して非常に少ないとはいえないと感じる。

これに対しては、「絵を描くことに対してより禁欲的な態度をとり、全て 1 と X で記述する」ことで 2 種まで節減できるという反論があり得よう。この事自体は正しいが、しかしそれは「iamjatex の中の文字種」の話であることを見過ごすべきでない。すなわち、iamjatex 環境を表すための「\begin{document}」の文字、あるいは LaTeX 文書で必然的に存在する「\documentclass」の記述のために更なる文字種の使用が強いられる。これは「わずかな文字種」を目的とした場合には致命的であると言わざるを得ない。

これを根本的に解決する方法として次のものを提案する。

  • LaTeX 言語について、全ての記述を文字〈1〉だけで行う代替的な記法を用いる

例えば「\relax」の場合、その文字列の各文字の ASCII 符号値は順に 92, 114, 101, 108, 97, 120 である。この各々の整数値を所謂「1 進数表記」で表し、改行で区切ることにする。

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

無論、実際には「\documentclass」から始まる LaTeX 文書全体が変換対象となるので、膨大な個数の〈1〉が現れることになる。ともかく、この変換により、任意の命令を含む LaTeX 文書を〈1〉だけで記述できる。

しかし、1 つ問題がある。変換された文書自体(ファイル名を sample.tex とする)は LaTeX の形式に従うものでないので、latex コマンドで処理させることができないのである。これに対しては、独自のフォーマットを用意することで対応する。すなわち、後で紹介する iniTeX 用の初期化ファイル 1tex.ini からフォーマット 1tex.fmt を生成する。これを用いる TeX のコマンドを 1tex として用意する。すると、ファイル sample.tex を以下のように組版できる。この組版結果は「元々の」LaTeX 文書と同一になるように 1tex.ini が設計されている。

1tex sample.tex

この提案方法の欠点を 1 つ挙げると、独自のフォーマットの採用により LaTeX の初歩的な使用者にとっての使用に多少の困難が伴うことである。しかし、iamjatex を用いた解決法が 20 種超の文字を必要とすることと比較すると、95 %以上の効率化に成功している。従って、先に述べた困難を差し引いても、この方法が「わずかな文字種」を志向する者にとって非常に魅力のあるものであることは確かであろう。

なお、この新しいフォーマットによる処理系を「1TeX」(“one-TeX”と読む)と名づけた。ロゴは以下のようにする。*2

f:id:zrbabbler:20111112100158p:image

※ 1TeX は以下の場所で公開している。

(重要な追記) 1TeX ではソースの終端判定を空行(〈1〉のない行)で行っている(空行以降は読まれず、また、空行が見つからずにファイルの終端に達しても処理が終わらない*3)。ソースファイル中に必ず空行が必要となる。


(前の記事の続き)

ZR「というネタを考えてみた」
*「普通の TeX ユーザにフォーマット作成ができる訳がないじゃん」
ZR「…………。」

111111

*「今日は 11 年 11 月 11 日ですね」
ZR「だから何だ?」
*「……何か、11 とか 1 とかにちなんだネタはないんですか?」
ZR「……ない」
*「えーっ、芸人がネタ切れしていてどうするんですかー!」
ZR「…………誰か芸人じゃーっ!?」
*「いえ、その、すみません、コメディアンに訂正させて頂きます…」
ZR「……………………。そうだな、例えば、iamjatex というパッケージを使って、iamjatex 環境の中に 1 をたくさん並べて……」
*「それ、使用済」
ZR「わかってる。まあ、こんな場合の常套手段は虫食い算だな。」

f:id:zrbabbler:20111111030210p:image

*「えー、条件付きなの。なんか杜撰。というか、TeX ネタはないの。例えば、iamjatex を改良してみるとか」
ZR「…………。」

*1:「わずかな文字数」という表現については、誤解を避けるため、「わずかな文字種」というべき(文字数は寧ろ膨大である)であろうが、それは全く瑣末なことである。

*2:会話および文字上での描写の便宜を考慮して、ベル等の鳴り物を伴わない単純なものとした。

*3:技術的な制限による。

2011-11-08

一周年

このブログマクロツイーター」であるが、最初の記事を書いたのが、2010 年 11 月 3 日。気が付けば、開設から 1 年の時が過ぎていた。

といっても、無論誰も祝ってくれる訳がないので、自作自演で、祝いのメッセージを贈ることにしよう ;-)

\documentclass[a4paper]{article}
\usepackage{iamjatex}
\begin{document}
\begin{iamjatex}

7nmmmpX    ,.     ____________             7nmmm2    7yyr7. 
  MMM1    7$Rv   1XZ7772Z2777ZZ             "1XHE     H7    
  MMM1   ,2 $$w  7    1771    7               T7TH   X/     
  MMMl  ,$  j$$ 7     l77l    ~777Z77X7777     T7TH 7       
  MMMl  $++++$$=      1771      XX7     777     7HH7        
  MMM1 2,     $X      177l      777       7      2HHX       
  MMM=+++  m =+++=    1771      777   A   1     2, HHX      
  MMM      M          1771      777xx77       v2    HHXx    
 1MMM     NM          7777      7X7  V7      77      HHHH   
MMMMMMMMMMMF       777X7777771  7X7   !   ,722nn,  n7HHHHNKn
                                7X7       7F                
                                777      7l                 
                             z7X77777777XF                 
\end{iamjatex}
\end{document}

組版結果は各自確かめてみよう。


*「ところで『マクロツイーター』でどういう意味なんですか?」
ZR「知りたい?」
*「うん……」
ZR「じゃあ、一つ質問だが、『Twitter』や『mixiボイス』のようなサービスの一般名称は何か? SNS の機能の一部ではある*1が、特に短文を投稿するサービスのことだ」
*「ん……、昔聞いたことあるな、えーと、そうだ、『マイクロブログ(microblog)』だったはず*2
ZR「でも、今や Twitter を説明する必要なんてない。他社のものも『Twitter のようなサービス』で通じる。で、そういうリアルタイム性の強いものが受け入れられるにつれ、従来のブログは衰退していく」
*「はあ」
ZR「すると、ブログが何であるかを説明しなければならない時が来るだろう。Twitter がマイクロなブログなら、逆に言うと、ブログは何だ?」
*「えーと、マクロ(macro)な Twitter……あっ!」
ZR「うん、ツイッターTwitter)は固有名詞だから、ツイーター(tweeter)に変えた」
*「なんだ、そういうことだったんですか! てっきり、とある言語の全くの訳の分からない不気味なマクロを延々と性懲りもなく呟いていて、こんなの誰の……」
ZR (-_-メ)

*1:でも、Twitter の社長は「TwitterSNS ではない」と言ってましたね。

*2:日本では「ミニブログ」の方が一般的なようだが。

2011-11-07

dviout の欧文フォントの謎が解けた! (3)

前回の続き)

「思想」の話だけで終わるのもアレなので、ここでは実際に「dviout 流」のフォント設定を実践してみる。目的は

timesnr-r "Times New Roman"

のような「素直な dviout の欧文マップ設定」を基にして、LaTeX で新たな欧文フォントを「普通に」使えるようにすることである。なお、dviout の話なので、Windows(特に W32TeX)を前提とする。そういう訳で、例として用いる欧文フォントは、Windows Vista で新しく導入された欧文フォントの一つである「Constantia」とする。このファミリについては Berry 命名規則のファミリ名「jk4」が与えられている。*1ここでは Regular シェープのみを扱う。このフォントのファイルは C:\windows\fonts\constan.ttf にある。

なお、以下の作業で用いるデータ(.enc ファイル等)をまとめて奥底に置いておく。

TTNFSS の方法を踏襲する

まずは、TTNFSS が用いている方法をそのまま(「名前の濫用」も含めて)実行することにする。すなわち、「dviout 流の 8r」である Windows-1252 を原エンコーディングとし、「dviout 流」の T1 エンコーディングを VF で実現するという方法である。なお、NFSS のファミリ名として wconstan1 を用いる。

これを新たなフォント適用する場合、両者のエンコーディングに対する .enc ファイルが必要であるが、dviout の配布物の中には含まれていないようである。よって、前掲の aencdviout.zip の中に win8r.enc と ecwin.enc を再現したものを含めた。この win8r.enc は基本的には Windows-1252 であるが、TTNFSS の TFM の実態と合わせて、「〈Ž〉(0x8E)〈ž〉(0x9E) を省く*2」「TeX に不要な文字(space (0x20) や soft-hyphen (0xAD) 等)を省く」という変更を加えている。ecwin.enc は前回に示した winenc.sty から導出したものである。

Berry 命名規則に従うと、「dviout 流 8r」のフォントTFM 名は jk4r8r、「dviout 流 T1」のフォントは jk4r8t となる。従って、TFM/VF 生成のコマンドは以下のようになる。*3

ttf2tfm constan.ttf -p win8r.enc -t ecwin.enc -v jk4r8t jk4r8r
vptovf jk4r8t

dviout のマップ行で指定するのは、原エンコーディングの方、つまり jk4r8r である。

jk4r8r "Constantia"

フォント定義ファイル(.fd ファイル)は通常の T1 エンコーディングの場合と全く同様に記述する。

[t1wconstan1.fd]
\DeclareFontFamily{T1}{wconstan1}{}
\DeclareFontShape{T1}{wconstan1}{m}{n}{<->jk4r8t}{}

これらのファイルを適切に配置すれば設定は完了である。以下にテスト用の LaTeX 文書を示す。「dviout 流の T1」を使うので winenc パッケージの読込が必要になることに注意。

[test-wconstan1.tex]
\documentclass[a4paper]{article}
\usepackage{textcomp}
\usepackage{winenc} % T1 の定義を修正する!
\begin{document}
% T1/wconstan1(実際は「TTNFSS的T1」)に切替
\usefont{T1}{wconstan1}{m}{n}
Ich m\"ochte s\"u{\ss}eren K\"ase.
  % なぜか ttf2tfm が /Euro を拾ってくれない...
\$1 = \texteuro 4.2 = \textyen 53 \par
``Macros are pass\'e --- it's so mid-20th-century!'' \par
% CP1252 の範囲を超えるので一部化ける
R\'ownie dobrze mog{\l}oby to by\'c po chi\'nsku. \par
% 本物の T1 エンコーディングの使用には影響しない.
\usefont{T1}{lmr}{m}{n} % T1 の Latin Modern Roman
R\'ownie dobrze mog{\l}oby to by\'c po chi\'nsku. \par % 正常出力
% しかし textcomp とは衝突する
\$1 = \texteuro 4.2 = \textyen 53 \par
\end{document}
f:id:zrbabbler:20111108030518p:image

この出力結果を見て解るように、winenc を読んだ後でも「本物の T1」を用いた出力は正常に行える。しかし、textcomp パッケージ(TS1 エンコーディング)とは衝突してしまう。

dviout 流」を再解釈してみる

先に見た衝突は、勿論、本来 T1 でないものを T1 として扱ったところから来ている。このような細かい齟齬を別にしても、現代的な TeX システムでは「普通の」8r や T1 が厳然と存在することは否めず、結局のところ、独自の解釈は「同じ名前をもつ別のものの存在」を生み出してしまい望ましいものではない。従って、この話の締めくくりとして、「dviout 流」を継承しつつ(だから先の「単純なマップ行」が通用する)、「普通の」ものとの矛盾が生じない方法を模索して見る。

まず、「dviout の 8r」についてだが、これは表(LaTeX)から見えないので 8r と呼ばれる必然性がない。だから素直に「Windows-1252」を表す名前を用いればよい。fontname の資料を見ると、「8w」が Windows-1252(WinANSI)を指すとみて間違いない。従って、TFMエンコーディング識別子も 8w とすればよいであろう。なお、折角新しい方式を考えているのだから、win8r.enc で削られた 〈Ž〉〈ž〉 も含める(現在の Windows-1252 に合わせる)こととし、この変更を行ったエンコーディングを bx-8w.enc に記した。

より大きな問題が「dviout の T1」である。「T1」のままでは不適当なので、このエンコーディングを使うならば、TFM と NFSS のエンコーディング名を別に与えることになるだろう。ただ、そうしてもそれが dviout 独自の産物であることに難がある。ところが、実は「dviout の T1」と同様の考えをもち、かつ TeX コミュニティにもっと受け入れられているエンコーディングが存在する――それは LY1 エンコーディングである。これも Windows-1252 の文字セットをもつフォントを可能な限り「効率的に」用いることを目的として設計されている。従って、私は、独自の winenc パッケージの代わりに LY1 エンコーディングを用いることが、「dviout 流」のより筋のよい実現方法だと考える。そこで、LY1 エンコーディングの .enc ファイル bx-ly1.enc を用意した。*4

この考えに従った方法は、「Windows-1252 を原エンコーディングとした『8w』*5の名前をもつ TFM を作り、LY1 エンコーディングをそれを参照する VF で実現する」ということになる。先の場合と類似の手順になるので、簡単に手順のみを示す。NFSS ファミリ名を wconstan2 とし、TFM 名に ZR 命名規則を用いるものとする。*6

[TFM 生成コマンド]
ttf2tfm constan.ttf -p bx-8w.enc -t bx-ly1.enc -v wconstan2-r-ly1 wconstan2-r-8w
vptovf wconstan2-r-ly1
[dviout のマップ行]
wconstan2-r-8w "Constantia"
[ly1wconstan2.fd]
\DeclareFontFamily{LY1}{wconstan2}{}
\DeclareFontShape{LY1}{wconstan2}{m}{n}{<->wconstan2-r-ly1}{}
[test-wconstan1.tex](テスト用文書)
\documentclass[a4paper]{article}
\usepackage[LY1,OT1]{fontenc}
\usepackage{textcomp}
\begin{document}
% LY1/wconstan2 に切替
\usefont{LY1}{wconstan2}{m}{n}
Ich m\"ochte s\"u{\ss}eren K\"ase.
  % やっぱり ttf2tfm が /Euro を拾ってくれない...
\$1 = \texteuro 4.2 = \textyen 53 \par
  % TeX-ligature のテスト
``Macros are pass\'e --- it's so mid-20th-century!'' \par
% \l は CP1252 にないので落ちる. \'c や \'n は合成になる.
R\'ownie dobrze mog{\l}oby to by\'c po chi\'nsku. \par
% もちろんこれも大丈夫
\usefont{T1}{lmr}{m}{n} % T1 の Latin Modern Roman
R\'ownie dobrze mog{\l}oby to by\'c po chi\'nsku. \par % 正常出力
% 今度は textcomp も大丈夫
\$1 = \texteuro 4.2 = \textyen 53 \par % 正常出力
\end{document}
f:id:zrbabbler:20111108030517p:image

*1:先頭の「j」がベンダ名(Microsoft)を表す。

*2:恐らく、TTNFSS が作られた当時の Windows-1252 にはこれらの文字が無かったのだと思われる。

*3:jk4r8r.tfm、jk4r8t.{tfm,vf,vpl} が生成される。VPL ファイルは TFM/VF への変換が終われば消して構わない。

*4:ここでは述べないが、fontname パッケージの texnansi.enc や texnansx.enc はそれぞれ欠点があるので、この bx-ly1.enc を用いたほうがよい。

*5:「8w」は Berry 規則の場合だが、それ以外の場合も、とにかく「TeXBase1」とは異なる「Windows-1252」自体を現す名前であること。

*6:「8r」や「8w」は LaTeX で直接用いられないので NFSS 名がない。そこで、ZR 規則のエンコーディング識別子はそのまま「8r」「8w」とする。

2011-11-06

dviout の欧文フォントの謎が解けた! (2)

前回の続き)

実は以下の資料・文献の中に答えが含まれている。(dvioutインストールディレクトリを $DVIOUT であらわす。)

  1. $DVIOUT/map/ttfonts.map の冒頭にあるコメントおよびそこで直接(%input を介してでなく)定義されたマップ行。
  2. $DVIOUT/FONT/winttf.lzh に含まれる「TTNFSS パッケージ」。
  3. そして、トニイ氏のサイトの「TeX Q and A」のページの末尾にある「dviout for Windows がフォントを表示する仕組み」の文書。1 と 2 についての解説もこの文書にあるので、要するにこれを読めばよい。

この中の 2.2.2 節に「通常の Windows 欧文 TrueType フォントTeX で使う方法」が述べられているが、これが探し求めていた「想定の方法」であると確信している。結果的には前回に述べた「1. VF 利用」に相当する訳だが、もっと深い事情がある。

TeX の欧文フォントの扱いに詳しい人なら、LaTeX 標準の PSNFSS バンドル(helvet パッケージ等)における TFM の構成について知っているであろう。すなわち、Times-Roman 等の Type1 フォントを「TeXBase1 エンコーディング(8r エンコーディング*1)」で再エンコードした TFM (ptmr8r)を生成し、LaTeX で用いる OT1(ptmr7t)、T1(ptmr8t)等のエンコーディングTFM は 8r の TFM を参照する VF として実現する、というものである。これの詳細については、件の質問スレッドの中で挙げられている ut 氏の「LaTeX のフォントの話」を参照されたい。*2以下では、「TeXBase1」を介した設定方法を知っているという前提で話を進める。

そういう前提で、2.2.2 節の説明を読むと、まさにその「TeXBase1(8r)の原エンコーディングTFM を介在させて T1(8t)の LaTeX エンコーディングTFM を VF として構成する」手順を述べているように見える。($DVIOUT/map/ttfonts.map のコメントについても同様である。)しかし、細部(特に脚注)まで見てみると、何やら様子が異なることが判る。例えば、本文で「Windowsエンコーディング “8r” に変換します」とあり、そこに付された脚注には

“8r” の “8” は 8bit を表し、 “r” は “raw” を表します。raw(無加工)とは、この場合 TTNFSS の ‘win8r.enc’ で定義されている Windowsエンコーディングを表しますPSNFSS の文脈では、Adobeエンコーディングを指すことが多いです。

とある。つまり、TTNFSS パッケージに含まれる TFM の「8r」は本当は「8r (= TeXBase1 *3)」ではなく Windows-1252 のことを最初から意図しているという意外な事実が判る。*4さらに、件の TTNFSS パッケージ($DVIOUT/FONT/winttf.lzh の中身)の texmf/tex/latex/ttnfss/winenc.sty を見ると、更なる驚愕の事実を目の当たりにすることになる。

[winenc.sty 121 行目]
\DeclareTextSymbol{\textyen}{T1}{'203}
\DeclareTextSymbol{\textcopyright}{T1}{'207}
\DeclareTextSymbol{\textregistered}{T1}{'206}
\DeclareTextSymbol{\P}{T1}{'211}
\DeclareTextSymbol{\textbullet}{T1}{'215}

なんと、T1 エンコーディングの定義を改変している!*5

何故、dviout の開発者はこんな極度に強引とも思える方法を採っているのだろうか。*6例の 2.2.2 節の内容を熟読すると、その意図の一端が感じ取れる気がする。恐らくはこんなことなのであろう。

Windows + TrueType フォントの世界」では「Postscript + Type1 フォントの世界」とは異なる「常識」があるはずで、それならば dviout + TTNFSS は dvips + PSNFSS の方法論を盲従するのでなく、「Windows の常識」に従った方法論を模索するべきである。*7

こう考えると、「8r」や「T1」等の「エンコーディング名の濫用」もその意図を納得できる(容認するかは別の問題だが)。*8

さらには、前回の「可能な方法」の議論の「1. VF 利用」(結果的にこれが正解なのであるが)に書いた次の「不可解な点」も払拭できる。

ただ、この方法は「dviout のための特別な方法」という印象が強い。確かに、この方法で設定したものは他の DVI ウェアでも通用するのであるが、他の DVI ウェアでは全く一般的でない方法(と私はこでまで認識していた)なので、「dviout のためにわざわざ変な方法を採っている」という印象を持っていたのである。

つまり、dviout は敢えて dvips と異なる方法―Postscript の方法―を採ったのであり、その後に登場した DVI ウェアは dvips を踏襲したので、そちらの方法に慣れた視点から見ると dviout が特異に見えるわけだが、果たしてそれも意図されたことであり、「全部同じ方法が採れるべきだ」という考え自体が否定されるべきものであったということである。

ただし、正直なところ、私はこの「思想」に賛成する者ではない。現状の TeX システムの構成は「DVI ウェアの間の差異を軽減する」方向に向かっているし、また実際に DVI ウェアごとに別の手順を採るのは面倒だから、結局「故意に別の方法をとる」のは受け入れ難い。そもそも dviout しか使わないのであれば、「dviout 流」を進むのもいいだろうが、恐らくは dviout のユーザの多くが、PDF 文書を得るために dvipdfmx を併用しているのではないか。そうすると、結局は多数派である「Postscript 流」に従うしかないのではないかと思う。従って、私が自作パッケージで dviout をサポートする場合には、これからも「4. ttf2pk を使う」或いは「2. Unicode SFD + VF」の方法を採ることになるだろう。*9


積年の疑問を解決する手がかりを頂いた 山本和義 氏と ut 氏に深く感謝したい。

そして、最近公開された ut 氏による解説資料を改めて紹介したい。

以前に紹介した eggtoothcroc 氏の資料および私のブログ記事と比べると、かなり体系的に説明されていて、この類の話を「整理した形で」身につけたい人に適していると思う。

(でもまだ続く)

*1Berry 命名規則での識別子が 8r だからこの別名がある。直接 LaTeX で使うエンコーディングでないので NFSS 名はない。

*2:なお、この構成方法は現在でも用いられるとは思うが、「OpenType する件」では敢えて取り上げなかった。一番の理由は、「それを行う必然性がないから」で、ただでさえ複雑な概念理解をさらに無益に複雑化すると判断したからである。

*3:fontname パッケージを見る限り、8r は TeXBase1 という特定のエンコーディングを指すことで間違いないようだ。

*4:なお、当該の文中にある「PSNFSS の文脈の 8r」は当然 TeXBase1 を指すと思われるが、これは「Adobeエンコーディング」ではなく TeX コミュニティが策定したものである。恐らくは AdobeStandard エンコーディングBerry 名識別子 8a; 8r に再エンコードする前の Type1 フォントの既定のエンコーディングは多くの場合これである)と混同していると思われる。

*5\textyen\textcopyright\textregistered 等の「Latin-1 の記号」の多くは T1 でなく TS1 の方に含まれているのであった。

*6TeX の初級者が強引で破壊的な方法を使うことは多いが、もちろん dviout の開発者は決して TeX の初級者ではない。

*7:TTNFSS の開発が始まったであろう 15〜20 年前の状況を前提にしている。

*8:なお、件の質問スレッドの中での議論の中で、私は、「Windows-1252 を近似的に TeXBase1 と見做して処理しようとしているのでないか」という推測を述べた。実際、TeXBase1 自体が Windows-1252 と互換になるように設計されている(8r.enc のコメントを見れば判る)のでこの 2 つは非常に似ている。しかしその後に山本和義 氏から「TTNFSS の 8r は TeXBase1 を意図したものでない」ことの指摘があった。「表示する仕組み」の資料を見れば、この推測は的外れであったことが解る。T1 エンコーディングについても、実際には少し相違があるものを T1 だと思う(そこから生じる齟齬には目をつぶる)ことはよく行われるが、わざわざ T1 の定義の改変まで行っていることを見ると、「TTNFSS 流の T1」―TTNFSS の仕様は dviout のそれに直結しているので「dviout 流の T1」といってもよい気がする―を「正なもの」として認めていたことが推定できる。

*9dviout をサポートする気がもう余りないのだが。

2011-11-05

dviout の欧文フォントの謎が解けた! (1)

今まで、dviout に関してずっと疑問に思ってきたことがあった。それは「欧文の OpenType フォントを使うことための、(開発者が想定している)正しい方法は何なのか」ということである。それが TeX Forum 上のある質問に対する議論を契機にしてようやく理解できたので、(「集い」の記事を休憩にして)ここでまとめておく。

欧文 TFM に対して OpenType フォントを対応させる方法は dviout のヘルプて載っていて特に難しくない。例えば timesnr-r.tfm という TFM に(Windows に標準で入っている)「Times New Roman」を割り当てる場合は、有効なマップファイル*1に以下の記述を書くだけでよい。*2

timesnr-r  "Times New Roman"

しかし、他の DVI ウェアのマップ行の書式と比べてみれば判るが、この中には「エンコーディング」を表す部分がない。*3そして、適当な方法で*4調べると、以下のようなエンコーディングになっていることが判明する。*5

f:id:zrbabbler:20111106040654p:image

これを見ると、0x21〜0xFF の部分は Windows-1252*6 になっている。0x00〜0x20 の部分が異様であるが、これは所謂「remap」が施された TeX 専用の 8 ビットの TrueType フォント(「BaKoMa フォント」等)に対応するための細工であり、*7今回の話とは関係ないのでこれ以上は触れない。基本的に Windows-1252 であるということが大事である。

Windows-1252 というのは無論「非常に有名な」文字コードであるが、(8 ビット欧文)LaTeX におけるフォントエンコーディングとしては全くサポートされていない。(だから「OT1」のような NFSS 名もない。)だから、このままでは非常に扱いづらい。

とすると、一番ありそうな予想は次のものだろう。この「既定エンコーディング」は「TeX 専用 TrueType フォント」を用いるためのもので、「Times New Roman」等の「普通の OpenType フォント(TrueType フォントも含む)」を使う場合は、適切なエンコーディングを指定することが要求されていると。

しかし、実際にはそうはなっていない。少なくとも、dviout は enc ファイルによるエンコーディング指定は全くサポートしていない。その代わり、dviout 独自の「Windows コードページの指定」等が使えるが、8 ビットの(欧文の)コードページの中に LaTeX で普通に用いるようなフォントエンコーディングは存在しない。*8

ではこの仕様の下だと、dviout で「普通の OpenType フォント」を欧文フォントとして用いることは不可能かというとそうではなく、そのための方法は幾らでも考え出せる。だがどれも「想定された方法」とするには不可解な点をもつのである。

  1. VF 利用: とにかく、結果のエンコーディング(前掲の図)は判っているので、それに合わせてエンコーディングファイル(.enc)を作れば TFM は生成できるし、あとは仮想フォント(VF)を通せば「そこにある文字」からなる LaTeXエンコーディングは実現できる。例えば OT1 や LY1 は可能だろうし、グリフ合成を頑張れば T1 も大部分はできそうだ。
    ただ、この方法は「dviout のための特別な方法」という印象が強い。確かに、この方法で設定したものは他の DVI ウェアでも通用するのであるが、他の DVI ウェアでは全く一般的でない方法(と私はこでまで認識していた)なので、「dviout のためにわざわざ変な方法を採っている」という印象を持っていたのである。
  2. Unicode SFD + VF: dviout は .enc ファイルのエンコーディング指定はサポートしないが、実は SFD ファイルはサポートしている。だから、まず Unicode SFD(timesnr-r-u@Unicode@ とか)の TFM を作ると、とにかくフォントにある(BMP の)全文字を出力する手段を得たことになる。だからあとは VF を使えば完全な T1 エンコーディングの設定が作れる。
    これは極めて面倒な方法だから、あまり行いたくない。
  3. 裏技 SFD: SFD ファイルが作れるということは「OpenType する件(SFD 編-7)」で述べた「普通の 8 ビットエンコーディングを SFD で実現する」という「裏技」が使えるということである。
    これが一番簡単なのだが、でもこれが「想定された方法」とはとても思えない。
  4. ttf2pk を使う: ttf2pk の設定を行っておけば、mktexpk でビットマップPK フォント)が生成されるので結果的に dviout でも出力できる。ttf2pk のマップ設定は .enc ファイルもサポートしていて他の DVI ウェア(dvipdfmx 等)と同じ感覚で行える。
    これは至極真っ当な方法だが、これが想定された方法だとすると、「普通の OpenType フォント」を指定する例が dviout のヘルプに書いてある理由が解らない。

だから結局疑問は「何が想定された方法か」に尽きるのである。

実のところ、この疑問を今まで持ち越してきた最大の原因は、「別に解決する必要がなかったから本気で調べなかった」ということだったりする。想定解であろうとなかろうととにかく使えるのだから実用上は困らない。自作のパッケージの欧文 TFM 関連部分で dviout のサポートを行う場合は、実際に上述の方法を用いてきた。*9そして、私自身は dviout は使っていないので、必要以上の興味を持っていなかったのである。

(続く)

*1dviout では既定ではマップファイルは無効になっているので有効化する必要があるが、その手順は eggtoothcroc 氏の資料や後で挙げる資料で説明されている。

*2フォントは「フォント名」で指定する。(WindowsAPI を使用するので。)TrueType フォントの場合はファイル名での指定も可能だが、その場合は内部動作が違うらしい。

*3:例えば dvipdfmx のマップ行は「timesnr-r-t1 ec times.ttf」のような形式で、ここでは ecエンコーディング(ec.enc に書かれたもの)を示している。

*4:例えば、256 文字全部が定義済の TFM を作って、そのフォントで全文字を出力させる TeX 文書をコンパイルして dviout で出力させればよい。メトリックが合わないのでずれて表示されるが、どの文字が出るかは判明する。

*5:この画像自体は dvipdfmx で再現した PDF を変換したもの。

*6:Latin-1 の Microsoft による独自拡張による 8 ビットエンコーディングで、Unicode 以前の英語 Windows の標準の文字コードであった。

*7:0xA1〜0xAA、0xAD〜0xC4 の範囲にあるグリフを 0x00〜0x20、0x7F(通常は制御文字領域である)にコピーしている。

*8:もちろん、入力エンコーディング(inputenc)は、その性質上、種々の Windows コードページをサポートする。例えば、\usepackage[winansi]{inputenc} をプリアンブルに書くとソースの文字コードWindows-1252 にできる。

*9:例えば、PXmika パッケージ(欧文部)では 2 の方法、PXmonja パッケージ(欧文部)では 3 の方法、PXchfon パッケージ(欧文、簡易表示)では 4 の方法を用いている。

2011-11-04

「TeX ユーザの集い 2011」について何か書いてみる (5)

TeX ユーザーの TeX をめざして
――TeX 総合支援ツールとしての KETpic の利用

北原清志 (工学院大学

図入りの数学教材を TeX で簡単に使いたい人は KETpic を使いましょう!

補足してみる
  • 数学の教育において、図を用いることは理解の状況を改善する上で非常に大切だ。言葉だけでは解らなくても、図を見れば「感覚的にわかる」(「アハ体験」的に)ことはよくある。しかし残念ながら、図の入った教材は非常に少ない。その理由は単純に正確な図を作成する手間が非常に大きいからだ。このような状況を改善するのが KETpic の目的である。
なにか書いてみる
  • 毎度おなじみ KETpic。まあ、発表者が絶対的に不足している現状では、こういう存在は有難いものであるはず。
  • KETpic による高度な描画機能は「TeX組版するからといって全部 TeX でやる必要はない」という思想の良い具体例になっている。
  • 最近は「TeX 総合支援ツール」の題目が示す通り、「LaTeX での多少複雑な処理について、KETpic のユーザから見てもっと自然な方法を提供する」という方向を模索しているようにみえる。
  • 高度な描画を目当てに KETpic を使っているユーザは既に CAS の言語について慣れ親しんでいて、多くの場合、それは TeXLaTeX よりも洗練された文法を持っている。だから、「KETpic ユーザである」ことを前提とするなら、その使いやすい文法で記述できた方がよい、という発想が暗黙的にあるのだと思う。
  • layer 環境というのは、CAS とは無関係で純粋に TeX で実装されているようだ。
  • 「本文中のある領域で、要素のレイアウトを完全に自由に決定したい」という場合、標準の LaTeX の場合は picture 環境を用いればよい(グリッド表示はは epic パッケージの \grid 命令を用いる*1)のが定石であるが、これはあまり知られていない気がする。
  • だから専用の環境を用意するというのは妥当なのであるが、そこで従来の picture(や拡張の pict2e)とは全く異なる命令セットを用意するというのは何となく気持ち悪い。*2
  • 「KETpic は tpic special を直書きしているので tpic をサポートしない pdfTeX/LuaTeX では使えない」というのはずっと気になっていたのだが、最近になって、描画に pict2e を使う版が開発されたようだ。
質疑応答
  • Q: MapleMathematica 以外(Maxima 等のフリーの CAS ソフトウェア)への対応は進んでいるのか?
  • A: 現在では、どの機能も全ての対応ソフトウェアで使える。(← という答えだったはず。)
  • それにしても、複数の CAS ソフトウェアへの対応ってどうしているのだろう。「共通化」ができなさそうだけど、一つずつ別箇に行っているのかな。
  • Q: 同じ図に対して「モノクロ」と「カラー」で出力を分けることができるか?
  • A: カラー出力には対応していて、モノクロとの出しわけについては…(←答えが聞き取れず。)
  • color パッケージの monochrome オプションでは対応できないのかな。
  • ある領域で、カラーでは色のベタ塗りでモノクロでは斜線を入れる、とかはどうしよう。
  • Q: emath パッケージの描画機能との違いは何か?
  • emath は図の作成の計算をすべて TeX 上で行う必要がありあまり複雑な(数学的な)図を描くようにはできない。あくまで「TeX だけでできるレベル」のことをサポートするためのものである。

*1:eepic ではなく epic なので tpic special は無関係。実際、overpic パッケージは単に \includegraphics と picture 環境と \grid を組み合わせているだけである。

*2:KETpic 自体は CAS の言語上で記述するので、それと整合させているという訳でもなさそう。

2011-11-03

「TeX ユーザの集い 2011」について何か書いてみる (4)

TeX Live 2011 and some possible extensions

TL2011 の 2010 からの変更点、および管理プログラム tlmgr の予定中の拡張機能について。
〔スライド作成ソフト: pdfLaTeX + beamer〕

補足してみる
  • TeX Live 2010 → 2011 の明確な変更点: (世界的には)なし
  • でも日本人にとっては重要なこと: e-pTeX が入った! platex = e-pTeXLaTeX、eptex = e-pTeX の plain、ptex = ptex の plain (欧文の DVITeX と同じ構成)。
  • upTeX とか updmap の KanjiMap サポートとかも入る予定で現在作業中。
  • tlmgr の現在テスト中の新機能
    • ユーザツリーモード: tlmgr は通常はシステムのツリー($TEXMFDIST 等)を管理するが、システムツリーの更新の権限がないと何もできない。そこで、ユーザツリー($TEXMFHOME 等)を管理対象とするモードを用意する。
    • 複数レポジトリのサポート: 諸般の事情から現在ではメインの TL レポジトリの他に複数のレポジトリ(tlcontrib、tlcritical)が存在しているので、それをサポートする。
何か書いてみる
  • 複数レポジトリの話は、英語が tlmgr の内部処理がよく解らないせいでほとんど理解できなかった。
  • これが使えるとディストリビューションの日本語化対応も楽になるらしいよ。

2011-11-02

「TeX ユーザの集い 2011」について何か書いてみる (3)

LuaTeX-ja の開発

北川弘典 (LuaTeX-ja プロジェクトチーム)

LuaTeX 上の日本語組版パッケージである LuaTeX-ja の現在の開発状況と pTeX との違いについて。
〔スライド作成ソフト: LuaLaTeX-ja + beamer〕

何か書いてみる
  • いやー、順調に進んでますねー。すごいですねー。*1
質疑応答
  • Q: 現状で LuaTeX-ja が非常に遅い(pTeX の 20 倍の時間がかかる)というが、Lua コードをコンパイルすれば改善されるのではないか。(Lua ソースを前もって中間コードにコンパイルして、得られたバイナリファイルを元のソースの代わりに用いるという方法があり、コンパイルにかかる時間を節約できる。)
  • A: ここでいう速度比はスタートアップを含まずに純粋に文書量に比例する部分のことだからコンパイル時間は関係がない。実際には、luaotfload パッケージ(LuaTeX で OpenType を扱うためのライブラリ)と LuaTeX-ja 自身の両方で速度低下が起こっている。LuaTeX-ja を速くする方法はコードの最適化くらいしか考え付かない。
  • まあ、LuaTeX エンジンや luaotfload がもう少し速くなってくれればよいのだがね。
  • Q: (北川さん開発の)e-pTeX の方をもっと発展させる、例えば pdfTeX の機能を取り込むといった予定はもうないのか?
  • A: ないと思ってよい。PDF 出力の方法とかはよく解らない。LuaTeX-ja のアプローチの方がよいと考えている。
  • e-pTeX は、オリジナルの TeX に対する「p- 拡張」と「e- 拡張」の両方を足し合わせて、後は両者の整合性をとる作業(これが大変なのであるが)を行えば済む。これに対して、「pdfpTeX」を作ろうと思うと、今ある「pdf 拡張」と「p- 拡張」だけでは足りず、例えば「CMap の扱い」や「OpenType の処理の改善」などを最初から実装する必要があり、作業量は e-pTeX に比べて格段と多くなる。
  • そもそも pdfpTeX が本当に必要なのか。海外で将来には LuaTeX への移行が進むのは確実で、従って、LuaTeX-ja の開発が必要なのは確かである。(ここで LuaTeX の p- 拡張をするのは馬鹿げている。)一方で、「別に新機能は不要でこれまで通りの pTeX が使えればよい」人も確実にいる。それでは e-pTeX も要らなかったのかというとそうではないという事情がある。私の昨年の発表で述べた通り、「今まで使っていたパッケージがある時から e-TeX を要求するようになる可能性がある」からである。では、同じ理屈で「これまで通りの人」が pdfpTeX を求める日が来るかというとその可能性は低いように思える。その理由は、(意外かも知れないが)「XeTeX があるから」である。つまり、XeTeX は pdfTeX 拡張をもたず、PDF を直接出力しないのである。従って、「パッケージがいつの間にか pdfTeX を要求する」ようになることは(近い将来は)なさそうだ。*2「これまで通りの人」は e-pTeX で十分とすると、pdfpTeX が必要なのはどんな場合だろうか? pdfTeX 特有の機能で、日本人が必要だと思うものがあまり思いつかないのである。
  • ただし、pdfTeX の「PDF とは関係のない(つまりそのまま e-pTeX に持ち込める)機能で便利そうなものは追加する」という考えは妥当である。そして事実、今の e-pTeX は pdfTeX の機能をいくつか取り込んでいる。さて、今どういう状況になっているんだったっけ……。

*1:いや、「集い」の前に一度中身を確認しておきたかったんだが、とある理由でそれができなくなったわけで…。

*2:XeTeX の ML で「XeTeX も obsolete になってしまうのか」という議論を見かけたが……。

2011-11-01

XML 組版と TeX 組版の間の関係

前回取り上げた「電子書籍と Web と XML の組版技術」の講演の中で、「XML と XSL-FO の関係は LaTeX と TeX の関係に似ている」という話があった。これについて自分なりにまとめておく。

この対応関係を理解するには、TeX の処理を

  • マクロプロセッサ(所謂「口」の部分)
  • 組版処理器(所謂「お腹」の部分)

の 2 つに分離して考えるのが妥当である。つまり、入力の TeX 文書(普通は plain TeX や LaTeX の文書であろう)について、TeX マクロを一旦全部展開してプリミティブ命令の列にして、それを「組版処理器」に通して DVI/PDF の出力を得る、と(仮に)考えるのである。無論、実際にはこの 2 つの処理は常に並行して走っているので、実際に「プリミティブの列」を目にすることはないが、敢えて中間出力にこれを含める方が都合がよい。

以上を前提にして、私の考える、XML 組版と TeX 組版の関係は以下のようになる。

f:id:zrbabbler:20111102035024p:image
  • ① は文書の著者(一般的に非技術者)が書くことが想定されている。LaTeX や XHTML のマークアップの直書きはそれほど難しいものではないが、それに困難を感じる場合は、簡易マークアップ(Wiki 記法の類)からの変換も考えられる。なお、目的の文書に特化した独自のマークアップ言語を用意することも可能であるが、そうすると ② での対応の手間が増大する。
  • ② のプログラムはその言語の知識をもつ技術者が作成する。① の文書毎に作成する必要があるが、マークアップとレイアウトの類似度に応じて使い回しができる(全く同じであれば同じものが使える)。ちなみに、XSLT は(チューリング完全な)プログラミング言語であるが、普通の言語とはかなり異なる文法概念と外観を持っている。こんな所も TeX のマクロ言語と通じるところがあるという……。
  • なお、LaTeX の場合、② は LaTeX カーネルと文書クラスと各種パッケージの全てのプログラムに相当する。ちなみに、XML に基づく言語では、「名前空間」を用いて別種の言語を組み込むことができる――例えば、XHTML の中に SVG や MathML を組み込むことができる――が、これは LaTeX でパッケージを読み込んで使用可能な命令(機能)を増やすことと類似性がある。
  • ③ は ① と ② から生成される。人間が書くものではない。断じてない。
  • ④ は言語ではなく純粋にソフトウェアである。主要な XSL-FO の組版エンジンの一覧は発表スライドの 9 ページに掲載されている。
  • ⑤ は元来の TeX では DVI 形式になる。pdfTeX/LuaTeX では PDF 文書が直接出力される。
  • ③ と ⑤ の違い(つまり「AH Formatter は何をするものなのか」)が解り難いかも知れない。PDF や PS(の各ページ)は中にテキストを含みうるが基本的に画像であると考えるとよい(EPS 形式は単一ページの PS 文書に過ぎないが、多くの人は画像形式だと思っているだろう)。つまり、各描画要素やテキスト中の各文字はその絶対位置が既に確定している。③ については、例えば本文の場合、「各ページ内の本文領域の位置とそこに流し込まれる一連の(書式付き)テキスト」が定まっているという状態で、文字の位置はまだ決まっていないのである。つまり、行分割やページ分割の実施は ④ の役割であり、従って、禁則処理や空き調整などの「日本語の組版規則」の実現というのも ④ の重要な目的だということになる。
  • XML 側の ①、②、③ の結びつきは弱い。独自 XML → XSL-FO の変換は XSLT でなくとも他の任意のプログラム言語を用いて行える。独自 XML を XSLT で変換するとしても、変換先を XHTML にしたり(CSS との組合せでブラウザで表示させる)TeX にしたりすることもある(発表スライドでも述べられている)。*1さらにこの変換を XSLT 以外で行うことも可能である。(要するに、適当なプログラミング言語を使えばどんな変換でもできるよ、ということ。)
  • TeX 側の ①→⑤ は実際には一続きの処理なので、そこから途中で抜けることはできない。*2しかし、①→③ の部分には途中から入ることができる。他の文書形式から自動変換する場合、その目的が ⑤ を得ること(① 自体ではない)であれば、①(例えば完全な LaTeX 形式の文書)ではなく ①→③ の途中(つまり「TeX on LaTeX」な文書)を変換先にする方が簡便であることもあるだろう。
  • TeX 側の ③ は TeX でしか扱えない*3が、①(LaTeX 等)は必ずしもそうではないことに注意。無論、LaTeX でも TeX でパッケージを書くことで幾らでも拡張可能(そして大概の場合何らかのパッケージが使われる)なのでそれについて上手くマネージする必要が生じるが、LaTeX2HTML のモデルが一つの解決例になっているであろう。

*1:ただし、XSLT の入力は XML 文書に限られる、だったはず。

*2:例外として、② でテキストを出力することで他形式に変換することが考えられる。

*3:「TeX(言語)を読めるのは TeX(処理系)だけ」という言葉は有名。