Pdf.js: prise en charge manquante du paramètre "viewrect" dans les identifiants de fragments d'URL

Salut,
Je suis nouveau ici, à la recherche d'un problème à résoudre, et j'aimerais résoudre ce problème à moins que quelqu'un ne le fasse déjà. Et j'ai aussi lu la documentation sur viewRect, je ne suis pas tout à fait sûr, à quoi font référence wd et ht.
Quelqu'un peut-il m'éclairer sur ce wd, et ht, s'il vous plaît? Merci d'avance.

N'hésitez pas à travailler dessus. Je pense que wd est "largeur" ​​et ht est "hauteur".

Salut @AndrewMyint , je voulais juste vous signaler quelques problèmes liés à celui-ci, qui documentent le comportement erroné de l'implémentation actuelle du paramètre (nommé par erreur) " zoom " : https://github .com/mozilla/pdf.js/issues/10773 et https://github.com/mozilla/pdf.js/issues/2843.

Merci @markmatney J'ai parcouru pdf_link_service.js, et je suis surpris que le paramètre " zoom " gère l'argument Fit alors qu'il devrait être géré dans " view " paramètre selon la documentation .

@markmatney Si je ne me trompe pas, toutes les valeurs fournies comme arguments tels que (left, top, scale, Fit, ...) sont utilisées dans BaseViewer.scrollPageIntoView . Et, il existe un certain nombre de cas de commutation (Fit, FitB, FitH,......) dans scrollPageIntoView . Et, un cas intéressant que j'ai trouvé est FitR que je ne vois même pas cet argument FitR dans la documentation .

Mais il me semble que " FitR " produit le comportement " viewrect " si vous ajoutez #zoom=FitR,72,72,288,432 à la barre d'adresse URL.

Pouvez-vous confirmer qu'il s'agit du comportement attendu pour viewrect , s'il vous plaît ? Merci.

Oui, je crois que BaseViewer.scrollPageIntoView est la méthode qui examine tous ces arguments, puis transforme en quelque sorte la fenêtre d'affichage en fonction d'eux.

Je me souviens aussi avoir vu FitR lorsque j'ai d'abord examiné cela. Il a été introduit dans master à d30fac0 (4 septembre 2011) avec le reste des Fit* , et est défini dans la spécification PDF Reference . Je ne sais pas pourquoi il a été omis de la spécification "Paramètres d'ouverture de fichiers PDF" (ou pourquoi il existe même deux spécifications distinctes, d'ailleurs).

Quoi qu'il en soit, je suis convaincu que viewrect devrait être implémenté différemment de FitR . C'est certainement discutable, mais :

• les traiter simplement de la même manière serait redondant et limiterait le nombre de cas d'utilisation qui pourraient être remplis par ce logiciel, et
• puisque les spécifications PDF définissent la sémantique de chacun différemment, nous pouvons certainement les implémenter différemment tout en respectant les spécifications.

J'espère voir une implémentation de viewrect où, contrairement à FitR , la vue résultante ne dépend pas des dimensions de la fenêtre du navigateur Web de l'utilisateur. Pour voir ce que je veux dire, allez sur https://mozilla.github.io/pdf.js/web/viewer.html#zoom =FitR,0,0,144,144. Ce fragment d'URL demande au spectateur d'afficher une région carrée d'environ 2" x 2" (_w_ x _h_, 1" ~ 72 px). Actuellement, si mon navigateur est en plein écran dans un affichage 1080 x 720 (ratio 3:2) paysage orienté, alors on me montre en fait une région de 3 "x 2". Si je fais pivoter mon écran de 90 degrés et que je visualise le même rectangle dans un navigateur plein écran, une région de 2" x 3" s'affiche. C'est parce que PDF.JS remplit le reste de l'espace disponible, conformément à la spécification de référence PDF pp. 583 :

[_page_ /FitR _left_ _bottom_ _right_ _top_]

Affichez la page désignée par _page_, avec son contenu agrandi juste assez pour s'adapter au rectangle spécifié par les coordonnées [...] entièrement dans la fenêtre [...] Si les facteurs d'agrandissement horizontal et vertical requis sont différents, utilisez le plus petit de les deux [...]

"Paramètres d'ouverture de fichiers PDF" définit viewrect beaucoup plus vague (voir le commentaire d'ouverture sur ce problème pour la définition). J'aimerais voir une implémentation qui affiche la même région quelle que soit la taille de la fenêtre du navigateur, de sorte que tout ce qui se trouve à l'extérieur de la région spécifiée soit flou ("grisé" ou "noirci"). À moins que quelque chose ne me manque, une telle implémentation serait toujours conforme aux spécifications.

En relisant mon commentaire, je viens de réaliser que l'implémentation PDFjs de FitR diverge de la spécification PDF Reference. Il interprète le rectangle comme _x,y,w,h_ alors qu'il doit être interprété comme _left,bottom,right,top_.