Support fo rotation, scaling and clipping of content

[josephwright]

Linked to #5 in some ways, there are currently no details of how to scale/rotate content or to clip it. This can be done in some backends using dedicated support, and in others using general 'drawing' primitives (e.g. in pdfTeX where PDF provides such ideas). Although absolute graphics scale in HINT is not of the same importance as for other output formats, the relative sizes of content could well be important.

[ruckertm]

The current version 2.0 of the HINT file format does not support rotation or clipping of images. Clipping and rotation might be added to the HINT file format at a later time. I personally think, however, that clipping and/or rotation should be done with an image processing program before or while running TeX.
There is support for scaling images: The width and/or height of an image can depend on \hsize and/or \vsize and hence the image will scale when it gets displayed to respect the current value of \hsize and/or \vsize. For an example see the file image.tex/image.hnt in the HINT/examples directory It shows two images, one with a "fixed" size 48pt x 48pt wide (as stored in the image file) that will scale together with the font size and onw that is 0.45\hsize wide and 0.9\vsize high (at a maximum) that will scale together with the available window size.

[josephwright]

Note that scaling, etc., doesn't just apply to images: you might for example want to do that with a box of arbitrary content (think for example a 'zoomed in' blowup, or a logo-like rotation of text).

[ruckertm]

OK I see the point for rotating text. For example too make vertical column headings for narrow columns with lengthy headings. An then it is probably the same effort implementing the rotation of arbitrary boxes. Rotating boxes in the viewer is simple. hitex would just need to compute the rotated dimensions of a box and continue as usual.
Scaling of text can be done with changing the font size, but if it is convenient, a rotated box can easily accomodate a scalefactor as well.

[davidcarlisle]

hitex would just need to compute the rotated dimensions of a box and continue as usual.

on rotation, the macro layer already needs to do the trig and leave the actual space, so in practice it is enough if the back end just rotates the box content.

So for latex+dvips for example, tex just sets a (typcally \rlap zero sized box) as usual. The rotation \special just locally changes the coordinate matrix with no feedback to the tex engine of the transformed coordinates

so in

\rotatebox{30}{hello world}

latex will already work out sin 30 and leave a box of the right size, it just needs a \special or hitex primitive to make the text rotate in the view.

[ruckertm]

Asume a \vbox with a \par in it. hitex might not know the \hsize inside the box and because it will postpone the linebreaking, it will not know the height, the depth nor the width of the box. So computing sin 30 (how does LaTeX compute sin 30 ?) will not help much. Hitex has three kinds of boxes: normal boxes, boxes where it knows the natural dimensions and the viewer needs to set the glue ratio, and boxes where it knows nothing and the viewer has to do all the computations. Still rotating these boxes (and computing sin 30) is not a big problem for the viewer because in the viewer the line breaking is done anyway and the dimensions of the box are known.
It would be easy to implement \HINTrotate followed by a that could come before the specification similar to \raise, \lower, \moveleft or \moveright. It would rotate the box content and compute the new height, depth, and width, keeping the reference point of the box on the baseline. A \raise or \lower (\moveleft or \moveright respectively) could then be applied after rotation to shift the new box.

Would such a \HINTrotate primitive would work well with LaTeX?

It's too late to add this in TL 2023, but it certainly could go into TL 2024 and could be available in the repository in a few month.

[davidcarlisle]

Would such a \HINTrotate primitive would work well with LaTeX?

It wouldn't work the same as other rotation back ends but I guess it will be workable (and probably necessary if you want to support delayed box dimensions).

In general it's not clear how delayed box dimensions should work to be honest. On the main vertical list I can see it works well,
but inside (say) an alignment, latex pretty much assumes it knows box sizes so it can lay out the various boxes. So I'm not sure how a rotated box will work but mostly because I'm not sure how an unrotated box works in latex for your third type where the dimensions are not known until the viewer.

If you experiment with some primitives in a branch here, we can certainly experiment with matching latex code, and hopefully have a plan in place for tl2024, certainly no need to rush something in to tl2023.

[ruckertm]

Alignments with unknown box dimensions is still work in progress. But rotation is not an extra complication here. The HINT format specifies node types for such alignments with delayed layout but this is largely untested (still on my todo list).
A branch in git for rotation is a good idea. I will start it soon.