Hacker News Reader

Comment by mmcgaha | Hacker News Reader

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.

View on HN

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

[2] https://tromp.github.io/img/pinwheel.pdf

Lovely example! Beautiful postscript makes me warm and fuzzy inside.

Apologies for being off-topic and possibly absurd question - could the binary lc be considered a concatenative language?

(I would have expected this comment on 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).

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.

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

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.

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.

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.

Tvg is a binary format? It's not really human readable. Compiling to it is a natural thing to be doing.

Sorry, was responding to the last part of your sentence.

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.

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.

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... [2] https://github.com/WebAssembly/spec/blob/master/interpreter/...

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.

S-expressions, finally! Thanks!

> 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.

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.

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.

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?

It's a bit of a trade-off. An existing browser for example will likely just add the format, effectively creating more attack surface, yes. A new product however can choose to only implement the simpler one (and if no features of the more complex one are needed, will likely want to do so for a multitude of reasons).

Over time, the old format may potentially be removed if it falls in disfavor, or at least only be accepted in more and more restricted contexts, but this works better in closed systems of course. I just finished excising a complex format in favor of a much simpler one, and since it was internal to the organization cutting out the old one did not cause anyone problems. For browsers, I don't know. Deprecating Java Applets and Flash seems to have worked, but those are maybe "heavier" examples than SVG.

As for comparison to existing vector formats, I don't have the necessary domain knowledge there.

The recent NSO exploit using the PDF JBIG2 codec was also a hilarious example of abusing image formats: https://news.ycombinator.com/item?id=29568625

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

Reply on news.ycombinator.com