SVG-Uploads zu klein angezeigt

Wir erlauben das Hochladen von SVG-Dateien auf den Maker-Foren, unter anderem, weil eine unserer Nutzergruppen Anwender von Lasergravurmaschinen und -schneidern ist, bei denen SVGs häufig verwendet werden. Wir möchten, dass Nutzer sie hochladen können – sowohl damit andere sie herunterladen können, als auch damit sie im Rahmen von Diskussionen sichtbar sind. Oft geschieht dies im Kontext einer Hilferfrage.

Leider werden sie jedoch extrem klein dargestellt, manchmal praktisch unsichtbar klein. Heute Abend lud jemand eine SVG-Datei hoch, die automatisch auf 12x8 Pixel festgelegt wurde. Das war so klein, dass die farbigen Linien verschwanden und die Darstellung eher wie ein Bild eines Eisbären in einem Schneesturm wirkte. (Ich bin erstaunt, dass der Kategorienmoderator überhaupt bemerkt hat, dass dort eine SVG-Datei war.) Dies ist für uns ein häufiges Problem.

Erfahrene Nutzer könnten zwar lernen, dass sie beispielsweise 12x8 in 480x320 ändern können, um das Bild tatsächlich sehen zu können, doch diese erfahrenen Nutzer müssen das meist nicht tun. Die meisten, die SVG-Dateien posten, sind Neueinsteiger, die Hilfe suchen, und sie kennen diesen Discourse-Sonderfall nicht.

Was veranlasst Discourse dazu, SVGs auf nur wenige Pixel zu begrenzen?

Hier ist die Anfrage, die ich vom Kategorienmoderator erhalten habe, zur Referenz:

Edit: Aus diesem Thread ein möglicher Grund, warum dies dieses Forum stärker als andere betrifft:

Häufige „K40“-Laserschneidmaschinen verfügen über ein Arbeitsfeld von 12"x8" und arbeiten in exakten Schritten von einem Tausendstel Zoll, nicht im metrischen System. Daher ist die Verwendung von Zoll für diese SVG-Dateien tatsächlich sinnvoll – es geht nicht darum, dass „Nutzer das metrische System verwenden sollten".

2 „Gefällt mir“

Ich denke, deine Einstellungen sind nicht standardkonform. Was passiert, wenn du hier eine SVG hochlädst?

SVGs können ein Sicherheitsrisiko darstellen, daher ist es unüblich, sie in Beiträgen frei rendern zu lassen.

Danke!

So sieht dieses spezielle Beispielbild hier aus (das ist kein Schmutz auf deinem Bildschirm, es ist das gerenderte Bild):

e1ff136dadb082718c04bb5aaf0f1395de79ba93

Ich sehe hier genau dieselbe abgeleitete Größe von 12x8 Pixeln; hier ist das rohe Markdown genau so, wie es beim Hochladen dieser Datei ohne Änderungen angezeigt wird:

![e1ff136dadb082718c04bb5aaf0f1395de79ba93|12x8](upload://wffVySQ30j5UczxrY5nifKC0kEP.svg) 

Wenn man die abgeleitete Größe von 12x8 auf 480x320 ändert, wird das Bild sichtbar und ist mehr als nur ein Staubkorn:

![e1ff136dadb082718c04bb5aaf0f1395de79ba93|480x320](upload://wffVySQ30j5UczxrY5nifKC0kEP.svg) 

e1ff136dadb082718c04bb5aaf0f1395de79ba93

Was genau meinst du mit „Einstellungen"?

Offensichtlich war das Zulassen von SVG-Uploads erforderlich; ich erinnere mich, dass ich vor etwa zwei Jahren svg zur Konfiguration authorized_extensions hinzufügen musste.

Ich habe den SVG-Bereinigungscode in Discourse gesehen. Ich sehe, dass sie hier gerendert werden. Aufgrund des Wertes von SVGs für eine der Kernaufgaben von Maker Forums, kombiniert mit unserer Art, unsere Nutzergruppe zu verwalten, haben wir uns bewusst dafür entschieden, sie anzuzeigen. Wenn Leute Probleme beim Laserschneiden oder -gravieren von SVGs haben, ist die Möglichkeit, das SVG im Kontext der Konversation zu sehen, eine wertvolle Hilfe für das Verständnis und die Diagnose.

Da ich SVGs hier auf Meta ebenfalls anzeigen konnte, hast du vermutlich dieselbe Entscheidung getroffen, wenn auch offensichtlich aus einem anderen Grund.

2 „Gefällt mir“

Ausgezeichnet, danke für die zusätzlichen Details. Vielleicht könnte @jamie.wilson sich in der kommenden Woche einen Blick auf dieses Problem ansehen.

5 „Gefällt mir“

Danke!

Ich wollte nur sichergehen, dass bei der Untersuchung Scorches Punkt oben zutrifft: Dass die 12x8 Pixel wahrscheinlich nicht zufällig sind, sondern höchstwahrscheinlich darauf zurückzuführen sind, dass die Einheiten in den Attributen width und height des svg-Elements nicht berücksichtigt werden: <svg ... width="12in" height="8in" ...> — Das war mir beim ersten Posten der Frage noch nicht klar. :smiling_face:

4 „Gefällt mir“

Du hast absolut recht. Die Bibliothek, die wir verwenden, um die Bildgrößen zu ermitteln, übernimmt einfach den ganzzahligen Wert der width- und height-Attribute in den SVG-Dateien und versucht nicht, Einheitstypen zu analysieren. Ich werde mich umsehen und versuchen, die sauberste Lösung für dieses Problem zu finden.

Ich habe mit einigen der problematischen Dateien sowohl ImageMagick als auch librsvg ausprobiert. Es scheint, als ob ImageMagick standardmäßig eine DPI von 96 verwendet und librsvg standardmäßig 90. Ich denke, beides ist in Ordnung, solange wir eine sinnvolle Standardwahl treffen und uns daran halten…

5 „Gefällt mir“

Entweder 90 oder 96 würden SVGs mit Breiten- und Höhenangaben nicht nur in Zoll, sondern auch in Millimetern auf eine vernünftigere Größe bringen. Momentan werden SVGs mit Breiten- und Höhenangaben in Millimetern im Grunde mit 1 mm pro Browser-Pixel dargestellt, also in etwa im ⅓- bis ¼-Maßstab. Bisher habe ich nur mit den Schultern gezuckt und gesagt: „Na ja, skalierbar ist es ja wohl…

Unsere Sorge ist, dass SVG in E-Mails überhaupt nicht gerendert wird, sodass der Nutzen davon ziemlich begrenzt ist.

E-Mail-HTML ist eine derart eingeschränkte (nicht zu vergessen: inkonsistent implementierte; siehe Litmus) HTML-Variante, und ihr betont doch, dass Discourse für das moderne Web entwickelt wurde (z. B. unendliches Scrollen), dass ich mir nicht bewusst war, dass eine vollständige Darstellung aller im Web möglichen Inhalte in E-Mails ein treibender Faktor ist. Das ist ein neuer Aspekt, den ich verstehen muss. (Ich könnte mir vorstellen, dass man bei unbegrenzten Ressourcen SVG in PNG umwandeln könnte, um es in E-Mails einzubinden – das wäre von höherer Qualität als der Großteil des Unsinn, der für E-Mail-HTML allgemein erforderlich ist. Doch da SVG standardmäßig nicht aktiviert ist, wirkt das als Priorität weit zu niedrig…)

@Neotinker hatte vor einiger Zeit Überlegungen, Onebox mit Three.js zu nutzen, um interaktive 3D-Modelle in Discourse-Diskussionen über diese Modelle einzubetten; etwas, das wir für Maker-Foren aktivieren würden, falls dies jemals als Funktion existiert. Würde die Überlegung „kann das in E-Mails nicht gerendert werden

1 „Gefällt mir“

Ich habe am Freitagnachmittag einen Pull-Request erstellt, der das Problem beheben sollte, dass SVG-Dateien winzig klein erscheinen, wenn die Abmessungen in Zoll, cm, mm oder ähnlichen Einheiten angegeben sind.

Der Pull-Request wartet derzeit auf einen Code-Review und ist daher noch nicht verfügbar, sollte aber in Kürze einsatzbereit sein.

5 „Gefällt mir“

Danke, dass du den Commit geteilt hast, damit ich sehen konnte, wo und wie das umgesetzt wurde!

Entschuldige, ich habe @codinghorror missverstanden – ich dachte, er meinte, es sei zu einem sprichwörtlichen Albtraum geworden, und ich wollte hier nicht extra viel Arbeit verursachen.

2 „Gefällt mir“

Kein Problem! Wir sind zwar Fans von SVG, aber auch Realisten :wink:

Auf jeden Fall sind Vorschläge für kleine Verbesserungen immer willkommen!

4 „Gefällt mir“

Hier ist ein SVG eines Stifts mit den Abmessungen 8 Zoll x 12 Zoll.

Die Änderungen wurden übernommen und sollten nach einem Update für Sie verfügbar sein.

8 „Gefällt mir“

Vielen Dank! Ich habe dies jetzt auf den Maker-Foren bereitgestellt :tada:

5 „Gefällt mir“