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

  • 3
    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
    Commented Sep 10, 2012 at 8:23
  • 1
    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
    Commented Sep 10, 2012 at 8:47
  • 6
    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
    Commented Sep 10, 2012 at 9:17
  • 2
    Somewhat related to tex.stackexchange.com/questions/58501/a-critique-of-tex
    – lhf
    Commented Sep 10, 2012 at 11:25
  • 4
    @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. Commented Sep 12, 2012 at 7:50

5 Answers 5


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


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.


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.

  • 6
    It should be possible to implement TeX in TeX.
    – morbusg
    Commented Sep 10, 2012 at 13:50
  • 1
    @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
    Commented Sep 10, 2012 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. Commented Sep 10, 2012 at 15:51
  • 3
    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. Commented Sep 12, 2012 at 22:02
  • 2
    @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... Commented Sep 12, 2012 at 22:12

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.

  • 2
    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
    Commented Sep 10, 2012 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
    Commented Sep 10, 2012 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. Commented Sep 10, 2012 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
    Commented Sep 10, 2012 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
    Commented Sep 10, 2012 at 10:02

Since you are asking for limitations of LaTeX: The LaTeX cosmos is a populated by packages that (mostly) solve one problem, but collide with others, sometimes in very surprising ways.

One example: Try to get a multiple-page table in a multicolumn (n>2) environment with running headers for every column, footnotes in every column, colour in arbitrary table cells, arbitrary lines between your table cells, UTF8 input and underlined text of arbitrary length (i.e. more than one line) with hyphenations. And throw in floating boxes of arbitrary shape somewhere on these pages.

There are packages for most aspects of this problem - but you will not get them working all together. You may be able to solve the complete problem with ConTeXt.

And I'm reasonably sure that this problem can be solved in InDesign or Quark.

  • 2
    That's a bit of a rand Martin and really doesn't have to do much with the question. ConTeXt and LaTeX can do what TeX can do no more no less. So if one or the other presents something better or worse then this doesn't make it a limitation. Commented Sep 12, 2012 at 21:57
  • Especially tables are not a good example of a TeX limitation wrt. DTP programs ;-) Commented Feb 21, 2013 at 4:33

With markup converters like Pandoc it is now possible to generate LaTeX documents without ever touching any LaTeX code.

However, obtaining aesthetic page breaks for slightly complex documents, for example taking into account figures, widows and orphans may still require manual intervention in the LaTeX code.

Quoting Frank Mittelbach:

This issue describes the fundamental problem in TeX’s approach: the program builds optimized paragraph shapes without any knowledge about their final placement on a page. The result is a “galley” from which columns are cut to a specified vertical size. A consequence of this is that one can’t have the shape of a paragraph depend on its final position on the page when using TEX’s page builder algorithm.

In summary, it seems we are not quite yet at that utopian point were one can blindly write content without ever having to worry about how the output will look like in LaTeX. Anyhow, LaTeX is not really intended for unattended typesetting.

For this reason, I now resort to automatic CSS typesetting with PrinceXML for any content that is longer than a letter. The PDF printouts on my web site are generated this way without any user intervention. This was not possible with LaTeX 2ε for the reasons mentionned above, eventhough I tried hard!

If you think of it, HTML+CSS is exactly intended for that: unattended typesetting on screens of unpredictable dimensions. A printed page is merely another media viewport.

On print-css.rocks, one can follow the latest developments in unattended CSS paged media typesetting.

  • The limitation of not being intended for unattended typesetting is true, I think. But in most cases, I suspect human intervention is a good thing, especially if high-quality output is sought. The PDFs on your website simply would not compete with the 'high-quality craft typography' referred to by Frank Mittelbach. (Not that all types of writing need to.)
    – jon
    Commented Dec 2, 2016 at 16:03
  • @jon I agree that the typographical quality of the unattended typeset PDFs with Prince XML is (still) lower than manually typeset LaTeX, especially with regards to mathematics. However, for dynamic content with frequent amendments, I prefer the more pragmatic luxury of just hitting a function key in my editor and knowing that the automatic CSS typeset PDF will be of acceptable quality, without any akward page breaks nor blank voids. Nonetheless, I sincerely do hope that LaTeX & ConTeXt developers take note for future major releases, since Prince XML is not free-libre software! Commented Dec 2, 2016 at 17:01
  • @jon Please, have a look again. I greatly improved the display math by converting to SVG using MathJax. Inline math remained as MathML. Commented Dec 13, 2016 at 21:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .