Hatena::ブログ(Diary)

アセトアミノフェンの気ままな日常

2015-10-12

OpenType Collection フォントの未解決問題まとめ

先日までの記事で作業の進捗状況をここで逐一報告してきたが、まだ OpenType Collection フォントに TeX Live が完全には対応しきれていないので、いま判明している限界 (To Do) をまとめておく:

LuaTeX で OpenType Collection フォントを扱う件

LuaTeX で使われる fontloader が一部の Collection フォント (OTC/TTC) を読み込めない件について、完全には解決していないようだ。

(1) とりあえず luaotfload の上流である ConTeXt のほうで改修していただくことができ、ConTeXt の beta 版 2015.10.09 21:28 ではほとんどの問題が解消した(Collection の fontname と名称一致する subfont がない場合にもエラーを吐かなくなったOS X Marvericks の Hannotate.ttc で No Characters も起きない)。ただし、この ConTeXt beta をもってしても OS X El Capitan 付属の「筑紫 A/B 丸ゴシック」だけは読み込みに失敗する(doraTeX さんのメール報告および Twitter 報告より)。このときの警告とエラーは以下のとおり

Invalid TTC index number -1 (0..1), using index 0 for font TsukuARdGothic-Regular
!LuaTeX error (file /Users/Shared/TeXLive/texmf/fonts/opentype/tsukushi/TsukushiAMaruGothic.ttc): sfnt: table not found...
==> Fatal error occurred, no output PDF file produced!

これは原因も依然不明のままである*1

(2) 上記(1)のとおり ConTeXt beta では一部の問題が解消したとはいえ、肝心の LuaTeX-ja で Collection フォントを使えるようにするには luaotfload にこの修正が降りてくるのを待つほかはない。一応 luaotfload 開発陣に例のエラー報告が Issue として伝わってはいるようだが、いつ修正されるかは不明なままである*2

(3) 上記 (1), (2) の問題がある一方で、2015年10月に LaTeX カーネルが LuaTeX 対応のために大改修されており、LuaTeX beta-0.81.0 の大幅プリミティブ名変更と併せて予期せぬ inconsistency が多発し、フォント問題の検証に支障をきたしている一面もある…(これは時間が解消してくれるはず)

(x)dvipdfmx で OpenType Collection を扱う件

これは特に「Adobe-Identity-0 なフォントを dvipdfmx でいかに扱うか」という問題である。

(1) Adobe-Identity-0 に変更された El Capitan 付属の游明朝体を横組み・縦組みで利用する試みが doraTeX さんにより行われ、縦組み・横組み両対応の CMap を作成することにより upLaTeX + dvipdfmx および pLaTeX + dvipdfmx概ね成功しているようだ。問題はこれをどこまで TeX Live 本家に取り込むかといったところだろうか*3。なお、縦組み用グリフの Unicode への対応 (ToUnicode) が正しく機能しないそうだが、これは dvipdfmx に限らず Adobe のアプリでも起こるらしく、フォント自体に問題があるという見方が強い。

(2) Adobe-Identity-0 な Source Han Code JP(源ノ角ゴシック Code JP)を dvipdfmx で埋め込むと PDF そのものが文字化けし(Twitter より)、xdvipdfmx で埋め込むと PDF には正しく表示されるが ToUnicode が正しく機能しないTwitter より)。これらの問題については現時点で未検証である。

→いずれも未解決なので積み残しリストに追加 (2015-12-27) 。

*1:この Incalid TTC index number は Hans が今回の改修で取り入れた「指定された psname を持つ subfont が見つからなかった場合もエラー終了させず、インデックス0番と仮定してフォールバックする」に基づく警告である。しかし、筑紫A丸ゴシックの psname を正しく指定してもこの警告が出るというのは不自然である。

*2:なお、リリースされたばかりの OTC 対応版 LuaTeX beta-0.81.0 は現在 TeX Live に入っている luaotfload 2.5 と inconsistent であるので、luaotfload の開発版の一刻も早いリリースが望まれている。

*3:とはいえ、游明朝体はかなり特殊なケースなので取り込むべきかどうかも微妙かもしれない。

2015-10-09

LuaTeX の fontloader の進捗状況

この前報告した LuaTeX の fontloader のパッチについて反応があった。しかし、再現例が OS X El Capitan の新しいフォントしか見当たらなかったため、一時は対応不能と言われかけた…が、kmaeda さんと doraTeX さんによる補足説明でなんとか状況を理解してもらうことに。僕もつられてこのメール

世の中にある Collection フォントのすべてに、その fontname と全く同じ名前を持つ subfont(Collection のなかの一つ一つのフォントのこと)があるとは限らないから、今の方法はまずいのでは

という主旨の説明を加えてみたところ、これに対する返信という形で新しい ConTeXt beta を出したと Hans さんからメールが。おおっ、というわけで試したところ、また別の問題*1が起きてしまい、再び報告。その数時間後にアップデートされた ConTeXt beta では、当初の問題点を含めてすべて解消しているように手元では見える。

そもそも ConTeXt とは LaTeX とは全く別の体系から成るフォーマットで、LaTeX

\documentclass{article}
\begin{document}
.....
\end{document}

のように書くのに対して、ConTeXt は

\starttext
.....
\stoptext

のように書く。LaTeX は Lamport が作成したものであり、多くのパッケージがそれに基づいて作られて日本でも「TeX = LaTeX」と勘違いされるほどに普及している。ConTeXt は Hans Hagen が開発し、ユーザによるカスタマイズ性を重視していると言われる(詳細は黒木さんの解説参照)。ConTeXt は LuaTeX で動くように開発が進んでおり、LuaLaTeX で用いる fontloader は ConTeXt 向けに作られたものを一部変更しつつ流用したものである。すなわち、この部分に関しては ConTeXt が上流で、それに追随するように LuaTeX のモジュールが発展していくといえる。そういう事情から、ConTeXt の修正は(時間がかかるとはいえ)LuaLaTeX 用パッケージに将来的には反映されることが期待でき、嬉しい結果になりつつある。

続く

*1:この問題は元々角藤さんによる発見。

2015-10-08

El Capitan 対応の総まとめ記事が出ました

昨日までの速報の、doraTeX さんによる渾身のまとめ。素晴らしい!

この問題に関連した僕の一連の日記は

日本の TeX 開発者コミュニティメーリス(開発者のみの承認制のため非公開)のなかで僕が担当している “LaTeX ユーザにとっての問題の本質を解明し、原因の箇所を実験的に特定する” という作業の過程で判明した情報を開示すること

を目的としてきた。したがって、開発者コミュニティと外をつなぐべく速報性を重視し、未確定情報であっても極力公開する方針をとってきた。しかし一般ユーザにとっては少々わかりにくい記述・高度なため不要と思われる記述も多くなってしまった感は否めない。そこでこれらの情報を最終的にまとめなおすことができればなお良いのだろうが、なにしろ僕自身が El Capitan を持っていない (!) ので躊躇していたところ、上記の記事が出て喜ばしい!


ありがとうございます(^^;;

追記 (2015-10-10):当該記事について補足したくなったのでこちらへ。

2015-10-07

LuaTeX でなぜか使えない TTC/OTC フォントを無理やり埋め込む実験

昨日述べたとおり、現在 TeX Live 2015 や W32TeX の最新版をもってしても一部のフォントが埋め込めない状況にある。この理由はどうやら LuaTeX 本体というよりはむしろフォントを読み込むユーティリティである luaotfload にあるらしいことが指摘されている。あまり他所で説明されていないので、LuaTeX のフォントの取り扱いについて本件に関わる部分のみ簡単に説明しておきたい。具体的にはどうやらフォントのキャッシュ作成時の問題らしい。以下、いかにも元々分かっていたかのように書いているが、今回の問題を調査するために改めて LuaTeX のフォント周りの挙動を調べただけであるので、もしかしたら誤りがあるかもしれないので注意されたい。

LuaTeX のタイプセット時の“フォントキャッシュ”

LuaTeX によるタイプセットでは、fontloader とよばれるライブラリが TEXMF ツリーやシステムからフォントを見出してキャッシュのようなものを作る。具体的には、OpenType フォントや TrueType フォントを読み込んだ場合に

  • TeX Live (win32) → C:\texlive\2015\texmf-var\luatex-cache\generic\fonts\otf
  • W32TeX → C:\w32tex\share\ctxdir\luatex-cache\generic\fonts\otf

に「フォント名.lua」というファイルを作成し、ここに fullname や psname などの必要な情報を書き込むようである(ほかの OS でも同様)。さらに、これはすぐに“コンパイル”されて「フォント名.luc」というバイナリが出来上がる。これが実際の組版に利用され、最終的な PDF 出力時に重要な役割を果たしているようである。

fontloader は lua コードで書かれており、頑張ってフォントの中身を読もうとする。たとえば IPAex 明朝 (ipaexm.ttf) を fontloader が読み込んだ場合、キャッシュの ipaexm.lua の膨大な記載の中には

  ["familyname"]="IPAexMincho",
  ["fontname"]="IPAexMincho",
  ["fontstyle_id"]=0,
  ["fullname"]="IPAexMincho",

などという情報がみえる。この lua ファイルがコンパイルされて luc ファイルになるのであるが、組版時には

  • luc が既に存在 → 何もせず luc をそのまま読む
  • luc が存在せず lua だけ存在 → lua をコンパイルして luc を生成
  • luc も lua も存在しない → まず lua を作ってそれをコンパイルして luc を生成

という処理が行われるようだ。単独フォントの .otf や .ttf であれば「フォント名.lua」になるが、Collection フォントであれば「フォント名-0.lua」のようにインデックス番号が付くか単に「フォント名.lua」(これは0番と等価)になるようである*1

では、フォントキャッシュ生成に失敗した場合は?

ところが、時にフォント内部に書かれているはずのフォント名を認識できないことがある。これが先の simsun.ttc をはじめとする Windows の TrueType Collection フォントで起きた現象で、この場合はフォールバックとして以下のようになる。

  ["familyname"]="SimSun",
  ["fontname"]="bad-fontname-simsun",
  ["fontstyle_id"]=0,
  ["fullname"]="bad-fullname-simsun",

これがコンパイルされても bad-fontname-simsun という名前のフォントは存在しないため LuaTeX がエラーを吐いて終了してしまうわけである。

しかし、ここで lua → luc のコンパイル規則を思い出そう。「luc があればそのまま読む」「luc がなければ lua から生成」…そう、1回目のタイプセットでいったん Invalid TTC index number で LuaTeX が落ちた後で残っているキャッシュを弄ってしまえばよいのである。具体的には

  1. まず luc ファイルを削除
  2. 次に lua ファイルを開いて「bad ナントカ」と書かれた fontname と fullname をそれっぽく修正して上書き保存
  ["familyname"]="SimSun",
  ["fontname"]="SimSun",
  ["fontstyle_id"]=0,
  ["fullname"]="SimSun",

とすればよい。こうすれば、2回目のタイプセットでは正しく記述された lua がコンパイルされたことになり、見事 simsun.ttc のようなフォントでも PDF 出力に成功する。

Windows TrueType Collection フォントのほうは開発版 luaotfload を入手すれば問題ないわけであるが、この方法は OS X El Capitan の新しい OTC にも有効であることがわかっている(実際にやっていただいた例)。ヒントとなったのは中国のフォーラムでの質問だが、具体的な解決策まで至っていなかった。本記事がなにかの参考になれば嬉しい。

なお、ちょうどいま日本の TeX 開発コミュニティで kmaeda さんが作成した luaotfload へのパッチがテスト中であり、doraTeX さんによれば El Capitan のフォントを正常に LuaTeX で取り扱えるようになったそうだ。



追記 (2015-10-08):この kmaeda さんによるパッチが LuaTeX 開発のメーリングリストに送られた(こちら)。luaotfload 開発側の対応に期待したい。→続報

追記 (2015-10-08):ここまでの一連の速報が doraTeX さんによりまとめられた

*1:正確には、TeX 文書中で simsun.ttc のようにファイル名からフォント指定すると simsun.lua というキャッシュができ、SimSun のように PostScript Name からフォント指定すると simsun-0.lua というキャッシュができるように見える。

2015-10-06

LuaTeX で一部の TTC/OTC フォントが扱えない?

昨日の LuaTeX の進歩で、OpenType Collection (OTC) フォントであるヒラギノや游明朝を LuaTeX で PDF に埋め込むことができるようになった。しかし、ここで一つ新たな問題点が見つかった。「いくつかの TTC/OTC フォントが、LuaTeX で埋め込めない」のである。これには2種類の現象が確認されている。

Windows の一部の TTC フォントについて(開発版は修正済み)

Windows バンドルの TrueType Collection フォントの一部 (batang.ttc, gulim.ttc, simsun.ttc) は、TeX Live 2015 に入っている LuaTeX-0.80.0 + luaotfload 2.5-4 (2014-08-10) で PDF への埋め込みに失敗する。たとえば以下のソース。

\documentclass{article}
\usepackage{fontspec}
\setmainfont{SimSun} % または \setmainfont{simsun.ttc}
\begin{document}
SimSun宋体字
\end{document}

SimSun とは simsun.ttc のインデックス0番のフォントの PostScript Name である。この場合のエラーがかなりわかりくい。

<c:/windows/fonts/simsun.ttc(bad-fontname-simsun:-1)Invalid TTC index number

メーリスの中で kmaeda さんに調べていただいたところによると、これは「何らかの事情でフォント名の読み取りに失敗した場合にフォールバックとして bad-fontmane-* という実在しない名前を付けて LuaTeX に渡し、それを見つけられない LuaTeX にインデックス -1 番と返させて落とす」ということらしい。既に2014年の段階で報告されており、CTAN にアップロードされている luaotfload では未だに直っていなかったというわけだ。幸い、開発版のほうで試してみると SimSun を正常に埋め込むことができるようになっていた。

待っていればそのうち CTAN に新バージョンが入るだろうとは思うが、先取りしたい場合は開発版リポジトリから luaotfload をとってきて適切に TEXMFLOCAL 以下に配置すればよい。

  • src と misc の中身を TEXMFLOCAL/texmf/tex/luatex/luaotfload へ
  • scripts の中身を TEXMFLOCAL/texmf/scripts/luaotfload へ

のように置けば認識してくれるそうだ(Thanks: doraTeX さん)。

OS X (Mac) El Capitan の一部の OTC フォントについて(現在検証中)

まずこれを試すには北川さんによるパッチを施した LuaTeX-0.80.1 (dev) SVN5330 をビルドする必要がある(末尾の補足参照)。この開発版 LuaTeX + luaotfload 開発版をもってしても、以下の OTC フォントを埋め込もうとすると

</Users/Shared/TeXLive/texmf/fonts/opentype/klee/Klee.ttc(AppleKlee-Medium:-1)Invalid TTC index number

というこれまた同じようなエラーが出るらしい(本実験は doraTeX さんによる)。

  • HiraginoSans-W{0,1,2,4,5,7,9}
  • Klee-{Medium,Demibold}
  • TsukuARdGothic-{Regular,Bold}
  • TsukuBRdGothic-{Regular,Bold}

現在、日本の TeX 開発コミュニティのメーリスでこの問題について精査中であるが、実はパッケージ側がコード修正を行わずとも“とりあえずは強引にフォントを埋め込める方法”というのが存在する。少々長くなりそうなので、次回に回すことにしよう。

追記 (2015-10-07):luaotfload の内部で PostScript Name をフォントから読み取ってキャッシュに書き込む処理に問題があったことが判明し、修正するパッチが完成した(Thanks: kmaeda さん)。このパッチを適用すれば、LuaTeX で El Capitan 搭載の OTC フォントを含むおそらく全てのフォントを正しく扱えるようになる見込み。

補足:LuaTeX のビルド方法 (SVN5330)

kmaeda さんにビルド方法を教えていただいたので、それを簡単にここに書いておく。僕は Cygwin でビルドしたが、LinuxOS X でも同様にビルド可能だそうだ。なお、あらかじめ svn (subversion) と makeinfo (texinfo) が入っていることを確認した方がよいかもしれない。また、最初のコマンド実行時に求められるパスワードについてはここを参照。

$ svn checkout -r 5330 --username anonsvn https://foundry.supelec.fr/svn/luatex/trunk
$ cd trunk
$ CFLAGS="-O2 -march=native" CXXFLAGS=$CFLAGS ./build.sh --parallel --jit      <= OS X では末尾に --clang も付ける

これでビルドが成功すれば luatex と luajittex のバイナリが生成しているはずである。

$ cd build/texk/web2c      <= OS X では build-clang/texk/web2c に生成
$ ls -l luatex luajittex

これを TeX Live 2015 のツリーに配置する(元々あった luatex, luajittex はリネームして退避させておくと安心)。そして、フォーマットファイルを更新する。

$ fmtutil-sys --byfmt luatex      <= Linux, OS X では sudo 必要
$ fmtutil-sys --byfmt lualatex    <= Linux, OS X では sudo 必要

これで Source Han Sans などの OTC フォントを扱えるようにはなるはずである。

続く