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

51–60 of 228 posts

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

#51

Post by com2kid »

ChrisMarshallNY wrote: post #36
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 u…

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

My company heavily uses JSON schema.

The OpenAPI project uses JSON Schemas, and AWS also allows for their usage in places.

And finally, there are a couple good projects that automatically generate JSON Schemas from Typescript definitions, which is my preferred way to go. :)

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

#52

Post by Abhinav2000 »

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

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

#54

Post by riedel »

ChrisMarshallNY wrote: post #36
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 u…

Hedge grammars have really nice features, which can be parsed by a class of pushdown automata. However, my experience is that not many people understood and valued those features in the XML ecosystem (see SVG but also Xpath). Would be nice to see actually a schema first language that has a good binary and human readable representation. IMHO we can do better than zipped JSON even if is hard.

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

#55

Post by Eisfunke »

PaulHoule wrote: post #18

I have been interested in the "low code" problem, in particular the kind of advanced parsers that were used in the 1990s to attempt things like "edit the UML diagram in a GUI and change the Ada source code the way a professional programmer would". Dreamweaver used to do this for HTML, sometime before it got bought by Adobe. Today Dreamweaver seems like it would be usable on a 90 THz computer but I can do 10 push ups…

Author here, for editing SVGs by hand I use VSCode (or VS Codium to be precise) with the SVG Viewer add-on in split-screen: https://marketplace.visualstudio.com/items?itemName=cssho.vs...

Works pretty well as split screen editor. The preview refreshes on save with ctrl-S.

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

#56

Post by Eisfunke »

intrepidhero wrote: post #21

> Decide whether a language is for humans or for machines and do one of those things. And do the one thing well instead of both, but badly. The thing is all these languages (ASM, C, XML, JSON, Python, etc) are fundamentally about communication between a human and a machine. We make tradeoffs between making them easy to parse (for the machine) or easy to read and write (for the human) but they all must address both ne…

You're absolutely right, it is always a trade-off. I've added a paragraph at the end of my article focused on that particular problem to address that: https://www.eisfunke.com/article/language-design-machine-or-...

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

#57

Post by thangalin »

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…

> If you need to generate basic shapes it's fairly straightforward.

You'd think so. While integrating TeX into my editor[0], using JMathTeX[1] as a starting point, I wanted to convert font glyphs to vector paths. At the time, every Java-based SVG renderer (Batik, JFreeSVG, SVG Salamander) suffered from the exact same performance problem: they all used Java's DecimalFormat class to convert floating point numbers to strings. These strings were then concatenated as paths into the output document. Sometimes the strings were re-copied numerous times because of buffer re-allocations and other reasons. (Part 5 of my series[2] on developing a TeX-oriented text editor covers this in depth.)

To get great performance---in Java, at least---even for basic shapes requires a sufficiently large, reusable buffer that doesn't incur memory re-allocations and an efficient algorithm to convert floats to strings---such as Ryu[3]. See my implementation that converts glyph paths to vector paths for details[4]. With these two changes I was able to improve upon JFreeSVG's implementation four-fold.

[0]: https://github.com/DaveJarvis/keenwrite (my editor)

[1]: https://github.com/DaveJarvis/JMathTeX/ (my fork)

[2]: https://bell-sw.com/announcements/2020/11/02/TeXnical-Writin... (my blog series)

[3]: https://github.com/ulfjack/ryu

[4]: https://github.com/DaveJarvis/JMathTeX/blob/d2d678717505765b...

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

#59

Post by runarberg »

cdrini wrote: post #45
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…

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…

Exactly, in the canvas API this is written like:

    

    ctx.moveTo(10, 10);
    ctx.lineTo(90, 10);
    ctx.lineTo(90, 90);
    ctx.lineTo(10, 90);
    ctx.lineTo(10, 10);
Not much better.

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

#60

Post by ChrisMarshallNY »

com2kid wrote: post #51
ChrisMarshallNY wrote: post #36

Earlier quoted context omitted.

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 u…

> 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. My company heavily uses JSON schema. The OpenAPI project uses JSON Schemas, and AWS also allows for their usage in places. And finally, there are a couple good projects that automatically generate JSON Schemas from Typescript definitions, which is my preferr…

This is nicely done: https://json-schema.org/specification.html

But note "draft."

Compare to: https://www.w3.org/standards/xml/schema

Post reply on HN