# The GELLMU Manual

## William F. Hammond

#### Dept. of Mathematics & Statistics University at Albany Albany, New York 12222 (USA)

Email: hammond@math.albany.edu

### ABSTRACT

This is the manual for Generalized Extensible LaTeX-Like Markup (GELLMU). The central focus in the GELLMU project is to tie LaTeX to the worlds of SGML and XML by providing LaTeX-like markup for writing documents under SGML and XML vocabularies (formally known as document types).

The Manual explains the distinction between basic and advanced use, provides a description of regular GELLMU as an instance of advanced GELLMU, and discusses the use of the didactic production system, which is the project's suite of processors for working with regular GELLMU.

The Manual also deals with the metacommands available when writing GELLMU markup. One of these metacommands is the project's emulation of LaTeX's newcommand, which makes it possible to have macros taking multiple arguments while writing for an SGML or XML vocabulary.

1  Introduction... *
2  Basic GELLMU... *
3  Metacommands... *
3.1  \documenttype... *
3.2  \newcommand... *
3.3  \begin{} … \end{}... *
3.4  \macro and \Macro... *
3.5  Macro-Level Fronting of SGML Element Names... *
4.1  Illustrations.... *
4.2  Multiple Argument/Option Syntax... *
4.3  Limitation in Regard to XML... *
5  The Didactic Document Type... *
5.1  Suggestions and Caveats... *
5.2  Markup Fundamentals... *
5.2.1  Explicitly named commands.... *
5.2.2  Certain single characters.... *
5.2.3  Certain strings... *
5.3  Large Structure... *
5.4  Sectioning... *
5.5  Labels, References, and Anchors... *
5.5.1  Labels and Sequencing... *
5.5.2  Anchors... *
5.5.3  Example Emulating a LaTeX Counter... *
5.6  General Usage for Sectional Units... *
5.6.1  The Content Model... *
5.6.2  The LaTeX-Like Form of General Usage... *
5.7  verbatim, verblist, and manmac... *
5.8  Accents... *
5.9  Tabular Environment Emulation... *
5.10  Graphic Inclusions... *
6  Mathematics in article... *
6.1  General... *
6.2  Assertions... *
6.2.1  Examples... *
6.2.2  Usage for assertion... *
6.3  Equations and Equation Arrays... *
6.4  The \mathsym Metacommand... *
7  The Didactic Production System... *
7.1  Permission... *
7.2  Materials... *
7.3  Other Required Software... *
7.4  Using the syntactic translator... *
7.4.1  Operation in Batch Mode... *
7.4.2  Interactive Operation... *
7.4.3  Interrupting the Syntactic Translator... *
7.5  Using the didactic production system... *
7.5.1  Staged Design... *
7.5.2  Default Staging... *
7.5.3  Parsing with nsgmls... *
7.5.4  Processing with sgmlspl... *
7.5.5  Environmental Variables... *
Appendix A  The GELLMU Archive... *
Appendix B  Release Notes... *
B.1  Comments on the Syntactic Translator... *
B.2  Comments on the Didactic Production System... *
B.2.1  Internationalization... *
B.2.2  Document Type Definitions... *
B.2.3  Translation to XML... *
B.2.4  Translation to HTML... *
B.2.5  Translation to LaTeX... *
B.2.6  Future Plans... *

### 1.  Introduction

GELLMU is an acronym for “Generalized Extensible LaTeX-Like MarkUp”, which is the author's concept for using LaTeX-like markup to write consciously for SGML document types such as HTML, DocBook, TEI, or GELLMU's own didactic LaTeX-like document type called article.

It evolved from earlier thought about delineation of a coherent subset of LaTeX commands with the property that if a LaTeX document used only those commands then it could be translated with full reliability to other formats including HTML so that documents could be prepared both for print and for the web from a single source.

Problems with this early thought during the years 1996–1997 included the fact that there did not seem to be a community of LaTeX users willing to focus on a narrow vocabulary and the fact then of a legacy practice that mixed LaTeX commands freely with non-LaTeX TeX commands.

The present idea was crystalized in the summer of 1998 while the author was looking at Ulrich Vieth's LaTeX markup for the TeX Directory System (TDS) specification from the TeX User Group (TUG), which now is physically realized in TUG's TeXLive series of TeX-related software distributions on CDrom. The HTML version of that specification was derived through an intermediate ad hoc translation from LaTeX to Texinfo, the language of the GNU Documentation System, which is a robust hypertext system, pre-dating HTML, that is driven by TeX the Program.

In thinking about generalizing Vieth's ad hoc translation, which used GNU Emacs Lisp (Elisp), one of the most widely available free cross-platform programming languages for which there is a free robust engine, the same engine that underlies the interactive editing interface of Emacs, the author realized that the structure of Texinfo is very much like that of an authoring level SGML document type. From that idea it was a small step to decide that one might profitably write Elisp code to use LaTeX-like markup for the conscious writing of a new LaTeX-like article document type.


Software associated with the GELLMU project falls into two parts:

1. The syntactic translator. This is a purely syntactic layer for converting LaTeX-like markup in configurable ways to SGML markup. Its output may be handled in standard SGML or XML systems.

2. The didactic production system. This component is a sketch, which might usefully serve as a base for further development, of an SGML production system for an authoring environment that consists of

1. An SGML document type called article that is accompanied by a corresponding XML document type.

2. A package of extensible translating utilities written in the language Perl.

As its name suggests, these materials are didactic and should be regarded as unfinished for production work.

There are two overall concepts: basic mode and advanced mode. The basic mode may be used to write consciously for any standard document type such as HTML, DocBook, or TEI, and the syntactic translator is for that mode the only software under this project that might be relevant. The advanced mode incorporates a configurable broader array of LaTeX-like markup features, mostly for brevity, in the syntactic translator. This mode is fully developed only for use with a LaTeX-like document type such as the didactic article document type that is part of the didactic production system.

One may use any SGML or XML processing framework in working with the article document type. The didactic production system includes what is needed to produce both HTML and regular LaTeX forms of an article instance. Consequently, one is able to produce both DVI using the LaTeX format for TeX, the program, and PDF using the LaTeX format for PDFTeX, the program. Moreover, one may tune the PDF in various ways using small alterations of the Perl code for translating the XML version of article to regular LaTeX.

### 2.  Basic GELLMU

Neither the basic nor the advanced mode involves in any way adoption of the language of LaTeX. (But many command names under the didactic article document type, mimic LaTeX command names.) There are two fundamental ideas:

1. A LaTeX-like command “\foo” corresponds to an SGML element “<foo>”.

2. The syntactic translator is almost entirely ignorant of vocabulary and a name like foo need not have meaning in it although it must have meaning in the document type for which one is consciously writing.1

To use the basic mode one must be familiar with the SGML document type for which one is writing. Ordinary HTML is an example. Very few of the features in the advanced markup not also part of the basic markup2 make any sense for use in the direct preparation of HTML with LaTeX-like input.

GELLMU uses LaTeX special characters such as ‘\’, ‘{’, and ‘}’ along with LaTeX-like argument/option syntax, where braces immediately following a command name indicate command arguments and square brackets, i.e., ‘[’ and ‘]’, indicate command options. A command corresponds to an SGML element, and in basic mode a command may have at most one argument, the content of which corresponds to SGML element content, and at most one option, the content of which corresponds to a list of SGML attribute specifications. Thus for example, in basic mode for HTML one may use the markup

 \a[href="http://www.w3.org/"]{The World Wide Web Consortium}

to form the HTML anchor:

 The World Wide Web Consortium .

(The formation of anchors with the didactic article document type in advanced mode is slightly more complicated because the characters ‘=’ and ‘/’, which may acquire special (and “overloaded”) semantic significance in mathematical contexts, are held for delayed evaluation as empty elements and because the syntactic translator, which does not recognize command names, regards this usage in advanced mode as multiple argument/option syntax (section 4.2), which is not part of basic mode.)

An example of the distinction between basic and advanced GELLMU is that in advanced mode it is possible and easy to arrange to have a blank line, as in LaTeX, represent the beginning of a paragraph. In basic mode for HTML one must3 use “\p” to begin a paragraph, and for the XML version of HTML one must also provide markup for the end of every paragraph, which may be done in several ways.

For some of the details on using the basic markup with HTML see Using the GELLMU Syntactic Translator to Write HTML. It will be instructive to have the parallel source markup available at the same time.

### 3.  Metacommands

A metacommand is a LaTeX-like command that does not correspond to an SGML element. Each metacommand is handled internally by the syntactic translator.

#### 3.1.  \documenttype

A document prepared in GELLMU source usually begins with a documenttype command. For example,

 \documenttype{html}

is used to begin a document prepared for the most common form of classical HTML.

The syntactic translator has two public variables gellmu-doctype-keylist and gellmu-doctype-info, which are Elisp associative lists, that enable one to match XML or SGML “<!DOCTYPE ... >” declarations with LaTeX-like

 \documenttype[my-optional-key]{my-doctype}

commands, where my-optional-key is available to override a default key for my-doctype. Thus, for example, “\documenttype{html}” points to the default key for “html”, which is “html-4.01” and which points to the W3C HTML 4.01 Transitional document type, while

 \documenttype[xhtml-1.0s]{html}

indicates W3C XHTML 1.0 Strict.

A user may configure these variables without modifying the source code for the GELLMU syntactic translator, but minimal knowledge of Elisp will be required. A future release might provide a configuration file for this purpose.

A second option for the documenttype metacommand, which must follow the single required argument, is provided for writing an internal declaration subset. The contents of an internal declaration subset constructed this way may be any internal declaration subset material. However, some care is required for entering characters that are special. To ease the handling of special characters four metacommands have been provided for use inside the internal declaration subset:

For example, a user who wishes to be able in source to use “&quo;” to reference the ASCII quotation mark when writing consciously in basic mode for TEI.2 would begin the source file with:

\documenttype{TEI.2}[
\entity{quo "&#x22;"}
]

#### 3.2.  \newcommand


The general construction of a newcommand definition is

 \newcommand{name}[nargs][first]{value}

where name is the name of the newcommand, nargs optionally specifies the number of its arguments, first is an optionally-provided default value for the first argument, and value denotes the value string.


Example. In writing HTML one might use

\newcommand{\href}[2][http://www.w3.org/]{\a[href="#1"]{#2}}

for brevity in writing many HTML anchors. With this definition the invocation

 \href{http://www.myweb.mydomain/me.html}{my web page}

gives rise to the HTML markup

 my web page

while the invocation “\href{Web Central}” gives rise to

 Web Central .

Rules.

1. The name of a newcommand may not be referenced in its value string.5


Failure to observe these rules may cause the syntactic translator to enter an infinite recursive loop. If a user suspects this may have happened, then the invocation of the syntactic translator should be interrupted (section 7.4.3).

#### 3.3.  \begin{} … \end{}

These provide emulation of LaTeX environment notation without actually providing anything that is not otherwise available. Markup which resembles that for a LaTeX environment simply resolves to an SGML element. This usage may be convenient for SGML elements of large scope such as, for example, the body of an HTML document.

With advanced mode the special form

 \begin{document} . . . \end{document}

may be used to emulate the corresponding feature of LaTeX for a document type, such as the didactic article document type, that in the large consists of a preamble and a body.

#### 3.4.  \macro and \Macro

Use of these is discouraged in the absence of a need. One situation that presents a need is name “fronting”: see the discussion below in section 3.5. Please note that in most situations one may use newcommand without an argument for simple macro substitutions.


There are four primary differences between macro and Macro, on the one hand, and newcommand, on the other hand.

1. Neither macro nor Macro can be used to define a macro that takes arguments.

2. The name of a newcommand must consist of word characters, but there is no restriction on the characters, apart from unbalanced brace characters (‘{’ and ‘}’), that may appear in the name field of a macro or Macro metacommand.

3. If the name of a macro or Macro does not begin with the command sequence introducer, i.e., the character ‘\’, then an invocation of that metacommand is given by every forward match of its name. The use of such names is strongly discouraged because document segments can then become opaque much too easily.

4. A newcommand invocation, absent the use of a semi-colon for termination, is only effective at the whole word level — with word here denoting a maximal string of successive word characters — whereas macro and Macro invocations are effective regardless of word boundaries.


Human authors using either macro or Macro may find unanticipated interactions between the three forms of macro substitution.

Unbalanced brace characters, i.e., the characters ‘{’ and ‘}’, may not be used in the name field or the value field of any form of macro metacommand.

#### 3.5.  Macro-Level Fronting of SGML Element Names

The word fronting as used here describes the practice of modifying the meaning of an SGML element name by using one or more of the macro facilities to generate usage of the same name as an element combined with other markup using the syntax that would otherwise correspond to basic use of the element.

Suppose, for example, one wants all paragraphs in HTML (marked with \p in GELLMU source) to be placed in a (style) class called custom.

Recommended procedure: Create a new unique name and then use macro to front it.

\newcommand{\cp}[1][]{\p[class="custom"]{#1}}
\macro{\p}{\cp}


 \p[class="custom"]{...} .

This will not intercept the alternate, otherwise nearly equivalent, markup given with \begin{p}\end{p} since newcommand is based on simple macro substitution and does not operate at the level of namespaces.

The idea with advanced GELLMU is that for SGML document types sharing structural characteristics with LaTeX one might wish to have the syntactic translator provide LaTeX-like markup syntax beyond the level used with basic GELLMU and that these additional layers of syntax should be configurable. The only substantial realization of this program so far is the case of the GELLMU didactic document type called article. The specifics of that realization are discussed in the following section.

#### 4.1.  Illustrations.

One might want to be able to use blank lines, as in LaTeX, for introducing new paragraphs in a document type that provides paragraphs.

In some article-level document types each sectional unit has a unit header providing markup for various, often optional, unit descriptors. It is convenient to be able to use LaTeX-like multiple argument/option syntax (section 4.2) for these.

If the document type provides authoring-level mathematical markup beyond inclusions of the World Wide Web Consortium's Mathematical Markup Language (MathML) under its XML namespace regime, then one might want to be able to use the ‘$’ character to toggle in and out of inline math, and if the document provides for math displays, then one might want to use, as in LaTeX, the strings “$” and “$” as delimiters for unstructured mathematical displays, and markup such as  $$. . .$$ for a single equation, and markup such as  \begin{eqnarray} . . . \end{eqnarray} for a list of equations. It is important to emphasize, however, that by overall system design the syntactic translator operates without substantial knowledge of vocabulary. While it is true that if ‘$’ is to provide a toggle for an inline element containing math, say, tmath, then the syntactic translator needs to have that association made, but the association is provided as the value of a configuration variable in the syntactic translator that can be changed between documents so that the syntactic translator may be used with many document types.

One way to make such configuration convenient is to use an array of Elisp functions that are fronts with various variable configuration packages for the basic function gellmu-trans in the syntactic translator.

The general outline for advanced GELLMU with arbitrary document types is not fully developed in the present release. Instead the project has concentrated on the realization of these ideas for the project's didactic article document type, which is the subject of the next section.

As the syntactic translator stands now, basic mode is characterized in the syntactic translator by the true setting for its Boolean variable gellmu-straight-sgml, while the configuration used by default for the didactic document type (which could be handled in basic mode with more verbose source markup) has that variable set false and also the variable gellmu-regular-sgml set false.

The term regular GELLMU refers to use of the syntactic translator with the default configuration for the didactic document type. It involves nearly maximal emulation of LaTeX-like markup; it implies both advanced mode and the didactic document type (section 5) article.

#### 4.2.  Multiple Argument/Option Syntax

An essential point in the present design is that the whole system is built from components, each of which has its own function6. Consistent with this design the syntactic translator operates with knowledge of syntax but little or no knowledge of language.

Multiple argument/option syntax has been built into advanced mode as part of the overall idea of providing, where sensible, LaTeX-like features in a precise user markup interface for writing in document types under SGML and XML.

What are the rules for converting the multiple argument/option syntax in source markup into SGML? Direct conversion by the syntactic translator of this type of usage into XML is not available because such conversion requires some language knowledge and the program does not operate with knowledge of language at that level7. One obtains an XML version of a document in the didactic production system by using a translator with minimal knowledge of the command vocabulary to create the XML version from an SGML version that is the immediate output of the syntactic translator.

In multiple argument/option syntax, which is much like that of LaTeX, arguments and options follow command names. Arguments are delimited by braces, i.e., ‘{’ and ‘}’ and options by square brackets, i.e., ‘[’ and ‘]’. There must be no white space between the arguments and options nor between the command name and the first member of an argument/option sequence.

Each command with a multiple argument/option sequence is translated to an open tag whose name is the name of the command. Each argument is translated to an ag0 element and each option to an op0 element. (Both ag0 and op0 lie in GELLMU's reserved name space.) There are two exceptional cases.

1. The first argument or option is an option inside which the very first character is a colon, i.e., ‘:’. This is the method provided in advanced mode for the direct entry of an SGML attribute sequence.8 The entire contents of the option string, apart from the leading ‘:’, which is discarded, are understood to be a sequence of SGML attributes for the SGML element whose name is the name of the command. There is no syntax check of the attribute contents by the syntactic translator. Such an attribute option is not treated as an op0 element. In particular, an attribute option is correctly followed immediately by a semi-colon, i.e., the character ‘;’, if and only if the corresponding SGML element is a defined-empty element under the SGML document type. Since SGML attributes correspond to very little of classical LaTeX9, attribute options are seldom used10 in the didactic production system. One such use is for the GELLMU equivalent of latex's equation* and eqnarray* environments, which is marked up this way:

[:nonum="true"]
e = mc^2
to produce: $\begin{array}{cc}& e=m{c}^{2}\end{array}$
2. The first argument is the only argument and there are no options apart from a possible attribute option. This case, which is extremely common, is exceptional relative to argument/option handling since the sole argument simply becomes element content without an ag0 wrapper.

When a command has a multiple argument/option sequence, the question arises whether the ag0 and op0 elements that arise from the arguments and options are the only content of the element corresponding to the command. The syntax does not provide a way to determine this. On the other hand, the SGML document type definition does provide information that indicates whether other content is possible. It is beyond the scope of the design of the syntactic translator for the syntactic translator to read a document type definition. The syntactic translator does, however, have a configurable list variable gellmu-autoclose-list that contains the names of elements for which no content beyond the elements arising from arguments and options is possible. While it is not necessary that every such command be entered in this list, when such a command not in the list is not explicitly followed by an element closing command, it is possible in some instances for an SGML parser to infer incorrectly the location of end of the element. Thus, the didactic production system provides a command anch for making anchors. The document type definition provides for one option, a reference, and one argument, the anchored text.11 Because the syntactic translator does not consider the document type definition, if one enters the markup

 \anch[href="http://www.w3.org/"]{W3C} HQ ,

unless the name anch is in the list12 gellmu-autoclose-list, an SGML parser will not have reason to close the anch until it sees the space following the anchored text “W3C”, and so that space will be considered insignificant white space with the result that there will be no space between the anchored text and the following “HQ”.

#### 4.3.  Limitation in Regard to XML

A final general comment about advanced mode is that the features it can provide beyond basic mode when one is writing consciously for an XML document type are somewhat limited. For example, blank lines cannot easily be made adequate for paragraph markup with the XML form of the didactic article document type. Although it is not a specific limitation for future editions of the syntactic translator, the vision is that use of advanced mode will be specifically for a somewhat rich SGML version of a document type.

### 5.  The Didactic Document Type

The didactic document type is the document type underlying what is called regular GELLMU. It is the heart of the idea of GELLMU as a bridge for authors from LaTeX to the world of XML. More specifically, the bridge is from the world of a LaTeX article to a document type in the world of XML, also called article, that has a structure and a vocabulary similar to those of the LaTeX document class.13 The techniques used in the didactic production system are extensible and can be carried over to other types of documents than articles. It is important to note that there are many features in regular LaTeX which have no analogue so far in the development of this project. One might hope to get an idea of the extent of coverage by reviewing the examples in the project archive (appendix A).

When an author prepares a document as a LaTeX article, the document is being marked up as data for a specific typesetting program: Donald Knuth's program TeX running with the main LaTeX facilities loaded.

When an author prepares a document as GELLMU source, the syntactic translator provides a LaTeX-like markup interface, but its output is not data for a specific typesetting program. Rather it is data for a broad class of processors. This means that multiple output formats can be obtained from a single source without the need for human intervention because XML provides a framework that makes it relatively easy to create reliable programs for translation from an XML document type to other formats. It offers, moreover, the possibility of translation to future formats free of any need for human intervention once translators from the original document type to such formats are written. The small price one pays for this advantage in moving from LaTeX markup to GELLMU markup is that the author must learn a few new things.14

There are two formal constructions of the didactic document type. The name of the document type is article. The first construction is an SGML version of article that provides features convenient for authors that are not available under XML. The second is an XML version. For most non-technical purposes the two constructions should be regarded as equivalent.

The SGML construction of an article is derived from GELLMU source markup for a document by using the syntactic translator. The didactic document type is accompanied by a translator implemented under the Perl language framework sgmlspl by David Megginson (see the release notes in appendix B for more information) for converting the SGML version of an article to the XML version.

The description in this section of the manual deals primarily with source level markup for the didactic document type and with how it is handled 15 by the time the XML version of an article is generated. Secondarily there is comment on how it is rendered in the chief output formats of the didactic production system, which are regular HTML16 with math rendering facilitated by MathJax17, PDF, XHTML+MathML, and terminal window HTML (for limited screens).

A quick glance at the flowchart (section 7.5.2) shows that the first XML stage — author-level XML — may be viewed as a second entry point to didactic production system processing. Some day this could become a reasonable formatting route for translations from things like Texinfo, DocBook, and, even perhaps, classical LaTeX itself via a processor such as tex4ht.

#### 5.1.  Suggestions and Caveats

Although this is the manual for a software release, it is not a book. A document of book size would be required for a full description of the didactic production system.

Much of the markup vocabulary is copied from LaTeX. There are some instances where there is some deviation from LaTeX usage, and many of those instances are mentioned here.

Definitive information about the didactic document type may be derived by consulting the document type definition. Because the didactic production system is conceived as a base for future development there are sketches in the document type definition that are not covered by the didactic processors. For example, although there is sketched code for the analogues of LaTeX's paragraph and subparagraph commands, which are sectional in nature, that is found in the translation from SGML to XML, there is no sketched code for these elements in the two formatters.

Another way to obtain information about the didactic production system is by studying examples including this manual and the examples in the project archive (appendix A).

#### 5.2.  Markup Fundamentals

There are several kinds of commands:

##### 5.2.1.  Explicitly named commands.

Apart from macro level metacommands an explicitly named command begins with a maximal string introduced by the character\followed by word characters, including the numerals0’, ‘1’, …, ‘9’. The notion of word character depends on one's locale, a concept that is formalized in GNU Emacs. In the ASCII character set the word characters are the 52 upper and lower case letters and the 10 numerals. The first numeral, if any, must not be ‘0 since such names are reserved for use by the syntactic translator. Command names are case sensitive.

An explicitly named command is a container, corresponding to an SGML element, if its name is immediately followed, without intervening white space, by the character ‘{’. In that case the delimited zone of containment normally ends with the subsequent balancing character ‘}’. (LaTeX-like multiple argument/option (section 4.2) chains deserve more discussion; for now it will suffice to point out that the use of the \anch command in this document for making “anchors” is an example, and, of course, LaTeX's \frac command is another example. For the present discussion these commands are considered to be containers.)

An explicitly named command corresponds to an SGML defined-empty element if its name is immediately followed, without intervening white space, by the character ‘;’.

An explicitly named command corresponds to an SGML element closing tag if its name is immediately followed, without intervening white space, by the character ‘:’.

The name of an explicitly named command is terminated by a non-word character. There is a small, possibly acceptable, level of syntactic ambiguity unless the name terminator is one of ‘{’, ‘;’, ‘:’, or ‘[’.

In basic mode if the name terminator is ‘[’, then that character introduces a list of SGML attribute specifications, each of the form name="value", and the list must be terminated by the character ‘]’. Then if the following character is ‘{’, the named command is a container that ends with the balancing ‘}’. Otherwise the following character may be ‘;’ if the named command is a defined-empty element and must be so in that case for direct editing of an XML document type.

In advanced mode if the name terminator is ‘[’, then that character introduces a LaTeX-like command option — part of the emulation of LaTeX's multiple argument/option syntax (section 4.2) — unless it is immediately followed, without intervening white space, by the character ‘:’, in which case the bracketed content is a list of SGML attribute specifications. (The initial ‘:’, which may be used optionally in basic mode, is discarded.)

In any other case there is some syntactical ambiguity. The syntactic translator will produce a corresponding SGML open tag unless the logical variable gellmu-xml-strict has been set.18 If the usage is consistent with the structure of the document type, an SGML parser will in many cases be able to handle the result correctly. The result of this type of syntactic ambiguity in source markup is not tolerated if one is editing directly for an XML document type. The terminator can be a blank space, but, if so, the blank space is likely to become invisible after SGML parsing much in the way that in LaTeX the markup

 \LaTeX document

will be collapsed into the single word form “LaTeXdocument” when typeset.19

##### 5.2.2.  Certain single characters.

52. * The direct internal subset is the content of the optional argument of the documenttype metacommand that follows its required argument. It should be noted in the didactic production system that the direct internal subset cannot be propagated to the XML form of article because it is digested by any standard SGML parser and, hence, by any translation based on a standard parsing. Thus, any pieces are merged in the XML form of an article although the translator xmlgart might be modified to construct an internal declaration subset there and provide partitioning of the XML version among filesystem pieces based on document structure.
53. * Please observe the rules of the LaTeX project regarding filenames as well as the license rules of the GNU General Public License if you wish to distribute a modified version of the Elisp source. Alternatively, the author is always interested in learning of suggestions for change.
54. * The corresponding usage in LaTeX would be “\'e”; this could be brought into GELLMU source using \macro, but it must be resolved to a name in the output of the GELLMU syntactic translator where everything that is markup needs a name. Rather than using a general container acute, the document type could have provided a name for the specific character.
55. * Alternatively LaTeX source can be submitted to an alternative TeX engine such as xetex, luatex, omega, … that is an extending modification of Donald Knuth's program TeX.
56. * There is no formal document type definition for a “.zml” file because such a file is endowed via XML attributes with information about tree structure for mathematical zones.