Pdf.js: Les formules sont trop grandes.

J'ai oublié de mentionner: j'utilise PDF Viewer 0.7.1 avec Firefox 18.0.1 sur Ubuntu Linux.

On dirait que cela n'affecte que Linux

Cependant, Windows affiche également une erreur dans le journal:
[16: 59: 53.199] Erreur lors de l'analyse de la valeur de 'font-size'. Déclaration abandonnée. @ http://arxiv.org/pdf/0707.3195v1.pdf
[16: 59: 53.569] Erreur lors de l'analyse de la valeur de «font». Déclaration abandonnée. @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh , pensez-vous que c'est lié?

@yurydelendik : Il semble que non, j'ai utilisé le stepper et les deux avertissements apparaissent sur la première page (le premier lors du réglage de l'arXiV-nr vertical à gauche, le second lors de la fin de la page).

@yurydelendik Je pense que nous pouvons fermer ça. Je ne peux pas reproduire le problème sur le développement d'Arch Linux x64, Firefox 22 et pdf.js. Aussi aucun problème sur Windows 7 x64.

Je viens de vérifier. Le problème persiste sur mes machines.
(Ubuntu Linux 12.04, Firefox 22, Pdf.js 0.8.1)

Peut-être que c'est corrigé dans le développement pdf.js, je ne sais pas.

Faites-moi savoir si vous voulez que je teste quelque chose.

Peut-être que c'est corrigé dans le développement pdf.js, je ne sais pas.
Faites-moi savoir si vous voulez que je teste quelque chose.

@kaymes Veuillez essayer de télécharger le fichier et de l'ouvrir (en cliquant sur le bouton Ouvrir le fichier, placé à droite de la barre d'outils PDF.js) dans le visualiseur Web: http://mozilla.github.io/pdf.js /web/viewer.html.
Cela utilise toujours la dernière version de PDF.js, veuillez donc essayer et voir si le fichier s'affiche correctement.

Je viens d'essayer la visionneuse en ligne à
http://mozilla.github.io/pdf.js/web/viewer.html. Ça rend toujours faux
avec toutes les accolades rendues bien trop grandes. C'était encore un autre ordinateur
mais aussi un exécutant Ubuntu 12.04 avec Firefox 22. Le problème pourrait donc être
Spécifique à Linux (ou même à Ubuntu) mais cela apparaît sur au moins trois
différentes machines.

Hmm, étrange. Dans ce cas, je suppose que ce serait spécifique à Ubuntu, car il n'y a aucun problème ici sur Arch Linux. Apprendre quelque chose de nouveau chaque jour :-)

Je viens de faire le test pour savoir si c'est la faute d'un addon. J'ai commencé Firefox
en mode sans échec et a ouvert le document à l'aide de la visionneuse en ligne. le
le problème persiste. Les addons peuvent donc être exclus.

Et j'ai fait un autre test: j'ai téléchargé Firefox directement depuis Mozilla. Alors
tous les correctifs / modifications d'Ubuntu ont disparu. Et puis j'ai commencé celui-ci
en mode sans échec. Le problème est toujours là.

Je vois cela aussi sur Ubuntu 13.04

[18:42:43.639] "PDF 8d10792f8d2028a66825b6ce6ab5b3c1 [1.4 GPL Ghostscript GIT PRERELEASE 9.05 / dvips(k) 5.95a Copyright 2005 Radical Eye Software] (PDF.js: 0.8.510)

Est-ce toujours un problème avec la dernière version de développement PDF.js sur http://mozilla.github.io/pdf.js/web/viewer.html? Je ne peux pas reproduire cela sur Arch Linux.

Le problème persiste (Ubuntu 12.04, FF26).

Sous Linux Mint basé sur Ubuntu, ce bogue est également reproductible avec Google Chrome 34 (et Firefox 32.0a1), ce n'est donc pas un problème exclusif de Firefox. Opera 12.16 rend cependant correct.

Je vais juste utiliser les mots TeX et LaTeX et maths dans ce commentaire afin que les gens puissent trouver ce bogue.

Cela semble être lié à l'anticrénelage: j'utilise gnome 3.14 dans une machine Debian Jessie, Firefox 33.0.2. Dans l'anticrénelage RVB et Niveaux de gris, lorsque l'option Léger indice est sélectionnée (dans Gnome Tweak Tool), j'ai le même problème. Lorsque je passe à l'une des autres options d'indication (Complet, Moyen ou Aucun), il ressemble à ce qu'il est censé ressembler.

Notez que dans Firefox, vous devez au moins actualiser l'onglet pour voir le changement.

Pour moi (Arch Linux), ce bogue apparaît si j'utilise un fontconfig / freetype patché à l'infini . L'utilisation des packages vanilla ne montre pas ce bogue.

Je ne sais pas si cela est lié aux correctifs ou à la configuration livrée avec les packages corrigés.

Peut se reproduire dans Ubuntu 14.04 dans Chromium et Firefox. Notez comment les artefacts changent lors de la mise à l'échelle du document. J'ai vu ce bug dans des dizaines de documents pdfTeX dans pdf.js, par exemple les indices de somme sont également affectés.

Cela semble vraiment être un problème en amont, même si je ne sais pas où le déposer.

J'ai reconstruit Ubuntu 14.04 freetype / fontconfig sans la plupart des correctifs spécifiques à la distribution, mais le problème persiste.

J'ai également installé le dernier freetype / fontconfig d'Ubuntu 15.10, mais le problème persiste.

Peut-être que cela doit être classé comme un bogue de Firefox (Linux) en amont? Je ne suis tout simplement pas sûr que cela soit causé par Firefox ou une bibliothèque de polices Linux particulière.

Voici un cas de test minimal:

\documentclass{article}
\begin{document}
$$ \sqrt{\frac{1}{2}} $$
\end{document}

Cela se produit différemment sur Ubuntu et Windows:

<style type="text/css">
* { margin:0; padding: 0 }
@font-face { font-family:"g_font_1";src:url(data:font/opentype;base64,T1RUTwAJAIAAAwAQQ0ZGIEG/4oQAAACcAAACWU9TLzJL4jE4AAAC+AAAAGBjbWFwAA0ApQAAA1gAAAAsaGVhZKsnRLAAAAOEAAAANmhoZWEDBvRyAAADvAAAACRobXR4BdwAAAAAA+AAAAAMbWF4cAADUAAAAAPsAAAABm5hbWUiztZPAAAD9AAAAgRwb3N0AAMAAAAABfgAAAAgAQAEBAABAQEOTU5QRUhJK0NNRVgxMAABAQFF+BsA+BwB+B0C+B4D+B8EHgoAH4uLHgoAH4uLDAdzHPRwHAWu+ZgFHQAAAKoPHQAAAAAQHQAAAK8RHQAAABwdAAABYhIABQEBDSAtOkBWZXJzaW9uIDAuMTFTZWUgb3JpZ2luYWwgbm90aWNlTU5QRUhJK0NNRVgxME1OUEVISStDTUVYMTBNZWRpdW0AAAAAAAAAAAADAQEDC62LDhwB9BwAABYOHAPoHABvFhwBYxz3jhUc//8GHP8oHAPqBRz/fRz/MgUc//kc//ccAAAc//4cAAAc//8IHAAAHP/8HAANHP/1HAABHP//CBwARBwAawUcAOcc+88FHAAhHAAAHAADHAAAHAAGHAAaCBwCJhwJHQUcAAIcAAccAAIcAAkcAAAcAAUIHAALHP/4HAAJHP/0Hhz/8BwAABz//Rz/8xz//Rz/8ggOHgoEeW8MCboKuguzkgwMs5IMDYsMDh0AAAAcEwBrAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbAsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLAAAAAAADAiQB9AAFAAACigK7AAAAjAKKArsAAAHfADEBAgAAAAAGAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAqMjEqAAAAcgByAwT0cABkAwQLkAAAAAAAAAAAAa8AAAAAAHIAAwAAAAEAAwABAAAADAAEACAAAAAEAAQAAQAAAHL//wAAAHL///+QAAEAAAAAAAEAAAAAEAAAAAAAXw889QAAA+gAAAAAngt+JwAAAACeC34nAAD0cA//AwQAAAARAAAAAAAAAAAAAQAAAwT0cAAA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAfQAAAPoAAAAAFAAAAMAAAAAABQA9gABAAAAAAAAABAAAAABAAAAAAABAA0AEAABAAAAAAACAAcAHQABAAAAAAADAAgAJAABAAAAAAAEAA0ALAABAAAAAAAFAAwAOQABAAAAAAAGAAAARQABAAAAAAAHAAcARQABAAAAAAAIAAcATAABAAAAAAAJAAcAUwADAAEECQAAACAAWgADAAEECQABABoAegADAAEECQACAA4AlAADAAEECQADABAAogADAAEECQAEABoAsgADAAEECQAFABgAzAADAAEECQAGAAAA5AADAAEECQAHAA4A5AADAAEECQAIAA4A8gADAAEECQAJAA4BAE9yaWdpbmFsIGxpY2VuY2VNTlBFSEkrQ01FWDEwVW5rbm93bnVuaXF1ZUlETU5QRUhJK0NNRVgxMFZlcnNpb24gMC4xMVVua25vd25Vbmtub3duVW5rbm93bgBPAHIAaQBnAGkAbgBhAGwAIABsAGkAYwBlAG4AYwBlAE0ATgBQAEUASABJACsAQwBNAEUAWAAxADAAVQBuAGsAbgBvAHcAbgB1AG4AaQBxAHUAZQBJAEQATQBOAFAARQBIAEkAKwBDAE0ARQBYADEAMABWAGUAcgBzAGkAbwBuACAAMAAuADEAMQBVAG4AawBuAG8AdwBuAFUAbgBrAG4AbwB3AG4AVQBuAGsAbgBvAHcAbgADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA);}
td { border: 1px solid #ccc; width: 9px; height: 10px; }
</style>
<table cellspacing="0" cellpadding="0" style="border-collapse:collapse;empty-cells:show">
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>
<div style='font:16px "g_font_1";position:absolute;top:0;left:0'>r</div>

https://bugzilla.mozilla.org/show_bug.cgi?id=1200077

N'oubliez pas que Chrome est également affecté, il ne s'agit donc probablement pas d'un bogue de Firefox.
Capture d'écran: Chrome 44 sous Linux Mint (basé sur Ubuntu).

https://bugs.freedesktop.org/show_bug.cgi?id=91829

@jethrogb Merci d'avoir déposé ceci en amont avec autant de détails! J'espère que le problème sera bientôt résolu.

Il semble que les gens de freedesktop concluent qu'il s'agit encore en partie d'un bogue pdfjs. Il y a donc probablement encore du travail à faire ici.

De plus, en attendant, existe-t-il des solutions de contournement simples autres que le zoom avant jusqu'à ce que le bogue disparaisse? J'utilise fréquemment sharelatex, qui semble avoir une visionneuse pdfjs intégrée.

C'est une faute de pdf.js. En un mot, pdf.js crée des polices invalides pour ces symboles mathématiques. Par la suite, l'auto-hinter de la police tire des conclusions erronées qui déclenchent un mauvais affichage.

Ainsi, pdf.js devrait corriger la manière dont les polices pdf sont converties.

J'ai rencontré ce problème avec l'extension atom pdf view , tout comme une preuve supplémentaire que ce n'est pas un problème de Firefox. Captures d'écran de son apparence dans atom , dans PDF.js et à quoi il devrait ressembler .

Je peux confirmer que ce problème existe dans Chrome dans Ubuntu 15.10.

Ce bogue devrait maintenant être corrigé avec une bibliothèque Freetype à jour installée (> = 2.6.2)

Non, le vrai bogue est dans la conversion de type 1 en OpenType de pdf.js qui crée des glyphes de polices invalides, et AFAIK ce n'est pas encore corrigé.

Oh, j'ai mal lu le bug en amont. Désolé pour les mauvaises informations.
Au fait, je ne détecte pas ce bug sur mes deux machines Debian (Jessie et Stretch).

pareil ici: aucun problème!
Arch Linux x86_64 et les polices de caractères corrigées avec l'infini [*], Firefox 45.0.2
(la même chose se produit avec le chrome 50.0.2661.75-1)

[*] cairo-infinality-ultime 1.14.6-1
fontconfig-infinality-ultime 2.11.95-4
freetype2-infinality-ultime 2.6.3-2

Toutes mes excuses si cela est inapproprié, mais je vais offrir une prime de 500 $ pour ce bug en cours de correction.

Chez ShareLaTeX, nous utilisons PDF.js pour rendre le PDF produit à partir des documents LaTeX des utilisateurs, et donc nos utilisateurs rencontrent probablement ce bogue plus souvent que l'utilisateur moyen.

Je n'ai trouvé aucun précédent ou commentaire concernant l'offre d'une prime de bogue pour ce projet, alors j'espère que ça va. N'hésitez pas à me contacter à [email protected]. Si vous préférez, nous pouvons configurer la prime en séquestre avec quelque chose comme https://www.bountysource.com/ , ou si quelqu'un d'autre souhaite ajouter à la prime.

BTW: Cela a été corrigé en amont dans freetype https://bugs.freedesktop.org/show_bug.cgi?id=91829

Cela n'a rien à voir avec FreeType, comme les gens ne cessent de le dire et comme cela est discuté en détail dans le problème FreeType que vous liez, il y a un bogue dans le convertisseur Type1 vers OpenType de pdf.js.

Cela n'a rien à voir avec FreeType ... il y a un bogue dans le convertisseur Type1 vers OpenType de pdf.js.

En fait, c'est un problème lié à FreeType car seul ce moteur rencontre le problème. Il peut y avoir un problème avec le convertisseur de pdf.js, et il sera utile de comprendre pourquoi cela se produit. Malheureusement, le lien ci-dessus ne fournit pas les explications détaillées. Plus de commentaires des experts FreeType accéléreraient cette résolution de bogue.

Un fichier de police converti par pdf.js
Le fichier de police d'origine intégré dans le PDF

Citations de choix tirées du rapport de bogue FreeType:

La police en question a un signe racine à la lettre «s».

La police contient un cmap qui mappe la position r' (not s ', BTW) à un glyphe appelé .notdef'. Since the auto-hinter accesses a font not by glyph names but by a Unicode mapping (either a real one or a synthesized), it believes that glyph r' est présent

Les cmaps de police ne doivent pas mentir à l'auto-hinter!

Oh, c'est probablement partiellement la faute de pdf.js, peut-être que le faux cmap est compilé à partir de pdf.js, pas à partir de la police d'origine. Quelqu'un doit vérifier.

Le fichier original cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name radicalbigg 'à la position 0x72. Le fichier sous-défini `CMEX10.pfb 'dans le rapport de bogue FireFox a également le nom de glyphe correct.

Correction provisoire dans # 7482. Je n'ai pas de ressources pour examiner cela davantage si les tests échouent, mais cela pourrait être simple. La police dans le pdf est un peu étrange car elle a une police symbolique, mais a également des mappages unicode pour certains des symboles. Habituellement, pour les polices symboliques, nous déplaçons tous les glyphes vers la zone d'utilisation privée s'il n'y a qu'un mappage d'identité unicode.

Je peux reproduire # 7482 corrige le problème pour moi au moins sur la deuxième page du PDF lié dans le premier article.

@brendandahl Génial, merci. Je vais vérifier si votre patch le corrige dès que possible. Est-il capable de fusionner? (Il semble que certains tests échouent?)

Est-il capable de fusionner? (Il semble que certains tests échouent?)

C'est attendu avec ce genre de patch. Cependant, nous devons inspecter les différences avant de passer un appel.

Bon progrès! J'ai fait des tests plus approfondis et j'ai trouvé une complication - le correctif fonctionne pour la sortie produite par dvips + ghostscript mais pas pour la sortie produite par pdftex - si je prends la source du cas de test ci-dessus et la compile avec pdflatex, la sortie est rendue incorrectement .

Vous trouverez ci-joint un cas de test plus exhaustif comprenant l'une des équations brisées du fichier d'origine 0707.3195v1.pdf.

Le premier fichier pdf est produit directement par pdflatex et ensuite la même sortie est produite par latex->dvips->ps2pdf . Les captures d'écran sont le rendu de pdf.js avec la demande d'extraction appliquée - cela ne résout pas le problème de la sortie pdftex, mais le corrige pour la conversion ghostscript.

Vraisemblablement, il y a quelque chose de différent dans la façon dont la police est intégrée dans la sortie par pdftex qui provoque toujours le bogue?

test-pdftex.pdf - toujours cassé

test-ps2pdf.pdf - corrigé

Source latex d'origine test.tex.txt

Salut @jpallen , je veux juste vous faire savoir que cela semble résoudre le problème sur Sharelatex lorsque je passe le compilateur à XeLatex.

Nous avons approfondi un peu plus cela à ShareLaTeX, et il semble que le correctif ci-dessus (https://github.com/mozilla/pdf.js/pull/7482 par @brendandahl) est sur la bonne ligne en termes de déplacer des personnages dans la zone d'utilisation privée, mais ne couvre pas tous les cas nécessaires. Les PDF générés par ps2pdf fonctionnent, mais ceux générés directement par pdflatex ont toujours ce problème de rendu.

Si nous déplaçons naïvement _everything_ vers la zone d'utilisation privée (par exemple https://github.com/brendandahl/pdf.js/compare/move-non-unicode-glyphs...briangough:put-all-symbolic-chars-in- private-use-area), puis il est rendu correctement. Cependant, ce n'est qu'un exemple de débogage car je suppose que ce n'est pas une bonne idée.

À ce stade, nos connaissances atteignent la limite et nous ne savons pas comment identifier les bons symboles à mettre dans la zone d'utilisation privée. Alors, pouvons-nous faire quelque chose pour faire avancer les choses?

Si nous déplaçons naïvement tout dans la zone d'utilisation privée (par exemple brendandahl @ move-non-unicode-glyphs ... briangough: put-all-symbolic-chars-in-private-use-area), alors le rendu est correct. Cependant, ce n'est qu'un exemple de débogage car je suppose que ce n'est pas une bonne idée.

Sans avoir testé ce qui précède, je soupçonne que cela pourrait en fait conduire à un rendu plus mauvais dans de nombreux fichiers PDF, car cela pourrait (essentiellement) entraîner la désactivation des indices pour toutes les polices symboliques dans certains rendus de polices. (Notez que beaucoup de polices prétendent être symboliques, même lorsqu'elles ne le sont pas.)

À ce stade, nos connaissances atteignent la limite et nous ne savons pas comment identifier les bons symboles à mettre dans la zone d'utilisation privée. Alors, pouvons-nous faire quelque chose pour faire avancer les choses?

Étant donné que les cas problématiques utilisent des polices Type1 normales, je pense toujours que la bonne solution _peut_ être de s'assurer que nous fournissons des informations Charset / Encoding lors de la conversion des polices Type1 en Type1Font_wrap .

@jpallen Je pense que nous devons reconnaître les polices générées par latex et que ces polices sont des symboles (par exemple par leur nom ou la manière dont elles sont créées), mais elles ne seront pas reconnues comme telles dans le reste des cas.

Ne pas déplacer _tous_ les caractères dans la zone privée nous donne certains avantages, par exemple la possibilité d'utiliser des polices dans les contrôles d'entrée, une meilleure instrumentation, et la capacité du moteur de rejeter les glyphes ou polices invalides tout en obtenant du texte un peu lisible. Donc, savoir si le glyphe est un symbole est une clé ici.

Une idée provisoire, basée sur PR # 7482, pourrait peut-être être de déplacer des caractères vers le PUA lorsque nous ne pouvons pas être sûrs que les données toUnicode sont correctes; par exemple quelque chose comme ceci: https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus : issue-2594.

Génial! J'ai essayé le nouveau patch dans Snuf fleupagus: issue-2594 et il semble bien fonctionner pour mon cas de test et divers documents pdflatex que j'ai essayés. : +1:

En tant que test, je l'ai déployé en production dans la visionneuse PDF sur www.ShareLaTeX.com , pour voir si des problèmes inattendus se présentent aujourd'hui.

Nous avons testé ce patch (https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594) en production au cours des 3 dernières semaines et il a corrigé les problèmes de rendu des polices LaTeX pour nous, sans aucun autre problème. Ce serait génial si cela peut être inclus merci. : +1:

J'ai commencé à examiner # 7705 et à me demander pourquoi mon correctif original ne corrigeait pas également test-pdftex.pdf . En regardant simplement les données de police, il semble que pdf.js devrait déplacer la majorité des glyphes de DVFZZA+CMEX10 vers la zone d'utilisation privée car la plupart d'entre eux n'ont pas de nom de glyphe valide vers des valeurs unicode. Par exemple, l'un des glyphes problématiques (charcode = 110 name = 'braceleftBig') n'a pas de valeur unicode mais il était mappé à 'n'. Le problème semble provenir du moment où nous construisons une carte Unicode, elle contient correctement 68 valeurs avec des glyphes qui ont des valeurs Unicode correspondantes, mais après l'avoir construite, nous rajoutons toutes les valeurs de codage d'origine, donc 110 est rempli avec `` n ''.

Je ne suis pas tout à fait sûr de la bonne solution, car si nous supprimons le code pour ajouter des valeurs d'encodage, notre sélection de texte régressera à partir de https://github.com/mozilla/pdf.js/commit/325f7afcca30c891ec7be06a5178c012a052bd55

Peut-être que @Snuffleupagus a quelques réflexions ...

_ Comme le suggère https://github.com/mozilla/pdf.js/issues/2594#issuecomment -254289210, la version précédente du PR # 7705 contenait une solution trop simpliste._

J'ai donc mis en place une nouvelle (et pour moi probablement la dernière) tentative de résolution de ce problème, qui peut être testée avec: http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html.
Il serait très utile que les personnes actuellement affectées par ce problème puissent tester la dernière version de PR # 7705 et signaler si cela suffit pour résoudre ce problème!

Fonctionne bien sur le test-pdftex.pdf, nous allons essayer de le déployer en production sur www.ShareLaTeX.com cette semaine et voir s'il y a des problèmes signalés.

Fonctionne bien sur le test-pdftex.pdf, nous allons essayer de le déployer en production sur www.ShareLaTeX.com cette semaine et voir s'il y a des problèmes signalés.

Comme indiqué sur IRC, veuillez vous référer à http://logs.glob.uno/?c=mozilla%23pdfjs&s=21+Nov+2016&e=21+Nov+2016#c54315 , nous aimerions aller de l'avant avec le PR # 7705 .
@briangough Avez-vous encore des résultats de test du patch en production sur ShareLaTeX?

Comme mentionné précédemment dans https://github.com/mozilla/pdf.js/issues/2594#issuecomment -259930252, il serait très utile que les personnes actuellement affectées par ce problème puissent aider à tester la solution proposée, ce qui peut être fait en utilisant par exemple, l'aperçu dans http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html, et signalez s'il résout ces problèmes!

Nous aimerions décrocher le PR # 7705, mais nous avons vraiment besoin de confirmation du correctif avant de le faire.

Désolé pour le retard. Le patch fonctionne bien - aucune plainte de nos utilisateurs, merci.

Clôture fixée par # 7705, grâce à @Snuffleupagus et @brendandahl!