Nous autorisons le téléchargement de fichiers SVG sur les forums Maker, en partie parce que l’un de nos publics cible est constitué d’utilisateurs de graveurs et de découpeuses laser, où les SVG sont couramment utilisés. Nous souhaitons que les personnes puissent les télécharger, tant pour que d’autres puissent les récupérer que pour les voir dans le cadre de discussions. Cela se produit souvent dans le contexte d’une demande d’aide.
Malheureusement, ils ont tendance à être rendus extrêmement petits, parfois pratiquement invisibles. Ce soir, quelqu’un a téléchargé un fichier SVG qui a été automatiquement défini à 12x8 pixels, une taille si petite que les lignes colorées ont disparu et que l’image a été rendue un peu comme une photo d’un ours polaire dans une tempête de neige. (Je suis étonné que le modérateur de la catégorie ait remarqué la présence d’un SVG.) Cela a été un problème récurrent pour nous.
Les utilisateurs expérimentés pourraient peut-être apprendre qu’ils peuvent, par exemple, remplacer 12x8 par 480x320 pour pouvoir réellement voir l’image, mais ces utilisateurs n’ont généralement pas besoin de faire cela ; la plupart des personnes publiant des SVG sont des nouveaux venus cherchant de l’aide, et ils ignorent cette particularité de Discourse.
Qu’est-ce qui amène Discourse à choisir de limiter les SVG à quelques pixels seulement ?
Voici la requête que j’ai reçue du modérateur de la catégorie, à titre de référence :
Édition : D’après ce fil de discussion, une raison possible expliquant pourquoi cela pourrait affecter ce forum plus que les autres :
Les découpeuses laser « K40 » courantes ont un lit de 12 pouces x 8 pouces et fonctionnent par incréments précis de millièmes de pouce plutôt qu’en système métrique. Ainsi, l’utilisation de l’unité pouce est en fait particulièrement adaptée pour ces fichiers SVG ; il ne s’agit pas d’une question de « les utilisateurs devraient utiliser le système métrique ».
Voici à quoi ressemble cette image spécifique ici (ce n’est pas un peu de poussière sur votre écran, c’est le rendu de l’image) :
Je vois exactement la même taille de 12x8 pixels déduite ici ; voici le code Markdown brut exactement tel qu’affiché après le téléchargement de ce fichier, sans aucune modification :
Évidemment, cela nécessitait d’autoriser le téléchargement de SVG ; il me semble que j’ai dû ajouter svg à la configuration authorized_extensions il y a environ deux ans.
J’ai bien vu le code de nettoyage des SVG dans Discourse. Je constate qu’ils sont rendus ici. En raison de la valeur des SVG pour l’une des missions clés de Maker Forums, combinée à la manière dont nous gérons notre base d’utilisateurs, nous avons choisi de les afficher intentionnellement. Lorsque les gens rencontrent des difficultés pour découper ou graver des SVG au laser, pouvoir voir le SVG dans le contexte de la conversation est une aide précieuse pour la compréhension et le diagnostic.
Puisque j’ai pu afficher des SVG ici sur meta également, vous avez probablement pris la même décision, bien que pour une raison différente, bien sûr.
Je voulais simplement m’assurer que, dans l’enquête, le point soulevé par Scorch ci-dessus — selon lequel les 12x8 pixels ne sont probablement pas aléatoires, mais plutôt dus à une mauvaise gestion des unités dans les attributs width et height de l’élément svg : <svg ... width="12in" height="8in" ...> — m’avait échappé lorsque j’ai initialement posé la question.
Vous avez tout à fait raison. La bibliothèque que nous utilisons pour récupérer les tailles d’image se contente de prendre la valeur entière des attributs width et height dans les fichiers SVG, sans tenter d’analyser les types d’unités. Je vais faire quelques investigations et essayer de trouver la solution la plus élégante pour ce problème.
J’ai expérimenté avec plusieurs fichiers problématiques en utilisant à la fois ImageMagick et librsvg. Il semble qu’ImageMagick utilise par défaut une résolution de 96 DPI, tandis que librsvg utilise 90 par défaut. Je suppose que l’un ou l’autre convient, tant que nous choisissons une valeur par défaut raisonnable et que nous nous y tenons…
Soit 90, soit 96 rendrait les SVG dont la largeur et la hauteur sont exprimées en millimètres (et non seulement en pouces) d’une taille plus raisonnable. Actuellement, les SVG dont la largeur et la hauteur sont en millimètres s’affichent essentiellement à raison de 1 mm par pixel du navigateur, soit à une échelle d’environ ⅓ à ¼. Auparavant, je haussais simplement les épaules en disant : « Bon, c’est scalable, je suppose… », mais si vous pouviez prendre en charge à la fois les pouces et les millimètres avec une résolution par défaut raisonnable, cela améliorerait considérablement le rendu des deux.
Le HTML des courriels est un ensemble de HTML si restreint (sans parler de son implémentation incohérente ; voir Litmus), et vous soulignez que Discourse est conçu pour le web moderne (par exemple, le défilement infini), que je n’avais pas conscience que la représentation complète dans les courriels de tout ce qui peut être représenté sur le web soit une considération déterminante. C’est un nouvel aspect que je dois comprendre. (Je pourrais imaginer que, avec des ressources infinies, on pourrait convertir SVG en PNG pour l’inclure dans les courriels, ce qui offrirait une fidélité supérieure à beaucoup des absurdités requises pour le HTML des courriels en général, mais avec SVG non activé par défaut, cela semble être une priorité très faible…)
@Neotinker avait évoqué l’idée d’utiliser un jour three.js pour intégrer des modèles 3D interactifs dans les conversations Discourse concernant ces modèles ; quelque chose que nous aimerions activer pour les Forums des Créateurs, si une telle fonctionnalité venait à exister. La considération « impossible à afficher dans les courriels » ferait-elle obstacle à l’acceptation d’un tel travail si lui ou quelqu’un d’autre l’implémentait ? (Je note que three.js utilise Discourse pour son propre forum…)
Ou si cela relève davantage d’une décision de priorisation concernant le temps que CDCK souhaite consacrer à ce problème, je serais ravi d’obtenir un lien vers le code ; je ne veux pas imposer une charge ici. Vous avez vu dans mes contributions précédentes que je ne suis pas un expert de Ruby ou de RoR, mais je serais prêt à ajouter cela à ma liste de choses à examiner. (J’avais initialement publié ce sujet avant de réaliser qu’il supprimait les unités et supposait des pixels, pensant donc qu’il s’agissait d’une décision de conception, ce qui explique pourquoi je l’ai placé dans ux plutôt que dans bug)
J’ai créé une demande de tirage vendredi après-midi qui devrait résoudre le problème des fichiers SVG qui apparaissent minuscules lorsque leurs dimensions sont exprimées en pouces, centimètres, millimètres ou unités similaires.
La demande de tirage est en attente de révision du code et n’est donc pas encore disponible, mais elle devrait être prête dans un court délai.
Merci d’avoir partagé le commit pour que je puisse voir où et comment cela a été fait !
Désolé, j’ai mal interprété @codinghorror — je pensais qu’il voulait dire que cela s’était transformé en une véritable boîte de Pandore, et je ne voulais pas créer autant de travail ici.
