Hacker News Reader

Comment by enriquto | Hacker News Reader

Since everybody talks about the format for figures, I feel the need to mention the .fig format [0] that was made exactly for that use case (human-editable textual description of simple line figures). It is also the native file format of the venerable Xfig figure editor [1].

[0] http://linux.math.tifr.res.in/manuals/html/xfig/fig-format.h...

[1] https://en.wikipedia.org/wiki/Xfig

View on HN

Other minimalist diagram formats include gremlin[1] and pic[2].

[1]: https://man7.org/linux/man-pages/man1/grn.1.html

[2]: https://www.man7.org/linux/man-pages/man1/pic.1.html

And pic was slightly extended and modernized by the SQLite author(s?) to become https://pikchr.org, for use in SQLite docs. (All the SQL syntax diagrams are drawn with pikchr, IIUC.)

If you want to embed pikchr SVGs in your statically generated HTML content, you may find https://soupault.app/ useful.

(Not affiliated with either, fan of both.)

Thank you for the link to pikchr--anything by the SQLite folks is something to check out.

Not having a diamond object-class for decision seems to be a large miss. [0] Also, unlike Mermaid [1], three downward arrows to boxes aren't spaced from one another, the boxes wind up overwriting one another. This gives pikchr a procedural/syntactical feel rather than an object/semantic one.

0. https://pikchr.org/home/doc/trunk/doc/grammar.md

1. https://github.blog/2022-02-14-include-diagrams-markdown-fil...

pikchr live demo: https://pikchr.org/home/pikchrshow

Mermaid live demo: https://mermaid-js.github.io/mermaid-live-editor/

  > for use in SQLite docs

Examples of output, because I too was curious:

https://www.sqlite.org/lang_createtable.html

https://www.sqlite.org/atomiccommit.html

> https://www.sqlite.org/lang_createtable.html

Here's what the source looks like: https://www2.sqlite.org/cgi/docsrc/blame?filename=art/syntax...

> https://www.sqlite.org/atomiccommit.html

These are actually just GIFs and it's unclear how they're generated. https://www2.sqlite.org/cgi/docsrc/file?name=images/ac/commi...

I made a few pikchr diagrams and liked the experience, though it would be good if there was a lossless WSYWIG editor that could create and edit them for quick and dirty creation.

There was a Changelog podcast episode with Richard Hipp (sqlite author) where he threw out the great idea that it would be nice if there were renderers in popular markdown engines that could display inline pikchr blocks. https://changelog.com/podcast/454

More examples of what is possible are on the linked pikchr page: https://pikchr.org/home/doc/trunk/doc/examples.md

You can also use a pandoc filter to turn code blocks with Pikchr code into inline images.

https://code.jboy.space/pikchr-filter/

The fig format isn’t very human-editable. It has a few nice features that SVG doesn’t (e.g. concise pattern and arrow head styling, which have to be done separately and more explicitly in SVG, though on the other hand SVG gives you more flexibility), but its actual syntax is bluntly horrible. It’s mostly just a sequence of space-separated numbers, where some are enumerated values, some integer coordinates, some float coordinates, some integer sizes, some still other stuff; where some values change the syntax for subsequent lines; and there are two different sets of units intermingled, one defined in the document and the other in 80ths of an inch (… though it might just get thinned to 160ths of an inch, and is also defined as one screen pixel, whatever that means, given that it came from before the high-DPI era); and…

Oh, let’s just take an example, a small excerpt from one of the diagrams at https://www.southampton.ac.uk/~dales/teaching/xfig/xfig.html:

  2 1 0 3 -1 7 0 0 -1 0.000 0 0 -1 1 0 2
   1 0 3.00 180.00 360.00
    11745 6750 9450 6750

Just to explain the first line: 2: polyline or similar. 1: actually polyline. 0: solid line. 3: line is 3⁄80in thick. -1: default pen colour. 0: white fill (… but ignored because of “no fill” later). 0: depth (z-index). 0: unused. -1: no fill. 0.000: to do with dashes (not used because of “solid line” earlier). 0: mitre join. 0: butt cap. -1: radius (not used as this is an actual polyline). 1: forward arrow (so the next line must now define the arrow style). 0: no backward arrow. 2: two points (so on the third line it expects four numbers—x₁, y₁, x₂, y₂).

An inexact SVG paraphrase (most inexact because of the two different types of units, which SVG doesn’t fully or consistently have—the closest is vector-effect="non-scaling-vector"; also I will note that a number of the properties are the defaults and would thus be likely to be omitted in real life):

  <polyline stroke-dasharray="0" stroke-width="3px" stroke="currentColor" fill="white" stroke-linejoin="mitre" stroke-linecap="butt" marker-end="url(#arrow)"
    points="11745,6750 9450,6750"/>
  <marker id="arrow" orient="auto-start-reverse" markerWidth="180" markerHeight="360" markerUnits="userSpaceOnUse" viewBox="-2 -1 2 2"><path d="M0 0l-2 1V-1z" stroke="context-stroke" fill="none" stroke-width="3px"/></marker>

This is vastly more human-editable. I write SVG by hand regularly, and edit tool-assisted SVG by hand even more regularly. I could not do the same for Fig in a regular text editor—I’d want tooling that labelled every field and enumeration value.

Reply on news.ycombinator.com