Pdf.js: falta de suporte para o parâmetro "viewrect" em identificadores de fragmento de URL

Oi,
Sou novo aqui, estou procurando um problema para corrigir e gostaria de corrigir esse problema, a menos que alguém já esteja fazendo isso. E também li a documentação sobre viewRect, não tenho certeza, a que wd e ht estão se referindo.
Alguém pode me esclarecer sobre esse wd e ht, por favor? Desde já, obrigado.

Sinta-se à vontade para trabalhar nisso. Acho que wd é "largura" e ht é "altura".

Olá @AndrewMyint , só queria apontar alguns problemas relacionados a este, que documentam o comportamento incorreto da implementação atual do parâmetro (nomeado erroneamente) " zoom ": https: // github .com / mozilla / pdf.js / issues / 10773 e https://github.com/mozilla/pdf.js/issues/2843.

Obrigado @markmatney , estive olhando em pdf_link_service.js e estou surpreso que o parâmetro " zoom " esteja tratando do argumento Fit enquanto deveria ser tratado em " view " parâmetro de acordo com a documentação .

@markmatney Se eu não estiver errado, todos os valores fornecidos como argumentos como (left, top, scale, Fit, ...) estão sendo usados ​​em BaseViewer.scrollPageIntoView . E, há uma série de casos de switch (Fit, FitB, FitH,......) manipulados em scrollPageIntoView . E, um caso interessante que encontrei é FitR que eu nem mesmo vejo o argumento FitR na documentação .

Mas me parece que " FitR " está produzindo o comportamento " viewrect " se você anexar #zoom=FitR,72,72,288,432 à barra de endereço URL.

Você pode confirmar que é o comportamento esperado para viewrect , por favor? Obrigada.

Sim, acredito que BaseViewer.scrollPageIntoView é o método que analisa todos esses argumentos e, de alguma forma, transforma a janela de visualização com base neles.

Também me lembro de ter visto FitR quando inicialmente examinei isso. Ele foi introduzido em master em d30fac0 (4 de setembro de 2011) junto com o restante de Fit* args e é definido nas especificações de referência do

De qualquer forma, tenho uma forte opinião de que viewrect deve ser implementado de forma diferente de FitR . Isso é certamente discutível, mas:

• simplesmente tratá-los da mesma forma seria redundante e limitaria o número de casos de uso que poderiam ser atendidos por este software, e
• uma vez que as especificações do PDF definem a semântica de cada um de maneira diferente, certamente _podemos_ implementá-las de maneira diferente, ao mesmo tempo que respeitamos as especificações.

Espero ver uma implementação de viewrect onde, ao contrário de FitR , a visualização resultante não depende das dimensões da janela do navegador do usuário. Para ver o que quero dizer, vá para https://mozilla.github.io/pdf.js/web/viewer.html#zoom = FitR, 0,0,144,144. Esse fragmento de URL pede ao visualizador para mostrar uma região quadrada de aproximadamente 2 "x 2" (_w_ x _h_, 1 "~ 72 px). Atualmente, se meu navegador estiver em tela inteira em 1080 x 720 (proporção 3: 2) paisagem orientada, então me é mostrado uma região de 3 "x 2". Se eu girar minha tela 90 graus e visualizar o mesmo retângulo em um navegador de tela inteira, então vejo uma região de 2 "x 3". Isso ocorre porque PDF.JS preenche o restante do espaço disponível, de acordo com as especificações de referência do PDF, pp. 583:

[_page_ / FitR _esquerda_ _bottom_ _right_ _top_]

Exibe a página designada por _página_, com seu conteúdo ampliado apenas o suficiente para caber no retângulo especificado pelas [...] coordenadas [...] inteiramente dentro da janela [...] Se os fatores de ampliação horizontal e vertical necessários forem diferentes, use o menor de os dois [...]

"Parâmetros para abrir arquivos PDF" define viewrect muito mais vagamente (veja o comentário de abertura sobre este assunto para a definição). Gostaria de ver uma implementação que exibe a mesma região, independentemente do tamanho da janela do navegador, para que qualquer coisa _fora_ da região especificada fique fora de foco ("acinzentado" ou "apagado"). A menos que esteja faltando alguma coisa, tal implementação ainda seria compatível com as especificações.

Lendo meu comentário, acabei de perceber que a implementação do PDFjs de FitR diverge das especificações de referência do PDF. Ele interpreta o retângulo como _x, y, w, h_ quando deveria ser interpretado como _esquerda, inferior, direita, superior_.