# What can't TeX do?

What are TeX's limitations in typography, book design and publishing? (and here TeX also includes all its derivatives, like pdfTeX, LuaTeX, and macro packages built upon it, LaTeX, ConTeXt etc.).

Some things (like math and references) are extremely easy in TeX. There are some things that are harder to do in TeX-based systems, but they are possible, even if cumbersome (like precise control of images' placement or manual control over layout and design). Solutions to some problems have been found (like microtype). Some things are rarely talked about (like color profiles).

Please mention what is either extremely hard to achieve with TeX or is not possible at all (due to inherent limitations of TeX, or due to bugs/limitations in the available tool chain). Please mention also which technological steps do not fit well with TeX workflow.

-
I think this is an acceptable question for this site, as a community wiki, where people should answer one tex limitation per answer. – Lev Bishop Sep 4 '11 at 14:56
Color profiles are not well supported in latex, although you can always use raw pdftex primitives if you know what you want. I believe Context has good support for them though. – Lev Bishop Sep 4 '11 at 14:58
I think the question should be closed or reworded. There are things that TeX can't do at the moment, but things change and the answers will possibly invalid in the future and therefore misleading. - If we answer the question, we should define first what TeX is. – topskip Sep 4 '11 at 17:35
Well TeX can't prevent the coming Apocalypse, for example... – Yuji Sep 4 '11 at 17:51
I was tempted to post something along the lines of @Yuji ... TeX can't bake cakes :) As for the rewording: I guess it makes sense to specify the current state of TeX in some way, and also to ask about limitations or borders, to indicate the relatedness of the impossible tasks, which is implicit so far. – doncherry Sep 4 '11 at 22:06

TeX has no real way to do river, lake and hole elimination. This would require a much more expensive paragraph layout algorithm than the Knuth and Plass dynamic programming.

-
I think it is possible but impossible within manageable time. It is possible to implement such an algorithm in Lua or even TeX. But I only heard of such an algorithm at the order O(n^3), cannot remember where I read about it – Yan Zhou Sep 4 '11 at 15:06
For more discussion on this see question 4507: avoiding-rivers-in-successive-lines-of-type – mas Sep 4 '11 at 16:08
Are there other programs that are known to avoid them automatically? – ℝaphink Sep 5 '11 at 16:28
@Raphink ant.berlios.de (Ant) states that it does so, but even with the help from the author I was unable to see any river elimination. (I did a bit of research on that area). And there are rumors that InDesign does that, but there is no official note from Adobe about that, so river elimination is probably due to the total fit algorithm in ID. – topskip Sep 7 '11 at 6:00
@ℝaphink Yes: Patoline – yo' Mar 8 '13 at 21:49

The definitive answer to this is perhaps Donald Knuth's own answers, given in an earthshaking announcement in 2010 and recorded in this video and transcribed in the TUG journal, TUGboat, Volume 31 (2010), No. 2, pp121ff.

-

Some things that are perhaps possible in TeX (with some programming) but not built in LaTeX or plain TeX itself:

• Automatic paragraph flow around arbitrary shapes (like images)
• Autokerning based on the shape of the glyphs
• good multi column support (balancing, images/formulae crossing multiple columns)
• text areas with overflow capabilities ("read more on page 3")
• Output to an "open" format such as InDesign (for editing afterwards) or XML
• Some way of splitting a vbox at a point (should break an image in two parts for example)
• XML input
• This list could be continued, but you get the point: magazine layout is not easy in TeX
-
you should divide this list into separate answers, since as you say, some of these have solutions, whereas others have only partial solutions/workarounds or could only be solved in principle with tricky tex programming that nobody has done yet. If you put it into separate answers, people can more easily edit in additional information. – Lev Bishop Sep 8 '11 at 15:21
Very good answer. Thank you. – sastanin Sep 11 '11 at 8:31

One of the things that are impossible in TeX90 is typesetting the first line of a paragraph in a different font than the rest of the para - with the possibility of hyphenation between the first and second line.

EDIT: It seems the magaz package implements this.

-
Are you sure? \documentclass[11pt]{article} \usepackage{lipsum,magaz} \begin{document}\FirstLine{\lipsum*[6]}\end{document} – Will Robertson Sep 5 '11 at 16:01
@WillRobertson: No, I'm not sure anymore. Thanks. :-) – Martin Schröder Sep 5 '11 at 16:20
There are some limitations to this approach, though, such as that it will break if there's much more than plain paragraph text. But overall a nice solution as far as it goes. – Will Robertson Sep 5 '11 at 23:00

TeX does not perform a global optimization of its cost functions but does so on a page by page basis. While I think it might be possible to solve this without touching the kernel, this must be pretty hard to do efficiently and transparently and I am not aware of any package that has tried to do this.

For an example of the practical effects of this deficiency, see How to spread floats automatically over a whole chapter?

I stole this picture from there:

-

TeX was not really designed for fully automatic typesetting, as you may want when the source document is computer-generated (for things like database reports or equipment manuals), or needs to be typeset in many different page geometries. These things are possible, but they need some care. The main problem is that TeX wants to set beautiful paragraphs and if it can't do that, then it throws an overfull hbox and expects the author to deal with it (eg, by rewording the offending text, or marking additional hyphenation locations). Some discussion of lowering TeX's standards is in this FAQ answer, which will eliminate overfull boxes, but it's still true that TeX is at it's best at when beautiful paragraphs are possible.

Here's an example:

\documentclass{article}
\usepackage[text={3.01cm,8in}]{geometry}
\begin{document}
{%Help TeX not to give up too easily....
\tolerance=9999
\setlength{\emergencystretch}{1em}
TeX was not really designed for fully automatic typesetting, as you may want
when the source document is computer-generated (for things like database reports
or equipment manuals), or needs to be typeset in many different page geometries.\par}

%I'd rather see something like this
TeX was not\break really designed for\break fully automatic typesetting,
as you may want when the\break source document is computer-generated (for
things like\break database reports or equipment manuals), or needs to be
typeset in many different page geometries.
\end{document}


Result:

Automatic breaking of displayed equations is another difficult aspect of automatic typesetting, although the breqn package makes an attempt at this.

-
sorry, but this is simply false. You can tweak linke breaking, so that no overfull boxes will be generated. You can do even multi pass line breaking with different parameters, so that you really get the best paragraph shape. In our database publishing software (speedata.github.com/publisher) that we use for creating high quality product catalogs (100% automatic) we get awesome typography due to the full control we have over TeX. – topskip Sep 7 '11 at 6:04
@Patrick: That sounds really interesting! I haven't been able to find any examples of the documents produced with Speedata Publisher on your website. Is there a showcase somewhere? – Jake Sep 7 '11 at 6:17
@Jake Not yet. We are still in the process of opening our software. There is even no english translation of the manual yet. We will have a more or less finished package by spring 2012. – topskip Sep 7 '11 at 6:24
@patrick: if the situation is easy: short words, wide textblock, long paragraphs, then beautiful (or at least decent) paragraphs are possible, and TeX will certainly find them. If the situation is difficult: long non-hyphenatable words, narrow columns, short paragraphs, then many paragraphs will need to be ugly. Yes you can tweak the parameters so that TeX doesn't produce overfull boxes in such cases (as I wrote), but still TeX's formula for "badness" (sum of cubes of the stretches/shrinks) isn't optimal for choosing which ugly paragraph is least bad. I edited my answer to clarify. – Lev Bishop Sep 7 '11 at 6:25
@Lev but then the typesetting task is simply impossible or extremely hard and this is not TeX's fault. Show me a formatter that is better then TeX (with a specific paragraph). IMO TeX is by far the best software out there for unattended typesetting and for database publishing (in terms of speed, quality, robustness, features and so on), and this is why we chose TeX (specifically LuaTeX) for that task. – topskip Sep 7 '11 at 6:32

To shamelessly copy and paste from the answer so that SX won't auto-comment my answer anymore:

Tex/Latex have what is called monolithic state: you can't cleanly isolate the configuration done by one package from another, which is one of the reasons why incompatibilities are possible. This means there is no way to identify how to undo what changes the \usepackage command has caused.

-

TeX, and Lua in LuaTeX are both Turing complete languages. So they should be able to do pretty much anything.

However, some things are more difficult due to the limited sets of features of the language. Some other things requires new algorithm, which may not perform reasonable well (Say it requires O(n^2) or even more computing times.

One particular example I can think of is Grid typesetting. This is one thing I always one to do but haven't found any elegant solutions in the TeX world yet.

-
No, TeX being Turing complete does not mean that in principle it can do "pretty much anything". One major point is that TeX doesn't know how the glyphs it uses look like - it only knows the bounding boxes. (This question of mine gives an idea what I mean.) – Hendrik Vogt Sep 4 '11 at 16:29
Grid computing is no problem with ConTeXt and there is also a solution with KOMA-Script, but I didn't find it – Herbert Sep 4 '11 at 16:29
@Herbert: That's the gridset alpha package -- but it provides only a partial solution (a \vskipnextgrid macro). – lockstep Sep 4 '11 at 20:38
In my experiments, I've found out that grid isn't a problem until you have inline maths. – morbusg Sep 7 '11 at 6:25
I wonder why you do your typesetting in TeX then at all. Just use a Turing machine – it can do everything TeX can. – Christian Jun 22 '13 at 14:57

Automatic splitting of floats for a better overall look (http://tex.stackexchange.com/a/4682/13450).

This is of course related to the general problem of a lack of global optimization but more specific. It would be nice to have floating text environments (tables, listings, text boxes, subfigure collections ...) that were split into two smaller parts if this were to improve the overall layout of the document (footnotes already do something like this).

-

TeX and LaTeX is not really good at constructing dictionary-style texts.

It's really designed to expect tables and text as separate entities, and is not really good at flowing text from one minipage to another (like in magazines - continued on page ...).

One document i am writing at the moment, has a formatted set of formulae definitions, followed by a few paragraphs of text, and then a few more formulae, and then more text. I am currently doing this with the {tabbing} environment, with the \kill line set in the preface sections. It works, i suppose.

I'm still trying to get hanging numbers to work. Some places, such as running text, it is appropriate to use hanging numbers, rather than block numbers, but i can't see how to do this. I downloaded a package printnum where the documentation is in hanging numbers in the required style, but it's set to decimal, rather than twelfty.

-

TeX is Turing complete, therefore it can do anything any other language can do. Therefore it can't do anything any other language can't do.

-
Please see the existing answer by Yan Zhou and the discussion under that post, especially the comment by Hendrik Vogt. Repeating this fundamental misunderstanding of what computability means doesn't make it any more true. This post also can be read as alluding to mysticism in that there are real physical entities that can do something computers principally can't (mostly humans are these entities). While you might hold this belief, it is note what the Church-Turing thesis states. – Christian Mar 26 '13 at 14:46