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

131–140 of 228 posts

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

#131

Post by hinkley »

pwdisswordfish6 wrote: post #93
hinkley wrote: post #84

Earlier quoted context omitted.

> "well fuck it, we'll just jam it all into a string. This is an almost universal disease of people trying to write XML grammars (or database schemas before that). Everyone thinks they can unambiguously decode multiple pieces of data stuffed into the same fixed-width field, and pretty much all of those people are wrong. Over, and over again. That they never learn is a testament to the developer's ability to make fixi…

So one reason for XML failing is that people who nominally used XML didn’t fully use its capabilities to capture data structure and kept their habits from the days of representing all data by fixed-width records?

XML and Java both come out of the same era. Java was supposed to be Object Oriented, but what we got instead is stringly typed code.

Array literals in programming languages are pretty much as compact as you can get (start, end, one character element separator), and the type system or a little code often allows you to fix a 1:1 mistake after the fact. This attribute is now a number or an array of numbers.

In XML if you want a properly formatted list you have to use child elements, which gets expensive really quickly so people balk. Especially if you already failed the attribute/child test by mistaking the value for 1:1 when it turned out to be 1:many.

We also already have HTML class, style, and on* attributes as prior art that we use to convince ourselves that one more will be okay. Basically XML gets it from both ends. XML makes entity relationships and irreversible decision, in an era where UML existed and harped constantly on it.

I don't know if there was any fixing it at that point. What I do know is that a lot of us shot meaningful glances at each other and tried as hard as we could to find something else to do until the dust settled. But you really could not avoid XML in the 00's.

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

#132

Post by jerf »

hinkley wrote: post #78
jerf wrote: post #25

Earlier quoted context omitted.

There's existing variable-length binary number formats [1] that already exist. SVG already has so many variable-length things in it that the downsides would probably be insignificant. I don't know if any of the existing Protobuf-like things have these built in, though. I know some of them have variable integers in them but I don't know about variable floats. This is kind of what I was getting at in that we have a lot…

I don't see how var_float lets you detect the length of a number field from the input. It seems to be designed to take arbitrary input from another function (which has already decided how big the data is out-of-band). Am I missing something, or can I not read 2 bytes from a file and detect if that's the end of the number or I need to read the next 2 bytes?

I dunno if that specific library has that feature, but it is certainly something that can be implemented. It's just a matter of programming.

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

#133

Post by lifthrasiir »

goto11 wrote: post #70
colllectorof wrote: post #44

Earlier quoted context omitted.

Can't wait for the improved JSON version: {"path": {"d": ["M", 10, 10, "H", 90, "V", 90, "H", 10, "L", 10, 10]}}

Since this is HN I will point out that s-expressions are vastly superior: (path (d (M 10 10) (H 90) (V 90) (H 10) (L 10 10)))

Even superior:

    path 10 10 M 90 H 90 V 10 H 10 10 L #000 stroke

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

#134

Post by dan-robertson »

kazinator wrote: post #74
goto11 wrote: post #70

Earlier quoted context omitted.

Since this is HN I will point out that s-expressions are vastly superior: (path (d (M 10 10) (H 90) (V 90) (H 10) (L 10 10)))

You probably mean (path d M 10 10 H 90 V 90 H 10 L 10 10) Shore up some nesting for the commands with pattern matching, returning a path struct: This is the TXR Lisp interactive listener of TXR 251. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. Garbage collection is on Tuesdays: bring unwanted pointers to curb by 7:30. 1> (defstruct path () name args) # 2> (defun parse-path-args (args) (match-c…

I think that’s too flat. There’s no easy place to put the width and suchlike. I think you’d want something like:

  (path (M 10 10 H 90 V 90 H 10 L 10 10) :color red)
Though probably I would prefer something more nested if possible, so you have a list of instructions rather than needing to parse them out of a flattened list. And I would likely use an alist rather than a plist for attributes like colour or stroke width.

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

#135

Post by jansan »

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…

I do not see what is wrong with the path string, which btw. is the same in HTML Canvas. I am using SVG on a daily basis and encountered many issues that annoyed me, but path data was never one of them.

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

#136

Post by jansan »

cooperadymas wrote: post #35

The real ugly with SVG is how frequently we request SVGs from designers or companies and they hand us an SVG file that contains nothing but a base64 encoded PNG image.

Lot of vector editing programs just cheat when things get difficult. I have seen drop shadows as bitmaps, path intersections that become polylines with zillion line segments, elements that are just missing, you name it. Doing vector graphics is hard beyond basic shapes, and I have the feeling that some developers and companies underestimate what they are trying to do at the beginning and then have to rely on workarounds for some features.

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

#137

Post by drewcoo »

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…

Those things are not equivalent.

The circle has unordered properties.

The path has ordered commands. I suppose those commands could be separated and numbered, but isn't that a lot more verbose and less readable?

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

#138

Post by jansan »

steerablesafe wrote: post #10

My two gripes with SVG I bumped into (although the second one is more to browser implementations). 1. It doesn't support premultiplied alpha interpolation mode. If you ever import partially transparent rasterized images then it can cause visible artifacts at the edges of opaque regions. 2. Last time I checked no implementation supported interpolation in linear colorspace (linearRGB [1]). So even though it's bloated i…

Other stuff that is missing:

- Relative coordinates. You can hack around this by using other SVG documents inside an SVG document, but this is really just a hack.

- Conic gradients. Even CSS has them.

Also, there are still a few implementation bugs for SVG. The Chromiums and Firefox teams have done an outstanding job at fixing bugs over the last few years, but if you do advanceed stuff, you will inevitable bounce into one of them. Also, Safari is not really good at SVG, but honestly, who cares.

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

#139

Post by felixfbecker »

paul_manias wrote: post #116
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…

> 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 wonder though why does that matter for a web format that can be served with GZIP encoding? Wouldn't GZIP eat the duplicative tags for breakfast? It would be so much easier to write, read, manipulate and animate.

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

#140

Post by jansan »

Jestar342 wrote: post #22

Recently switched from SVGs to PNGs because the toolset the designers are using means every SVG has the same HTML ID attribute value. So when rendering >1 SVG on a page, they all render the same as the last one in the dom.

Take a look at SVG Injection. This may solve your problems, as the injector will add a unique id to your SVG:

https://github.com/iconfu/svg-inject

Post reply on HN