Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SVG: The Good, the Bad and the Ugly

eisfunke.com

Post reply on HN
Print view View original

171–180 of 228 posts

Re: SVG: The Good, the Bad and the Ugly

#171

Post by nigeltao »

wrnr wrote: post #112

There is already ivg https://github.com/reactivego/ivg

Yeah, that's a renderer for the IconVG file format. As I've said previously:

IconVG is a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji.

IconVG is similar in concept to SVG (Scalable Vector Graphics) but much simpler. Compared to "SVG Tiny", it does not have features for text, multimedia, interactivity, linking, scripting, animation, XSLT, DOM, combination with raster graphics such as JPEG formatted textures, etc.

The announcement is at https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p... and quoting from that:

"The SVG spec prints as 400 pages, not including the XML, CSS or XSLT specifications. [The IconVG godoc.org page, which includes the file format specification, prints as 26 pages]...

The Material Design icon set... consists of 961 vector icons. As SVG files, this totals 312,887 bytes. As 24 * 24 pixel PNGs, 190,840 bytes. As 48 * 48 pixel PNGs, 318,219 bytes. As IconVGs, 122,012 bytes."

Re: SVG: The Good, the Bad and the Ugly

#172

Post by FpUser »

I see nothing wrong with the XML. At least in its basic form. I use it extensively (often manual editing with the help of notepad++ / notepadqq) with no problem. I am not a dedicated web developer either.

Re: SVG: The Good, the Bad and the Ugly

#173

Post by rapidlua »

marcodiego wrote: post #2

Article mentions svg supports tag... Coolest use of it: https://www.xul.fr/svgtetris.svg

FlameGraph [1] renders profiling results into svg. Profile is essentially hierarchical; a user can zoom into subtree by clicking an element. Probably not an inspiring use of script in svg; but boy, how handy this feature is!

https://gist.githack.com/mejedi/90eac4f11f794f43808f90e38b1a...

[1] http://www.brendangregg.com/flamegraphs.html

Re: SVG: The Good, the Bad and the Ugly

#174

Post by c-smile »

> A good idea would be to develop a simple vector graphics exchange format that is desigend to be easily processed by machines. As minimal in features as possible. Maybe JSON-based, definitely not XML-based.

Just for the note, there is such format already and it is quite popular actually, see: https://lottiefiles.com/

Lottie files are JSONs produced by Bodymovin plugin for Adobe After Effects.

These are primarily for short vector animations but lotties work OK for static images too.

Re: SVG: The Good, the Bad and the Ugly

#175

Post by RobertKerans »

samatman wrote: post #165
paul_manias wrote: post #116

Earlier quoted context omitted.

> Oh. You can almost hear the designer saying "well fuck it, we'll just jam it all into a string. I'll throw in my 2 cents here because the responses aren't addressing why the path descriptors are stylised in this way. Whether SVG's underlying document format was XML, JSON, SGML, CSS or whatever is irrelevant. However else you did it, any alternative would be more verbose because the 'd' tag already offers the most c…

I'll reference you to a comment elsewhere in the tree, and its parents[0], which came up with this s-expression: (path (M 10 10 H 90 V 90 H 10 L 10 10) :color red) It's legitimately hard to beat sexprs for the combination of compactness, generality, and ease of use. If I were to start from first principles in making a vector graphics format, I'd probably make it a schema over EDN. I bet the extra complexity of having…

I've used SVG pretty heavily for years, in particular for the last couple of months as I've been writing libraries/tools that render SVG output (parsing for the cli tool side, lots of hand-writing & testing, cleaning, rendering).

Yes an s-expression is imo normally the best representation (more specifically, an x-expression (see Racket) would be ideal). However, practically, it's not actually that useful. It is very useful as an intermediary step.

For example for a tool where the SVG is parsed to an x-expression and cleaned then compiled back. This is one of the [aborted] things I was working on, as the three best existing tools [in JS, Python and Rust] for this all have issues of one kind or another. Or you have a tool that allows you to write x-expressions then compile. But always with this, if that's the case, can't really directly jnterop with the host language/platform -- as you say, would have to be from first principles. And further to that, it would need HTML from first principles because one of the huge, huge benefits is that SVG drops directly into HTML with virtually the same semantics, same styling, same JS interactivity hooks. And the issue is compounded by SVG not just being XML, that it is also a DSL (NB solution is normally to restrict to a subset of features), so the clean structure breaks down pretty often. Imo SVG has to be the way it is, that the tradeoffs of the bastardised XML it uses have to have been made for it to be actually useful. Those tradeoffs also make it difficult to use, and often very difficult to parse easily. But without changing how HTML works, how web browser rendering works, I don't see how there are any alternatives that are substantially better.

Re: SVG: The Good, the Bad and the Ugly

#176

Post by c-smile »

simias wrote: post #15

>Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It’s tiring to write by hand and just as tiring to parse or generate automatically. What's even worse is that because XML is a garbage fire of a format, SVG actually builds its own micro-DSL to work around limitations. So for instance you have something like: Ok, fair enough. Readable, self-describing. But then you have: Oh. You can almost hear…

For the note, Sciter (https://sciter.com) and Sciter.JS support inline vector images in its CSS.

Instead of SVG and things like FontAwesome in 99% UI cases we use just these

    button {
      background-image: url(path:M 10 10 H 90 V 90 H 10 L 10 10);
      fill: red;
    }
or

Re: SVG: The Good, the Bad and the Ugly

#177

Post by JNRowe »

gibolt wrote: post #38
simias wrote: post #15

>Furthermore the XML-based syntax is pretty ugly and needlessly verbose. It’s tiring to write by hand and just as tiring to parse or generate automatically. What's even worse is that because XML is a garbage fire of a format, SVG actually builds its own micro-DSL to work around limitations. So for instance you have something like: Ok, fair enough. Readable, self-describing. But then you have: Oh. You can almost hear…

You don't edit raw png values either, with rgb/index values in a list. SVGs are meant to be created and used like any image file. The fact that they are almost human-editable and can be inlined means we are bound to be disappointed when working with them in this manner

> You don't edit raw png values either

However, for when you want that there is SNG¹. It can be a surprisingly fun way to perform minor corrections or filters to an image.

¹ http://sng.sourceforge.net/

Re: SVG: The Good, the Bad and the Ugly

#178

Post by follower »

simias wrote: post #102
gibolt wrote: post #38

Earlier quoted context omitted.

You don't edit raw png values either, with rgb/index values in a list. SVGs are meant to be created and used like any image file. The fact that they are almost human-editable and can be inlined means we are bound to be disappointed when working with them in this manner

I disagree, I routinely manually mess with SVG (even SVG generated with a program like inkscape) because it lets me add interactivity and animations. That's the killer feature for me: you can draw arbitrary vector shapes in a website, then hook into them using javascript the way you would any DOM element. There are a few subtleties to make it work well, but it's pretty straightforward. Here's an example: https://svkt…

Along those lines, I recently encountered this project that enables the use of SVG to design maps etc for games developed with the Rust language game engine Bevy: https://github.com/carrascomj/bevy_svg_map

"The properties of the lines (color, opacity, fill...) can be used to programmatically add functionality..."

Post reply on HN