- dev-luatex - NTG Mailing Lists

Warning re comparing Word and TeX
by c.a.rowley＠open.ac.uk 02 Nov '09

02 Nov '09

Hi guys Do not forget that Word etc have a different model for microtypography and how they treat font metrics and 'normal horizontal stacking' of glyph sequences. The big difference that has a major effect on how math layout is acheived is that they do not use the concept of nested boxes: everything is simply 'positioned glyphs'. There are other important differences but they are not so likely to affect math typesetting. If you get Windows 2010, I think that all the math stuff is available 'at the OS level' which I think means that it is also all in an Active-X control for developers use. But probably with zero documentattion! Finally, if you want to know about their algorithm, just ask them! Although they may reply, as I would about details like that, 'we have forgotten'. Cheers, chris > > Office 2007 seems to handle sub/superscripts of big operators > differently; superscript is placed immediately after base glyph while a > negative kern equal to italic correction is inserted between base and > subscript i.e. the reverse of what is described in the spec, and math > kerning is ignored completely. Big sigh. I'll see if I can get my hands on a copy of Word2009. Best wishes, Taco -----dev-luatex-bounces(a)ntg.nl wrote: ----- To: dev-luatex(a)ntg.nl From: dev-luatex-request(a)ntg.nl Sent by: dev-luatex-bounces(a)ntg.nl Date: 02/11/2009 11:00 Subject: dev-luatex Digest, Vol 46, Issue 2 Send dev-luatex mailing list submissions to dev-luatex(a)ntg.nl To subscribe or unsubscribe via the World Wide Web, visit http://www.ntg.nl/mailman/listinfo/dev-luatex or, via email, send a message with subject or body 'help' to dev-luatex-request(a)ntg.nl You can reach the person managing the list at dev-luatex-owner(a)ntg.nl When replying, please edit your Subject line so it is more specific than "Re: Contents of dev-luatex digest..." Today's Topics: 1. Re: Luatex 0.44.0 announcement (Khaled Hosny) 2. echoing system call argument to stderr (T T) 3. Re: echoing system call argument to stderr (Manuel P?gouri?-Gonnard) 4. Re: kpse.find_file (Reinhard Kotucha) 5. Re: echoing system call argument to stderr (T T) 6. Re: echoing system call argument to stderr (Akira Kakuto) 7. Re: Luatex 0.44.0 announcement (Taco Hoekwater) ---------------------------------------------------------------------- Message: 1 Date: Sun, 1 Nov 2009 15:00:25 +0200 From: Khaled Hosny <khaledhosny(a)eglug.org> To: Taco Hoekwater <taco(a)elvenkind.com> Cc: luatex development list <dev-luatex(a)ntg.nl> Subject: Re: [Dev-luatex] Luatex 0.44.0 announcement Message-ID: <20091101130025.GA8814@khaled-laptop> Content-Type: text/plain; charset="utf-8" On Fri, Oct 30, 2009 at 09:02:30AM +0100, Taco Hoekwater wrote: > > Hi, > > Khaled Hosny wrote: > > On Tue, Oct 27, 2009 at 12:06:09PM +0100, Taco Hoekwater wrote: > >> * Math delimiters and large operators in new MATH fonts no > >> longer apply the italic correction (this fixes placements > >> of super- and subscripts on such items for those fonts). > > > > This doesn't sound the correct way to me. The described algorithm in > > MATH specification is to set subscripts immediately after the base > > (without italic correction) and shift superscripts horizontally by the > > amount of italic correction, then apply math kerning if present, this > > way fonts with no math kerning will still give acceptable output and > > need for math kerning will be minimized. > > Well, I am clearly doing something wrong, because both the old and > new outputs look crappy. I'll rethink this. Office 2007 seems to handle sub/superscripts of big operators differently; superscript is placed immediately after base glyph while a negative kern equal to italic correction is inserted between base and subscript i.e. the reverse of what is described in the spec, and math kerning is ignored completely. So I think the current positioning of superscripts is correct, only subscripts need to be fixed, though I'm not really sure about any of those conclusions :) Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer

1 0

Luatex 0.44.0 announcement
by Taco Hoekwater 02 Nov '09

02 Nov '09

Hi, I have just uploaded the archives for a new luatex release, 0.44.0. There are not a lot of new features yet, but this releases fixes a fair amount of bugs found in 0.43.0 (and earlier versions). New features: * libpng is now 1.2.40. * hlist nodes now have a subtype to distinguish hlists generated by the paragraph breaking, explicit \hbox commands, and other (as-yet-undefined) sources. * \pdfobj now has an extra optional keyword: 'uncompressed', which forces the object to be written to the PDF in plain text (see the manual for the exact details). * The lua file from the luamd5 library (which provides the md5.hexsuma() function) is now embedded in the executable. Bug fixes: * \latelua now works in DVI mode again. * status.output_file_name could crash when used too soon. * In 0.43, rules were not output at all in DVI mode. * \leavevmode\penalty-10000\penalty-10000 crashed luatex. * the API of margin kern nodes to lua was using the wrong fields in the nodes. * A few fixes to the manual. * PDF Xref stream dicts were slightly non-conformant. * There was too much space between two consecutive math displays (this bug was inherited from Aleph) * Synctex was broken (thanks, Akira) * Font mark classes were handled incorrectly by the fontloader code. * There was a crash possible with certain types of named PDF destinations. * Math delimiters and large operators in new MATH fonts no longer apply the italic correction (this fixes placements of super- and subscripts on such items for those fonts). * The converter from lua strings to token lists (for the node interface) sometimes generated invalid tokens. * CFF (OpenType) fonts now listen to 'embedding="full"'. TTF is still todo. * Font tables with 'embedding="no"' would cause luatex to crash. * \pdfobj file {} failed to find the file if there was no lua callback in place. * An optimization in MS Mincho caused luatex to crash. The archives can be downloaded from supelec as usual: http://foundry.supelec.fr/gf/project/luatex/ You could also check out the sources via anonymous svn: svn co http://foundry.supelec.fr/svn/luatex/tags/beta-0.44.0 Bugs and feature requests can be added to the issue tracker at http://tracker.luatex.org Have fun, Taco

2 4

echoing system call argument to stderr
by T T 02 Nov '09

02 Nov '09

Hi, I've noticed that os.execute under texlua echos its argument to stderr. This is not the behaviour under the standard lua interpreter. Is it a bug or feature (and what would be the reason for it)? Cheers, Tomek

3 3

kpse.find_file
by Reinhard Kotucha 01 Nov '09

01 Nov '09

Hi, I just fixed some nasty bugs in texlua wrappers for ppower4 and pdfthumb which are under texmf-dist/scripts in TeX Live. There are no problems on Windows: When I type "ppower4 --help", I get PPower4 [-v|-n|-h|-V|--verbose=<n>|--nocompress|--help|--version] infile outfile On Unix, however, I get a warning message: warning: kpathsea: configuration file texmf.cnf not found in these directories: [...] Here is [...] with colons replaced my linebraeks: /usr/local/texlive/2009/texmf-dist/scripts/ppower4 /usr/local/texlive/2009/texmf-dist/scripts /usr/local/texlive/2009/texmf-dist /usr/local/texlive/2009/texmf-dist/scripts/ppower4/share/texmf-local/web2c /usr/local/texlive/2009/texmf-dist/scripts/share/texmf-local/web2c /usr/local/texlive/2009/texmf-dist/share/texmf-local/web2c /usr/local/texlive/2009/texmf-dist/scripts/ppower4/texmf-local/web2c /usr/local/texlive/2009/texmf-dist/scripts/texmf-local/web2c /usr/local/texlive/2009/texmf-dist/texmf-local/web2c /usr/local/texlive/2009/texmf-dist/scripts/ppower4/share/texmf/web2c /usr/local/texlive/2009/texmf-dist/scripts/share/texmf/web2c /usr/local/texlive/2009/texmf-dist/share/texmf/web2c /usr/local/texlive/2009/texmf-dist/scripts/ppower4/texmf/web2c /usr/local/texlive/2009/texmf-dist/scripts/texmf/web2c /usr/local/texlive/2009/texmf-dist/texmf/web2c ...and pp4p.jar is obviously not found, Java then prints its own usage message. It seems that texmf.cnf is searched in texmf-dist only, but how can this happen? Strange enough, everything works fine on Windows. I can strip down the texlua script: ------------------------------------------------------------------ #!/usr/bin/env texlua if os.type == 'windows' then kpse.set_program_name('ppower4.exe', 'ppower4') else kpse.set_program_name('ppower4') end jarfile=kpse.find_file('pp4p.jar', 'texmfscripts') print (jarfile) ------------------------------------------------------------------ On Windows it returns /path/to/pp4p.jar, on Unix it returns "nil". The command kpsewhich -format=texmfscripts pp4p.jar returns the correct path on both, Unix and Windows. Hence, I think it's a LuaTeX problem. I don't think that fixing this problem is urgent. It's definitely not worthwhile to delay a TeX Live release. Karl, I can provide a simple solution for the time being: Because what we have in TeX Live already works as expected on Windows, we only need a solution for Unix. I could simply copy the shell scripts we had in TeX Live 2005 to texmf-dist/scripts/ppower4 and adapt the symlinks accordingly. Then everything works on all platforms. What do you think? Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

3 3

Cron <luatex@vz3> /var/www/luatex.org/www/bin/luatex-svn
by root＠www.metatex.org 01 Nov '09

01 Nov '09

------------------------------------------------------------------------ r3091 | oneiros | 2009-11-01 01:32:36 +0100 (Sun, 01 Nov 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/fontforge/fontforge/parsettf.c unnest some externs ------------------------------------------------------------------------

1 0

Cron <luatex@vz3> /var/www/luatex.org/www/bin/luatex-svn
by root＠www.metatex.org 31 Oct '09

31 Oct '09

------------------------------------------------------------------------ r3090 | taco | 2009-10-31 15:52:37 +0100 (Sat, 31 Oct 2009) | 4 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/fontforge/fontforge/parsettf.c M /trunk/source/texk/web2c/luatexdir/luafontloader/fontforge/fontforge/psread.c M /trunk/source/texk/web2c/luatexdir/luafontloader/fontforge/fontforge/splinefont.h Speed up reading of OTF fonts in fontloader.open() by using an approximate boundingbox that is calculated during CFF parsing instead of the perfectly accurate one that had to be calculated based on actual splines. ------------------------------------------------------------------------

1 0

Cron <luatex@vz3> /var/www/luatex.org/www/bin/luatex-svn
by root＠www.metatex.org 28 Oct '09

28 Oct '09

------------------------------------------------------------------------ r3089 | taco | 2009-10-28 15:38:26 +0100 (Wed, 28 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/image/pdftoepdf.cc initial fix for premature newlines ------------------------------------------------------------------------

1 0

Cron <luatex@vz3> /var/www/luatex.org/www/bin/luatex-svn
by root＠www.metatex.org 27 Oct '09

27 Oct '09

------------------------------------------------------------------------ r3088 | taco | 2009-10-27 16:28:43 +0100 (Tue, 27 Oct 2009) | 3 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/font/mapfile.c allow a null font name in the fmlookup() function, for the benefit of lua-loaded fonts ------------------------------------------------------------------------

1 0

Cron <luatex@vz3> /var/www/luatex.org/www/bin/luatex-svn
by root＠www.metatex.org 27 Oct '09

27 Oct '09

------------------------------------------------------------------------ r3084 | taco | 2009-10-27 11:43:01 +0100 (Tue, 27 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/NEWS New News ------------------------------------------------------------------------ r3085 | taco | 2009-10-27 11:43:57 +0100 (Tue, 27 Oct 2009) | 2 lines Changed paths: A /tags/beta-0.44.0 (from /trunk:3084) new release tag ------------------------------------------------------------------------ r3086 | taco | 2009-10-27 13:15:11 +0100 (Tue, 27 Oct 2009) | 2 lines Changed paths: M /trunk/manual/luatexref-t.pdf M /trunk/manual/luatexref-t.tex new manual + small fix ------------------------------------------------------------------------ r3087 | taco | 2009-10-27 13:16:51 +0100 (Tue, 27 Oct 2009) | 2 lines Changed paths: M /tags/beta-0.44.0/manual/luatexref-t.pdf M /tags/beta-0.44.0/manual/luatexref-t.tex fixes to the manual from trunk ------------------------------------------------------------------------

1 0

Wishing is free: fonts and glyph placement
by Javier Múgica 27 Oct '09

27 Oct '09

If one takes a look at the kerning pairs of a font with many accented letters, for instance lmr10, there are many "duplicate" pairs, in the sense that in addition to "ko" there also appear "kó", "kò", "kô" and so forth, and "ke", "ké", etc., obviously with the same kerning value, and if we had \'k (accented k) then all of the combinations again. If a new accented letter gets added, all its pais have to be encoded. There is clearly some logic missing there. The idea is that something which is at the right like k, plus something which is at the left like o, needs a kerning of such and such. While the quadratic grouth of pairs is still tractable for normal text with the current speed and memory capacities of computers, it becomes out of control in math, where the possible pairs is beyond any tabulation capacity. I for example had recently Q\Sigma, which clearly requires kerning. The underlying problem is that TeX does not take into account the actual shape of the glyphs, but just its enclosing rectangle. Since this is not sufficent for high quality typesetting there are two pieces of information relating to the shape of the gliph beyond the enclosing rectangle that TeX knows about: the kerning pairs and the italic correction. There are just two patches that leave many situations to be manually adjusted by the editor (I refer to the person), depending on his patience and quality standards, specially in math, where both the pairs of gliphs that get combined and the relative position of them is virtualy unlimited. While computing gliph spacing by analyzing the glyph's shapes may be too involved, a good, easier solution could be that, in addition to the rectangle enclosing the glyph, another shape were known, not so complicated as a glyph's shape but not so crude as a rectangle. I could be restricted to a one-piece polygon without holes enclosing the character and leaving a little space between its border and the character (as the character's box currently does). For example, the polygon for the letter k could be a rectangle with a wedge intruding at the right side, while that of o, ó, e, etc. could be an octagon. So when these characters were placed together it would be done so that the respective polygons touch, instead of the rectangular boxes as is now the case, and the need of kerning would disappear. This approach would: -- reduce the kerning pairs drastically -- need a linear grouth with the number of glyphs in the font (the polygons) instead of a quadratic one. -- New glyphs, specialy adorned variants of existing ones, would automatically get the correct spacing with existing ones. -- Pairs that seldom appear and are thus not considered in the kerning tables, would also get the right spacing automatically. -- The unlimited possible combinations inside math would get handled correctly. Most of them or at least many. Thus, the need for dozens of \! \, \phantoms and like stuff would decrease substantialy. Here are some examples: \Bigg)_{\!0} (or was it even _{\!\!0}?) f^2\,) %here it is the left protruding of the )'s polygon that would come into play. 1/\!\sqrt{3} This requires adding another piece of info per-character in the font. Now I can't remember how the tables of an OT font are orginized and don't know whether this is possible or not. The inconvenience I see in trying to compute the spacements based directly on the shape of the gliph (with respect to the polygons I'm proposing), appart from the many bugs that could be present till it finally got properly programmed, is that it is too big a jump form the current glyph placement algorithms in math, but it may well be that my fears are unjustifed. The polygon approach has also the advantage that it is easier to define the polygons so as to obtain the current spacing between the most common kerning pairs, while it would be more difficult to program an algorithm based on the glyphs' shapes achieving the same effect, but on the other side it need not be better to exactly preserve the current kerning values. It may be too son for proposing this now, but I'm sure this will sooner or later (possibly later) come to be discussed, since for the finest text editor, a glyph placement in math based solely on the rectangle of the glyphs and the italic correction cannot possibly be the definitive solution. Cheers to all Javier A. Múgica

6 7