Pdf.js: Se souvenir de la position de la vue après avoir actualisé la page

Ce serait génial.

Je suis étudiant au collège Seneca et j'apprends l'open source, et j'espérais travailler sur ce bogue pour mon cours. Si personne d'autre n'y travaille actuellement, j'aimerais l'essayer.

Personne n'a indiqué qu'il y travaillait, c'est donc à vous! N'hésitez pas à nous contacter sur IRC ou à laisser un message ici au cas où vous auriez des questions.

Hé merci beaucoup pour la réponse rapide. Je souhaite vraiment contribuer à un projet open source. Je vais commencer à travailler dessus tout de suite. Depuis que c'est la première fois que je fais quelque chose comme ça, y a-t-il quelque chose que je devrais savoir?
Merci beaucoup!

Je pense que toutes les informations nécessaires pour ce correctif sont répertoriées sur https://github.com/mozilla/pdf.js/wiki/Contributing. Sauf si vous touchez des fichiers dans le dossier src/ (ce à quoi je ne m'attends pas; je suppose que vous n'aurez besoin de toucher que les fichiers du dossier web/ ), il vous suffit d'exécuter gulp lint et gulp unittest pour vérifier vos modifications. Vous pouvez exécuter gulp server pour démarrer un serveur local afin de tester vos modifications dans le navigateur. Si vous avez d'autres questions, consultez le wiki, contactez-nous sur IRC ou demandez ici. Bonne chance!

Merci, je vais commencer à lire les fichiers.

J'examine cela mais je ne sais pas si j'ai très bien compris le problème.

1 - Générez un fichier PDF local (fichier: //....pdf).
3 - Modifier le fichier PDF.

Le problème est donc uniquement lié à la création / génération de mon propre PDF? Par exemple, le construire avec un générateur de pdf comme latex / jspdf?

J'ai fait ce qui suit et je n'ai pas pu reproduire:

1. Je me suis construit un PDF et je l'ai ouvert avec http://localhost:8888/web/viewer.html?file=/andrei_test/a4.pdf
2. navigué vers la page 3.
3. Puis édité le pdf (ajouté plus de texte en page3)
4. rafraîchi et vu le nouveau contenu de la page3 apparaître mais j'étais toujours à la page 3, pdf.js ne m'a pas déplacé vers la page1.

Avant cela, j'ai juste essayé d'actualiser le PDF par défaut à partir de viewer.html plusieurs fois et j'avais l'impression que la page n'était pas du tout mémorisée. Mais maintenant, je pense que je comprends, si je le rafraîchis trop vite (avant que le hachage interne ne soit fait pour me souvenir de l'endroit où faire défiler après l'actualisation), cela me mènera simplement au dernier endroit où j'étais avant mon dernier défilement, pas à mon dernière position. Mais si j'attends une demi-seconde de plus puis actualise, alors je vois que ça va, je reçois la position de défilement jusqu'à l'endroit où j'ai défilé pour la dernière fois.

Je ne suis donc pas vraiment sûr de ce que je recherche ici. Pourriez-vous donner plus de détails sur la façon de reproduire? Merci!

Je ne peux pas tester à nouveau pour le moment, mais à l'étape 4, vous aviez l'habitude de l'avoir
passer à la page 1 après actualisation (si le document a changé). Cela dit je n'étais pas
travaillant localement mais via une connexion serveur. Je ne sais pas si cela pourrait faire un
différence.

Le dim 31 décembre 2017 à 04:42, Andrei Petre [email protected]
a écrit:

J'examine cela mais je ne sais pas si j'ai bien compris le problème
bien.

1 - Générez un fichier PDF local (fichier: //....pdf).
3 - Modifier le fichier PDF.

Le problème est donc uniquement lié à la création / génération de mon propre PDF? Par exemple
le construire avec un générateur de pdf comme latex / jspdf?

J'ai fait ce qui suit et je n'ai pas pu reproduire:

1. J'ai créé un PDF et l'ai ouvert avec http: // localhost : 8888 / web /
   viewer.html? file = / andrei_test / a4.pdf
   http: // localhost: 8888 / web / viewer.html? file = / andrei_test / a4.pdf
2. navigué vers la page 3.
3. Puis édité le pdf (ajouté plus de texte en page3)
4. rafraîchi et j'ai vu le nouveau contenu de la page 3 apparaître mais j'étais toujours
   à la page 3, pdf.js ne m'a pas déplacé vers la page1.

Avant cela, je viens d'essayer d'actualiser le PDF par défaut à partir de viewer.html a
quelques fois et j'avais l'impression que la page n'était pas rappelée à
tout. Mais maintenant je pense que je comprends, si je le rafraîchis trop vite (avant le
le hachage interne est fait pour se rappeler où faire défiler en arrière après rafraîchissement),
alors ça m'amènera juste à la dernière fois que j'étais avant mon dernier parchemin, pas
à ma dernière position. Mais si je perdais une demi-seconde de plus et que je me rafraîchis,
alors je vois que ça va, je reçois la position de défilement à l'endroit où j'ai défilé pour la dernière fois.

Je ne suis donc pas vraiment sûr de ce que je recherche ici. Pourriez-vous donner plus de détails
sur comment se reproduire? Merci!

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-354573873 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AGBkZqzS34MYDM8wZi41cNY0NiVUyoI-ks5tFsNqgaJpZM4HBeqE
.

Je viens de refaire le test et j'ai été définitivement déplacé vers la première page lors du rechargement. Ce
est avec le navigateur Chrome si cela fait une différence. Et travaille toujours
à distance avec serveur http.
Au fait, sharelatex, rstudio et d'autres utilisent les backends pdf.js et
ont déjà résolu ce problème apparemment. Ne pourrions-nous pas simplement leur demander de
contribuer un patch?

Le dim 31 décembre 2017 à 07:18 , Yasha Savelyev
a écrit:

Je ne peux pas tester à nouveau pour le moment, mais à l'étape 4, vous aviez l'habitude de l'avoir
passer à la page 1 après actualisation (si le document a changé). Cela dit je n'étais pas
travaillant localement mais via une connexion serveur. Je ne sais pas si cela pourrait faire un
différence.

Le dim 31 décembre 2017 à 04:42, Andrei Petre [email protected]
a écrit:

J'examine cela mais je ne sais pas si j'ai bien compris le problème
bien.

1 - Générez un fichier PDF local (fichier: //....pdf).
3 - Modifier le fichier PDF.

Le problème est donc uniquement lié à la création / génération de mon propre PDF? Par exemple
le construire avec un générateur de pdf comme latex / jspdf?

J'ai fait ce qui suit et je n'ai pas pu reproduire:

1. Je me suis construit un PDF et l'ai ouvert avec
   http: // localhost : 8888 / web / viewer.html? file = / andrei_test / a4.pdf
   http: // localhost: 8888 / web / viewer.html? file = / andrei_test / a4.pdf
2. navigué vers la page 3.
3. Puis édité le pdf (ajouté plus de texte en page3)
4. rafraîchi et j'ai vu le nouveau contenu de la page 3 apparaître mais j'étais toujours
   à la page 3, pdf.js ne m'a pas déplacé vers la page1.

Avant cela, je viens d'essayer d'actualiser le PDF par défaut à partir de viewer.html a
quelques fois et j'avais l'impression que la page n'était pas rappelée à
tout. Mais maintenant je pense que je comprends, si je le rafraîchis trop vite (avant le
le hachage interne est fait pour se rappeler où faire défiler en arrière après rafraîchissement),
alors ça m'amènera juste à la dernière fois que j'étais avant mon dernier parchemin, pas
à ma dernière position. Mais si je perdais une demi-seconde de plus et que je me rafraîchis,
alors je vois que ça va, je reçois la position de défilement à l'endroit où j'ai défilé pour la dernière fois.

Je ne suis donc pas vraiment sûr de ce que je recherche ici. Pourriez-vous donner plus de détails
sur comment se reproduire? Merci!

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-354573873 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AGBkZqzS34MYDM8wZi41cNY0NiVUyoI-ks5tFsNqgaJpZM4HBeqE
.

Je peux confirmer que ce problème est reproductible. Non seulement la page a reculé, mais le zoom a également été réinitialisé. Je soupçonne que cela peut être dû au fait que le hachage a été modifié lorsque nous avons modifié le fichier.

@timvandermeij Est-ce à gagner? J'aimerais m'y attaquer!

Je ne peux pas comprendre

BrianNgo: Je peux confirmer que ce problème est reproductible. Non seulement la page a reculé, mais le zoom a également été réinitialisé. Je soupçonne que cela peut être dû au fait que le hachage a été modifié lorsque nous avons modifié le fichier.

@BrianNgo Avez-vous travaillé en local, avec le code, ou comment avez-vous testé cela? Pourriez-vous donner quelques informations détaillées sur la reproduction?

yashamon: Et travaille toujours à distance avec le serveur http

@yashamon pourrais-tu expliquer plus en détail ta configuration? Cela pourrait dépendre de cela, car lorsque j'ai essayé d'exécuter un serveur local et d'y accéder sur localhost (par exemple http://localhost:8888/web/viewer.html?file=/andrei_test/a4.pdf ), je ne pouvais pas reproduire cela. J'utilisais aussi du chrome.

Jolo510: @timvandermeij Est-ce à gagner? J'aimerais m'y attaquer!

@ Jolo510 C'est à gagner,

Le problème ici est que le fichier n'a changé que légèrement, mais le hachage a complètement changé. Aux fins du test, le contenu PDF réel n'a pas d'importance, vous devez simplement vous assurer que les fichiers PDF que vous testez ont des hachages différents.

Pour reproduire de manière plus fiable, vous pouvez prendre un ensemble de fichiers PDF totalement indépendants (par exemple les PDF dans test/pdfs/ ) et écraser un fichier PDF avant de recharger PDF.js (avec la vue définie sur la page 2, de sorte que vous verra la différence entre la page 1 et la page 2). De cette façon, le même chemin de fichier pointera vers un fichier différent et vous pourrez voir le bogue en action.

@andreip Oui, je le teste en local avec Chrome. Ce que j'ai fait, c'est ouvrir le pdf de la même manière que ce que vous aviez: http: // localhost : 8888 / web / viewer.html? File = / andrei_test / a4.pdf. Ensuite, j'ai utilisé libreoffice pour modifier le fichier et je l'ai exporté. Actualisé la page et le bogue s'est produit.

À mon avis, ce n'est pas vraiment un bug. En modifiant le fichier, l'application perçoit le fichier actuel comme un nouveau fichier (ce qui est la chose la plus sûre à supposer). Ainsi, l'application doit réinitialiser son historique pour l'afficher comme un nouveau fichier.

Le vrai problème serait d'actualiser le fichier trop rapidement avant que le hachage interne ne soit effectué.

@andreip Génial! Je vais voir si je le repo localement.

Je prévois de faire fonctionner l'application localement ce soir. Ensuite, prenez le temps le jour suivant ou deux pour reproduire le bogue et fouiller dans le code.

@BrianNgo Si le problème actualise le fichier trop rapidement, quelle serait une solution potentielle?

Des progrès à ce sujet?

Le mercredi 17 janvier 2018, 23:07, Johnnie Lo, [email protected] a écrit:

Je prévois de faire fonctionner l'application localement ce soir. Puis prenez du temps
le lendemain ou deux pour reproduire le bogue et fouiller dans le code.

@BrianNgo https://github.com/brianngo Si le problème se rafraîchit aussi
rapidement, quelle serait une solution potentielle?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-358539017 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AGBkZmlmOIxzNatXTXTGW3bNaeNFkWFzks5tLtF2gaJpZM4HBeqE
.

@yashamon Non, je n'ai fait aucun progrès à ce sujet.

@ Rob - W
Hey ,
Je vois beaucoup de gens tenter leur chance. Essayez-le. S'il vous plaît laissez-moi savoir si nous devons également écrire un test

@ ankitverma2211 Si possible, les tests seraient formidables.
Cependant, nous n'avons pas de tests automatisés pour ce type de fonctionnalités, donc si le correctif semble raisonnable et passe un test manuel, nous l'accepterons également.

Je voudrais commencer là-dessus. est-ce que quelqu'un d'autre travaille actuellement là-dessus?

Pas que je sache de. N'hésitez pas à y travailler!

Bien sûr, je commence par vous envoyer un ping sur IRC pour obtenir de l'aide

Le lun.24 décembre 2018 à 16:24 Tim van der Meij [email protected]
a écrit:

Pas que je sache de. N'hésitez pas à y travailler!

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-449718751 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AF8SZdbnLGoX5cY1fvk02tcM_3o8KDctks5u8LJUgaJpZM4HBeqE
.

@timvandermeij J'ai parcouru tout le code impliqué lors du rendu du fichier pdf.
Il utilise le stockage local pour stocker l'historique des vues pdfjs avec des fichiers sous forme de tableau. Dans lequel chaque élément stocke l'empreinte digitale du fichier et d'autres métadonnées sur le dernier historique de vue. lorsque nous modifions une empreinte de fichier des changements de fichier et pour cette nouvelle empreinte, nous n'avons pas d'historique de vue.

mon ancien fichier d'empreinte => 14ecd8cdbbf6f76f04030d59025b5937

empreinte digitale après changement de fichier => 619c4c4f872e96e6514b25c6a1ae03f2

Dans la mesure où j'ai effectué le calcul des empreintes digitales pour un document, cela dépend du contenu et de la bande-annonce PDF.

voici quelques références

calcul de l'empreinte digitale

référence de stackoverflow

laissez-moi savoir ce que vous dites à ce sujet. devrions-nous fermer ce problème?

Salut Rahul,

Cela peut vous aider si vous regardez Sharelatex en action, qui utilise pdf.js comme
backend et a déjà un travail autour, le rendu des fichiers PDF après la source latex
changement de code, qui changera certainement n'importe quel hachage, tout en gardant la vue
position. Je pense que leurs extensions sont open source sur github, mais pas
ayez un lien prêt.

Le ven 28 décembre 2018 à 15:01 Rahul Sharma [email protected]
a écrit:

@timvandermeij https://github.com/timvandermeij J'ai traversé le
tout le code impliqué lors du rendu du fichier pdf.
Il utilise le stockage local pour stocker l'historique des vues pdfjs avec des fichiers en tant que
tableau. Dans lequel chaque élément stocke l'empreinte digitale du fichier et d'autres
métadonnées sur l'historique de la dernière vue. lorsque nous modifions une empreinte de fichier de
le fichier change et pour cette nouvelle empreinte digitale, nous n'avons aucune vue
l'histoire.

mon ancien fichier d'empreinte => 14ecd8cdbbf6f76f04030d59025b5937

empreinte digitale après changement de fichier => 619c4c4f872e96e6514b25c6a1ae03f2

Pour autant que je sois passé par le calcul des empreintes digitales pour un doc, cela dépend
sur le contenu et la bande-annonce pdf.

voici quelques références

calcul de l'empreinte digitale
https://github.com/mozilla/pdf.js/blob/58c3ea08202becf007c304512c44726719acb508/src/core/core.js#L513

référence de stackoverflow
https://stackoverflow.com/questions/33309378/using-fingerprint-generated-by-pdfjs-as-unique-id-for-a-pdf

laissez-moi savoir ce que vous dites à ce sujet. devrions-nous fermer ce problème?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-450426605 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AGBkZidcCqtZjNp18mXaFfC78IfPRj-1ks5u9oaTgaJpZM4HBeqE
.

ce sera d'une grande aide si vous pouvez partager le lien vers le repo qui en est responsable, puis ce sera une fonctionnalité de ce repo plutôt qu'un bogue

J'avais un script greasemonkey qui remplaçait la clé "Cr" par un clic "viewBookmark", ce qui résout ce problème pour moi. Cela n'a pas fonctionné après une version de Firefox. Il semble que greasemonkey n'est pas chargé dans pdf.js. Est-ce prévu?

EDIT: après un peu de recherche, je pense que c'est intentionnel - https://discourse.mozilla.org/t/extensions-on-pdfjs-pages/28441

@timvandermeij @yashamon

J'ai regardé le repo Sharelatex. ils le font en utilisant le suivi de pdfjs.history avec projectId plutôt que par empreinte digitale qui change avec le document modifié, mais projectId pour ce document particulier reste le même pour sharelatex.

J'ai quelques questions en tête. J'ai essayé de me connecter avec vous les gars dans IRC mais je n'ai pas eu de réponse

Des questions:

1. est-ce que nous devons maintenir le numéro de page également lorsque le pdf change et que l'utilisateur ouvre un nouveau fichier dans un nouvel onglet.
   tel qu'il est conservé dans la méthode actuelle des empreintes digitales.
2. Si cela ne doit être que dans l'onglet courant, nous pouvons utiliser des sessions sinon nous ajouterons quelques clés supplémentaires à view_history.
   Guidez-moi s'il-vous-plaît

Corrigé dans # 10424.

Je viens de tester cela, toujours le même comportement. L'actualisation de la page ne corrige la position d'affichage de la page que si le fichier pdf n'est pas modifié, sinon la vue passe à la première page. C'est très facile à tester avec latex choisir un document compiler et prévisualiser le pdf ajouter un mot aléatoire dans la source latex, recompiler et prévisualiser le pdf, l'aperçu pdfjs passe à la première page. Je suis sur la version 2.2.191 en chrome. J'enregistrerai Firefox quand j'en aurai l'occasion.

J'ai testé avec Firefox, il semble que sur la dernière version, le problème soit résolu, alors est-ce juste que la version de Chrome est à la traîne?

La version de l'extension Chrome inclut ce correctif. Son comportement peut différer en raison d'une différence de comportement du navigateur. Une fois, j'ai posté une description détaillée du problème sur https://github.com/mozilla/pdf.js/commit/cdea75dc397f4eb4d6fd1f7d8a388c7d11df3452 (qui faisait partie de https://github.com/mozilla/pdf.js/pull/6200) .

J'ai soumis un problème similaire # 11359 concernant le * pdf généré par latex. Il n'est en fait pas correct que cela utilise un "hachage basé sur le contenu du fichier" @ Rob - W. Il s'agit plutôt d'un ID intégré dans le PDF lors de la création, et la manière dont cet ID est généré dépend de l'application génératrice, pour * latex c'est un hachage basé sur la combinaison de l'heure actuelle et du chemin du fichier tex. Voir mon dernier commentaire là pour une solution.