We allow SVG uploads at Maker Forums, in part because one of our user bases is users of laser engravers and cutters, and SVGs are commonly used there. We want people to be able to upload them; both for others to download them, and to see them in the course of discussion. This is often in the context of a request for help.
Unfortunately, they tend to be rendered extremely small, sometimes practically invisibly small. Tonight, someone uploaded an SVG and it was automatically set to 12x8 pixels, which was so small that the colored lines disappeared and it was rendered much like a picture of a polar bear in a snowstorm. (I’m amazed that the category moderator noticed that there was an SVG there at all.) This has been a common problem for us.
The experienced users could perhaps learn that they can, for example, change 12x8 to 480x320 to actually be able to see the image, but the experienced users mostly don’t need to do this; most of the people posting SVGs are newcomers seeking help, and they don’t know about this Discourse quirk.
What causes Discourse to choose to limit SVGs to only a few pixels?
Here’s the query I got from the category moderator, for reference:
Edit: From that thread, a possible reason that this might affect this particular forum more than others:
Common “K40” laser cutters have a 12"x8" bed and run in exactly thousandth-of-an-inch steps, rather than in metric, so using inches is actually specifically reasonable for those SVG files, it’s not a “users should use metric” thing.
Obviously this required allowing SVG uploads; my recollection was that I had to add svg to the authorized_extensions configuration two years ago or so.
I did see the SVG sanitization code in Discourse. I see that they are rendering here. Because of the value of SVGs for one of the key missions of Maker Forums, combined with how we manage our user base, we have chosen to display them on purpose. When people are having trouble laser-cutting/engraving SVGs, being able to see the SVG in the context of the conversation is a valuable aid to understanding and diagnosis.
Since I was able to display SVGs here on meta as well, presumably you have made the same decision, though obviously for a different reason.
Just making sure that in the investigation, Scorch’s point above that the 12x8 pixels is probably not random but most likely due to not handling the units in the width and height attributes of the svg element: <svg ... width="12in" height="8in" ...> — I hadn’t realized that when I first posted the question.
You’re exactly right. The library we’re using to grab the image sizes just takes the integer value of the width and height attributes in the SVG files, and doesn’t attempt to parse any unit types. I’ll poke around and try to work out the cleanest solution for this issue.
I’ve been experimenting with a couple of the problematic files using both ImageMagick and librsvg. It seems as though ImageMagick defaults to a DPI of 96, and librsvg defaults to 90. I guess either is fine as long as we pick a sensible default and stick to it…
Either 90 or 96 would make SVGs with width and height not only in inches, but also in mm also a more reasonable size. Right now SVGs with width and height in mm are basically showing at 1mm per browser pixel, thus showing at something like ⅓-¼ scale. Before I just shrugged and said, “Well, scalable I guess…” but if you can add both inches and mm at a reasonable default resolution that would make both render a lot better.
Email HTML is such a restricted (not to mention inconsistently implemented; see Litmus) set of HTML, and y’all make the point that Discourse is created for the modern web (e.g. infinite scrolling), that I had no awareness that full representation in email of everything that could be represented on the web was a driving consideration. This is a new wrinkle for me to understand. (I could imagine that given infinite resources one might render SVG to PNG to include in email, which would be higher fidelity than a lot of the nonsense required for HTML email generally, but with SVG not enabled by default that feels way low as a priority…)
@Neotinker had thoughts of at some time of getting onebox using threejs to embed interactive 3D models in Discourse conversations about those models; something we would want to turn on for Maker Forums should it ever exist as a feature. Would the “can’t render that in email” consideration get in the way of accepting such work if he or someone else were to implement it? (I note that threejs use Discourse for their own forum…)
Or if this is more a priority call for how much time CDCK wants to put into the problem, I’d be happy for a pointer to the code; I don’t mean to imply a burden here. Y’all have seen in my previous contributions that I’m not a Ruby or RoR expert, but I’d be willing to put it on my queue of things to look at. (I posted this topic originally before we realized that it was dropping units and assuming pixels, so thought it was a design decision, which was why I put it in ux instead of bug)
I created a pull request on Friday afternoon which should address the issue of SVG files being teeny-tiny if the dimensions are expressed in terms of inches, cm, mm or similar.
The pull request is awaiting code review so isn’t available just yet, but it should be good to go shortly.
Thanks for sharing the commit so that I could see where and how it was done!
Sorry I misinterpreted @codinghorror — I thought that he meant it had turned into a proverbial can of worms, and I hadn’t meant to make lots of work here.
)
