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

31–40 of 228 posts

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

#31

Post by goto11 »

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…

> The fact that SGML-based formats managed to become as popular as they are is really proof that there's something fundamentally rotten in software engineering.

HTML is a pretty good syntax though. SGML-like syntax is just less appropriate for formats which are not text-centered, since the element/attribute distinction becomes superfluous noise in the syntax.

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

#32

Post by Someone »

hinkley wrote: post #19
jerf wrote: post #4

Even JSON is going to be "bloated". This cries out for a well-done, well-thought out binary format. While binary formats have certain disadvantages that never go away, a lot of the worst ones that we associate with them are the result of older standards that failed to contain enough extensibility. But there's a lot of good prior art to look at now. Heck, nowadays you could probably just define something as Protobuf (…

There are tools for shrinking SVG that do some of what you say. One advantage of the text format is that you can reduce precision of the path data to a couple of significant figures. That would be hard to do with a binary format. You'd have to decide up front on 8 bytes or 16 bytes per coordinate pair.

Binary formats need not use fixed-length fields. You could use a format that stores small integers in 8 bits, yet allows for larger ones. See for example https://developers.google.com/protocol-buffers/docs/encoding....

You don’t even have to use byte-sized fields, but doing that makes encoding and decoding harder, and the overhead of also storing the actual lengths in bits of variable sized fields may be too much to make it worth that.

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

#33

Post by runarberg »

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…

Using D3 to draw plots and other data visualizations is really golden. Next to other good plotting libraries (such as ggplot2) having SVG as my canvas really gives me the feeling that I can do everything that I want.

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

#34

Post by mchusma »

Jestar342 wrote: post #30
nness wrote: post #28

Earlier quoted context omitted.

Magnifying the SVG as part of the workflow, svgo for instance, is a life-saver for all these edge-cases.

Noted, thanks.

I use this for most SVGs: https://jakearchibald.github.io/svgomg/

"SVGO's Missing GUI". Give it to the designers and they can make sure to give you the smallest possible file that makes sense. I find that some files look great at "0" precision, some require "1" or "2".

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

#36

Post by ChrisMarshallNY »

exabrial wrote: post #11

> Maybe JSON-based, definitely not XML-based No. Strong schemas are _why_ it's supported across a multitude of platforms. JSON because "it's got JSON, what plants crave" is an absolutely dumb argument. And the see article "parsing JSON is a minefield". I can't think of a way to make the standard worse than re-implementing in JSON. There are some legit missing features from SVG as other commenters have pointed out. To…

I have worked with XML since it was a wee laddie. I generally prefer using JSON, but all my SDKs emit BOTH XML and JSON (and, occasionally, CSV).

XML Schema is the main reason I use XML. I hate Schema. Hates HAAATESSSS NASSSTY SSSSCHEMA..., but it is ironclad. If it is described in Schema, then it is guaranteed (or not; in which case Schema also accounts for that).

JSON Schema is a non-starter. No one ever seems to use it, and I don't think it ever made it out of committee. It pretty much goes against why JSON is popular.

If anyone wants REAL pain, then we should go back to BNF: https://en.wikipedia.org/wiki/Backus–Naur_form

I worked with a BNF compiler, and I still wake up screaming.

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

#37

Post by flowerlad »

If you're looking for a machine-readable vector graphics format that has an SVG-like imaging model, there is such a format already: AI4

AI4 stands for Adobe Illustrator 4.0. Gnuplot and Mathematica can produce AI4 files. Most vector graphics programs can open AI4 files too.

Here's the documentation: http://www.idea2ic.com/File_Formats/Adobe%20Illustrator%20Fi...

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

#38

Post by gibolt »

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

Post reply on HN