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 advantages.
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]