Pdf.js: Las fórmulas están pintadas demasiado grandes.

Olvidé mencionar: estoy usando PDF Viewer 0.7.1 con Firefox 18.0.1 en Ubuntu Linux.

Parece que solo afecta a Linux

Sin embargo, Windows también muestra un error en el registro:
[16: 59: 53.199] Error al analizar el valor de 'tamaño de fuente'. Declaración eliminada. @ http://arxiv.org/pdf/0707.3195v1.pdf
[16: 59: 53.569] Error al analizar el valor de 'fuente'. Declaración eliminada. @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh , ¿crees que está relacionado?

@yurydelendik : Parece que no, he usado el paso a paso y ambas advertencias aparecen en la primera página (la primera al configurar el arXiV-nr vertical a la izquierda, la segunda al terminar la página).

@yurydelendik Creo que podemos cerrar esto. No puedo replicar el problema en el desarrollo de Arch Linux x64, Firefox 22 y pdf.js. Tampoco hay problemas en Windows 7 x64.

Acabo de comprobarlo dos veces. El problema aún persiste en mis máquinas.
(ambos Ubuntu Linux 12.04, Firefox 22, Pdf.js 0.8.1)

Tal vez esté arreglado en pdf.js de desarrollo, no lo sé.

Avísame si quieres que pruebe algo.

Tal vez esté arreglado en pdf.js de desarrollo, no lo sé.
Avísame si quieres que pruebe algo.

@kaymes Por favor, intente descargar el archivo y abrirlo (haciendo clic en el botón Abrir archivo, ubicado en el lado derecho de la barra de herramientas PDF.js) en el visor web: http://mozilla.github.io/pdf.js /web/viewer.html.
Esto siempre usa la última versión de PDF.js, así que inténtelo y vea si el archivo se muestra correctamente.

Acabo de probar el visor en línea en
http://mozilla.github.io/pdf.js/web/viewer.html. Todavía se rinde mal
con todos los tirantes demasiado grandes. Era otra computadora más
pero también uno que ejecuta Ubuntu 12.04 con Firefox 22. Así que el problema podría ser
Específico de Linux (o incluso Ubuntu) pero se muestra en al menos tres
diferentes maquinas.

Hmm, extraño. En ese caso, supongo que sería específico de Ubuntu, porque no hay problemas aquí en Arch Linux. Aprendiendo algo nuevo cada día :-)

Acabo de probar si es culpa de algún complemento. Comencé firefox
en modo seguro y abrió el documento utilizando el visor en línea. los
el problema aún persiste. Así que se pueden descartar complementos.

E hice una prueba más: descargué Firefox directamente desde Mozilla. Entonces
todos los parches / modificaciones de Ubuntu se han ido. Y luego comencé este
en modo seguro. El problema sigue ahí.

También veo esto en Ubuntu 13.04

[18:42:43.639] "PDF 8d10792f8d2028a66825b6ce6ab5b3c1 [1.4 GPL Ghostscript GIT PRERELEASE 9.05 / dvips(k) 5.95a Copyright 2005 Radical Eye Software] (PDF.js: 0.8.510)

¿Sigue siendo un problema con la última versión de desarrollo de PDF.js en http://mozilla.github.io/pdf.js/web/viewer.html? No puedo reproducir esto en Arch Linux.

El problema aún prevalece (Ubuntu 12.04, FF26).

Bajo Linux Mint basado en Ubuntu, este error también se puede reproducir con Google Chrome 34 (y Firefox 32.0a1), por lo que no es un problema exclusivo de Firefox. Opera 12.16 se renderiza correctamente.

Solo voy a usar las palabras TeX y LaTeX y matemáticas en este comentario para que la gente pueda encontrar este error.

Esto parece estar relacionado con el antialiasing: uso gnome 3.14 en una máquina Debian Jessie, Firefox 33.0.2. Tanto en el antialiasing RGB como en el de escala de grises, cuando se selecciona la opción de leve sugerencia (en Gnome Tweak Tool), tengo el mismo problema. Cuando cambio a cualquiera de las otras opciones de sugerencias (Completo, Medio o Ninguno), se ve como se supone que debe verse.

Tenga en cuenta que en Firefox al menos debe actualizar la pestaña para ver el cambio.

Para mí (Arch Linux), este error aparece si utilizo un fontconfig / freetype parcheado infinitamente. El uso de paquetes vanilla no muestra este error.

No sé si está relacionado con los parches o con la configuración enviada con los paquetes parcheados.

Puede reproducirse en Ubuntu 14.04 en Chromium y Firefox. Observe cómo cambian los artefactos al escalar el documento. He visto este error en docenas de documentos pdfTeX en pdf.js, por ejemplo, los índices de suma también se ven afectados.

Esto realmente parece ser un problema anterior, aunque no estoy seguro de dónde archivarlo.

Reconstruí Ubuntu 14.04 freetype / fontconfig sin la mayoría de los parches específicos de la distribución, pero el problema persiste.

También instalé el último freetype / fontconfig de Ubuntu 15.10, pero el problema persiste.

¿Quizás esto deba archivarse como un error ascendente de Firefox (Linux)? Simplemente no estoy seguro de si es causado por Firefox o una biblioteca de fuentes de Linux en particular.

Aquí hay un caso de prueba mínimo:

\documentclass{article}
\begin{document}
$$ \sqrt{\frac{1}{2}} $$
\end{document}

Esto se representa de manera diferente en Ubuntu y Windows:

<style type="text/css">
* { margin:0; padding: 0 }
@font-face { font-family:"g_font_1";src:url(data:font/opentype;base64,T1RUTwAJAIAAAwAQQ0ZGIEG/4oQAAACcAAACWU9TLzJL4jE4AAAC+AAAAGBjbWFwAA0ApQAAA1gAAAAsaGVhZKsnRLAAAAOEAAAANmhoZWEDBvRyAAADvAAAACRobXR4BdwAAAAAA+AAAAAMbWF4cAADUAAAAAPsAAAABm5hbWUiztZPAAAD9AAAAgRwb3N0AAMAAAAABfgAAAAgAQAEBAABAQEOTU5QRUhJK0NNRVgxMAABAQFF+BsA+BwB+B0C+B4D+B8EHgoAH4uLHgoAH4uLDAdzHPRwHAWu+ZgFHQAAAKoPHQAAAAAQHQAAAK8RHQAAABwdAAABYhIABQEBDSAtOkBWZXJzaW9uIDAuMTFTZWUgb3JpZ2luYWwgbm90aWNlTU5QRUhJK0NNRVgxME1OUEVISStDTUVYMTBNZWRpdW0AAAAAAAAAAAADAQEDC62LDhwB9BwAABYOHAPoHABvFhwBYxz3jhUc//8GHP8oHAPqBRz/fRz/MgUc//kc//ccAAAc//4cAAAc//8IHAAAHP/8HAANHP/1HAABHP//CBwARBwAawUcAOcc+88FHAAhHAAAHAADHAAAHAAGHAAaCBwCJhwJHQUcAAIcAAccAAIcAAkcAAAcAAUIHAALHP/4HAAJHP/0Hhz/8BwAABz//Rz/8xz//Rz/8ggOHgoEeW8MCboKuguzkgwMs5IMDYsMDh0AAAAcEwBrAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbAsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLAAAAAAADAiQB9AAFAAACigK7AAAAjAKKArsAAAHfADEBAgAAAAAGAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAqMjEqAAAAcgByAwT0cABkAwQLkAAAAAAAAAAAAa8AAAAAAHIAAwAAAAEAAwABAAAADAAEACAAAAAEAAQAAQAAAHL//wAAAHL///+QAAEAAAAAAAEAAAAAEAAAAAAAXw889QAAA+gAAAAAngt+JwAAAACeC34nAAD0cA//AwQAAAARAAAAAAAAAAAAAQAAAwT0cAAA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAfQAAAPoAAAAAFAAAAMAAAAAABQA9gABAAAAAAAAABAAAAABAAAAAAABAA0AEAABAAAAAAACAAcAHQABAAAAAAADAAgAJAABAAAAAAAEAA0ALAABAAAAAAAFAAwAOQABAAAAAAAGAAAARQABAAAAAAAHAAcARQABAAAAAAAIAAcATAABAAAAAAAJAAcAUwADAAEECQAAACAAWgADAAEECQABABoAegADAAEECQACAA4AlAADAAEECQADABAAogADAAEECQAEABoAsgADAAEECQAFABgAzAADAAEECQAGAAAA5AADAAEECQAHAA4A5AADAAEECQAIAA4A8gADAAEECQAJAA4BAE9yaWdpbmFsIGxpY2VuY2VNTlBFSEkrQ01FWDEwVW5rbm93bnVuaXF1ZUlETU5QRUhJK0NNRVgxMFZlcnNpb24gMC4xMVVua25vd25Vbmtub3duVW5rbm93bgBPAHIAaQBnAGkAbgBhAGwAIABsAGkAYwBlAG4AYwBlAE0ATgBQAEUASABJACsAQwBNAEUAWAAxADAAVQBuAGsAbgBvAHcAbgB1AG4AaQBxAHUAZQBJAEQATQBOAFAARQBIAEkAKwBDAE0ARQBYADEAMABWAGUAcgBzAGkAbwBuACAAMAAuADEAMQBVAG4AawBuAG8AdwBuAFUAbgBrAG4AbwB3AG4AVQBuAGsAbgBvAHcAbgADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA);}
td { border: 1px solid #ccc; width: 9px; height: 10px; }
</style>
<table cellspacing="0" cellpadding="0" style="border-collapse:collapse;empty-cells:show">
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>
<div style='font:16px "g_font_1";position:absolute;top:0;left:0'>r</div>

https://bugzilla.mozilla.org/show_bug.cgi?id=1200077

No olvide que Chrome también se ve afectado, por lo que probablemente no sea un error de Firefox.
Captura de pantalla: Chrome 44 en Linux Mint (basado en Ubuntu).

https://bugs.freedesktop.org/show_bug.cgi?id=91829

@jethrogb ¡ Gracias por

Parece que la gente de freedesktop concluye que esto sigue siendo en parte un error de pdfjs. Así que probablemente todavía queda trabajo por hacer aquí.

Además, mientras tanto, ¿hay alguna solución alternativa que no sea hacer zoom hasta que desaparezca el error? Utilizo sharelatex con frecuencia, que parece tener un visor de pdfjs incorporado.

Es una falla de pdf.js. En pocas palabras, pdf.js crea fuentes no válidas para esos símbolos matemáticos. Posteriormente, el auto-hinter de fuente llega a conclusiones erróneas que desencadenan la visualización incorrecta.

Por lo tanto, pdf.js debería corregir la forma en que se convierten las fuentes pdf.

Me encontré con este problema con la extensión de vista de pdf de atom , como una prueba más de que no es un problema de Firefox. Capturas de pantalla de cómo se ve en atom , en PDF.js y cómo debería verse .

Puedo confirmar que este problema existe en Chrome en Ubuntu 15.10.

Este error ahora debería corregirse con una biblioteca Freetype actualizada instalada (> = 2.6.2)

No, el error real está en la conversión de tipo 1 a OpenType de pdf.js que crea glifos de fuente no válidos, y AFAIK, esto aún no se ha solucionado.

Oh, leí mal el error aguas arriba. Perdón por la mala información.
Por cierto, no detecto este error en mis dos máquinas Debian (Jessie y Stretch).

lo mismo aquí: ¡sin problemas!
Arch Linux x86_64 y cosas de fuentes parcheadas con infinalidad [*], firefox 45.0.2
(lo mismo ocurre con el cromo 50.0.2661.75-1)

[*] cairo-infinality-ultimate 1.14.6-1
fontconfig-infinality-ultimate 2.11.95-4
freetype2-infinality-ultimate 2.6.3-2

Disculpe si esto es inapropiado, pero ofreceré una recompensa de $ 500 por la corrección de este error.

En ShareLaTeX usamos PDF.js para renderizar el PDF producido a partir de los documentos LaTeX de los usuarios, por lo que nuestros usuarios probablemente encuentren este error con más frecuencia que el usuario promedio.

No pude encontrar ningún precedente o comentario con respecto a ofrecer una recompensa por errores para este proyecto, así que espero que esté bien. No dude en ponerse en contacto conmigo en [email protected]. Si lo prefiere, podemos configurar la recompensa en fideicomiso con algo como https://www.bountysource.com/ , o si alguien más quisiera agregar a la recompensa.

Por cierto: esto se ha corregido en sentido ascendente en freetype https://bugs.freedesktop.org/show_bug.cgi?id=91829

Esto no tiene nada que ver con FreeType, como la gente sigue diciendo y como se comenta a fondo en el problema de FreeType que vincula, hay un error en el convertidor de Type1 a OpenType de pdf.js.

Esto no tiene nada que ver con FreeType ... hay un error en el convertidor Type1 a OpenType de pdf.js.

En realidad, es un problema relacionado con FreeType porque solo este motor experimenta el problema. Puede haber un problema con el convertidor de pdf.js, y será útil entender por qué está sucediendo. Lamentablemente, el enlace anterior no proporciona las explicaciones detalladas. Más aportes de los expertos de FreeType acelerarían la resolución de este error.

Un archivo de fuente convertido por pdf.js
El archivo de fuente original incrustado en el PDF

Citas de elección del informe de errores de FreeType:

La fuente en cuestión tiene un signo de raíz en la letra 's'.

La fuente contiene un cmap que asigna la posición r' (not s ', BTW) a un glifo llamado .notdef'. Since the auto-hinter accesses a font not by glyph names but by a Unicode mapping (either a real one or a synthesized), it believes that glyph r' está presente

¡Los cmaps de fuentes no deben mentirle al auto-hinter!

Oh, probablemente también sea parcialmente culpa de pdf.js, tal vez el cmap falso se compile a partir de pdf.js, no de la fuente original. Alguien necesita verificar.

El archivo original cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name radicalbigg 'en la posición 0x72. El archivo subconjunto "CMEX10.pfb" en el informe de errores de FireFox también tiene el nombre de glifo correcto.

Solución provisional en # 7482. No tengo recursos para investigar esto más si las pruebas fallan, pero podría ser simple. La fuente en el pdf es un poco extraña ya que tiene una fuente simbólica, pero también tiene mapeos Unicode para algunos de los símbolos. Por lo general, para las fuentes simbólicas, movemos todos los glifos al área de uso privado si solo hay una asignación de identidad Unicode.

Puedo reproducir # 7482 soluciona el problema para mí al menos en la segunda página del PDF vinculado en la primera publicación.

@brendandahl Impresionante, gracias. Verificaré si su parche lo corrige lo antes posible. ¿Es capaz de fusionarse? (¿Parece que fallan algunas pruebas?)

¿Es capaz de fusionarse? (¿Parece que fallan algunas pruebas?)

Eso es lo que se espera con este tipo de parche. Sin embargo, debemos inspeccionar las diferencias antes de realizar una llamada.

Buen progreso! Hice algunas pruebas más extensas y encontré una complicación: la solución funciona para la salida producida por dvips + ghostscript pero no para la salida producida por pdftex, si tomo la fuente del caso de prueba anterior y la compilo con pdflatex, la salida se representa incorrectamente .

Se adjunta un caso de prueba más exhaustivo que incluye una de las ecuaciones rotas del archivo 0707.3195v1.pdf original.

El primer archivo pdf es producido directamente por pdflatex y luego la misma salida es producida por latex->dvips->ps2pdf . Las capturas de pantalla son la representación de pdf.js con la solicitud de extracción aplicada; no resuelve el problema con la salida de pdftex, pero lo soluciona para la conversión de ghostscript.

Presumiblemente, hay algo diferente en la forma en que la fuente está incrustada en la salida de pdftex que hace que el error aún ocurra.

test-pdftex.pdf - aún roto

test-ps2pdf.pdf - fijo

Test.tex.txt de fuente de látex original

Hola @jpallen , solo quiero que sepas que parece solucionar el problema en Sharelatex cuando cambio el compilador a XeLatex.

Hemos investigado un poco más esto en ShareLaTeX, y parece que el parche anterior (https://github.com/mozilla/pdf.js/pull/7482 por @brendandahl) está en las líneas correctas en términos de mover personajes al área de uso privado, pero no cubre todos los casos necesarios. Los PDF generados por ps2pdf funcionan, pero los generados directamente por pdflatex todavía tienen este problema de renderizado.

Si ingenuamente movemos _todo_ al área de uso privado (por ejemplo, https://github.com/brendandahl/pdf.js/compare/move-non-unicode-glyphs...briangough:put-all-symbolic-chars-in- área de uso privado), luego se procesa correctamente. Sin embargo, este es solo un ejemplo de depuración, ya que supongo que no es una buena idea.

En este punto nuestro conocimiento llega al límite y no sabemos cómo identificar los símbolos correctos para poner en el área de uso privado. Entonces, ¿hay algo que podamos hacer para ayudar a que esto avance?

Si ingenuamente movemos todo al área de uso privado (por ejemplo, brendandahl @ move-non-unicode-glyphs ... briangough: put-all-symbolic-chars-in-private-use-area), entonces se representa correctamente. Sin embargo, este es solo un ejemplo de depuración, ya que supongo que no es una buena idea.

Sin haber probado lo anterior, sospecho que hacerlo podría conducir a una peor representación en _muchos_ archivos PDF, ya que podría (básicamente) hacer que las sugerencias se deshabiliten para _todas_ las fuentes simbólicas en ciertos procesadores de fuentes. (Tenga en cuenta que muchas fuentes afirman ser simbólicas, incluso cuando en realidad no lo son).

En este punto nuestro conocimiento llega al límite y no sabemos cómo identificar los símbolos correctos para poner en el área de uso privado. Entonces, ¿hay algo que podamos hacer para ayudar a que esto avance?

Dado que los casos problemáticos usan fuentes Type1 normales, sigo pensando que la solución correcta _puede_ ser asegurar que proporcionemos la información adecuada Charset / Encoding al convertir fuentes Type1 en Type1Font_wrap .

@jpallen creo que debemos reconocer las fuentes que son generadas por latex y esas fuentes son símbolos (por ejemplo, por su nombre o la forma en que se crean), pero no se reconocerán como tales en el resto de los casos.

No mover _todos_ los caracteres al área privada nos da algunas ventajas, por ejemplo, la posibilidad de usar fuentes en los controles de entrada, mejor instrumentación y la capacidad del motor para descartar glifos o fuentes no válidas y aún así obtener texto algo legible. Entonces, saber si el glifo es un símbolo es una clave aquí.

Una idea tentativa, basada en PR # 7482, tal vez podría ser mover caracteres a la PUA cuando no podemos confiar en que los datos toUnicode sean correctos; por ejemplo, algo como esto: https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus : issue-2594.

¡Excelente! Probé el nuevo parche en Snuf fleupagus: problema-2594 y parece funcionar bien para mi caso de prueba y varios documentos pdflatex que probé. : +1:

Como prueba, lo he implementado en producción en el visor de pdf en www.ShareLaTeX.com , para ver si

Hemos probado este parche (https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594) en producción durante las últimas 3 semanas y ha solucionado los problemas de representación de fuentes LaTeX para nosotros, sin que aparezcan otros problemas. Sería genial si se pudiera incluir gracias. : +1:

Comencé a revisar # 7705 y comencé a preguntarme por qué mi parche original no solucionó también test-pdftex.pdf . Con solo mirar los datos de la fuente, parece que pdf.js debería mover la mayoría de los glifos de DVFZZA+CMEX10 al área de uso privado, ya que la mayoría de ellos no tienen un nombre de glifo válido para valores Unicode. Por ejemplo, uno de los glifos problemáticos (charcode = 110 name = 'braceleftBig') no tiene un valor Unicode pero se asigna a 'n'. El problema parece provenir de cuando construimos un mapa Unicode, contiene correctamente 68 valores con glifos que tienen valores Unicode coincidentes, pero después de construirlo, volvemos a agregar todos los valores de codificación originales, por lo tanto 110 se completa con 'n'.

No estoy muy seguro de cuál es la solución correcta aquí porque si eliminamos el código para volver a agregar valores de codificación, nuestra selección de texto retrocederá de https://github.com/mozilla/pdf.js/commit/325f7afcca30c891ec7be06a5178c012a052bd55

Quizás @Snuffleupagus tenga algunos pensamientos ...

_ Como sugiere https://github.com/mozilla/pdf.js/issues/2594#issuecomment -254289210, la versión anterior de PR # 7705 contenía una solución que era demasiado simplista.

Por lo tanto, he reunido un nuevo (y para mí probablemente el último) intento de arreglar esto, que se puede probar con: http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html.
Sería de gran ayuda si las personas que actualmente están afectadas por este problema pudieran probar la última versión de PR # 7705 e informar si es suficiente para solucionar este problema.

Funciona bien en test-pdftex.pdf, intentaremos implementarlo en producción en www.ShareLaTeX.com esta semana y veremos si hay algún problema informado.

Funciona bien en test-pdftex.pdf, intentaremos implementarlo en producción en www.ShareLaTeX.com esta semana y veremos si hay algún problema informado.

Como se discutió en IRC, consulte http://logs.glob.uno/?c=mozilla%23pdfjs&s=21+Nov+2016&e=21+Nov+2016#c54315 , nos gustaría seguir adelante con PR # 7705 .
@briangough ¿Tiene algún resultado de probar el parche en producción en ShareLaTeX?

Como se mencionó anteriormente en https://github.com/mozilla/pdf.js/issues/2594#issuecomment -259930252, sería más útil si los afectados actualmente por este problema pudieran ayudar a probar la solución propuesta, lo que se puede hacer usando por ejemplo, la vista previa en http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html, ¡e informe si soluciona estos problemas!

Nos gustaría aterrizar PR # 7705, pero realmente necesitamos la confirmación de la solución antes de hacerlo.

Perdón por el retraso. El parche funciona bien, no hay quejas de nuestros usuarios, gracias.

Cierre según lo fijado por # 7705, ¡gracias a @Snuffleupagus y @brendandahl!