maji さん、詳しい検証をありがとうございます。
2017年4月01日(土) 02:29 付けの beginner さんの投稿（#p59488）によれば、
beginner さんが書きました:
PDF出力だけでなく紙プリンター出力でも同じように文字化けます。おっしゃるように <th> タグで太字になってる部分が化けてます。ブラウザでのプレビューは文字化けません。
とのことなので、これを前提とするなら、Firefox 側からプリンタドライバに引き渡されるデータ処理に何らかの問題があるように見えます。
以下、maji さんのテスト報告を拝見して気づいたことを、順を追って書かせていただきます。
maji さんが書きました:
about:config にて「 skia 」が値として指定されていた以下の二つの設定名
AzureCanvasBackend
AzureContentBackend
標準状態の Firefox 52.0.x (Windows 版) に、この２つの設定項目は存在しません。
gfx.canvas.azure.backends = direct2d1.1,skia,cairo
gfx.content.azure.backends = direct2d1.1,skia,cairo
の２つは存在し、上述ような初期値を持っていますが、これは直接影響していないように見えます。
maji さんがご提示になっている項目は、Skia が有効になった結果、生成されるのかもしれません。
maji さんが書きました:
Firefox52のリリースノートによると
》 Windows上でコンテンツの描画に Direct2D が使われていない場合、代わりに Skia を使用します。
との対処があったとの事です。
通常、Firefox (Windows 版) では初期状態で Direct2D が有効になっています（gfx.direct2d.disabled = false）。
しかし、[オプション] -> [詳細] -> [一般] -> [ブラウズ] -> [ハードウェアアクセラレーション機能を使用する (可能な場合)] を無効にした場合、あるいは、「(可能な場合)」ではない条件が加わったとき、Direct2D は無効化されます（gfx.direct2d.disabled = true）。
（補足）
[ハードウェアアクセラレーション機能を使用する (可能な場合)] の有効／無効は、gfx.direct2d.disabled だけでなく layers.acceleration.disabled など複数の設定項目が変更されます。
このご報告が非常に大きなヒントになりました。
つまり、Windows OS で標準的な 2D グラフィック機能である Direct2D が無効化されることで、Skia が使用されるようになり、その文脈で何らかの問題が発生するのだと仮定することができます。
一方、ハードウェアアクセラレーション機能だけに問題があるのだとすると、Firefox のバージョンによる動作結果の変化が合理的に説明できません。
そこで、最初に technologic89 さんから提示された条件、つまりアップデート前の Firefox 43.0.1 では問題は起こっておらず、52.0.1 へのアップデート以後に起こり始めたというお話から類推して、マルチプロセス（e10s）がらみの要素を加味して動作パターンの仮説を立て、実験してみました。
テスト環境は次の通りです。
Windows 7 SP1 64bit
通常リリース版 (32bit) の Firefox 52.0.2
プリンタ（PDF 出力用）＝ CutePDF Writer + Ghostscript
結論を申し上げると、次のような結果になりました。（等幅フォントで最適化）
────┬──┬───
e10s＼HW│有効│無効
────┼──┼───
有効 │○ │×
────┼──┼───
無効 │○ │○
────┴──┴───
縦＝マルチプロセス（e10s）の有効／無効
横＝ハードウェアアクセラレーション（HW）の有効／無効
○＝正常、×＝文字化け発生
つまり、何らかの理由でハードウェアアクセラレーションが無効化されたとき、Direct2D に変わって Skia が使用されたとして、e10s が有効だとプリント結果の一部に文字化けが発生するようです。別の言い方をすると、Skia は e10s 有効下では正常に働かない場合がある、といえばいいでしょうか。
当方のテストでは、e10s が無効化されていれば、ハードウェアアクセラレーションの有効／無効に関係なく文字化けは発生しませんでした。
新規プロファイルで起動した直後は、一般的にアドオン（拡張機能）は入っていませんから、多くのユーザー環境では Firefox 52.0 系の初期状態で e10s が有効化されていると思います。その後、e10s が無効化されたとしても、文字化けが解消することはあっても新たに発生することは考えにくいでしょう。
従って、変化が生じる直接の契機は、e10s 有効下におけるハードウェアアクセラレーション機能の変化とそれにともなうグラフィックス機能の変更が、何らかの影響を及ぼしているのであろうと考えられます。
（ただし、<th> タグや <h*> タグで定義されたすべての文字列が、必ず文字化けするわけではなさそうです。この点はさらに検証する必要があるかもしれません。）
maji さんが書きました:
なんとなくですが
新規プロファイルで真っ新にしたプロファイルで最初は正常も
時間が経つにつれて(数回 Firefox起動を繰り返すと)事象発生する(プロファイルに何らかの変更が加わる)みたいな感じです。
technologic89 さん、beginner さん、maji さんのお三方に共通して再現できているお話なので、何かしらの要因はあるのでしょう。
ハードウェアアクセラレーション機能の有効／無効を反映させるには、Firefox の再起動が必要ですから、リフレッシュや新規プロファイルでの初回起動時は、初期値で有効化が維持されているのかもしれません。その後、Firefox の再起動をくり返すタイミングによって、ユーザー環境にある何らかの要因が無効化を誘発し、Firefox が内部的に使用する 2D グラフィックス機能を変更しているのかもしれません。
しかし、実際に何がハードウェアアクセラレーション機能の変化を誘発しているかは、今ある情報だけではわかりません。お三方のところで、直接の契機になっている要因は共通しているかもしれませんし、それぞれ異なるかもしれません。
【当面の回避策】
現状で考えられる対策としては、e10s を強制的に無効化することで、ハードウェアアクセラレーション機能がどう変化しても印刷結果に影響を与えないようにすることでしょうか。
about:config から、
browser.tabs.remote.autostart.2
の値（初期値＝ true 、e10s 有効）を、false に変更することで、e10s を無効化できます。
（補足）
開発版などから継続使用してきたプロファイルには、標準ではない設定項目が残っているかもしれませんが、リフレッシュや新規プロファイルを作ったのなら、その後はユーザーが意識的に追加・変更しない限り、e10s 関係の設定項目は標準状態だと思います。
以上は、当方がいまできる条件下で試した結果です。
いちおう理屈の上では説明がつきそうですが、他のユーザー環境ではどうなるかわかりません。興味のあるユーザーさんは、さらなる検証にご協力いただけるとありがたいです。
とりえあえず以上です。的外れな話になっていたらすみません。
重ねて、maji さんのテストとその中での発見に感謝いたします。
（おことわり）
当方の諸事情により、今まで以上に不定期な応答しかできなくなっています。
即答を期待されても、それに応えられない場面がかなり多くなりますことを、ご容赦ください。
ログイン
ユーザー登録
FAQ
検索
