Pdf.js: O caminho SVG está incorretamente dividido em 2 nós
Anexe (recomendado) ou Link para o arquivo PDF aqui:
test4.pdf
Configuração:
- Navegador da web e sua versão: Chrome 56.0.2924.76
- Sistema operacional e sua versão: Linux Mint 18.3
- Versão PDF.js: commit c0d6e46e392b327996eb0964b7932cb5bdde1727
- É uma extensão do navegador: não
Etapas para reproduzir o problema:
- execute "node pdf2svg.js test4.pdf"
- carregue a saída test4.1.svg no Chrome
- Verifique o log de erros do console. Você verá isto:
Qual é o comportamento esperado? (adicionar captura de tela)
Sem erros.
O que deu errado? (adicionar captura de tela)
Um caminho na saída foi dividido em 2 partes.
O "M" inicial está em um nó e o "L" seguinte está no próximo nó.
Eles devem estar no mesmo nó.
Link para um visualizador (se hospedado em um site diferente de mozilla.github.io/pdf.js ou como extensão do Firefox / Chrome):
johnkingsley
Todos 4 comentários
Isso pode estar relacionado ao bug # 9167.
johnkingsley
em 6 fev. 2019
Acho que o culpado está aqui:
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533 -L534
Não estou muito familiarizado com o funcionamento de OperatorList mas parece que as listas de operadores estão divididas em blocos de cerca de 1000 operadores. Às vezes, o limite do bloco é colocado no meio de uma definição de caminho PDF. Isso produz dois operadores OPS.constructPath e o último não começa com moveTo .
Isso parece plausível?
Em vez de modificar OperatorList e sua constante CHUNK_SIZE , svg.js deve ser corrigido. Talvez assim: Operadores OPS.constructPath consecutivos devem ser combinados em um nó <svg:path> se não houver nenhum operador de pintura de caminho intermediário ...
janpe2
em 12 fev. 2019
Não estou muito familiarizado com o funcionamento de
OperatorListmas parece que as listas de operadores estão divididas em blocos de cerca de 1000 operadores.
Correto; isso permite que a renderização comece antes que OperatorList inteiro (ou seja, a página) tenha sido analisada, reduzindo assim o tempo total necessário desde o carregamento da página até que ela seja totalmente renderizada.
Isso parece plausível?
Sim, e ele deve ser fácil de verificar (apenas aumentar o valor muito, incapacitando eficazmente esta chunking).
Em vez de modificar
OperatorListe sua constanteCHUNK_SIZE, svg.js deve ser corrigido.
De acordo, modificar a constante definitivamente não é uma solução aceitável. Em primeiro lugar, não faria nada mais do que mover o erro para outro lugar. Em segundo lugar, e muito mais importante, alterá-lo poderia ter implicações de longo alcance para o desempenho geral de renderização no back-end do canvas.
Talvez assim: Operadores
OPS.constructPathconsecutivos devem ser combinados em um nó<svg:path>se não houver nenhum operador de pintura de caminho intermediário ...
Novamente, isso parece totalmente razoável.
Snuffleupagus
em 12 fev. 2019
Posso confirmar que, se aumentar CHUNK_SIZE para 10000000, o problema desaparece.
(e eu concordo que esta não é uma solução adequada)
Obrigado pela ajuda.
johnkingsley
em 13 fev. 2019
Questões relacionadas
AlexP3
·
3Comentários
brandonros
·
3Comentários
patelsumit5192
·
3Comentários
azetutu
·
4Comentários
hp011235
·
4Comentários
Comentários muito úteis
Correto; isso permite que a renderização comece antes que
OperatorListinteiro (ou seja, a página) tenha sido analisada, reduzindo assim o tempo total necessário desde o carregamento da página até que ela seja totalmente renderizada.Sim, e ele deve ser fácil de verificar (apenas aumentar o valor muito, incapacitando eficazmente esta chunking).
De acordo, modificar a constante definitivamente não é uma solução aceitável. Em primeiro lugar, não faria nada mais do que mover o erro para outro lugar. Em segundo lugar, e muito mais importante, alterá-lo poderia ter implicações de longo alcance para o desempenho geral de renderização no back-end do canvas.
Novamente, isso parece totalmente razoável.