Detail graphic 'drawing' support

[josephwright]

Currently, the manual gives no information on what type of 'drawing' support is available via \special. Other backends offer some approach to creating basic constructs such as lines, paths, fills, etc.

[ruckertm]

In the current version 2.0 HINT file format there is no support for drawing primitives.
There are currently no plans to offer drawing primitives. Drawings should be included as graphics.
The supported graphics file formats (JPG and PNG) are not optimal for vector graphics. The support of SVG files (or some subset of SVG) is under consideration. For example the freetype
library that is included in the HINT viewers supports some form of SVG that could be made
available.

[josephwright]

SVG support, if it also includes the necessary steps to pick up the co-ordinate system, would allow 'drawing' from within the TeX run. I guess from my POV, something very similar to the dvisvgm specials would be good:

Parameter text may also contain the expressions {?x}, {?y}, {?color}, and {?matrix} that expand to the current x or y coordinate, the current color, and current transformation matrix, respectively. Character sequence {?nl} expands to a newline character. Finally, constructions of the form {?(expr)} enable the evaluation of mathematical expressions which may consist of basic arithmetic operations including modulo. Like above, the variables x and y represent the current coordinates.

(I've only used {?x},{?y} and {?nl} to date, but I can see that {?(expr)} and {?matrix} are useful: no so sure about {?color}.)

Note that as well as 'explicit' graphics (TikZ, etc.), the drawing primitives in other engines are used for things like decorating tables, fancy-looking boxes, etc., i.e. content that can't really be covered by creating a graphic externally and including it.

[ruckertm]

I am not sure what "drawing from within the TeX run" means. Note that hitex postpones running the page builder and breaking paragraphs into lines until displaying the HINT file in the viewer and that the viewer does NOT contain a TeX interpreter. As a consequence, while hitex is running there is absolutely no information available about positions on the page (except that \eject will cause a new page (of unknown size) to start); and while hintview is running there is not a single TeX macros around that could be expanded.

[josephwright]

@ruckertm I am thinking of tools such as TikZ (or PSTricks). Under the hood, TikZ produces a series of \special instructions which are 'finalised'. For example, with input

\documentclass[border=10pt]{standalone}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
  \pgfpathmoveto{\pgfpoint{0cm}{0cm}}
  \pgfpathlineto{\pgfpoint{1cm}{1cm}}
  \pgfpatharcaxes{0}{90}{\pgfpoint{2cm}{5mm}}{\pgfpoint{0cm}{1cm}}
  \pgfusepath{draw}
\end{tikzpicture}
\end{document}

the output contains*

.....\hbox(0.0+0.0)x0.0, shifted -0.2
......\pdfsave
......\pdfliteral{0.3985 w}
......\pdfcolorstack 0 push {0 g 0 G}
......\pdfliteral{0 J}
......\pdfliteral{0 j}
......\pdfliteral{10 M}
......\pdfliteral{[] 0 d}
......\hbox(0.0+0.0)x0.0
.......\pdfliteral{0 0 m}
.......\pdfliteral{28.34647 28.34647 l}
.......\pdfliteral{28.34647 44.00177 2.96419 50.34735 -28.34647 42.51968 c}
.......\pdfliteral{S}
.......\pdfcolorstack 0 push {0 g 1.0 0.0 0.0 RG}
.......\pdfliteral{0 0 m}
.......\pdfliteral{1613.06963 1209.80222 l}
.......\pdfliteral{S}
.......\pdfcolorstack 0 pop
......\pdfrestore
......\pdfcolorstack 0 pop

when using pdfTeX. (* The actual output here is from l3draw as it avoids a few oddities that pgf generates, but the idea is the same.)

As you can see, this is a collection of PDF primitives inside a box of fixed size.

[ruckertm]

If a viewer has a pdf interpreter anyway, adding pdf code to the TeX output file is not an issue. HINT viewers do neither have/require a PS nor a pdf interpreter. Specifying such a mini-pdf language would be an (unnecessary) burden to any HINT viewer. So I look for an existing graphics language (SVG ?) and adding an existing interpreter for it to the HINT viewer. The burden is then on the hitex side, because it would need to translate something like \pgfpatharcaxes ... into e.g. SVG.
I am not likely to implement such an extension any time soon because there are other more urgend things to implment, for example UTF8 input and UTF8 fonts.

[davidcarlisle]

couldn't you provide a \special that basically just pushed a path to openGL? that is line rather than bezier curve based but doing the extra arithmetic wouldn't be too much I think, something like https://www.geeksforgeeks.org/bezier-curves-in-opengl/ ?

[ruckertm]

Yes I could extend hitex by implementing \HINTline and \HINTbezier and a couple more primitives, but where would it end. I could extend it by implementing \HINTdraw which would write a string in some syntax to the output file and leave it to the viewer to parse that string and do something with it. But in both cases I would implement some mini-language for drawing and an interpreter for it mapping the language to OpenGL.
But there are already nice graphic languages in existence and my time is quite limited. So I might take librsvg and libcairo, link them to the viewer, and enable (limited) SVG1.1 files as graphic input. This would be a standard extension. In a second step, I would extend hitex
by some translator that would be able to generate an svg image on the fly from a tikzpicture.
This will definitely not do this before TL 2025. If someone wants to do this, the sources for the viewers are in the repository, and I am more than happy to give any support needed.

[josephwright]

If a viewer has a pdf interpreter anyway, adding pdf code to the TeX output file is not an issue. HINT viewers do neither have/require a PS nor a pdf interpreter.

I should have been clearer: I was highlighting an example of 'TeX input to backend output'. For pdfTeX, that's PDF, for classical TeX it's PostScript, for HiTeX presumably it would be SVG. We already have code for SVG production with dvisvgm, so that would be entirely suitable.