As I understand it, LaTeX3 is a rewrite of LaTeX to fix the shortcomings of LaTeX2e, and ConTeXt is another TeX-based language (set of macros like LaTeX?) that solves quite a few problems that are hard to solve with LaTeX2e.

How do they compare? Do they solve the same problems? Does LaTeX3 bring to the LaTeX world similar functionalities as ConTeXt?

  • I think the most important thing about implementation is that ConTeXt uses script language heavily. (Ruby in the past, and Lua now.) LaTeX2e and current LaTeX3 don't use scripts.
    – Leo Liu
    Commented Sep 30, 2011 at 4:38
  • @Leo Liu: Ruby (and Perl before it) were used only for auxillary scripts (like latexmk or rubber in LaTeX world). Of course lua is now is used in more pervasive way. Commented Sep 30, 2011 at 14:58

2 Answers 2


A full answer here has several parts. First, at the time of writing it's important to bear in mind that ConTeXt is not only available but works well, while LaTeX3 is a concept which is being developed. That means that it's not even 100% clear what shape LaTeX3 will take. It's also not clear that LaTeX3 will deliver, but for the purposes of answering the question I'll ignore this! I'll also highlight what seem to be (broad) similarities.

TeX-based systems

There are then two broad areas to talk about: the user 'experience' and the implementation. In both areas, there are differences but I'd like to highlight one important similarity: both ConTeXt and LaTeX3 are ultimately TeX-based. A radically-different approach from either would be to parse input using another language (Python is often highlighted, for its scripting ability), then convert to TeX primitives (plus low-level macros), and only do the real typesetting in TeX. Neither ConTeXt nor LaTeX3 do that.

At the user level

At the user level, LaTeX works with the concept of a document class as a key concept, .i.e. you always have:


In LaTeX2e, the separation between a class and adding code is somewhat diffuse. The idea for LaTeX3 is to make 'design' and 'code' separate areas, and so have the document class as a purely design concept. ConTeXt does not enforce the idea of a loading a particular 'style' for a document in the same way (although it is possible to load a module to set defaults). There is a key philosophical difference here, as ConTeXt is in many ways closer to the plain TeX concept of 'author as designer', while LaTeX3 is intended to enhance the separation of the two roles.

An area where there is clear similarity is that LaTeX3 will make a lot more use of keyval input 'out of the box' than LaTeX2e does. This is very much a similarity to ConTeXt, which makes extensive use of keyval. There are, however, differences in implementation (the classic one is that LaTeX keyval input skips spaces around the =, while ConTeXt does not).

Another similarity in this area is that the scope of 'core' LaTeX3 supported ideas is intended to be much broader than 'core' LaTeX2e ones, and thus similar to what ConTeXt manages. Quite how this works out depends on the development of LaTeX3, do it is not possible at this stage to give a more detailed analysis of this area. This area encompasses the 'limitations of LaTeX2e' part of the question. For example, ConTeXt can do proper grid typesetting, which is a significant challenge in LaTeX2e.


At the implementation level, ConTeXt (Mark IV) uses a mix of TeX and Lua. On the other hand, LaTeX3 is (currently) dependent on e-TeX plus the \pdfstrcmp macro (or equivalent functionality), and thus works with suitably recent versions of pdfTeX, XeTeX and LuaTeX. LaTeX3 then constructs a programming language of its own ('expl3') using the require TeX primitives. This is clearly a fundamental different, as Lua provides ConTeXt with a flexible programming system and also access to TeX internals that are not available using primitives. At the time of writing, it's not clear how LaTeX3 might handle 'LuaTeX-only' ideas: might there be team-supported 'LuaTeX-only' modules, for example?

The fact that LaTeX3 uses only TeX, whereas ConTeXt uses a large amount of Lua, leads on to the fact that LaTeX3, like LaTeX2e, is intended to be a TeX format which can be used in a 'classical' manner

pdftex "&latex3" <myfile>

ConTeXt, in contrast, is a more 'dynamic' assembly as the Lua part is not saved into the format file. Thus ConTeXt is always executed using the context script. Using this script-based wrapper, ConTeXt can deal with multiple TeX runs, indexing and so forth 'automagically'. The intention (at present) is that LaTeX3 will work in the same way as LaTeX2e: one LaTeX run = one TeX run.

Documenting interfaces

ConTeXt is build explicitly on TeX and Lua, while LaTeX3 defines its own language, expl3. Thus programming ConTeXt means programming in TeX, which is not documented formally in the ConTeXt manuals. A key driver behind LaTeX3 is the idea that beyond the kernel, everything needed to program LaTeX3 should be documented in the LaTeX3 documentation.

LaTeX3 is also aiming for a clear separation between user functions and internal functions, i.e. for every document-level function \foo there should be a (documented) internal function \int_foo. ConTeXt has a very rich set of interfaces, but is not (to my knowledge) built on quite such strict 'two-layer' principles.

  • 1
    I've done my best here to give some information as it seems to me. I'm hoping some regular ConTeXt users can point out where I'm wrong and edit accordingly (or of course post their own answers)!
    – Joseph Wright
    Commented Sep 30, 2011 at 7:48
  • 2
    Thanks, this is very interesting. You say LaTeX3 is still changing much and might not even release, yet there are important core packages such as xparse and fontspec that make use of it, no? Also, I feel like the stability of LuaTeX is brining more Lua-specific packages to LaTeX (I happen to have some) and there might be more and more of these packages appearing in the CTAN as problems that are hard to solve in TeX can get solved in Lua.
    – raphink
    Commented Sep 30, 2011 at 8:23
  • 1
    @Joseph -- i hope that users of "older" TeX systems (if by that you include users of LaTeX2e) are worth worrying about. several rather large math and technical publishers depend on LaTeX2e for production, and if LaTeX3 isn't at least reasonably backward-compatible, you have done them a great disservice. Commented Sep 30, 2011 at 13:35
  • 4
    @Joseph -- that's kind of what i figured. at ams, we have authors who are still using "antique" installations (we're still coping with submissions based on latex 2.09, for which we have to request copies of the obsolete packages being used), but for production, we try to keep our underlying system based on a disribution of tex live that's no more than two years old. for us, context is (so far) a non-starter; it has fine capabilities, but is not easily bent into the form we need, and besides, i haven't heard that anyone has asked for it yet. but latex3, when it arrives, ... Commented Sep 30, 2011 at 13:57
  • 1
    I agree with most of what you have said regarding ConTeXt. A small note. ConTeXt programming interface is documented fairly well on the ConTeXt wiki. Also the source code has extensive comments and usage examples.
    – Aditya
    Commented Sep 30, 2011 at 18:30

ConTeXt is a complete, self contained system which tries to have solutions for (almost) everything.

LaTeX (all versions) on the other side is "only" a kernel. That you need to load packages to get some features is not a deficiency: LaTeX is meant to be extended by packages and classes. LaTeX3 will move some basic features which are currently in packages to the kernel, nevertheless a lot will have to be added by other package/class writers. source3 or xparse define mostly basic functions meant for package writers.

ConTeXt is managed by (and so under control) a rather small team. (I have no idea what would happen if the principal maintainer (Hans Hagen) would stop the work on ConTeXt.)

The LaTeX team is larger and has evolved over the time. Some people did quit the team, new people joined.

There exist up to no documentation about the inner working and ideas of the implementation ConTeXt. That makes it rather difficult to write yourself code to extend or change ConTeXt. ConTeXt has a concept of "user modules" but I don't think it is used much (and as the maintainer once wrote "The fact that it's custom in LaTeX to overload code and thus create a maintenance decency does not mean that I want such a dependency on my code."). My impression is that in most cases people wait until a feature is implemented by the ConTeXt maintainers.

On the other side there exist hundreds and thousands of page of internal LaTeX documentation. If you look at the documentation of e.g. source3 you see that the LaTeX team make a large effort to describe the ideas behind the code and every time you ask something you get long and useful answers. LaTeX don't only allow you to take part you are actually invited to add something to LaTeX.

I think ConTeXt is very powerful and someone who wants only a good system to write/manipulate documents should consider it. But for me part of the fun of TeX is the ability to write my own code, to debug problems, to understand the working of the system. I don't want to use only applications where I simply have to learn which button to press or which command to type even if this application can do everything I want and so every time I personally tried to find my way in ConTeXt I was at the end frustrated.

  • 9
    As one of the current LaTeX3 team, I'd point out that I personally feel LaTeX3 needs a scope similar to ConTeXt. we're also aiming to avoid some of the package dependency issues by having a much clearer idea of 'internal' versus 'documented' interfaces.
    – Joseph Wright
    Commented Sep 30, 2011 at 9:08
  • 2
    @Joseph: I don't know how you see the "scope" of context. Certainly some things should be pulled back, e.g. the various tabular packages and things involving manipulation of the output routine. But imho LaTeX should concentrate on offering tools not so much on solutions. Look a bit how a lot people here and in other places gets involved in latex: Because they can tinker with the code, build some small package, play around. I have seen people feeling the urge to write their first (probably horrible) latex package after few weeks. Commented Sep 30, 2011 at 9:55
  • 7
    @UlrikeFischer On my list of 'should be core' would be (1) font encoding; (2) font loading; (3) float and caption management; (4) tables (booktabs, different forms of tabular, etc.); (5) multiple columns; (6) grid typesetting; (7) bibliography management (based on biblatex); (8) drawing (based on Tikz); (9) microtypography. Without all of these, a stand-alone format won't compete with LaTeX2e. (Remember, a stand-alone format can't use any existing packages.)
    – Joseph Wright
    Commented Sep 30, 2011 at 10:01
  • 7
    I agree about 1-6 and would add (core) language support (babel/polyglossia), large parts of hyperref and graphicx. I'm not sure about biblatex (what about glossaries?), tikz (pstricks?) and in part microtypography - such special tasks needs imho specialized maintainers (teams), they can be "concurrent" packages, also the packages will/should evolve after the format is frozen, so they incorporation should be different to the incorporation of real core functionality. Commented Sep 30, 2011 at 11:19
  • 18
    As someone who will never ever find writing TeX code fun, I'm very happy I don't have to when using ConTeXt. Also the fact that there are very few ConTeXt modules is because you hardly need any, not because you can't write your own modules. I wrote a bidi module for ConTeXt (there is hardly any TeX code in it, though), and it works pretty reliably (thanks to consistent and predictable internals), but the situation in LaTeX is chaotic that I can't get a package there to work reliably in any sane way. Commented Sep 30, 2011 at 18:25

You must log in to answer this question.

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