Pdf.js: Fehler beim Laden von PDF, das Systemschriften verwendet

Dies schlägt fehl, da die Schriftart nicht geladen wird, wenn wir versuchen, sie in font_loader.js#L313 abzurufen .
Das Problem scheint zu sein, dass es angesichts von evaluator.js#L284 überhaupt nie geladen wird, da font.data in diesem Fall nicht definiert ist. Der Grund dafür ist, dass die betreffende Schriftart keine eingebettete Schriftartdatei hat, was bedeutet, dass wir in fonts.js zurückkehren, bevor wir font.data definieren. Siehe fonts.js#L2256 und fonts.js#L2303 .
Der Grund dafür, dass dies für uns in der Praxis kein größeres Problem darstellt, ist, dass es anscheinend nur PDFs (wie dieses Problem) betrifft, bei denen die Schriftartressource beispielsweise in einem XObject -Wörterbuch enthalten ist.

Ich weiß leider nicht, wie wir dieses Problem lösen könnten, da das Erstellen font.data ohne Schriftartdatei im aktuellen Code schwierig erscheint. Vielleicht würde dies "kostenlos" gelöst, wenn wir die Standardschriften in PDF.js einbetten würden?

PS Ich habe auch bemerkt, dass die Behebung dieses Problems eine (oder zwei) der Dateien beheben würde, die in http://bthorben.github.io/pdfRepo/#crashed aufgeführt sind.

Kann es eine Lösung wie diese geben:

1 - Option, um die Verwendung einer Standardschriftart oder einer Schriftart zuzulassen, die bereits für die genaue Datei verwendet wurde
2 - Option, um das Rendern dieses Elements zu überspringen
Dies kann helfen, mit der PDF-Datei weiterzuarbeiten, wenn einige Schriftarten fehlen, und nur als Warnung ausgegeben zu werden, nicht als Fehler.

Was denkst du?

Wir bevorzugen die erste Option, betten jedoch noch keine Schriftarten ein und verlassen uns darauf, dass das System diese für einige Funktionen enthält. Wir können es sicherlich ignorieren, sobald wir herausgefunden haben, wie man es richtig abschneidet (Für diese Schriftarten können wir auf Anfrage leere Buchstabenumrisse erstellen).

Eröffnen Sie zumindest die Möglichkeit, diesen Fehler zu fangen (...), anstatt einfach alles zu stoppen, bis Sie eine bessere Lösung gefunden haben. Leider unterbricht dieses Problem die Funktionalität in unserer Live-Umgebung, was ... schlecht ist.

Gibt es eine Problemumgehung? Oder eine Art Fehlererkennungsmechanismus, der von @xwcg vorgeschlagen wird?

Ein Dupe wurde hier abgelegt: https://bugzilla.mozilla.org/show_bug.cgi?id=1463728

Hallo an alle,
Ich habe den gleichen Fehler.
Darf ich wissen, ob es vor der formellen Behebung eine vorübergehende Problemumgehung für dieses Problem gibt?

Irgendwelche Updates dazu? Es ist von 2014 und immer noch nicht gelöst

@diego-lipinski-de-castro FYI, diese #9809-Zusammenführung hat dies behoben, wenn SieignoreErrors: true in die getDocument-Funktion übergeben. Wenn Sie npm pdfjs-dist verwenden, ist es noch nicht aktualisiert. Ich habe gerade aus dem Quellcode erstellt, und PDFs, die sich früher über Schriftarten beschwert haben, werden jetzt korrekt mit der Canvas-Ausgabe verarbeitet. Alles scheint in Ordnung.

@sirisian Danke für dein Update. Freue mich auf die Veröffentlichung

@sirisian weißt du wann das update für npm pdfjs-dist kommt? und ob es eine Problemumgehung für npm gibt?
Danke

Irgendwelche Updates zu diesem Fix-Release für npm pdfjs-dist ?

Hallo, ich stoße auch auf diesen Fehler. Gibt es eine Möglichkeit, Schriftarten, die nicht auf dem System vorhanden sind, durch eine Standardschriftart zu ersetzen?

Hallo @timvandermeij, wann werden wir diesen Fix wahrscheinlich in pdfjs-dist sehen?

Mit pdfjs-dist": "^2.2.2 set disableFontFace: false wurde dieses Problem bei mir behoben.

pdfjs.getDocument( { url: pdfUrl, disableFontFace: false, }

Wenn pdf.js keinen Text in einer bestimmten Schriftart lädt, sollte es meiner Meinung nach denselben Text mit einer Ersatzschriftart laden, die er anzeigen _könnte_ (z. B. die vom Benutzer in den Schriftarteinstellungen festgelegten Standardschriftarten), anstatt das Rendern zu stoppen die Seite und werfen einen Fehler. Dies war das Verhalten in Firefox 61 und früher, wenn die Option „Seiten erlauben, ihre eigenen Schriftarten anstelle Ihrer Auswahl oben zu wählen“ deaktiviert ist. Meiner Meinung nach ist es besser, Text in einer Ersatzschrift anzuzeigen, als gar nichts anzuzeigen.

Mit pdfjs-dist": "^2.2.2 set disableFontFace: false wurde dieses Problem bei mir behoben.

pdfjs.getDocument( { url: pdfUrl, disableFontFace: false, }

Dieser hat mein Problem gelöst, ich verwende pdfjs-dist ^2.0.943
Danke schön

Ich arbeite an einem Projekt, bei dem IE 11 erforderlich ist und die Sicherheitseinstellungen (verwaltet vom IT-Team) das Herunterladen benutzerdefinierter Schriftarten nicht zulassen. Dies führt zu einer PDF-Wiedergabe, die beim Rendern größtenteils leer ist und nur wenige Überschriften und kursive Zeichen aufweist.

Das Setzen disableFontFace: true bewirkt im IE 11 (und eigentlich in allen anderen Browsern) das Gegenteil. Die meisten Schriftarten werden dann gerendert, aber es werden Litaneifehler eingeführt, die wie folgt aussehen:

Warning: getPathGenerator - ignoring character: "Error: Requesting object that isn't resolved yet Times_path_i.".

Die Fehler weisen alle auf unterschiedliche Zeichen im Abschnitt Times_path_* der Nachricht hin. Das Dokument lädt die meisten Inhalte, aber Überschriften, Kursivschrift und andere Variationen fehlen visuell (obwohl der leere Text aufgrund der transparenten Textebene oben ausgewählt werden kann).

Ich stecke also fest zwischen der vollständigen Wiedergabe von Schriftarten in allen Browsern mit Ausnahme dieser verwalteten Version von IE 11 (aufgrund der vom Administrator erzwungenen Sicherheitseinstellung in Bezug auf Schriftarten) oder der teilweise fehlerhaften Wiedergabe von Schriftarten überall, weil ich versucht habe, einen Fix für IE 11 zu implementieren.

Irgendwelche Vorschläge?

irgendwelche Neuigkeiten dazu?

Hallo Team,
Ich habe alle möglichen Dinge ausprobiert, nichts kann den Fehler beheben.
gibt es irgendwelche neuigkeiten?

Dies ist eine große Auswirkung auf uns. Warum ist die Problemumgehung, disableFontFace=false festzulegen? Mein Verständnis ist, dass es bei disableFontFace=true egal ist, welche eingebetteten Schriftarten im PDF vorhanden sind (oder nicht). Ist das falsch?

irgendwelche Neuigkeiten dazu?

Vor 6 Jahren hatte @AllSeeingEye ein Problem und heute hat diese Bibliothek 594 ungelöste Probleme. Niemand gibt einen Af * über diesen Fehler, oder was? Ein Fehler, der für mich ein No-Go ist, muss nach anderen Bibliotheken wie pdf-lib suchen.

Guten Tag allerseits!

Beim Versuch, das Renderproblem der Textebene mit disableFontFace -Parametern zu lösen, traten ähnliche Probleme auf.

Auf disableFontFace: false einige Dokumente so aus:

Während auf disableFontFace: true das vorherige Dokument gut dargestellt wird, gibt es ein Problem mit einem anderen Dokument:

Alle diese Zellen waren nicht leer.
Einige Dokumente werden auf eine Weise gut gerendert, andere auf andere Weise.
Wie soll ich handeln?

Ich habe ein ähnliches Problem wie @Hatgor
Gibt es eine Lösung oder etwas, das getan werden kann, um dies richtig zu machen? Die oben genannten Lösungen funktionieren nicht. :|

Ich habe genau das gleiche Problem. Der Versuch, es in einem Lambda auf Node12 auszuführen, auf dem amazonlinux2 ausgeführt wird - was bedeutet, dass standardmäßig keine Schriftarten installiert sind. Es wäre WIRKLICH schön, wenn wir die 14 Standardschriftarten standardmäßig in pdfjs einbetten oder eine API zum Laden bereitstellen könnten, anstatt sich darauf zu verlassen, dass sie im Basissystem installiert sind. Bislang waren meine Bemühungen, die Schriftarten auf dem System zu installieren, ... alles andere als erfolgreich.

An diesem Punkt denke ich, dass ich jede PDF-Datei mit einer anderen Bibliothek wie pdf-lib vorverarbeiten könnte, um die 14 Standardschriftarten explizit einzubetten, und DANN zum Rendern an diese Bibliothek weiterzugeben. Etwas übertrieben und nervig, aber wenn es das Problem löst....

Nachdem ich buchstäblich stundenlang mit amazonlinux2 herumgebastelt habe, um Schriftarten zu installieren, KANN ich die nicht enthaltenen Schriftarten zum Rendern bringen, indem ich disableFontFace explizit auf false setze, aber dann schlagen die eingebetteten Schriftarten aus dem PDF mit demselben Symbol fehl, das im Kommentar von @Hatgor zu sehen ist.

OK, bisher kein Würfel in der Vorverarbeitung von PDFs zum Einbetten von Schriften. Gibt es vielleicht eine Möglichkeit, eine Schriftart einzufügen, die nicht in das PDF eingebettet ist? Ich kann die erforderlichen .ttf(s) woanders hosten, aber ich sehe nichts in der API, um eine beliebige Schriftart zu laden.