Pdf.js: La ruta SVG está dividida incorrectamente en 2 nodos
Adjunte (recomendado) o enlace al archivo PDF aquí:
test4.pdf
Configuración:
- Navegador web y su versión: Chrome 56.0.2924.76
- Sistema operativo y su versión: Linux Mint 18.3
- Versión PDF.js: confirmar c0d6e46e392b327996eb0964b7932cb5bdde1727
- Es una extensión de navegador: no
Pasos para reproducir el problema:
- ejecutar "nodo pdf2svg.js test4.pdf"
- cargue la salida test4.1.svg en Chrome
- Verifique el registro de errores de la consola. Verás esto:
¿Cuál es el comportamiento esperado? (agregar captura de pantalla)
Sin errores.
¿Qué salió mal? (agregar captura de pantalla)
Una ruta en la salida se dividió en 2 partes.
La "M" inicial está en un nodo y la "L" siguiente está en el siguiente nodo.
Deben estar en el mismo nodo.
Enlace a un visor (si está alojado en un sitio que no sea mozilla.github.io/pdf.js o como extensión de Firefox / Chrome):
johnkingsley
Todos 4 comentarios
Esto puede estar relacionado con el error # 9167.
johnkingsley
en 6 feb. 2019
Creo que el culpable está aquí:
https://github.com/mozilla/pdf.js/blob/a045a00af34b764edda5991d2bcd18541ed60536/src/core/operator_list.js#L533 -L534
No estoy muy familiarizado con el funcionamiento de OperatorList pero parece que las listas de operadores están divididas en partes de aproximadamente 1000 operadores. A veces, el límite del fragmento se coloca en el medio de una definición de ruta de PDF. Esto produce dos operadores OPS.constructPath y el último no comienza con moveTo .
¿Suena esto plausible?
En lugar de modificar OperatorList y su constante CHUNK_SIZE , se debería arreglar svg.js. Tal vez así: Los operadores OPS.constructPath consecutivos deben combinarse en un nodo <svg:path> si no hay un operador de pintura de ruta intermedio ...
janpe2
en 12 feb. 2019
No estoy muy familiarizado con el funcionamiento de
OperatorListpero parece que las listas de operadores están divididas en partes de aproximadamente 1000 operadores.
Correcto; esto es para permitir que la renderización comience antes de que se haya analizado todo OperatorList (es decir, la página), reduciendo así el tiempo total necesario desde que se carga la página hasta que se renderiza por completo.
¿Suena esto plausible?
Sí, y debe ser fácil de verificar (sólo aumentará el valor mucho, desactivando efectivamente esta CHUNKING).
En lugar de modificar
OperatorListy su constanteCHUNK_SIZE, svg.js debería fijarse.
De acuerdo, modificar la constante definitivamente no es una solución aceptable. En primer lugar, no haría más que mover el error a otra parte. En segundo lugar, y mucho más importante, cambiarlo podría tener implicaciones de gran alcance para el rendimiento general de la representación en el back-end del lienzo.
Tal vez así: Los operadores
OPS.constructPathconsecutivos deben combinarse en un nodo<svg:path>si no hay un operador de pintura de ruta intermedio ...
Una vez más, eso suena totalmente razonable.
Snuffleupagus
en 12 feb. 2019
Puedo confirmar que si aumento CHUNK_SIZE a 10000000, el problema desaparece.
(y estoy de acuerdo en que esta no es una solución adecuada)
Gracias por tu ayuda.
johnkingsley
en 13 feb. 2019
Temas relacionados
SehyunPark
·
3Comentarios
PeterNerlich
·
3Comentarios
jigskpatel
·
3Comentarios
dmisdm
·
3Comentarios
BrennanDuffey
·
3Comentarios
Comentario más útil
Correcto; esto es para permitir que la renderización comience antes de que se haya analizado todo
OperatorList(es decir, la página), reduciendo así el tiempo total necesario desde que se carga la página hasta que se renderiza por completo.Sí, y debe ser fácil de verificar (sólo aumentará el valor mucho, desactivando efectivamente esta CHUNKING).
De acuerdo, modificar la constante definitivamente no es una solución aceptable. En primer lugar, no haría más que mover el error a otra parte. En segundo lugar, y mucho más importante, cambiarlo podría tener implicaciones de gran alcance para el rendimiento general de la representación en el back-end del lienzo.
Una vez más, eso suena totalmente razonable.