14 ms·

So here's a question: JSON is to XML what ___ is to SVG. What is in the blank? There's just so much complexity in even the 1.1 spec. Patterns, for example, a

So here's a question: JSON is to XML what ___ is to SVG. What is in the blank? There's just so much complexity in even the 1.1 spec. Patterns, for example, are given the default of specifying the width and height of the area to be repeated in objectBoundingBox units. But the arbitrarily complex content has its units defined in terms of the userspace units derived from the context in which the pattern itself is used. Now, if you play around with patterns for a bit you can certainly figure out the logic of those defaults. Most likely the author doesn't want the aspect ratio of the pattern content to change based on the width/height specified for the pattern viewbox. Hence patternContentUnits defaults to "userSpaceOnUse". On the other hand, the author likely wants to control the total number of columns/rows that will be displayed. Hence patternUnits defaults to "objectBoundingBox", where you can do the math for 1/width for rows and 1/height for columns. But then when you try to do actual work using those defaults-- say, filling a rectangle with a pattern that displays four small circles as "nails" in the corners of the rectangle-- it doesn't work. The patternUnits attribute isn't expressive enough to let you specify a way to attach each pattern iteration to a corner of the shape. You can achieve that for a particular bounding box, but it isn't easy. So the logical though complex default isn't particularly expressive in practice, and the more sane, less expressive way to do patterns requires non-default attributes. I run into similar such problems with many of the SVG 1.1 features. There's an incredible amount of complexity, but not a matching amount of expressivity gained for it. Even something like grabbing or setting a value for height/width/x/y is made more complex because the DOM is storing both a base value and an additional value should the user happen to have specified declarative animation on the element. But then declarative animation isn't implemented in all browsers after all this time-- nor is it as easy to work with as the burgeoning web animations API.

dukoid 10y ago
Android Vector Drawables? If you manage to ignore the use of namespaces for attributes, which seems to account for half the file size for smaller files... :-/
arnarbi 10y ago
It's perhaps not the answer you are looking for, but spending a couple of evenings learning PostScript (as a programming language) is eye opening.
- taeric 10y ago
  I just finished suggesting that in a sibling post. :) For examples of METAPOST, see http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.html http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.h... For examples of Postscript, see https://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Examples/english.html https://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Example... Note that for the postscript examples, if you open them in "preview" or other graphical program, it will show you the graphics. If you open it in a text editor, you will see the code.
- DonHopkins 10y ago
  Here's a visual PostScript programming and debugging environment I wrote in PostScript for the NeWS window system in 1989. http://www.donhopkins.com/drupal/node/97 http://www.donhopkins.com/drupal/node/97 https://www.youtube.com/watch?v=iuC_DDgQmsM https://www.youtube.com/watch?v=iuC_DDgQmsM
taeric 10y ago
The problem is that JSON didn't come into being to replace XML. JSON exists only because it was basically the JS literal syntax, and people needed easy ways to instantiate javascript objects. (If there is an alternative history here that is compelling, I'll accept it. Will be hard, though, because I swear JSON was essentially an accepted standard as soon as people found they could write out a JS object directly.) So, is there another language that lets you script graphics easily? PostScript would have come close, maybe. METAPOST definitely gets close, though folks are afraid of it. I think my vote would ultimately end up being METAPOST, as far as capabilities go. Nothing, if we are looking for a popularity contest. And, well, nothing if we are looking for "works well in the browser".
- BinaryIdiot 10y ago
  > JSON exists only because it was basically the JS literal syntax, and people needed easy ways to instantiate javascript objects. JSON is an interchange format that, while it's based off a subset of JavaScript, was created as the authors were looking for a way to send data between the browser and the server without Flash swifts or Java applets that was small and easy to use and since JavaScript was already there they just lifted that. I'm not sure I get the "needed easy ways to instantiate javascript objects". I don't see that anywhere and ECMAScript 3 was out at the time which let you instantiate them pretty easily. So maybe I misunderstand your meaning?
  - flukus 10y ago
    > a way to send data between the browser and the server without Flash swifts or Java applets that was small and easy to use And because they hated angle brackets. XML already filled that void.
    - BinaryIdiot 10y ago
      XML wouldn't have filled the void well for JavaScript though. Their goal was to send data back and forth and would ultimately need to be processed and rendered by JavaScript. Easiest way to do that is to just send a JavaScript object back and forth. It would have been a lot cheaper to parse JSON into JavaScript objects especially back then on the more limited hardware than trying to parse XML.
pavlov 10y ago
JSON is to XML what ___ is to SVG. What is in the blank? It's not exciting or clever, but HTML5 Canvas fills in that blank. It'a a minimal API that was designed by Apple to be just good enough to make Mac OS X 10.4 desktop widgets possible to implement in JavaScript. Canvas has a straightforward mapping to the big platform 2D APIs -- CoreGraphics, Cairo, Direct2D. The bitmap data interfaces are an ugly but in practice mostly satisfactory escape hatch when you need to draw something the API doesn't include. Both SVG and CSS are failed specs in my mind due to what you succinctly describe as "incredible complexity without matching expressivity". The difference is that CSS doesn't have an alternative, so everyone tries to live with it.
- colanderman 10y ago
  SVG is a data format; Canvas is an API. They're only interchangeable in limited use cases.
  - tyingq 10y ago
    Fabric.js helps a bit with that. It can export/import a canvas to either JSON or SVG. http://fabricjs.com/fabric-intro-part-3#deserialization http://fabricjs.com/fabric-intro-part-3#deserialization
  - pavlov 10y ago
    JavaScript is a programming language, yet its subset JSON is a data format. PostScript is a programming language, yet it looks like a data format to most applications. The web is supposed to be about hyperlinked documents, yet it's mostly about executing JavaScript applications these days. The blurred lines between data and code are the most exciting thing about this whole field, if you ask me!
    - colanderman 10y ago
      JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surface syntax, which is wholly irrelevant. PostScript is a terrible intermediate graphics format. It is not structured like how SVG is, and thus does not lend itself well to editing. Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates. You're right that Canvas is analogous to PostScript; Canvas also would make a terrible intermediate format. Sure, we could use it as one; it would certainly be a more universal final format than SVG; but then, what's wrong with PostScript there? It's certainly less verbose. Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field.
rbonvall 10y ago
I would love to have something like TikZ for the browser.
nigeltao 10y ago
Last year, I invented IconVG, a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji. IconVG is similar in concept to SVG (Scalable Vector Graphics) but much simpler. Compared to "SVG Tiny", it does not have features for text, multimedia, interactivity, linking, scripting, animation, XSLT, DOM, combination with raster graphics such as JPEG formatted textures, etc. The announcement is at https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p8k8 https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p... and quoting from that: "The SVG spec prints as 400 pages, not including the XML, CSS or XSLT specifications. [The IconVG godoc.org page, which includes the file format specification, prints as 26 pages]... The Material Design icon set... consists of 961 vector icons. As SVG files, this totals 312,887 bytes. As 24 * 24 pixel PNGs, 190,840 bytes. As 48 * 48 pixel PNGs, 318,219 bytes. As IconVGs, 122,012 bytes."
- josephg 10y ago
  Thats really cool, but its impossible to discover and learn about hidden away in a dusty old thread on the golang-nuts mailing list. If you want your project to become popular & used by a wider audience, it would be totally worth getting a domain and making a website for it. Ideally the site would host demos and links to the spec / implementations - but even something simple with the content described in that thread would be a good start.
  - fenwick67 10y ago
    Even just a github repo with a `gh-pages` branch and simple static site can do wonders for a project.
  - xyzzy_plugh 10y ago
    I discovered it by reading this page while browsing the shiny package: https://godoc.org/golang.org/x/exp/shiny/iconvg https://godoc.org/golang.org/x/exp/shiny/iconvg I think the documentation is quite good. What you ask of Nigel is similar to what you see in the article. Should he spend his own resources to maintain a domain and website? How far does one take this?
ZenPsycho 10y ago
not a serious reply, but while we are listing out SVG alternatives, heres an obscure one named IDEAL[1] that came with System V UNIX. (linked: the manual in postscript format) the basic vector primative in IDEAL is a complex number, for making rotations "easier". The language itself is one of the few examples of a fully constraints oriented language. functions rather than taking input parameters, simply have free variables. you can supply constants for any of them and the system will resolve when there is only one possible solution. the output of IDEAL is dvi which could be fed into TROFF to print. [1]: https://web.cecs.pdx.edu/~trent/gnu/groff/103.ps https://web.cecs.pdx.edu/~trent/gnu/groff/103.ps
_delirium 10y ago
> There's just so much complexity in even the 1.1 spec. Not sure if you meant to imply that, but "even" here suggests that 2.0 is an increase in complexity over 1.1, which I'm not sure is true. There is some new stuff, but also a lot of edge cases simplified and entire bodies of cruft ripped out (for example, XML DTDs and all associated baggage are gone).
- jancsika 10y ago
  Yes, that's what I meant. Off the top of my head: 2.0 adds mesh gradients, a "bearing" command to path data, text that wraps (or possibly fills a cavity/shape, can't remember), manual z-ordering, and probably other new features that I didn't notice. However, it sounds like the browsers have essentially rejected a lot of those new features. If the idea is that they instead use the 2.0 spec only for the clarifications and cruft cleanup that you mention, that would reduce complexity and be a good thing.
  - stuaxo 10y ago
    Some of the features, like mesh gradient have polyfills. Polyfills are the only way this chicken and egg problem will be solved, if widely used browser vendors will eventually implement the standards.
    - jancsika 10y ago
      I'm only speculating, but the problem may be the complexity of the paint server interface. Using it requires FuncIRIs which-- as one commenter on another thread pointed out-- can cause name collisions with inline SVGs. You could of course abstract away that problem with javascript post-processing-- but then you have yet more complexity, this time for a problem that doesn't exist in the domain of CSS. That limits the expressivity of the feature. For example, I wouldn't be able to just play around with SVG mesh gradients inside about:blank in Firefox due to a deeper problem with resolving FuncIRIs. Whereas I can trivially create a CSS gradient there and experiment with them.

dukoid 10y ago

Android Vector Drawables? If you manage to ignore the use of namespaces for attributes, which seems to account for half the file size for smaller files... :-/

arnarbi 10y ago

It's perhaps not the answer you are looking for, but spending a couple of evenings learning PostScript (as a programming language) is eye opening.

taeric 10y ago
I just finished suggesting that in a sibling post. :) For examples of METAPOST, see http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.html http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.h... For examples of Postscript, see https://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Examples/english.html https://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Example... Note that for the postscript examples, if you open them in "preview" or other graphical program, it will show you the graphics. If you open it in a text editor, you will see the code.
DonHopkins 10y ago
Here's a visual PostScript programming and debugging environment I wrote in PostScript for the NeWS window system in 1989. http://www.donhopkins.com/drupal/node/97 http://www.donhopkins.com/drupal/node/97 https://www.youtube.com/watch?v=iuC_DDgQmsM https://www.youtube.com/watch?v=iuC_DDgQmsM

taeric 10y ago

The problem is that JSON didn't come into being to replace XML. JSON exists only because it was basically the JS literal syntax, and people needed easy ways to instantiate javascript objects. (If there is an alternative history here that is compelling, I'll accept it. Will be hard, though, because I swear JSON was essentially an accepted standard as soon as people found they could write out a JS object directly.) So, is there another language that lets you script graphics easily? PostScript would have come close, maybe. METAPOST definitely gets close, though folks are afraid of it. I think my vote would ultimately end up being METAPOST, as far as capabilities go. Nothing, if we are looking for a popularity contest. And, well, nothing if we are looking for "works well in the browser".

BinaryIdiot 10y ago
> JSON exists only because it was basically the JS literal syntax, and people needed easy ways to instantiate javascript objects. JSON is an interchange format that, while it's based off a subset of JavaScript, was created as the authors were looking for a way to send data between the browser and the server without Flash swifts or Java applets that was small and easy to use and since JavaScript was already there they just lifted that. I'm not sure I get the "needed easy ways to instantiate javascript objects". I don't see that anywhere and ECMAScript 3 was out at the time which let you instantiate them pretty easily. So maybe I misunderstand your meaning?
- flukus 10y ago
  > a way to send data between the browser and the server without Flash swifts or Java applets that was small and easy to use And because they hated angle brackets. XML already filled that void.
  - BinaryIdiot 10y ago
    XML wouldn't have filled the void well for JavaScript though. Their goal was to send data back and forth and would ultimately need to be processed and rendered by JavaScript. Easiest way to do that is to just send a JavaScript object back and forth. It would have been a lot cheaper to parse JSON into JavaScript objects especially back then on the more limited hardware than trying to parse XML.

pavlov 10y ago

JSON is to XML what ___ is to SVG. What is in the blank? It's not exciting or clever, but HTML5 Canvas fills in that blank. It'a a minimal API that was designed by Apple to be just good enough to make Mac OS X 10.4 desktop widgets possible to implement in JavaScript. Canvas has a straightforward mapping to the big platform 2D APIs -- CoreGraphics, Cairo, Direct2D. The bitmap data interfaces are an ugly but in practice mostly satisfactory escape hatch when you need to draw something the API doesn't include. Both SVG and CSS are failed specs in my mind due to what you succinctly describe as "incredible complexity without matching expressivity". The difference is that CSS doesn't have an alternative, so everyone tries to live with it.

colanderman 10y ago
SVG is a data format; Canvas is an API. They're only interchangeable in limited use cases.
- tyingq 10y ago
  Fabric.js helps a bit with that. It can export/import a canvas to either JSON or SVG. http://fabricjs.com/fabric-intro-part-3#deserialization http://fabricjs.com/fabric-intro-part-3#deserialization
- pavlov 10y ago
  JavaScript is a programming language, yet its subset JSON is a data format. PostScript is a programming language, yet it looks like a data format to most applications. The web is supposed to be about hyperlinked documents, yet it's mostly about executing JavaScript applications these days. The blurred lines between data and code are the most exciting thing about this whole field, if you ask me!
  - colanderman 10y ago
    JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surface syntax, which is wholly irrelevant. PostScript is a terrible intermediate graphics format. It is not structured like how SVG is, and thus does not lend itself well to editing. Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates. You're right that Canvas is analogous to PostScript; Canvas also would make a terrible intermediate format. Sure, we could use it as one; it would certainly be a more universal final format than SVG; but then, what's wrong with PostScript there? It's certainly less verbose. Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field.

rbonvall 10y ago

I would love to have something like TikZ for the browser.

nigeltao 10y ago

Last year, I invented IconVG, a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji. IconVG is similar in concept to SVG (Scalable Vector Graphics) but much simpler. Compared to "SVG Tiny", it does not have features for text, multimedia, interactivity, linking, scripting, animation, XSLT, DOM, combination with raster graphics such as JPEG formatted textures, etc. The announcement is at https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p8k8 https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p... and quoting from that: "The SVG spec prints as 400 pages, not including the XML, CSS or XSLT specifications. [The IconVG godoc.org page, which includes the file format specification, prints as 26 pages]... The Material Design icon set... consists of 961 vector icons. As SVG files, this totals 312,887 bytes. As 24 * 24 pixel PNGs, 190,840 bytes. As 48 * 48 pixel PNGs, 318,219 bytes. As IconVGs, 122,012 bytes."

josephg 10y ago
Thats really cool, but its impossible to discover and learn about hidden away in a dusty old thread on the golang-nuts mailing list. If you want your project to become popular & used by a wider audience, it would be totally worth getting a domain and making a website for it. Ideally the site would host demos and links to the spec / implementations - but even something simple with the content described in that thread would be a good start.
- fenwick67 10y ago
  Even just a github repo with a `gh-pages` branch and simple static site can do wonders for a project.
- xyzzy_plugh 10y ago
  I discovered it by reading this page while browsing the shiny package: https://godoc.org/golang.org/x/exp/shiny/iconvg https://godoc.org/golang.org/x/exp/shiny/iconvg I think the documentation is quite good. What you ask of Nigel is similar to what you see in the article. Should he spend his own resources to maintain a domain and website? How far does one take this?

ZenPsycho 10y ago

not a serious reply, but while we are listing out SVG alternatives, heres an obscure one named IDEAL[1] that came with System V UNIX. (linked: the manual in postscript format) the basic vector primative in IDEAL is a complex number, for making rotations "easier". The language itself is one of the few examples of a fully constraints oriented language. functions rather than taking input parameters, simply have free variables. you can supply constants for any of them and the system will resolve when there is only one possible solution. the output of IDEAL is dvi which could be fed into TROFF to print. [1]: https://web.cecs.pdx.edu/~trent/gnu/groff/103.ps https://web.cecs.pdx.edu/~trent/gnu/groff/103.ps

_delirium 10y ago

> There's just so much complexity in even the 1.1 spec. Not sure if you meant to imply that, but "even" here suggests that 2.0 is an increase in complexity over 1.1, which I'm not sure is true. There is some new stuff, but also a lot of edge cases simplified and entire bodies of cruft ripped out (for example, XML DTDs and all associated baggage are gone).

jancsika 10y ago
Yes, that's what I meant. Off the top of my head: 2.0 adds mesh gradients, a "bearing" command to path data, text that wraps (or possibly fills a cavity/shape, can't remember), manual z-ordering, and probably other new features that I didn't notice. However, it sounds like the browsers have essentially rejected a lot of those new features. If the idea is that they instead use the 2.0 spec only for the clarifications and cruft cleanup that you mention, that would reduce complexity and be a good thing.
- stuaxo 10y ago
  Some of the features, like mesh gradient have polyfills. Polyfills are the only way this chicken and egg problem will be solved, if widely used browser vendors will eventually implement the standards.
  - jancsika 10y ago
    I'm only speculating, but the problem may be the complexity of the paint server interface. Using it requires FuncIRIs which-- as one commenter on another thread pointed out-- can cause name collisions with inline SVGs. You could of course abstract away that problem with javascript post-processing-- but then you have yet more complexity, this time for a problem that doesn't exist in the domain of CSS. That limits the expressivity of the feature. For example, I wouldn't be able to just play around with SVG mesh gradients inside about:blank in Firefox due to a deeper problem with resolving FuncIRIs. Whereas I can trivially create a CSS gradient there and experiment with them.