Pdf.js: "Gras" / corruption aléatoire / apparent

Je ne peux pas "ne pas" désactiver le worker en raison du téléchargement massif que cela provoque sur chaque vue

Pouvez-vous expliquer cette partie?

Si vous essayez d'utiliser getDocument plusieurs fois, utilisez une seule instance de PDFWorker. Il est difficile de dire ce qui cause la corruption des polices, mais le fait d'avoir un lien vers l'exemple de travail peut nous éclairer. Pouvez-vous créer / publier un exemple qui cause le problème?

Ok, je ne peux pas facilement publier un lien. Si je cours avec les travailleurs activés, cela fonctionne à 100%. Si je définis l'indicateur de désactivation, vous voyez le problème ci-dessus, au hasard, peut-être 1 instance de 4.

J'évitais la réponse de "juste activer les travailleurs" en détaillant "pourquoi" je désactive le travailleur, c'est-à-dire que j'affiche assez rapidement beaucoup de petits PDF, et en ajoutant un téléchargement de 1,2 Mo pour pdf_worker.js pour chaque affichage n'est pas pratique. J'ai regardé le code du web-worker pour voir s'il y a une option pour que les ouvriers mettent en cache le script .js sur lequel ils sont appelés, mais je n'ai rien réussi à trouver.

Ma première estimation (basée sur l'effet) est qu'il y a quelque chose quelque part avec une portée globale qui est effacée correctement si le script est chargé pour chaque instance, ce qui pose un problème si le worker scripté est réutilisé à plusieurs reprises. Cependant (!) Étant donné que le problème peut se produire sur le PREMIER affichage PDF, je ne sais pas trop quoi regarder.

J'évitais la réponse de "juste activer les travailleurs" en détaillant "pourquoi" je désactive le travailleur, c'est-à-dire que j'affiche assez rapidement beaucoup de petits PDF, et en ajoutant un téléchargement de 1,2 Mo pour pdf_worker.js pour chaque affichage n'est pas pratique.

@oddjobz Je ne comprends toujours pas le problème. Avec le travailleur désactivé, vous _toujours_ télécharger pdf.worker.js mais cela se passe sur le fil principal. Une configuration correcte sur le serveur Web permet la mise en cache du fichier javascript statique et évite le téléchargement de 1,2 Mo pour chaque demande sans effort supplémentaire. PDFWorker doit aider à la mise en cache des instances du web worker sur une seule page (par exemple lorsque plusieurs getDocuments sont exécutés).

Vous ne savez pas si ce problème est complet sans code pour votre solution, par défaut, PDF.js met en cache le code de travail Web lorsqu'il est utilisé sur un serveur Web standard avec navigateur standard (dans les configurations par défaut).

Eh bien, je ne sais pas quelle est la différence entre le code que j'utilise et le code que vous avez, mais il y a une différence quelque part. Premièrement, avec le worker désactivé, le pdf_worker.js est chargé une fois sur le premier hit "seulement". Avec les travailleurs activés, il charge le code sur chaque nouveau document et rien de ce que je fais ne semble avoir d'effet sur la mise en cache. (c'est-à-dire qu'il n'est pas mis en cache) Je soupçonne plutôt que parce que les développeurs Chrome avaient des problèmes avec les travailleurs Web et le code en cache, ils ont désactivé la mise en cache. Pour autant que je puisse voir, tous mes en-têtes sont tels qu'ils devraient être pour la mise en cache, mais la mise en cache ne se produit pas. (alors que d'autres éléments sont mis en cache)

J'ai trois bits pertinents;
une. Bloc de code principal avec une balise de script
b. Onload qui définit les variables globales
c. Une classe autonome qui affiche un PDF dans un DIV

bloc de code principal;

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

code de téléchargement;

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

définition de classe;

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();
        }
    });

Moi aussi;

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

Et je reçois le document par défaut est un DIV avec l'ID "pdf-canvas".

Essayons ça:

1. Ouvrez http://mozilla.github.io/pdf.js/web/viewer.html dans Chrome
2. Ouvrez les outils de développement sur la page Réseau et affichez la console partagée (appuyez sur 'esc' sur cet onglet)
3. Assurez-vous qu'il n'est pas intercepté dans une exception (désactivez la rupture d'exception et actualisez sinon)
4. Assurez-vous que "Désactiver le cache" est désactivé (décochez et actualisez sinon)
5. Dans la console, exécutez PDFJS.getDocument('http://mozilla.github.io/pdf.js/web/compressed.tracemonkey-pldi-09.pdf')
6. Remarquez que le deuxième "pdf.worker.js" a le statut "200 OK (à partir du cache)"

Les extraits de code ne sont pas utiles. Veuillez déployer un petit exemple quelque part (par exemple sur les pages github)

Oui, je le vois ... cela semble être une version plus récente de PDF.js que celle que j'utilise ... en supposant que la différence ne soit pas le problème, je comparerai les en-têtes que Varnish propose à mon serveur Web pour voir si Je peux voir pourquoi ce n'est pas en cache

Je soupçonne plutôt que parce que les développeurs Chrome avaient des problèmes avec les travailleurs Web et le code mis en cache, ils ont désactivé la mise en cache.

Je ne vois pas de connexion entre cela et l'option disableWorker. Le pdf.worker.js est demandé, qu'il soit vrai ou faux. Le problème ne doit donc pas concerner la mise en cache.

Pour plus de simplicité, je suppose que cela est lié au fonctionnement de la messagerie en mode disableWorker (qui n'est pas vraiment testé et créé uniquement pour prendre en charge les navigateurs hérités et faciliter le débogage). Cela aidera à affiner le problème pour avoir un cas de test minimal où le problème est visible (de préférence accessible en ligne).

Ok, donc c'est intéressant .. test contre localhost: 8443 sur un cert factice (où le nom d'hôte! = Localhost), il ne cache pas. Quand je teste contre le serveur en direct, le port 443 avec un certificat commercial valide, il met en cache (!) ... je ne sais pas trop quoi en faire .. fera encore des tests quand j'aurai un peu de temps, mais pour maintenant je vais activer les web workers et voir ce qui se passe. (mais je pense qu'il y a encore un problème là-dedans quelque part ...)

Je ne suis pas tout à fait sûr de me croire ... j'ai donc ajouté quelques captures d'écran ...

Désactiver le cache n'est définitivement pas coché ...
(la configuration du serveur Web est identique)

Y a-t-il autre chose à faire ici? D'après ce que je comprends, cela ne ressemble pas à un bogue dans PDF.js, mais plutôt dans l'implémentation personnalisée.

Ce sera bien d'avoir un cas de test permettant de reproduire cet échec (intermittent?).

C'est un bug, je vais faire une démonstration en ligne, mais cela prendra du codage et un peu de temps ...

Salut, j'ai le même problème.

Rien d'écrit de personnalisé ici, vient de télécharger le repo depuis Github

@ subhadip-codeclouds Je ne pense pas que vous ayez le même problème. Veuillez ouvrir un numéro séparé et fournir les détails demandés.

@ subhadip-codeclouds Où puis-je trouver ce pdf? J'ai un problème similaire et j'aimerais l'utiliser comme cas de test.

Je crois que j'ai le même problème de rendu de police sur Ubuntu avec Chrome (je n'ai pas testé d'autres plates-formes). J'utilise le dernier pdf.js de master, et parfois un PDF ressemblera au PDF de @oddjobz et parfois il ressemblera au PDF de @ subhadip-codeclouds. Cela semble se produire au hasard sur des PDF aléatoires.

Je ne sais pas vraiment ce qui ne va pas ni comment le reproduire de manière fiable. Cependant, c'est le scénario. J'utilise React pour créer un site Web dynamique d'une seule page. Les utilisateurs cliquent souvent sur un onglet, ce qui crée un iframe et affiche pdf.js dans l'iframe. Compte tenu du fonctionnement de React et de mon site Web, un iframe est créé et détruit à plusieurs reprises. Cela peut prendre un certain temps, mais finalement j'obtiendrai toujours une corruption de rendu de police. Et une fois que cela se produit pour un PDF, cela commencera à arriver à d'autres PDF de manière aléatoire. Certains vont toujours bien, d'autres non.

Y a-t-il quelque chose (par exemple les indicateurs de débogage) que je peux activer ou faire pour aider à comprendre ce qui se passe? Je ne vois aucune erreur ou avertissement dans la console.

Voici un PDF qui se termine presque toujours par une corruption de rendu de police au démarrage.
https://datalanche-sec-public.s3.amazonaws.com/filings/0001047469-15-008315/a2226328zex-31_2.htm.pdf

Encore une chose. Si j'ouvre un nouvel onglet dans Chrome avec la même URL, les PDF sont corrigés. Cependant, si je reste dans le même onglet, navigue vers un site Web complètement différent, puis navigue vers mon site Web (sans utiliser le bouton retour), les fichiers PDF avec des polices corrompues sont toujours corrompus. Il semble presque que tout ce qui se passe corrompe la mémoire et / ou le cache de l'onglet.

Il s'agit probablement d'un problème de mise en cache dans Chrome (voir https://github.com/mozilla/pdf.js/issues/7751#issuecomment-256683285 pour plus de détails).

Une mise à jour pour ceci? avoir le même problème

Bien que je le vois encore (inexplicablement) à l'occasion, c'est très rare et, en effet suffisamment rare, j'ai vraiment arrêté de m'en soucier. Le problème que je semblait avoir était le chevauchement des opérations. Il "semble" possible d'opérer sur un document pdf (page suivante par exemple) alors qu'une autre opération est encore en cours, et c'est cela qui semble poser le problème. Ma solution était d'encapsuler toutes les opérations dans une classe, puis d'insérer un verrou principal sur les points d'entrée et de sortie afin qu'aucune opération liée au pdf ne puisse entrer en conflit - cela «semble» avoir des choses fixes pour moi. Je suppose vaguement que les fichiers pdf s'exécutent dans un thread ou un processus de travail séparé, d'où la possibilité d'un conflit. C'était il y a peu de temps, mais de mémoire, je pense que le threading est une option et j'ai découvert la solution en la désactivant, ce qui a eu un impact négatif sur les performances, mais a résolu le problème.

Cela m'arrive tout le temps, mais c'est suffisamment aléatoire pour que je ne puisse pas créer de cas de test. Cependant, il est tout à fait possible que ce soit une corruption de mémoire due au threading dans mon cas aussi, mais je pensais que Javascript était monothread?

Je pensais que Javascript était un thread

Il est. Je pense que @oddjobz signifie (?)

Je pense (de mémoire) qu'il utilise l'option d'utiliser une nouvelle fonctionnalité de navigateur appelée "travailleurs Web", qui vous permet effectivement de créer des fils javascript .. si vous désactivez cette fonctionnalité, essayez d'afficher un "grand" PDF, vous voir "pourquoi" cette fonctionnalité est utilisée ... :)

il utilise la possibilité d'utiliser une nouvelle fonctionnalité de navigateur appelée "web workers" ...
si vous désactivez cette fonctionnalité, puis essayez d'afficher un "grand" PDF, vous voyez "pourquoi" cette fonctionnalité est utilisée

Veuillez noter que OP demande de désactiver cette fonctionnalité, signifie que les Web Workers ne sont pas utilisés, ce qui déplace le blâme sur le navigateur et n'a rien à voir avec le "threading" JavaScript.

C'est un peu subtil, Javascript est mono-thread, mais Chrome est multi-thread, et les web workers vous permettent d'exécuter deux processus Chrome et facilite la communication entre eux. Je pense que seul le maître a accès au DOM, mais vous pouvez utiliser des sous-threads pour des tâches gourmandes en processeur sans bloquer le thread de l'interface utilisateur. Cela devient plus amusant lorsque vous trouvez que vous pouvez créer des travailleurs Web qui ne sont pas attachés à un fil ou à un onglet spécifique, afin qu'ils survivent efficacement à un rechargement de page (c'est-à-dire qu'ils sont persistants). Je vois beaucoup de problèmes qui découlent de cela ...

Bien sûr - mais mon commentaire est que sans thread (c'est-à-dire en implémentant mon propre verrouillage au niveau du thread), 99% de ce problème disparaît. (pour moi).

@oddjobz , @rpedela essayez de désactiver l'accélération matérielle / gpu et voyez si le problème persiste.

@yurydelendik ,

@yurydelendik , mon application est en ligne depuis plus de 6 mois, je suis heureux que tout problème restant soit "différent" et très probablement une erreur d'utilisateur ou un document étrange occasionnel. LE problème que j'avais, qui, bien que non cohérent, était reproductible à 100%, c'est parti. Il était (à mon humble avis) causé par un chevauchement entre les opérations sur les documents, c'est-à-dire un processus commençant avant la fin de la précédente - threading ou non, mettant un verrou manuel pour empêcher les opérations de commencer avant que la précédente ne soit terminée. L'exemple facilement reproduit consistait à numériser rapidement un document vers l'avant et à lancer le traitement "suivant" avant que la page précédente n'ait complètement terminé le rendu.

Javascript est monothread, mais Chrome est multithread, et les web workers vous permettent d'exécuter deux processus Chrome et facilitent la communication entre eux. Je pense que seul le maître a accès au DOM, mais vous pouvez utiliser des sous-threads pour des tâches gourmandes en processeur sans bloquer le thread de l'interface utilisateur.

Cette déclaration avec le terme "travailleur Web" prête à confusion. Pouvez-vous fournir des références pour vérifier les déclarations ci-dessus? Les Web Workers n'ont aucun accès au DOM par conception, et PDF.js effectue une peinture sur le thread principal. Voulez-vous dire le processus de rendu de Chrome? Le seul moyen de mettre à jour DOM est toujours à partir du thread principal et non des travailleurs Web.

Le processus commençant avant la fin du précédent - threading ou non, mise en place d'un verrou manuel pour empêcher les opérations de commencer avant que le précédent ne soit terminé, le fixe.

Qu'entendez-vous exactement par «opérations» dans ce contexte, est-ce la durée de vie de l'appel render() de l'API?

@oddjobz Je viens de relire le fil de discussion et il y a beaucoup de déclarations contradictoires à différentes périodes de temps. La section de configuration est également en conflit, par exemple, je ne peux pas reproduire cela localement sur n'importe quel navigateur sous Mac OSX. Je ne suis toujours pas sûr que vous puissiez le reproduire avec une visionneuse standard (pas votre personnalisée). Je fermerai ce bogue comme invalide / incomplet pour ne pas confondre les autres participants au fil.

@oddjobz , @rpedela , @badams , @pholisma , @ subhadip-codeclouds pouvez-vous fournir un rapport de bogue séparé avec la ou les configuration (s) exacte (s) que vous rencontrez le problème et les étapes exactes quand pouvez-vous reproduire le problème (y compris le PDF)? s'il s'agit d'une solution personnalisée, fournissez un lien public vers celle-ci.

Ok, c'est le code en question - vous pouvez voir le correctif en place.

Spécifiquement pour le verrouillage, j'ai une routine comme ça;

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;
    });
},

Oui, c'est pourquoi je n'ai pas insisté sur le fait à l'époque, il semble y avoir une grande réticence à accepter même qu'il y a un problème - et encore moins qu'il doit être corrigé.

Le problème avec l'extrait ci-dessus a été résolu par https://github.com/mozilla/pdf.js/pull/6571

Eh bien, que puis-je dire, j'utilisais la dernière version mi-2016 et j'avais toujours le problème. Je semble me souvenir qu'on m'ait dit à l'époque (à plusieurs reprises) que c'était corrigé. (et comme beaucoup d'autres, je pouvais voir que ce n'était manifestement pas le cas)

Quoi qu'il en soit, pour quiconque voit le même problème, essayez de coller un verrou comme ci-dessus et voyez si cela fait une différence ... ce n'est que deux lignes ...

@yurydelendik Cela se produit assez régulièrement pour nos utilisateurs (principalement sous Windows 7), mais j'ai pu le reproduire sur OSX avec la dernière version, mais pas à 100% de manière cohérente.

Nous n'utilisons aucun code personnalisé, procédons simplement comme suit

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

Cela semble dépendre d'un certain nombre de facteurs, tels que s'il y a un autre texte en gras dans le document, et le niveau de zoom initial (le zoom avant et arrière le corrigera parfois) J'ai également remarqué que cela n'affecte que l'aperçu, et l'impression, lors du téléchargement du pdf, il semble rendre parfaitement (je suppose que c'est parce que pdf.js ne fait que transmettre le fichier fourni à l'utilisateur).

Nous avons décidé de ne plus utiliser cette solution et de télécharger le fichier directement sur la machine de l'utilisateur, mais je vais essayer de prendre le temps de proposer un cas de test reproductible bien que j'aie déjà passé toute ma journée hier à chasser ce bogue.

@badams , je peux confirmer que le zoom était également une solution pour moi, tout comme une page suivante / précédente. J'avais également l'impression que l'audace rendait le problème plus probable.

Je vais essayer de prendre le temps de proposer un cas de test reproductible

@badams merci, tout ce qui prend toutes les variantes lorsque les contributeurs essaient de reproduire le problème sur leur ordinateur fonctionnera, et les exemples complets publiés en ligne fonctionnent le mieux (vous pouvez publier un exemple complet dans la branche gh-pages d'un dépôt github).

Salut les gars,

Je n'ai pas bien compris toute cette histoire.
Existe-t-il déjà un correctif? Ou une sorte de mise en œuvre que je devrais faire?

Cordialement,
Tarcisio Pereira

Je n'ai pas bien compris toute cette histoire.

Je ne pense pas que quiconque le fasse.

Ce fil de discussion est fermé car il ne fournit pas les étapes exactes pour reproduire le problème (et en raison de certaines recommandations trompeuses dans les commentaires). Nous ne nous attendons pas à ce que le problème soit reproductible à 100%, mais le faire apparaître au moins une fois sur 10 sera formidable.

Éléments possibles qui peuvent provoquer le fonctionnement de PDF.js de cette façon ou avoir un bogue dans son code:

• Un serveur ou un navigateur HTTP ne gère pas correctement les demandes de plage HTTP
• Un navigateur ne gère pas correctement le chargement des polices ou les opérations de canevas
• La solution personnalisée entre en conflit avec les opérations ci-dessus

FWIW J'ai vu cette corruption dans de rares situations avec notre déploiement de pdf.js (v1.7.376). Notre traitement des demandes de gamme semble correct. Je ferai un rapport si je peux trouver des étapes de repro fiables ...

Nous n'avons eu ce problème que sur Chrome, après avoir changé le zoom, il disparaît. Nous avons donc défini showPreviousViewOnLoad sur false et n'avons plus jamais eu ce problème.

@TZanke pourriez-vous clarifier pourquoi la suppression de showPreviousViewOnLoad changerait le zoom? Merci!

@tonyjin pdf.js autozoom calcule une valeur de zoom et l'enregistre dans le stockage local. Après le rechargement de la page, le zoom automatique n'est pas utilisé, mais la valeur de zoom calculée précédente est utilisée. Et il semble qu'il y ait un problème de chargement de cette valeur à nouveau.

Ainsi, lors de la désactivation de showPreviousViewOnLoad la fonction de zoom automatique démarre à chaque fois, effectue un zoom sur la page correctement et aucun problème de rendu ne se produit.

@TZanke - J'ai essayé votre approche, mais malheureusement, le problème se pose encore parfois .. :(