A General Overview
What is ConTeXt then?
ConTeXt is a typesetting system, or in other words: an extensive set of tools aimed at giving the user absolute and complete control over the appearance and presentation of a specific electronic document intended for print on paper or to be shown on screen. This chapter explains what this means. But first, let us highlight some of the characteristics of ConTeXt.
-
There are two flavours of ConTeXt known as Mark II and Mark IV respectively. ConTeXt Mark II is frozen, i.e. it is considered to be an already fully-developed language that is not intended to have further changes or new things added. A new version would appear only in the case where some error needs to be corrected. ConTeXt Mark IV, on the other hand, continues to be developed so that new versions appear from time to time that introduce some improvement or additional utility. But, although still in development, it is a very mature language in which changes introduced by the new versions are quite subtle and exclusively affect the low level operation of the system. For the average user these changes are totally transparent; it is as if they did not exist. Although both flavours have much in common, there are also some incompatible features between them. Hence this introduction focuses only on ConTeXt Mark IV.
-
ConTeXt is software libre (or free software, but not just in the sense of gratis). The program properly speaking (that is, the complex of computer tools that make up ConTeXt), is distributed under the GNU General Public Licence. The documentation is offered under the “Creative Commons” licence that allows it to be freely copied and distributed.
-
ConTeXt is neither a word processor program nor a text editing program, but a collection of tools aimed at transforming a text we have previously written in our favourite text editor. Therefore, when we work with ConTeXt:
-
We begin by writing one or more text files with any kind of text editor.
-
In these files, along with the text that makes up the contents of the document, there is a range of instructions that tell ConTeXt about the appearance that the final document generated from the original text files must have. The complete set of ConTeXt instructions, in fact, is a language; and since this language allows one to program the typographical transformation of a text, we can say that ConTeXt is a typographical programming language.
-
Once we have written the source files, these will be processed by a program (also called
context1), which will generate a PDF file from them ready to be sent to a print shop or to be shown on screen.
-
-
In ConTeXt, therefore, we must differentiate between the document we are writing, and the document that ConTeXt generates. To avoid any doubts, in this introduction I will call the text document that contains formatting instructions the source file, and the PDF document generated by ConTeXt from the source file I will call the final document.
The above basic points will be further developed below.
Typesetting texts
Writing a document (book, article, chapter, leaflet, print out, paper …) and putting it together typographically are two very different activities. Writing the document is much the same as drafting it; this is done by the author who decides on its content and structure. The document created directly by the author, just as he or she wrote it, is called the manuscript. By its very nature, only the author or those permitted to read it have access to the manuscript. Its dissemination beyond this intimate group requires the manuscript to be published. Today, publishing something — in the etymological sense of making it “accessible to the public” — is as simple as putting it on the internet, available to anyone who finds it and wants to read it. But until relatively recently, publication was a cost-intensive process dependent on certain professionals specialised in it, only accessed by those manuscripts which, because of their content, or because of their author, were considered to be particularly interesting. And even today we tend to reserve the word publication for this kind of professional publication where the manuscript undergoes a series of transformations in its appearance aimed at improving the legibility of the document. This series of transformations is what we call typesetting.
The aim of typesetting is — generally speaking, and leaving aside advertisement-type texts that seek to attract the reader's attention — to produce documents with the greatest legibility, meaning the quality of the printed text that invites or facilitates its reading and ensures that the reader feels comfortable with it. Many things contribute to this; some, of course, have to do with the document's contents: (quality, clarity, organisation…), but others depend on things like the type and dimensions of the font used, the use of white space in the document, visual separation between paragraphs, etc. In addition, there are other kinds of resources, not so much of the graphic or visual kind, such as the presence or otherwise in the document of specific aids to the reader like page headers and footers, indexes, glossaries, use of bold type, margin headings, etc. The knowledge and correct handling of all the resources available to a typesetter could be called the “art of typesetting” or the “art of printing”.
Historically, and until the advent of the computer, the tasks and roles of writer and typesetter were kept quite distinct. The author wrote by hand or on a 19th century machine called a typewriter, the typographical resources of which were even more limited than those who wrote by hand; and then the writer gave the originals to the publisher or printer who transformed them to obtain the printed document.
Today, computer science has made it easier for the author to decide on the composition down to the last detail. However, this does not do away with the fact that the qualities that a good author needs are not the same as those needed by a good typesetter. Depending on the kind of document being dealt with, the author needs an understanding of the subject matter being written about, clarity of exposition, well-structured thinking that allows for the creation of a well-organised text, creativity, a sense of rhythm, etc. But the typesetter has to combine a good knowledge of the conceptual and graphical resources at his or her disposal, and sufficient good taste to be able to use them harmoniously.
With a good word processing program2 it is possible to achieve a reasonably good typographically prepared document. But word processors, generally speaking, are not designed for typesetting and the results, although they may be correct, are not comparable to the results obtainable with other tools designed specifically to control the composition of the document. In fact, word processors are how typewriters evolved, and their use, to the extent that these tools mask the difference between the authorship of the text and its typesetting, tends to produce unstructured and typographically inadequate texts. On the contrary, tools like ConTeXt have evolved from the printing press; they offer many more composition possibilities and above all, it is not possible to learn how to use them without also acquiring, along the way, many notions relating to typesetting. This is the difference from word processors, which someone can use for many years without learning a single thing about typography.
Markup languages
In the days before computers, as I said before, the author prepared the manuscript by hand or typewriter and handed it to the publisher or printer who was responsible for the transformation of the manuscript into the final printed text. Although the author had relatively little involvement in the transformation, he or she did maintain some intervention by pointing out, for example, that certain lines of the manuscript were the titles of its various parts (chapters, sections …), or by indicating that certain things should be highlighted typographically in some way. These indications were made by the author in the manuscript itself, sometimes expressly, and at other times through certain conventions that continued to develop over time. For example, the chapters always began on a new page by inserting several blank lines before the title, underlining it, writing it in capital letters, or framing the text to be highlighted between two underscores, increasing the indentation of a paragraph, etc.
To put it briefly, the author marked up the text in order to provide indications relating to how it should be typeset. Then later, the editor would handwrite other indications on the text for the printer, such as, for example, the font to be used, and its size.
Today, in a computerised world, we can continue to do this to generate electronic documents through what is called a markup language. These kinds of languages use a series of marks or indications that the program processing the file containing them knows how to interpret. Probably the best known markup language today is HTML, since most web pages today are based on it. An HTML page contains the text of a web page, along with a series of marks that tell the browser program that loads the page how it should display it. The HTML markup that web browsers understand, together with instructions about how and where to use them, is called the “HTML language”, which is a markup language. But as well as HTML, there are many other markup languages; in fact they are booming, and so XML, which is the markup language par excellence, is found everywhere today and is in use for pretty much everything: for database design, for the creation of specific languages, transmission of structured data, application configuration files, etc. There are also markup languages intended for graphic design (SVG, TikZ or MetaPost), maths formulas (MathML), music (Lilypond and MusicXML), finance, geomatics, etc. And of course there are also markup languages aimed at the typographical transformation of text, and among these, TeX and its derivatives stand out.
With regard to the typographical markup that indicates how a text should look, there are two kinds that we can refer to: purely typographical markup and conceptual markup or, if you prefer, logical markup. Purely typographical markup is limited to indicating precisely what typographical resource should be used to display a certain text; such as when, for example, we indicate that certain text should be in bold or italics. Conceptual markup, on the other hand, indicates what function complies with certain text in the document as a whole, such as when we indicate that something is a title, or a subtitle, or a quote. In general, documents that prefer to use this second kind of markup are more consistent and easier to compose, since once again they point out the difference between authorship and composition: the author indicates that such and such a line is a title, or that such and such a fragment is a warning, or a quote; and the typesetter decides how to typographically highlight all titles, warnings or quotations; thus, on the one hand, consistency is guaranteed, as all the fragments that fulfil the same function will look the same, and, on the other hand it saves time, because the format of each type of fragment only needs to be indicated once.
TeX and its derivatives
TeX was developed towards the end of the 70s by Donald E. Knuth, a professor (now emeritus professor) of theoretical computer programming at Stanford University, who implemented the program to produce his own publications and as an example of a systematically developed and annotated program. Along with TeX, Knuth developed an additional programming language called MetaFont, created for designing typographical fonts, and he used it to design a font he baptised as Computer Modern, which, along with the usual characters of any font, also included a complete set of “glyphs”3 designed for writing mathematics. To all this he added some additional utilities and thus the typesetting system called TeX was born, which, due to its power, quality of results, flexibility of use and broad possibilities, is considered one of the best computerised systems for text composition. It was designed for texts in which there was a lot of mathematics, but it soon became clear that the system's possibilities made it suitable for all kinds of texts.
Internally, TeX functions in the same way as the former compositors would do in a print shop. For TeX, everything is a box: The letters are contained in boxes, the blank spaces are also boxes, several letters (the boxes containing several letters) form a new box that encloses the word, and several words, along with the blank space between them, form a box containing a line, several lines become a box containing the paragraph … and so on. All this, moreover, with extraordinary precision in the handling of measurements. Consider that the smallest unit that TeX deals with is 65.536 times smaller than the typographical point with which characters and lines are measured, which is usually the smallest unit handled by most word processing programs. This means that the smallest unit handled by TeX is approximately 0.000005356 millimetres.
The name TeX comes from the root of the Greek word τέχνη, written in upper case letters (ΤÉΧΝΗ). Therefore, the final letter of the word TeX is not a Latin ‘X’, but the Greek ‘χ’, pronounced — apparently — like the Scottish ‘ch’ in loch. So TeX should be pronounced as Tech. This Greek word, on the other hand, meant both “art” and “technology”, and this is the reason why Knuth chose it to name his system. The purpose of this name — he wrote — “is to remind you that TeX is primarily concerned with high quality technical manuscripts. Its emphasis is on art and technology, as in the underlying Greek word”.
Using the convention established by Knuth, TeX is to be written:
- In typographically formatted texts like this one, using the logo that I have been using until now: the three letters in upper case, with the central ‘E’ slightly displaced below to facilitate a closer alignment between the ‘T’ and the ‘X’; or in other words: “TeX”.
To facilitate the writing of this logo, Knuth included an
instruction in TeX for writing it in the final document:
\TeX.
- In unformatted texts (such as an email, or a text file), with the ‘T’ and the ‘X’ in upper case, and the central ‘e’ in lower case; so: “TeX”.
This convention continues to be used in all derivatives of TeX that include its proper name, as is the case with ConTeXt. When writing it in text mode we need to write “ConTeXt”.
TeX engines
The TeX program is free libre software: its source code is available to the public and anyone can use it or modify it as they wish, with the only condition that, if modifications are made, the result cannot be called “TeX” This is why, over time, certain adaptations of the program have emerged, introducing different improvements to it, and which are generally referred to as TeX engines. Apart from the original TeX program, the main engines are, in chronological order of appearance, pdfTeX, eTeX, XeTeX and LuaTeX. Each of them is supposed to incorporate the improvements of the previous one. These improvements, on the other hand, up until the appearance of LuaTeX, did not affect the language itself, but only the input files, the output files, handling of sources and low level operation of macros.
The question of which TeX engine to use is a much debated one within the TeX universe. I will not develop this question here since ConTeXt Mark IV only works with LuaTeX. In reality, in the ConTeXt world, discussion on TeX engines becomes a discussion on whether to use Mark II (that works with PdfTeX and XeTeX) or Mark IV (that only works with LuaTeX).
Formats derived from TeX
The core or heart of TeX only understands a set of approximately 300
very basic instructions, called primitives, which are suitable
for typesetting operations and programming functions. The great majority
of these instructions are of a very low level, which, in computer
terminology, means that they are more easily understandable by the
computer than by human beings, since they concern very elementary
operations of the “shift this character 0.000725 millimetres
upward” kind. Hence Knuth saw that TeX would be extensible,
meaning that there should be a mechanism that allows instructions to be
defined at a higher level, more easily understandable by human beings.
These instructions, that are broken down into other simpler instructions
at the time of execution, are called macros. For example, the
TeX instruction that prints the (\TeX) logo, is broken down as
follows at the time of execution:
T
\kern -.1667em
\lower .5ex
\hbox {E}
\kern -.125em
X
But for the human being, it is much easier to understand and remember
that the simple command “\TeX” carries
out the typographical operations needed to print the logo.
The difference between what is a macro and what is a primitive, really only has importance from the perspective of the TeX developer. From the user's perspective they are instructions or, if you prefer, commands. Knuth called them control sequences.
This possibility of extending the language through macros is one of the characteristics that turned TeX into such a powerful tool. In fact, Knuth himself created approximately 600 macros that, along with the 300 primitives, make up the format called “Plain TeX”. It is quite common to confuse TeX properly so called, with Plain TeX and, in fact, almost everything usually written or said about TeX, is really a reference to Plain TeX. Books that claim to be about TeX (including the foundational “The TeX Book”), really refer to Plain TeX; and those who believe they are directly working with TeX are in reality working with Plain TeX.
Plain TeX is what, in TeX terminology, is called a format, consisting of a broad set of macros, together with certain rules of syntax concerning how and in what way to use them. As well as Plain TeX, with the passing of time other formats have been developed, among which it is worth mentioning LaTeX, a broad set of macros for TeX created in 1985 by Leslie Lamport and which is probably the TeX derivative that is most in use in the academic, technological and mathematical world. ConTeXt is (or has begun to be), on a par with LaTeX as a format derived from TeX.
Normally these formats are accompanied by a programme that loads
the macros that make them up into memory before calling on tex
(or the actual engine being used for processing) to process the source
file. But even though all these formats are actually running TeX, as
each of them has different instructions and different syntax rules from
the user's point of view, we can think of them as different
languages. They all draw their inspiration from TeX, but are different
from TeX and also different from each other.
ConTeXt
In reality ConTeXt, which started out as a format of TeX, is much more than that today. ConTeXt includes:
- A very broad set of TeX macros. If Plain TeX has around 900 instructions, ConTeXt has around 3500; and if we add up the names of the different options that these commands support, we are talking about a vocabulary of around 4000 words. The vocabulary is this large because of the ConTeXt strategy to facilitate its learning, and this strategy means the inclusion of any number of synonyms for commands and options.
The intention is that if a certain effect is to be achieved, then
for each of the ways an English speaker would call that effect there
is a command or option that achieves it — which is supposed to make
the use of the language easier. For example, to simultaneously get a
bold and italic letter, ConTeXt has three instructions all of
which achieve the same result: \bi, \italicbold and
\bolditalic.
-
A likewise broad set of macros for MetaPost, a graphical programming language derived from MetaFont, which in turn is a language for typeface design that Knuth developed jointly with TeX.
-
Various scripts developed in Perl (the oldest), Ruby (some also old, others not so old) and Lua (the most recent).
-
An interface that integrates TeX, MetaPost, Lua and XML, allowing one to write and process documents in any of these languages, or to mix elements from some of them.
Perhaps you did not understand much of the previous explanation? Don't worry about it. I used a lot of computer jargon in it and mentioned many programs and languages. It is not necessary to know all the different components to use ConTeXt. The important thing, at this stage of learning, is to stay with the idea that ConTeXt integrates many tools from different sources that together make up a typesetting system.
It is because of this latter feature of integration of tools with different origins, that we say that ConTeXt is a “hybrid technology” intended for typesetting documents. My understanding is that this turns ConTeXt into an extraordinarily advanced and powerful system.
Even though ConTeXt is much more than a collection of macros for TeX, it continues to be based on TeX, and this is why this document, that I claim to be no more than an introduction, focuses on this.
ConTeXt, on the other hand, is rather more modern than TeX. When TeX was created, the emergence of computers was just at the beginning, and we were far from seeing what the internet and the multimedia world would be (would become). In this respect, ConTeXt naturally integrates some of the things that have always been something of a foreign body in TeX such as including external graphics, handling colour, hyperlinks in electronic documents, assuming a paper size suitable for a document intended for display on a screen, etc.
A short history of ConTeXt
ConTeXt was born approximately in 1991. It was created by Hans Hagen and Ton Otten in a Dutch document design and processing company called “Pragma Advanced Document Engineering”, usually abbreviated as Pragma ADE. It began by being a collection of TeX macros that had Dutch names and was unofficially known as Pragmatex, aimed at the company's non-technical employees who had to manage the many details of editing typeset documents and who were not used to using markup languages or interfaces other than Dutch. Hence the first version of ConTeXt was written in Dutch. The idea was to create a sufficient number of macros with a uniform and consistent interface. Approximately in 1994 the package was stable enough for a user manual to be written in Dutch, and in 1996, through the initiative of Hans Hagen, reference to it began taking on the name “ConTeXt”. This name claims to mean “Text with TeX” (using the Latin preposition ‘con’ meaning ‘with’), but at the same time a wordplay on the English (and Dutch) word “Context”. Behind the name, therefore, lies a triple play on words involving “TeX”, “text” and “context”.
Therefore, since the name is based on wordplay, ConTeXt should be pronounced ‘context’ and not ‘contecht’ since this would mean losing the play on words.
The interface began to be translated into English approximately in 2005, giving rise to the version known as ConTeXt Mark II, where the ‘II’ is explained because in the mind of the developers, the previous version in Dutch was Version~‘I’, even though it was never officially called that. After the interface was translated into English, the use of the system began to spread beyond the Netherlands, and the interface was translated into other European languages such as French, German, Italian and Romanian. The “official” documentation for ConTeXt, nevertheless, is normally based on the English version, and this is the version this document works with.
In its initial version, ConTeXt Mark II worked with the PdfTeX TeX engine. But later, at the appearance of the XeTeX engine, ConTeXt Mark II was modified to allow the use of this new engine that contributed a number of advantages by comparison with PdfTeX. But when LuaTeX came along some years later, the decision was made to internally reconfigure how ConTeXt functioned in order to integrate all the new possibilities that this new engine offered. And so, ConTeXt Mark IV was born, and it was presented in 2007, immediately after the presentation of LuaTeX. Very probably, one of the influencing factors in the decision to reconfigure ConTeXt to adapt it to LuaTeX was that two of the three main developers of ConTeXt, Hans Hagen and Taco Hoekwater, were also part of the main team developing LuaTeX. This is why ConTeXt Mark IV and LuaTeX were born at the same time and developed in unison. There is a synergy between ConTeXt and LuaTeX that does not exist in any other derivative of TeX; and I doubt that any of the others can avail themselves of the advantages of LuaTeX as ConTeXt can.
There are many differences between Mark II and Mark IV, although most of them are internal, that is, they have to do with how the macro actually works at a lower level, such that from the user's perspective the differences are not noticeable: the name and parameters of the macro remain the same. There are, however, some differences that affect the interface and force one to do things differently depending on which version one is working with. These differences are relatively few, but they do affect very important aspects such as for example, the coding of the input file, or the handling of fonts installed in the system.
It would, however, be very welcome if somewhere there were a document that explained (or listed) the appreciable differences between Mark II and Mark IV. In the ConTeXt wiki, for example, for each ConTeXt command there are two kinds of syntax (very often identical). I presume one belongs to Mark II and the other to Mark IV; and based on this assumption, I also presume that the first version is from Mark II. But the truth is that the wiki tells us nothing about this.
The fact that the differences, at a language level, are relatively few, means that on many occasions rather than speaking of two versions we are talking about two “flavours” of ConTeXt. But whether you call them one or the other, the fact is that a document prepared for Mark II cannot normally be compiled with Mark IV and vice versa; and if the document mixes both versions, it will most likely not compile well with either of them; which implies that the author of the source file has to start by deciding whether to write for Mark II or for Mark IV.
If we work with the different versions of ConTeXt, a good trick for
differentiating at first sight between files intended for Mark II and
those intended for Mark IV is to use a different extension for the
file names. Thus, for example, for any files I have written for
Mark II, I put .mkii as the extension, and .mkiv
instead for those written for Mark IV. It is true that ConTeXt
expects all source files to have the extension .tex, but we
can change the file extension as long as we expressly indicate the
file extension when applying ConTeXt to the file.
The ConTeXt distribution installed on the wiki, “ConTeXt Standalone”, includes
both versions, and to avoid confusion — I assume — uses a different
command for each of them to compile a file. Mark II compiles with the
command texexec and Mark IV with the command context.
In fact both commands, context and texexec, are scripts with different options that run mtxrun, which in turn
is a Lua script.
Today, Mark II is frozen and Mark IV continues to be developed, which means that new versions of the former are only published when errors or faults are discovered that need to be corrected, while new versions of Mark IV continue to be published regularly; sometimes two or three times a month, even though in most of these cases the “new versions” do not introduce perceptible changes in the language but are limited to somehow improving implementation of a command at low level, or updating some of the many manuals included with the distribution. Even so, if we have installed the development version — which is what I would recommend and which is the one installed by default with “ConTeXt Standalone” — it makes sense to update our version from time to time (See Appendix for the way of updating the installed version of “ConTeXt Standalone”).
LMTX and other alternative implementations of Mark IV
The developers of ConTeXt are naturally restless, and therefore have not ceased development of ConTeXt with Mark IV; new versions are still being tested and experimented with, although in general these differ from Mark IV in very few ways, and do not have the incompatibility in compiling that exists between Mark IV and Mark II.
Thus, certain minor variants of Mark IV called, respectively, Mark VI, Mark IX and Mark XI have been developed. Of these, I have only been able to find a small reference to Mark VI in the ConTeXt wiki where it says that the only difference with Mark IV lies in the possibility of defining commands by assigning the parameters not a number, as is traditional in TeX, but a name, as is usually done in almost all programming languages.
More important than these small variations, I believe, is the appearance in the ConTeXt universe (ConTeXtverse?) of a new version called LMTX, a name which is an acronym of LuaMetaTeX: a new TeX engine that is a simplified version of LuaTeX, developed with a view to saving computer resources; which means that LMTX requires less memory and less processing power than ConTeXt Mark IV.
LMTX was presented in spring 2019 and one assumes that it will not imply any external change to the Mark IV language. For the author of the document there would be no difference at the time of working with it; but when compiling it, one would need to choose between doing so with LuaTeX, or doing so with LuaMetaTeX. In Appendix A, relating to the installation of ConTeXt, a procedure is shown for assigning a different command name to each of the installations (section 3).
ConTeXt versus LaTeX
Given that the most popular format derived from TeX is LaTeX, a comparison between this and ConTeXt is inevitable. Clearly we are talking about different languages although in some way related to each other since they both derive from TeX; the relationship is similar to that which exists, for example, between Spanish and French: languages that have a common origin (Latin) which means that their syntax is similar and many of the words in each of these languages is mirrored by a word in the other. But apart from this family resemblance, LaTeX and ConTeXt differ in their philosophy and implementation, since the initial aims of both, are, to some degree, the opposite. LaTeX claims to facilitate the use of TeX, isolating the author from the concrete typographical details to help focus on content, leaving the typesetting details in the hands of LaTeX. This means that simplifying the use of TeX takes place at the expense of limiting the immense flexibility of TeX, by predefining basic formats and limiting the number of typographical issues that the author has to decide on. In contrast to this philosophy, ConTeXt was born within a company dedicated to typesetting documents. Therefore, far from wanting to isolate the author from typesetting details, the aim is to give the author absolute and complete control over them. To achieve this, ConTeXt provides a uniform and consistent interface which is much closer to the original spirit of TeX than LaTeX.
This difference in philosophy and founding objectives then translates, in turn, into a difference in implementation. LaTeX, that tends to simplify things as much as possible, does not need to use all of TeX's resources. In some way, its core is rather simple. So when there is a need to broaden its possibilities, it is necessary to expressly write a package to do so. This packaging associated with LaTeX is both a virtue and a defect: a virtue, because the tremendous popularity of LaTeX, together with the generosity of its users, means that almost any need we are likely to have has been met by someone before, and that there is a package to achieve it; but it is also a defect because these packages are often incompatible with each other, and their syntax is not always uniform. This means that working with LaTeX requires one to constantly be searching through thousands of already existing packages to fulfil one's needs and ensure that they all work together.
By contrast with the simplicity of the LaTeX core, which is complemented by its extensibility through packages, ConTeXt is designed to have within it all — or almost all — the typographical possibilities of TeX, so its conception is much more monolithic, but at the same time it is also more modular. The ConTeXt core allows us to do almost everything, and we are guaranteed that there will be no incompatibilities between its different utilities, no need to investigate extensions for what we need, and the syntax of the language does not change just because we need a particular utility.
It is true that ConTeXt has what are called extension modules that some might consider as carrying out a function similar to the LaTeX packages, but in real terms they both work differently: ConTeXt modules are designed exclusively to include additional utilities that, because they are still in an experimental stage, have not yet been incorporated into the core, or to allow access to extensions authored by someone outside the ConTeXt development team.
I do not believe that either one of these two philosophies is preferable to the other. The question depends rather on the user's profile and what he or she wants. If the user does not want to deal with typographical issues but simply produce very high quality standardised documents, it would probably be preferable to opt for a system like LaTeX; on the other hand, the user who likes to experiment, or who needs to control every last detail of the document, or someone who has to devise a special layout for a document, would probably be better off using a system like ConTeXt, where the author has all the control in their hands; with the risk, of course, of not knowing how to use this control correctly.
A good understanding of the dynamics of working with ConTeXt
When we work with ConTeXt, we always begin by writing a text file
(which we call a source file), in which, along with the actual
content of our final document, we will include the instructions (in
ConTeXt-speak) that indicate exactly how we want the document to be
formatted: the general appearance we want its pages and paragraphs to
have, the margins we want to apply to certain paragraphs, the font we
want to display, the snippets we want shown in a different font, etc.
Once we have written the source file, we apply the context
program from a terminal, which will process it, and will generate a
different file from it in which the contents of our document will be
formatted in accordance with the instructions included in the source
file for this purpose. This new file could be sent to a (commercial)
printer, displayed on screen, placed on the internet or distributed
among contacts, friends, clients, teachers, pupils … or in other
words, to anyone for whom we wrote the document.
This means that when working with ConTeXt the author is working with a file whose appearance has nothing to do with the final document: the file the author is directly working on is a text file that is not formatted typographically. So ConTeXt works in a different way than do programs known as word processors that show the final appearance of the edited document at the same time we are writing it. For those accustomed to word processors, the way of working with ConTeXt will initially feel strange, and it may even take some time to get used to it. However, once one gets used to it, one understands that in reality this other way of working, differentiating between the work file and the final result, is actually an advantage for many reasons, among which I will highlight here, without following any particular order, the following:
-
Because text files are ‘lighter’ to handle than word processor binary files, and editing them requires less computer memory, they are less likely to be corrupted, and they do not become unintelligible when we change the version of the program we are creating them with. They are also compatible with any operating system, and can be edited with many text editors, so that in order to work with them it is not necessary for the computer system to have the program the file was created with installed on it: any other editing program will do; and in every computer system there is always some text editing program.
-
Because differentiating between the working document and the final document helps to distinguish what the actual content of the document is from what its appearance will be, allowing the author to concentrate on the content in the creation phase, and to focus on the appearance in the typesetting phase.
-
Because it allows one to quickly and accurately change the appearance of the document, since this is determined by ConTeXt commands that can be easily identified.
-
Because this facility for changing the appearance, on the other hand, allows us to easily generate two (or more) different versions from a single content: Perhaps one version optimised for printing on paper, and another designed to be displayed on screen, adjusted to the size of the latter and perhaps including hyperlinks that make no sense in a paper document.
-
Because typographical errors (typos) that are common in word processors, such as extending the italics beyond the last character of a word, are also easily avoided.
-
Because while the work file is not distributed and is ‘for our eyes only’, it is possible to incorporate annotations and observations, comments and warnings for ourselves for subsequent revisions or versions, with the peace of mind in knowing that these will not appear in the formatted file to be distributed.
-
Because the quality that can be obtained by processing the whole document simultaneously is much higher than that which can be achieved with a program that has to make typographical decisions as the document is being written.
-
Etcetera.
All of the above means that on the one hand when working with ConTeXt, once we have got the hang of it, we are more efficient and productive, and that on the other hand, the typographical quality we can obtain is much superior to what can be obtained with so-called word processors. And although it is true that the latter are easier to use, in point of fact they are not that much easier to use. Because while it is true that ConTeXt, as we have said before, contains 3500 instructions, a normal user of ConTeXt will not need to know them all. To do what is usually done with word processors, we only need to know the instructions that allow us to indicate the structure of the document, a few instructions concerning common typographical resources, such as bold or italics, and perhaps how to generate a list, or a footnote. In total, no more than 15 or 20 instructions will allow us to do almost all the things that are done with a word processor. The rest of the instructions allow us to do different things that we normally cannot do with a word processor, or are very difficult to achieve. We can say that while learning to use ConTeXt is more difficult than learning to use a word processor, this is because we can do a lot more with ConTeXt.
Getting help with ConTeXt
While we are new to it, the best place for getting help with ConTeXt is, undoubtedly, on the wiki, which abounds in examples and has a good search engine, especially if one understands English well. We can also find help on the internet, of course, but here the play on words in the name ConTeXt will play tricks on us because searching on the word “context” will return millions of results most of which will have nothing to do with what we are looking for. To find information on ConTeXt you need to add something to the word “context”; for example, “tex”, or “Mark IV” or “Hans Hagen” (one of the creators of ConTeXt) or “Pragma ADE”, or something similar. It could also be useful to seek information using the wiki name: “contextgarden”.
When we have learned something more about ConTeXt, we can consult some of the many documents included in “ConTeXt Standalone”, or even seek help in TeX — LaTeX Stack Exchange, or on the mailing list for ConTeXt (NTG-context). The latter involves the people who know the most about ConTeXt, but the rules of good cyber-etiquette demand that before asking a question, we should have tried hard beforehand to find the answer ourselves.
-
ConTeXt is both a language and a program at the same time (besides being other things). This fact, in a text like the current one, poses the problem that at times we have to distinguish between these two aspects. This is why I have adopted the typographical convention of writing “ConTeXt” with its logo (ConTeXt) when I want to refer exclusively to the language, or to both the language and the program. However, when I want to refer exclusively to the program, I will write “
context” all in lower case and in the monospaced type that is typical of computer terminals and typewriters. I will also use this type for examples and mentions of commands belonging to this language. ↩ -
According to a rather old convention, we make a distinction between text editors and word processors. The early kinds of text editing programs dealt with unformatted text files, while the other kind worked with binary files of formatted text. ↩
-
In typography, a glyph is the graphical representation of a character, a number of characters or part of a character, and is today's equivalent of the letter type (the bit engraved with the letter or movable type). ↩