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

71–80 of 228 posts

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

#71

Post by pwdisswordfish6 »

michaelt wrote: post #63
cdrini wrote: post #45

Earlier quoted context omitted.

How is XML a garbage fire? In comparison to what? Also, representing paths succinctly as text is inherently complicated. You're trying to represent a very 2D thing in a linear 1D syntax. It's not a limitation of XML, it's a limitation of text being 1D. XML/SGML are a very effective way of representing tree data (again, non-1D data) in 1D strings. And they're wonderfully extensible, while still keeping a well defined…

> How is XML a garbage fire? If you decided to go fully XML on " " it would probably look like this: 10 10 90 10 90 90 10 90 10 10 Some would say the fact the designers of XML went for "M 10 10 H 90 V 90 H 10 L 10 10" instead shows they thought XML is too verbose. simias likely agrees that XML is too verbose - and wonders why they used XML at all

Because it was popular, especially in web-development-adjacent circles back then. And there weren’t many open-standard extensible general-purpose structured data formats. (There are a few more now, but still not that many.) JSON technically did exist (as a subset of JavaScript), but it wasn’t until Crockford named it that it became widely known.

And it’s not like XML has no good ideas in it either. You may disagree about the execution, but the idea of seamlessly mixing structured data defined by independent standards in a single document is pretty damn powerful.

Also, your example is rather strawman-ish: there is no point in using separate elements for individual coordinates, and anyone designing the format would know this. A more realistic example would have contain an ordered sequence of and elements. (In fact, SVG already contains and which use roughly this structure.)

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

#74

Post by kazinator »

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)))

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-case args
         ((M @x @y . @rest) ^((M ,x ,y) ,*(parse-path-args rest)))
         ((L @x @y . @rest) ^((L ,x ,y) ,*(parse-path-args rest)))
         ((H @x . @rest) ^((H ,x) ,*(parse-path-args rest)))
         ((V @x . @rest) ^((V ,x) ,*(parse-path-args rest)))
         (())
         (@else (error "bad path arguments: ~s" else))))
  parse-path-args
  3> (defun-match parse-path
       (((path @(symbolp @name) . @args))
        (new path name name args (parse-path-args args)))
       ((@else) (error "bad path syntax: ~s" else)))
  parse-path
  4> (parse-path '(path d M 10 10 H 90 V 90 H 10 L 10 10))
  #S(path name d args ((M 10 10) (H 90) (V 90) (H 10) (L 10 10)))
Error cases:

  5> (parse-path '(path d M 10 10 H 90 V 90 X 10 L 10 10))
  ** bad path arguments: (X 10 L 10 10)
  ** during evaluation of form (error "bad path arguments: ~s"
                                    else)
  ** ... an expansion of (progn (error "bad path arguments: ~s"
                                     else))
  ** which is located at expr-2:2
  ** run with --backtrace to enable backtraces
  6> (parse-path '(paath d M 10 10 H 90 V 90 X 10 L 10 10))
  ** bad path syntax: paath d M 10 10 H 90 V 90 X 10 L 10 10
  ** during evaluation of form (error `bad path syntax: @else`)
  ** ... an expansion of (progn (error `bad path syntax: @else`))
  ** which is located at expr-3:1
  ** run with --backtrace to enable backtraces

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

#75

Post by tannhaeuser »

Abhinav2000 wrote: post #52
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…

There's nothing wrong with xml or other SGML based markups. They are meant to be written by a computer, not by hand.....

Maybe holds for XML, but not SGML. Its features such as SHORTREF and tag inference for eg parsing Wiki and other custom syntax into canonical angle-bracket markup (aka XML) are pretty much designed to be typed ergonomically and minimalistic, as popular as ever with markdown, etc.

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

#76

Post by hinkley »

Someone wrote: post #32
hinkley wrote: post #19

Earlier quoted context omitted.

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…

I think you missed my point. SVG coordinates are effectively arbitrary precision. 3.5 bits per byte of arbitrary precision, but arbitrary precision nonetheless. There are no small integers, only scalar or vector values.

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

#77

Post by SigmundA »

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.

Just use img tags pointing to SVG's?

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

#78

Post by hinkley »

jerf wrote: post #25
hinkley wrote: post #19

Earlier quoted context omitted.

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.

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?

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

#79

Post by tln »

SVG is preceded by and informed by postscript and PDF.

The postscript language reference manual is 912 pages.

https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf

The PDF reference is 978 pages.

https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/pd...

SVG, if it's less than either is actually doing well...

IMO these three technologies and the accompanying docs are masterpieces, despite bloat. Digging in to those reference docs can almost be fun

The author's idea of SlimSVG sounds interesting, but I think focusing on the file format isn't enough -- one powerful feature of SVG is that it's part of the DOM. Can there be a better system than the DOM+JS for allowing a dynamic document?

EG, document object model in JSON (maybe with JSON schema) and allow updates with JSON patch, with a client/server model for updates. (There's more to DOM)

Personally I think XML is well suited to this task, and am glad to have learned of SVG Native from this thread

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

#80

Post by mywittyname »

kumarvvr wrote: post #41
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…

JSON is a really poor format for anything but simple data. XML may be verbose and not readable, but it is an excellent format for describing and storing data. One alternative for SVG could be an SQL table like datastore, similar to sqlite. I would love yo have the ability to query data, rather than parse through XML. I do understand that transferring such data blobs over networks is an issue.

The biggest issue I have with XML is the ambiguity between attributes and child elements. The distinction makes sense in an abstract perspective, but real-world implementations rarely use them in a consistent manner.
Post reply on HN