[Dev-luatex] Four suggestions

Javier Múgica de Rivera javier at digi21.net
Mon Sep 3 18:52:10 CEST 2007

    Yes, I do have red that at this stage suggestions will not really be 
usefull, but the fact that what would be my top suggestion wasn't 
present in the manual from April but already appeared in the June one 
made me think that my ideas weren't bad at all and could actually be 
usefull (I was thinking about the dinamic allocation of memory).

    1. Currently, when TeX computes the space between two lines it looks 
at the depth of the line above and the height of the line below. It may 
happen, specially if math is being inserted inline, that the character 
that causes the maximum depth in the above line is far away from the one 
that accounts for the maximum height in the line below, causing TeX to 
insert unnecessary white space. I think it could be a good idea to 
compute the skip between lines taking into account the actual position 
of characters and boxes.
    Given that a high ascendent looks too close to a deep descendent not 
only in the case when the last is on top of the former, but also when it 
is near it, a primitive parameter (length) like \charsurround could be 
    Before thinking on how this could be implemented, there is a very 
important side effect, that deserves attention on its own:

    Look at §109 of TeX: The Program:

    "When TeX 'packages' a list into a box, it needs to calculate the 
proportionality ratio by which the glue inside the box should stretch or 
shrink. **This calculation does not affect TeX's decision making**, so 
the precise details of rounding, etc., in the glue calculation are not 
of critical importance for the consistency of results on different 

    If my idea for the computation of the line skip is to be 
implemented, this assertion is not valid any more. Whether it will be 
implemented or not, now that LuaTeX provides access to the internal 
structures of TeX it is very likely that the assertion is not valid
anyway, or will not be in the near future. Therefore, I think that §109 
should be rewritten to deal with glue ratios using fixed-point arithmetic.

    As for the implementation of my idea for the line skip, this is what 
I thought: TeX has to compute the minimum separation between two lines: 
the above-line and the below-line. It would first generate a profile for 
each line: a tooth-like bottom profile for the above-line, and a top 
profile for the below-line. Then it could operate fast on those two 
profiles, and thus compute efficiently the minimum separation that is 
present between the lines, taking into account \charsurround.

    *        *       *

    2. Other idea I would like to propose is making \phantom a 
primitive. The idea behind \phantom is that it is as if you actually 
typed the material, but it finally does not show up, as if it were 
printed with invisible ink. The current definition of \phantom does not 
fulfil this idea. In particular, it generates Ord items in math. This is 
specially anoying for delimiters. It has some other drawbacks; it kills 
the stretching and shrinking of glue, so the "phantommed" material may 
not actually occupy the same space as real material, possibly in a line 
just above or below, resulting in misalignments.
    Now that nodes can have attributes, maybe could phantomness be one 
of them.

    *       *       *

    3. Yet another thing (I sent this some time ago to the pdfdtex list, 
but because I didn't know about this list and thought that the other was 
the one discussing the extensions to TeX. This is the place where this 
message belongs to. Sorry to those who will read it twice): An 
intermediate scope of assignment, between \local and \global. The idea 
is that the assignment be still in force in the innermost group that 
encloses that which we are in. For example, if the primitive is to be 
named \regional,


the two first \show\foo would display 'c', while the third would display 

    By now, instead of thinking "how?" you are probably thinking "why?". 
I found this very useful in tree scenarios. The first one is to write 
function-like macros. Suppose that we want a macro to perform some 
operations and return the value, then we could do

    \def\myfunction{{%   notice the aditional grouping
    %Perform some operations, possibly long. Everyting is local, so we 
may use scratch registers
    %and the control sequences we wish, provided we are sure that the 
output routine will not be invoked.
    %Now, return the vaule
    \regional\myregister\myregister    %Or \regional\myregister\dimen0, 
or \regional\foo{whatever}, or...

  Another situation is inside alignments. It often happens, or at least 
it often happens to me, that we want to change the behavour of \\ for 
the current row we are in; or for the entire alignment but still taking 
advantage of other programmed features (for examlple, suppose we have 
\begin{matrix} ... \end{matrix}, or \begin{mymatrix} ... \end{mymatrix}, 
or \mytable{ ... }, and we want to change just \\,).
    Since TeX puts each alignment entry inside a group by itself, it is 
impossible to perform such changes locally, since right after 
\begin{matrix} or \mytable{, we are already at the first entry. It will 
not usually be solvable with aftergroup, and it is likely that we cannot 
do the cange before entering the table, because the macro may itself 
redefine \\.
    The third situation, and it may be the one that arises more often, 
is when passign some information to the group enclosign the one we are 
in. It is currently solved by using global (e.g., \global\st at rredtrue), 
but that is not save.

    *        *        *

    4. Just one more. The todo list includes  "A way to (re?)calculate 
the width of a \vbox, taking only the natural width of the included 
items into account".  What about the depth of a \hbox where items have 
been raised? Try
  \setbox0\hbox{\raise 10pt\hbox{a}}. \showthe\dp0

You will get \dp0=0pt. It is specially anoying when raising a box that 
would otherwise be the one causing the maximum depth of the enclosing 
box (for example, denominators).

Javier A.

More information about the dev-luatex mailing list