Add TikZ support package

[alerque]

This was mentioned on the Wiki but an issue was never opened, so here goes. For me the need for this is greatly reduced by having SVG support, but it would still be nice to have for bringing documents over from TeX and would probably still be a huge boon for some markets.

Implement a package that generates graphs using TikZ and embeds the output. Since there is a Lua interface this should be easier than (but conceptually similar) to how MathJax (#220) and Lilypond (#435) support might work. It's probably also worth cross-linking my idea for pre-processing raster images with ImageMagick (#436).

[akavel]

(Side note: dpic uses different syntax than TikZ and is not written in Lua, but fills a similar niche (see e.g. page 8 of dpicdoc.pdf), is BSD-licensed and written in C. This, or the GNU pic installed IIUC on most Linuxes as part of groff package, could possibly be used already to render PDF diagrams in SILE based on a language similar in spirit to TikZ.)

[baubleb]

I want to add that it is not just graphs with axis and plots that would be useful to be able to do, but other diagramming such as state machines and transition graphs for example. Underneath graphics primitives abstracted up to markup environments for special diagramming.

Then we could create environments such like

\begin{statemachine}
%statemachine markup here
\end{statemachine}

Then render something like this

I could just embed them as images using other languages and tools, but then labelling and fonts would need to also match the document, and also the issue of referencing in specialised contents tables rather than "Table of Figures".

[alerque]

If you have a tool that takes markup in and spits the plots you want out it is pretty trivial to write a SILE package to deal with them. Passing contextual information like the current document font is just a little more work. If you have a language/tool you want to implement feel free to open an issue for it and I'll get you started. We well have to resolve #1092, so it might look like this:

\script[src=packages/statemachine]
\begin[handler=statemachine]{raw}
% state machine markup here
\end{raw}

... or you may need to specify on the CLI what handlers you'll use in advance, something like:

$ sile --raw statemachine foo.sil

Either way it is quite doable and should be easy to get rolling.

TikZ in the other hand is a special snowflake because it's technically an input language with deep tries to LaTeX itself and no stand alone handler that generates outputs. It expects to reach deep into TeX internals. As such it's not really in the same category as, say, some stand alone tool that converted UML markup to SVG.

(Lilypond is also a special snowflake because it doesn't output one graphic, the expectation is that it would generate many graphics such as one per bar, then let the typsetter sort out placing them perhaps across page breaks etc.)

[baubleb]

\begin[handler=statemachine]{raw}
% state machine markup here
\end{raw}

Handler (like the notion and terms callback, delegate and function pointer etc) is a programattic notion and terminology, imo that is leaking programmatic abstraction up into typesetting markup abstractions.

The risk there is typesetting markup becomes more programming than descriptive marking up and then the markup loses clarity of purpose.

[Omikhleia]

Handler (like the notion and terms callback, delegate and function pointer etc) is a programattic notion and terminology, imo that is leaking programmatic abstraction up into typesetting markup abstractions.

You should have that comment on #1347 - There might be a good name somewhere between my inline[format=<MIME type>] there and alerque's raw[handler=<name> here 😼

[alerque]

Good point on the programming vs. markup terminology.

[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 the diagram mentioned above:

"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:

• no subscripts; in the original PIC this was done with help from an additional EQN preprocessor AFAIU; 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.

[alerque]

@akavel That looks quite promising, especially because with SVG output it should be dead simple to integrate into SILE. Would you mind opening your above message as a new issue (since this isn't about TikZ)? I'd like to play around with implementing it, both because I have at least one immediate use for it as a small test and because I think it would make a good proof of concept for how to write a package for this sort of thing.

[akavel]

@alerque Done (#1434). I'd be super interested especially if you would manage to add the support for subscripts/math/fonts/... through some kind of "SILE re-processing of SVG text"!

[Omikhleia]

Rejected (Wontfix): It does not seem relevant to introduce a dependency of that kind in the core distribution. Tikz is a huge beast 😸

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.