- dev-luatex - NTG Mailing Lists

zziplib building
by Taco Hoekwater 07 Sep '07

07 Sep '07

Hi, (At the moment, this post is probably only relevant for Arthur) I have just committed to the trunk a first attempt to get rid of the autofoo madness that surrounds zziplib. It currently compiles for linux on i586 and the mingw crosscompiler, but all the other architectures probably need some bit of tweaking in one of the two new files: src/libs/zziplib/zzip/Makefile src/libs/zziplib/zzip/_config.h If you know how to compile trunk on your platform, please have a go and see whether/how it works out for you. Best wishes, Taco

2 5

Cron <luatex@server> /home/luatex/luatex-svn
by root＠aanhet.net 07 Sep '07

07 Sep '07

U luatex/trunk/src/libs/zziplib/zzip/_config.h U luatex/trunk/src/texk/web2c/luatexdir/luatex.web U luatex/trunk/src/texk/web2c/luatexdir/lua/luanode.c Checked out revision 697.

1 0

Cron <luatex@server> /home/luatex/luatex-svn
by root＠aanhet.net 06 Sep '07

06 Sep '07

A luatex/trunk/src/libs/zziplib/zzip/Makefile A luatex/trunk/src/libs/zziplib/zzip/_config.h U luatex/trunk/src/texk/web2c/luatexdir/luatexlib.mk Checked out revision 694.

1 0

Cron <luatex@server> /home/luatex/luatex-svn
by root＠aanhet.net 06 Sep '07

06 Sep '07

U luatex/trunk/src/libs/lua51/Makefile U luatex/trunk/src/libs/luafontforge/src/ffdummies.c U luatex/trunk/src/libs/luafontforge/src/luafflib.c U luatex/trunk/src/libs/luafontforge/fontforge/fontforge/splinesave.c U luatex/trunk/src/libs/luafontforge/fontforge/fontforge/tottfgpos.c U luatex/trunk/src/libs/luafontforge/fontforge/fontforge/tottf.c U luatex/trunk/src/libs/luafontforge/fontforge/fontforge/featurefile.c U luatex/trunk/src/texk/web2c/luatexdir/luatex.ch U luatex/trunk/src/texk/web2c/luatexdir/luatex.web Checked out revision 693.

1 0

Cron <luatex@server> /home/luatex/luatex-svn
by root＠aanhet.net 06 Sep '07

06 Sep '07

U luatex/trunk/src/texk/web2c/luatexdir/luatex.ch U luatex/trunk/src/texk/web2c/luatexdir/luatex.web Checked out revision 690.

1 0

Cron <luatex@server> /home/luatex/luatex-svn
by root＠aanhet.net 05 Sep '07

05 Sep '07

U luatex/trunk/src/texk/web2c/luatexdir/luatex.ch U luatex/trunk/src/texk/web2c/luatexdir/luatex.web Checked out revision 688.

1 0

Cron <luatex@server> /home/luatex/luatex-svn
by root＠aanhet.net 05 Sep '07

05 Sep '07

U luatex/trunk/src/texk/web2c/luatexdir/luatex.ch U luatex/trunk/src/texk/web2c/luatexdir/luatex.web U luatex/trunk/src/texk/web2c/luatexdir/lua/lfontlib.c U luatex/trunk/src/texk/web2c/luatexdir/lua/luanode.c Checked out revision 686.

1 0

Cron <luatex@server> /home/luatex/luatex-svn
by root＠aanhet.net 05 Sep '07

05 Sep '07

U luatex/trunk/src/texk/web2c/luatexdir/luatex.web U luatex/trunk/src/texk/web2c/luatexdir/lua/lnodelib.c Checked out revision 682.

1 0

Four suggestions
by Javier Múgica de Rivera 04 Sep '07

04 Sep '07

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 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. * * * 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, \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... }% } 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@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). Regards, Javier A.

4 3

New snapshot
by Taco Hoekwater 25 Aug '07

25 Aug '07

Hi, I have just uploaded a new snapshot, the first one that presents itself as "beta 0.11". I will on vacation for the next two weeks, and I wanted to publish the font fixes I have been working on in the past week before that. New: * pfb/afms font can now be used in 'wide' (encodingbytes=2) mode Fixes: * set_attribute(-1) is now the same as unset_attribute() * OpenType lookups with glyph classes would crash luatex * luazlib would not compile on debian (fix from Norbert) * CID-based fonts would crash luatex * Bare CFF should be read in binary mode (fix from Akira) * VF processing did not process packets containing zero bytes properly As usual, I have uploaded source and binaries to http://foundry.supelec.fr/projects/luatex/ Have fun in the coming weeks, Taco

3 4