4 ms·

But then it might easily become unclear exactly which subset of SVG is supported. I am personally leery of implementing subsets of other formats. I find it be

by Athas 4y ago

But then it might easily become unclear exactly which subset of SVG is supported. I am personally leery of implementing subsets of other formats. I find it better to define entirely new formats, at least for simple things like this. To render this "lines" format, you could of course easily write a translator that turns it into SVG. It's mostly the other direction that I would be hesitant about.

bestest 4y ago
Why would you want implement a subset of SVG? It's native for browsers, and is surely supported in a plethora of languages using various libraries.
- aidos 4y ago
  Hmmm. There actually a lot to it and you don’t want to end up in a situation where documents don’t render properly unless you’re using a really complete viewer.
- cxcorp 4y ago
  Because standards compliant SVG introduces XSS surfaces.
- badsectoracula 4y ago
  Now you replaced a trivial file format that (from a quick glance at the code) needed about ~35 of easily readable and self-contained Lua code to parse with an external dependency that would be much larger and harder to follow and either having (at least) an XML parser as its own dependency or implementing its own XML parsing, as well as being at the mercy of their developers. Also unless you are using some highly popular library, you may end up with some abandoned dependency. Examples of both are at [0] (C++ based parser, you'd also need to write some bindings for lua) and [1] (Lua based parser for a subset of the format, abandoned for almost a decade). There are times when using an external dependency might be a good idea, but a text-based file format that describes lines and can be implemented in a few lines of code is not one. [0] https://github.com/svgpp/svgpp https://github.com/svgpp/svgpp [1] https://github.com/luapower/svg_parser https://github.com/luapower/svg_parser
- Athas 4y ago
  Some people appreciate simplicity as a virtue - simplicity of implementation as well. To such people, using a third party library to conceal an incredibly complicated implementation is still in principle ugly. I don't know if that is what motivated the author here, but I certainly know lots of people who would cite that as their motivation.
  - jheriko 4y ago
    he used a gigantic and elaborate framework/engine filled with cruft... so i doubt that was the thinking here.
ainar-g 4y ago
In another thread[1] I've mentioned the SVG Tiny profile[2], which has been defined almost twenty years ago and is apparently already used in some cases where the full power of SVG is not required. [1]: https://news.ycombinator.com/item?id=31638850 https://news.ycombinator.com/item?id=31638850 [2]: https://www.w3.org/TR/SVGTiny/ https://www.w3.org/TR/SVGTiny/

by Athas 4y ago

bestest 4y ago

Why would you want implement a subset of SVG? It's native for browsers, and is surely supported in a plethora of languages using various libraries.

aidos 4y ago
Hmmm. There actually a lot to it and you don’t want to end up in a situation where documents don’t render properly unless you’re using a really complete viewer.
cxcorp 4y ago
Because standards compliant SVG introduces XSS surfaces.
badsectoracula 4y ago
Now you replaced a trivial file format that (from a quick glance at the code) needed about ~35 of easily readable and self-contained Lua code to parse with an external dependency that would be much larger and harder to follow and either having (at least) an XML parser as its own dependency or implementing its own XML parsing, as well as being at the mercy of their developers. Also unless you are using some highly popular library, you may end up with some abandoned dependency. Examples of both are at [0] (C++ based parser, you'd also need to write some bindings for lua) and [1] (Lua based parser for a subset of the format, abandoned for almost a decade). There are times when using an external dependency might be a good idea, but a text-based file format that describes lines and can be implemented in a few lines of code is not one. [0] https://github.com/svgpp/svgpp https://github.com/svgpp/svgpp [1] https://github.com/luapower/svg_parser https://github.com/luapower/svg_parser
Athas 4y ago
Some people appreciate simplicity as a virtue - simplicity of implementation as well. To such people, using a third party library to conceal an incredibly complicated implementation is still in principle ugly. I don't know if that is what motivated the author here, but I certainly know lots of people who would cite that as their motivation.
- jheriko 4y ago
  he used a gigantic and elaborate framework/engine filled with cruft... so i doubt that was the thinking here.

ainar-g 4y ago

In another thread[1] I've mentioned the SVG Tiny profile[2], which has been defined almost twenty years ago and is apparently already used in some cases where the full power of SVG is not required. [1]: https://news.ycombinator.com/item?id=31638850 https://news.ycombinator.com/item?id=31638850 [2]: https://www.w3.org/TR/SVGTiny/ https://www.w3.org/TR/SVGTiny/