Pdf.js: Times New Roman PS mal rendu

Créé le 22 mars 2019 · 3Commentaires · Source: mozilla/pdf.js

Joindre (recommandé) ou créer un lien vers le fichier PDF ici :
EMG8 -Cambridge Essentail Gold Maths 8-B 117.pdf

Configuration:

Navigateur Web et sa version : Chrome 73
Système d'exploitation et sa version : * Macos 10.14.1 *
Version PDF.js :
Est une extension de navigateur : Non

Étapes pour reproduire le problème :

Ouvrez le PDF (c'est une seule page extraite d'un livre) et voyez les polices mal rendues

Quel est le comportement attendu ? (ajouter une capture d'écran)
Sur n'importe quel autre lecteur PDF, le rendu est correct :

Lien vers une visionneuse (si hébergé sur un site autre que mozilla.github.io/pdf.js ou en tant qu'extension Firefox/Chrome) :
Visionneuse de pages github actuelle : https://mozilla.github.io/pdf.js/web/viewer.html

Remarques:
Nous avons réussi à le faire fonctionner en modifiant les polices dans le PDF. Il s'agit actuellement de "Times New Roman PS", le restituer avec juste "Times New Roman" semble le corriger.

Il n'y a pas d'erreurs de console ou d'autres signes visibles de solutions telles que des CMap manquantes.

Malheureusement, nous ne sommes pas autorisés à modifier les PDF, donc le re-rendu de chacun n'est pas une solution viable.

Si quelqu'un peut donner un aperçu de cela et d'une solution possible, ce serait grandement apprécié

4-font-conversion

Source

dmisdm

Commentaire le plus utile

Le PDF définit plusieurs fois les mêmes polices. Par exemple, la police LULQLP+TimesLTStd-Roman est définie neuf fois. Chacun fait référence au même FontDescriptor et au même flux de données CFF intégré.

Il existe un calcul de hachage de police dans PartialEvaluator.prototype.preEvaluateFont() dans core/evaluator.js. Il ajoute les entrées Encoding, ToUnicode et Widths dans le hachage. Certaines polices du PDF obtiennent des codes de hachage identiques car toutes les entrées mentionnées sont identiques, même les largeurs. Seules les entrées FirstChar et LastChar diffèrent. Si les polices obtiennent des codes de hachage identiques, une police peut-elle être ignorée afin qu'elle ne soit pas convertie en OpenType ?

Voici un PDF réduit qui contient deux polices du PDF original
issue10665_reduced.pdf

janpe2 le 26 mars 2019

👍4

Tous les 3 commentaires

Voici un PDF réduit qui contient deux polices du PDF original
issue10665_reduced.pdf

janpe2 le 26 mars 2019

👍4

Il existe un calcul de hachage de police dans PartialEvaluator.prototype.preEvaluateFont() dans core/evaluator.js. Il ajoute les entrées Encoding, ToUnicode et Widths dans le hachage. Certaines polices du PDF obtiennent des codes de hachage identiques car toutes les entrées mentionnées sont identiques, même les largeurs. Seules les entrées FirstChar et LastChar diffèrent.

Vraiment excellente analyse, merci; cela a rendu le bogue facile à corriger !

Si les polices obtiennent des codes de hachage identiques, une police peut-elle être ignorée afin qu'elle ne soit pas convertie en OpenType ?

Dans certains fichiers PDF mal générés, il peut y avoir d'énormes quantités de polices identiques, et le but de preEvaluateFont était simplement d'éviter d'avoir à charger/analyser les doublons. Par conséquent, loadFont comparera les hash es, et si possible utilisera une police déjà chargée/parsée.
Évidemment, tout dépend du fait que les hash sont en fait corrects/uniques, mais heureusement, il y a eu relativement peu de bogues dans ce code au fil des ans.