Pdf.js: Zufällige / offensichtliche "Fettdruck" / Korruption

Ich kann den Worker wegen des massiven Downloads, den dies bei jeder Ansicht verursacht, nicht "nicht" deaktivieren

Könnten Sie diesen Teil erklären?

Wenn Sie versuchen, getDocument mehrmals zu verwenden, verwenden Sie eine einzelne PDFWorker-Instanz. Es ist schwer zu sagen, warum Schriftarten beschädigt werden, aber ein Link zum Arbeitsbeispiel kann Licht ins Dunkel bringen. Können Sie ein Beispiel erstellen / veröffentlichen, das das Problem verursacht?

Ok, ich kann einen Link nicht einfach veröffentlichen. Wenn ich mit aktivierten Workern laufe, funktioniert es zu 100%. Wenn ich das Deaktivierungsflag setze, wird das oben gezeigte Problem zufällig angezeigt, möglicherweise 1 Instanz von 4.

Ich habe die Antwort "Nur die Arbeiter aktivieren" abgelehnt, indem ich "Warum" den Arbeiter deaktiviere, dh, ich zeige viele kleine PDFs ziemlich schnell an und füge einen 1,2-MB-Download für pdf_worker.js für hinzu Jedes Display ist nicht praktisch. Ich habe den Web-Worker-Code überprüft, um festzustellen, ob es für Worker eine Option gibt, das aufgerufene .js-Skript zwischenzuspeichern, aber ich habe nichts gefunden.

Meine anfängliche Vermutung (basierend auf dem Effekt) ist, dass es irgendwo etwas mit einem globalen Bereich gibt, das korrekt gelöscht wird, wenn das Skript für jede Instanz geladen wird. Dies führt zu einem Problem, wenn das Arbeitsskript wiederholt wiederverwendet wird. Da das Problem jedoch (!) Auf der ERSTEN PDF-Anzeige auftreten kann, weiß ich nicht, was ich sehen soll.

Ich habe die Antwort "Nur die Arbeiter aktivieren" abgelehnt, indem ich "Warum" den Arbeiter deaktiviere, dh, ich zeige viele kleine PDFs ziemlich schnell an und füge einen 1,2-MB-Download für pdf_worker.js für hinzu Jedes Display ist nicht praktisch.

@oddjobz Ich verstehe die Besorgnis immer noch nicht. Mit deaktiviertem Worker lädst du immer noch pdf.worker.js herunter, aber es passiert im Hauptthread. Die ordnungsgemäße Einrichtung auf dem Webserver ermöglicht das Zwischenspeichern der statischen Javascript-Datei und vermeidet das Herunterladen von 1,2 MB für jede Anforderung ohne zusätzlichen Aufwand. PDFWorker hilft beim Zwischenspeichern von Instanzen des Web Workers auf einer Seite (z. B. wenn mehrere getDocuments ausgeführt werden).

Sie sind sich nicht sicher, ob dieses Problem ohne Code für Ihre Lösung vollständig ist. Standardmäßig speichert PDF.js den Web-Worker-Code zwischen, wenn er auf einem Standard-Webserver mit Standardbrowser verwendet wird (in Standardkonfigurationen).

Nun, ich weiß nicht, was der Unterschied zwischen dem von mir verwendeten Code und dem von Ihnen verwendeten Code ist, aber irgendwo gibt es einen Unterschied. Erstens wird bei deaktiviertem Worker die Datei pdf_worker.js beim ersten Treffer "nur" einmal geladen. Wenn Worker aktiviert sind, wird der Code in jedes neue Dokument geladen, und nichts, was ich tue, scheint Auswirkungen auf das Caching zu haben. (dh es wird nicht zwischengespeichert) Ich vermute eher, dass Chrome-Entwickler das Caching deaktiviert haben, weil sie Probleme mit Web-Workern und zwischengespeichertem Code hatten. Soweit ich sehen kann, sind alle meine Header so, wie sie für das Caching sein sollten, aber das Caching findet nicht statt. (wohingegen andere Sachen zwischengespeichert sind)

Ich habe drei relevante Bits;
ein. Hauptcodeblock mit einem Skript-Tag
b. Onload, der die globalen Variablen festlegt
c. Eine eigenständige Klasse, die ein PDF in einem DIV anzeigt

Hauptcodeblock;

<script type="text/javascript" src="js/compatibility.js"></script>
<script type="text/javascript" src="js/pdf.js"></script>

Onload-Code;

    PDFJS.disableWorker = true;
    PDFJS.verbosity = PDFJS.VERBOSITY_LEVELS.debug;
    PDFJS.workerSrc = "/js/pdf.worker.js";

Klassendefinition;

JS.require('JS.Class',function(Class) {

    CLASS.PDFViewer = new Class({

        locked  : false,
        page        : 0,
        pages   : 0,
        pdf     : null,
        doc_id  : null,

        initialize: function(prefix) {
            this.canvas   = prefix+'-canvas';           // Canvas element ID we'll be rendering to
            this.prefix   = prefix;
            this.id_page  = '#'+this.canvas+'-page';    // Ident of page number
            this.id_pages = '#'+this.canvas+'-pages';   // Ident of page count
            this.setfocus(null);                        // Element to focus after render
        },
        reset:      function() { this.now_showing = null; console.log("PDF Reset")},
        set:        function(doc_id) { this.doc_id = doc_id; console.log("Docid:",doc_id) },
        load:       function() { this.fetch(this.doc_id); },
        set_doc:    function() {},
        setfocus: function(field_id) { this.focuson = field_id; },

        decode: function(base64) {
            var raw = atob(base64);
            var uint8Array = new Uint8Array(raw.length);
            for (var i = 0; i < raw.length; i++) {
                uint8Array[i] = raw.charCodeAt(i);
                }
          return uint8Array;
        },

        full_screen: function() {
            if( $('#'+this.prefix+'-hide-me').is(':visible') ) {
                $('#'+this.prefix+'-hide-me').hide();
                $('#'+this.prefix+'-full-screen').removeClass("col-sm-7");
                $('#'+this.prefix+'-full-screen').addClass("col-sm-12");
            } else {
                $('#'+this.prefix+'-hide-me').show();
                $('#'+this.prefix+'-full-screen').removeClass("col-sm-12");
                $('#'+this.prefix+'-full-screen').addClass("col-sm-7");
            }
            this.turn_page();
        },
        focus: function() {
            if(this.focuson) {
                console.log("SetFocus>>",this.focuson);
                setTimeout("$('"+this.focuson+"').focus()",100);
                this.focuson = null;
            }
        },
        display: function(pdf) {
            this.pdf = pdf;
            $(this.id_pages).text(this.pdf.numPages);
            this.pages = this.pdf.numPages;
            this.page = 1;
            this.turn_page();
        },
        fetch: function(rid) {
            if(this.locked) return false;
            var self = this;
            var src = '/images/default.pdf';
            function success(data) {
                if(!LIB.check_error(data)) return false;
                if(data.pdf) src = self.decode(data.pdf);
                self.locked = true;
                PDFJS.getDocument(src).then(function(pdf){ self.display(pdf); });
                return true;
            }
            ionman.call('nac.rpc.pdf_spec',{'rid': rid},success)
            return true;
        },
        turn_page: function() {
        var self = this;
            self.pdf.getPage(self.page).then(function(page) {
                var canvas = document.getElementById(self.canvas);
        var ctx = canvas.getContext('2d');
        var unscaledViewport = page.getViewport(1.0);
                canvas.width = $('#'+self.canvas).width();
                var scale = canvas.width / unscaledViewport.width;
                var viewport = page.getViewport(scale);
                canvas.height = viewport.height;
            var renderContext = { canvasContext: ctx, viewport: viewport };
        page.render(renderContext).promise.then(function(){
                setTimeout(function(){
                    self.locked = false;
                        self.focus();
                    },250);
                });
                $(self.id_page).text(self.page);
            });
        },
        next: function() {
            if( this.page == this.pages) return;
            this.page += 1;
            this.turn_page();
        },
        prev: function() {
            if( this.page == 1) return;
            this.page -= 1;
            this.turn_page();
        }
    });

So ich mache;

var viewer = CLASS.PDFViewer('pdf');
viewer.fetch();

Und ich bekomme das Standarddokument ist ein DIV mit der ID "pdf-canvas".

Lass uns das versuchen:

1. Öffnen Sie http://mozilla.github.io/pdf.js/web/viewer.html in Chrome
2. Öffnen Sie devtools auf der Netzwerkseite und zeigen Sie die geteilte Konsole an (klicken Sie auf dieser Registerkarte auf 'esc').
3. Stellen Sie sicher, dass keine Ausnahme vorliegt (deaktivieren Sie die Ausnahmeunterbrechung und aktualisieren Sie sie andernfalls).
4. Stellen Sie sicher, dass "Cache deaktivieren" deaktiviert ist (andernfalls deaktivieren und aktualisieren).
5. Führen Sie in der Konsole PDFJS.getDocument('http://mozilla.github.io/pdf.js/web/compressed.tracemonkey-pldi-09.pdf')
6. Beachten Sie, dass die zweite "pdf.worker.js" den Status "200 OK (aus Cache)" hat

Code-Schnipsel sind nicht hilfreich. Bitte stellen Sie irgendwo ein kleines Beispiel bereit (z. B. auf Github-Seiten).

Ja, ich sehe es. Dies scheint eine neuere Version von PDF.js zu sein, als ich verwende. Unter der Annahme, dass der Unterschied nicht das Problem ist, werde ich die Header vergleichen, die Varnish mit meinem Webserver ausgibt, um zu sehen, ob Ich kann erkennen, warum es nicht zwischengespeichert wird.

Ich vermute eher, dass Chrome-Entwickler das Caching deaktiviert haben, weil sie Probleme mit Web-Workern und zwischengespeichertem Code hatten.

Ich sehe keine Verbindung zwischen dieser und der Option disableWorker. Die Datei pdf.worker.js wird angefordert, unabhängig davon, ob sie wahr oder falsch ist. Das Problem muss also für das Caching irrelevant sein.

Der Einfachheit halber gehe ich davon aus, dass dies mit der Funktionsweise des Messaging im disableWorker-Modus zusammenhängt (der nicht wirklich getestet und nur zur Unterstützung älterer Browser und zur Erleichterung des Debuggens erstellt wurde). Es wird hilfreich sein, das Problem einzugrenzen, um einen minimalen Testfall zu erhalten, bei dem das Problem sichtbar ist (vorzugsweise online verfügbar).

Ok, das ist also interessant. Testen gegen localhost: 8443 auf einem Dummy-Zertifikat (wobei der Hostname! = Localhost), es wird nicht zwischengespeichert. Wenn ich gegen den Live-Server, Port 443 mit einem gültigen kommerziellen Zertifikat, teste, wird der Cache (!) Ausgeführt. Ich bin mir nicht ganz sicher, was ich davon halten soll. Ich werde weitere Tests durchführen, wenn ich etwas Zeit habe, aber für Jetzt werde ich die Web-Worker aktivieren und sehen, was passiert. (aber ich denke, irgendwo gibt es noch ein Problem ...)

Ich bin mir nicht ganz sicher, ob ich mir glaube. Also habe ich einige Screenshots hinzugefügt.

Cache deaktivieren ist definitiv nicht angekreuzt ...
(Webserverkonfiguration ist identisch)

Gibt es hier noch etwas zu tun? Soweit ich weiß, klingt dies nicht nach einem Fehler in PDF.js, sondern in der benutzerdefinierten Implementierung.

Es wird schön sein, einen Testfall zu haben, mit dem wir diesen (zeitweiligen?) Fehler reproduzieren können.

Es ist ein Fehler, ich werde eine Online-Demonstration produzieren, aber es wird einige Codierung und ein wenig Zeit in Anspruch nehmen ...

Hallo, ich habe das gleiche Problem.

Hier nichts Brauches geschrieben, nur das Repo von Github heruntergeladen

@ subhadip-codeclouds Ich glaube nicht, dass Sie das gleiche Problem haben. Bitte öffnen Sie eine separate Ausgabe und geben Sie die gewünschten Details an.

@ subhadip-codeclouds Wo finde ich dieses PDF? Ich habe ein ähnliches Problem und möchte es als Testfall verwenden.

Ich glaube, ich habe unter Ubuntu mit Chrome das gleiche Problem beim Rendern von Schriftarten (habe andere Plattformen nicht getestet). Ich verwende die neuesten pdf.js von master, und manchmal sieht ein PDF wie das PDF von @oddjobz und manchmal wie das PDF von @ subhadip-codeclouds aus. Dies scheint bei zufälligen PDFs zufällig zu geschehen.

Ich weiß nicht wirklich, was falsch ist oder wie ich es zuverlässig reproduzieren kann. Dies ist jedoch das Szenario. Ich verwende React, um eine dynamische, einseitige Website zu erstellen. Benutzer klicken häufig auf eine Registerkarte. Dadurch wird ein Iframe erstellt und pdf.js im Iframe angezeigt. Angesichts der Funktionsweise von React und meiner Website wird immer wieder ein Iframe erstellt und zerstört. Es kann eine Weile dauern, aber irgendwann bekomme ich immer eine Beschädigung beim Rendern von Schriftarten. Und sobald es für ein PDF passiert, passiert es zufällig mit anderen PDFs. Einige sind immer in Ordnung, andere nicht.

Gibt es irgendetwas (z. B. Debug-Flags), das ich aktivieren oder tun kann, um herauszufinden, was los ist? Ich sehe keine Fehler oder Warnungen in der Konsole.

Hier ist eine PDF-Datei, die beim Start fast immer zu einer Beschädigung beim Rendern von Schriftarten führt.
https://datalanche-sec-public.s3.amazonaws.com/filings/0001047469-15-008315/a2226328zex-31_2.htm.pdf

Eine Sache noch. Wenn ich in Chrome einen neuen Tab mit derselben URL öffne, werden die PDFs korrigiert. Wenn ich jedoch auf derselben Registerkarte bleibe, zu einer völlig anderen Website navigiere und dann zu meiner Website navigiere (ohne die Schaltfläche "Zurück"), sind die PDF-Dateien mit beschädigten Schriftarten immer noch beschädigt. Es scheint fast so, als ob alles, was passiert, den Speicher und / oder den Cache des Tabs beschädigt.

Möglicherweise handelt es sich um ein Caching-Problem in Chrome (weitere Informationen finden Sie unter https://github.com/mozilla/pdf.js/issues/7751#issuecomment-256683285).

Gibt es hierzu Neuigkeiten? das gleiche Problem haben

Obwohl ich das gelegentlich (unerklärlich) immer noch sehe, ist es sehr selten und in der Tat selten genug, dass ich wirklich aufgehört habe, mir darüber Sorgen zu machen. Das Problem, das ich zu haben schien, waren überlappende Operationen. Es "scheint" möglich zu sein, ein PDF-Dokument (z. B. die nächste Seite) zu bearbeiten, während ein anderer Vorgang noch ausgeführt wird, und dies scheint das Problem zu verursachen. Meine Lösung bestand darin, alle Operationen in einer Klasse zu verpacken und dann eine Hauptsperre an den Ein- und Ausstiegspunkten einzufügen, damit keine PDF-bezogenen Operationen in Konflikt geraten können - dies "scheint" feste Probleme für mich zu haben. Ich gehe vage davon aus, dass PDF-Inhalte in einem separaten Thread oder Arbeitsprozess ausgeführt werden, daher besteht die Möglichkeit eines Konflikts. Es ist eine Weile her, aber aus dem Speicher heraus denke ich, dass das Threading eine Option ist, und ich habe die Lösung durch Deaktivieren entdeckt, was sich negativ auf die Leistung auswirkte, aber das Problem löste.

Es passiert mir die ganze Zeit, aber es ist zufällig genug, dass ich keinen Testfall erstellen kann. Es ist jedoch durchaus möglich, dass es sich auch in meinem Fall um eine Speicherbeschädigung durch Threading handelt, aber ich dachte, Javascript sei Single-Threaded?

Ich dachte, Javascript sei Single-Threaded

Es ist. Ich denke, was @oddjobz bedeutet (?), Dass es in Chrome einen Fehler geben kann, wenn Sie mehr als eine HTML5-

Ich denke, (aus dem Speicher) wird die Option verwendet, eine neue Browserfunktion namens "Web Worker" zu verwenden, mit der Sie effektiv Javascript-Threads erstellen können. Wenn Sie diese Funktion deaktivieren, versuchen Sie, eine "große" PDF-Datei anzuzeigen siehe "warum" diese Funktion verwendet wird ... :)

Es wird die Option verwendet, eine neue Browserfunktion namens "Web Worker" zu verwenden ...
Wenn Sie diese Funktion deaktivieren und dann versuchen, eine "große" PDF-Datei anzuzeigen, wird angezeigt, warum diese Funktion verwendet wird

Bitte beachten Sie, dass OP anweist, diese Funktion zu deaktivieren. Dies bedeutet, dass keine Web Worker verwendet werden, was die Schuld auf den Browser überträgt und nichts mit JavaScript-Threading zu tun hat.

Es ist ein bisschen subtil, Javascript ist Single-Threaded, aber Chrome ist Multi-Threaded, und Web Worker ermöglichen es Ihnen, zwei Chrome-Prozesse auszuführen und die Kommunikation zwischen ihnen zu erleichtern. Ich denke, nur der Master erhält DOM-Zugriff, aber Sie können Sub-Threads für prozessorintensive Dinge verwenden, ohne den UI-Thread zu blockieren. Es macht mehr Spaß, wenn Sie feststellen, dass Sie Web-Worker erstellen können, die nicht an einen bestimmten Thread oder Tab gebunden sind, damit sie ein erneutes Laden der Seite effektiv überstehen (dh sie sind dauerhaft). Ich sehe eine Menge Probleme, die sich daraus ergeben ...

Sicher - aber mein Kommentar ist, dass ohne Threading (dh durch Implementieren meiner eigenen Sperre auf Thread-Ebene) 99% dieses Problems verschwinden. (für mich).

@oddjobz , @rpedela Versuchen Sie, die Hardware- / GPU-Beschleunigung zu deaktivieren, und Sie , ob das Problem weiterhin auftritt.

@yurydelendik , yup, das war offensichtlich, eines der ersten Dinge, die ich versuchte. (kein Unterschied)

@yurydelendik , meine Bewerbung ist seit mehr als 6 Monaten

Javascript ist ein Single-Thread, aber Chrome ist ein Multithread-Thread. Mit Web-Workern können Sie zwei Chrome-Prozesse ausführen und die Kommunikation zwischen ihnen erleichtern. Ich denke, nur der Master erhält DOM-Zugriff, aber Sie können Sub-Threads für prozessorintensive Dinge verwenden, ohne den UI-Thread zu blockieren.

Diese Aussage mit dem Begriff "Web Worker" ist verwirrend. Können Sie Referenzen angeben, um die obigen Aussagen zu überprüfen? Web Worker haben keinen Zugriff auf das DOM, und PDF.js zeigt das Malen im Haupt-Thread an. Meinen Sie damit den Renderprozess von Chrome? Die einzige Möglichkeit, DOM zu aktualisieren, ist der Hauptthread und nicht der Webworker.

Prozess, der beginnt, bevor der vorherige beendet wurde - Einfädeln oder nicht, Einsetzen einer manuellen Verriegelung, um zu verhindern, dass Vorgänge gestartet werden, bevor der vorherige beendet wurde.

Was genau meinen Sie in diesem Zusammenhang mit "Operationen", ist es die Lebensdauer des API-Aufrufs render() ?

@oddjobz Ich habe gerade den Thread noch einmal gelesen und es gibt viele widersprüchliche Aussagen zu verschiedenen Zeiten. Auch der Konfigurationsabschnitt ist widersprüchlich, z. B. kann ich das in keinem Browser unter Mac OS X lokal reproduzieren. Ich bin mir immer noch nicht sicher, ob Sie es mit dem Standard-Viewer (nicht Ihrem benutzerdefinierten) reproduzieren können. Ich werde diesen Fehler als ungültig / unvollständig schließen, um andere Thread-Teilnehmer nicht zu verwirren.

@oddjobz , @rpedela , @badams , @pholisma , @ subhadip-codeclouds Können Sie einen separaten Fehlerbericht mit genauen Konfigurationen bereitstellen , bei denen das Problem auftritt , und genauen Schritten, wann das Problem reproduziert werden kann (einschließlich PDF)? Wenn es sich um eine benutzerdefinierte Lösung handelt, stellen Sie einen öffentlichen Link dazu bereit.

Ok, dies ist der fragliche Code - Sie können den Fix an Ort und Stelle sehen.

Speziell für das Sperren habe ich eine Routine wie diese;

this.locked = true;
PDFJS.getDocument(path+doc_id).then(function(pdf) {
    $('#pdf-canvas-pages').text(pdf.numPages);
    self.pages = pdf.numPages;
    self.page = 1;
    self.pdf = pdf;
    pdf.getPage(1).then(function(page) { self.turnpage(); });
})

turnpage: function() {
    var self = this;
    self.pdf.getPage(self.page).then(function(page) {
        var canvas = document.getElementById('pdf-canvas');
        var ctx = canvas.getContext('2d');
        var unscaledViewport = page.getViewport(1);
        canvas.width = $('#pdf-canvas').width();
        var scale = canvas.width / unscaledViewport.width;
        var viewport = page.getViewport(scale);
        canvas.height = viewport.height;
        var renderContext = { canvasContext: ctx, viewport: viewport };
        page.render(renderContext);
        $('#pdf-canvas-page').text(self.page);
        self.locked = false;
    });
},

Ja, aus diesem Grund habe ich den Punkt damals nicht angesprochen. Es scheint sehr widerstrebend zu sein, überhaupt zu akzeptieren, dass es ein Problem gibt - geschweige denn, dass es behoben werden muss.

Das Problem mit dem obigen Snippet wurde von https://github.com/mozilla/pdf.js/pull/6571 behoben

Nun, was soll ich sagen, ich habe Mitte 2016 die neueste Version verwendet und hatte immer noch das Problem. Ich erinnere mich anscheinend daran, dass mir damals (wiederholt) gesagt wurde, dass es behoben wurde. (und wie viele andere konnte ich sehen, dass es nachweislich nicht so war)

Wie auch immer, für alle da draußen, die das gleiche Problem sehen, versuchen Sie, ein Schloss wie oben zu stecken und zu sehen, ob es einen Unterschied macht. Es sind nur zwei Zeilen.

@yurydelendik Dies geschieht ziemlich konsistent für unsere Benutzer (hauptsächlich unter Windows 7), aber ich konnte es unter OSX mit der neuesten Version reproduzieren, aber nicht zu 100% konsistent.

Wir verwenden keinen benutzerdefinierten Code, sondern gehen einfach wie folgt vor

<iframe
    style="height: 650px; width: 600px"
    src="/path/to/pdfjs/web/viewer.html?file=/path/to/file.pdf"
/>

Es scheint von einer Reihe von Faktoren abzuhängen, z. B. ob das Dokument einen anderen fett gedruckten Text enthält, und die anfängliche Zoomstufe (durch Vergrößern und Verkleinern wird dies manchmal behoben). Ich habe auch festgestellt, dass dies nur die Vorschau betrifft. und beim Drucken scheint das PDF beim Herunterladen perfekt zu rendern (ich denke, das liegt daran, dass pdf.js nur die bereitgestellte Datei an den Benutzer weitergibt).

Wir haben uns entschieden, diese Lösung nicht mehr zu verwenden und die Datei direkt auf den Computer des Benutzers herunterzuladen, aber ich werde versuchen, mir etwas Zeit zu nehmen, um einen reproduzierbaren Testfall zu erstellen, obwohl ich gestern bereits meinen ganzen Tag damit verbracht habe, diesen Fehler zu verfolgen.

@badams , ich kann bestätigen, dass Zoom auch ein Fix für mich war, ebenso wie eine Seite next / prev. Ich hatte auch den Eindruck, dass Fettdruck das Problem wahrscheinlicher machte.

Ich werde versuchen, mir etwas Zeit zu nehmen, um einen reproduzierbaren Testfall zu erstellen

@badams danke, alles, was alle Variationen

Hallo Leute,

Ich habe diese ganze Geschichte nicht richtig verstanden.
Gibt es schon einen Fix? Oder eine Art Implementierung, die ich machen sollte?

Grüße,
Tarcisio Pereira

Ich habe diese ganze Geschichte nicht richtig verstanden.

Ich glaube nicht, dass es jemand tut.

Dieser Thread wurde geschlossen, da er keine genauen Schritte zur Reproduktion des Problems enthält (und aufgrund einiger irreführender Empfehlungen in den Kommentaren). Wir erwarten nicht, dass das Problem zu 100% reproduzierbar ist, aber es wird großartig sein, wenn es mindestens einmal in 10 Fällen auftritt.

Mögliche Elemente, die dazu führen können, dass PDF.js auf diese Weise ausgeführt wird oder ein Fehler im Code vorliegt:

• Ein HTTP-Server oder -Browser verarbeitet HTTP-Bereichsanforderungen nicht ordnungsgemäß
• Ein Browser verarbeitet das Laden von Schriftarten oder den Canvas-Vorgang nicht ordnungsgemäß
• Benutzerdefinierte Lösungen stehen in Konflikt mit den oben genannten Vorgängen

FWIW Ich habe diese Beschädigung in seltenen Situationen bei der Bereitstellung von pdf.js (v1.7.376) gesehen. Unsere Bearbeitung von Bereichsanfragen scheint korrekt zu sein. Ich melde mich wieder, wenn ich zuverlässige Repro-Schritte finde ...

Wir hatten dieses Problem nur in Chrome. Nach dem Ändern des Zooms verschwindet es. Also haben wir showPreviousViewOnLoad auf false und hatten dieses Problem nie wieder.

@TZanke Könnten Sie klarstellen, warum das Entfernen von showPreviousViewOnLoad den Zoom ändern würde? Vielen Dank!

@tonyjin pdf.js Autozoom berechnet einen Zoomwert und speichert ihn im lokalen Speicher. Nach dem erneuten Laden der Seite wird der automatische Zooom nicht verwendet, sondern der zuvor berechnete Zoomwert. Und es sieht so aus, als ob beim erneuten Laden dieses Werts ein Problem auftritt.

Wenn Sie also showPreviousViewOnLoad deaktivieren, wird die AutoZoom-Funktion jedes Mal aktiviert, die Seite wird richtig gezoomt und es treten keine Renderprobleme auf.

@TZanke - Ich habe Ihren Ansatz ausprobiert, aber leider taucht das Problem manchmal immer noch auf .. :(