Difference between revisions of "Modes"

From Wiki
Jump to navigation Jump to search
m (closing tag much needed)
(21 intermediate revisions by 4 users not shown)
Line 28: Line 28:
 
ConTeXt has three commands for setting modes:
 
ConTeXt has three commands for setting modes:
  
* <code><cmd>enablemode </cmd>[...]</code>
+
* <code>{{cmd|enablemode }}[...]</code>
* <code><cmd>disablemode</cmd>[...]</code>
+
* <code>{{cmd|disablemode}}[...]</code>
* <code><cmd>preventmode</cmd>[...]</code>
+
* <code>{{cmd|preventmode}}[...]</code>
  
The names are self-descriptive. <cmd>enablemode</cmd> activates a mode,
+
The names are self-descriptive. {{cmd|enablemode}} activates a mode,
<cmd>disablemode</cmd> deactivates a mode, and <cmd>preventmode</cmd> permanently
+
{{cmd|disablemode}} deactivates a mode, and {{cmd|preventmode}} permanently
 
deactivates a mode. All three commands take a list of modes as an argument. For
 
deactivates a mode. All three commands take a list of modes as an argument. For
 
example,  you can  activate modes named <code>screen</code> and <code>solution</code> with
 
example,  you can  activate modes named <code>screen</code> and <code>solution</code> with
Line 47: Line 47:
 
   context --mode=screen,solution ...
 
   context --mode=screen,solution ...
  
 +
== Pre-defining modes ==
  
 +
Normally, the overhead for testing modes is negligible, but it can add up if modes are tested multiple times in a document (for example, as part of a macro). In such cases, you can ''define'' a mode before using them, to speed up the processing. Modes are defined using:
 +
 +
<texcode>
 +
\definemode[...][...]
 +
</texcode>
 +
 +
The first argument is a list of modes; the second argument may be `yes`, `no`, or `keep`. For example,
 +
 +
* <code>\definemode[screen][yes]</code> defines a mode and enables it;
 +
* <code>\definemode[screen][no]</code> defines a mode and disables it;
 +
* <code>\definemode[screen][keep]</code> defines a mode and keeps its previous status.
 +
 +
Typically, it is better to use <code>\definemode[...][keep]</code> so that the modes may be enabled or disabled from command line as well.
  
 
= Conditional processing based on modes =
 
= Conditional processing based on modes =
Line 77: Line 91:
 
</texcode>
 
</texcode>
  
 +
<code>\startmode</code> (and <code>\startnotmode</code>) checks the value of the mode '''at the time it is executed'''. This is important when you are setting the modes using <code>\enablemode</code> or <code>\disablemode</code>. For example,
 +
<texcode>
 +
\enablemode[foo]
 +
\startmode[foo]
 +
...
 +
\stopmode
 +
</texcode>
 +
the contents of the mode environment are executed because <code>foo</code> is enabled when <code>\startmode</code> is encountered. However, in
 +
<texcode>
 +
\startmode[foo]
 +
...
 +
\stopmode
 +
\enablemode[foo]
 +
</texcode>
 +
the contents of the mode environment are not execited because <code>foo</code> is not enabled when <code>\startmode</code> is encountered.
 +
 +
 +
== Checking for multiple modes (<code>or</code>/<code>and</code> statements for modes) ==
 
<code>\startmode</code> and <code>\startnotmode</code> can check for multiple modes,
 
<code>\startmode</code> and <code>\startnotmode</code> can check for multiple modes,
 
by giving a list of modes as their arguments.  <code>\startmode</code>
 
by giving a list of modes as their arguments.  <code>\startmode</code>
Line 123: Line 155:
  
 
<texcode>
 
<texcode>
\doifmode        {modes} {content}
+
\doifmode        {mode1, mode2, ...} {Processed if any mode is enabled}
\doifnotmode    {modes} {content}
+
\doifnotmode    {mode1, mode2, ...} {Processed if any mode is disabled}
\doifallmodes    {modes} {content}
+
\doifallmodes    {mode1, mode2, ...} {Processed if all modes are enabled}
\doifnotallmodes {modes} {content}
+
\doifnotallmodes {mode1, mode2, ...} {Processed if all modes are disabled}
 
</texcode>
 
</texcode>
 
The logic for determining when the content is processed is exactly the same as
 
The logic for determining when the content is processed is exactly the same as
Line 134: Line 166:
 
the conditions are not satisfied (like the <code>\else</code> branch of <code>\if</code>).
 
the conditions are not satisfied (like the <code>\else</code> branch of <code>\if</code>).
 
<texcode>
 
<texcode>
\doifmodeelse       {modes} {content} {alt}
+
\doifmodeelse       {mode1, mode2, ...} {Processed if any mode is enabled}   {else this is processed}  
\doifnotmodeelse   {modes} {content} {alt}
+
\doifallmodeselse   {mode1, mode2, ...} {Processed if all modes are enabled}  {else this is processed}
\doifallmodeselse  {modes} {content} {alt}
+
\doifnotallmodeselse {mode1, mode2, ...} {Processed if all modes are disabled} {else this is processed}
\doifnotallmodeselse{modes} {content} {alt}
+
</texcode>
 +
 
 +
Note that there is no command <code>\doifnotmodeelse</code> because there is no need for it; <code>\doifmodeelse</code> may be used for the same effect (with the <code>if</code> and <code>else</code> branches switched).
 +
 
 +
== Checking multiple modes in parallel (<code>case</code> statement for modes) ==
 +
 
 +
In addition to the above <em>"or"</em> and <em>"and"</em> environment which check modes is sequence, you can also check multiple modes in parallel. The syntax for such a <em>"case"</em> environment is as follows:
 +
 
 +
<texcode>
 +
\startmodeset
 +
    [mode1, mode2, ...]    {Processed if either mode is enabled}
 +
    [mode3, mode4, ...]    {Processed if either mode is enabled}
 +
    [default]              {Processed if none of the above modes match}
 +
\stopmodeset
 +
</texcode>
 +
 
 +
The same mode can be referenced multiple times, and '''all''' matching branches are executed.
 +
The {{cmd|startmodeset}} ... {{cmd|stopmodeset}} environments can be nested. So, you can use
 +
 
 +
<texcode>
 +
\startmodeset
 +
    [mode1, mode2] {
 +
        Processed when either mode1 or mode2 is enabled
 +
    }  
 +
    [mode3] {
 +
        \startmodeset
 +
            [mode1]    {Processed when mode1 and mode3 are enabled}
 +
            [mode2]    {Processed when mode2 and mode3 are enabled}
 +
            [default]  {Processed when mode3 is enabled and mode1 and mode2 are disabled}
 +
        \stopmodeset
 +
    }
 +
    [default] {
 +
        Processed when mode1, mode2, and mode3 are disabled.:
 +
    }
 +
\stopmodeset
 
</texcode>
 
</texcode>
  
= Accessing Modes in Lua =
+
== Checking modes in Lua ==
  
 
In MkIV, the state of any mode is accessible at the Lua end as <code>tex.modes</code> table. Specifically,
 
In MkIV, the state of any mode is accessible at the Lua end as <code>tex.modes</code> table. Specifically,
Line 156: Line 222:
 
checks if both <code>mode1</code> and <code>mode2</code> are enabled.
 
checks if both <code>mode1</code> and <code>mode2</code> are enabled.
  
'''Note''': This table was added in 2010.10.14 beta and is not available in earlier releases.
 
  
 
= System modes =
 
= System modes =
  
 
Besides allowing user-definable modes, ConTeXt provides some system
 
Besides allowing user-definable modes, ConTeXt provides some system
modes. These modes start with a <code>*</code> character. Here I will explain
+
modes. These modes start with a <code>*</code> character. Here  
only the more commonly used system modes; see the ConTeXt [http://pragma-ade.com/general/manuals/mmodes.pdf modes manual]
+
only the more commonly used system modes are explained; see the ConTeXt [http://pragma-ade.com/general/manuals/mmodes.pdf modes manual]
 
for a complete list.
 
for a complete list.
  
Perhaps the most useful system modes is <code>*mkiv</code> which
+
 
determine whether MKIV is being used. This modes are handy when you
+
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
want different setups for MKII and MKIV. (The complementary <code>*mkii</code> does not exist; instead
+
|'''*mkii'''
you may use <code>\doifnotmode{*mkiv}</code> etc.)
+
| Enabled when running [[MkII]]
 +
|-
 +
| '''*mkiv'''
 +
| Enabled when running [[MkIV]]
 +
|}
 +
 
 +
 
 +
Perhaps the most useful system modes are <code>*mkii</code> and <code>*mkiv</code> which
 +
determine whether MKII or MKIV is being used. These modes are handy when you
 +
want different setups for MKII and MKIV.
  
 
Other modes are useful for very specific situations. Some of these are described
 
Other modes are useful for very specific situations. Some of these are described
 
below.
 
below.
 +
 +
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
| '''*first'''
 +
| Enabled during the first compile run
 +
|}
  
 
A document must be run multiple times to get the cross referencing,
 
A document must be run multiple times to get the cross referencing,
Line 179: Line 260:
 
<code>*first</code> mode is handy&mdash;it is active only on the first run of the
 
<code>*first</code> mode is handy&mdash;it is active only on the first run of the
 
document.
 
document.
 +
 +
 +
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
| '''*export'''
 +
| Enabled when <code>\setupbackend[export=yes]</code> is set
 +
|}
 +
 +
You may want to use different images for XML [Export]. The <code>*export</code> mode is useful in such cases.
 +
 +
 +
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
|'''*project'''
 +
| Enabled when inside <code>\startproject</code> ... <code>\stopproject</code>
 +
|-
 +
|'''*component'''
 +
| Enabled when inside <code>\startcomponent</code>...<code>\stopcomponent</code>
 +
|-
 +
| '''*environment'''
 +
| Enabled when inside <code>\startenvironment</code> ... <code>\stopenvironment</code>
 +
|-
 +
| '''*text'''
 +
| Enabled when inside <code>\starttext</code> ... <code>\stoptext</code>.
 +
|}
  
 
You can use the project-product-component structure for managing large projects
 
You can use the project-product-component structure for managing large projects
Line 191: Line 299:
 
encountered. Similarly, a mode <code>*text</code> is enabled when
 
encountered. Similarly, a mode <code>*text</code> is enabled when
 
<code>\starttext</code> is encountered, and likewise for the others.
 
<code>\starttext</code> is encountered, and likewise for the others.
 +
 +
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
|'''*frontpart'''
 +
| Enabled when inside <code>\startfrontmatter</code> ... <code>\stopfrontmatter</code>
 +
|-
 +
| '''*bodypart'''
 +
| Enabled when inside <code>\startbodymatter</code> ... <code>\stopbodymatter</code>
 +
|-
 +
| '''*backpart'''
 +
| Enabled when inside <code>\startbackmatter</code> ... <code>\stopbackmatter</code>
 +
|}
  
 
A large document is typically broken down into different section blocks:
 
A large document is typically broken down into different section blocks:
Line 198: Line 319:
 
if you want macros that work differently in different section blocks, you can
 
if you want macros that work differently in different section blocks, you can
 
check for modes <code>*frontpart</code>, <code>*bodypart</code>, and so on.
 
check for modes <code>*frontpart</code>, <code>*bodypart</code>, and so on.
 +
 +
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
|'''*list'''
 +
| Enabled inside a list entry
 +
|-
 +
|'''*marking'''
 +
| Enabled inside a marking
 +
|-
 +
|'''*register'''
 +
| Enabled inside a register
 +
|-
 +
|'''*chapter''', '''*section''', etc.
 +
| Enabled inside the corresponding section head.
 +
|}
 +
 +
 +
Sometimes you want a macro to behave differently if it is part of a section head, a section number, a list, a marking, or a register. For section heads, you can check for modes <code>*chapter</code>, <code>*section</code>, <code>*subsection</code>, etc. Similarly, <code>*list</code> is enabled inside a list, <code>*marking</code> is enabled inside a marking, and <code>*register</code> is enabled inside a register.
 +
 +
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
|'''*en-us''', '''*nl''', etc.
 +
| Enabled when the current <code>\language</code> is <code>en-us</code>, <code>nl</code>, etc.
 +
|-
 +
|'''**en-us''', '''**nl''', etc.
 +
| Enabled when the <code>\mainlanguage</code> is <code>en-us</code>, <code>nl</code>, etc.
 +
|}
  
 
ConTeXt provides support for multiple languages. Languages are recognized by
 
ConTeXt provides support for multiple languages. Languages are recognized by
Line 212: Line 362:
 
English and the current language is Dutch, the modes <code>**en-us</code> and
 
English and the current language is Dutch, the modes <code>**en-us</code> and
 
<code>*nl</code> are set (notice the extra <code>*</code> in <code>**en-us</code>).  
 
<code>*nl</code> are set (notice the extra <code>*</code> in <code>**en-us</code>).  
 +
 +
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
|'''*figure'''
 +
| Enabled when a graphic is found
 +
|-
 +
|'''*interaction'''
 +
| Enabled when interaction is enabled
 +
|-
 +
|'''*grid'''
 +
| Enabled when grid typesetting is enabled
 +
|}
 +
 +
{|cellpadding="5"  style="border-collapse: collapse;border-width: 1px; border-style: solid;"
 +
|'''*pdf'''
 +
| Enabled when the main output is pdf
 +
|-
 +
|'''*dvi'''
 +
| Enabled when the main output is dvi
 +
|}
  
 
Other system modes: <code>*figure</code> is set when a graphic is found,
 
Other system modes: <code>*figure</code> is set when a graphic is found,
Line 228: Line 399:
 
<texcode>
 
<texcode>
 
\startmode[palatino]
 
\startmode[palatino]
  \usetypescript[palatino][8r]
 
 
   \setupbodyfont[palatino,12pt]
 
   \setupbodyfont[palatino,12pt]
 
\stopmode
 
\stopmode
  
 
\startmode[times]
 
\startmode[times]
  \usetypescript[postscript][8r]
 
 
   \setupbodyfont[postscript,12pt]
 
   \setupbodyfont[postscript,12pt]
 
\stopmode
 
\stopmode
Line 243: Line 412:
 
and run with one of the following:
 
and run with one of the following:
  
   texexec --mode=palatino filename
+
   context --mode=palatino filename
   texexec --mode=times    filename
+
   context --mode=times    filename
  
 
== Running external commands once ==
 
== Running external commands once ==
Line 261: Line 430:
 
</texcode>
 
</texcode>
  
 
+
{{Getting started navbox}}
  
 
[[Category:ConTeXt programming]]
 
[[Category:ConTeXt programming]]

Revision as of 11:39, 11 March 2019

< The ConTeXt Way | Inside ConTeXt | Project structure >

Very often, you want to generate multiple versions of the same document: one version for printing and one for viewing on the screen, one version for students and one version for the instructor, and so on. You can do this in a simple but naive way: create different files set up for the different versions and \input the common material, or create some new conditional flags using \newif and set them appropriately for conditional processing. Or you could use modes—the ConTeXt way of doing conditional processing.

Introduction

A mode is similar to a conditional flag, but with a few advantages: new modes need not be explicitly defined (no need for something like \newif), multiple modes can be simultaneously enabled or disabled, and the status of multiple modes can be checked easily. Moreover, modes can be set from a command line switch. As a result, multiple versions of a document can be generated without changing the source file.

The name or identifier of a mode can be any combination of letters, digits, or spaces. Names starting with * are reserved for system modes.

In this article I explain how to activate a mode and how to check if a mode is active or not.

Setting modes

ConTeXt has three commands for setting modes:

The names are self-descriptive. \enablemode activates a mode, \disablemode deactivates a mode, and \preventmode permanently deactivates a mode. All three commands take a list of modes as an argument. For example, you can activate modes named screen and solution with

\enablemode[screen,solution]

Modes can also be activated by a command line switch --modes to texexec or context. For example, another way to activate the screen and solution modes, to run ConTeXt using one of:

 texexec --mode=screen,solution ...
 context --mode=screen,solution ...

Pre-defining modes

Normally, the overhead for testing modes is negligible, but it can add up if modes are tested multiple times in a document (for example, as part of a macro). In such cases, you can define a mode before using them, to speed up the processing. Modes are defined using:

\definemode[...][...]

The first argument is a list of modes; the second argument may be yes, no, or keep. For example,

  • \definemode[screen][yes] defines a mode and enables it;
  • \definemode[screen][no] defines a mode and disables it;
  • \definemode[screen][keep] defines a mode and keeps its previous status.

Typically, it is better to use \definemode[...][keep] so that the modes may be enabled or disabled from command line as well.

Conditional processing based on modes

You may want to process or ignore a chunk of code if a particular mode is enabled or disabled. Such a chunk of code is specified using \startmode and \startnotmode environments. Their use is best explained by an example.

Suppose you want to change the paper size of a document depending on whether it is for print or screen. This can be done in multiple ways. You could set the default paper size for print and change it in screen mode:

\setuppapersize[letter][letter]
\startmode[screen]
  \setuppapersize[S6][S6]
\stopmode

(S6 is one of the screen-optimized paper sizes in ConTeXt; the paper size has a 4:3 aspect ratio and a width equal to the width of A4 paper.)

Alternatively, you could set a default paper size for the screen and change it if screen mode is not enabled:

\setuppapersize[S6][S6]
\startnotmode[screen]
  \setuppapersize[letter][letter]
\stopnotmode

\startmode (and \startnotmode) checks the value of the mode at the time it is executed. This is important when you are setting the modes using \enablemode or \disablemode. For example,

\enablemode[foo]
\startmode[foo]
...
\stopmode

the contents of the mode environment are executed because foo is enabled when \startmode is encountered. However, in

\startmode[foo]
...
\stopmode
\enablemode[foo]

the contents of the mode environment are not execited because foo is not enabled when \startmode is encountered.


Checking for multiple modes (or/and statements for modes)

\startmode and \startnotmode can check for multiple modes, by giving a list of modes as their arguments. \startmode processes its contents (everything until the next \stopmode, thus \startmode cannot be nested.) if any of the modes are enabled, otherwise (i.e., when all the modes are disabled) \startmode ignores its contents. The opposite is \startnotmode: it processes its contents (everything until the next \stopnotmode) if any of the modes are disabled, otherwise—when all the modes are enabled—the contents are ignored.

\startmode and \startnotmode are "or" environments. They process their contents if any of the modes satisfy the required condition. Their "and" counterparts are also available: \startallmodes and \startnotallmodes process their contents only if all the given modes satisfy the required condition. For example, suppose you want to enable interaction (e.g., hyperlinks) only when both screen and solution modes are enabled. Then you can use:

\startallmodes[screen,solution]
  \setupinteraction[state=start]
\stopallmodes

To summarize, the four start-stop environments for checking modes are:

\startmode[mode1, mode2, ...]
  % Processed if any of the modes is enabled
\stopmode

\startnotmode[mode1, mode2, ...]
  % Processed if any of the modes is disabled
\stopnotmode

\startallmodes[mode1, mode2, ...]
  % Processed if all the modes are enabled
\stopallmodes

\startnotallmodes[mode1, mode2, ...]
  % Processed if all the modes are disabled
\stopnotallmodes

These environments have \doif... alternatives that are useful for short setups. Also, they can be nested.

\doifmode        {mode1, mode2, ...} {Processed if any mode is enabled}
\doifnotmode     {mode1, mode2, ...} {Processed if any mode is disabled}
\doifallmodes    {mode1, mode2, ...} {Processed if all modes are enabled}
\doifnotallmodes {mode1, mode2, ...} {Processed if all modes are disabled}

The logic for determining when the content is processed is exactly the same as for the start-stop commands.

These \doif commands each have a variant to process alternative code if the conditions are not satisfied (like the \else branch of \if).

\doifmodeelse        {mode1, mode2, ...} {Processed if any mode is enabled}    {else this is processed} 
\doifallmodeselse    {mode1, mode2, ...} {Processed if all modes are enabled}  {else this is processed} 
\doifnotallmodeselse {mode1, mode2, ...} {Processed if all modes are disabled} {else this is processed}

Note that there is no command \doifnotmodeelse because there is no need for it; \doifmodeelse may be used for the same effect (with the if and else branches switched).

Checking multiple modes in parallel (case statement for modes)

In addition to the above "or" and "and" environment which check modes is sequence, you can also check multiple modes in parallel. The syntax for such a "case" environment is as follows:

\startmodeset
    [mode1, mode2, ...]     {Processed if either mode is enabled}
    [mode3, mode4, ...]     {Processed if either mode is enabled}
    [default]               {Processed if none of the above modes match}
\stopmodeset

The same mode can be referenced multiple times, and all matching branches are executed. The \startmodeset ... \stopmodeset environments can be nested. So, you can use

\startmodeset
    [mode1, mode2] {
        Processed when either mode1 or mode2 is enabled
    } 
    [mode3] {
        \startmodeset
            [mode1]     {Processed when mode1 and mode3 are enabled}
            [mode2]     {Processed when mode2 and mode3 are enabled}
            [default]   {Processed when mode3 is enabled and mode1 and mode2 are disabled}
        \stopmodeset
    }
    [default] {
        Processed when mode1, mode2, and mode3 are disabled.:
    }
\stopmodeset

Checking modes in Lua

In MkIV, the state of any mode is accessible at the Lua end as tex.modes table. Specifically,

tex.modes["screen"]

returns true if mode screen is enabled and false otherwise. Thus, specific combinations of modes can be checked using boolean expressions. For example

if (tex.modes["mode1"] and tex.modes["mode2"]) then
 ...
end

checks if both mode1 and mode2 are enabled.


System modes

Besides allowing user-definable modes, ConTeXt provides some system modes. These modes start with a * character. Here only the more commonly used system modes are explained; see the ConTeXt modes manual for a complete list.


*mkii Enabled when running MkII
*mkiv Enabled when running MkIV


Perhaps the most useful system modes are *mkii and *mkiv which determine whether MKII or MKIV is being used. These modes are handy when you want different setups for MKII and MKIV.

Other modes are useful for very specific situations. Some of these are described below.


*first Enabled during the first compile run

A document must be run multiple times to get the cross referencing, table of contents, etc. right. However, sometimes you need to do some external processing (e.g., graphic conversion) that only needs to be done once. In such cases, the *first mode is handy—it is active only on the first run of the document.



*export Enabled when \setupbackend[export=yes] is set

You may want to use different images for XML [Export]. The *export mode is useful in such cases.



*project Enabled when inside \startproject ... \stopproject
*component Enabled when inside \startcomponent...\stopcomponent
*environment Enabled when inside \startenvironment ... \stopenvironment
*text Enabled when inside \starttext ... \stoptext.

You can use the project-product-component structure for managing large projects like a book series. See Project structure for details of this approach. A product or its components may be compiled separately, and you may want to do something different when a product is compiled or when a component is compiled. To do so, you need to check for modes *project, *product, *component, and *environment; these modes are set when the corresponding structure file is processed. For example, the *product mode is set whenever a product file is read; more specifically, when \startproduct is encountered. Similarly, a mode *text is enabled when \starttext is encountered, and likewise for the others.


*frontpart Enabled when inside \startfrontmatter ... \stopfrontmatter
*bodypart Enabled when inside \startbodymatter ... \stopbodymatter
*backpart Enabled when inside \startbackmatter ... \stopbackmatter

A large document is typically broken down into different section blocks: frontmatter, bodymatter, appendices, and backmatter. Internally, these section blocks are referred to as frontpart, bodypart, appendix, and backpart. Each section block sets a system mode with the same name. So, if you want macros that work differently in different section blocks, you can check for modes *frontpart, *bodypart, and so on.


*list Enabled inside a list entry
*marking Enabled inside a marking
*register Enabled inside a register
*chapter, *section, etc. Enabled inside the corresponding section head.


Sometimes you want a macro to behave differently if it is part of a section head, a section number, a list, a marking, or a register. For section heads, you can check for modes *chapter, *section, *subsection, etc. Similarly, *list is enabled inside a list, *marking is enabled inside a marking, and *register is enabled inside a register.


*en-us, *nl, etc. Enabled when the current \language is en-us, nl, etc.
**en-us, **nl, etc. Enabled when the \mainlanguage is en-us, nl, etc.

ConTeXt provides support for multiple languages. Languages are recognized by their IETF language tags, like en-us for US English, en-gb for British English, nl for Dutch, de for German, etc. A document has a main language, set with the command \mainlanguage[...], that is used for translated labels like chapter and figure. You can also switch the current language using \language[...] to change the hyphenation rules. Whenever a language is chosen, its identifier is set as a mode. The mode for the main language starts with two *. For example, when the main language is US English and the current language is Dutch, the modes **en-us and *nl are set (notice the extra * in **en-us).


*figure Enabled when a graphic is found
*interaction Enabled when interaction is enabled
*grid Enabled when grid typesetting is enabled
*pdf Enabled when the main output is pdf
*dvi Enabled when the main output is dvi

Other system modes: *figure is set when a graphic is found, *interaction is set when interaction is enabled, *grid is set when grid typesetting is enabled, and *pdf and *dvi are set when the output is PDF or DVI. Others are too esoteric to describe here. If you are interested, see the modes manual mentioned earlier.

Specific Examples

Different fonts

Suppose you want to generate two versions of a document, one with times font and one with palatino. One way to do this is as follows:

\startmode[palatino]
   \setupbodyfont[palatino,12pt]
\stopmode

\startmode[times]
   \setupbodyfont[postscript,12pt]
\stopmode

\starttext
\input knuth
\stoptext

and run with one of the following:

 context --mode=palatino filename
 context --mode=times    filename

Running external commands once

Suppose you want to run some external program, say to generate a figure. Unfortunately, the program only generates postscript figure. So you want to convert it to pdf. This can be done as follows:

\startmode[*first]
   % external program which creates a file fig-1.ps
   \executesystemcommand{some_external_program ...}
   % convert PS into PDF
   \executesystemcommand{texmfstart pstopdf fig-1.ps}
\stopmode

% include the resulting PDF
\externalfigure[fig-1]

Template:Getting started navbox