En Maker Forums permitimos la subida de archivos SVG, en parte porque uno de nuestros grupos de usuarios está formado por usuarios de grabadoras y cortadoras láser, donde los SVG son de uso común. Queremos que las personas puedan subirlos, tanto para que otros los descarguen como para poder verlos durante las discusiones. Esto suele ocurrir en el contexto de una solicitud de ayuda.
Desafortunadamente, tienden a renderizarse extremadamente pequeños, a veces tan pequeños que son prácticamente invisibles. Esta noche, alguien subió un SVG y se estableció automáticamente a 12x8 píxeles, lo cual era tan pequeño que las líneas de color desaparecieron y se visualizó casi como una imagen de un oso polar en una tormenta de nieve. (Me sorprende que el moderador de la categoría se diera cuenta de que había un SVG allí.) Este ha sido un problema común para nosotros.
Los usuarios experimentados podrían aprender, por ejemplo, a cambiar 12x8 por 480x320 para poder ver realmente la imagen, pero la mayoría de los usuarios experimentados no necesitan hacer esto; la mayoría de las personas que publican SVG son nuevos usuarios que buscan ayuda y no conocen esta peculiaridad de Discourse.
¿Qué hace que Discourse decida limitar los SVG a solo unos pocos píxeles?
Aquí está la consulta que recibí del moderador de la categoría, para referencia:
Edición: De ese hilo, una posible razón por la que esto podría afectar a este foro en particular más que a otros:
Las cortadoras láser comunes “K40” tienen una cama de 12"x8" y funcionan en incrementos exactos de milésimas de pulgada, en lugar de en unidades métricas, por lo que usar pulgadas es en realidad razonable específicamente para esos archivos SVG; no se trata de que “los usuarios deberían usar el sistema métrico”.
Obviamente, esto requirió permitir la carga de SVG; mi recuerdo es que tuve que agregar svg a la configuración authorized_extensions hace unos dos años.
Vi el código de saneamiento de SVG en Discourse. Veo que se están renderizando aquí. Debido al valor de los SVG para una de las misiones clave de Maker Forums, combinado con cómo gestionamos a nuestra base de usuarios, hemos optado por mostrarlos intencionalmente. Cuando las personas tienen problemas para cortar o grabar SVG con láser, poder ver el SVG en el contexto de la conversación es una ayuda valiosa para la comprensión y el diagnóstico.
Dado que pude mostrar SVG aquí en meta también, presumiblemente has tomado la misma decisión, aunque obviamente por una razón diferente.
Solo quiero asegurarme de que, en la investigación, el punto que Scorch mencionó anteriormente sobre que los 12x8 píxeles probablemente no sean aleatorios, sino que se deban a la falta de manejo de las unidades en los atributos de ancho y alto del elemento svg: <svg ... width="12in" height="8in" ...> — no me había dado cuenta de eso cuando publiqué la pregunta por primera vez.
Tienes toda la razón. La biblioteca que estamos usando para obtener los tamaños de imagen simplemente toma el valor entero de los atributos width y height en los archivos SVG, y no intenta analizar ningún tipo de unidad. Voy a investigar un poco e intentar encontrar la solución más limpia para este problema.
He estado experimentando con algunos de los archivos problemáticos usando tanto ImageMagick como librsvg. Parece que ImageMagick usa por defecto un DPI de 96, mientras que librsvg usa por defecto 90. Supongo que cualquiera está bien, siempre que elijamos un valor por defecto razonable y nos mantengamos fieles a él…
Tanto 90 como 96 harían que los SVG con ancho y alto no solo en pulgadas, sino también en mm, tuvieran un tamaño más razonable. Ahora mismo, los SVG con ancho y alto en mm se muestran básicamente a 1 mm por píxel del navegador, es decir, a una escala de aproximadamente 1/3 a 1/4. Antes simplemente encogía los hombros y decía: «Bueno, supongo que es escalable…», pero si pudieras añadir tanto pulgadas como mm con una resolución predeterminada razonable, ambos se renderizarían mucho mejor.
El HTML para correos electrónicos es un conjunto tan restringido (por no mencionar inconsistentemente implementado; véase Litmus), y ustedes señalan que Discourse está creado para la web moderna (por ejemplo, desplazamiento infinito), así que no tenía idea de que la representación completa en correo electrónico de todo lo que podría representarse en la web fuera una consideración prioritaria. Este es un nuevo matiz para mí. (Podría imaginar que, dados los recursos infinitos, uno podría renderizar SVG a PNG para incluirlo en el correo electrónico, lo cual tendría una fidelidad mayor que mucha de la tontería necesaria para el HTML de correo electrónico en general, pero con SVG no habilitado por defecto, eso se siente muy bajo como prioridad…)
@Neotinker tenía la idea de, en algún momento, usar onebox con threejs para incrustar modelos 3D interactivos en las conversaciones de Discourse sobre esos modelos; algo que querríamos activar para los Foros de Fabricantes si alguna vez existiera como función. ¿La consideración de “no se puede renderizar eso en el correo electrónico” impediría aceptar dicho trabajo si él u otra persona lo implementara? (Observo que threejs usa Discourse para su propio foro…)
O si esto es más bien una llamada de prioridad sobre cuánto tiempo quiere dedicar CDCK al problema, estaría feliz con que me dieran una pista sobre el código; no quiero implicar que esto sea una carga aquí. Ustedes han visto en mis contribuciones anteriores que no soy un experto en Ruby o RoR, pero estaría dispuesto a ponerlo en mi lista de cosas por revisar. (Publicé este tema originalmente antes de que nos diéramos cuenta de que estaba descartando unidades y asumiendo píxeles, así que pensé que era una decisión de diseño, por eso lo puse en Contribute > UX en lugar de Contribute > Bug)
El viernes por la tarde creé una solicitud de extracción que debería resolver el problema de que los archivos SVG aparezcan diminutos cuando sus dimensiones se expresan en pulgadas, centímetros, milímetros o unidades similares.
La solicitud de extracción está pendiente de revisión de código, por lo que aún no está disponible, pero debería estar lista en breve.
¡Gracias por compartir el commit para que pudiera ver dónde y cómo se hizo!
Disculpa que malinterpreté a @codinghorror — pensé que se refería a que se había convertido en un verdadero lío, y no quería generar tanto trabajo aquí.
