Pdf.js: ひどくレンダリングされたTimesNew Roman PS

作成日 2019年03月22日  ·  3コメント  ·  ソース: mozilla/pdf.js

ここにPDFファイルを添付（推奨）またはリンクします：
EMG8 -Cambridge Essentail Gold Maths 8-B 117.pdf

構成：

  • Webブラウザとそのバージョン： Chrome 73
  • オペレーティングシステムとそのバージョン： * Macos 10.14.1 *
  • PDF.jsバージョン： 2.2.91
  • ブラウザ拡張機能ですか：いいえ

問題を再現する手順：


  1. PDF（本から抽出された1ページ）を開いて、レンダリングが不適切なフォントを確認します

image

期待される動作は何ですか？ （スクリーンショットを追加）
他のPDFリーダーでは、正常にレンダリングされます。
image

ビューアへのリンク（mozilla.github.io/pdf.js以外のサイトでホストされている場合、またはFirefox / Chrome拡張機能としてホストされている場合）：
現在のgithubページビューア： https ：

ノート：
PDF内のフォントを編集することで、それを機能させることができました。 現在は「TimesNewRoman PS」ですが、「TimesNewRoman」だけで再レンダリングすると修正されるようです。

コンソールエラーや、CMapの欠落などの解決策のその他の目に見える兆候はありません。

残念ながら、PDFを変更することは許可されていないため、PDFを再レンダリングすることは実行可能な解決策ではありません。

誰かがこれと可能な解決策についての洞察を与えることができれば、それは大いに感謝されます🤠

4-font-conversion
ソース
picture dmisdm

最も参考になるコメント

PDFは同じフォントを何度も定義しています。 たとえば、フォントLULQLP+TimesLTStd-Romanは9回定義されています。 それぞれが同じFontDescriptorと同じ埋め込みCFFデータストリームを参照します。

core / Evaluationor.jsのPartialEvaluator.prototype.preEvaluateFont()にフォントハッシュ計算があります。 ハッシュにエントリEncoding、ToUnicode、およびWidthsを追加します。 PDF内の一部のフォントは、幅も含めてすべてのエントリが同一であるため、同一のハッシュコードを取得します。 エントリFirstCharとLastCharのみが異なります。 フォントが同一のハッシュコードを取得する場合、OpenTypeに変換されないように、フォントがスキップされる可能性がありますか？

これは、元のPDFの2つのフォントを含む縮小PDFです。
issue10665_reduced.pdf

picture janpe2 2019年03月26日
👍4

全てのコメント3件

PDFは同じフォントを何度も定義しています。 たとえば、フォントLULQLP+TimesLTStd-Romanは9回定義されています。 それぞれが同じFontDescriptorと同じ埋め込みCFFデータストリームを参照します。

core / Evaluationor.jsのPartialEvaluator.prototype.preEvaluateFont()にフォントハッシュ計算があります。 ハッシュにエントリEncoding、ToUnicode、およびWidthsを追加します。 PDF内の一部のフォントは、幅も含めてすべてのエントリが同一であるため、同一のハッシュコードを取得します。 エントリFirstCharとLastCharのみが異なります。 フォントが同一のハッシュコードを取得する場合、OpenTypeに変換されないように、フォントがスキップされる可能性がありますか？

これは、元のPDFの2つのフォントを含む縮小PDFです。
issue10665_reduced.pdf

janpe2 picture janpe2 2019年03月26日
👍4

core / Evaluationor.jsのPartialEvaluator.prototype.preEvaluateFont()にフォントハッシュ計算があります。 ハッシュにエントリEncoding、ToUnicode、およびWidthsを追加します。 PDF内の一部のフォントは、幅も含めてすべてのエントリが同一であるため、同一のハッシュコードを取得します。 エントリFirstCharとLastCharのみが異なります。

本当に優れた分析、ありがとう。 これにより、バグを簡単に修正できました。

フォントが同一のハッシュコードを取得する場合、OpenTypeに変換されないように、フォントがスキップされる可能性がありますか？

いくつかのひどく生成されたPDFファイルでは、大量の同一のフォントが存在する可能性があり、 preEvaluateFontの目的は、重複するフォントをロード/解析する必要をなくすことでした。 したがって、 loadFontはhash esを比較し、可能であれば、すでにロード/解析されたフォントを使用します。
明らかに、これはすべて、 hashが実際に正しい/一意であるという事実にかかっていますが、幸いなことに、そのコードには何年にもわたってバグが比較的少ないです。

Snuffleupagus picture Snuffleupagus 2019年03月27日

助けてくれて本当にありがとう！

dmisdm picture dmisdm 2019年03月28日
このページは役に立ちましたか？
0 / 5 - 0 評価

関連する問題

AlexP3 picture AlexP3  ·  3コメント
anggikolo11 picture anggikolo11  ·  3コメント
jigskpatel picture jigskpatel  ·  3コメント
xingxiaoyiyio picture xingxiaoyiyio  ·  3コメント
kleins05 picture kleins05  ·  3コメント