- dev-luatex - NTG Mailing Lists

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

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

26 Oct '09

------------------------------------------------------------------------ r3076 | oneiros | 2009-10-25 23:50:13 +0100 (Sun, 25 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/src/ffdummies.c M /trunk/source/texk/web2c/luatexdir/luafontloader/src/luafflib.c indent, svn:keywords, header ------------------------------------------------------------------------ r3077 | oneiros | 2009-10-25 23:51:23 +0100 (Sun, 25 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/pdf/pdfgen.c M /trunk/source/texk/web2c/luatexdir/pdf/pdftables.c indent ------------------------------------------------------------------------ r3078 | oneiros | 2009-10-25 23:52:31 +0100 (Sun, 25 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/lua/lstatslib.c M /trunk/source/texk/web2c/luatexdir/lua/ltexlib.c M /trunk/source/texk/web2c/luatexdir/lua/luagen.c M /trunk/source/texk/web2c/luatexdir/lua/luainit.c M /trunk/source/texk/web2c/luatexdir/lua/luatex-api.h M /trunk/source/texk/web2c/luatexdir/lua/luatoken.c indent ------------------------------------------------------------------------ r3079 | oneiros | 2009-10-25 23:53:33 +0100 (Sun, 25 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/font/writetype0.c indent ------------------------------------------------------------------------ r3080 | oneiros | 2009-10-25 23:55:06 +0100 (Sun, 25 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/align.c M /trunk/source/texk/web2c/luatexdir/tex/linebreak.c M /trunk/source/texk/web2c/luatexdir/tex/mainbody.c M /trunk/source/texk/web2c/luatexdir/tex/mlist.c M /trunk/source/texk/web2c/luatexdir/tex/printing.c M /trunk/source/texk/web2c/luatexdir/tex/texmath.c indent ------------------------------------------------------------------------ r3081 | oneiros | 2009-10-25 23:57:52 +0100 (Sun, 25 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/luatex.c svn:keywords ------------------------------------------------------------------------ r3082 | oneiros | 2009-10-25 23:58:59 +0100 (Sun, 25 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/src/ffdummies.c M /trunk/source/texk/web2c/luatexdir/luafontloader/src/luafflib.c rm svn:mergeinfo ------------------------------------------------------------------------ r3083 | oneiros | 2009-10-26 00:17:31 +0100 (Mon, 26 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/src/ffdummies.c add some attributes ------------------------------------------------------------------------

1 0

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

23 Oct '09

------------------------------------------------------------------------ r3075 | taco | 2009-10-23 08:52:48 +0200 (Fri, 23 Oct 2009) | 2 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/src/luafflib.c fix a bug with MS Mincho whis has baseline_cnt=1, but no baseline position info ------------------------------------------------------------------------

1 0

Re: [Dev-luatex] Bug#529331: Additional issues with poppler 0.12 (which is in unstable now)
by Norbert Preining 21 Oct '09

21 Oct '09

On Di, 20 Okt 2009, Ilya Barygin wrote: > There are additional issues with poppler 0.12 which is in unstable now: Thanks Ilya, I have added the ubuntu 0.11 an your libpoppler 0.12 patch. Can you give some copyright/license statement for this patch please. Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining Associate Professor JAIST Japan Advanced Institute of Science and Technology preining(a)jaist.ac.jp Vienna University of Technology preining(a)logic.at Debian Developer (Debian TeX Task Force) preining(a)debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- WINSTON-SALEM (n.) A person in a restaurant who suggest to their companions that they should split the cost of the meal equally, and then orders two packets of cigarettes on the bill. --- Douglas Adams, The Meaning of Liff

1 0

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

20 Oct '09

------------------------------------------------------------------------ r3074 | taco | 2009-10-20 11:17:00 +0200 (Tue, 20 Oct 2009) | 3 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/pdf/pdfobj.c initialize the file pointer for \pdfobj file {} if there is no callback ------------------------------------------------------------------------

1 0

Storing more info with the hboxes.
by Javier Múgica 20 Oct '09

20 Oct '09

Recently the suggestion has been posted to the luatex bug/fature tracker that the horizontal boxes remember where they come from, for postprocessing purposes. This reminds me about one of my yet unposted suggestions, because it also has to do with the horizontal boxes storing more information for purposes of postprocessing. It could be useful if once an hbox is packed it creates two profiles, one for its upper border and one for its lower one. By the profile I mean the boder that could be seen if the boxes and rules where black rectangles. These will be "teeth-like" profiles, lower-teeth-like for the upper profile, upper-teeth for the lower one. It would consist of an array (i.e., not a linked list) recording that at distance 'x' the height raises to 'h' (or, for the lower profile, the depth goes down to 'd') and it lasts for 'width', for all the values of x where the height of the contents changes. When there is a hole, like any glue, the value for 'h' could be -\maxdimen, may be, these are just details. While from LuaTeX we may give the standard answer "you can do that with a callback by traversing the nodes of the box after it has been packed", I don't think it is actually like that: The computation involved is a lengthy one, having to dynamicaly build and modify the table as later boxes or rules overlap with previous ones (for we all now that the order of the intems inside a packed box need not be their x-order), and taking care to free the tables as they are no longer needed, a task that is better done in C. Also because it is a too low level feature, being just something that TeX does and Lua exposes to the programer via two tables, that will allways be associated with a packed hlist, in addition to the table representing its contents. It could be useful for: -- Taking into account the position of deep descenders in one line and high ascenders in the next one not to innecessarily overspace the two likes. This is the same concept as the kerning between two caracters; i.e., do not just place the boxes adjacent to one another, but take into account the contexts of the boxes being put together to produce a finer spacing, but changing characters for lines and horizonal for vertical. The way I would actualy do this is, for every teeth of the upper profile of the lower line, to take into accound the descenders of the upper line just within \keepfreedistance (say) distance. If I'd set \keepfreedistance=\maxdimen I'd get TeX's current behavour. -- Writing a smart line braking algorithm that adds penalties for "rivers". --Easy improvement of correct math placement of atoms. We had a year or so ago in the Spanish TeX list a discusion about this that originated by a user who noticed that the ^2 after \sin was higher than after \cos. The reason is the dot of the i of \sin. If the box carried its profiles with it, the algorithm for computing the height of the superscripts and depth of subscripts could take into account just the profile back to 0.5 em's distance, say, instead of the whole box as now (another primitive?) --Possibly many others that would become apparent once the feature were there and people started using it. The reason for a random access array instead of a sequenced access list is clear once we think about examples (for instance, seeking items with values of 'x' within a certain range) and, specially, on the way it would be programmed in C. In case this is ever impemented, reserving memory for n elements, where n is the number of nodes in the hlist, would waste on average little space.

2 1