Improving LaTeX for the user

I’ve been discussing some points about the future of (La)TeX with various people, and some key issues come to mind. Most LaTeX users do not want to meddle with the internal parts of LaTeX or TeX. In an ideal world, I suspect most users would like to need little beyond the correct document class to get things “just right” in their layout. Perhaps a few simple settings, but really little more than that.

With the correct packages and class loaded, you can do many things in LaTeX. However, you really shouldn’t need to load specific support for hyperlinks, T1 encoding, basic font changing, creating new float types and so on in 2009 (let alone 2010, 2011, etc.). The efforts of the LaTeX3 team have to date focussed on programming and to a lesser extent document design. How things will work at the user level is much less clear.

I’d suggest that a real focus on getting something for users would be the best way forward. This might mean less improvement internally, but I’d think that a LaTeX kernel which could do everything in The LaTeX Companion would be pretty successful, even with few changes “under the hood”. This would mainly be a re-coding excercise from existing packages, which in a way is similar to what I’ve tried to do with siunitx. Much of the basics in siunitx are taken from other packages (at least in terms of user interface), but it brings several ideas together in one place. The same idea could easily be applied to the kernel. Of course, this might leave some of the clever ideas for LaTeX3 out of the code at this stage, but I’d hope would get momentum behind a more regularly updated system.

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. At present, LaTeX3 only requires e-TeX, not LuaTeX (in contrast to ConTeXt Mark IV). Should the LaTeX team say something like:

For current testing purposes, only the e-TeX extensions are needed, but this is likely to change. XeTeX or LuaTeX will be required to run the release version of LaTeX3 with full functionality.

I’d say yes, as I think that it’s time to move on from complex font installation and usage restrictions. I’d also be very tempted to say that LaTeX3 will assume UTF-8 input unless otherwise specified (as both XeTeX and LuaTeX are native UTF-8 systems).

This type of approach will make LaTeX easier to use, and I’d hope to see it arrive! After all, users are the TeX community.

9 thoughts on “Improving LaTeX for the user

  1. I most definitely support this approach. Over and over, I’m astonished how many people still don’t use UTF8, although there’s simply no reason not to use it (ok, there still are editors which don’t support UTF8 – something I don’t understand either).

    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

    • When I said about “just loading a class”, I was not necessarily thinking about the core classes (although these should be improved and there should I think be more of them). I was thinking more that even if there is a dedicated class for what you want to do, there is still too much need to load additional packages. Of course, part of that is down to whoever writes the class, but I’d hope the situation can be improved if not completely sorted. Part of this depends on what exactly packages are loaded for: if you want some specialist functions there will always be a need to load extra stuff. As you say, I’d also favour including things like biblatex, csquotes, etc. (at the user level, with whatever internal changes actually happen). Let me rephrase as “most users should not need to load support packages to alter formatting or carry out common tasks, although there will always be specialist packages for particular areas and effects”.

      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.

  2. On the packages issue again, one problem at present is that if you use a custom class, the class author will probably load various packages to achieve particular effects. If the user then wants to adjust something simple, the correct package may or may not be loaded. With a “rich” kernel, every class will have a lot of adjustment available without loading anything else. So this approach would make it much easier to make some small adjustment, say to the appearance. The same method would apply to a standard class as to a custom class.

  3. No objection from me. Most the stuff you write makes perfect sense, but unfortunately, in the end only one question is relevant: Will it ever come and if it does – when? The essential problem of the TeX world is IMO that significant changes are always the result of the efforts of a few individuals and very rarely of a coordinated group: XeTeX is the work of Jonathan Kew, LuaTeX is mainly done by Hans and Taco, and there is little exchange between the projetcs. I fully realize that these projects have different goals, that there is little technical overlap between them (and it’s good to see that Taco tries to achieve some level of compatibility, for example, when it comes to math). But I think it is symptomatic that we now have two “next generation engines”. Or take biblatex: BibTeX’s limitations have been known for years, but it took the effort of one individual to come up with a modern replacement (which many people still have never have heard of).

    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.

  4. You are quite right about the “small groups of dedicated individuals” problem. ConTeXt is the same, but I note that it does manage quite wide coverage (I’d say similar in scale to what LaTeX3 needs to cover to succeed).

    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).

  5. Joseph, as you and I have discussed, I think LuaTeX + LaTeX is the best way forward for the future, in general. It will open up TeX work to a whole new group of people who are unwilling to deal with TeX’s arcane macro language.

    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.

  6. I’d agree about LuaTeX (once I’ve got the hang of it, I’m sure I’ll have more to say).

    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.

  7. I wish to comment on this statement:

    “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.

  8. The need for easier font access depends on what you are doing. For typesetting maths-heavy material, the limited number of good maths fonts does restrict things somewhat (although I note that Microsoft are working hard on this area, amongst others). However, a lot of (La)TeX users need little or no mathematical content. I’m a chemist, and the only “mathematical” things I need are variables such as “T” for temperature (which can be set using the italic text font). For those working in the humanities or on non-academic material maths is really neither here nor there. Fonts are, however, and the current approach (loading a specialised package for each font, if one exists). Hence the need for a more user-friendly approach, in my opinion. Users of the fontspec package already have that, and I’m essentially saying that the kernel should provide a similarly user-focussed interface.

Leave a Reply