7 ms·

For simple image generation, nothing beats SVG or EPS. For years, these two technologies have let me add cool stuff to PDFs and web pages without the need for e

For simple image generation, nothing beats SVG or EPS. For years, these two technologies have let me add cool stuff to PDFs and web pages without the need for expensive/complex/insecure libraries. It is going to be pretty hard to beat the ease of generating these formats.

ikskuh 5y ago
Then you should check out the TinyVG text format: (tvg 1 (32 32 1/1 u8888 reduced) ( (1 0 0) ) ( (fill_polygon (flat 0) ( (16 0) (32 32) (0 32) )) ) ) This draws you a tiny triangle. The only problem you'll get is when doing text, but for SVG: These wouldn't be portable anyways
- shatteredgate 5y ago
  Am I the only one who dislikes S-expressions and prefers XML or JSON or even YAML? The parenthesis are way too confusing when editing manually and the format doesn't have enough semantic information to always correctly parse into common structures in any language besides lisp. I enjoy writing lisp myself but I really think it is a mistake to use them for common formats everywhere that I've seen it tried.
  - dnautics 5y ago
    seriously, it shouldn't be so hard to write a parser that compiles your favorite text format to TVG, or even to the lispy text format.
    - shatteredgate 5y ago
      IMO that defeats the purpose of using this format if you have to write things to compile to it. If you do that you might as well just compile to the binary format since you won't be editing your canonical representation anyway. I'd imagine with image formats you'd want to pick a format that is the easiest possible thing to parse and consume while not harming it's "editableness" and I don't think S-expressions fit that bill.
      - dnautics 5y ago
        Tvg is a binary format? It's not really human readable. Compiling to it is a natural thing to be doing.
        shatteredgate 5y ago
        Sorry, was responding to the last part of your sentence.
  - templix 5y ago
    You enjoy writing Lisp, but somehow find parenthesis way too confusing when editing manually? That's pretty hilarious. If you take the expression above and format it in any half-decent editor, it's pretty clear. YAML is a shitshow, JSON is yuck and let's not talk about XML.
    - shatteredgate 5y ago
      Yes, I enjoy lisp the language and its constructs but I don't enjoy the parenthesis or the syntax. What's hilarious about that? I'm sure you could list some aspects of lisp that you don't like if you have a lot of experience with it. >YAML is a shitshow, JSON is yuck and let's not talk about XML. My issue with S-expressions as a data exchange format is that they're actually just the worst aspects of all three of those combined. If you're frustrated by XML having really deep trees and only having strings and elements as datatypes, then S-expressions are just as bad, reliably they only really have strings and lists as datatypes and the trees tend to have even deeper nesting than XML. For JSON the formats are equivalent if you remove everything from JSON except lists and strings, so S-expressions are strictly a worse subset, they're just as yuck. YAML is bad because it's complex and badly specified but S-expressions are still worse of a shitshow because there is no spec. You just have to hope the format you used is compatible with your Lisp implementation. And yes this has caused me problems where using "read" on S-expressions with certain characters in them or in certain encodings completely breaks on some Lisp implementations. If you're using some other language that isn't Lisp and you're rolling your own parser then good luck having that be compatible with anything, most parsers I see just pick a random Lisp implementation and aim for compatibility with it which is still not reliable. The only good thing I can say about S-expressions is that they're quite easy to spit out from a bash script, but for this problem domain (vector graphics) there is an even easier option: use a very simple command-based format like postscript.
  - hayley-patton 5y ago
    I'm not a fan of the usual uses of S-expressions in data formats, but for quite the opposite reasons. People seem to have a thing for making up new syntax, so you can't just throw a normal S-expression parser at the problem, and be done with it. For example, the wasm2ps reader [1] has to know how to read a comment in the WebAssembly text format. I decided to leave the project at handling integer instructions and control flow only, as there are other oddities like using a single atom for alignment and offsets in load and store instructions [2]. Some people I've talked to wished that people would stop inventing ad-hoc syntaxes, and just use S-expressions or something. Using S-expressions but adding more ad-hoc syntax gives you the worst of both options. While admittedly less of a problem for implementation, it is also annoying to see lists with dangling parens on their own lines, and symbols with underscores or camelCase in the names, once you are used to the normal way of formatting Lisp code. [1] https://github.com/no-defun-allowed/wasm2ps/blob/master/Code/reader.lisp https://github.com/no-defun-allowed/wasm2ps/blob/master/Code... [2] https://github.com/WebAssembly/spec/blob/master/interpreter/README.md#s-expression-syntax https://github.com/WebAssembly/spec/blob/master/interpreter/...
  - mro_name 5y ago
    XML and YAML (including it's JSON representation) are complexity nightmares. But especially for xml, the tooling makes them appealing to use as e.g. distribution format with JS-less browser templating.
- mro_name 5y ago
  S-expressions, finally! Thanks!
deleted 5y ago
[deleted]
tromp 5y ago
Agreed; I was playing with pinwheel tilings [1] today and decided to make some pinwheel art [2] that fits in a signature: %!PS % -John Tromp http://tromp.github.io/ /t{dup 1 sub gsave dup 0 gt{[.4 .2 -.2 .4 .4 .2]concat t currentgray .8 mul .2 add setgray -1 1 scale t -1 2 translate t 1 -1 scale t[0 1 1 0 0 2]concat t pop}{0 moveto 1 0 lineto 0 2 lineto closepath clip fill}ifelse grestore}def 10 10 translate 600 600 scale 5 t showpage [1] https://en.wikipedia.org/wiki/Pinwheel_tiling https://en.wikipedia.org/wiki/Pinwheel_tiling [2] https://tromp.github.io/img/pinwheel.pdf https://tromp.github.io/img/pinwheel.pdf
- earleybird 5y ago
  Apologies for being off-topic and possibly absurd question - could the binary lc be considered a concatenative language?
  - tromp 5y ago
    (I would have expected this comment on https://news.ycombinator.com/item?id=29630293#29631288 https://news.ycombinator.com/item?id=29630293#29631288 instead:-) No, Blc is not a concatenative language. It uses application rather than concatenation to combine programs, and its semantics is not described in terms of stack operations (the blc seld-interpreter happens to use a stack though).
    - earleybird 5y ago
      I did see that comment but it was the postscript code you mentioned in your post which evoked concatenative question :-) I have, perhaps, a naïve internalisation of the reduction steps in something like Forth having the same shape as function application as an elimination step.
- mmcgaha 5y ago
  Lovely example! Beautiful postscript makes me warm and fuzzy inside.
kingcharles 5y ago
Thinking about SVG and EPS inside a PDF reminds me of a Turducken Ꙭ
anyfoo 5y ago
> without the need for expensive/complex/insecure libraries. Maybe because in the formats named, the image format is the expensive/complex/insecure libraries? I know that sounds a bit snappy, but I felt the author of TinyVG made a pretty good case for what they're aiming at: a simple vector format that does not come with a (or even multiple, in at least the case of PDF) Turing complete kitchen sinks.
- mmcgaha 5y ago
  You are 100% right. I will now throw out all of my work because despite being easy to generate, I could accidentally generate an image that does something bad (do you even halt bro?) and I don't want to do that. So I will throw out my simple well tested native solutions and replace them with a solution that needs to be compiled to a native solution.
  - anyfoo 5y ago
    The point is not the producer. The point is that complex formats require complex infrastructure (parsers, interpreters etc.) on the consumer of the format. And the issue with Turing complete kitchen sinks in your image format is not so much that it may not terminate (it is a problem, but a more minor one), but that such facilities are a) themselves often a vector, b) often a good way to leverage other vectors. Look at log4j for a recent example on what unwanted complexity does. For something matching the subject matter at hand here, look at the various image parsing attacks that have gained large notoriety. Now force multiply by having PostScript, an actual programming language, in the path.
    - mmcgaha 5y ago
      I am not really arguing because more image formats can only make my life easier but I have to wonder what is the point of this new format when I have to compile it into the existing complex-infrastructure format. If you tell me that we should add native support for this format, does that mean that we remove support for the complex-infrastructure formats or have we simply created a wider surface area for bugs? Finally, what makes this format preferable to the many existing format other than SVG?

ikskuh 5y ago

Then you should check out the TinyVG text format: (tvg 1 (32 32 1/1 u8888 reduced) ( (1 0 0) ) ( (fill_polygon (flat 0) ( (16 0) (32 32) (0 32) )) ) ) This draws you a tiny triangle. The only problem you'll get is when doing text, but for SVG: These wouldn't be portable anyways

shatteredgate 5y ago
Am I the only one who dislikes S-expressions and prefers XML or JSON or even YAML? The parenthesis are way too confusing when editing manually and the format doesn't have enough semantic information to always correctly parse into common structures in any language besides lisp. I enjoy writing lisp myself but I really think it is a mistake to use them for common formats everywhere that I've seen it tried.
- dnautics 5y ago
  seriously, it shouldn't be so hard to write a parser that compiles your favorite text format to TVG, or even to the lispy text format.
  - shatteredgate 5y ago
    IMO that defeats the purpose of using this format if you have to write things to compile to it. If you do that you might as well just compile to the binary format since you won't be editing your canonical representation anyway. I'd imagine with image formats you'd want to pick a format that is the easiest possible thing to parse and consume while not harming it's "editableness" and I don't think S-expressions fit that bill.
    - dnautics 5y ago
      Tvg is a binary format? It's not really human readable. Compiling to it is a natural thing to be doing.
      - shatteredgate 5y ago
        Sorry, was responding to the last part of your sentence.
- templix 5y ago
  You enjoy writing Lisp, but somehow find parenthesis way too confusing when editing manually? That's pretty hilarious. If you take the expression above and format it in any half-decent editor, it's pretty clear. YAML is a shitshow, JSON is yuck and let's not talk about XML.
  - shatteredgate 5y ago
    Yes, I enjoy lisp the language and its constructs but I don't enjoy the parenthesis or the syntax. What's hilarious about that? I'm sure you could list some aspects of lisp that you don't like if you have a lot of experience with it. >YAML is a shitshow, JSON is yuck and let's not talk about XML. My issue with S-expressions as a data exchange format is that they're actually just the worst aspects of all three of those combined. If you're frustrated by XML having really deep trees and only having strings and elements as datatypes, then S-expressions are just as bad, reliably they only really have strings and lists as datatypes and the trees tend to have even deeper nesting than XML. For JSON the formats are equivalent if you remove everything from JSON except lists and strings, so S-expressions are strictly a worse subset, they're just as yuck. YAML is bad because it's complex and badly specified but S-expressions are still worse of a shitshow because there is no spec. You just have to hope the format you used is compatible with your Lisp implementation. And yes this has caused me problems where using "read" on S-expressions with certain characters in them or in certain encodings completely breaks on some Lisp implementations. If you're using some other language that isn't Lisp and you're rolling your own parser then good luck having that be compatible with anything, most parsers I see just pick a random Lisp implementation and aim for compatibility with it which is still not reliable. The only good thing I can say about S-expressions is that they're quite easy to spit out from a bash script, but for this problem domain (vector graphics) there is an even easier option: use a very simple command-based format like postscript.
- hayley-patton 5y ago
  I'm not a fan of the usual uses of S-expressions in data formats, but for quite the opposite reasons. People seem to have a thing for making up new syntax, so you can't just throw a normal S-expression parser at the problem, and be done with it. For example, the wasm2ps reader [1] has to know how to read a comment in the WebAssembly text format. I decided to leave the project at handling integer instructions and control flow only, as there are other oddities like using a single atom for alignment and offsets in load and store instructions [2]. Some people I've talked to wished that people would stop inventing ad-hoc syntaxes, and just use S-expressions or something. Using S-expressions but adding more ad-hoc syntax gives you the worst of both options. While admittedly less of a problem for implementation, it is also annoying to see lists with dangling parens on their own lines, and symbols with underscores or camelCase in the names, once you are used to the normal way of formatting Lisp code. [1] https://github.com/no-defun-allowed/wasm2ps/blob/master/Code/reader.lisp https://github.com/no-defun-allowed/wasm2ps/blob/master/Code... [2] https://github.com/WebAssembly/spec/blob/master/interpreter/README.md#s-expression-syntax https://github.com/WebAssembly/spec/blob/master/interpreter/...
- mro_name 5y ago
  XML and YAML (including it's JSON representation) are complexity nightmares. But especially for xml, the tooling makes them appealing to use as e.g. distribution format with JS-less browser templating.
mro_name 5y ago
S-expressions, finally! Thanks!

deleted 5y ago

[deleted]

tromp 5y ago

Agreed; I was playing with pinwheel tilings [1] today and decided to make some pinwheel art [2] that fits in a signature: %!PS % -John Tromp http://tromp.github.io/ /t{dup 1 sub gsave dup 0 gt{[.4 .2 -.2 .4 .4 .2]concat t currentgray .8 mul .2 add setgray -1 1 scale t -1 2 translate t 1 -1 scale t[0 1 1 0 0 2]concat t pop}{0 moveto 1 0 lineto 0 2 lineto closepath clip fill}ifelse grestore}def 10 10 translate 600 600 scale 5 t showpage [1] https://en.wikipedia.org/wiki/Pinwheel_tiling https://en.wikipedia.org/wiki/Pinwheel_tiling [2] https://tromp.github.io/img/pinwheel.pdf https://tromp.github.io/img/pinwheel.pdf

earleybird 5y ago
Apologies for being off-topic and possibly absurd question - could the binary lc be considered a concatenative language?
- tromp 5y ago
  (I would have expected this comment on https://news.ycombinator.com/item?id=29630293#29631288 https://news.ycombinator.com/item?id=29630293#29631288 instead:-) No, Blc is not a concatenative language. It uses application rather than concatenation to combine programs, and its semantics is not described in terms of stack operations (the blc seld-interpreter happens to use a stack though).
  - earleybird 5y ago
    I did see that comment but it was the postscript code you mentioned in your post which evoked concatenative question :-) I have, perhaps, a naïve internalisation of the reduction steps in something like Forth having the same shape as function application as an elimination step.
mmcgaha 5y ago
Lovely example! Beautiful postscript makes me warm and fuzzy inside.

kingcharles 5y ago

Thinking about SVG and EPS inside a PDF reminds me of a Turducken Ꙭ

anyfoo 5y ago

> without the need for expensive/complex/insecure libraries. Maybe because in the formats named, the image format is the expensive/complex/insecure libraries? I know that sounds a bit snappy, but I felt the author of TinyVG made a pretty good case for what they're aiming at: a simple vector format that does not come with a (or even multiple, in at least the case of PDF) Turing complete kitchen sinks.

mmcgaha 5y ago
You are 100% right. I will now throw out all of my work because despite being easy to generate, I could accidentally generate an image that does something bad (do you even halt bro?) and I don't want to do that. So I will throw out my simple well tested native solutions and replace them with a solution that needs to be compiled to a native solution.
- anyfoo 5y ago
  The point is not the producer. The point is that complex formats require complex infrastructure (parsers, interpreters etc.) on the consumer of the format. And the issue with Turing complete kitchen sinks in your image format is not so much that it may not terminate (it is a problem, but a more minor one), but that such facilities are a) themselves often a vector, b) often a good way to leverage other vectors. Look at log4j for a recent example on what unwanted complexity does. For something matching the subject matter at hand here, look at the various image parsing attacks that have gained large notoriety. Now force multiply by having PostScript, an actual programming language, in the path.
  - mmcgaha 5y ago
    I am not really arguing because more image formats can only make my life easier but I have to wonder what is the point of this new format when I have to compile it into the existing complex-infrastructure format. If you tell me that we should add native support for this format, does that mean that we remove support for the complex-infrastructure formats or have we simply created a wider surface area for bugs? Finally, what makes this format preferable to the many existing format other than SVG?