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 e-mails est un ensemble de balises si restreint (sans parler d’une implémentation incohérente ; voir Litmus), et vous avez souligné 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 e-mails de tout ce qui pouvait être affiché sur le web soit une considération majeure. C’est un aspect nouveau pour moi à intégrer. (J’imagine que, avec des ressources infinies, on pourrait convertir les SVG en PNG pour les inclure dans les e-mails, ce qui offrirait une fidélité bien supérieure à la plupart des bidouilles habituellement nécessaires pour le HTML des e-mails, mais le fait que SVG ne soit pas activé par défaut rend cela loin d’être une priorité…)
@Neotinker avait envisagé à un moment donné d’utiliser Three.js dans les onebox pour intégrer des modèles 3D interactifs dans les conversations Discourse sur ces modèles ; quelque chose que nous voudrions activer pour les Forums des Créateurs, s’ils venaient jamais à exister en tant que fonctionnalité. La considération selon laquelle « cela ne peut pas être affiché dans les e-mails » empêcherait-elle d’accepter un tel travail s’il était implémenté par lui ou par quelqu’un d’autre ? (Je note que Three.js utilise Discourse pour son propre forum…)
Ou si cela relève davantage d’un choix de priorité concernant le temps que CDCK souhaite consacrer à ce problème, je serais heureux de recevoir une indication vers le code ; je ne veux pas sous-entendre que cela constitue une charge. Vous avez vu, dans mes contributions précédentes, que je ne suis pas un expert Ruby ou RoR, mais je suis prêt à l’ajouter à ma liste des sujets à examiner. (J’ai publié ce sujet initialement avant que nous réalisions qu’il s’agissait d’une perte d’unités et d’une hypothèse de pixels, pensant donc qu’il s’agissait d’une décision de conception, c’est pourquoi je l’ai placé dans Contribute > UX au lieu de Contribute > 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.
