My question is, why is it so hard for image hosting service to support native SVG, instead of converting an image to other format. Would like to hear the limitations and challenges that comes with it.
http://imgur.userecho.com/topic/23630-svg-support/
The worst problem may be SVG itself - SVG 1.2 which dates from 2004 was abandoned, and most browsers implement SVG 1.1 which is rather lacking in features. This makes it hard if you're a designer to produce SVG documents which a browser can actually render.
At a bare minimum any SVG hosting project would have to involve some sort of SVG lint, to make sure that browser-incompatible SVG elements are not present, implement workarounds for browser-specific bugs, and check that there are no <script> tags etc. The sheer size and complexity of even SVG 1.1 makes it non-trivial. One pragmatic approach to sanitize SVG may be to round-trip SVG -> PDF -> SVG via cairosvg and pdftocairo, though it may burn some CPU.
Wikipedia does it using librsvg, fwiw: https://live.gnome.org/LibRsvg
I keep hoping that epub will generate a renaissance of interest in SVG. So far no luck.
You don't need to sanitize SVGs to host them safely - you just put them inside <img> tag and browsers will do sandboxing for you.
What features do you actually miss in SVG 1.1? Gradient meshes? 3d transforms? multiple fills? I can think of only advanced stuff that is rarely used and tricky to do with other web technologies anyway.
Also, why would you want to strip browser-incompatible SVG elements? Browsers will simply ignore such elements.
SVG rendered via an <img> tag has restrictions in browsers, for example Firefox will not allow the SVG to reference an external image file such as a jpg. Once again, you put the raw SVG file in the browser and it does not render...
Obviously I miss any SVG 1.2 feature which Inkscape lets me easily use. Compositing for example. User has "SVG" output from Inkscape, user puts it on an "SVG" hosting service, it does not render in the browser = unhappy user. Users don't care less about what version of SVG they are using.
Stripping browser-incompatible elements could be useful, for example, if I place my content inside an SVG 1.2 <page> then the browser will render nothing at all, where as if the server stripped out the <page> element first, I'd be able to see my content. Obviously this applies only to a single page tag. Once again, you put the raw SVG file in the browser and it does not render...
Bug-workarounds are the primary reason for wanting to manipulate the elements though, there is a Safari bug which can cause it to ignore <defs> but work if you switch out <defs> for <g>. Once again, you put the raw SVG file in the browser and it does not render...
Of course, why would anyone bother? It's that hard to find hosters that will host anything, so why do through the hassle to encruft your data with some somewhat unwieldy wrapper?
The fact that it's XML is in some way a "protection" here since for no particularly good reason some character codes cannot be represented by xml (not even encoded), meaning you'll need ugly workarounds to store arbitrary data.
If you really wanted to, you could pretty much make your own webpage run on the image hosting server.
Also, you could send a malicious script to someone hidden in a cute cat drawing, and it would look like it was the host's fault.
The render bomb point is a little trickier, as you can use some detailed filters to crash most browsers. Heck, even a single simple shape will crash any version of iOS.
You can upload svg files with the right content type to Amazon S3 without trouble, is that not good enough?
If you just want to shop them you could convert them to bitmap or host them on GitHub
If you want to include them on your website, they're small and compress well with gzip so why have the complexity of relying on a third party services
It you have too much traffic to be able to host them yourself then you should look at something like a CDN e.g. Cloudfront, infront of S3
Isn't SVG just XML? I'd assume you could host it that way.
