18

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?

Community
  • 1
Andrew Stacey
  • 153,724
  • 43
  • 389
  • 751
  • 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. – Andrew Stacey Feb 20 '13 at 09:35

2 Answers2

9

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.

yannisl
  • 117,160
  • 1
    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. – Andrew Stacey Feb 20 '13 at 09:37
  • 1
    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. – yannisl 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. – Andrew Stacey Feb 20 '13 at 15:09
4

That is a good question, and a wonderful first answer. For some reason, the board bot put this thread in my login results, and I believe I have something to offer.

I am the developer for the novel document class. It is not one of the LaTeX standards, but is installable. I wrote it after I already used it privately for a printed (to paper) book, by way of sharing.

Have little TeX programming skill, I restricted usage to only lualatex, and since this document class is intended for fiction (not academics), I disabled many standard TeX commands that would have different meaning for knowledgeable and non-knowledgeable users. In other words, I subtracted programming features, rather than adding them. The package documentation quite clearly tells potential users that they are restricted to doing what they need to do, rather than everything possible. In particular, only lualatex is supported.

Others have liked novel, if they are actually writing fiction. And, here at SE, yet others have asked why novel does not do something that they could have done using book or memoir. (Answer: live with it.)

So, to the original question: Is your document class, or package, intended for a specific purpose, with specific user base? If so, it may be a good idea to limit the compiler, and maybe limit such other things as LTR/RTL language, use of fonts, and so forth. Anyone who cannot use your code has many other TeX choices, so there is no need to please everyone.

rallg
  • 2,379