February 2008 - dev-context - NTG Mailing Lists

cyrillic glyphs
by Mojca Miklavec 29 Feb '08

29 Feb '08

Hello Hans, According to AGLFN at http://partners.adobe.com/public/developer/en/opentype/aglfn13.txt consider for example the glyph 0420;afii10034;CYRILLIC CAPITAL LETTER ER in char-def.lua you have [0x0420]={ ["adobename"]="afii0x2732", ["category"]="lu", ["cjkwd"]="a", ["contextname"]="cyrillicR", ["description"]="CYRILLIC CAPITAL LETTER ER", ["lccode"]=0x0440, ["linebreak"]="al", ["unicodeslot"]=0x0420, -- Р }, So: ["adobename"]="afii0x2732", "instead of" afii10034. What do you suggest? I guess that adobename might need to have multiple entries anyway. Mojca

3 6

Luatex beta 0.22.1 released
by Taco Hoekwater 27 Feb '08

27 Feb '08

Hi all, I have just uploaded the archives for luatex 0.22.1, that is a bugfix release for 0.22.0 Fixes and changes: * The macnames.c source file for building ttf2afm is restored. * "make depend" in luatexdir now works again * luatex sometimes crashed because it attempted to expand an already expanded font * luatex aborted when --progname was given but no format name. It now sets the format name to the given progname in that case * sometimes paragraphs with near-empty lines could cause a crash * img.supportedtypes() had a bug causing it to crash * img.supportedtypes() has been renamed to img.types for consistency * img.boxes() added, returns strings representing bounding boxes * img.node() added, returns a whatsit node cf. \pdfrefximage * node.write() now accepts multiple arguments * the program_name_set switch was not set automatically from C, causing errors unless lua code called kpse.set_program_name() explicitly * kpse.set_program_name() can now be called more than once in a single run. * os.spawn{...} and os.exec{...} could cause crashes because of a memory allocation error The archives (source and binaries) can be downloaded from supelec, as usual: http://foundry.supelec.fr/projects/luatex/ Bugs and feature requests can be added to the issue tracker at http://tracker.luatex.org Have fun, Taco

1 0

New Debian packages (luatex, context) for Etch
by Norbert Preining 21 Feb '08

21 Feb '08

Hi all! Before leaving againg for 3 weeks in mountainous isolation I have updated context and luatex. For luatex there is also an etch version. Current versions: luatex 0.22.0.svn080220-1.np.etch.1 context 2008.01.28-1 As usual, here is the full list: texlive and tex-common deb http://people.debian.org/~preining/TeX/ tl2007/ deb-src http://people.debian.org/~preining/TeX/ src/ lmodern deb http://people.debian.org/~preining/TeX/ lmodern/ deb-src http://people.debian.org/~preining/TeX/ lmodern/ context deb http://people.debian.org/~preining/TeX/ context/ deb-src http://people.debian.org/~preining/TeX/ context/ luatex (for etch) deb http://people.debian.org/~preining/TeX/ luatex/ deb-src http://people.debian.org/~preining/TeX/ luatex/ luatex (for sid, but sid users will get it anyway) deb http://people.debian.org/~preining/TeX/ luatex-sid/ deb-src http://people.debian.org/~preining/TeX/ luatex-sid/ Best wishes 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 ------------------------------------------------------------------------------- LYDIARD TREGOZE (n.) The opposite of a mavis enderby (q.v.) An unrequited early love of your life who still causes terrible pangs though she inexplicably married a telephone engineer. --- Douglas Adams, The Meaning of Liff

1 0

why my first idea of experimental minimals didn't work out :)
by Mojca Miklavec 02 Feb '08

02 Feb '08

Hello (this is for amusement only - an interesting experience), if anyone would like to know why the idea with experimental branch of minimals didn't work out in its current form (I wanted to have a full tree and a separated tree with fixes only, but it took files from current and experimental in an arbitrary order). This is an answer from the mailing list: ------ Duh. I realize now that it's perfectly reasonable for you to be able to reproduce the problem while I can't. Versions 2.6.9 and earlier of rsync sort the file-list using the C library's quicksort, an unstable sort, so the results in case of duplicate files are highly sensitive to both the C library implementation and the order of directory entries in the source (which in turn is sensitive to the filesystem implementation). You probably have both a different C library and a different filesystem than I do. In any case, since rsync 3.0.0pre1, the default file-list sorting algorithm is a mergesort, which is stable, so files from earlier source arguments take priority. If you upgrade to an rsync 3.0.0pre* version, your scenario should work consistently. If it doesn't, that's a bug we should try to fix.

1 0