5 ms·

While I do appreciate the thought process and hard work, it does maybe feel like the most of the benefits could be obtained with a strict subset of SVG instead

While I do appreciate the thought process and hard work, it does maybe feel like the most of the benefits could be obtained with a strict subset of SVG instead - something like SVG Tiny was meant to be, but with fewer bad decisions! That would allow for compatibility with the existing ubiquitous SVG ecosystem.

ikskuh 5y ago
The problem with that is that you still need to implement a full XML parser. Even if you strip out any CSS and ECMAScript, it will still require the complexity of XML with all it's gloryness and escapiness and ambigious defines. And even if we rely only on XML, we get the DOM and hierarchical structures. If we forbid those, we have <svg><object /><object /><object /></svg> as a file format and people will look weird because their other SVG won't be supported in there.
- tracnar 5y ago
  You could also restrict the allowed XML so it can be parsed/generated without a full parser.
- exabrial 5y ago
  "XML is bad" is still one of the worst engineering arguments. Why is it bad? What is the tradeoff? Things that are bad are easy to quantify as they're measurable. What does it have? It has strong schema support built in. Any intelligent IDE allows for cmd-space completion by reading the XSD. I don't buy this argument as full XML parsers are not even as complicated as HTML5 parsers, which nobody seems to have an issue with. It's not the end-all-be-all of formats, but this is something that's oft-repeated and never quantified. Your second point is actually valid though. If the TinyVG format takes advantage of non-tree based data-structures, I can certainly understand the motivation. I have a hard time conceptualizing how a tree based format would be beneficial to a vector format, other than describing metadata about certain "areas" of the image.
  - adgjlsfhk1 5y ago
    XML is bad because it bloats the size by roughly 3x (compared to other text formats like s-exprs), is difficult to implement properly. HTML is bad too, we're just more stuck with it so it's less useful to complain.
    - shatteredgate 5y ago
      The size is not really an issue for any compression algorithm. I've seen quite a few small XML parsers that don't bother with the full spec and only implement a subset.
      - adgjlsfhk1 5y ago
        Even when you compress XML, it's still around 10% bigger than JSON, and around 40% bigger than protobuf (not endorsing either, just examples). Furthermore, making the compressor work harder isn't free. The time to compress and decompress XML is roughly 2x higher than with JSON, and if you decompress the data before using it, XML will still hit you wrt RAM usage. All of these would be fine if XML offered you some really good advantage over alternatives, but as far as I can see, it doesn't. It just eats up CPU/memory/bandwith/keystrokes for no reason.
        shatteredgate 5y ago
        XML does offer some really good advantages when it comes to storing strings and sub-documents. I would absolutely not want to write any kind of document in JSON, but XML has been used successfully for a great many document formats.
  - ikskuh 5y ago
    XML is bad for TinyVG as it is too large in several regards. XML kinda requires DOM parsing, XML is a text format (so inefficient encoding) and XML parsers need to be large so they can be called XML parsers. All of these properties contradict a embedded world where you can render vector graphics from 32k RAM on a chip that doesn't even have enough memory for a framebuffer itself. Also implementation complexity of XML is so high that i gave up on impementing a correct parser. I don't want to have a half-assed parser that cannot parse XML, but only "XML light" and making this is a huge amount of work which i don't want to waste in my leisure time

ikskuh 5y ago

The problem with that is that you still need to implement a full XML parser. Even if you strip out any CSS and ECMAScript, it will still require the complexity of XML with all it's gloryness and escapiness and ambigious defines. And even if we rely only on XML, we get the DOM and hierarchical structures. If we forbid those, we have <svg><object /><object /><object /></svg> as a file format and people will look weird because their other SVG won't be supported in there.

tracnar 5y ago
You could also restrict the allowed XML so it can be parsed/generated without a full parser.
exabrial 5y ago
"XML is bad" is still one of the worst engineering arguments. Why is it bad? What is the tradeoff? Things that are bad are easy to quantify as they're measurable. What does it have? It has strong schema support built in. Any intelligent IDE allows for cmd-space completion by reading the XSD. I don't buy this argument as full XML parsers are not even as complicated as HTML5 parsers, which nobody seems to have an issue with. It's not the end-all-be-all of formats, but this is something that's oft-repeated and never quantified. Your second point is actually valid though. If the TinyVG format takes advantage of non-tree based data-structures, I can certainly understand the motivation. I have a hard time conceptualizing how a tree based format would be beneficial to a vector format, other than describing metadata about certain "areas" of the image.
- adgjlsfhk1 5y ago
  XML is bad because it bloats the size by roughly 3x (compared to other text formats like s-exprs), is difficult to implement properly. HTML is bad too, we're just more stuck with it so it's less useful to complain.
  - shatteredgate 5y ago
    The size is not really an issue for any compression algorithm. I've seen quite a few small XML parsers that don't bother with the full spec and only implement a subset.
    - adgjlsfhk1 5y ago
      Even when you compress XML, it's still around 10% bigger than JSON, and around 40% bigger than protobuf (not endorsing either, just examples). Furthermore, making the compressor work harder isn't free. The time to compress and decompress XML is roughly 2x higher than with JSON, and if you decompress the data before using it, XML will still hit you wrt RAM usage. All of these would be fine if XML offered you some really good advantage over alternatives, but as far as I can see, it doesn't. It just eats up CPU/memory/bandwith/keystrokes for no reason.
      - shatteredgate 5y ago
        XML does offer some really good advantages when it comes to storing strings and sub-documents. I would absolutely not want to write any kind of document in JSON, but XML has been used successfully for a great many document formats.
- ikskuh 5y ago
  XML is bad for TinyVG as it is too large in several regards. XML kinda requires DOM parsing, XML is a text format (so inefficient encoding) and XML parsers need to be large so they can be called XML parsers. All of these properties contradict a embedded world where you can render vector graphics from 32k RAM on a chip that doesn't even have enough memory for a framebuffer itself. Also implementation complexity of XML is so high that i gave up on impementing a correct parser. I don't want to have a half-assed parser that cannot parse XML, but only "XML light" and making this is a huge amount of work which i don't want to waste in my leisure time