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 de los correos electrónicos es un conjunto de HTML tan restringido (por no mencionar su implementación inconsistente; véase Litmus), y ustedes hacen hincapié en que Discourse está creado para la web moderna (por ejemplo, el desplazamiento infinito), que no tenía conciencia de que la representación completa en el correo electrónico de todo lo que se podría representar en la web fuera una consideración determinante. Esta es una nueva complejidad que debo entender. (Podría imaginar que, dadas recursos ilimitados, alguien podría renderizar SVG a PNG para incluirlo en el correo electrónico, lo que ofrecería una mayor fidelidad que gran parte de la confusión requerida para el HTML de correo electrónico en general, pero con SVG no habilitado de forma predeterminada, eso se siente muy bajo como prioridad…)
@Neotinker tenía la idea de que en algún momento se utilizara 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 una función. ¿La consideración de “no se puede renderizar eso en el correo electrónico” impediría aceptar dicho trabajo si él o alguien más lo implementara? (Noto que threejs utiliza Discourse para su propio foro…)
O si esto es más una llamada de prioridad sobre cuánto tiempo CDCK quiere dedicar al problema, estaría encantado de recibir una referencia al código; no quiero implicar una carga aquí. Ya 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 que revisar. (Publicé este tema originalmente antes de darnos cuenta de que estaba omitiendo unidades y asumiendo píxeles, por lo que pensé que era una decisión de diseño, y esa fue la razón por la que lo puse en ux en lugar de 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í.
