Pdf.js: Falta la compatibilidad con el parámetro "viewrect" en los identificadores de fragmentos de URL.

Hola,
Soy nuevo aquí, estoy buscando un problema para solucionar y me gustaría solucionar este problema a menos que alguien ya lo esté haciendo. Y también leí la documentación sobre viewRect, no estoy muy seguro, a qué se refieren wd y ht.
¿Alguien puede aclararme sobre ese wd y ht, por favor? Gracias por adelantado.

Siéntete libre de trabajar en esto. Creo que wd es "ancho" y ht es "alto".

Hola @AndrewMyint , solo quería señalarle un par de problemas relacionados con este, que documentan el comportamiento erróneo de la implementación actual del parámetro (erróneamente nombrado) " zoom ": https: // github .com / mozilla / pdf.js / issues / 10773 y https://github.com/mozilla/pdf.js/issues/2843.

Gracias @markmatney He estado mirando pdf_link_service.js, y me sorprende que el parámetro " zoom " esté manejando el argumento Fit mientras que debería manejarse en " view " parámetro según documentación .

@markmatney Si no me equivoco, todos los valores proporcionados como argumentos como (left, top, scale, Fit, ...) se están utilizando en BaseViewer.scrollPageIntoView . Y hay varios casos de cambio (Fit, FitB, FitH,......) manejan en scrollPageIntoView . Y, un caso interesante que encontré es FitR que ni siquiera veo ese argumento FitR en la documentación .

Pero me parece que " FitR " está produciendo el comportamiento " viewrect " si agrega #zoom=FitR,72,72,288,432 a la barra de direcciones URL.

¿Puede confirmar que es el comportamiento esperado para viewrect , por favor? Gracias.

Sí, creo que BaseViewer.scrollPageIntoView es el método que analiza todos esos argumentos y luego de alguna manera transforma la ventana gráfica en función de ellos.

También recuerdo haber visto FitR cuando inicialmente miré esto. Se introdujo en master en d30fac0 (4 de septiembre de 2011) junto con el resto de Fit* args, y se define en la especificación de referencia de PDF . No estoy seguro de por qué se omitió de la especificación "Parámetros para abrir archivos PDF" (o por qué hay incluso dos especificaciones separadas, para el caso).

De todos modos, tengo una fuerte opinión de que viewrect debería implementarse de manera diferente a FitR . Esto es ciertamente discutible, pero:

• simplemente tratarlos de la misma manera sería redundante y limitaría el número de casos de uso que podría cumplir este software, y
• dado que las especificaciones de PDF definen la semántica de cada uno de manera diferente, ciertamente _podemos_ implementarlas de manera diferente mientras seguimos cumpliendo con las especificaciones.

Espero ver una implementación de viewrect donde, a diferencia de FitR , la vista resultante no depende de las dimensiones de la ventana del navegador web del usuario. Para ver lo que quiero decir, vaya a https://mozilla.github.io/pdf.js/web/viewer.html#zoom = FitR, 0,0,144,144. Ese fragmento de URL le pide al espectador que muestre una región cuadrada de aproximadamente 2 "x 2" (_w_ x _h_, 1 "~ 72 px). Actualmente, si mi navegador es de pantalla completa en una pantalla de 1080 x 720 (proporción 3: 2) orientado al paisaje, se muestra una región de 3 "x 2". Si giro la pantalla 90 grados y veo el mismo rectángulo en un navegador de pantalla completa, se muestra una región de 2 "x 3". Esto se debe a PDF.JS llena el resto del espacio disponible, según la especificación de referencia de PDF págs. 583:

[_page_ / FitR _left_ _bottom_ _right_ _top_]

Muestre la página designada por _page_, con su contenido ampliado lo suficiente para ajustarse al rectángulo especificado por las coordenadas [...] completamente dentro de la ventana [...] Si los factores de aumento horizontal y vertical requeridos son diferentes, use el más pequeño de los dos [...]

"Parámetros para abrir archivos PDF" define viewrect mucho más libremente (ver el comentario de apertura sobre este tema para la definición). Me gustaría ver una implementación que muestre la misma región independientemente del tamaño de la ventana del navegador, de modo que cualquier cosa _fuera_ de la región especificada quede fuera de foco ("atenuada" o "oscurecida"). A menos que me falte algo, dicha implementación aún sería compatible con las especificaciones.

Al leer mi comentario, me acabo de dar cuenta de que la implementación de PDFjs de FitR difiere de la especificación de referencia de PDF. Interpreta el rectángulo como _x, y, w, h_ cuando debe interpretarse como _izquierda, inferior, derecha, superior_.