On 1-2-2011 8:54, Paul Isambert wrote:
With LuaTeX (which I don't pretend to understand exactly either), when it comes to such matters, you're alone: you're the one in charge of "text shaping", even for ligatures from pairs of glyphs (e.g. "ff"), since you're supposed to have created them when loading the font. So I don't think integrating HarfBuzz would be in line with LuaTeX's philosophy, otherwise it would be no different from XeTeX in that respect. On the other hand, nothing prevents you (the user) from calling HarfBuzz (or doing whatever you're supposed to do with it) from LuaTeX, I guess.
As for the sentence "LuaTeX should be made to do the same thing", if "should" means "it'd be good", I suppose the author hasn't really understood LuaTeX; if "should" means "it is going to happen, normally", then /I/ haven't really understood LuaTeX. What the last sentence means is obscure to me.
Again, I don't know much about HarfBuzz, and I can't obviously make any authorized statement on LuaTeX, but that's how I see things.
LuaTeX is and will remain a TeX engine, an opened up one. One of the principles is that we won't hard code solutions other than the one provided by (traditional) TeX (although unicode is the coding and wide tfm fonts are corner stones). There is the default (relatively lightweight) font loader based on fontforge. There is no universal solution and hardcoding or binding to some other library is no option, if only because they come and go, and fashion can change. The idea is to have a stable engine (as stable as traditional tex itself) that can act as basis. However, as one can load Lua libraries, any library that has a Lua interface can in principle be plugged in. So if someone wants another renderer, he/she can plug in something and as long as what gets returned suits tex's inner model (node lists) it's ok. In that respect luatex is indifferent to how/what/where it happens. Using some renderer is not so much different from using libraries to access databases or filesystems or ... So, to answer your question: no extrnal rendering libraries will be linked in by default and none will be provided by the luatex team, but one can imagine external libraries to be used that get fed data from luatex and give something back that gets fed back into the machinery. Of course, when a macro package depends on such libraries, it adds another depedency which can be a long term maintainance problem. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------