Pikchr integration

[akavel]

FWIW, https://pikchr.org is a small CLI application in C that is an evolution by SQLite author(s) of the venerable PIC by Brian Kernighan. It allows drawing SVG diagrams from a markup language. The following script allows to roughly reproduce a diagram mentioned in a comment discussing TikZ integration:

"start" big
arrow right 50%
Z0: circle "z0" big italic
move go 300% heading 60 from Z0.c
Z1: circle "z1" big italic with .c at previous.end
move go 300% heading 120 from Z0.c
Z2: circle "z2" big italic with .c at previous.end
move go 300% heading 60 from Z2.c
Ze: circle "ze" big italic with .c at previous.end
arrow from Z0 to Z1 chop "1" big above
arrow from Z0 to Z2 chop "0" big below
arrow from Z1 to Ze chop "1" big above
arrow from Ze to Z2 chop "0" big below
spline from Z1.c go .75 heading 190 then to Z2.c chop -> "0  " big rjust
spline from Z2.c go .75 heading 10 then to Z1.c chop -> "  1" big ljust

define loop {
spline from $1 go \
.4 heading (73 $2) then \
.15 heading (90 $2) then \
.11 heading (160 $2) then \
.11 heading (200 $2) then \
.15 heading (270 $2) then \
to $1 chop ->
}

loop(Ze)
dot invis at .1 right of 4th vertex of last spline "1" big
loop(Z2,+90)
dot invis at .1 below 4th vertex of last spline "0" big

circle at Ze.c radius 90%

which results in the following SVG image:

Notable differences to the TikZ-built diagram:

• no subscripts; in the original PIC this was done with help from an additional EQN preprocessor AFAIU (see the end of the section 13 of the PIC manual); hopefully, given that this is SVG, SILE could be used here somehow (this could also help to match the font, possibly);
• the "loops" below "z2" and to the right of "ze" are uglier; I'm not sure if there's an easy way to get something prettier, but also I'm just starting to learn pikchr.

See also https://kroki.io for some other interesting diagramming tools.

(This issue is extracted from a comment in a thread about TikZ integration. See the thread for some earlier discussion.)

[alerque]

Just a comment on progress here, this really does look like a simple package to do, but it will depend on an external resource (the pikchr binary or a compiled library version). We could bundle this in SILE, but my plan is to make separate packages for things that require external software. This makes testing a lot easier to organize.

Support for creating packages like this as LuaRock dependencies will land in v0.14.0, at which point creating this package should become viable.

[Omikhleia]

On the not-so-simple side of things, if it does pikchr to SVG and we stream that to our existing SVG support, the latter doesn't support text...

(As an aside note, such diagrams are kind of a niche market, so are probably best having separately indeed.)

Maybe users are conflating two things here.

• There is an existing way to support any external file to "image" conversion, via the *converters" package for instance (which extends the \img and include commands by defaut. \svg doesn't subscribe to it "natively", but that could be considered, perhaps, the documentation actually hints towards it, though rather the other way round, as a way to skip our existing SVG support).
• The other thing is a way to pass an "external" raw content from within a SILE document. Addressing this only makes it easier to "embed" stuff à la Markdown, but however it's done via something like Add inline-escaping in SIL-language #1347 or different, once the hooks are in place, the issue at stakes are quite the same.

[ctrlcctrlv]

Why this and not DOT

[Omikhleia]

Why this and not DOT

Tikz / Kroki / Pikchr / PlantUML / Lilypond -- and whatever other formats: personally I'd have the same answer. It's already doable to invoke a converter to process an external file with an external program. With the above-mentioned escaping, it would also be doable from within raw content in a SILE document, in a generic way, would this be felt cool. Then all those eventually boil down to the same thing -- invoking the external program and grabbing the output back. One can even call inkscape or IM to convert to export as PNG or PDF, avoiding our SVG limitations. People can already write this type of packages.

[Omikhleia]

If people need a bit of bootstrapping here... Let's even show how easy it is... to support, say, dot.

Attached a test file and a supporting package

• the package needs Add inline-escaping in SIL-language #1347 (easy, checkout the corresponding branch in a local SILE 0.13 fork...) and should work on SILE 0.13 (untested, as I run it via docker currently, and realized I wouldn't have dot there anyway... But the "boilerplate" code should be quite close).
• It works on 0.12.5 with the above raw escaping proposal back-ported (easy, checkout my own omikhleia-sile-packages repo 🤡 )

xformat.zip

It's around 50 lines of code only (...a bit less if one removes the compatibility stuff, albeit one should also handle the temporary file in a better way -- that's basic Lua, though -- so all in all, it's small...)

With that, one can do

• \img[src=some.dot, width=..., height=...]
• \raw[type=dot, width=..., height=...]{some dot commands}

Proof:

[ctrlcctrlv]

Interesting! Is SILE.registerRawHandler new?

[Omikhleia]

Interesting! Is SILE.registerRawHandler new?

That's the proposal from that PR #1347 I kept mentioning on an on above... Might not make it with that name or with the exact same syntax, but the idea is there for discussion: expose a raw escape command, and a registration API for packages to add new handlers.

[Omikhleia]

Actually relates to #1092

[Omikhleia]

Rejected (Wontfix): It does not seem relevant to introduce dependency of that kind in the core distribution.
Maintainers have settled on keeping the core free, as much as they can, of packages that require external dependencies.

Not that this is therefore out of scope for core SILE, but not necessarily out of scope for the SILE ecosystem: Anything that requires compiling or using external dependencies belongs in a 3rd-party package, not to not to the core distribution.

We already have the tooling available for that and anybody can spin up a 3rd-party package. If SILE needs to implement some API to make it more usable, we can look into that.

For future reference, at this date here are examples of 3rd-party packages that use external tooling:

• printoptions.sile (GraphicMagick and Ghostscript )
• embedders.sile (Graphviz DOT and Lilypond)

The core converters package is also an interesting resource to consider.