April 2007 - dev-luatex - NTG Mailing Lists

Proposed patch for the nc/nd problem
by David Kastrup 04 Apr '07

04 Apr '07

Seems like I can't get a patch attached to a bug report in the PDFTeX system, and Martin has closed the bug after fixing the first half. Here is a proposed patch to deal with the rest (note that 9.99998nd gets a wrong value, too, with the current code even though it adheres to Knuth's original description of the constraints). It also fixes Knuth's comment, and puts the nd ratio in shortest terms. The patch is based on LuaTeX, but it should be possible to apply it to pdfTeX. -- David Kastrup

2 1

Just noticed something...
by David Kastrup 04 Apr '07

04 Apr '07

In the messages from the tex.tex run, I got overfull box messages like the following: Overfull \hbox (12.40152pt too wide) in paragraph at lines 21018--21025 []\tenbf 836. \tenrm It is not nec-es-sary to cre-ate new ac-tive nodes hav-ing [] greater than $[] +| \hbox(6.94444+1.94444)x469.75499, glue set - 1.0, direction TLT .\whatsit ..\localinterlinepenalty=0 ..\localbrokenpenalty=0 ..\localleftbox=null ..\localrightbox=null .\tenbf 8 .\tenbf 3 .\tenbf 6 .\tenbf . .etc. That whatsit has to go. Absolutely. When the user is explicitly assigning values to \local* variables, placing a whatsit at the point of assignment is fine and expected. It is even conceivable to place a whatsit at the start of the current hlist _when_ we assign to \local* in the middle of the list. But we can't go peppering the lists with whatsits when we are not asked for it. It will break far too many existing packages. Unless we find a way to make whatsits transparent. But the combination glue whatsit glue could not preserve a whatsit when doing \skip0=\lastskip \unskip \skip1=\lastskip \unskip \vskip\skip1 \vskip\skip2 So there is -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

3 2

A design philosophy question...
by David Kastrup 03 Apr '07

03 Apr '07

I have this year reported something as a bug to Barbara Beeton (the bug collector for TeX) which I find disturbing: TeX's arithmetic on units truncates and thus is biased. This has the annoying effect that "1in", supposedly representing one inch which is _exactly_ 72.27 points, will in TeX stand for the value "72.26999pt" and be actually smaller than the value "72.27pt". Of course, fixing this might change existing documents. Also we have: **\dimen0=1in entering extended mode *\showthe\dimen0 > 72.26999pt. *\showthe\dimexpr100\dimen0\relax > 7226.9989pt. *\dimen0=72.27pt *\showthe\dimen0 > 72.27pt. *\showthe\dimexpr100\dimen0\relax > 7227.00043pt. So while "72.27pt" is _quite_ closer to one inch than "1in" is, it is larger. Anyway, is something like that an area that LuaTeX would actually ever consider touching? After all, it would break document compatibility. Which might be, I believe, less of a holy grail for ConTeXt than for LaTeX. Opinions? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

4 12

What is the unit "nc" supposed to be?
by David Kastrup 03 Apr '07

03 Apr '07

New Cicero or what? Please consider the following: This is luaTeX, Version 3.141592-snapshot-2007040210 (Web2C 7.5.6) **\dimen0=1nc *\showthe\dimen0 > 12.80373pt. <*> \showthe\dimen0 ? *\dimen0=0.99998nc *\showthe\dimen0 > -0.09723pt. <*> \showthe\dimen0 ? * This does not cut it at all. The section in tex.web starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 32768 or less. In LuaTeX, the section brazenly starts with @ The necessary conversion factors can all be specified exactly as fractions whose numerator and denominator are 65535 or less. Who does things like that without actually checking that they work? It is possible to rework the arithmetic to get along with 65535, but it is certainly not a matter of merely changing the _documentation_ and not the code. I have no idea whether this is an eTeX, a PDFTeX, an Aleph or a LuaTeX invention (did I forget anything?), but it certainly can't stay like that. Sorry if I sound like a whiner here. If you think it worth the trouble, I can rework the arithmetic (but there is a reason that Knuth kept to 15 bit factors, so it is going to become more complicated). But I consider it more likely that nc should be changed to 1370:107 which is the closest 15 bit fraction to 12nd (it is smaller than 12nd, but the next larger suitable fraction 32163:2512 is slightly further from 12nd). Please remember that in TeX, 2in is not equal to 1in+1in anyway. I think we can afford this. Certainly better than the current behavior. -- David Kastrup

4 11

Rationale for using putenv?
by David Kastrup 02 Apr '07

02 Apr '07

Hi, in luastuff.c we have static int os_setenv (lua_State *L) { char *value, *key, *val; key = (char *)luaL_optstring(L, 1, NULL); val = (char *)luaL_optstring(L, 2, NULL); if (key) { if (val) { value = xmalloc(strlen(key)+strlen(val)+2); sprintf(value,"%s=%s",key,val); if (putenv(value)) { return luaL_error(L, "unable to change environment"); } } else { #if defined(WIN32) || defined(__sun__) value = xmalloc(strlen(key)+2); sprintf(value,"%s=",key); if (putenv(value)) { return luaL_error(L, "unable to change environment"); } #else (void)unsetenv(key); #endif } } lua_pushboolean (L, 1); return 1; } Now putenv is not required by Posix, as opposed to setenv. The main rationale for "putenv" is that it leaves memory management of the string to the application, and thus can avoid leaking memory. However, the above code just uses xmalloc without deallocating previously set values, so it leaks, anyway. Basically I see two ways of dealing with this: a) maintain a table of key -> "key=value" mappings for environment variables that have been set by Lua. That way, one can keep track of what strings need to stay allocated, and which can be deallocated again. b) don't bother about the leak and use setenv instead. Option b) would be somewhat more portable, I believe. Of course, if people actually use os_setenv to switch around between environment variables frequently, the leak might get annoying at some point of time. -- David Kastrup

3 10

LaTeX and LuaTeX
by David Kastrup 02 Apr '07

02 Apr '07

Well, the various LaTeX hyphenation pattern files are giving me a run for my money: authors think it is a good idea to encode them in binary, regardless of whether we are talking latin-1, T1 or koi8 encodings. What a mess. I started writing to a few of the maintainers... Anyway, in the mean time one can dump LaTeX using the following file named latex.8bit instead: That's just for dumping: I have not actually tried running this format. I don't even know whether the callback survives into the format or not... -- David Kastrup

2 3

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

02 Apr '07

U luatex/src/texk/web2c/luatexdir/lua/luainit.c Checked out revision 383.

1 0

automadness
by Taco Hoekwater 02 Apr '07

02 Apr '07

Hi, Arthur Reutenauer wrote: > > * The spurious '$' are more of a concern: apparently they're due to > discrepancies between Solaris /bin/sh and bash (which seem to > interpret constructs like > "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set" differently, > and on Solaris the dollar sign is set verbatim). So what we actually > have to do is use bash for the configure scripts (which on Solaris > is available as /bin/bash as well as /usr/bin/bash). But of course, > the path is set explicitely at the top of the script... So this is > more of a problem. > > So, as a last request, would it be possible the tell autoconf to write > "#!/bin/bash" at the beginning of the configure scripts, instead of > /bin/sh? This seems the way to go, since on many systems /bin/sh is bash > anyway (including Mac OS X), and apparently it's expected to be it, since > it doesn't work otherwise on Solaris. > > If it it's not possible, let it be; I'll find a workaround, but this is > rather silly. I agree that it is silly, but I just realized that this version will at least *run* on systems with only sh or pdksh. Changing the first line of the configure scripts to something like #!/usr/bin/env bash would make it fail completely on such systems. So, I am sorry, but I have changed my mind about making that change to the configure scripts (for now). Best wishes, Taco

3 2