Pdf.js: Times New Roman PS yang dirender dengan buruk

Dibuat pada 22 Mar 2019  ·  3Komentar  ·  Sumber: mozilla/pdf.js

Lampirkan (disarankan) atau Tautkan ke file PDF di sini:
EMG8 -Cambridge Essentail Gold Maths 8-B 117.pdf

Konfigurasi:

  • Peramban web dan versinya: Chrome 73
  • Sistem operasi dan versinya: * Macos 10.14.1 *
  • Versi PDF.js :
  • Apakah ekstensi browser: Tidak

Langkah-langkah untuk mereproduksi masalah:


  1. Buka PDF (satu halaman yang diekstrak dari buku) dan lihat font yang ditampilkan dengan buruk

image

Apa perilaku yang diharapkan? (tambahkan tangkapan layar)
Pada pembaca PDF lainnya, ini ditampilkan dengan baik:
image

Tautan ke pemirsa (jika dihosting di situs selain mozilla.github.io/pdf.js atau sebagai ekstensi Firefox/Chrome):
Penampil halaman github saat ini: https://mozilla.github.io/pdf.js/web/viewer.html

Catatan:
Kami telah berhasil membuatnya bekerja dengan mengedit font dalam PDF. Saat ini "Times New Roman PS", rendering ulang hanya dengan "Times New Roman" tampaknya memperbaikinya.

Tidak ada kesalahan konsol, atau tanda-tanda solusi lain yang terlihat seperti CMaps yang hilang.

Sayangnya kami tidak diizinkan untuk mengubah PDF, jadi merender ulang setiap PDF bukanlah solusi yang tepat.

Jika ada yang bisa memberikan wawasan tentang ini dan solusi yang mungkin, itu akan sangat dihargai

4-font-conversion

Komentar yang paling membantu

PDF mendefinisikan font yang sama berkali-kali. Misalnya, font LULQLP+TimesLTStd-Roman didefinisikan sembilan kali. Masing-masing mengacu pada FontDescriptor yang sama dan aliran data CFF tertanam yang sama.

Ada perhitungan hash font di PartialEvaluator.prototype.preEvaluateFont() di core/evaluator.js. Itu menambahkan entri Encoding, ToUnicode, dan Widths di hash. Beberapa font dalam PDF mendapatkan kode hash yang identik karena semua entri yang disebutkan identik, bahkan Lebar. Hanya entri FirstChar dan LastChar yang berbeda. Jika font mendapatkan kode hash yang identik, dapatkah itu menyebabkan font dilewati sehingga tidak akan dikonversi ke OpenType?

Ini adalah PDF yang diperkecil yang berisi dua font dari PDF asli
issue10665_reduced.pdf

Semua 3 komentar

PDF mendefinisikan font yang sama berkali-kali. Misalnya, font LULQLP+TimesLTStd-Roman didefinisikan sembilan kali. Masing-masing mengacu pada FontDescriptor yang sama dan aliran data CFF tertanam yang sama.

Ada perhitungan hash font di PartialEvaluator.prototype.preEvaluateFont() di core/evaluator.js. Itu menambahkan entri Encoding, ToUnicode, dan Widths di hash. Beberapa font dalam PDF mendapatkan kode hash yang identik karena semua entri yang disebutkan identik, bahkan Lebar. Hanya entri FirstChar dan LastChar yang berbeda. Jika font mendapatkan kode hash yang identik, dapatkah itu menyebabkan font dilewati sehingga tidak akan dikonversi ke OpenType?

Ini adalah PDF yang diperkecil yang berisi dua font dari PDF asli
issue10665_reduced.pdf

Ada perhitungan hash font di PartialEvaluator.prototype.preEvaluateFont() di core/evaluator.js. Itu menambahkan entri Encoding, ToUnicode, dan Widths di hash. Beberapa font dalam PDF mendapatkan kode hash yang identik karena semua entri yang disebutkan identik, bahkan Lebar. Hanya entri FirstChar dan LastChar yang berbeda.

Analisis yang sangat bagus, terima kasih; ini membuat bug mudah diperbaiki!

Jika font mendapatkan kode hash yang identik, dapatkah itu menyebabkan font dilewati sehingga tidak akan dikonversi ke OpenType?

Dalam beberapa file PDF yang dihasilkan dengan buruk mungkin ada sejumlah besar font yang identik, dan tujuan preEvaluateFont hanyalah untuk menghindari keharusan memuat/mengurai yang duplikat. Oleh karena itu loadFont akan membandingkan hash es, dan jika memungkinkan gunakan font yang sudah dimuat/diuraikan.
Jelas ini semua bergantung pada fakta bahwa hash es sebenarnya benar/unik, tetapi untungnya ada sedikit bug dalam kode itu selama bertahun-tahun.

Ini luar biasa terima kasih banyak atas bantuannya!

Apakah halaman ini membantu?
0 / 5 - 0 peringkat