# Typesetting limitations of LaTeX

What are the typesetting limitations of LaTeX? In other words what are the things that desktop publishing and word processing programs do better than LaTeX? I am not really interested in things that are better left to the editor (spell check, grammar check) or some post processing program (track changes, word count), but rather typesetting type issues. For example, LaTeX and I really struggle with suppressing page breaks and changing paragraph size. I think even MS Word can do these things better (although it is obviously much easier when you are ignoring the badness of the paragraph). Are there other things? Is there a list or a reference somewhere?

EDIT In regards to the comment by alfC, in the bigger picture the question is what functionality is currently missing from LaTeX (and packages) that exists in other programs. Things like rivers are still difficult from a conceptual standpoint, while resizing a paragraph and preventing page breaks are easy to conceptualize (but difficult to solve).

-
Maybe not a proper answer and somehow pedantic, but TeX is a Turing complete language (en.wikipedia.org/wiki/Turing_completeness), so any well defined "computable" typesetting algorithm is in principle doable within TeX/LaTeX. How difficult can it be to implement or if it is already available in the form of a package is a different question. Also it does not apply to heuristic/vague typesetting requirements, that in effect may be hidden in professional commercial software packages, but if they were known it can be implemented. – alfC Sep 10 '12 at 8:23
I see. Just out of curiosity, What difficult problems you know that are solved in other word processing programs? Are rivers solved? (in Word?). – alfC Sep 10 '12 at 8:47
You might want to watch Frank Mittelbach's talk at TUG2012: he covers things that are hard or not possible at the engine level. – Joseph Wright Sep 10 '12 at 9:17
Somewhat related to tex.stackexchange.com/questions/58501/a-critique-of-tex – lhf Sep 10 '12 at 11:25
@alfC, at the risk of being overly pedantic: As I've pointed out before, TeX being Turing complete doesn't mean that TeX can solve any typesetting task. One major problem is that it has hardly any information about the distribution of "ink" in the bounding boxes of characters. For example in this question of mine I don't see how Turing completeness would help. – Hendrik Vogt Sep 12 '12 at 7:50

A comparison of TeX's capabilities that can be used reasonably efficiently (ignoring the Turing argument as it doesn't really help much) with high-quality craft typography has been discussed by me in the article E-TeX: Guidelines to future TeX extensions. I recently reevaluated the state of affairs at the Boston TeX conference. The final paper is not yet finished (hope it will be in the next TUGboat but a video of the talk is at LaTeX project website). Both talks discuss the TeX capabilities and limitations based on the fact that TeX is a programs that renders its output as a "composer" using algorithms.

TeX is not a graphical system where the composer is essentially sitting in front of the screen. So a comparison between TeX and say MS-Word is a bit missleading as essentially TeX formats do not attempt to cater for this kind of interface (though it would be more or less possible by dropping most of the composing functionality and leave that to the users). But if you are interested in the typography limitations then the above article(s) might be a good start --- and none of these limitations are resolved in other typesetting or deskop publishing systems (with a few exceptions due to internals of the box/glue/penalty model of TeX, e.g., changing parshapes based on position on the page is very difficult in TeX but less so in other systems that either work visually or do not care about the quality of linebreaks and thus can do the par shaping at a different stage).

### Update

As of March 2013 the TUGboat paper on E-TeX: Guidelines to Future TeX extension -- revisited is now also available on the project web site.

-

My answer is far from complete, but I thought I'd rather share my thoughts. Off hand I can think of these (later I'll edit my answer, if something new pops up).

1. Limitations of the size of paper you can use and some memory limitations you may run into when doing computationally heavy TikZ (see for instance this example from TeXamples). Most of the time this can be overcome by optimizing your code, externalization of certain parts or (as a last resort) modifying the memory limits available to your TeX engine. Still, it's highly unlikely to run into such limitations. TeX is really very well engineered.

2. There is one thing I miss: 'endless' paper length document class. `:)` (See my earlier question on this.) As you can see, workarounds exist in this case, too. (A limit of 10 m exists though, which should not be a problem for mundane applications.)

3. I've never seen any sort of code folding in the PDF output file (would most likely require JavaScript).

4. EDIT: MS Word has some 'advanced' grammar checking, e.g. it marks words that appear twice next to each other, marks senteces with unusual structure, etc. While this is probably something to be rather implemented in an editor, I don't know of any package that could throw a warning if it finds one of these problems.

-
Code folding would be so cool! But I doubt it would be possible even with javascript, as you would need to recalculate pagebreaks, probably floats, etc. Maybe it would be possible to hide complete pages... – Juri Robl Sep 10 '12 at 9:20
2. If I am not mistaken `preview` package allows to have endless paper length. 3. Not sure if this qualifies as a 'typesetting' limitation (but definitely a limitation currently, that would be cool). – alfC Sep 10 '12 at 9:20
"It's highly unlikely to run into such limitations": that is not my experience. If you start using `pgfplots`, many reasonably-sized graphs go out of memory. – Federico Poloni Sep 10 '12 at 9:44
@FedericoPoloni: There are workarounds. The `pgfplots` manual has a section (6.2 Memory Limitations) dedicated to solving this problem. I have to admit I only used `pgfplots` for (less than) reasonably sized plots, but as I said, there are workarounds. (I can't vouch for the effectiveness of these methods, as I've never had to try them.) – Count Zero Sep 10 '12 at 10:00
4. Although this is the kind of features that Daniel was trying to exclude in the question, I think it is possible to implement a package for spell or grammar checking, one that marks (red) errors in the output (e.g. if in draft mode for example), that can be helpful (also it can be inefficient --spellcheck each time-- and inflexible --how can one add custom dictionary words? well maybe it can be implemented using ispell or other as backend--). [EDIT: this seems to be a partial solution tex.stackexchange.com/questions/42843/… for the spelling part] – alfC Sep 10 '12 at 10:02

The biggest limitations I can think of (strictly in comparison with programs like InDesign or Word) are as follows.

Mind you, I have no idea what consequences any changes would have wrt. computational complexity or output quality of the system as a whole. TeX does the things it does extremely fast and in near optimum quality, so it may well be in the "pareto set", so to say.

But anyway...

## Paragraph formatting and column/page breaking are strictly detached from each other.

Consequently, TeX's paragraph optimization algorithm doesn't "know" where a certain line will be positioned on the page and can't take this into account.

This has some dire consequences. Off the top of my head:

1. It's awfully hard to make text "flow around" things on the page, especially when page breaks or flush bottom typesetting are involved.
2. I can avoid breaking the page at a line containing a hyphen or a widow/orphan, but I can't make a penalty for paragraph breaking to avoid it appearing on this line.

## TeX is missing a lot of "meta information" on the page

Things like color, z coordinate, angle, writing direction etc. are somehow 'fiddled' into the boxes making up the page or are just implicit in the order content is output. Most of the info can't be inspected later, and communication between content items ("does this box collide with the other one when it's turned around?") becomes next to impossible.

## TeX has a "waterfall" model of page building

Whenever content has left one part of TeXs digestive system for another one, there mostly is no way back. The best we can achieve is to undo everything until a certain stage (for instance, by throwing a box away instead of outputting it) and retrying with different parameters.

If TeX had an object oriented page model where every information could be freely inspected, modified or restructured at any stage and where "typesetting" and "page building" mainly meant to re-structure objects and enrich them with meta information ("where has this paragraph been broken, how much has glue been stretched") which can later be inspected or modified, things would be much much easier.

-
It should be possible to implement TeX in TeX. – morbusg Sep 10 '12 at 13:50
@morbusg, reimplementing tex in any language is pretty painful, see for example en.wikipedia.org/wiki/New_Typesetting_System for how difficult it is, even in a "nice" language like java. Implementing TeX in TeX, while possible in principle, is.... unlikely. – Lev Bishop Sep 10 '12 at 14:07
@morbusg Of course, but wrt. the "meta-TeX" the basic TeX will be just another implementation language; you could as well use Java ot Python. If you want to enrich the typesetting capabilities in any way, then the fact that you're using TeX as the basis for re-implementation won't help you much. – Stephan Lehmke Sep 10 '12 at 15:51
Stephan, your object oriented page model might be a start but it wouldn't help much as there aren't proper algorithms that do the logic in more than very simple cases. This is where the research community has failed in the last 20 years. – Frank Mittelbach Sep 12 '12 at 22:02
@FrankMittelbach That's why I released myself of algorithmic questions right in the beginning ;-) But even just applying all the "old" algorithms that we have in a clear and open way to a transparent object-oriented data structure would be an enormous win... – Stephan Lehmke Sep 12 '12 at 22:12