“One particular area to think about is fonts. With both XeTeX and LuaTeX able to handle system fonts directly, the basic LaTeX system seems very antiquated.”

The reason Dr. Knuth wrote TeX was to establish a way to typeset equations and text that were in the same font (see “TEX and METAFONT : new directions in typesetting” by Donald Knuth). If you enable LaTeX3 with system fonts, won’t you be getting away from this. For example, see this web page displaying fonts that are already compatible with TeX: http://www.tug.dk/FontCatalogue/. Not all of them typeset equations with the same font as the text.

As a graphic artist who typesets articles, books, etc. in LaTeX2e for math professors I don’t have a need or desire for any fonts other than the ones that Dr. Knuth made for TeX.

From the luatex mailing list, I’d say that the team are very much aware that they need 100% compatibility with (pdf)tex in default mode (i.e. anything incompatible has to be asked for). I’d also suspect that “luatex” will be the appropriate command for a long time, with “pdftex” retained.

I also think that if the “(pdf)latex” executables are ever to invoke luatex instead of etex, it must be essentially 100% backward-compatible with existing documents (and their random fonts, encodings, and so on). Not easy, but most of the world’s math is written in LaTeX. We can’t break it.

I’d suggest that the key is not to attempt to do everything in one go. If the LaTeX3 team can get a basic “micro-kernel” written, then bits can be added in a step-wise fashion. I’d imagine re-implementing the current kernel (functionality-wise but with better internals), then adding parts to the kernel rather than as separate packages. This is rather more the ConTeXt model, in many ways. Of course this would mean that LaTeX3 documents might need to alter over time to reflect the kernel changes. I realise there are a lot of big “ifs” here!

On the engine side, I think a lot of people are concerned about the possibility of “two competing, incompatible systems”. I’ve said elsewhere that XeTeX has “delivered” on its goals, and so it is down to LuaTeX to do everything that XeTeX can do (if in a slightly different way), plus all of the Lua-specific things. The reality is that at present XeTeX is a lot more accessible to users (either using plain or xelatex + fontspec).

In the end, people with programming skills develop the things they need and use, which is perfectly ok. For LaTeX this unfortunately means that there is not much coordination going on. I think few people would object to the LaTeX3 you’re sketching, the problem is that it would probably need a huge coordinated effort.

KOMA was something I had in mind for a model on what the kernel needs to do. I’d imagine duplicating the functionality, but not necessarily the interface. I forgot to say in the post that there would need to be quite a lot of interface work, even if you simply adopt many of the current CTAN packages and add code to the kernel. There needs to be a consistent interface to the functions, and at the moment that is lacking between different packages.

I agree entirely on engine requirements. At present, LuaTeX is probably not quite ready for the mainstream (for example, it’s not available in MiKTeX), but it will be well before LaTeX3 can possibly be finished. So I’d hope that the user parts of LaTeX3 can be built on that basis (most obviously fonts, but other areas as well). One thing that I’m keen on is using Lua for floating point work. I’d like to see a low-level floating point module in LaTeX3, written (at present) using strings if necessary and Lua if available. This will allow higher level modules to use Lua without needing to know about it.

While the idea that you “just have to load the proper class” is intriguing, I doubt that it’s actually feasible. The basic classes could definitely be improved, but there will always be the need for more detailled tuning. Just have to take a look at the 300+ pages of the koma-script manual …

That said, there are certainly many things which could be easily integrated into the kernel which make life easier for everybody; the user shouldn’t need to worry about encodings and font iusses, let something like fontspec deal with those things. The same for color and pdf-related features, and while we’re at it include biblatex (and csquotes) into the kernel.

As for the question whether LaTeX3 should use XeTeX and LaTeX: If LateX3 ever sees the light, it would be a big joke if it wouldn’t take advantage of those two engines. Why rely on an ancient foundation when you want to take LaTeX to the next level? There’s simply no sensible reason not take advantage of XeTeX and LuaTeX.

Simon