[Dev-luatex] Four suggestions

Hans Hagen pragma at wxs.nl
Mon Sep 3 20:57:55 CEST 2007

Javier Múgica de Rivera wrote:
>     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).

it's not a matter of 'useful' but more one of priorities .. the next 
couple of years luatex dev will focus on core features and especially 
opening up the engine; once that part is stable it's time to start 
thinking of adding fucntionality but even then, chances are good that it 
will be helper functions so that one can use lua coee to implement 
his/her solutions

so, feel free to post ideas, if only because then they're archived somehow

>     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 
> added.
>     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 
> computers."
>     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.
>     *        *       *

you can do that by using callbacks that process the node list

>     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.
>     *       *       *

more control over math is definitely on the agenda but first we need to 
open up the math machinery (later this year/ beginning next year)

btw, luatex will not define attributes itself; it's just a mechanism to 
let information travel along with nodes; indeed you can reserve an 
attribute (one of many) for phantomness but you need to write node 
manipulation code to do something useful with it

>     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,
> \def\foo{a}{\def\foo{b}{\regional\def\foo{c}\show\foo}\show\foo}\show\foo
> the two first \show\foo would display 'c', while the third would display 
> 'a'.
>     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...
>     }%
>     }

for a long time we've been thinking of a feature like that, where 
results can be carried over one (or more groups); it has a low priority 
but it's definitely on the agenda (has even been prototyped by taco a 
couple of years ago)

>   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.
>     *        *        *

alligments ... as with math we need more control there too

>     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).

the width calculation mentioned in the todo concerns the natural width 
of the longest line in a (often ragged) paragraph

concerning your raise example ... i would not expect a (positive or 
negative) depth there anyway since that's how raise is supposed to work

taking the skyline of a line into account is one of the things that node 
list processing should make possible; once we have more control over 
line breaks (for that the hyphenation engine will be opened up) these 
things can be investigated indeed


                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl

More information about the dev-luatex mailing list