Pdf.js: Lembre-se da posição de visualização após atualizar a página

Criado em 8 jan. 2016  ·  34Comentários  ·  Fonte: mozilla/pdf.js

Atualmente, a posição da visualização é salva por um hash com base no conteúdo do arquivo. Ao recarregar a página, devemos também levar em consideração a última posição, pois ela corresponde ao comportamento normal dos navegadores. Normalmente, quando você recarrega uma página da web, o deslocamento de rolagem é restaurado (mesmo se o conteúdo da página mudou).

A motivação para essa mudança vem de experimentar o seguinte fluxo de trabalho interrompido:

  1. Gere um arquivo PDF local ( file://....pdf ).
  2. Abra o PDF com PDF.js e role para algum capítulo no arquivo PDF.
  3. Edite o arquivo PDF.
  4. Atualize o visualizador PDF.js (por exemplo, com F5).
  5. Resultado esperado: mantenha a posição de rolagem.
    Resultado real: a página 1 é mostrada na janela de visualização.

Notas técnicas:

  • performance.navigation.type pode ser usado para detectar recarregamento de página versus navegações.
  • history.state é preservado quando uma página é recarregada.
1-viewer

Todos 34 comentários

Isso seria incrível.

Sou um estudante da faculdade Seneca aprendendo código aberto e esperava trabalhar nesse bug em meu curso. Se ninguém mais estiver trabalhando nisso, eu gostaria de fazer uma tentativa.

Ninguém indicou que está trabalhando nisso, então é todo seu! Sinta-se à vontade para nos contactar no IRC ou deixe uma mensagem aqui caso tenha alguma questão.

Ei, muito obrigado pela resposta rápida. Eu realmente quero contribuir para um projeto de código aberto. Vou começar a trabalhar nisso imediatamente. Desde que é minha primeira vez fazendo algo assim, há algo que eu deva saber?
Muito obrigado!

Acho que todas as informações necessárias para este patch estão listadas em https://github.com/mozilla/pdf.js/wiki/Contributing. A menos que você toque nos arquivos da pasta src/ (o que não é de se esperar; espero que você só precise tocar nos arquivos da pasta web/ ), você só precisa executar gulp lint e gulp unittest para verificar suas alterações. Você pode executar gulp server para iniciar um servidor local para testar suas alterações no navegador. Se tiver mais perguntas, consulte a wiki, contacte-nos no IRC ou pergunte aqui. Boa sorte!

Obrigado, vou começar a ler os arquivos.

Estou investigando isso, mas não sei se entendi o problema muito bem.

1 - Gere um arquivo PDF local (arquivo: //....pdf).
3 - Edite o arquivo PDF.

Então, o problema está apenas relacionado à construção / geração do meu próprio PDF? Por exemplo, construí-lo com algum gerador de pdf como latex / jspdf?

Eu fiz o seguinte e não consegui reproduzir:

  1. Criei um PDF para mim e abri com http://localhost:8888/web/viewer.html?file=/andrei_test/a4.pdf
  2. navegou para a página 3.
  3. Em seguida, editei o pdf (adicionado mais texto na página 3)
  4. atualizei e vi o novo conteúdo na página 3 aparecer, mas eu ainda estava na página 3, o pdf.js não me moveu para a página 1.

Antes disso, tentei atualizar o PDF padrão de viewer.html algumas vezes e tive a impressão de que a página não foi lembrada. Mas agora acho que entendi, se eu atualizar muito rápido (antes que o hashing interno seja feito para lembrar onde rolar de volta após a atualização), então isso me levará ao último lugar em que estava antes do meu último pergaminho, não ao meu última posição. Mas se eu esperar meio segundo a mais e depois atualizar, então vejo que está tudo bem, fico na posição de rolagem da última vez.

Portanto, não tenho certeza do que estou procurando aqui. Você poderia dar mais detalhes sobre como reproduzir? Obrigado!

Não posso testar novamente no momento, mas na etapa 4 você costumava fazer isso
pule para a página 1 após a atualização (se o documento mudou). Que disse que não era
trabalhando localmente, mas em uma conexão de servidor. Não tenho certeza se isso poderia fazer um
diferença.

No domingo, 31 de dezembro de 2017 às 4h42, Andrei Petre [email protected]
escrevi:

Estou investigando isso, mas não sei se entendi muito bem o problema
bem.

1 - Gere um arquivo PDF local (arquivo: //....pdf).
3 - Edite o arquivo PDF.

Então, o problema está apenas relacionado à construção / geração do meu próprio PDF? Por exemplo
construí-lo com algum gerador de pdf como latex / jspdf?

Eu fiz o seguinte e não consegui reproduzir:

  1. Construí um PDF para mim e abri com http: // localhost : 8888 / web /
    viewer.html? file = / andrei_test / a4.pdf
    http: // localhost: 8888 / web / viewer.html? file = / andrei_test / a4.pdf
  2. navegou para a página 3.
  3. Em seguida, editei o pdf (adicionado mais texto na página 3)
  4. atualizei e vi o novo conteúdo na página 3 aparecer, mas ainda estava
    na página 3, o pdf.js não me moveu para a página1.

Antes disso, tentei atualizar o PDF padrão de viewer.html a
algumas vezes e tive a impressão de que a página não foi lembrada em
todos. Mas agora acho que entendi, se eu atualizar muito rápido (antes do
hashing interno é feito para lembrar onde rolar para trás após a atualização),
então me levará para a última vez que estive antes do meu último pergaminho, não
para minha última posição. Mas se eu perdesse meio segundo a mais e depois atualizasse,
então eu vejo que está tudo bem, eu fico na posição de rolagem para onde rolou pela última vez.

Portanto, não tenho certeza do que estou procurando aqui. Você poderia dar mais detalhes
sobre como reproduzir? Obrigado!

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-354573873 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AGBkZqzS34MYDM8wZi41cNY0NiVUyoI-ks5tFsNqgaJpZM4HBeqE
.

Acabei de testar novamente e fui definitivamente movido de volta para a página um ao recarregar. este
é com o navegador Chrome, se isso faz diferença. E ainda trabalhando
remotamente com http-server.
A propósito, sharelatex, rstudio e outros estão usando back-ends de pdf.js e
já resolveu esse problema, aparentemente. Não poderíamos apenas pedir-lhes para
contribuir com um patch?

No domingo, 31 de dezembro de 2017 às 7h18 , Yasha Savelyev
escrevi:

Não posso testar novamente no momento, mas na etapa 4 você costumava fazer isso
pule para a página 1 após a atualização (se o documento mudou). Que disse que não era
trabalhando localmente, mas em uma conexão de servidor. Não tenho certeza se isso poderia fazer um
diferença.

No domingo, 31 de dezembro de 2017 às 4h42, Andrei Petre [email protected]
escrevi:

Estou investigando isso, mas não sei se entendi muito bem o problema
bem.

1 - Gere um arquivo PDF local (arquivo: //....pdf).
3 - Edite o arquivo PDF.

Então, o problema está apenas relacionado à construção / geração do meu próprio PDF? Por exemplo
construí-lo com algum gerador de pdf como latex / jspdf?

Eu fiz o seguinte e não consegui reproduzir:

  1. Criei um PDF para mim e abri com
    http: // localhost : 8888 / web / viewer.html? file = / andrei_test / a4.pdf
    http: // localhost: 8888 / web / viewer.html? file = / andrei_test / a4.pdf
  2. navegou para a página 3.
  3. Em seguida, editei o pdf (adicionado mais texto na página 3)
  4. atualizei e vi o novo conteúdo na página 3 aparecer, mas ainda estava
    na página 3, o pdf.js não me moveu para a página1.

Antes disso, tentei atualizar o PDF padrão de viewer.html a
algumas vezes e tive a impressão de que a página não foi lembrada em
todos. Mas agora acho que entendi, se eu atualizar muito rápido (antes do
hashing interno é feito para lembrar onde rolar para trás após a atualização),
então me levará para a última vez que estive antes do meu último pergaminho, não
para minha última posição. Mas se eu perdesse meio segundo a mais e depois atualizasse,
então eu vejo que está tudo bem, eu fico na posição de rolagem para onde rolou pela última vez.

Portanto, não tenho certeza do que estou procurando aqui. Você poderia dar mais detalhes
sobre como reproduzir? Obrigado!

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-354573873 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AGBkZqzS34MYDM8wZi41cNY0NiVUyoI-ks5tFsNqgaJpZM4HBeqE
.

Posso confirmar que este problema é reproduzível. Não apenas a página voltou, o zoom também foi reiniciado. Eu suspeito que isso pode ser devido ao hash foi alterado quando modificamos o arquivo.

@timvandermeij Isso está disponível? Eu gostaria de dar uma olhada nisso!

Eu não consigo entender

BrianNgo: Posso confirmar que este problema é reproduzível. Não apenas a página voltou, o zoom também foi reiniciado. Eu suspeito que isso pode ser devido ao hash foi alterado quando modificamos o arquivo.

@BrianNgo Você trabalhou no local, com o código, ou como você testou isso? Você poderia dar algumas informações de reprodução passo a passo?

yashamon: E ainda trabalhando remotamente com o servidor http

@yashamon você poderia explicar mais sua configuração? Pode ser dependente disso, já que quando tentei executar um servidor local e acessá-lo no localhost (por exemplo, http://localhost:8888/web/viewer.html?file=/andrei_test/a4.pdf ), não consegui reproduzir isso. Eu também estava usando o cromo.

Jolo510: @timvandermeij Isso está em jogo? Eu gostaria de dar uma olhada nisso!

@ Jolo510 Está em jogo, vá em frente. Não estou trabalhando nisso, não consegui reproduzir da última vez que tentei.

O problema aqui é que o arquivo mudou apenas ligeiramente, mas o hash mudou completamente. Para fins de teste, o conteúdo real do PDF não importa, você só precisa garantir que os PDFs que está testando tenham hashes diferentes.

Para reproduzir de forma mais confiável, você pode pegar um conjunto de arquivos PDF completamente não relacionados (por exemplo, os PDFs em test/pdfs/ ) e sobrescrever um arquivo PDF antes de recarregar o PDF.js (com a visualização definida para a página 2, para que você verá a diferença entre a página 1 e a página 2). Desta forma, o mesmo caminho de arquivo apontará para um arquivo diferente e você poderá ver o bug em ação.

@andreip Sim, estou testando localmente com o Chrome. O que fiz foi abrir o pdf semelhante ao que você tinha: http: // localhost : 8888 / web / viewer.html? File = / andrei_test / a4.pdf. Então usei o libreoffice para modificar o arquivo e exportá-lo. Atualizei a página e o bug aconteceu.

Na minha opinião, isso não é realmente um bug. Ao modificar o arquivo, o aplicativo percebe o arquivo atual como um novo arquivo (o que é mais seguro assumir). Portanto, o aplicativo deve redefinir seu histórico para visualizá-lo como um novo arquivo.

O verdadeiro problema seria quando atualizar o arquivo muito rápido antes de fazer o hash interno.

@andreip Incrível! Vou ver se consigo recompor localmente.

Estou pensando em fazer o aplicativo rodar localmente esta noite. Em seguida, reserve algum tempo no dia seguinte ou dois para reproduzir o bug e mergulhar no código.

@BrianNgo Se o problema for atualizar o arquivo muito rapidamente, qual seria uma possível solução?

Algum progresso nisso?

Na quarta-feira, 17 de janeiro de 2018, 23:07 Johnnie Lo, [email protected] escreveu:

Estou pensando em fazer o aplicativo rodar localmente esta noite. Então reserve algum tempo
no próximo dia ou dois para reproduzir o bug e cavar no código.

@BrianNgo https://github.com/brianngo Se o problema também estiver atualizando
rapidamente, qual seria uma solução potencial?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-358539017 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AGBkZmlmOIxzNatXTXTGW3bNaeNFkWFzks5tLtF2gaJpZM4HBeqE
.

@yashamon Não, não fiz nenhum progresso nisso.

@ Rob - W
Ei ,
Eu vejo muitas pessoas tentando fazer isso. Dando uma chance. Por favor, deixe-me saber se precisarmos escrever um teste para isso também

@ ankitverma2211 Se possível, os testes seriam ótimos.
No entanto, não temos testes automatizados para esse tipo de recurso, portanto, se o patch parecer razoável e passar em um teste manual, também o aceitaremos.

Eu gostaria de começar com isso. mais alguém está trabalhando nisso?

Não que eu saiba. Sinta-se à vontade para trabalhar nisso!

Claro que estou começando com isso irei enviar um ping para vocês no IRC por qualquer ajuda

Na segunda-feira, 24 de dezembro de 2018 às 4:24 PM Tim van der Meij [email protected]
escrevi:

Não que eu saiba. Sinta-se à vontade para trabalhar nisso!

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-449718751 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AF8SZdbnLGoX5cY1fvk02tcM_3o8KDctks5u8LJUgaJpZM4HBeqE
.

@timvandermeij Passei por todo o código envolvido durante a renderização do arquivo pdf.
Ele usa armazenamento local para armazenar o histórico de visualização de pdfjs com arquivos como um array. Em que cada elemento armazena a impressão digital do arquivo e outros metadados sobre o histórico da última visualização. quando modificamos uma impressão digital do arquivo, o arquivo muda e para essa nova impressão digital não temos nenhum histórico de visualização.

minha impressão digital de arquivo antigo => 14ecd8cdbbf6f76f04030d59025b5937

impressão digital após alteração do arquivo => 619c4c4f872e96e6514b25c6a1ae03f2

Até onde eu fiz o cálculo da impressão digital para um documento, isso depende do conteúdo e do trailer do pdf.

aqui está alguma referência

cálculo de impressão digital

referência stackoverflow

deixe-me saber o que você diz sobre isso. devemos encerrar este problema?

Oi Rahul,

Pode ajudar se você verificar o Sharelatex em ação, que usa pdf.js como um
backend e já tem uma solução alternativa, renderizando os pdfs após a fonte de látex
mudança de código, o que certamente mudará qualquer hash, mantendo a visualização
posição. Eu acredito que suas extensões são de código aberto no github, mas não
tem um link pronto.

Na sexta-feira, 28 de dezembro de 2018 às 15:01 Rahul Sharma [email protected]
escrevi:

@timvandermeij https://github.com/timvandermeij eu passei pelo
todo o código que está envolvido na renderização do arquivo pdf.
Ele usa armazenamento local para armazenar o histórico de visualização de pdfjs com arquivos como um
array. Em que cada elemento armazena a impressão digital do arquivo e outros
metadados sobre o histórico da última visualização. quando modificamos uma impressão digital de arquivo de
o arquivo muda e para essa nova impressão digital não temos nenhuma visualização
história.

minha impressão digital de arquivo antigo => 14ecd8cdbbf6f76f04030d59025b5937

impressão digital após alteração do arquivo => 619c4c4f872e96e6514b25c6a1ae03f2

Até onde eu passei pelo cálculo de impressão digital para um doc depende
no conteúdo e no trailer do pdf.

aqui está alguma referência

cálculo de impressão digital
https://github.com/mozilla/pdf.js/blob/58c3ea08202becf007c304512c44726719acb508/src/core/core.js#L513

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

deixe-me saber o que você diz sobre isso. devemos encerrar este problema?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mozilla/pdf.js/issues/6847#issuecomment-450426605 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AGBkZidcCqtZjNp18mXaFfC78IfPRj-1ks5u9oaTgaJpZM4HBeqE
.

será de grande ajuda se você puder compartilhar o link para o repo que é responsável por isso e então será um recurso para este repo ao invés de um bug

Eu costumava ter um script greasemonkey que substituía a chave "Cr" por um clique em "viewBookmark", o que basicamente resolve esse problema para mim. Não funcionou depois de alguma versão do Firefox. Parece que o greasemonkey não está carregado no pdf.js. É intencional?

EDITAR: depois de um pouco de pesquisa, acho que isso é intencional - https://discourse.mozilla.org/t/extensions-on-pdfjs-pages/28441

@timvandermeij @yashamon

Eu dei uma olhada no repo Sharelatex. eles estão fazendo isso usando o controle de pdfjs.history com projectId em vez de impressão digital, que muda com o documento alterado, mas o projectId para aquele documento específico permanece o mesmo para o sharelatex.

Tenho poucas perguntas em mente. Eu tentei me conectar com vocês no IRC, mas não obtive resposta

Questões:

  1. é que precisamos manter o número da página também quando o pdf muda e o usuário abre um novo arquivo em uma nova guia.
    como é mantido no método de impressão digital atual.
  2. Se precisar estar apenas na guia atual, podemos usar as sessões, caso contrário, adicionaremos mais algumas chaves para view_history.
    Por favor me guie

Corrigido em # 10424.

Acabei de testar isso, ainda é o mesmo comportamento. Atualizar a página corrige a posição de visualização da página apenas se o arquivo pdf não for alterado, caso contrário, a visualização pula para a primeira página. Isso é muito fácil de testar com latex, escolha um documento, compile e visualize o pdf adicione uma palavra aleatória na fonte do latex, recompile e visualize o pdf, a visualização do pdfjs pula para a primeira página. Estou na versão 2.2.191 no cromo. Vou verificar o firefox quando tiver uma chance.

Eu testei com o Firefox, parece que na versão mais recente o problema foi corrigido, então será que a versão do Chrome está ficando para trás?

A versão da extensão do Chrome inclui este patch. Seu comportamento pode ser diferente devido a uma diferença no comportamento do navegador. Certa vez, postei uma descrição detalhada do problema em https://github.com/mozilla/pdf.js/commit/cdea75dc397f4eb4d6fd1f7d8a388c7d11df3452 (que fazia parte de https://github.com/mozilla/pdf.js/pull/6200) .

Enviei um problema semelhante # 11359 com relação a * pdf gerado por látex. Na verdade, não é correto que isso use um "hash baseado no conteúdo do arquivo" @ Rob-W. Em vez disso, é um ID embutido no PDF na criação, e como esse ID é gerado depende do aplicativo gerador, para * latex é um hash baseado na combinação da hora atual e o nome do caminho do arquivo tex. Veja meu último comentário lá para uma solução.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

xingxiaoyiyio picture xingxiaoyiyio  ·  3Comentários

aaronshaf picture aaronshaf  ·  3Comentários

liuzhen2008 picture liuzhen2008  ·  4Comentários

anggikolo11 picture anggikolo11  ·  3Comentários

kleins05 picture kleins05  ·  3Comentários