Pdf.js: SVG-Pfad ist fälschlicherweise in 2 Knoten unterteilt
Anhängen (empfohlen) oder Link zur PDF-Datei hier:
test4.pdf
Aufbau:
- Webbrowser und seine Version: Chrome 56.0.2924.76
- Betriebssystem und seine Version: Linux Mint 18.3
- PDF.js-Version: Commit c0d6e46e392b327996eb0964b7932cb5bdde1727
- Ist eine Browsererweiterung: nein
Schritte zum Reproduzieren des Problems:
- Führen Sie "Knoten pdf2svg.js test4.pdf" aus
- Laden Sie die Ausgabe test4.1.svg in Chrome
- Überprüfen Sie das Fehlerprotokoll der Konsole. Sie werden dies sehen:
Was ist das erwartete Verhalten? (Screenshot hinzufügen)
Keine Fehler.
Was schief gelaufen ist? (Screenshot hinzufügen)
Ein Pfad in der Ausgabe wurde in 2 Teile aufgeteilt.
Das anfängliche "M" befindet sich in einem Knoten und das folgende "L" befindet sich im nächsten Knoten.
Diese sollten sich im selben Knoten befinden.
Link zu einem Viewer (sofern auf einer anderen Website als mozilla.github.io/pdf.js oder als Firefox/Chrome-Erweiterung gehostet):
johnkingsley
Alle 4 Kommentare
Dies kann mit Fehler Nr. 9167 zusammenhängen.
johnkingsley
am 6. Feb. 2019
Ich denke, der Täter ist hier:
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533 -L534
Ich bin mit der Funktionsweise von OperatorList nicht sehr vertraut, aber es sieht so aus, als ob die Operatorlisten in Blöcke von etwa 1000 Operatoren aufgeteilt sind. Manchmal wird die Blockgrenze in der Mitte einer PDF-Pfaddefinition platziert. Dies erzeugt zwei OPS.constructPath Operatoren und letzterer beginnt nicht mit einem moveTo .
Klingt das plausibel?
Anstatt OperatorList und seine Konstante CHUNK_SIZE ändern, sollte svg.js korrigiert werden. Vielleicht so: Aufeinanderfolgende OPS.constructPath Operatoren sollten zu einem <svg:path> Knoten kombiniert werden, wenn es keinen dazwischen liegenden Path-Painting-Operator gibt...
janpe2
am 12. Feb. 2019
Ich bin mit der Funktionsweise von
OperatorListnicht sehr vertraut, aber es sieht so aus, als ob die Operatorlisten in Blöcke von etwa 1000 Operatoren aufgeteilt sind.
Richtig; dies soll ermöglichen, dass das Rendern beginnt, bevor das gesamte OperatorList (dh die Seite) geparst wurde, wodurch die Gesamtzeit, die vom Laden der Seite bis zum vollständigen Rendern benötigt wird, reduziert wird.
Klingt das plausibel?
Ja, und es sollte leicht zu überprüfen sein (erhöhen Sie einfach den Wert stark , um diese Aufteilung effektiv zu deaktivieren).
Anstatt
OperatorListund seine KonstanteCHUNK_SIZEändern, sollte svg.js korrigiert werden.
Zugegeben, das Ändern der Konstanten ist definitiv keine akzeptable Lösung. Zunächst einmal würde es nichts weiter tun, als den Fehler an eine andere Stelle zu verschieben. Zweitens, und viel wichtiger, könnte eine Änderung weitreichende Auswirkungen auf die allgemeine Rendering-Performance im Canvas-Backend haben.
Vielleicht so: Aufeinanderfolgende
OPS.constructPathOperatoren sollten zu einem<svg:path>Knoten kombiniert werden, wenn es keinen dazwischen liegenden Path-Painting-Operator gibt...
Das klingt wiederum total vernünftig.
Snuffleupagus
am 12. Feb. 2019
Ich kann bestätigen, dass das Problem verschwindet, wenn ich CHUNK_SIZE auf 10000000 erhöhe.
(und ich stimme zu, dass dies keine richtige Lösung ist)
Danke für Ihre Hilfe.
johnkingsley
am 13. Feb. 2019
Verwandte Themen
xingxiaoyiyio
·
3Kommentare
dmisdm
·
3Kommentare
SehyunPark
·
3Kommentare
timvandermeij
·
4Kommentare
PeterNerlich
·
3Kommentare
Hilfreichster Kommentar
Richtig; dies soll ermöglichen, dass das Rendern beginnt, bevor das gesamte
OperatorList(dh die Seite) geparst wurde, wodurch die Gesamtzeit, die vom Laden der Seite bis zum vollständigen Rendern benötigt wird, reduziert wird.Ja, und es sollte leicht zu überprüfen sein (erhöhen Sie einfach den Wert stark , um diese Aufteilung effektiv zu deaktivieren).
Zugegeben, das Ändern der Konstanten ist definitiv keine akzeptable Lösung. Zunächst einmal würde es nichts weiter tun, als den Fehler an eine andere Stelle zu verschieben. Zweitens, und viel wichtiger, könnte eine Änderung weitreichende Auswirkungen auf die allgemeine Rendering-Performance im Canvas-Backend haben.
Das klingt wiederum total vernünftig.