Hello, expanding on yesterday's message about font expansion in LuaTeX beta 0.10.1, I verified the phenomenon of text being typeset in a narrow column and clipped at the left margin. Then I dug deeper into it. Then I remembered Colonel Kurtz in "Apocalypse Now": "The horror, the horror ..." ;-) Situation: teTeX 3.0 on a macintosh (PPC) with a new pdfeTeX (1.40.3) and LuaTeX beta 0.10.1 (both built by myself). The HOMETEXMF path in texmf.cnf is "/Volumes/Dummy;/Volumes/Work/Workplace/Writing/TeX;/usr/local/ teteX/and/so/on". In the second path element, the formats for both LuaTeX and pdfeTex are stored, along with some other files (formats, log files). The first path element does not exist (just a dummy for testing the phenomenon). If the number of visible files in the directory the luatex.fmt file is stored in is equal to six or lower, some strange overfull boxes are reported by LuaTeX, and the text is typeset as described above. See attached log file "Six_LuaTeX.console.log". "Six_web2c.listing.txt" is the directory listing of the directory the formats are stored in. If the number of visible files in the directory is seven, everything works perfectly. See attached log file "Seven_LuaTeX.console.log" and "Seven_web2c.listing.txt". It seems that the error occurs if the number of (visible) files in the directory is even or less than six. Note that the error also seems to depend on which path element in HOMETEXMF points to the format directory. If it is the first path element, the error seems to occur if the number of (visible) files in the directory is odd or less than seven. The issue is not a corrupt file system; I created a small partition for the test (no big deal, I head a little bit of free space on my HD) and also verified the file system integrity. Now, normally I would say that there is something really, really wrong with my TeX setup -- but in pdfeTeX, everything works perfectly (pdfetex.fmt in the same place as luatex.fmt, same test file; see "Six_pdfTeX.console.log" and "Seven_pdfTeX.console.log"). This IMO points to LuaTeX. Or am I missing something? I have not yet had the time to look into the source code. The following is a small Plain-based document which demonstrates the behaviour: ------------------------------ CUT ------------------------------- \pdfoutput1 % The following text is typeset correctly: Hello {\tentt world} with Lua\TeX. Hello {\tentt world} with Lua\TeX. Hello {\tentt world} with Lua\TeX. Hello {\tentt world} with Lua\TeX. Hello {\tentt world} with Lua\TeX. Hello {\tentt world} with Lua\TeX. Hello {\tentt world} with Lua\TeX. Hello {\tentt world} with Lua\TeX. % The following text is typeset in a narrow column and cut off at the % left. This is just {\tentt test}. Just a {\tentt test}. Nothing more than a {\tentt test}. Just a {\tentt test}. Nothing more than a {\tentt test}. Just a {\tentt test}. Nothing more than a {\tentt test}. Just a {\tentt test}. Nothing more than a {\tentt test}. Just a {\tentt test}. Nothing more than a {\tentt test}. Just a {\tentt test}. Nothing more than a {\tentt test}. % The following text is typeset in a narrow column as well: This is just test. Just a test. Nothing more than a test. Just a test. Nothing more than a test. Just a test. Nothing more than a test. Just a test. Nothing more than a test. Just a test. Nothing more than a test. Just a test. Nothing more than a test. % The following *was* typeset across the whole page, until I added % the `-- not' et cetera: Some more text, just to check if the weird typesetting of the last paragraph can be repeated. Still, it would be strange if not. But it looks like -- not, at least if the paragraph is short. If it is longer, the text is typeset incorrectly. % The following is typeset across the whole page, just like it should % be: But only if the paragraph is a little bit longer, a few lines. \bye ------------------------------ CUT ------------------------------- Sorry for posting this weird bug (if it is a bug). I know how difficult it is to track these phenomenons down. Jonathan
Hi Jonathan, Doesn't make much sense, does it? Thanks fro the detailed report, I am working on it (at least on the problems I can reproduce). Best wishes, Taco
Hello,
If the number of visible files in the directory the luatex.fmt file is stored in is equal to six or lower, some strange overfull boxes are reported by LuaTeX, and the text is typeset as described above.
I tried to reproduce the phenomenon and had the following results (with TeX Live 2007 on Mac OS X Intel): • With the LuaTeX beta version and a standard configuration I get extremely weird output in the vein of what Jonathan observed (see FontExpandTest-beta.{log,pdf}). • I then tried to change the number of files in the directory where the format file lies like Jonathan did but could see no change. In the process, though, I noticed that setting TEXFORMATS makes some of the problems disappear (FontExpandTest-current.{log,pdf}). • Then (actually in the first place) I made the same experiments with the current SVN trunk revision and the very weird problem of the first paragraph didn't show up anymore: setting TEXFORMATS or not made no difference and whatever I tried I got the output shown in FontExpand-current.pdf. I didn't try very hard Jonathan's trick of changing the number of files in the directory where the format file is found, but it seems to me that it doesn't make any difference with my configuration. So, although the problems aren't all solved yet, it seems that some of them have already disappeared in the latest revision; and even if I couldn't reproduce the exact same behaviour as Jonathan reported, I'm pretty confident that the problem with the six or seven files in the web2c directory amounts to the same as the one I had with setting TEXFORMATS (after all it's all about kpathsea search for the format file); and subsequently, I'm strongly inclined to think that this weirdest of all bugs has been fixed in the current SVN revision. I'm also attaching the TeX file I used for all my experiments; it's only the extract from Jonathan's original e-mail but I put it here for self-containedness. Arthur
Arthur Reutenauer wrote:
So, although the problems aren't all solved yet, it seems that some of them have already disappeared in the latest revision; and even if I couldn't reproduce the exact same behaviour as Jonathan reported, I'm pretty confident that the problem with the six or seven files in the web2c directory amounts to the same as the one I had with setting TEXFORMATS (after all it's all about kpathsea search for the format file); and subsequently, I'm strongly inclined to think that this weirdest of all bugs has been fixed in the current SVN revision.
Thanks for this. No progress to report yet. My current guess is that the weird problems lately are essentially all the same problem: a rogue pointer somewhere overwrites random bits of memory with other stuff. Best wishes, Taco
Hello,
So, although the problems aren't all solved yet, it seems that some of them have already disappeared in the latest revision; and even if I couldn't reproduce the exact same behaviour as Jonathan reported, I'm pretty confident that the problem with the six or seven files in the web2c directory amounts to the same as the one I had with setting TEXFORMATS (after all it's all about kpathsea search for the format file); and subsequently, I'm strongly inclined to think that this weirdest of all bugs has been fixed in the current SVN revision.
Thank you for investing your time in this. I just checked out the HEAD from svn and will repeat the tests during the weekend. Taco: How stable is HEAD currently?
Arthur
Jonathan
Jonathan Sauer wrote:
Thank you for investing your time in this. I just checked out the HEAD from svn and will repeat the tests during the weekend.
Taco: How stable is HEAD currently?
It should be better than the beta, I have not done much coding, just lots of bug hunting in the past few weeks. I plan a new beta next week, just before I start meddling with HEAD again. Best, Taco
Taco Hoekwater wrote:
Jonathan Sauer wrote:
Thank you for investing your time in this. I just checked out the HEAD from svn and will repeat the tests during the weekend.
Taco: How stable is HEAD currently?
It should be better than the beta, I have not done much coding, just lots of bug hunting in the past few weeks. I plan a new beta next week, just before I start meddling with HEAD again.
The current HEAD (as of 30sec) should give noticeably better results for this test file. I am quite confident I fixed the rogue \tentt appearances, at least. Best wishes, Taco
participants (3)
-
Arthur Reutenauer
-
Jonathan Sauer
-
Taco Hoekwater