Hatena::ブログ(Diary)

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

2017-08-08

TikZ を dviout に対応させる話(ただし画期的)

夏、真っ盛りですね! 夏の日差しを浴び………………(中略)……ゆきだるま☃!

ゆきだるま☃のスゴイ問題解決パワー

さて、本ブログでは以前から、☃のもつ強力な「問題解決能力」に注目してきた。ご存知の通り、TeX は激アレである。このため、LaTeX 上の開発においては、時に「本質的に解決困難な問題」にぶち当たってしまうことがある。こういう時に「出力を☃に変える」という画期的な方策を取ることで、たちどころに解決してしまう、という話である。具体的には、今まで次のような事例を紹介している。

そういうわけで、今年の「ゆきだるま☃の日*1」のネタとして、日本語の LaTeX 界隈において長く未解決のまま残されている問題に手を付けることにする。その問題とは

TikZ(およひ PGF)パッケージの dviout 対応

である。

dviout で TikZ するとアレ

例えば、TikZ で頑張って「三角形の外心」の図を描いたとする。

[triangle1.tex]
% pLaTeX文書
\documentclass[dviout,a4paper]{jsarticle}% dvioutしたいが…
\usepackage{tikz}
\usetikzlibrary{calc}
\colorlet{myblue}{blue!80!black}
\begin{document}

\begin{center}
\begin{tikzpicture}[x=5mm,y=5mm]
  \coordinate (A) at (4,4);
  \coordinate (B) at (0,0);
  \coordinate (C) at (6,0);
  \coordinate (O) at (3,1);
  \draw[myblue!80] (O)--($(A)!.5!(B)$);
  \draw[myblue!80] (O)--($(B)!.5!(C)$);
  \draw[myblue!80] (O)--($(C)!.5!(A)$);
  \draw[myblue!80,overlay] (O) circle[radius=3.16228];
  \fill[myblue] (O) circle[radius=2pt] node[left=2pt] {O};
  \draw[thick] (A)--(B)--(C)--cycle;
  \fill (A) circle[radius=2pt] node[above=2pt] {A};
  \fill (B) circle[radius=2pt] node[left =2pt] {B};
  \fill (C) circle[radius=2pt] node[right=2pt] {C};
\end{tikzpicture}
\end{center}

\end{document}

これは本来は次のような小奇麗な図を出力するはずである。(これは dvipdfmx で*2出力したものである。)

f:id:zrbabbler:20170807235450p:image

しかし周知の通り、TikZ は dviout に対応していない。そのため、前傾の文書コンパイルした結果の triangle1.dvidviout で開くと、まず次のような不吉なエラーダイアログが出現する。

f:id:zrbabbler:20170808001837p:image

ここで[無視]を選ぶと、文書の版面が表示されるが、肝心の図は何だか訳のわからないゴミのようなものに化けてしまっている。無残である。

f:id:zrbabbler:20170808001703p:image
dviout の未対応は本質的な問題

PGF/TIkZ の dviout 対応が一向に進まない最大の原因は「誰もソレをやろうとしないから」であることは間違いない。しかし、実際に PGF の dviout 用のドライバの開発を本気で考え始めると、解決すべき様々な問題が待ち構えていることにすぐに気づくであろう。というのも…………………(省略☃)。

しかし、この数々の困難な問題も、ひとたび☃のパワーを借りればたちまち解決してしまう。賢明な読者の皆さんには、もう答えはお判りであろう。

TikZ の出力を☃に変えればよい!

単純明快である。

scdviout-pgf パッケージ

というわけで、さっそく作ってみた。

使い方はとても簡単で、tikz(あるいは pgf)パッケージを読み込む前に、dvioutドライバオプションを付けて scdviout-pgf パッケージを読み込む。(例によって、ドライバオプションはグローバルに指定してもよい。)

\usepakcage[dviout]{scdviout-pgf}% これを書くだけ!
\usepackage{tikz}

これにより、PGF/TikZ のドライバとして同梱の pgfsys-scdviout.def が指定される。これは dviout 用に実装された(画期的な)ドライバであるため、PGF/TikZ の図が出力されるようになる。

dviout で TikZ できて、しかも素敵!

それでは早速使ってみよう。先ほどの triangle1.tex について、tikz の前に scdviout-pgf を読み込むように変更する。

% pLaTeX文書
\documentclass[dviout,a4paper]{jsarticle}% dvioutしたい!
\usepackage{scdviout-pgf}% これでTikZできる!
\usepackage{tikz}
%……あとはそのまま

なんとこれだけで、さっきは無残に失敗していた dviout での図の表示が、今度は何事もなく完了する。素晴らしい!

f:id:zrbabbler:20170808003855p:image
もっと dviout で TikZ してみる

もう少し頑張って、複数の図を含む文書を作ってみる(文書ソース triangle2.tex)。

f:id:zrbabbler:20170808011521p:image

もし、scdviout-pgf を読まない状態で dviout で見てみると……これはひどい

f:id:zrbabbler:20170808011516p:image

ところが、scdviout-pgf を読み込んだ状態だと……とっても素敵!

f:id:zrbabbler:20170808011513p:image

おめでとうございます!

まとめ

ゆきだるま☃のパワー、恐るべし!

*1:もう既にお馴染みであろうが、念のため補足しておく。毎年 8 月 8 日が「ゆきだるま☃の日」である。

*2:もちろんドライバ指定を dvipdfmx にして。

2017-07-30

LuaTeX が実はそんなに遅くないかも知れない件

LuaTeX といえば「スゴイけど遅い」という印象がある。しかし最近は随分と速くなった感じもしている。というわけで、実際に「日本語文書コンパイル速度の比較」をしてみた。

※詳細についてはこちら。

計測方法

  • テスト用の文書はコレ。BXJS クラスの標準設定を使っていて、A4 で 9 ページある。
    % BXJSクラスを使用してエンジンを自動判定させる.
    \documentclass[autodetect-engine,dvi=dvipdfmx,ja=standard,
      a4paper]{bxjsarticle}
    \usepackage{bxjalipsum} % \jalipsum 命令
    \title{テスト的な何か}
    \author{某ZR}
    \date{コンパイル日付: \today}
    \begin{document}
    \maketitle
    
    \section{初恋}
    \begin{quote}
    \jalipsum{hatsukoi}% 島崎藤村「初恋」
    \end{quote}
    
    \section{草枕}
    \jalipsum{kusamakura}% 夏目漱石「草枕」冒頭13段落
    
    \section{吾輩は猫である}
    \jalipsum{wagahai}% 夏目漱石「吾輩は猫である」冒頭33段落
    
    \end{document}
    
  • (u)pLaTeX については、実際には ptex2pdf を用いて PDF まで変換する際の時間を測る。
  • Windows 10 上の TeX Live 2017 を使用。
  • updmap の jaEmbed の値は ipaex である。つまり、pdfLaTeXはipaex-type1が使われ、他は本物のIPAexフォントが使われる。
  • 3 回予備で実行した後、9 回実行して所要時間を計測、その中間にある 5 回分の平均値を求めた。

実験結果

エンジン所要時間(秒)
pLaTeX(ptex2pdf)2.98
upLaTeX(ptex2pdf)3.24
XeLaTeX4.07
pdfLaTeX4.36
LuaJITLateX6.54
LuaLaTeX7.68

まとめ

LuaLaTeX は pLaTeX/upLaTeX に比べると 2〜2.5 倍くらい遅い。昔は「20 倍くらい遅い」という状態だったので、それと比べると大幅に高速化が行われていることが判る。


おまけ:“重い”パッケージを使った場合

少々画期的な要素(ゆきだるま⛄が回転している、等)を含めるために“重い”パッケージ(TikZ や expl3 等)を読み込む場合は、LuaLaTeX と pLaTeX の所要時間の差が小さくなる。

例えば次の tcfaspin パッケージを利用した文書の場合。

\documentclass[autodetect-engine,dvi=dvipdfmx,ja=standard,
  a4paper]{bxjsarticle}
\usepackage{tcfaspin}
\usepackage{scsnowman}
\begin{document}
私は\scsnowman[muffler=red,hat,arms,snow,scale=1.5]よりも
\faSpin{\scsnowman[muffler=red,hat,arms,snow,scale=1.5]}の
方が好きです。
\end{document}
\end{document}
f:id:zrbabbler:20170730183008g:image

先と同じ要領で計測した所要時間は以下のようになる。

エンジン所要時間(秒)
pLaTeX(ptex2pdf)4.92
upLaTeX(ptex2pdf)5.59
XeLaTeX5.16
pdfLaTeX4.82
LuaJITLateX8.16
LuaLaTeX8.90

2017-07-01

pLaTeX でも源ノ明朝したい話

今もうできること

新しい dvipdfmx(20170318 版以降)では「Unicode 直接アクセス指定」の機能が強化され、それにより従来は面倒であった「AJ1 でない OpenType フォント」への対応が格段に容易になった、という話は既に何度か述べた。

すなわち、最新の TeX Live 2017 では次のようにして源ノ明朝(Source Han Serif)を upLaTeX で使うことができるようになっている。

% upLaTeX文書
\documentclass[uplatex,papersize,a5paper]{jsarticle}
\usepackage[deluxe]{otf}
\usepackage[sourcehan-otc]{pxchfon}% 源ノアレ
\begin{document}
{\TeX}{\ajSnowman}\textbf{一切}関係ありません。
\end{document}
f:id:zrbabbler:20170701132250p:image

今まだできないこと

一方で、dvipdfmx の「Unicode 直接アクセス指定」を利用した方法には明らかな限界がある。それは「Unicode 以外の和文フォントには対応できない」ということである。このため、「pLaTeX の標準和文フォント」や「japanese-otf の \CID 入力」には対応できない。

例えば次の pLaTeX 文書があるとする。

\documentclass[papersize,a5paper]{jsarticle}% pLaTeX用
%\documentclass[uplatex,papersize,a5paper]{jsarticle}% upLaTeX用
\usepackage{otf}
\usepackage[kozuka-pr6n]{pxchfon}% 小塚フォント
%\usepackage[sourcehan-otc]{pxchfon}% 源ノアレ
\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\renewcommand{\labelenumi}{\theenumi}
\begin{document}
韓国プロ野球ではシーズン最多本塁打数の記録をもち
「アジアの大砲」と呼ばれ、日本の読売巨人軍に5年間在籍した
野球選手は誰か。
\begin{enumerate}
\item\UTF{9DD7}\item \UTF{9127}小平
\item \CID{13706}澤ひとみ
\item ウィリアム・ヘンリー・ゲイツ\ajRoman{3}\item またそのネタですか
\end{enumerate}
\end{document}

pxchfon のプリセットを kozuka-pr6n にした状態(上掲のソースのまま)では pLaTeX でのコンパイルは正常に行われる。

f:id:zrbabbler:20170701132411p:image

しかしプリセットを sourcehan-otc にした場合(4 行目の代わりに 5 行目を有効にする)は、pLaTeXコンパイルは無事に終わるが、dvipdfmx の実行で次のようなエラーが出て失敗する。要するに「フォントが Adone-Japan1 でないからダメ」ということである。*1

Character collection mismatched:
        Font: Adobe-Identity-0
        CMap: Adobe-Japan1-1

dvipdfmx:fatal: Inconsistent CMap specified for this font.

Output file removed.

また、同じ内容の文書を upLaTeX でコンパイルした場合(1 行目の代わりに 2 行目を有効にする)は、直接入力と \UTF 入力の文字は正常に出力されるが、\CID 入力は全て化けている。

f:id:zrbabbler:20170701132406p:image

でも何とかしてみる

これは dvipdfmx 自体がもつ制限なので、マップ設定を工夫することでは(物理フォントの種類に依存しない形では)解決できない。しかし、話を「pxchfon が扱う範囲(標準および japanese-otf の和文フォント)」に絞って考えると、突破口は存在する。

要するに、論理フォントの名目の情報(TFM 名および NFSS での位置)が全て既知であるため、「Unicode の論理フォントだけを参照する仮想フォント(VF)」として他の(非 Unicode の)論理フォント代替物を作成し、LaTeX 側の(NFSS の)設定を代替物の方を使用するように変更すればよいのである。*2

というわけで、作ってみた。(最新の TeX Live および W32TeX には既に収録されている。)

この pxufont は単に \usepackage で読み込むだけでよい。(japanese-otf と併用する場合は otf パッケージの跡に読み込む。)

\documentclass[papersize,a5paper]{jsarticle}% pLaTeX用
%\documentclass[uplatex,papersize,a5paper]{jsarticle}% upLaTeX用
\usepackage{otf}
\usepackage{pxufont}% これでOK!
\usepackage[sourcehan-otc]{pxchfon}% 源ノアレ
\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\renewcommand{\labelenumi}{\theenumi}
\begin{document}
韓国プロ野球ではシーズン最多本塁打数の記録をもち
「アジアの大砲」と呼ばれ、日本の読売巨人軍に5年間在籍した
野球選手は誰か。
\begin{enumerate}
\item\UTF{9DD7}\item \UTF{9127}小平
\item \CID{13706}澤ひとみ
\item ウィリアム・ヘンリー・ゲイツ\ajRoman{3}\item またそのネタですか
\end{enumerate}
\end{document}
f:id:zrbabbler:20170701144138p:image

今まで正常に扱えなかった非 Unicodeフォントが全て正常に出力されている。

もちろん、Unicode の論理フォントを参照している以上、Unicode にない文字には対応できない。(これは CID-keyed でない TrueType フォントを dvipdfmx で指定して普通に japanese-otf を用いた時と同様の制限である。)

% pLaTeX文書
\documentclass{jsarticle}
\usepackage{otf}
\usepackage[sourcehan-otc]{pxchfon}
\usepackage{pxufont}
\begin{document}
\begin{itemize}
\item \ajMaru{10}\ajMaru{20}\ajMaru{30}\ajMaru{40}%
      \ajMaru{50}\ajMaru{60}\ajMaru{70}\ajMaru{80}
\item \○A\○a\(A)\(a)\□A\□a\●A\●a
\item \ajLig{ドル}\ajLig{ポンド}\ajLig{ユーロ}\ajLig{ルーブル}%
      \ajLig{リラ}\ajLig{ルピー}\ajLig{バーツ}\ajLig{ドラクマ}
\item \○上\○下\○印\○秘\○正\○副\○問\○答
\item \ajSnowman\ajUmbrella\ajPostal\ajBall
      \ajUpHand\ajDownHand\ajRightScissors\ajLeftScissors
\end{itemize}
\end{document}

これの出力結果は以下の左の図のようになる。右の図は同じ内容の文書を小塚フォントで出力したものであり、これと比較すると一部の文字が正常に出力されないことが判る。*3

f:id:zrbabbler:20170701150020p:image f:id:zrbabbler:20170701150017p:image

将来できるようになること

現状では、japanese-otf の機能を用いた異体字の区別はうまく働かない。

%\documentclass{jsarticle}% pLaTeX用
\documentclass[uplatex]{jsarticle}% upLaTeX用
% 2004JIS字形を指定する
\usepackage[jis2004]{otf}
\usepackage[sourcehan-otc,prefer2004jis]{pxchfon}
\usepackage{pxufont}
\begin{document}
\begin{itemize}
\item 葛餅で蓬餅で、かつ煎餅!
\item \CID{1481}城市から\CID{7652}飾区まで。% 字形の使い分け
\end{itemize}
\end{document}

pLaTeXコンパイルした場合は、ほぼ確実に 90JIS 字形が選択される。

f:id:zrbabbler:20170701151817p:image

upLaTeX でコンパイルした場合は、japanese-otf の jis2004 の有無は正常に考慮されるが、それでも \CID で「両方の字形を使い分ける」ことはできない。

f:id:zrbabbler:20170701151807p:image

しかし実はこれは 20170318 版の dvipdfmx に存在するチョットしたバグのせいである。最新の 20170627 版(W32TeX では既に利用可能である)ではこのバグは既に修正されているため、完全に意図通りの出力が得られる。

f:id:zrbabbler:20170701153608p:image

この新しい dvipdfmx が TeX Live で使えるようになるのは来年の TeX Live 2018 からということになる。この新しい dvipdfmx が普及すれば、「Unicode 直接アクセス指定」の活用の幅はもっと拡がることになるだろう。

*1:この「グリフ集合の整合性の検査」も新版の dvipdfmx で導入された。それまでは不整合であっても“適当に”処理が続けられたが、当該フォントの出力は完全に文字化けになっていた。

*2pLaTeX の japanese-otf の中字・明朝体フォントを例にすると: NFSS から実の TFM へのマップは JY1/hmc/m/n → nmlminr-h → hminr-h である。しかし“Unicode 直接”前提の dvipdfmx のマップでは JIS コードの hminr-h は使えず Unicode の otf-ujmr-h しか使えない。従って、nmlminr-h と等価(つまり JIS コード)でマップ先を otf-ujmr-h とした新たな VF の zu-nmlminr-h を用意した上で、NFSS 側で JY1/hmc/m/n → zu-nmlminr-h → otf-ujmr-h というマップに置き換えるのである。

*3:実を言うと、\ajSnowman\ajUmbrella\ajPostal の 3 つの記号は japanese-otf において最初から Unicodeフォントで扱われているのであるが。

2017-06-24

新しい pxbabel についての話

この記事では、pxbabel パッケージ(PXbase バンドル)の新版(1.1 版)における新しい機能について解説する。

pxbabel って何

要するに、こういうことをするためのもの。

\documentclass[uplatex,a4paper]{jsarticle}
\usepackage[schinese,japanese]{pxbabel}
\begin{document}
『骨』は簡体字では『%
\foreignlanguage{schinese}{}%
』と書く。
\end{document}
f:id:zrbabbler:20170622120801p:image

日本語と中国語では別のフォントを使う必要があるわけだが、そのフォントの切替を「Babel における言語の切替」というインタフェースで行えるようにしたのが pxbabel パッケージである。(pxbabel は内部で babel を読み込んでいる。)

詳しい解説は奥底のページにある。ただしここの説明は古い版に基づくものである。

新しいやつと古いやつは読込方法が違う

新版ではパッケージの読込の方法がより簡単なものに変更されている。

新しいやつの場合

要するに「babel の代わりに pxbabel を読み込む」という形になる。pxbabel を使うことにより 4 つの CJK 言語(japanese・korean・schinese・tchinese)が“指定できるようになる”ため、CJK 言語およびその他の Babel の言語のうち、自分が使いたいものを列挙すればよい。babel での規則と同じく、一番最後に書いたものが基底言語(その文書のメインの言語で文書開始時に有効になっている)になる。

  1. 例えば“韓国語文書”を作る場合は:

    \usepackage[korean]{pxbabel}
    
  2. 例えば“繁体字中国語を含む日本語の文書”を作る場合は:

    \usepackage[tchinese,japanese]{pxbabel}
    
  3. 例えば“英語と日本語を含むフランス語文書”を作る場合は:

    \usepackage[english,japanese,french]{pxbabel}
    
  4. 例えば“エスペラントと日本語を含む簡体字中国語文書”を作る場合は:

    \usepackage[esperanto,japanese,schinese]{pxbabel}
    
古いやつの場合

これに対して、旧版は「babel の後で pxbabel を読む」という手順になっていた。

  • まずは非 CJK 言語のオプションを指定して babel を読み込む。(ここで最後に書いたものが基底言語になる。)
  • その後に pxbabel を読み込むと、4 つの CJK 言語が(常に)有効になる。ここで CJK 言語を基底言語に変えたい場合は、pxbabel のオプションmain=<言語名> を指定する。

先の節で例に挙げたパターンは、旧版では以下のようになる。

  1. 韓国語文書”を作る場合は:

    \usepackage[english]{babel}
    \usepackage[main=korean]{pxbabel}
    
    ※CJK 言語は常に有効なので korean の指定は不要なことに注意。
    ※babel を言語オプション無しで読み込むことは許されないので、取りあえずダミーとして english を指定する。
  2. 繁体字中国語を含む日本語の文書”を作る場合は:

    \usepackage[english]{babel}
    \usepackage[main=japanese]{pxbabel}
    
    ※tchineseは“どこにも書かない”ことになる。
  3. “英語と日本語を含むフランス語文書”を作る場合は:

    \usepackage[english,french]{babel}
    \usepackage{pxbabel}
    
    ※pxbabel に main がないので babel で決定した基底言語がそのまま保持される。
  4. エスペラントと日本語を含む簡体字中国語文書”を作る場合は:

    \usepackage[esperanto]{babel}
    \usepackage[main=schinese]{pxbabel}
    
互換性の心配は無用

ただし、旧版の仕様に従った文書コンパイル結果が変わってしまってはいけないので、以下のようにして後方互換性を保持している。

  • babel と pxbabel が別個に読み込まれた場合は旧版の仕様に従う。つまり、main キーが指定されない場合は、pxbabel は基底言語を変更しない。
  • 新版でも実際には 4 つの CJK 言語全てが有効になっている。(ただし pxbabel のオプションに明示指定することが推奨される。)
  • main キーで基底言語を明示指定する方法は新版でも有効である。main=french のように非 CJK 言語を指定することも可能。*1

キャプション言語の扱い(caption オプション

Babel で日本語(などの CJK 言語)を扱うときの顕著な問題点の一つが「キャプション言語の切替」の問題である。これは先に挙げた奥底の記事の別の箇所で詳しく論じられている。

新版では、キャプション言語の切替の挙動は caption というオプションキーで制御できる。

caption の既定値は基底言語により異なり以下のようになる。*4

  • 基底言語が非 CJK 言語になる場合は switch、つまり Babel の仕様が保持される。
  • 基底言語が CJK 言語になる場合は main となる。pxbabel が追加した CJK 言語はキャプション文字列の定義を含んでいないため、文書クラスでの定義を利用する必要があるからである。

従って、pxbabel を利用して CJK 言語が基底となる文書を作成する場合は、文書クラスは当該の言語のためのものを選ぶ必要がある。先の例でいうと、1 では韓国語用、2 では日本語用、4 では簡体字中国語用の文書クラスを用いる必要がある。*5

bxorigcapt パッケージ

ちなみに、「Babel は使いたいが、キャプション文字列文書クラスで決めたものをそのまま使いたい」という場合、bxorigcapt パッケージを使うという手段もある。


補足的な何か。

*1:ちなみに、これは偶然であるが、比較的最近の Babel には main キーで基底言語を明示指定する機能が追加されている。

*2otherlanguage*-形はキャプション言語の切替を行わない。

*3:この“default”という名称は「昔の bxbase の \bxmainlanguageデフォルトの動作」であることに由来する。

*4:この仕様は古い版と新しい版の間で変更はない。

*5:通常、CJK 言語の各々と非 CJK 言語の間で「文書クラスをキャプションだけ書き換えて融通する」ということは、レイアウトが大きく異なるゆえ不可能である。従って、CJK 言語が基底の場合は「文書クラスの文字列を保持する」のが最適なのである。

2017-06-23

pxchfon の新しいやつ(v1.0a)

W32TeXTeX Live では既に更新されている。

プリセット“yu-win10+”でもっと游フォントできる話

Windows 10 搭載の游フォントを使うマップ設定を pxchfon で指定する場合のプリセットは yu-win10 である。しかし、この設定には引用符 “ ” ‘ ’ の出力が不正になるという欠点がある。

% upLaTeX文書; UTF-8
\documentclass[uplatex,a4paper]{jsarticle}
\usepackage[yu-win10]{pxchfon}
\begin{document}
%“ ”が正しく出力されない。
{\TeX}は“アレ”、\textgt{☃は“非アレ”。}
\end{document}
f:id:zrbabbler:20170618000959p:image

フォントの(既定で出力される)引用符は全角幅でない。その上、Windows の游フォントは(macOS のものと異なり)CID-keyed でないので、「全角幅の引用符を指定して出力する」ことができない。従って旧来の dvipdfmx では全角幅の引用符を出力することは困難であった。

例によって、新しい dvipdfmx であれば、この問題に対処できる。それを実装したのが、新しいプリセットである yu-win10+ である。(例によって upLaTeX 専用である。)

% upLaTeX文書; UTF-8
\documentclass[uplatex,a4paper]{jsarticle}
\usepackage[yu-win10+]{pxchfon}
\begin{document}
%“ ”があっても大丈夫!
{\TeX}は“アレ”、\textgt{☃は“非アレ”。}
\end{document}
f:id:zrbabbler:20170618000956p:image

yu-win10+ だと正常に出力されている。一般人が見る限りは……。

でもやっぱりごまかしている話

……実は、yu-win10+ の出力も完全ではない。「フォントな人」が見れば直ちに判るだろうが、游明朝の引用符が游ゴシックになっている。これは「元の(引用符以外の)フォントと別のフォントに振る必要がある」という実装上の制限を回避するためであり、具体的には、游明朝と游ゴシックの両方の「引用符フォント」を“Yu Gothic UI”に振っているのである。*1

フォントマップファイルダンプ出力機能

フォントマップファイルダンプ出力機能」を使うと、pxchfon が設定した「現在のフォントマップ」をマップファイルの形で出力することができる。

単純フォントマップファイルダンプ出力(dumpmap オプション

例えば、pxchfon を利用して、以下のように「和文フォントを全部『HG創英角ポップ体』にする」設定を行ったとする。

[favorite.tex]

% upLaTeX文書
\documentclass[uplatex,a4paper]{jsarticle}
\usepackage[noalphabet]{pxchfon}
\setminchofont[0]{HGRPP1.TTC}% HG創英角ポップ体!!
\setgothicfont[0]{HGRPP1.TTC}% HG創英角ポップ体!!
\begin{document}
\section{なんか書いてみる}
吾輩は☃である。意味はまだ無い。
\end{document}
f:id:zrbabbler:20170617235923p:image

そして、この設定が心底気に入って、「和文フォントデフォルトHG創英角ポップ体にしたい!」と思ったとする。しかし、デフォルトの設定をするためには、フォントマップの内容を記したファイルが必要である。

フォントマップファイルダンプ出力機能を利用すると、所望のマップファイルを簡単に作成できる。pxchfon に dumpmap オプションを追加する。

\usepackage[dumpmap,noalphabet]{pxchfon}

この状態で favorite.texコンパイルすると、favorite.map というファイルが出力される。

% a.map
uprml-h UniJIS-UTF16-H :0:HGRPP1.TTC
uprml-v UniJIS-UTF16-V :0:HGRPP1.TTC
uprml-hq UniJIS-UCS2-H :0:HGRPP1.TTC
upgbm-h UniJIS-UTF16-H :0:HGRPP1.TTC
upgbm-v UniJIS-UTF16-V :0:HGRPP1.TTC
upgbm-hq UniJIS-UCS2-H :0:HGRPP1.TTC
urml UniJIS-UTF16-H :0:HGRPP1.TTC
urmlv UniJIS-UTF16-V :0:HGRPP1.TTC
ugbm UniJIS-UTF16-H :0:HGRPP1.TTC
ugbmv UniJIS-UTF16-V :0:HGRPP1.TTC
% EOF

従って、後は「普段の upLaTeX のコンパイルのワークフロー」においてこの favorite.map が使用されるように適切な設定を行えばよい。

TeX Live の場合は、後述の「TeX Live 用フォントマップファイルダンプ出力」機能を用いた方が便利である。

  • favorite.map を「dvipdfmx が見える場所」に配置する。
    (例えば `$TEXMFHOME/fonts/map/dvipdfmx/)
  • dvipdfmx の実行において favorite.map が読まれるようにする。
    • ビルドツールや統合環境の設定において、dvipdfmx のオプション-f favorite.map が追加されるようにする。
    • W32TeX の場合、dvipdfmx の設定ファイル($SELFAUTODIR/texmf-dist/dvipdfmx/dvipdfmx.cfg*2)の末尾に f favorite.map を追記する。
      TeX Live では原則的にこの作業を行ってはいけない。

※「単純」の方のダンプ出力は、本当に当該の文書で有効になっているマップ行だけを出力する。例えば、先の favorite.tex の場合、upLaTeX 文書でありかつ japanese-otf を使っていないため、pLaTeX の標準和文フォント(rml など)や japanese-otf の和文フォントに対するマップ行は含まれていない。逆に、有効になっているマップ行は何でも出力するので、例えば、alphabet が指定された場合は欧文フォントr-cfjar-r-@PXcjk0@ など)のマップ行も出力*3し、また \usefontmapline で直接指定されたマップ行も出力する。

TeX Live 用フォントマップファイルダンプ出力(dumpmaptl オプション

dumpmap オプションは全てのマップ設定を単一のファイルに書き出すのに対し、こちらの dumpmaptl オプションTeX Live の kanji-config-updmap ユーティリティに適した形式の複数のファイルに出力する。従って、この機能を利用して「kanji-config-updmap 用のカスタム設定」(参照)を簡単に作成できる。

例えば、次のように、sourcehan プリセットを指定してさらに dumpmaptl オプションを追加する。

\documentclass[a4paper]{jsarticle}
\usepackage[sourcehan,dumpmaptl]{pxchfon}
\begin{document}
アレ。
\end{document}

この文書コンパイルすると、以下の 4 つのマップファイルが出力される。

  • ptex-mysourcehan.map
  • uptex-mysourcehan.map
  • otf-mysourcehan.map
  • otf-up-mysourcehan.map

この後、以下の手順を行うことで、「pxchfon の sourcehan と同じ設定」をデフォルトに設定することができる。

  • マップファイルを「dvipdfmx から見える場所」に配置する。
    (例えば $TEXMFLOCAL/fonts/map/dvipdfmx/*4置いて、mktexlsr を実行する。)
  • kanji-config-updmap-sys mysourcehan を実行する。

※「TeX Live 用」の方のダンプ出力は、当該の文書で実際に有効であるかに関わらず、ユーザが行った設定に対応するような、kanji-config-updmap の様式に従ったマップファイルを出力する。kanji-config-updmap の管轄でないもの(欧文フォント\usefontmapline)はどこにも出力されない。

ドライバオプションできる話

pxchfon は本質的に dvipdfmx しかサポートしない。*5このためドライバオプションをサポートしていなかった。しかし現在の LaTeX の使用では「ドライバオプションをグローバルに指定する」ことが一般的になりつつあるので、グローバルにドライバが指定された場合には「そのドライバ指定に対して最適な動作」を行うのが望ましい。

そこで、pxchfon においてもドライバオプションをサポートした。

  • dvipdfmx: 従来通り、dvipdfmx に依存する動作を行う。
  • dvipsdvioutxdvinodvidriver: dvipdfmx に依存する動作を回避する。主要機能が無効になるため、実質的に何の役にも立たなくなる。*6

既定値は dvipdfmx なので、ドライバオプションを指定しない場合の挙動は何も変わらない。主な目的がグローバルオプションに対応することであるので、「これからは pxchfon にドライバオプションを指定すべきだ」と主張しているわけではない。

*1:「sourcehan の設定で一部の日本語論理フォント韓国語中国語フォントに振っている」というのと同様の話。

*2$SELFAUTODIRW32TeXインストールしたディレクトリ

*3:ただし、“pxchfon 用の欧文フォント”は pxchfon を読みこんだ時のみに使われるものなので、そのマップ行を当該の文書の外で適用してもあまり意味がない。

*4TeX Live では原則的にユーザレベルよりもシステムレベル設定を用いた方がよいので$TEXMFLOCAL` にした。

*5:ただし、マニュアルを読めば判るように、「フォントマップ設定が効かないことを前提にして、プレビュー目的で敢えて dvipdfmx 以外の DVI ウェアで DVI を扱う」ことは想定されている。

*6:先の注釈で述べたような「プレビュー用途」の場合、「dvipdfmx 専用の DVI 命令が含まれることによる無用な警告が出なくなる」というメリットはあるだろう。