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

121–130 of 228 posts

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

#121

Post by mrmonkeyman »

climech wrote: post #101
ognarb wrote: post #90

Earlier quoted context omitted.

You clearly didn't understand how the path element in SVG works. The M, L and other characters contains valuable information. M stand for move, L for trace a line, but you can also have instructions for bezier curve or Z for closing a path. Your json format by removing this information is useless.

I believe something like this would work (excuse the comments normally not allowed in JSON): { paths: [ { points: [ [10, 10], // 0 [90, 10], // 1 [90, 90], // 2 [10, 90] // 3 ], lines: [ [0, 1, 2, 3, 0] // connect point 0 to 1 to 2 to (...) ], curves: { 0: [5, 15, 15, 5] // bezier control points for point 0 (x1, y1, x2, y2) } } ] } The downside (other than the bloat) would be when writing the code by hand, you'd have…

How is this better?

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

#122

Post by jcelerier »

climech wrote: post #101
ognarb wrote: post #90

Earlier quoted context omitted.

You clearly didn't understand how the path element in SVG works. The M, L and other characters contains valuable information. M stand for move, L for trace a line, but you can also have instructions for bezier curve or Z for closing a path. Your json format by removing this information is useless.

I believe something like this would work (excuse the comments normally not allowed in JSON): { paths: [ { points: [ [10, 10], // 0 [90, 10], // 1 [90, 90], // 2 [10, 90] // 3 ], lines: [ [0, 1, 2, 3, 0] // connect point 0 to 1 to 2 to (...) ], curves: { 0: [5, 15, 15, 5] // bezier control points for point 0 (x1, y1, x2, y2) } } ] } The downside (other than the bloat) would be when writing the code by hand, you'd have…

i'd much rather have

    [ { line: [10, 10] }, { cubic: [ 5, 15, 15, 5 ] }, ... ]
or even

    [ ["line", 10, 10], ["cubic", ...], ... ]
- anything as long as there's a way to stream the data (which is not possible with your format as you need to receive the whole object before being able to do anything).

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

#123

Post by dschuessler »

Snitch-Thursday wrote: post #67
Symbiote wrote: post #42

Earlier quoted context omitted.

I think, when developers don't like working in XML, it's because the tool forces them to do the job properly . That's work for whoever is producing the document, but wonderful for all the consumers.

> because the tool forces them to do the job properly I'd argue the same restrictions on "setting handwave to maximum" and "XHTML doc has one missing brace, no web page at all now" are two extremes that have their parallels in the 'dynamic vs static typing', 'immutable pure vs mutable impure functions', 'XML vs JSON (oh wait!)', and 'web app vs native program' arguments that we HN readers love to debate. The trick is…

It's a trap. You only need to find the happy medium if you accept the constraints that generate the trade-off in the first place.

And in at least three of the four antagonisms you list, it comes down to the DX of the tooling. Static typing isn't so much of a pain if your type errors are helpful and descriptive. The missing brace in the XHTML doc is easily found when using proper and easy to use XML linters. And I don't see why writing native apps shouldn't be as simple as writing web apps. At least there are attempts that seem to get some mileage out of the idea (e.g. Revery, Flutter).

The trick is to make the toolset more approachable.

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

#124

Post by progval »

pjmlp wrote: post #110
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]}}

path: d: M: 10, 10 H: 90 V: 90 H: 10 L: 10, 10 Just beautiful.

Nope, it should be an array. You use a hash so order isn't preserved and duplicate keys are removed. (Assuming that's Yaml)

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

#125

Post by todd8 »

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…

BNF is just a notation for describing a formal language. Although there are many slight variations of BNF in use, BNF is generally used to describe very precisely the exact syntactically legal sentences (that is, sequences symbols) that belong to a formal language.

Some languages are simple, for example the language that is any sequence of one or more 'A'.

A, AA, AAA, AAAA and so forth are all valid sentences in this language. This is a particularly simple language, but it could be described in BNF:

     ::= A |  A
This language could also be specified as { A^n | n >= 1 } using a set notation or as a regular expression like A+

A slightly more complex language is the language of all sentences made up of a sequence of A and B in any order followed by a sequence of C exactly twice as long as the A's and B's together:

     ::= CC | CC
     ::= A | B
Legal sentences look like: ACC, AACCCC, ABCCCC, BABCCCCCC, etc. Such a language can't be described by classical regular expressions, but can be described by the context-free grammar expressed in BNF above.

There are alternatives and generalizations of BNF notations. Wirth used railroad diagrams to describe the syntax of PASCAL in the Pascal Report describing his language. This are more visual, but not more powerful.

BNF might be a pain, but there is generally no simple way to express complex syntax requirements for programming languages. BNF isn't used to solve the same problem being addressed by XML or JSON which are methods to encode data.

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

#127

Post by icefo »

irrational wrote: post #89

>like to write it by hand I'm honestly horrified that someone out there is writing SVG by hand.

Being able to open a file to quickly change the fill color of a figure for example is nice.

I first did it with inscape and the file size of the simple logo I was editing went up by 6x due to the inscape metadata so I did it manually.

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

#128

Post by riedel »

ChrisMarshallNY wrote: post #60
com2kid wrote: post #51

Earlier quoted context omitted.

> 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

https://www.w3.org/XML/Schema

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

#129

Post by ChrisMarshallNY »

todd8 wrote: post #125
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…

BNF is just a notation for describing a formal language. Although there are many slight variations of BNF in use, BNF is generally used to describe very precisely the exact syntactically legal sentences (that is, sequences symbols) that belong to a formal language. Some languages are simple, for example the language that is any sequence of one or more 'A'. A, AA, AAA, AAAA and so forth are all valid sentences in this…

BNF is an archetype of declarative language.

But I used to work on an X.400 system, and we would have to map out data structures in BNF, pass it through a BNF/X.409 compiler that always hashed things up (often our bad, but that was back in the "big iron" days, when we would have to arm-wrestle for compiler passes), then, once we fixed the X.409, we'd need to pass it into a X.409/C compiler.

And fix it again...

Post reply on HN