[Dev-luatex] A few newbie questions

Taco Hoekwater taco at elvenkind.com
Wed Jan 28 10:22:53 CET 2009

Yue Wang wrote:
> Hi, Taco:
> Last week I stayed in my grandma's home (located in a beautiful
> countryside) which has limited internet access. So I planned to study
> the luatex source code during the stay. 

Shouldn't you have been out enjoying that same countryside then? ;)

> - wouldn't it be great if we remove the packed data dependency?

Yes, it would be better. It entails a lot of work though, even
for relatively small program like mplib, and there are not only

> since we can get rid of the messy web or C macros.

We would be able to get rid of the macros, but we will have to introduce
lots of typecasts or pointer indirections depending on whether the
node structure will be a heterogenous union or a listhead + data.
I have gone through that process for the exported image backend in
mplib (which uses unions, see e.g. psout.w), and it was a fair amount
of work even for that small chunk of code.

I am not saying that it shouldn't be done, just that it is not something
that can be undertaken lightly. I already intend to make metapost's
knots and knot lists use truly dynamic memory (a relatively minor task)
but I have to find a quiet time.

In luatex the problem is more complicated because pascal&web2c does not
like pointers much, so nothing is planned there until after the switch
from pascal to C(web).

> -Why can't we use IEEE floating number specification?

Please do an internet search for "megapost metapost", and you will
find some posts and presentations on the subject (most written by me).

Short summary: future versions of MPlib will incorporate either
the MPFR library ( http://www.mpfr.org/ ) or decNumber
( http://www.alphaworks.ibm.com/tech/decnumber ).

I have yet to decide which one, both have their advantages.

> TeX/MetaPost have it's own number presentation builtin. But this is a
> very complicated and strange floating number system which represent
> each number as a integer. I think IEEE floating number specification
> is good enough for implementing TeX? 

Not really, because there are portability issues wrt rounding. the
normal C "double" data type is not acceptable without an additional
library to make it behave reliably. And for MP, double is not really
precise enough anyway, so it is better jump to something more serious.

> remove the dependency of part 7 and part 9, maybe we can also make our
> code more portable on different machines.

TeX's do-it-yourself integer calculus is the most portable you can get.

> - Why should we do memory management ourselves?

It is still there mostly for the same reason as mentioned above for
the packed memory: it is a lot of work to change it.

>       Wouldn't it be great if we just ask the operating system's C
> library to handle these tasks (like using malloc and free as the
> example code of mp_new_fill_node shows). Modern operating system's
> library is more efficient, and it will also make the luatex code looks
> better.

This is true for mp.w, but I am not so sure that system malloc() will
perform better that texnodes.c (which essentially uses 10 dedicated
avail lists). Anyway, see the remarks above.

> - From the part of the code I read, if I understand correctly, the
> only reason of incorporating fontforge is to get the font Metrics
> data?

Not only that. Stuff that needs doing:

* parsing of Type1 & Type0 (CID composite) fonts
* parsing of sfnt containers (ttc and dfont)
* parsing of TTF and OTF fonts (including AAT)
* bounding box calculations for PostScript-based glyphs
  (because this information is not in the font itself)
* parsing and processing of GPOS & GSUB tables
* font reencoding
* converting to all of this to a lua table

To be honest, I have no idea how many of those things can be done
by freetype2, but I highly doubt its OTF support will be sufficient.

> If so, I think FreeType2 is sufficient to accomplish the task? [I
> think freetype2 is much smaller and efficient, and fontforge use
> freetype2]

More information about the dev-luatex mailing list