# Am I programmatically tieing my hands behind my back by insisting on a particular engine?

I've read Differences between LuaTeX, ConTeXt and XeTeX, but still have a niggle at the back of my mind that I'd like to ask about.

I'm developing a LaTeX package/class/stuff with the aim of making it possible for me to write any document I like in LaTeX even if the output format is not PDF/DVI/PS (see Getting LaTeX on to the Web for the backstory). Because this is subverting TeX ever-so-slightly, I end up having to do a bit of tinkering under the bonnet. Because my TeX skills are somewhat basic, I often wonder if I'm going about things the right way. Let me give two pertinent examples.

1. There are several times where it is convenient to use catcode changes to implement some stuff. For example, making `^` active so that I can preprocess the stuff that is about to get superscripted. But messing around with catcodes is part of the Dark Arts and it seems that wherever I actually do the catcode change I end up in trouble. One of the simplest bits of trouble is when a macro argument is read in but needs a catcode change in the middle. When I get to this point, I find myself thinking:

I could do this by cunning auxiliary macros and other `\aftergroup` nonsense or ... I could say "Stuff it, I'll use `\scantokens`".

2. The eventual output is text, but it has to go through PDF and then a pdf-to-text converter. I want some ligatures, such as `--` to an endash and quotes, but not most ligatures. As the eventual output is text the actual font doesn't matter so I could create my own that suits. When I get to this point, I find myself thinking:

I could spend ages sorting out all the `.tfm`, `.afm`, `.ttfn` files or ... I could say "Stuff it, I'll use `fontspec`".

The point is that if I insist on using a particular engine, I could go for the easy options.

Now, the primary purpose of my package is to make it easy for me to write documents using my familiarity with LaTeX. It is not not not for converting existing LaTeX documents to some other format. Nonetheless, I would like to make it useful for other people to use, and experience says that the first use most will put it to is to convert some existing document to some other format (who reads the manual these days?).

So assuming that I put in some instructions on which packages to add or remove (thinking mainly of fonts), my question is this: is there anything in terms of the basic programming functionality of the different engines that I need to be aware of?

In more direct terms, if I think purely with regard to primitives, is there a total order on the engines: TeX < eTeX < XeTeX < LuaTeX? Or, is there anything that TeX can do that, say, LuaTeX can't?

-
Certainly XeTeX and LuaTeX have some complementarity due to differences in approach: 'link to libraries' versus 'do it in Lua'. – Joseph Wright Feb 19 '13 at 16:29
@JosephWright What I'm trying to ask is "Does that make any practical difference?", particularly if I'm not bothered about fonts. – Loop Space Feb 20 '13 at 9:35

First to some specifics,

is there anything in terms of the basic programming functionality of the different engines that I need to be aware of?

Other than LuaTeX is a different kettle of fish, offering a better programming interface the other engines have pretty much the same functionality or functionality you can emulate.

is there anything that TeX can do that, say, LuaTeX can't?

Run on its own without the use of another external program!

And now for some more general comments. In general there is always somebody better than us in something, maybe coding, maybe maths. What I try and do is to first understand my own limitations and take a ...hey it works approach. Once I get there I then try to improve to something better and or optimize a bit. So if you feel more confident with one engine rather than another start from this engine.

Personally as far as TeX coding is concerned I have great admiration for quite a few of our users code and especially for Oberdiek's work. Most of his packages, as far as I know can run in all engines and he does a great job in maintaining them (see `intcalc`) for example. He has quite a few packages that emulate LaTeX commands so that you can run the packages virtually in any engine. Same for PGF. If you want this level of portability you need to have fallback routines for any engine --- fallback fonts engine detection routines and the like. Dave's `docstrip` is another good example.

Most of the principles of TeX, such as being able to reproduce the same document on any computer exactly and its ability to be ported on any computer, are good principles that stood well in the test of time. If you can incorporate them in what you do you can only benefit from it in the long run.

To summarize, my suggestion get it to work within your abilities and framework and then make it more portable.

-
What dependencies does luatex have, then, that mean it can't run on its own? I agree that backwards compatibility is admirable, but I've also seen code that ties itself in knots to achieve it and since I don't need it then I'm not sure that tying myself in knots is worth it for its own sake. – Loop Space Feb 20 '13 at 9:37
Andrew ... this is from the manual ...Features may come and go. The current version of LUATEX is not meant for production and users cannot depend on stability, nor on functionality staying the same. It has a lot of dependencies such as pdfTeX, fontforge the current version of Lua etc. But as I said in my answer, go for it and then if you want to generalize your package do so at a later stage. – Yiannis Lazarides Feb 20 '13 at 14:56
Yiannis, thanks for the clarification. It was the "Run on its own without the use of another external program!" that I wasn't sure how to interpret. – Loop Space Feb 20 '13 at 15:09