Consentiamo il caricamento di file SVG nei Maker Forums, in parte perché uno dei nostri gruppi di utenti è costituito da utenti di incisor e taglieri laser, dove gli SVG sono comunemente utilizzati. Vogliamo che gli utenti possano caricarli, sia per permettere ad altri di scaricarli, sia per visualizzarli durante le discussioni. Spesso ciò avviene nel contesto di una richiesta di aiuto.
Purtroppo, tendono a essere resi estremamente piccoli, a volte praticamente invisibili. Stasera, qualcuno ha caricato un SVG che è stato automaticamente impostato a 12x8 pixel, così piccolo che le linee colorate sono scomparse e l’immagine è apparsa come una foto di un orso polare in una tempesta di neve. (Sono sorpreso che il moderatore della categoria abbia notato che c’era un SVG.) Questo è stato un problema ricorrente per noi.
Gli utenti esperti potrebbero forse imparare che possono, ad esempio, cambiare 12x8 in 480x320 per poter effettivamente vedere l’immagine, ma gli utenti esperti di solito non hanno bisogno di farlo; la maggior parte delle persone che pubblicano SVG sono nuovi arrivati che cercano aiuto e non conoscono questa stranezza di Discourse.
Cosa causa in Discourse la scelta di limitare gli SVG a pochi pixel?
Ecco la query ricevuta dal moderatore della categoria, per riferimento:
Modifica: Da quel thread, una possibile ragione per cui questo potrebbe colpire più questo forum rispetto ad altri:
Le comuni taglieri laser “K40” hanno un piano di lavoro di 12"x8" e operano esattamente in passi di millesimo di pollice, piuttosto che in metrico, quindi l’uso delle pollici è effettivamente ragionevole per quei file SVG; non si tratta di un problema di “gli utenti dovrebbero usare il sistema metrico”.
Ecco come appare quel particolare grafico qui (non è un po’ di polvere sullo schermo, è il grafico renderizzato):
Vedo esattamente la stessa dimensione di 12x8 pixel inferita qui; ecco il markdown grezzo esattamente come mostrato dopo il caricamento di questo file, senza alcuna modifica:
Ovviamente questo ha richiesto di consentire il caricamento di SVG; il mio ricordo è che ho dovuto aggiungere svg alla configurazione authorized_extensions circa due anni fa.
Ho visto il codice di sanificazione degli SVG in Discourse. Vedo che vengono renderizzati qui. A causa del valore degli SVG per una delle missioni chiave di Maker Forums, combinato con il modo in cui gestiamo la nostra base utenti, abbiamo scelto di visualizzarli intenzionalmente. Quando le persone hanno problemi a tagliare/incidere al laser gli SVG, poter vedere l’SVG nel contesto della conversazione è un valido aiuto per la comprensione e la diagnosi.
Poiché sono riuscito a visualizzare gli SVG anche qui su meta, presumo che tu abbia preso la stessa decisione, sebbene ovviamente per un motivo diverso.
Sto solo assicurandomi che, nell’indagine, il punto sollevato da Scorch sopra, secondo cui i 12x8 pixel probabilmente non sono casuali ma molto probabilmente dovuti alla mancata gestione delle unità negli attributi width e height dell’elemento svg: <svg ... width="12in" height="8in" ...> — non me ne ero reso conto quando ho pubblicato per la prima volta la domanda.
Hai perfettamente ragione. La libreria che stiamo utilizzando per ottenere le dimensioni delle immagini si limita a prendere il valore intero degli attributi width e height nei file SVG, senza tentare di analizzare i tipi di unità. Farò qualche ricerca e cercherò di trovare la soluzione più pulita per questo problema.
Sto sperimentando con alcuni dei file problematici utilizzando sia ImageMagick che librsvg. Sembra che ImageMagick utilizzi di default una DPI di 96, mentre librsvg utilizza di default 90. Immagino che vada bene l’uno o l’altro, purché scegliamo un valore predefinito ragionevole e ci atteniamo ad esso…
Sia 90 che 96 renderebbero le SVG con larghezza e altezza espresse non solo in pollici, ma anche in millimetri, di dimensioni più ragionevoli. Al momento, le SVG con larghezza e altezza in millimetri vengono visualizzate essenzialmente a 1 mm per pixel del browser, risultando quindi ridotte a circa 1/3 o 1/4 della scala reale. Prima mi limitavo a dire: “Beh, sono scalabili, suppongo…”, ma se fosse possibile aggiungere sia pollici che millimetri con una risoluzione predefinita ragionevole, entrambi verrebbero resi molto meglio.
L’HTML delle email è un insieme di HTML così limitato (per non parlare dell’implementazione incoerente; vedi Litmus), e voi sottolineate che Discourse è stato creato per il web moderno (ad esempio lo scroll infinito), che non avevo idea che la rappresentazione completa in email di tutto ciò che può essere rappresentato sul web fosse una considerazione guida. Questa è una nuova sfumatura che devo comprendere. (Potrei immaginare che, date risorse infinite, si potrebbe convertire un SVG in PNG per includerlo nelle email, ottenendo una fedeltà superiore rispetto a gran parte delle assurdità richieste per l’HTML delle email in generale, ma con gli SVG non abilitati di default, sembra una priorità molto bassa…)
@Neotinker aveva pensato, in un secondo momento, di utilizzare onebox con threejs per incorporare modelli 3D interattivi nelle conversazioni di Discourse relative a quei modelli; qualcosa che vorremmo attivare per i Maker Forums, qualora diventasse una funzionalità. La considerazione “non può essere visualizzata nelle email” ostacolerebbe l’accettazione di tale lavoro se lui o qualcun altro lo implementasse? (Noto che threejs utilizza Discourse per il proprio forum…)
Oppure, se si tratta più di una scelta prioritaria su quanto tempo CDCK voglia dedicare al problema, sarei felice di ricevere un riferimento al codice; non intendo imporre un onere. Avete visto nei miei contributi precedenti che non sono un esperto di Ruby o RoR, ma sarei disposto a inserirlo nella mia coda di cose da esaminare. (Ho pubblicato questo argomento inizialmente prima di renderci conto che stava eliminando le unità e assumendo i pixel, quindi pensavo fosse una decisione di design, motivo per cui l’ho inserito in ux invece che in bug)
Venerdì pomeriggio ho creato una pull request che dovrebbe risolvere il problema dei file SVG che appaiono minuscoli quando le dimensioni sono espresse in pollici, cm, mm o simili.
La pull request è in attesa di revisione del codice, quindi non è ancora disponibile, ma dovrebbe essere pronta a breve.
Grazie per aver condiviso il commit, così ho potuto vedere dove e come è stato fatto!
Scusa se ho frainteso @codinghorror — pensavo che volesse dire che si era trasformato in un proverbiale barattolo di vermi, e non intendevo creare molto lavoro qui.
