症状の概要

EvinceでPDFを表示すると、日本語フォントが正常に表示されない。

• poppler-dataがインストールされていてもいなくても表示されない。
  • 症状は変わる（「透明文字」→「トーフ」）。
  • 文字を選択してコピーして別のソフトウェア（e.g. gedit）に貼りつけると、正常に表示される。
• 再現するのはフォントを埋め込んでいないPDFに限られる（と4/13時点では想定されている）

機序

Evince（正確にはバックエンドのpoppler）がfontconfigを使って「表示に利用するフォント」を選定する上で、誤った方法で「最初に出てきたフォント」を利用している

• fontconfig上、日本語環境では「DejaVu + Takaoを利用する」ように設定されている（from language-selector-commonが投下する69）。

  • これにより、本来なら「DejaVuにグリフがあるものはDejaVu、ないものはTakaoに代替」して表示される。

  • が、いろいろな問題によりTakaoに代替せずにDejaVuのままになっていて、結果としてトーフが表示される。

• Evinceで文書表示時、プロパティを見るとフォントとしてTimes New Romanとか出てくるが、これは本質的には関係ない（正常に代替している場合でも変わらない＆内部的にまた別のロジックでこれが出てきている）。PDF内部のフォント名にShift JISが使われており、これをダイアログ内部で正常に表示できないために、PDFファイル内部の先頭にあるTimes New Romanがそのまま使われている。

機序の推定方法

• 以下の方法で症状を消失させることができる。
  • sudo mv /etc/fonts/conf.d/69-language-selector-ja-jp.conf ~

  • /etc/fonts/conf.d/69-language-selector-ja-jp.conf にある、DejaVuを指定する行を削除するパッチ（http://pastebin.ubuntu.com/593581/ ）を当てる。

後者の方法はワークアラウンドとしても利用可能。

調査

• 状況の区分
  • 「表示されない」には、「表示されない（透明な文字が表示されている）/四角いトーフ/トーフ状に16進数/16進数でもないおかしな文字が表示される」などなどの症状があるが、このケースでは「トーフ」が基本。
    • 「透明な文字」の場合はpoppler-dataが入っていない可能性がある。
    • poppler-dataを入れた状態で「トーフ」以外の症状が出る場合、別の問題の可能性がある。
  • おそらくCMAPは正常にマッピングできていて、フォントに格納されたグリフがない状態。グリフを引っ張り出すフォントを適切に選定できていない可能性が高い。
• 問題の切り分け
  • [済] アプローチ1. poppler-dataはインストールされているか？
    • されている。入っていなければ「透明な文字」になる。
  • [済] アプローチ2. Evinceのバージョンのせい？
    • poppler-dataのバージョンをmaverickのものに落としても同じ(0.4.4→0.4.2)
    • Evinceそのもののバージョンは、maverickとnattyで同じ(2.32)
  • [済] アプローチ3. apparmor？
    • apparmorの設定を確認したところ、poppler-dataを読み込む部分には変化なし
  • [済] アプローチ4. fontconfigの設定のせい？
    • 案) Lucid-ja から /etc/fonts/ 以下をコピーして試す
    • 案) fc-matchで地道に候補を見ていく
  • その他乱暴なアプローチをしてみたら書く場所
    • (変わらず) dpkg -i fontconfig-config_2.6.0-1ubuntu12_all.deb ; 実質的なfcの設定はそのまま
    • (変わらず) dpkg -i fontconfig-config_2.8.0-2ubuntu1_all.deb ; 実質的なfcの設定はそのまま
    • (変わらず) dpkg -i libevdocument2_2.30.3-0ubuntu1.2_i386.deb libevview2_2.30.0-0ubuntu1_i386.deb
    • (変わらず) apt-lineをLucidにしてsudo apt-get install evince=2.30.3-0ubuntu1.2
    • (変わるかも) sudo mv /etc/fonts/conf.d/69-language-selector-ja-jp.conf ~
      • 環境によっては直らないかもしれない
      • ロジックとしては脆弱だが、language-selector-0.6.7~ja2/fontconfig/69-language-selector-ja-jp.confを/etc/font/conf.d/（conf.availでもいい）にコピーすると直る？

      • むしろ http://pastebin.ubuntu.com/593581/ ？

      • とりあえずBTSした。http://pad.lv/759882

      • 本質的にはEvinceの内部実装がいろいろとマズイが、表面的にはfcで回避できる。

解決に向けたアプローチ

ワークアラウンド

Evinceのフォント選定方法でも問題がないようにfontconfigを補正する。

see [/fontconfig]

根治方法

Evinceのフォント選定問題を直す

潜在的問題

後回しにしても致命的ではない（と思われる）問題。

• 縦書きフォントだけ正常表示されない（トーフになる）ケースがありえる模様。
  • 理論的にはあってもおかしくない（vmapが通っていなければフォントにマッピングされないし、vmapから該当するグリフを引き出せなければ表示できない）。
  • なんでやねん感は残る。

テスト手法

another-test.pdf が正常表示できるかどうかで判定可能と見られる。

• another-test.pdfは4つの段落に別れており、それぞれ MJS-リュウミンEB-KL / MJS-新ゴM / HG P明朝L Sun / HG PゴシックB Sun が指定されている。
• フォント・フォントサブセットは埋めこまれていない。
• 通常のUbuntu環境にはいずれも存在しないフォントであるため、代替フォントで表示されるのが正しい。
  • 結果、代替フォントの指定に失敗すると「トーフ」等の問題が再現する。

another-test2.pdf に、Ubuntuに存在することが期待されるフォントを入れてみたが、結果は一緒

• 制作したWindows環境では、意図したとおり（存在するフォントはそれが使われる）に表示。Adobe Reader使用
• Ubuntu 10.04 LTS 日本語RemixのAdobe Reader9/Evince、10.10 日本語RemixのEvinceでは、代替フォントが使われる

• Ubuntu 11.04では、 another-test.pdf と同じくトーフ

テスト例(by Mocchi)

Mocchiがtest.pdfとanother-test.pdfで確認した結果が以下表。

• 表を見るのが面倒な人むけまとめ：
  • Lucid(Japanese Remix; Lucid-ja)では常に正常。
  • Nattyでも欧文フォントは正常。しかし、和文フォントはpoppler-dataの有無に関わらず正常表示は得られない。
    • poppler-dataの有無で症状が変わる。

another-test.pdfでの「トーフ」の実例：

テスト例(by HiroshiChonan)

参考までにHiroshiChonanのmaveric上でのスクリーンショット。poppler-dataインストール済み。

• 縦書きフォントのみ正常表示されていない。

テスト用PDF

（第三・第四カラム目のフォント情報はEvinceの［ファイル］→［プロパティ］で表示されるフォントタブから取得したもの。一部謎の結果がかえっている）

• g_test.pdfは、g_emb.pdfとg_non_emb.pdfをpdftk でつなげたもの

追記 印刷に対する影響など by KojiOtani

印刷への影響

Ubuntuでは、印刷システムがpopplerを使用しているために、印刷にもこの問題の影響が出る。問題の出るPDFファイルをlpr等で直接、印刷すると紙の上で問題が再現する。Evinceから印刷しても、表示と同様にトーフが印刷される。 それ以外のアプリケーションでも、印刷ファイルとして出力するPDFやPSファイルにフォントを埋め込んでいない場合には、同様の問題が発生する可能性がある。

popplerの動作

popplerは、PDFで指定されたひとつのフォントに対してはただひとつのフォントしか選択していない。そのフォントにグリフがなければトーフ(実際に表示されるものは、フォント依存)になる。 PDFやPSは、そのファイル内ではCIDフォントを指定している。popplerは、CIDフォントの代わりになるものをTrueTypeフォント等で代替するという動作をしており、通常のアプリとは、フォントの指定方法が異なり、グリフがないから次のフォントといった動作は簡単ではない。少なくとも大幅な変更が必要となるので、すぐには修正は難しい。

縦書きについて

g_no_emb.pdfで縦書きのフォントが一部トーフになるのも、まったく同様のフォント選択の問題であって他の問題はない。vmapは関係ない。Ryumin-Lightはうまく表示できて、GothicBBB-Mediumがうまくいかないのは、Lightは認識してMediumを認識していないから。

fontconfigの設定の補正について

ワークアラウンドで提案されているfontconfigの設定を補正する方法で、印刷の問題も同様に解決できる。

個人的には、ひとつのフォント指定に対して、Latin-1のフォント+日本語フォントの組み合わせを使うのは問題があると思う。 なぜなら、日本語フォント内の英字グリフは、漢字などのグリフと合わせて統一してデザインされており、本来それを使うべきだと思う。 違うデザインのフォントを使用する場合は、そもそも、違うフォントとしてアプリが指定するべきことである。 なので、このワークアラウンドで修正としては問題はないと思う。

popplerの修正について

とはいえ、Latin-1フォント+日本語(CJK)フォントの組み合わせをどうしても使いたいというユーザもいるようなので、他のアプリに影響しないようpoppler内でごまかす方法を考える。

前述したようにfallbackするのは大変なので、フォントの選択時にAdobe-Japan1に対し、日本語をサポートしていないフォントを選択しないよう変更することが考えられる。Japan2やChinese, Koreanでも同様に処理する。