Pdf.js: fehlende Unterstützung für den Parameter "viewrect" in URL-Fragment-IDs

Hi,
Ich bin neu hier und suche nach einem Problem, das behoben werden muss, und ich würde dieses Problem gerne beheben, es sei denn, jemand macht es bereits. Und ich habe auch die Dokumentation zu viewRect gelesen, ich bin mir nicht ganz sicher, worauf sich wd und ht beziehen.
Kann mich bitte jemand darüber aufklären. Danke im Voraus.

Arbeiten Sie gerne daran. Ich denke, wd ist "Breite" und ht ist "Höhe".

Hallo @AndrewMyint , ich wollte Sie nur auf ein paar Probleme im Zusammenhang mit diesem hinweisen, die das fehlerhafte Verhalten der aktuellen Implementierung des (fälschlicherweise benannten) Parameters " zoom " dokumentieren : https://github.com/mozilla/pdf.js/issues/2843.

Danke @markmatney, ich habe pdf_link_service.js durchgesehen und bin überrascht, dass der Parameter " zoom " das Argument Fit , während er in " view " behandelt werden sollte Parameter laut Dokumentation .

@markmatney Wenn ich mich nicht irre, werden alle Werte, die als Argumente wie (left, top, scale, Fit, ...) bereitgestellt wurden, in BaseViewer.scrollPageIntoView . Und es gibt eine Reihe von Schalterfällen (Fit, FitB, FitH,......) , die in scrollPageIntoView . Und ein interessanter Fall, den ich gefunden habe, ist FitR wobei ich das Argument FitR in der Dokumentation nicht einmal sehe.

Aber es scheint mir, dass " FitR " das Verhalten " viewrect " erzeugt, wenn Sie #zoom=FitR,72,72,288,432 an die URL-Adressleiste anhängen.

Können Sie bitte bestätigen, dass dies das erwartete Verhalten für viewrect ist? Dankeschön.

Ja, ich glaube, dass BaseViewer.scrollPageIntoView die Methode ist, die all diese Argumente betrachtet und dann irgendwie das Ansichtsfenster basierend auf ihnen transformiert.

Ich erinnere mich auch, dass ich FitR als ich das zuerst untersucht habe. Es wurde bei d30fac0 (4. September 2011) zusammen mit dem Rest der Fit* Argumente in master eingeführt und ist in der PDF-Referenzspezifikation definiert. Ich bin mir nicht sicher, warum es in der Spezifikation "Parameter zum Öffnen von PDF-Dateien" weggelassen wurde (oder warum es sogar zwei separate Spezifikationen gibt).

Wie auch immer, ich bin der festen Meinung, dass viewrect anders implementiert werden sollte als FitR . Das ist sicherlich umstritten, aber:

• sie einfach gleich zu behandeln wäre überflüssig und würde die Anzahl der Anwendungsfälle, die von dieser Software erfüllt werden könnten, begrenzen, und
• Da die PDF-Spezifikationen die Semantik jedes Einzelnen unterschiedlich definieren, _können_ wir sie sicherlich anders implementieren, während wir uns weiterhin an die Spezifikationen halten.

Ich würde mir eine Implementierung von viewrect wünschen, bei der im Gegensatz zu FitR die resultierende Ansicht nicht von den Abmessungen des Webbrowserfensters des Benutzers abhängt. Um zu sehen, was ich meine, gehen Sie zu https://mozilla.github.io/pdf.js/web/viewer.html#zoom =FitR,0,0,144,144. Dieses URL-Fragment fordert den Betrachter auf, einen quadratischen Bereich von ungefähr 2" x 2" anzuzeigen (_w_ x _h_, 1" ~ 72 px). Derzeit, wenn mein Browser im Vollbildmodus in einer Anzeige von 1080 x 720 (3:2) angezeigt wird ausgerichtete Landschaft, dann wird mir tatsächlich ein Bereich von 3" x 2" angezeigt. Wenn ich mein Display um 90 Grad drehe und dasselbe Rechteck in einem Vollbildbrowser betrachte, wird mir ein Bereich von 2" x 3" angezeigt. Dies liegt daran, dass PDF.JS füllt den Rest des verfügbaren Platzes gemäß der PDF-Referenzspezifikation S. 583:

[_page_ /FitR _left_ _bottom_ _right_ _top_]

Zeigen Sie die mit _page_ bezeichnete Seite an, deren Inhalt gerade so vergrößert ist, dass das durch die Koordinaten angegebene Rechteck [...] vollständig in das Fenster passt [...] Wenn die erforderlichen horizontalen und vertikalen Vergrößerungsfaktoren unterschiedlich sind, verwenden Sie den kleineren von die Zwei [...]

"Parameter zum Öffnen von PDF-Dateien" definiert viewrect viel lockerer (siehe den einleitenden Kommentar zu diesem Thema für die Definition). Ich würde gerne eine Implementierung sehen, die unabhängig von der Browserfenstergröße dieselbe Region anzeigt, sodass alles _außerhalb_ der angegebenen Region unscharf wird ("ausgegraut" oder "geschwärzt"). Sofern ich nichts übersehe, wäre eine solche Implementierung immer noch spezifikationskonform.

Beim Lesen meines Kommentars habe ich gerade festgestellt, dass die PDFjs-Implementierung von FitR von der PDF-Referenzspezifikation abweicht. Es interpretiert das Rechteck als _x,y,w,h_, obwohl es als _links,unten,rechts,oben_ interpretiert werden sollte.