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 storing more information for purposes of postprocessing. 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. We had a year or so ago in the Spanish TeX list a discusion about this 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.