In the spirit of a free-form Friday on StackOverflow, I'd like to know if I should consider learning ConTeXt. What got me into LaTeX way back in 1994 was having structural markup that made longer documents easier to write. What got me into XeTeX was being able to use my Mac's fonts just like I could in a word processor. What makes ConTeXt users passionate about it or at least willing to forsake LaTeX?

Edit: Thanks for all the answers and great discussion in the comments. The whole page deserves a green check. Success! I am now interested in ConTeXt.

  1. Not really any extra packages with ConTeXt - there are a few modules, but dealing with package conflicts doesn't really happen here.
  2. Built-in XML processor - I use this with TEI and Docbook XML. I gain the typesetting sexiness of a TeX backend, coupled with the validation features of XML is great.
  3. PDF-X compliance pretty much right out of the box - this is one thing LaTeX really lacks if you are doing any kind of serious publishing. There is a package for LaTeX for pdfx for latex, but I've never been able to make it work.
  4. along the same lines as the last one, icc color profile support pretty much out of the box.
  5. simplefonts package - load your system fonts like XeLaTeX
  6. UTF-8 support by default. important if you write a language other than english. you can use utf8 in LaTeX, but you need a package . . . again, this is the default.

I'm sure I've missed some major things. I'm still pretty new to ConTeXt after using LaTeX for some years, but so far I'm really enjoying it. Another major, but probably not "documented", feature is that ConTeXt is aimed more at general publishing, while LaTeX seems to be aimed heavily at academia.

  • 1
    Sounds good. I'm intrigued by by XML processing. I need to look up PDF-X and ICC though. – Matthew Leingang Nov 5 '10 at 22:06
  • I was a bit surprised to see the simplefonts module. I'm not actually sure it's a good idea to replicate syntax between LaTeX and ConTeXt. But I'm unfortunately not a ConTeXt user, so… – Will Robertson Nov 5 '10 at 22:09
  • 1
    @marczellm I assume you already know what XML is... if not then see http://en.wikipedia.org/wiki/XML. With context you can write a stylesheet where you map XML elements to ConTeXt styles. You then feed both the XML and your stylesheet into the ConTeXt binary, and it typesets your XML in a PDF. Now, most XML projects (DocBook and TEI are two XML applications, the former for documenting computer software and hardware, the latter for structural representations of humanities texts) will use XSLT and Apache FOP to render PDF. I don't find the typesetting by FOP to be of good quality, and XML-FO – Mica Mar 13 '13 at 0:13
  • 1
    @Mica Do you have good resources on how to get started with the "XML first" workflow? – jubobs Jun 26 '14 at 11:07
  • 1
    @Jubobs dl.contextgarden.net/myway/tas/xhtml.pdf is a good way to get started if you have an XML file and want to write a stylesheet to transform it to PDF, which I think is what you're asking for. – Mica Jun 28 '14 at 3:46

In my opinion, the two biggest strengths of ConTeXt are:

  1. By design, every command is configurable using key-value options
  2. These options are consistent and predictable.

Lets consider an example of changing the style of various parts of a document to bold italic.

  • To make section headings bolditalic:

  • To make page footers bolditalic:

  • To make contents of enumerations (which are similar to LaTeX's theorems) bolditalic:

  • To make the contents of the second levels of itemizations bolditalic:

  • To make the first row and first column of a table bolditalic

    \setupTABLE[row]   [1][style=bolditalic]

Knowing this, can you guess how to change the style of figure and table captions to bolditalic? (Hint: captions are set using \setupcaptions). Now contrast this with the corresponding commands in LaTeX.

Because of this consistency, you do not need to have multiple ConTeXt manuals open when you are tweaking the document style.

  • 7
    I guess that the more general point that I'd take from this is that ConTeXt is mainly the work of one small team, who've therefore kept things consistent. – Joseph Wright Nov 6 '10 at 15:31
  • 18
    True and false. The initial development of both LaTeX and ConTeXt were largely a single person effort. And the dev teams of both LaTeX and ConTeXt are small (2-5 active devs in both cases). The difference is because LaTeX was designed to be configurable by writing a .sty file, while ConTeXt was designed to be configurable by the user, a reflection on their purpose and the time when they were created (80s vs 90s). As a result, in LaTeX a number of packages that allow configuration by the user have sprung up, each with its own user interface; in ConTeXt, such packages are not needed. – Aditya Nov 6 '10 at 15:50
  • 6
    The dev team of the LaTeX kernel is small but you shouldn't forget all the package authors. The LaTeX2e kernel is frozen so all the work that in context is done in the kernel is done in LaTeX through packages and so their are a part of LaTeX. A frozen kernel has advantages: a hello-world-document in LaTeX will always compile. There is no beta which suddenly breaks a simple document. Packages have advantages too: it's much easier to solve a problem if you can remove easily large parts of the code, which leads to more user knowledge and so to more contributors. – Ulrike Fischer Nov 6 '10 at 17:09
  • 6
    @Ulrike: having lots of separate contributors does not turn them into a team automatically. I think this is actually the point that Aditya was trying to make: if these package writers actually were a team, surely they would have agreed on a common user interface. – Taco Hoekwater Nov 7 '10 at 7:35
  • 7
    One thing worth noting is that some LaTeX classes, such as memoir, have been designed to provide unify commands and options for page layout and provide a level of consistency similar to your examples. – Sharpie Nov 8 '10 at 22:05

To add to Mica's list:

  1. The thing that attracted me to Context is support for graphical layout, through grids and layers. Context is good at organising material on a page. I have the impression that Tikz is being used more and more for this kind of thing for Latex documents, but using Tikz in this way leads to slow compile cycles.
  2. Beyond the fact that "packages are included," as Mica says, passing options to environments is done in a very consistent way. I generally find it much easier to remember what values to pass to which keys in environments, than remember which package does what.
  3. Generous functionality is given to environments: look at what can be done with framed boxes, how general and useful they are for setting off visual information.
  4. The possibility of naming setups for environments allows a much cleaner separation of content from typesetting.

The last point, in particular, is something I'd like the Latex 3 team to be thinking about.

  • 3
    grids is a good call! I haven't had a project that required one, but I'm eager to try it out. – Mica Nov 5 '10 at 22:42

Not exclusively ConTeXt feature, but definitely best supported in ConTeXt is the programmatic interface to luatex. You can generate all kinds of documents entirely in lua using lua versions of ConTeXt commands. Very cool.


What I consider extremely convenient and user-friendly is the context executable. Similar to tools like latexmk it determines the necessary number of runs and then resolves all the references, index, and bibliography on its own. There is no need to run any external program such as makeindex or bibtex anymore with MkIV.

Also context does not pollute the working directory with state files. My LaTeX projects with an index and bibliography create the following files when processed with latexmk: aux bbl bcf blg fdb_latexmk fls idx ilg ind out run.xml toc. The context executable creates a single tuc-file which maintains the state of all the above.


I want to add another point to the list mostly referring to my experience with automated document preparation (which has been mentioned before):

  • Using a CI build with ConTeXt such as the one mentioned in this answer of mine pulls a 1 GiB (not optimized) docker image (ConTeXt standalone is around 300 MiB) which will be able to run any ConTeXt document. To have the same option for LaTeX I have to pull a 3 GiB docker image (to get a full TeX Live or around 1.7 GiB if you create a minimized image).
  • I do not need to check the document built, because I know that my tables will do nice page breaks (it is hard to achieve that level with longtable) and that references are resolved correctly. (Actually, I have checked many of the documents that have been produced, but never needed to correct any issues, in contrast to the previous LaTeX workflow.)
  • For automated document production the integration of ConTeXt's command-line arguments and the options to simply set modes by passing parameters is a great feature. I know you can do similar things with a LaTeX setup but in ConTeXt I do not have to worry about workaround-ish behavior.

And two points that are also quite user-friendly (in my view):

  • An in-built metafun interpreter (which is actually quite fast).
  • Usable table design (especially concerning coloring without overlapping, programmatically generating table source etc.)
  • Why a 1GiB docker image? If you use a small linux installation, then ConTeXt standalone distribution itself is only about 300MB (most of which are fonts) – Aditya Oct 31 '18 at 9:14
  • @Aditya As I said it is not optimized (it is a debian base image with some small corporate software and ConTeXt standalone) but to compare it with e.g. "sumdoc/texlive-2018" it seems fair (they have debian base and include Pygments as well as the full TeX Live 2018). It is still a large difference though. I agree that I should have clarified that ConTeXt is much smaller (and I have edited my post). – TeXnician Oct 31 '18 at 9:42
  • I would like to know more about CI builds of either LaTeX or ConTeXt documents. Do you have any good links to HOWTOs? – Matthew Leingang Oct 31 '18 at 17:16
  • 1
    @pmav99 If you are looking for the Docker and CI files, have a look at my other answer on this site :) – TeXnician Feb 22 at 6:50
  • 2
    @MatthewLeingang If you still have not found anything, there is another question on this site about Gitlab CI. – TeXnician Feb 22 at 6:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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