# [tug-summer-of-code] A couple of project proposals

Hans Hagen pragma at wxs.nl
Sat Feb 14 04:16:21 CET 2009

```Scott Pakin wrote:
> Yikes!  I didn't realize my suggestions would produce such a flurry of
> comments.  Let me try to respond to the key points that have been
> brought up:
>
> 1) A "PDFeLuaXeTeX" system is too much effort for a summer project.
>
> I didn't realize that XeTeX represented such a deep change to TeX.  I

at some point a stream of characters becomes a list of nodes; in xetex
that has to be somehow transfoemed into something that a library can
deal with and back; in luatex on the other hand it gets interfaces to
lua and both approaches are quite different; mixing them would for sure
lead to a real messy engine and all kind of interferences

> guess I had assumed that XeTeX was implemented as a set of TeX change
> files and that the student would merely have to deal with a few
> conflicts across change files and with integrating the various build
> processes.

pdftex is tex+etex+lots of pdf related things mixed into the code
xetex is tex+etex+dvi based extensions
luatex is pdftex+aleph minus overlap and some stuff, and then
reimplemented in c as well as opened up

so, indeed quite different

(after all, if tex was easy to patch, extend etc etc it had happened 20

> If a pdfLaTeX+eTeX+LuaTeX+XeTeX system is as tricky as everyone here
> is claiming, then a good alternative is what Arthur Reutenauer and
> Mojca Miklavec brought up: integrating XeTeX's font support at the
> macro-package (viz., fontspec) level, presumably using Lua to
> interface with external font libraries.  I'm sure that being able to
> write things like \setromanfont{MyObscureSystemFont} in a LaTeX
> document would be a great boon to LaTeX users.

that's just macro level, so it will eventually happen (as fas as i
understood some latex users are working on it); the luatex engine
permits any interface but will not have hard coded solutions

Hans

-----------------------------------------------------------------