Hacker News Reader

Comment by Pxtl | Hacker News Reader

When I first heard about svg, I was excited. Finally everybody getting behind a vector graphics format... and since then the more I see the worse it looks. A boosted, text-oriented, JavaScript-enhanced resource monster. All the worst attributes of HTML, but in vector graphics.

Did anybody want this? I know I wanted a jpg of vector graphics - a resource-friendly small system for embedding vector graphics into things. Something where I don't have to worry about an image having an xss vulnerability. Something that degrades gracefully so it can still work in some form on an anemic piece of equipment.

But no. We throw bigger and heavier hardware at more trivial problems.

View on HN

Did anybody want this?

Yes.

SVG is not a lightweight vector graphics format, which seems to be what you were hoping for. I agree that such a format would be useful as well.

However, for better or worse, web apps are a thing in 2016, and that means we need formats that lend themselves to programming and interaction. Having SVG do that for vector graphics is useful for much the same reasons as having HTML do that for text-based content and forms.

Agreed, a lightweight vector graphics format would certainly be welcome. However, the stuff SVG is capable of doing is not trivial but mostly just poorly understood.

I think the article below is a good read and I sometimes wonder if some of the (unconscious) negative perception around SVG is because of the slowness of its adoption:

http://blog.siliconpublishing.com/2015/12/the-fall-and-rise-...

Having said that, I personally find efforts to make SVG better understood (articles, books, tutorials etc) somewhat lacking, although that might just be a personal opinion.

Text-oriented... what did you expect? Binary formats are tough to standardize. We have raster images, video, audio files, and fonts, but very few of those formats are "web" formats. Most of them are designed around getting the most bang for your bit to the extreme--an MPEG-4 decoder is a real beast, to be sure, and it's hardly a good model for vector graphics. Vector graphics follow more of a human authorship pipeline (capturing a series of drawing commands) rather than machine capture pipeline (sampling data at a certain frequency). JSON, XML, JavaScript, HTML, even HTTP are built on text-oriented protocols and formats because text-oriented systems are easier to standardize and extend. MPEG-4, MP3, JPEG, Vorbis, are binary protocols because they only exist to represent and compress narrowly-defined multidimensional data.

Resource-friendly for small systems--how would we reduce memory consumption? The alternative model for vector graphics is what, PDF or PostScript? They're not exactly models of restraint. SVG looks positively austere compared to PDF or PostScript.

The closest thing I can think of to your ideal "minimal binary" vector graphics is something like TTF, which is basically its own little nightmare compared with SVG. TTF has its own vulnerabilities, its own proprietary scripting system compiled to bytecode, et cetera.

For me, SVG is doing a great job of enabling really cool things like D3, and at the same time hammering more nails into the coffin that is Flash--something far more a resource hog than SVG. And we don't really need more 90s-era formats, we've got plenty of those, thank you very much. SVG is to images what HTML is to documents. You can build simple, static ones easily enough, and you can also make a little bit of magic happen if you throw in some JavaScript.

It looks like in the future we'll be embracing more binary systems. TLS, HTTP/2, and WebAssembly are some examples. But it took a long time to get the institutional expertise to invent such systems, and if we had rushed to use binary instead of text in the early days, we would have probably gotten it wrong in a bad way.

Besides... the hardware is getting bigger and faster anyway... we might as well deliver some good experiences with it. Most of your battery is probably going to power the backlight and GPS radio anyway.

Flash--something far more a resource hog than SVG

If you had actually tried the first few versions of Macromedia Flash, on hardware of the time, you'd be surprised what could be accomplished. SVG is absolutely bloated in comparison.

I did, I taught classes on Macromedia Flash in the late 90s and early 2000s. That version of Flash simply isn't relevant to the modern web. You might as well be comparing RealPlayer with modern YouTube.

That said, I'm not sure what you would want to remove from "bloated" SVG.

It's like the W3C is reinventing Macromedia Flash, which was the choice for compact, interactive vector graphics around 10 years ago. I don't like what Adobe did to it after they bought Macromedia, but a subset of SWF would've fit the "resource-friendly small system for embedding vector graphics into things" use case very well. I wrote a substantial part of a SWF renderer --- in x86 Asm --- and it wasn't that difficult, because the format is actually quite simple to parse. An XML parser alone would've been larger than that, nevermind the SVG-specific processing on top of it.

On Windows, including historic, mobile and embedded versions, there are well-supported vector formats suitable for embedding images.

If your software paints stuff using GDI or GDI+, you can use windows metafile images, EMF/EMF+/EMZ.

If your software paints stuff using Silverlight or WPF or WinRT, the XAML format has descent support for vector graphics. On WinRT, it’s even compiled to binary form, BAML, to save resources in runtime.

Are vector graphics a trivial problem? I can't say that they are.

SVG is an untapped technology. It functions as an embedded document. When used within the Object tag, it can run javascript and CSS and ideally renders complex graphics with a much smaller payload. Also, they look amazing on all devices as they use the browser's rendering pipeline. SVG has been a fully supported standard for years.

https://sarasoueidan.com/blog/art-directing-svg-object/

You need paths built out of bezier segments and ways to fill them (Mono color and gradients). Maybe add some filters for effects like shadows, but that's it. Fairly trivial to implement.

Things like strokes and text that are hard to implement can just be converted into filled paths.

Reply on news.ycombinator.com