Like the title says, is there anything about the system you're using that you would like to change? Some annoyance that should be fixed, some feature that could be improved or added?

  • 10
    This is very open-ended and opinionated question. StackExchange sites and TeX-SE in particular are not good for this kind of discussions. Feb 12 '11 at 9:31
  • 6
    I think the question is borderline acceptable, as long as it gets good (i.e. well-reasoned) answers. However, it should probably be closed after some time before it starts to accumulate lots of answers from people who just want to vent their frustration with TeX.
    – Caramdir
    Feb 12 '11 at 18:06
  • 2
    @Caramdir This can (perhaps) be prevented by making the question protected. In fact, I’ll go ahead … Feb 13 '11 at 14:24

12 Answers 12


One area of TeX which needs to be improved is math spacing (starting from 2007, Word does better than TeX in this area). The TeXbook (in chapter 18) recommends quite a few manual adjustments most which could (and thus should) be automated (and the list is not complete). Here are a few examples, with the correct spacing below (the cos²+sin² is a bit subtle as it’s a thin space instead of a medium space, but it is an important change since it also changes the shrinking and stretching values):

examples of bad math spacing by TeX

The problem is that the 8 spacing classes (\mathord, \mathop, \mathbin, \mathrel, \mathopen, \mathclose, \mathpunct and \mathinner) are not enough to cover all the cases. You would need at least the following supplementary classes: \mathnull (no spacing at all, for / and the backslash used as quotient), \mathfact (for factorials), \mathsqrt (for square roots) \mathdiff (for differentials in integrals) and \mathdpunct (for double punctuation like : and ; in French typography, in which you want a thin space both after and before).

  • 10
    these are good ideas, you might consider adding a feature request at tracker.luatex.org. LuaTeX already does much better than TeX (essentially implementing Word's algorithm), but there are still huge gaps.
    – Philipp
    Feb 13 '11 at 22:23
  • 1
    @Philipp: Is the exact algorithm used by LuaTeX documented somewhere? Jan 13 '13 at 15:52
  • 2
    @HendrikVogt: mostly the source code is the documentation. MS has released a paper about OpenType math typesetting, but that's far from complete, so some parts are just reverse-engineering whatever Word does.
    – Philipp
    Jan 13 '13 at 18:09
  • @Philipp: Puh, I had a look but couldn't locate the algorithm. Do you know in which file I should look? Jan 14 '13 at 13:54
  • @HendrikVogt: foundry.supelec.fr/gf/project/luatex/scmsvn/… files texmath.w, mathcodes.w, and mlist.w
    – Philipp
    Jan 14 '13 at 22:43

TeX is a system written by a genius, and it has many great features, but the underlying architecture is flawed. The programming interface, and the programming mechanisms provided within the system contrast the intuition of most computer programmers. The list of idiosyncratic features is too long to enumerate:

  • Character codes and non standard lexical analysis.
  • Clumsy support for imperative programming, including numbered variables of a limited number, no variable names, no control flow, no boolean type, etc.
  • Use of Pascal.
  • Arbitrary constants and numbers (file numbers, character codes).

In short, if I could do it all over again, I would (a) use a decent modern programming language for the implementation (b) design a clean programming interface, including the usual tools of the trade, block structure, typed named variables, procedures, exceptions, and, yes, even object orientation.

Finally, I would (c) apply a clean design which does not reveal or discuss issues such as mouth, stomach, and \expandafter, and of course, I would write a book without dangerous curves signs...

  • 3
    @Yossi: see you in a few years ;-). Feb 12 '11 at 17:52
  • 3
    @Bruno: Indeed! But, please think about it---the implementation of a new programming language is usually not considered an insurmountable barrier. What is it about TeX/LaTeX that makes both of us think that it would be next to impossible to redo it the right way?
    – Yossi Gil
    Feb 12 '11 at 18:34
  • 4
    The history of failed attempts and the need to be 100% backwards compatible (including bugs)?
    – Caramdir
    Feb 12 '11 at 18:38
  • 5
    You can use LuaTeX to create such a system without reimplementing everything from new. Use TeX's algorithms and your implementation/api/...
    – topskip
    Feb 12 '11 at 20:57
  • 5
    @yossi: i'm never sure what people mean when they say (or imply) "tex is flawed because it's written in pascal". tex is flawed because it's an old program, written when there were few serious general-purpose languages (other than fortran and the like) available; knuth's choice of programming language seemed to me, when i first encountered it, as entirely reasonable -- indeed, i wrote an embedded os in pascal in the mid-80s, long after knuth's "modest" effort... i don't doubt the use of pascal makes patching difficult, but i don't believe it contributed to any of tex's "original sins" Nov 9 '11 at 7:20

Top 1 on my list: (1) better error messages and (2) better debugging facilities.

  1. I found it notoriously hard to understand LaTeX error messages, especially if "advanced" document classes (such as beamer) or packages (such as biblatex or hyperref) are involved. (For instance, with beamer frames the reported error location is often just the closing brace of the frame.)

  2. Even more difficult, at least for the beginner to intermediate developer, is the debugging of own macros. Using \show and \meaning is IMHO painful. What I really would like to have is a "symbolic" debugger where I could step through the expansion process to understand what is going on.

  • 2
    Have you tried \tracingall?
    – morbusg
    Nov 9 '11 at 16:25
  • 3
    \tracingmacros=1 tells you exactly each step of the expansion; e-TeX has added also \tracingifs.
    – egreg
    Nov 9 '11 at 16:39
  • 1
    After using LaTeX for a while, I have been recently learning TeX (highly recommend the book by Seroul & Levy), and I find that the error reporting is quite good. What has happened with LaTeX is that the macros of LaTeX, and certain packages, do not devote sufficient care to error detection and reporting (sometimes due to then-justifiable constraints). So we see error messages that come from the bowels of TeX: in terms of what TeX sees, rather in terms of what you typed. (It seems that if one used TeX for typesetting and did one's programming elsewhere, the results would be quite pleasant.) Feb 20 '17 at 22:01

I think too many parameters and algorithms are "hard-wired" into the TeX engine, in particular when it comes to math typesetting. One example is the algorithm for placing a sub- and superscript combination, which sometimes leads to undesirable results, as I explained in this answer. (Very strange: The distance of a superscript from the baseline is at least 80% of the x-height only if a subscript is present and by default too close to the superscript, otherwise the superscript is allowed to be lower.)

It would be great if some improvements in this direction could be included in LuaTeX.


I hope that the author of XeTeX spends some time and fixes XeTeX bidirectional primitives bugs and also adds few new primitives as already suggested. Doing bidirectional macro programming with various bugs and shortages of XeTeX in terms of bi-directionality, has been a headache for me.

  • 2
    Let me second that.
    – Yossi Gil
    Feb 12 '11 at 16:46

Nice automagickal default spacing, alignment and line-breaking in display math mode and in tables, with the user not having to rake his/her brain about whether to split his gathered's or align his multline's or start his tables with {p{\wildguess}|cpr|@{h}lp||pl@{z}}. You should be able to write a really long equation, or a table, and for that to "just work".

  • 4
    +1 for p{\wildguess}.
    – lockstep
    Nov 25 '11 at 23:56

For me, it's about simplification:

Package integration

Integrate some of the most common packages into LaTeX directly, e.g. array for tabular extensions, geometry for page dimensions, fancyhdr for headers and footers, etc.

I think we could determine a limited number of core packages that implement very common features, iron out whatever incompatibility / instability / missing feature they still exhibit and integrate them into LaTeX.

LaTeX currently require (trained) users to load the same packages over and over to do simple things like produce a right-aligned fixed-width tabular column, and, even worse, forces new users to waste time figuring out how to achieve this.

Package rationalization

Combine / throw out unmaintained or redundant packages. This is probably a very touchy topic, but I think having 5+ packages to achieve the same thing is a waste of resources. For example, shouldn't we agree that biblatex (example!, please don't shoot me...) is the way to go for bibliographies, integrate whatever missing features from natbib, multibib, etc. and slowly depreciate these packages?

It would be very challenging to find the right balance on when this "rationalization" should kick in (we shouldn't discourage anyone from creating new packages), but I believe that sometimes there is too much choice for beginners, and too much work for class / package writers that want to ensure compatibility.

Engine & fonts

This is a long shot, but if we could move everyone over to LuaTeX, integrate fontspec (see first point) and provide a base of great fonts in Open Type (no more Type 1, no more cm-super etc.), I believe TeX would be more attractive to more people.

Or to put it differently, I think that a combination of a simplified font system / handling with a selection of great free fonts (from such foundries as The League of Movable Type, exljbris, etc) would attract a much more broader base of "regular" and "creative" users than today.


Surprisingly high on my list: not calling that verbatim-handling macro \next. I think

"file ended while scanning use of \next"

(or whatever the phrasing is) is the archetypical meaningless error which you have no chance to fix unless you happen to already know it's caused by the \end{...} of your verbatim-like environment not starting on column 0. I think somebody reading the code would have less problems with a not-quite-appropriately-named \getnextverbatimline or whatnot than the normal user has with \next.

  • 4
    how is this infelicity of latex relevant to a discussion of tex itself? Nov 9 '11 at 7:26
  • 4
    How is "What would you like to change about TeX/LaTeX/XeTeX/etc.?" a discussion solely of the tex(1) executable? (Never mind the fact that the unfortunate naming dates back to the TeXbook, as far as I recall.) Nov 9 '11 at 8:44
  • I'd change the (0,0)-point of the page to be at the top left corner of the paper, instead of assuming it's one inch from left and top (although note the later --compat).
  • Some of the plain macros are defined in terms of points, I'd change those to use em's and ex's instead (i.e., relative to the used typeface).
  • If I were to re-implement TeX (lol!), I'd do it with a multi-paradigm high abstraction level language with a consistent syntax. Although I do understand why one would seek to achieve efficiency over everything else; to quote Knuth from TAOCP Vol. 1's Preface:

    For example, some combinatorial calculcations need to be repeated a trillion times, and we save about 11.6 days of computation for every microsecond we can squeeze out of their inner loop.

    That's a nice angle! But maybe not one which fits the nature of TeX, though. At least not to the point where efficiency goes over everything else. What with the compiler targeted instruction sets and all.

    So I'd be choosing cost of programmer time over the cost of computation time, and a language which has survived even longer than TeX itself.

    I'd make it backwards compatible with a toggle --compat, but without that option flag, it would handle math much in the same way Philippe describes with some additional exceptions for constants for example.

    If I'd choose the other way around, efficiency over everything else, that just would have to be done in MMIX for a custom computer! ;-D



Transforming boxes to tokens and back

I very often find myself in a situation where I would like to

  1. find out exactly something which is "hidden" in a box (say, is there a hyphenation at a specific line, or how much is glue stretched)
  2. make a small modification to a box's contents

It is possible up to a degree to analyse box contents with \lastbox, but as the name already says, any kind of box content which is not a box or glue or kern or penalty (like rules, characters or specials) makes the analysis futile.

In particular, it is impossible this way to analyse and recursively reconstruct a box in a modified way, apart from trivial cases.

So I'd basically like two primitives:

  1. Transform a box into a token list
  2. Transform a token list (which was derived from a box) back into a box.

Needless to say, transforming a box into a token list and transforming that token list back to a box should always reconstruct the same box.

Mind you, I am not talking about transforming a box back into the tokens it was originally generated from (which would mean, say, "undoing" paragraph formatting), because that process is a "trapdoor" function.

All the tokens in the token list could be special just for representing box content, as long as I can analyse and modify the box in all respects by analysing the token list.

If you look into the log listing of a box:

..\vbox(548.5+0.0)x390.0, glue set 505.11273fil
...\glue(\topskip) 3.66669
...\hbox(8.33331+2.33331)x390.0, glue set 320.08823fil
....\OT1/cmr/m/n/12 s
....\OT1/cmr/m/n/12 o

then I would be perfectly content to get everything listed there as a sequence of (nested) tokens, as long as all information and content is there in "parseable" form.


"Weak" groups

I've found myself quite a few times trying to temporarily modify a macro, but this method has some very real problems:

\bgroup <stuff> \def\x{\egroup <more stuff>} \x

In particular, if the first "<stuff>" defines any macros, they'll be lost when \x is performed. A certain kind of "weak" group that all \defs "escape" by default except stuff explicitly declared so would be nice. That way you could write stuff like this:

  % make any subsequent changes to \a local to this weak group:
  \weaken\a % or \weakencsname a\endcsname.
  <do stuff with \a>
\ewgroup % the weak redefinition of \a disappears in a puff of logic.
\a\b % no error. They are both equal to \relax

instead of

\let\OLDa\a % and *hope* that \OLDa is not defined already
<do stuff with \a>
\let\OLDa\undefined % and *hope* that \undefined is actually undefined

Exporting macros out of an enclosing group

If for no other reason than the fact that this would make writing packages safer since you would know that anything you didn't explicitly export could not pollute the global namespace (speaking of which... namespaces would be nice too)

  \a % no error. The definition of \a was exported 1 group level outwards.
%\a % error. \a is not defined here.

I'm missing a paragraph rebreak feature when part of a paragraph is carried to the next page during a page break. When one has to change the page width, e.g., from page 1 to page 2 of a letter, this would be very useful!

Not the answer you're looking for? Browse other questions tagged or ask your own question.