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 so eingeschränkte (ganz zu schweigen von inkonsistent implementierten; siehe Litmus) Teilmenge von HTML, und ihr weist darauf hin, dass Discourse für das moderne Web entwickelt wurde (z. B. endloses Scrollen), daher war mir nicht bewusst, dass eine vollständige Darstellung aller im Web darstellbaren Elemente in E-Mails ein entscheidender Gesichtspunkt ist. Das ist eine neue Nuance, die ich verstehen muss. (Ich könnte mir vorstellen, dass man bei unbegrenzten Ressourcen SVG in PNG konvertieren könnte, um es in E-Mails einzubinden, was eine höhere Wiedergabetreue hätte als der ganze Unsinn, der für HTML-E-Mails im Allgemeinen erforderlich ist, aber da SVG nicht standardmäßig aktiviert ist, wirkt das sehr niedrig priorisiert…)

@Neotinker hatte die Idee, irgendwann Onebox mit Three.js zu verwenden, um interaktive 3D-Modelle in Discourse-Konversationen über diese Modelle einzubetten; etwas, das wir in Maker-Foren aktivieren möchten, falls es jemals als Feature existieren sollte. Würde die Überlegung „Das kann man nicht in E-Mails rendern“ die Annahme solcher Arbeiten behindern, wenn er oder jemand anderes sie implementiert? (Ich merke an, dass Three.js Discourse für ihr eigenes Forum nutzt…)

Oder wenn dies eher eine Prioritätsfrage ist, wie viel Zeit CDCK in das Problem stecken möchte, würde ich mich über einen Hinweis auf den Code freuen; ich will damit nicht implizieren, dass ich eine Last darstelle. Ihr habt in meinen vorherigen Beiträgen gesehen, dass ich kein Ruby- oder RoR-Experte bin, aber ich wäre bereit, es auf meine Liste der zu prüfenden Punkte zu setzen. (Ich hatte dieses Thema ursprünglich gepostet, bevor wir merkten, dass Einheiten abgeschnitten wurden und Pixel angenommen wurden, daher dachte ich, es handele sich um eine Designentscheidung, weshalb ich es in Contribute > UX statt in Contribute > Bug gepostet habe :smiling_face:)

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“