dev-luatex December 2007

dev-luatex@ntg.nl

18 participants
34 discussions

Snapshot 20070307
by Taco Hoekwater 10 May '12

10 May '12

Hi all, I decided to do a snapshot now instead of waiting for friday, because I want to start concentrating on something else besides font support issues. What's new: * Non-CID PostScript-based Opentype fonts are now combined over the entire document, and properly subsetted. The code is borrowed from xdvipdfmx with some minor adjustments Adding support for CID-keyed OpenType fonts would not be hard but at the moment I lack example input (and incentive). * A small extension to the virtual fonts structure: you can use f.fonts[1] = { 'id' = 38} to do a backreference to a previously defined font. This saves quite a few computations * There was a bug in the handling of \leaders in the output whereby it's width was taken to be twice what it should be while writing to the PDF, fixed now. * The font inclusion code is cleaned up a bit by Hartmut. * Some compilation problems were fixed. * There is (quite a bit of) debugging information printed out when OTPs are in use, because I am tracking down a bug reported by Idris. The input of each and every OTP step is shown on the terminal in a line line this: [57902][1568][58423][1568][58408][1568][58921] those are the decimal values of ocp i/o characters. If you don't need them, don't worry about it. Happy TeXing, Taco ----- Downloading and installation details: If you go to https://foundry.supelec.fr/frs/?group_id=10 you will see that there are three new released files: * luatex-snapshot-20070307.tar.bz2 This is the source tree. * luatex-snapshot-20070307-win32.zip A cross-compiled (mingw) windows binary. This is a web2c based binary, so it needs a texmf.cnf file (It will NOT work if you have only miktex installed). * luatex-snapshot-20070307-linux-i386.tar.bz2 An intel 32 linux binary (2.6.17)

3 2

luatex and context for Debian
by Norbert Preining 06 Jan '08

06 Jan '08

Dear all, I have updated luatex and context so currently I can even run MkIV documents ;-) Debian/sid users should have them already. Debian/etch users should get luatex 0.20.2-1 from deb http://people.debian.org/~preining/TeX/ luatex/ deb-src http://people.debian.org/~preining/TeX/ luatex/ Currently I have only i386 packages, but will build amd64 for etch soon. And maybe powerpc builds can be organized. For context 2007.12.18-1 please add deb http://people.debian.org/~preining/TeX/ context/ deb-src http://people.debian.org/~preining/TeX/ context/ Just for completeness, it is good to have: texlive: deb http://people.debian.org/~preining/TeX/ tl2007/ deb-src http://people.debian.org/~preining/TeX/ src/ latin modern: deb http://people.debian.org/~preining/TeX/ lmodern/ deb-src http://people.debian.org/~preining/TeX/ lmodern/ For Ubuntu users of the development version (i.e., that tracking sid more or less) luatex can be found at deb http://people.debian.org/~preining/TeX/ luatex-sid/ deb-src http://people.debian.org/~preining/TeX/ luatex-sid/ Please comment if you find something missing. Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining <preining(a)logic.at> Vienna University of Technology Debian Developer <preining(a)debian.org> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- HASSOP (n.) The pocket down the back of an armchair used for storing two-shilling bits and pieces of Lego. --- Douglas Adams, The Meaning of Liff

2 2

subscribe
by Hans van der Meer 26 Dec '07

26 Dec '07

met vriendelijke groet Hans van der Meer

1 0

Re: [Dev-luatex] [NTG-context] luatex not compiling
by Taco Hoekwater 25 Dec '07

25 Dec '07

Idris Samawi Hamid wrote: > Hi guys, > > On Fri, 21 Dec 2007 03:50:04 -0700, Martin Schröder <martin(a)oneiros.de> > wrote: > >> 2007/12/20, Hans van der Meer <hansm(a)science.uva.nl>: >>> Probably changing the code into: >>> #include <signal.h> >>> #ifndef _SIGNAL_H_ >>> #include <sys/signal.h> >>> #endif >>> might help, but I have not tested this (some of the pie should be left >>> for Taco c.s. ;-) >> Just curious: What does the man page of signal.h say how to include >> it on OSX? On linux it's <signal.h> ... > > Should'nt this discssion go to the dev-luatex list? :-) But did not CC the list himself. :-) This: http://www.hmug.org/man/2/sigaltstack.php looks like a Mac OS X manual page. However, Thomas reported that using stack_t (as the man page says) did not actually help either. I do not have a recent Macintosh, so I can not test this. If this issue can not be resolved, I will simply remove the signal trapping code in the next beta. Best wishes, Taco

4 6

build failure on arm
by Norbert Preining 21 Dec '07

21 Dec '07

Hi Taco! We have a build failure of luatex 0.20.1 on ARM when building the lua51 code: gcc -g -O2 -Wall -DLUA_USE_POSIX -c -o lcoco.o lcoco.c lcoco.c: In function 'lua_newcthread': lcoco.c:460: error: '__JMP_BUF_SP' undeclared (first use in this function) lcoco.c:460: error: (Each undeclared identifier is reported only once lcoco.c:460: error: for each function it appears in.) make[3]: *** [lcoco.o] Error 1 >From the compile run: checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking host system type... armv5tel-unknown-linux-gnu checking target system type... armv5tel-unknown-linux-gnu checking build system type... armv5tel-unknown-linux-gnu checking for a BSD compatible install... (cached) /usr/bin/install -c [...] OpenBSD-Compat has been configured with the following options: Host: armv5tel-unknown-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign -std=gnu99 The full build log can be found at http://buildd.debian.org/fetch.cgi?&pkg=luatex&ver=0.20.1-1&arch=arm&stamp=… Do you have any idea how that could be fixed? Thanks a lot and all the best Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining <preining(a)logic.at> Vienna University of Technology Debian Developer <preining(a)debian.org> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- FLODIGARRY (n. Scots) An ankle-length gabardine or oilskin tarpaulin worn by deep-sea herring fishermen in Arbroath and publicans in Glasgow. --- Douglas Adams, The Meaning of Liff

3 5

Fwd: CTAN Update: ant
by Martin Schröder 18 Dec '07

18 Dec '07

It's alive :-) ---------- Forwarded message ---------- From: CTAN Announcements <ctan-ann(a)dante.de> Date: 18.12.2007 10:13 Subject: CTAN Update: ant To: ctan-ann(a)dante.de On Tue, 18 Dec 2007, Achim Blumensath submitted an update to the ant package. Location on CTAN: /systems/ant Summary description: ant is not TeX License type: pd Announcement text: ---------------------------------------------------------------------- I'm pleased to announce the release of ant version 0.8. The archive can be found at http://ant.berlios.de ant is a typesetting system inspired by TeX. It does not aim at complete compatibility with TeX but focuses instead on a flexible, clean, and modular design. ant is public domain. New in this release are: o support for margin kerning o many improvements of the built in scripting language o various bug fixes and minor improvements ---------------------------------------------------------------------- This package is located at http://mirror.ctan.org/systems/ant . More information is at http://tug.ctan.org/info/?id=ant (if the package is new it may take a day for that information to appear). We are supported by the TeX Users Group http://www.tug.org . Please join a users group; see http://www.tug.org/usergroups.html . _______________________________________________ Thanks for the upload. For the CTAN Team Rainer Schöpf

3 3

beta 0.20.2 released
by Taco Hoekwater 17 Dec '07

17 Dec '07

Hi all, I have just uploaded the archives for luatex 0.20.2. This is a simple bugfix release for last week's beta: * some portability fixes to the build scripts * a fix for multi-\span in alignments causing unbreakable loops * manual improvements from Jonathan Sauer * fix for undefined csnames in \directlua if web2c's hash_extra is nonzero * fix for LR text inside of a RL document * fix for open_read_file callback not being called unless find_read_file was also registered * removed the ocp status message when \ocps are not actually used * "unicodeenc" in the fontforge to_table renamed to "unicode" for improved consistency I have uploaded source and linux/win32 binaries to http://foundry.supelec.fr/projects/luatex/ Have fun, Taco

1 0

.BEILMOPS or how I stopped worrying and love Open Source
by Jonathan Sauer 13 Dec '07

13 Dec '07

Okay, this is weird (and long), but it gets clearer near the end: The following test using lpeg to split a comma-separated values works perfectly (never mind that subpattern B does not do anything): ---------------------------------------------------------------------- % A: % \catcode`\:=11 % \def\FM:ifFileIncluded#1{\message{whatever}} % % \FM:ifFileIncluded{} \directlua0{\unexpanded{ whiteSpace = lpeg.S(" \t\n") splitComma = lpeg.P({ lpeg.Ct(lpeg.V("elem") * (lpeg.V("sep") * lpeg.V("elem"))^0), sep = lpeg.S(",{}"), elem = whiteSpace^0 * lpeg.C((1 - lpeg.V("sep"))^1) * whiteSpace^0, % B }) }} \def\splitComma#1{% \directlua0{% local s = '\luaescapestring{\unexpanded{#1}}' local t = lpeg.match(splitComma,s) for k,v in ipairs(t) do texio.write_nl('[' .. v .. ']') end }% } \splitComma{A, B, C, D, E, F} % `print' is not documented, but prints a compiled pattern's bytecode % to the console \directlua0{lpeg.print(splitComma)} \end ----------------------------------------------------------------------- The pattern created is: [1 = elem 2 = sep 3 = elem 4 = sep ] 00: call -> 2 01: jmp -> 51 02: opencapture table(n = 0) (0) 03: call -> 10 04: choice -> 8 (0) 05: call -> 41 06: call -> 10 07: partial_commit -> 5 08: closecapture close(n = 0) (0) 09: ret 10: span [(09-0a)(20)] 19: opencapture simple(n = 0) (0) 20: choice -> 23 (0) 21: call -> 41 22: failtwice 23: any * 1 24: choice -> 30 (0) 25: choice -> 28 (0) 26: call -> 41 27: failtwice 28: any * 1 29: partial_commit -> 25 30: closecapture close(n = 0) (0) 31: span [(09-0a)(20)] 40: ret 41: set [(2c)(7b)(7d)] 50: ret 51: end However, if I run this with my own format, the pattern is: [1 = elem 2 = sep 3 = elem 4 = sep ] 00: call -> 2 01: jmp -> 51 02: opencapture table(n = 0) (0) 03: call -> 10 04: choice -> 8 (0) 05: call -> 41 06: call -> 10 07: partial_commit -> 5 08: closecapture close(n = 0) (0) 09: ret 10: span [(0a)(20)(2e)(42)(45)(49)(4c-4d)(4f-50)(53)] 19: opencapture simple(n = 0) (0) 20: choice -> 23 (0) 21: call -> 41 22: failtwice 23: any * 1 24: choice -> 30 (0) 25: choice -> 28 (0) 26: call -> 41 27: failtwice 28: any * 1 29: partial_commit -> 25 30: closecapture close(n = 0) (0) 31: span [(0a)(20)(2e)(42)(45)(49)(4c-4d)(4f-50)(53)] 40: ret 41: set [(2c)(7b)(7d)] 50: ret 51: end So instead of checking for whitespace in instructions 10 and 31, input is checked against the character set "\n .BEILMOPS" (and splitting the list fails almost completely). I know what a "Beil" is (an axe), and I know what a "Mops" is (some kind of weird animal, a bit like a groundhog [think Bill Murray]), but what is a "Beilmops"? And a "dot Beilmops"? Is is written in C# or what? Now you'll say "yeah, sure, who cares what weird stuff that weird Jonathan does in that weird format of his", but: This only happens if a macro "\FM:ifFileIncluded" is defined or referenced. If this macro is called "\FM:ifFileLoadeded" (the same length) or "\FM:ifFileIlcluded" ("l" instead of "n"), the pattern is compiled correctly. "\FM:ifFileLncluded" works, too. But the moment a control sequence called "\FM:ifFileIncluded" is used (defined or referenced), the lpeg pattern contains that strange animal. I tried to use Lua state 1 instead of 0 to make sure there were no definitions that could create a side-effect, but the pattern remained the same. I tried to uncomment (A) in above PlainTeX code, but the pattern is still correct. So I first suspected some kind of overflow in TeX's hash table that only occurs when there already exist a lot of control sequences and one of them has a very specific name and thus hash value (this does not seem to be the case, though). I tried moving the definition of "\FM:ifFileIncluded" to the beginning of my format (right after setting the catcodes), but without success. I tried defining it in the PlainTeX format, but again to no avail. I tried removing all unnecessary files from my format, with the same result. More weirdness that I more or less accidentally stumbled upon: \directlua1{\unexpanded{lpeg.print(lpeg.S(" \t\n"))}} results in set [(0a)(20)(2e)(42)(45)(49)(4c-4d)(4f-50)(53)] which is wrong, but \directlua1{\detokenize{lpeg.print(lpeg.S(" \t\n"))}} results in set [(09-0a)(20)] which is correct. And the equivalent, but slightly longer \directlua1{lpeg.print(lpeg.S(" \string\t\string\n"))} again results in the correct set [(09-0a)(20)] And indeed: If I replace "\unexpanded" in the code example above by "\detokenize" (and remove the empty lines which for some reason result in "\par" when "\detokenize" is used, but not with "\unexpanded"), the pattern is compiled correctly and works as expected. The plot thickens. Let's look further; how about simply telling Lua to print the string " \t\n"? \directlua1{\detokenize{texio.write_nl("[ \t\n]")}} results in [ ] but \directlua1{\unexpanded{texio.write_nl("[ \t\n]")}} results in [ IMPOSSIBLE. ] Not so weird anymore: "IMPOSSIBLE." is printed by procedure "print_cs" in luatex.web if the control sequence's pointer is below "active_base", that is zero or negative, or >= the pointer to the undefined control sequence (at least as far as I understand it). And "IMPOSSIBLE." sorted and stripped of duplicates is ... ".BEILMOPS"! Also note that "\t" is defined in PlainTeX, but not in my format. If I define it at the beginning of the code example above, nothing changes. But if I define it before defining "\FM:ifFileIncluded", everything works as expected, and \directlua1{\unexpanded{texio.write_nl("[ \t\n]")}} results in [ ] Not "IMPOSSIBLE." anymore. Now: If the control passed to "print_cs" (or "tokenlist_to_cstring" in luatoken.c) is undefined, "IMPOSSIBLE." is printed. As "\t" is indeed undefined, this is completely expected. What's not expected, is that this only happens if the macro "\FM:ifFileIncluded" is not defined before "\t" is defined (if at all). And weird again: "\n" is defined by neither PlainTeX nor my format, but does not result in "IMPOSSIBLE.". Side note: \immediate\write16{\detokenize{[ \t\n]}} \immediate\write16{\unexpanded{[ \t\n]}} both correctly display "[ \t \n ]". So it seems that "\unexpanded" works as expected, but something else does not. And finally: If I say "\let\t\t" at the beginning of my format, everything works as well. So "\t" may well be undefined, as long as it is entered into TeX's hash table before "\FM:ifFileIncluded" is. Jonathan

6 28

Cron <luatex@www> /var/www/luatex.org/www/bin/luatex-svn
by root＠www.bittext.nl 13 Dec '07

13 Dec '07

U svn/trunk/src/texk/web2c/luatexdir/luatex.web U svn/trunk/src/texk/web2c/luatexdir/font/luafont.c U svn/trunk/manual/luatexref-t.tex U svn/trunk/manual/luatexref-t.pdf Checked out revision 966.

1 0

Cron <luatex@www> /var/www/luatex.org/www/bin/luatex-svn
by root＠www.bittext.nl 12 Dec '07

12 Dec '07

U svn/trunk/src/texk/web2c/luatexdir/luatex.ch U svn/trunk/src/texk/web2c/luatexdir/luatex.web U svn/trunk/src/texk/web2c/luatexdir/lua/luatoken.c U svn/trunk/src/texk/web2c/luatexdir/tex/texnodes.c U svn/trunk/manual/luatexref-t.tex U svn/trunk/manual/luatexref-t.pdf Checked out revision 962.

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

dev-luatex December 2007