Pdf.js: Denken Sie nach dem Aktualisieren der Seite an die Ansichtsposition

Das wäre super.

Ich bin Student am Seneca College und lerne Open Source. Ich hatte gehofft, an diesem Fehler für meinen Kurs arbeiten zu können. Wenn derzeit niemand daran arbeitet, würde ich es gerne versuchen.

Niemand hat angegeben, dass sie daran arbeiten, also liegt es ganz bei Ihnen! Kontaktieren Sie uns im IRC oder hinterlassen Sie hier eine Nachricht, falls Sie Fragen haben.

Hey, vielen Dank für die schnelle Antwort. Ich möchte wirklich zu einem Open Source-Projekt beitragen. Ich werde sofort anfangen daran zu arbeiten. Gibt es etwas, über das ich wissen sollte, seit ich so etwas zum ersten Mal mache?
Vielen Dank!

Ich denke, alle notwendigen Informationen für diesen Patch sind unter https://github.com/mozilla/pdf.js/wiki/Contributing aufgeführt. Sofern Sie keine Dateien im Ordner src/ berühren (was ich nicht erwarte; ich gehe davon aus, dass Sie nur Dateien im Ordner web/ berühren müssen), müssen Sie nur gulp lint ausführen. gulp unittest , um Ihre Änderungen zu überprüfen. Sie können gulp server ausführen, um einen lokalen Server zu starten und Ihre Änderungen im Browser zu testen. Wenn Sie weitere Fragen haben, besuchen Sie das Wiki, kontaktieren Sie uns im IRC oder fragen Sie hier. Viel Glück!

Danke, ich werde anfangen, die Dateien durchzulesen.

Ich prüfe das, aber ich weiß nicht, ob ich das Problem sehr gut verstanden habe.

1 - Generieren Sie eine lokale PDF-Datei (Datei: //....pdf).
3 - PDF-Datei bearbeiten.

Das Problem bezieht sich also nur auf das Erstellen / Generieren meiner eigenen PDF-Datei? ZB mit einem PDF-Generator wie Latex / JSPDF bauen?

Ich habe folgendes getan und konnte es nicht reproduzieren:

1. Ich habe mir ein PDF erstellt und es mit http://localhost:8888/web/viewer.html?file=/andrei_test/a4.pdf geöffnet
2. navigiert zu Seite 3.
3. Dann bearbeitete das PDF (mehr Text in Seite 3 hinzugefügt)
4. aktualisiert und sah den neuen Inhalt auf Seite 3 erscheinen, aber ich war immer noch auf Seite 3, pdf.js hat mich nicht auf Seite 1 verschoben.

Vorher habe ich nur ein paar Mal versucht, das Standard-PDF von viewer.html aktualisieren, und ich hatte den Eindruck, dass die Seite überhaupt nicht gespeichert wurde. Aber jetzt denke ich, ich verstehe, wenn ich es zu schnell aktualisiere (bevor das interne Hashing durchgeführt wird, um sich daran zu erinnern, wohin ich nach dem Aktualisieren zurückblättern soll), bringt es mich nur an den letzten Ort, an dem ich vor meinem letzten Bildlauf war, nicht an meinen letzte Position. Aber wenn ich noch eine halbe Sekunde warte und dann aktualisiere, dann sehe ich, dass es in Ordnung ist. Ich bekomme eine gescrollte Position an die Stelle, an der ich zuletzt gescrollt habe.

Ich bin mir also nicht sicher, wonach ich hier suche. Könnten Sie weitere Einzelheiten zur Reproduktion angeben? Vielen Dank!

Ich kann im Moment nicht noch einmal testen, aber in Schritt 4 haben Sie das immer bekommen
Springen Sie nach der Aktualisierung zu Seite 1 (falls sich das Dokument geändert hat). Das heißt, ich war nicht
lokal arbeiten, aber über eine Serververbindung. Ich bin mir nicht sicher, ob das einen machen könnte
Unterschied.

Am Sonntag, den 31. Dezember 2017 um 04:42 Uhr, Andrei Petre [email protected]
schrieb:

Ich prüfe das, aber ich weiß nicht, ob ich das Problem sehr gut verstanden habe
Gut.

1 - Generieren Sie eine lokale PDF-Datei (Datei: //....pdf).
3 - PDF-Datei bearbeiten.

Das Problem bezieht sich also nur auf das Erstellen / Generieren meiner eigenen PDF-Datei? Z.B
Erstellen Sie es mit einem PDF-Generator wie Latex / JSPDF?

Ich habe folgendes getan und konnte es nicht reproduzieren:

1. Ich habe mir ein PDF erstellt und es mit http: // localhost : 8888 / web / geöffnet.
   viewer.html? file = / andrei_test / a4.pdf
   http: // localhost: 8888 / web / viewer.html? file = / andrei_test / a4.pdf
2. navigiert zu Seite 3.
3. Dann bearbeitete das PDF (mehr Text in Seite 3 hinzugefügt)
4. aktualisiert und sah den neuen Inhalt auf Seite 3 erscheinen, aber ich war immer noch
   Auf Seite 3 hat mich pdf.js nicht auf Seite 1 verschoben.

Vorher habe ich nur versucht, das Standard-PDF aus viewer.html a zu aktualisieren
einige Male und ich hatte den Eindruck, dass die Seite bei nicht erinnert wurde
alle. Aber jetzt denke ich zu verstehen, wenn ich es zu schnell aktualisiere (vor dem
Internes Hashing wird durchgeführt, um sich zu merken, wohin nach dem Aktualisieren zurückgescrollt werden soll.
dann bringt es mich nur zum letzten Mal, als ich vor meiner letzten Schriftrolle war, nicht
zu meiner letzten Position. Aber wenn ich noch eine halbe Sekunde vergeude und mich dann erfrische,
dann sehe ich, dass es in Ordnung ist, ich bekomme eine gescrollte Position zu der Stelle, an der ich zuletzt gescrollt habe.

Ich bin mir also nicht sicher, wonach ich hier suche. Könnten Sie mehr Details geben
wie reproduzieren? Vielen Dank!

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-354573873 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AGBkZqzS34MYDM8wZi41cNY0NiVUyoI-ks5tFsNqgaJpZM4HBeqE
.

Ich habe es gerade erneut getestet und wurde beim Neuladen definitiv auf Seite eins zurückversetzt. Diese
ist mit Chrome Browser, wenn das einen Unterschied macht. Und immer noch arbeiten
remote mit http-server.
Übrigens verwenden sharelatex, rstudio und andere pdf.js Backends und
habe dieses Problem anscheinend schon gelöst. Könnten wir sie nicht einfach darum bitten?
einen Patch beitragen?

Am Sonntag , den 31. Dezember 2017 um 07:18 Uhr, Yasha
schrieb:

Ich kann im Moment nicht noch einmal testen, aber in Schritt 4 haben Sie das immer bekommen
Springen Sie nach der Aktualisierung zu Seite 1 (falls sich das Dokument geändert hat). Das heißt, ich war nicht
lokal arbeiten, aber über eine Serververbindung. Ich bin mir nicht sicher, ob das einen machen könnte
Unterschied.

Am Sonntag, den 31. Dezember 2017 um 04:42 Uhr, Andrei Petre [email protected]
schrieb:

Ich prüfe das, aber ich weiß nicht, ob ich das Problem sehr gut verstanden habe
Gut.

1 - Generieren Sie eine lokale PDF-Datei (Datei: //....pdf).
3 - PDF-Datei bearbeiten.

Das Problem bezieht sich also nur auf das Erstellen / Generieren meiner eigenen PDF-Datei? Z.B
Erstellen Sie es mit einem PDF-Generator wie Latex / JSPDF?

Ich habe folgendes getan und konnte es nicht reproduzieren:

1. Ich habe mir ein PDF erstellt und es mit geöffnet
   http: // localhost : 8888 / web / viewer.html? file = / andrei_test / a4.pdf
   http: // localhost: 8888 / web / viewer.html? file = / andrei_test / a4.pdf
2. navigiert zu Seite 3.
3. Dann bearbeitete das PDF (mehr Text in Seite 3 hinzugefügt)
4. aktualisiert und sah den neuen Inhalt auf Seite 3 erscheinen, aber ich war immer noch
   Auf Seite 3 hat mich pdf.js nicht auf Seite 1 verschoben.

Vorher habe ich nur versucht, das Standard-PDF aus viewer.html a zu aktualisieren
einige Male und ich hatte den Eindruck, dass die Seite bei nicht erinnert wurde
alle. Aber jetzt denke ich zu verstehen, wenn ich es zu schnell aktualisiere (vor dem
Internes Hashing wird durchgeführt, um sich zu merken, wohin nach dem Aktualisieren zurückgescrollt werden soll.
dann bringt es mich nur zum letzten Mal, als ich vor meiner letzten Schriftrolle war, nicht
zu meiner letzten Position. Aber wenn ich noch eine halbe Sekunde vergeude und mich dann erfrische,
dann sehe ich, dass es in Ordnung ist, ich bekomme eine gescrollte Position zu der Stelle, an der ich zuletzt gescrollt habe.

Ich bin mir also nicht sicher, wonach ich hier suche. Könnten Sie mehr Details geben
wie reproduzieren? Vielen Dank!

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-354573873 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AGBkZqzS34MYDM8wZi41cNY0NiVUyoI-ks5tFsNqgaJpZM4HBeqE
.

Ich kann bestätigen, dass dieses Problem reproduzierbar ist. Nicht nur die Seite wurde zurückgeschoben, auch der Zoom wurde zurückgesetzt. Ich vermute, dass dies daran liegt, dass der Hash geändert wurde, als wir die Datei geändert haben.

@ Timvandermeij Ist das zu gewinnen? Ich würde gerne einen Sprung drauf machen!

Ich kann es nicht herausfinden

BrianNgo: Ich kann bestätigen, dass dieses Problem reproduzierbar ist. Nicht nur die Seite wurde zurückgeschoben, auch der Zoom wurde zurückgesetzt. Ich vermute, dass dies daran liegt, dass der Hash geändert wurde, als wir die Datei geändert haben.

@BrianNgo Haben Sie lokal mit dem Code gearbeitet oder wie haben Sie dies getestet? Können Sie schrittweise Informationen zur Wiedergabe geben?

yashamon: Und immer noch remote mit http-server arbeiten

@yashamon könntest du mehr dein Setup erklären? Dies kann davon abhängen, da ich dies nicht reproduzieren konnte, als ich versuchte, einen lokalen Server auszuführen und über localhost darauf zuzugreifen (z. B. http://localhost:8888/web/viewer.html?file=/andrei_test/a4.pdf ). Ich habe auch Chrom verwendet.

Jolo510: @timvandermeij Ist das zu gewinnen? Ich würde gerne einen Sprung drauf machen!

@ Jolo510 Es ist zu gewinnen,

Das Problem hierbei ist, dass sich die Datei nur geringfügig geändert hat, der Hash sich jedoch vollständig geändert hat. Zum Testen spielt der tatsächliche PDF-Inhalt keine Rolle. Sie müssen lediglich sicherstellen, dass die zu testenden PDF-Dateien unterschiedliche Hashes haben.

Um eine zuverlässigere Reproduktion zu erzielen, können Sie eine Reihe völlig unabhängiger PDF-Dateien (z. B. die PDFs in test/pdfs/ ) verwenden und eine PDF-Datei überschreiben, bevor Sie PDF.js neu laden (mit der Ansicht auf Seite 2) wird den Unterschied zwischen Seite 1 und Seite 2 sehen). Auf diese Weise verweist derselbe Dateipfad auf eine andere Datei, und Sie können den Fehler in Aktion sehen.

@andreip Ja, ich http: // localhost : 8888 / web / viewer.html? File = / andrei_test / a4.pdf. Dann habe ich libreoffice verwendet, um die Datei zu ändern und sie zu exportieren. Die Seite wurde aktualisiert und der Fehler ist aufgetreten.

Meiner Meinung nach ist dies kein wirklicher Fehler. Durch Ändern der Datei nimmt die App die aktuelle Datei als neue Datei wahr (was am sichersten ist). Daher sollte die App ihren Verlauf zurücksetzen, um sie als neue Datei anzuzeigen.

Das eigentliche Problem wäre, wenn die Datei zu schnell aktualisiert wird, bevor das interne Hashing durchgeführt wird.

@andreip Super ! Ich werde sehen, ob ich es lokal repo.

Ich plane, die App heute Abend lokal zum Laufen zu bringen. Nehmen Sie sich dann in den nächsten ein oder zwei Tagen etwas Zeit, um den Fehler zu reproduzieren und in den Code einzutauchen.

@BrianNgo Wenn das Problem die Datei zu schnell

Irgendwelche Fortschritte in diesem Bereich?

Am Mittwoch, 17. Januar 2018, 23:07 Uhr schrieb Johnnie Lo, [email protected] :

Ich plane, die App heute Abend lokal zum Laufen zu bringen. Dann nehmen Sie sich etwas Zeit
am nächsten oder zweiten Tag, um den Fehler zu reproduzieren und in den Code zu graben.

@BrianNgo https://github.com/brianngo Wenn das Problem ebenfalls aktualisiert wird
schnell, was wäre eine mögliche Lösung?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-358539017 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AGBkZmlmOIxzNatXTXTGW3bNaeNFkWFzks5tLtF2gaJpZM4HBeqE
.

@yashamon Nein, ich habe hier keine Fortschritte gemacht.

@ Rob - W.
Hallo ,
Ich sehe viele Leute, die darauf schießen. Probieren Sie es aus. Bitte lassen Sie mich wissen, ob wir auch dafür einen Test schreiben müssen

@ ankitverma2211 Wenn möglich, wären Tests großartig.
Wir haben jedoch keine automatisierten Tests für diese Art von Funktionen. Wenn der Patch also vernünftig aussieht und einen manuellen Test besteht, würden wir ihn auch akzeptieren.

Ich möchte damit anfangen. arbeitet noch jemand daran?

Nicht, dass ich davon Wüste. Fühlen Sie sich frei, daran zu arbeiten!

Sicher, ich fange damit an und werde euch im IRC um Hilfe bitten

Am Montag, 24. Dezember 2018, um 16:24 Uhr Tim van der Meij [email protected]
schrieb:

Nicht, dass ich davon Wüste. Fühlen Sie sich frei, daran zu arbeiten!

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-449718751 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AF8SZdbnLGoX5cY1fvk02tcM_3o8KDctks5u8LJUgaJpZM4HBeqE
.

@timvandermeij Ich habe den gesamten Code durchgesehen, der beim Rendern der PDF-Datei beteiligt ist.
Es verwendet lokalen Speicher zum Speichern des PDF-Ansichtsverlaufs mit Dateien als Array. In dem jedes Element den Fingerabdruck der Datei und andere Metadaten zum letzten Ansichtsverlauf speichert. Wenn wir einen Datei-Fingerabdruck der Datei ändern, ändert sich für diesen neuen Fingerabdruck kein Ansichtsverlauf.

Mein alter Datei-Fingerabdruck => 14ecd8cdbbf6f76f04030d59025b5937

Fingerabdruck nach Dateiwechsel => 619c4c4f872e96e6514b25c6a1ae03f2

Soweit ich die Fingerabdruckberechnung für ein Dokument durchlaufen habe, hängt dies vom Inhalt und dem PDF-Trailer ab.

Hier ist eine Referenz

figerprint Berechnung

Stackoverflow-Referenz

Lass mich wissen, was du dazu sagst. sollten wir dieses Problem schließen?

Hallo Rahul,

Es kann hilfreich sein, wenn Sie Sharelatex in Aktion ausprobieren, bei dem pdf.js als verwendet wird
Backend und hat bereits eine Lösung, um PDFs nach Latex-Quelle neu zu rendern
Codeänderung, die sicherlich jeden Hash ändert, während die Übersicht erhalten bleibt
Position. Ich glaube, ihre Erweiterungen sind Open Source auf Github, aber nicht
Habe einen Link bereit.

Am Fr, 28. Dezember 2018 um 15:01 Uhr Rahul Sharma [email protected]
schrieb:

@timvandermeij https://github.com/timvandermeij Ich habe die durchlaufen
ganzer Code, der beim Rendern der PDF-Datei beteiligt ist.
Es verwendet lokalen Speicher, um den Verlauf der PDF-Ansicht mit Dateien als zu speichern
Array. In dem jedes Element den Fingerabdruck der Datei und des anderen speichert
Metadaten zum letzten Ansichtsverlauf. wenn wir einen Datei-Fingerabdruck von ändern
Die Datei ändert sich und für diesen neuen Fingerabdruck haben wir keine Ansicht
Geschichte.

Mein alter Datei-Fingerabdruck => 14ecd8cdbbf6f76f04030d59025b5937

Fingerabdruck nach Dateiwechsel => 619c4c4f872e96e6514b25c6a1ae03f2

Soweit ich die Fingerabdruckberechnung für ein Dokument durchlaufen habe, kommt es darauf an
auf den Inhalt und PDF-Trailer.

Hier ist eine Referenz

figerprint Berechnung
https://github.com/mozilla/pdf.js/blob/58c3ea08202becf007c304512c44726719acb508/src/core/core.js#L513

Stackoverflow-Referenz
https://stackoverflow.com/questions/33309378/using-fingerprint-generated-by-pdfjs-as-unique-id-for-a-pdf

Lass mich wissen, was du dazu sagst. sollten wir dieses Problem schließen?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-450426605 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AGBkZidcCqtZjNp18mXaFfC78IfPRj-1ks5u9oaTgaJpZM4HBeqE
.

Es ist eine große Hilfe, wenn Sie den Link zu Repo freigeben können, der dafür verantwortlich ist, und dann ist es eher eine Funktion für dieses Repo als ein Fehler

Früher hatte ich ein Greasemonkey-Skript, das den Schlüssel "Cr" durch einen "viewBookmark" -Klick ersetzte, wodurch dieses Problem im Grunde für mich gelöst wird. Nach einer Version von Firefox hat es nicht funktioniert. Es sieht so aus, als ob greasemonkey nicht in pdf.js geladen ist. Ist es beabsichtigt?

BEARBEITEN: Nach einigem Suchen halte ich dies für beabsichtigt - https://discourse.mozilla.org/t/extensions-on-pdfjs-pages/28441

@ Timvandermeij @ Yashamon

Ich habe mir Sharelatex Repo angesehen. Dazu verfolgen sie die Datei pdfjs.history mit projectId und nicht den Fingerabdruck, der sich mit dem geänderten Dokument ändert. Die Projekt-ID für dieses bestimmte Dokument bleibt jedoch für sharelatex gleich.

Ich habe einige Fragen im Kopf. Ich habe versucht, mich mit euch im IRC zu verbinden, aber keine Antwort bekommen

Fragen:

1. ist, dass wir die Seitenzahl auch beibehalten müssen, wenn sich das PDF ändert und der Benutzer eine neue Datei in einer neuen Registerkarte öffnet.
   wie es in der aktuellen Fingerabdruckmethode beibehalten wird.
2. Wenn es nur in der aktuellen Registerkarte sein muss, können wir Sitzungen verwenden, andernfalls werden wir einige weitere Schlüssel an view_history anhängen.
   Bitte führen Sie mich

In # 10424 behoben.

Habe gerade das getestet, immer noch das gleiche Verhalten. Durch das Aktualisieren der Seite wird die Position der Seitenansicht nur korrigiert, wenn die PDF-Datei unverändert bleibt. Andernfalls springt die Ansicht zur ersten Seite. Dies ist sehr einfach mit Latex zu testen. Wählen Sie ein Dokument aus, kompilieren Sie es und zeigen Sie eine Vorschau des PDFs an. Fügen Sie ein zufälliges Wort in die Latexquelle ein, kompilieren Sie das PDF neu und zeigen Sie eine Vorschau an. Die PDF-Vorschau springt zur ersten Seite. Ich bin auf Release 2.2.191 in Chrome. Ich werde Firefox einchecken, wenn ich die Gelegenheit dazu bekomme.

Ich habe mit Firefox getestet. Es sieht so aus, als ob das Problem in der neuesten Version behoben ist. Ist es also nur so, dass die Chrome-Version hinterherhinkt?

Die Chrome-Erweiterungsversion enthält diesen Patch. Das Verhalten kann sich aufgrund eines unterschiedlichen Verhaltens des Browsers unterscheiden. Ich habe einmal eine detaillierte Beschreibung des Problems unter https://github.com/mozilla/pdf.js/commit/cdea75dc397f4eb4d6fd1f7d8a388c7d11df3452 (das Teil von https://github.com/mozilla/pdf.js/pull/6 war) veröffentlicht .

Ich habe ein ähnliches Problem # 11359 in Bezug auf * latexgeneriertes PDF eingereicht. Es ist eigentlich nicht richtig, dass dies einen "Hash basierend auf dem Dateiinhalt" @ Rob - W verwendet. Es handelt sich vielmehr um eine ID, die bei der Erstellung in das PDF eingebettet wird, und wie diese ID generiert wird, hängt von der generierenden Anwendung ab. Bei * latex handelt es sich um einen Hash, der auf der Kombination der aktuellen Zeit und des Pfadnamens der Tex-Datei basiert. Siehe meinen letzten Kommentar dort für eine Lösung.