Javier Múgica javier at digi21.eu
Tue Oct 20 11:00:35 CEST 2009

Recently the suggestion has been posted to the luatex bug/fature
tracker that the horizontal boxes remember where they come from, for
postprocessing purposes. This reminds me about one of my yet unposted
suggestions, because it also has to do with the horizontal boxes

It could be useful if once an hbox is packed it creates two profiles,
one for its upper border and one for its lower one. By the profile I
mean the boder that could be seen if the boxes and rules where black
rectangles. These will be "teeth-like" profiles, lower-teeth-like for
the upper profile, upper-teeth for the lower one. It would consist of
an array (i.e., not a linked list) recording that at distance 'x' the
height raises to 'h' (or, for the lower profile, the depth goes down
to 'd') and it lasts for 'width', for all the values of x where the
height of the contents changes. When there is a hole, like any glue,
the value for 'h' could be -\maxdimen, may be, these are just details.

While from LuaTeX we may give the standard answer "you can do that
with a callback by traversing the nodes of the box after it has been
packed", I don't think it is actually like that: The computation
involved is a lengthy one, having to dynamicaly build and modify the
table as later boxes or rules overlap with previous ones (for we all
now that the order of the intems inside a packed box need not be their
x-order), and taking care to free the tables as they are no longer
needed, a task that is better done in C. Also because it is a too low
level feature, being just something that TeX does and Lua exposes to
the programer via two tables, that will allways be associated with a
packed hlist, in addition to the table representing its contents.

It could be useful for:

-- Taking into account the position of deep descenders in one line and
high ascenders in the next one not to innecessarily overspace the two
likes. This is the same concept as the kerning between two caracters;
i.e., do not just place the boxes adjacent to one another, but take
into account the contexts of the boxes being put together to produce a
finer spacing, but changing characters for lines and horizonal for
vertical.
The way I would actualy do this is, for every teeth of the upper
profile of the lower line, to take into accound the descenders of the
upper line just within \keepfreedistance (say) distance. If I'd set
\keepfreedistance=\maxdimen I'd get TeX's current behavour.

-- Writing a smart line braking algorithm that adds penalties for "rivers".

--Easy improvement of correct math placement of atoms.
that originated by a user who noticed that the ^2 after \sin was
higher than after \cos. The reason is the dot of the i of \sin. If the
box carried its profiles with it, the algorithm for computing the
height of the superscripts and depth of subscripts could take into
account just the profile back to 0.5 em's distance, say, instead of
the whole box as now (another primitive?)

--Possibly many others that would become apparent once the feature
were there and people started using it.

The reason for a random access array instead of a sequenced access
list is clear once we think about examples (for instance, seeking
items with values of 'x' within a certain range) and, specially, on
the way it would be programmed in C. In case this is ever impemented,
reserving memory for n elements, where n is the number of nodes in the
hlist, would waste on average little space.