Hacker News Reader

Comment by starmole | Hacker News Reader

This showcases what's wrong with SVG: It does way too much!

To be useful as a vector image format, there should be strict rules (and less cruft). Why is there no libsvg like libjpeg or libpng? Why have interaction as part of an image format?

SVG lives in an uncanny valley between jpeg and flash/js.

I think there is still a big need for a real vector interchange and display format. Right now people pick a "good" subset of SVG. Or even fallback to fonts.

My dream vector format:

- Pixel perfect across implementations at 50%,100%,200% renderings. At least grid aligned lines.

- Lossless roundtrip across apps. Start in Illustrator, edit parts in Inkscape, other parts in Animate, untouched things stay exactly the same.

- Standard zero dependency C reference implementation: Stream in, bitmap out.

View on HN

This! I've started to look for usable vector image format for game development somewhere in 2004, now it's 2017 and there is still nothing available. For SVG you literally need to pull-in whole browser engine, which is most likely 2-3 times the size of your whole game.

One possible solution is to the same what XMPP did on XML, or JSON did on JavaScript: Define a "safe subset" of SVG, and stick to that. Perhaps use the "safe subset of XML" as a base (as defined e.g. in XMPP.)

Use a library (or at least a validator) that works exactly on this subset, and fails for anything not strictly conforming to this.

Of course, this is not as satisfying as a "clean slate" approach, but on the other hand, this is a clear migration path with backwards compatibility - which is always good to have during a transition period to avoid all those bootstrapping and chicken-egg issues.

I've found librsvg to be pretty good. It's used for exactly this purpose in Gnome. You stick a Cairo surface behind it and it translates the operations to that.

https://github.com/GNOME/librsvg

However, admittedly, I use it in combination with a full blown browser because it doesn't need/handle text completely. I like SVG, but I too have accepted that if I want stuff to render properly, the only place to find a usable and complete SVG engine is in a web browser.

Maybe something like this: https://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format

> Why is there no libsvg like libjpeg or libpng?

nanosvg is pretty good:

https://github.com/memononen/nanosvg

Here is a Go library for SVG generation:

https://github.com/ajstarks/svgo https://speakerdeck.com/ajstarks/svgo-code-plus-picture-exam...

> It does way too much!

And even so, it still has no hairline. All line widths are finite and change when zooming.

Only in IE/Edge. On other browsers you can prevent scaling of line-widths

It does, well, if following SVG 1.2 Tiny it does, at least. As far as I know it's implemented in Opera, FF, Chrome and Safari. Not sure about IE.

It's implemented as vector-effect: vector-effect="non-scaling-stroke"

There's an example here https://gist.github.com/lightjs/5372867

> All line widths are finite and change when zooming. That's good imho.

There is https://www.w3.org/TR/SVGTiny12/ which is a subset of SVG without scripting, without CSS styling. Not sure why it never gained more traction.

Because SVG Tiny 1.2 still has support for scripting and CSS styling.

https://www.w3.org/TR/SVGTiny12/styling.html https://www.w3.org/TR/SVGTiny12/script.html

I trusted Wikipedia (which says otherwise) without checking the references. Argh!

It explicitly doesn't require that the engine do anything with the content of <script> tags, and CSS is explicitly unsupported - they simply use a small subset of properties from CSS as attributes.

It still includes interactivity & scripting (https://www.w3.org/TR/SVGTiny12/script.html)! Even audio etc.! So that's probably why it didn't get traction.

But how to deal with things like line-wrapping, when fonts have unknown size? Somehow, it should be possible to programmatically determine how each line is broken up. A similar argument holds for hinting at low pixel sizes.

This means it is inevitable that SVG should be Turing-complete.

Image should be self-contained. Proper vector format should convert text into a set of vector primitives.

The files could get quite huge after that. Also one feature of svg (whether it is an advantage is for everyone to decide) is that it can render fonts as they are rendered in the other parts of OS. Which is why it can be seamlessly embedded.

also it does things weirdly and surprisingly - like right in the first codepen sample when she put width and height to be 100% of the viewport but the svg engine decided not to stretch it... ugh.

and that ignoring browser specific issues, for example svg and css filtering don't work on edge/ie11

but nice hacks I guess. the real takeaway are probably svg animations, those can make cool stuff without the keyframe weirdness.

It isn't perfect and it works inside of OpenFL but Haxe has a svg render in OpenFL that makes it much smaller in size to import and is more stream lined.

https://github.com/openfl/svg

> Why have interaction as part of an image format?

What about as part of a text format? Would anyone find that useful?

There is also librsvg. It is heavily used with linux desktops.

Reply on news.ycombinator.com