Pdf.js: Formeln sind zu groß gemalt.

Erstellt am 23. Jan. 2013  ·  62Kommentare  ·  Quelle: mozilla/pdf.js

Schau es dir an
http://arxiv.org/pdf/0707.3195v1.pdf

Ab Seite 2 erscheinen alle Formeln zu groß und werden teilweise über den Rest des Textes gemalt. Andere PDF-Viewer zeigen dies korrekt an.

So zeigt pdf.js Seite 2:
wrong

So zeigt evince Seite 2:
right

3-pdf-broken 4-font-conversion 4-os-linux

Hilfreichster Kommentar

Entschuldigung, wenn dies unangemessen ist, aber ich werde ein Kopfgeld von 500 US-Dollar für die Behebung dieses Fehlers anbieten.

Bei ShareLaTeX verwenden wir PDF.js, um die aus den LaTeX-Dokumenten der Benutzer erstellten PDF-Dateien zu rendern. Daher stoßen unsere Benutzer wahrscheinlich häufiger auf diesen Fehler als der durchschnittliche Benutzer.

Ich konnte keinen Präzedenzfall oder Kommentar zum Anbieten einer Bug Bounty für dieses Projekt finden, also hoffe ich, dass es in Ordnung ist. Kontaktieren Sie mich unter https://www.bountysource.com/ einrichten oder wenn jemand anderes das Kopfgeld hinzufügen möchte.

Alle 62 Kommentare

Ich habe vergessen zu erwähnen: Ich verwende PDF Viewer 0.7.1 mit Firefox 18.0.1 unter Ubuntu Linux.

Sieht so aus, als ob es nur Linux betrifft

Windows zeigt jedoch auch einen Fehler im Protokoll an:
[16: 59: 53.199] Fehler beim Analysieren des Werts für 'Schriftgröße'. Erklärung fallen gelassen. @ http://arxiv.org/pdf/0707.3195v1.pdf
[16: 59: 53.569] Fehler beim Analysieren des Werts für 'font'. Erklärung fallen gelassen. @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh , denkst du, es ist verwandt?

@yurydelendik : Scheint nicht, ich habe den Stepper verwendet und beide Warnungen erscheinen auf der ersten Seite (die erste beim Einstellen des vertikalen arXiV-nr links, die zweite beim Beenden der Seite).

@yurydelendik Ich denke, wir können dies schließen. Ich kann das Problem bei der Entwicklung von Arch Linux x64, Firefox 22 und pdf.js nicht replizieren. Auch keine Probleme unter Windows 7 x64.

Ich habe es nur noch einmal überprüft. Das Problem besteht weiterhin auf meinen Maschinen.
(beide Ubuntu Linux 12.04, Firefox 22, Pdf.js 0.8.1)

Vielleicht ist es in der Entwicklung pdf.js behoben, ich weiß es nicht.

Lassen Sie mich wissen, ob ich etwas testen soll.

Vielleicht ist es in der Entwicklung pdf.js behoben, ich weiß es nicht.
Lassen Sie mich wissen, ob ich etwas testen soll.

@kaymes Bitte versuchen Sie, die Datei herunterzuladen und zu öffnen (indem Sie auf die Schaltfläche zum Öffnen der Datei rechts in der Symbolleiste PDF.js klicken) im Web-Viewer: http://mozilla.github.io/pdf.js /web/viewer.html.
Dies verwendet immer die neueste Version von PDF.js. Versuchen Sie dies also und prüfen Sie, ob die Datei korrekt angezeigt wird.

Ich habe gerade den Online-Viewer bei ausprobiert
http://mozilla.github.io/pdf.js/web/viewer.html. Es macht immer noch falsch
mit all den Zahnspangen viel zu groß gemacht. Es war noch ein Computer
aber auch eine mit Ubuntu 12.04 mit Firefox 22. Das Problem könnte also sein
Linux-spezifisch (oder sogar Ubuntu), aber es zeigt auf mindestens drei
verschiedene Maschinen.

Hmm, seltsam. In diesem Fall wäre es wohl Ubuntu-spezifisch, da es hier unter Arch Linux keine Probleme gibt. Jeden Tag etwas Neues lernen :-)

Ich habe gerade den Test gemacht, ob es die Schuld eines Addons ist. Ich habe Firefox gestartet
im abgesicherten Modus und öffnete das Dokument mit dem Online-Viewer. Das
Problem bleibt bestehen. So können Addons ausgeschlossen werden.

Und ich habe noch einen Test gemacht: Ich habe Firefox direkt von Mozilla heruntergeladen. Damit
Alle Ubuntu-Patches / Modifikationen sind weg. Und dann habe ich diesen angefangen
im abgesicherten Modus. Das Problem besteht immer noch.

Ich sehe das auch unter 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)

Ist dies immer noch ein Problem mit der neuesten PDF.js-Entwicklungsversion unter http://mozilla.github.io/pdf.js/web/viewer.html? Ich kann dies unter Arch Linux nicht reproduzieren.

Das Problem besteht weiterhin (Ubuntu 12.04, FF26).

selection_012

Unter Ubuntu-basierter Linux Mint ist dieser Fehler auch mit Google Chrome 34 (und Firefox 32.0a1) reproduzierbar, sodass es sich nicht um ein exklusives Firefox-Problem handelt. Opera 12.16 wird jedoch korrekt dargestellt.

Ich werde in diesem Kommentar nur die Wörter TeX und LaTeX und Mathe verwenden, damit die Leute diesen Fehler finden.

Dies scheint mit Antialiasing zu tun zu haben: Ich verwende Gnome 3.14 in einer Debian Jessie-Maschine, Firefox 33.0.2. Sowohl beim RGB- als auch beim Graustufen-Antialiasing habe ich das gleiche Problem, wenn die Option "Leichter Hinweis" ausgewählt ist (im Gnome Tweak Tool). Wenn ich zu einer der anderen Hinweisoptionen (Voll, Mittel oder Keine) wechsle, sieht es so aus, wie es aussehen soll.

Beachten Sie, dass Sie in Firefox mindestens die Registerkarte aktualisieren müssen, um die Änderung zu sehen.

Für mich (Arch Linux) tritt dieser Fehler auf, wenn ich einen Infinity- Patch für fontconfig / freetype verwende. Die Verwendung der Vanille-Pakete zeigt diesen Fehler nicht an.

Ich weiß nicht, ob es sich um die Patches oder die Konfiguration handelt, die mit den gepatchten Paketen geliefert wird.

Kann in Ubuntu 14.04 in Chrom und Firefox reproduziert werden. Beachten Sie, wie sich die Artefakte beim Skalieren des Dokuments ändern. Ich habe diesen Fehler in Dutzenden von pdfTeX-Dokumenten in pdf.js gesehen, z. B. sind auch Summenindizes betroffen.

Dies scheint wirklich ein vorgelagertes Problem zu sein, obwohl ich nicht sicher bin, wo ich es einreichen soll.

Ich habe Ubuntu 14.04 freetype / fontconfig ohne die meisten verteilungsspezifischen Patches neu erstellt, aber das Problem besteht weiterhin.

Ich habe auch den neuesten freetype / fontconfig von Ubuntu 15.10 installiert, aber das Problem besteht weiterhin.

Vielleicht muss dies als Upstream-Firefox (Linux) -Fehler abgelegt werden? Ich bin mir nur nicht sicher, ob es durch Firefox oder eine bestimmte Linux-Schriftartenbibliothek verursacht wird.

Hier ist ein minimaler Testfall:

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

Dies wird unter Ubuntu und Windows unterschiedlich dargestellt:

<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>

Vergessen Sie nicht, dass Chrome ebenfalls betroffen ist, sodass es sich wahrscheinlich nicht um einen Firefox-Fehler handelt.
Screenshot: Chrome 44 unter (Ubuntu-basiert) Linux Mint.
zwischenablage03

@jethrogb Danke, dass du diesen Upstream mit so vielen Details

Es scheint, dass die Leute von freedesktop zu dem Schluss kommen, dass dies teilweise immer noch ein pdfjs-Fehler ist. Hier gibt es also wahrscheinlich noch einiges zu tun.

Gibt es in der Zwischenzeit auch andere einfache Problemumgehungen als das Vergrößern, bis der Fehler verschwindet? Ich verwende häufig Sharelatex, in das anscheinend ein PDF-Viewer integriert ist.

Es ist ein pdf.js Fehler. Kurz gesagt, pdf.js erstellt ungültige Schriftarten für diese mathematischen Symbole. Anschließend kommt die Schriftart Auto-Hinter zu falschen Schlussfolgerungen, was zu einer falschen Anzeige führt.

Daher sollten pdf.js festlegen, wie PDF-Schriftarten konvertiert werden.

Ich bin auf dieses Problem mit der Erweiterung der Atom-PDF-Ansicht gestoßen, nur als weiterer Beweis, dass es kein Firefox-Problem ist. Screenshots, wie es in Atom , in PDF.js aussieht und wie es aussehen sollte .

Ich kann bestätigen, dass dieses Problem in Chrome in Ubuntu 15.10 besteht.

Dieser Fehler sollte jetzt behoben werden, indem eine aktuelle Freetype-Bibliothek installiert ist (> = 2.6.2).

Nein, der eigentliche Fehler liegt in der Konvertierung von pdf.js in Typ 1 in OpenType, wodurch ungültige Schriftzeichen entstehen, und AFAIK ist dies noch nicht behoben.

Oh, ich habe den Upstream-Bug falsch verstanden. Entschuldigung für die schlechten Informationen.
Übrigens erkenne ich diesen Fehler auf meinen beiden Debian-Computern (Jessie und Stretch) nicht.

das gleiche hier: überhaupt keine probleme!
Arch Linux x86_64 und mit Unendlichkeit gepatchtes Font-Zeug [*], Firefox 45.0.2
(das gleiche passiert mit Chrom 50.0.2661.75-1)

[*] Cairo-Infinality-Ultimate 1.14.6-1
fontconfig-infinality-ultimative 2.11.95-4
freetype2-infinality-Ultimate 2.6.3-2

Entschuldigung, wenn dies unangemessen ist, aber ich werde ein Kopfgeld von 500 US-Dollar für die Behebung dieses Fehlers anbieten.

Bei ShareLaTeX verwenden wir PDF.js, um die aus den LaTeX-Dokumenten der Benutzer erstellten PDF-Dateien zu rendern. Daher stoßen unsere Benutzer wahrscheinlich häufiger auf diesen Fehler als der durchschnittliche Benutzer.

Ich konnte keinen Präzedenzfall oder Kommentar zum Anbieten einer Bug Bounty für dieses Projekt finden, also hoffe ich, dass es in Ordnung ist. Kontaktieren Sie mich unter https://www.bountysource.com/ einrichten oder wenn jemand anderes das Kopfgeld hinzufügen möchte.

Übrigens: Dies wurde im Freetype https://bugs.freedesktop.org/show_bug.cgi?id=91829 vorgelagert behoben

Dies hat nichts mit FreeType zu tun, wie die Leute immer wieder sagen, und wie in der von Ihnen verlinkten FreeType-Ausgabe ausführlich besprochen, gibt es einen Fehler im Konverter Type1 to OpenType von pdf.js.

Dies hat nichts mit FreeType zu tun ... es gibt einen Fehler im Konverter Type1 to OpenType von pdf.js.

Tatsächlich handelt es sich um ein Problem im Zusammenhang mit FreeType, da nur diese Engine das Problem aufweist. Möglicherweise liegt ein Problem mit dem Konverter von pdf.js vor, und es ist hilfreich zu verstehen, warum dies geschieht. Leider enthält der obige Link keine detaillierten Erklärungen. Weitere Eingaben der FreeType-Experten würden diese Fehlerbehebung beschleunigen.

Eine von pdf.js konvertierte Schriftartdatei
Die in die PDF-Datei eingebettete Originalschriftdatei

Auswahlzitate aus dem FreeType-Fehlerbericht:

Die betreffende Schriftart hat ein Wurzelzeichen bei den Buchstaben 's'.

Die Schriftart enthält eine cmap, die die Position r' (not s '(übrigens) einem Glyphen namens .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' zuordnet

Font cmaps dürfen nicht im Auto-Hinter liegen!

Oh, es ist wahrscheinlich auch teilweise die Schuld von pdf.js, vielleicht komponiert die gefälschte cmap aus pdf.js, nicht aus der Originalschrift. Jemand muss überprüfen.

Die Originaldatei cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name radikalbigg 'an Position 0x72. Die untergeordnete Datei "CMEX10.pfb" im FireFox-Fehlerbericht hat auch den richtigen Glyphennamen.

Vorläufiger Fix in # 7482. Ich habe keine Ressourcen, um dies genauer zu untersuchen, wenn das Testen fehlschlägt, aber es könnte einfach sein. Die Schriftart im PDF ist etwas seltsam, da sie eine symbolische Schriftart hat, aber auch Unicode-Zuordnungen für einige der Symbole. Normalerweise verschieben wir für symbolische Schriftarten alle Glyphen in den Bereich für den privaten Gebrauch, wenn nur eine Identitäts-Unicode-Zuordnung vorhanden ist.

Ich kann # 7482 reproduzieren und behebt das Problem für mich zumindest auf der zweiten Seite des PDFs, auf das im ersten Beitrag verwiesen wird.

@brendandahl Super , danke. Ich werde überprüfen, ob Ihr Patch das Problem so schnell wie möglich behebt. Kann es zusammengeführt werden? (Es sieht so aus, als ob einige Tests fehlschlagen?)

Kann es zusammengeführt werden? (Es sieht so aus, als ob einige Tests fehlschlagen?)

Das wird mit dieser Art von Patch erwartet. Wir müssen jedoch die Unterschiede prüfen, bevor wir einen Anruf tätigen können.

Gute Fortschritte! Ich habe einige umfangreichere Tests durchgeführt und eine Komplikation festgestellt - das Update funktioniert für die Ausgabe von dvips + ghostscript, aber nicht für die Ausgabe von pdftex - wenn ich die Quelle für den obigen Testfall nehme und sie mit pdflatex kompiliere, wird die Ausgabe falsch gerendert .

Im Anhang finden Sie einen ausführlicheren Testfall mit einer der fehlerhaften Gleichungen aus der ursprünglichen Datei 0707.3195v1.pdf.

Die erste PDF-Datei wird direkt von pdflatex und dann wird dieselbe Ausgabe von latex->dvips->ps2pdf . Die Screenshots sind das Rendern von pdf.js mit der angewendeten Pull-Anforderung - es löst das Problem mit der pdftex-Ausgabe nicht, behebt es jedoch für die Ghostscript-Konvertierung.

Vermutlich hat die Art und Weise, wie die Schriftart von pdftex in die Ausgabe eingebettet wird, etwas anderes, was dazu führt, dass der Fehler weiterhin auftritt?

test-pdftex.pdf - immer noch kaputt
test-pdftex pdf - google chrome - with fix

test-ps2pdf.pdf - behoben
test dvi - test-ps2pdf pdf - google chrome - with fix

Original Latexquelle test.tex.txt

Hallo @jpallen ,

Wir haben uns bei ShareLaTeX etwas eingehender damit befasst, und es sieht so aus, als ob der obige Patch (https://github.com/mozilla/pdf.js/pull/7482 von @brendandahl) in Bezug auf Verschieben von Zeichen in den privaten Nutzungsbereich, deckt jedoch nicht alle erforderlichen Fälle ab. Die von ps2pdf generierten PDFs funktionieren, aber die direkt von pdflatex generierten PDFs haben immer noch dieses Rendering-Problem.

Wenn wir naiv alles in den Bereich der privaten Nutzung verschieben (z. B. https://github.com/brendandahl/pdf.js/compare/move-non-unicode-glyphs...briangough:put-all-symbolic-chars-in- Private-Use-Bereich), dann wird es korrekt gerendert. Dies ist jedoch nur ein Debugging-Beispiel, da ich davon ausgehe, dass dies keine gute Idee ist.

Zu diesem Zeitpunkt stößt unser Wissen an die Grenze und wir wissen nicht, wie wir die richtigen Symbole für den privaten Gebrauch identifizieren können. Können wir also irgendetwas tun, um dies voranzutreiben?

Wenn wir alles naiv in den Bereich für den privaten Gebrauch verschieben (z. B. brendandahl @ move-non-unicode-glyphs ... briangough: Alle symbolischen Zeichen in den Bereich für den privaten Gebrauch setzen), wird es korrekt gerendert. Dies ist jedoch nur ein Debugging-Beispiel, da ich davon ausgehe, dass dies keine gute Idee ist.

Ohne das oben Gesagte getestet zu haben, würde ich vermuten, dass dies tatsächlich zu einem schlechteren Rendering in vielen PDF-Dateien führen könnte, da dies (im Grunde) dazu führen könnte, dass Hinweise für alle symbolischen Schriftarten in bestimmten Schriftrenderern deaktiviert werden. (Beachten Sie, dass viele Schriftarten behaupten, symbolisch zu sein, auch wenn dies tatsächlich nicht der Fall ist.)

Zu diesem Zeitpunkt stößt unser Wissen an die Grenze und wir wissen nicht, wie wir die richtigen Symbole für den privaten Gebrauch identifizieren können. Können wir also irgendetwas tun, um dies voranzutreiben?

Da in den problematischen Fällen normale Type1-Schriftarten verwendet werden, denke ich immer noch, dass die richtige Lösung darin bestehen kann, sicherzustellen, dass wir beim Konvertieren von Type1-Schriftarten in Type1Font_wrap die richtigen Charset / Encoding -Informationen bereitstellen.

@jpallen Ich denke, wir müssen Schriftarten erkennen, die von Latex generiert werden, und diese Schriftarten sind Symbole (z. B. nach Namen oder der Art und Weise, wie sie erstellt werden), aber sie werden in den übrigen Fällen nicht als solche erkannt.

Wenn wir nicht alle Zeichen in den privaten Bereich verschieben, haben wir einige Vorteile, z. B. die Möglichkeit, Schriftarten in Eingabesteuerelementen zu verwenden, die Instrumentierung zu verbessern und die Engine in die Lage zu versetzen, ungültige Glyphen oder Schriftarten zu verwerfen und dennoch etwas lesbaren Text zu erhalten. Zu wissen, ob Glyphe ein Symbol ist, ist hier ein Schlüssel.

Eine vorläufige Idee, die auf PR # 7482 basiert, könnte möglicherweise darin bestehen, Zeichen in die PUA zu verschieben, wenn wir nicht darauf vertrauen können, dass die toUnicode -Daten korrekt sind. zB so etwas: https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus : issue-2594.

Großartig! Ich habe den neuen Patch in Snuf fleupagus ausprobiert: issue-2594 und er scheint für meinen Testfall und verschiedene pdflatex-Dokumente, die ich ausprobiert habe, gut zu funktionieren. : +1:

Als Test habe ich es in der Produktion im PDF-Viewer auf www.ShareLaTeX.com bereitgestellt , um

Wir haben diesen Patch (https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594) in den letzten 3 Wochen in der Produktion getestet und die LaTeX-Probleme beim Rendern von Schriftarten behoben uns, ohne dass andere Probleme auftauchen. Wäre toll wenn es danke aufgenommen werden kann. : +1:

Ich begann # 7705 zu überprüfen und fragte mich, warum mein ursprünglicher Patch nicht auch test-pdftex.pdf reparierte. Wenn man sich nur die Schriftdaten ansieht, sieht es so aus, als ob pdf.js den Großteil der Glyphen von DVFZZA+CMEX10 in den Bereich für den privaten Gebrauch verschieben sollte, da die meisten von ihnen keinen gültigen Glyphennamen für Unicode-Werte haben. Beispielsweise hat eines der problematischen Glyphen (charcode = 110 name = 'braceleftBig') keinen Unicode-Wert, wurde jedoch 'n' zugeordnet. Das Problem scheint darauf zurückzuführen zu sein, dass beim Erstellen einer Unicode-Map 68 Werte mit Glyphen mit übereinstimmenden Unicode-Werten korrekt enthalten sind. Nach dem Erstellen werden jedoch alle ursprünglichen Codierungswerte wieder hinzugefügt, sodass 110 mit 'n' gefüllt werden.

Ich bin mir nicht ganz sicher, was die richtige Lösung ist, denn wenn wir den Code entfernen, um wieder Codierungswerte hinzuzufügen, wird unsere Textauswahl von https://github.com/mozilla/pdf.js/commit/325f7afcca30c891ec7be06a5178c012a052bd55 zurückgeführt

Vielleicht hat @Snuffleupagus einige Gedanken ...

Wie https://github.com/mozilla/pdf.js/issues/2594#issuecomment -254289210 andeutet, enthielt die vorherige Version von PR # 7705 eine zu vereinfachte Lösung.

Ich habe daher einen neuen (und für mich wahrscheinlich letzten) Versuch zusammengestellt, dies zu beheben, der getestet werden kann mit: http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html.
Es wäre sehr hilfreich, wenn Personen, die derzeit von diesem Problem betroffen sind, die neueste Version von PR # 7705 testen und melden könnten, ob dies ausreicht, um dieses Problem zu beheben!

Funktioniert gut mit der Datei test-pdftex.pdf. Wir werden versuchen, sie diese Woche in der Produktion auf www.ShareLaTeX.com bereitzustellen, um festzustellen, ob Probleme gemeldet wurden.

Funktioniert gut mit der Datei test-pdftex.pdf. Wir werden versuchen, sie diese Woche in der Produktion auf www.ShareLaTeX.com bereitzustellen, um festzustellen, ob Probleme gemeldet wurden.

Wie im IRC besprochen, lesen Sie bitte http://logs.glob.uno/?c=mozilla%23pdfjs&s=21+Nov+2016&e=21+Nov+2016#c54315 . Wir möchten mit PR # 7705 fortfahren .
@briangough Haben Sie noch Ergebnisse beim Testen des Patches in der Produktion auf ShareLaTeX?

Wie bereits unter https://github.com/mozilla/pdf.js/issues/2594#issuecomment -259930252 erwähnt, wäre es am hilfreichsten, wenn diejenigen, die derzeit von diesem Problem betroffen sind, beim Testen der vorgeschlagenen Lösung helfen könnten zB die Vorschau in http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html und melden, ob diese Probleme behoben sind!

Wir möchten PR # 7705 landen, aber wir brauchen wirklich eine Bestätigung des Fixes, bevor wir dies tun.

Entschuldigung für die Verspätung. Der Patch funktioniert einwandfrei - keine Beschwerden unserer Benutzer, danke.

Schließen wie von # 7705 festgelegt, dank @Snuffleupagus und @brendandahl!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

jigskpatel picture jigskpatel  ·  3Kommentare

azetutu picture azetutu  ·  4Kommentare

zerr0s picture zerr0s  ·  3Kommentare

patelsumit5192 picture patelsumit5192  ·  3Kommentare

sujit-baniya picture sujit-baniya  ·  3Kommentare