Linuxdoc Reference

A introduction to the linuxdoc dtd

Uwe Böhme, <uwe@hof.baynet.de>

v1.1, 30 January 2000

This article is intended to be a reference for the SGML document type definition linuxdoc, which is coming along with the SGML text formatting system version 1.0. It should also be applicable to future versions which may be found at My Homepage .

1. Making of

2. Introduction

3. A minimalistic document

4. Document Classes

5. Inlines

6. Sectioning

7. Paragraphs

8. Inline Tags

9. Mathematical Formulas

10. Labels and References

11. Indices

11.1 Including a index

12. Literate Programming

13. Reference

Appendix

14. Named Symbols

15. Mathematical Figures

16. Linuxdoc dtd Source

1. Making of

1.1 Legal stuff

Copyright © 1997-2000 by Uwe Böhme. This document may be distributed under the terms set forth in the Linux Documentation Project License at LDP . Please contact the authors if you are unable to get the license. This is free documentation. It is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.

This document is not part of ldp (even if I took their form of license). I'm not yet playing in that league.

1.2 Genesis

This document was born trying to learn more about writing texts on my linux system. The one system looking like suitable to my needs was sgml-tools SGML-Tools Organsation an the linuxdoc dtd.

In [ SGML-Tools User's Guide 1.0 ($Revision: 1.1.1.1 $) ] (see section Reference ) the overall structure is described nice and easy. Also [ Quick SGML Example, v1.0 ] (see section Reference ) was helpful, but :

A lot of features are not mentioned.

On the way to learn more about it, I met [ The qwertz Document Type Definition ] (see section Reference ). It's as detailed as hoped, but it's not made for the linuxdoc dtd (even if linuxdoc is based on qwertz).

I tried a new approach: Look at the dtd

dtd = document type definition

file itself, and try to understand it.

As time went by I noticed that I also forgot about some stuff, or - at least - didn't point it out strong enough. This will change within the next revision.

Any feedback you might have is welcome (especially help with English spelling or grammar) by e-mail at Uwe Böhme .

2. Introduction

The principle of any sgml'ed document (linuxdoc, docbook, html) is more or less the same:

Don't write how it should look like , but write what it is .

This is a different approach than the standard "wysiwyg"

What you see is what you (should) get (if you are a very lucky one and your computer wins the war against buggy software)

one

You might want to call it wysiwym , i.e. "What you see is what you mean"

. You do not tell the program that this line should be in a bigger font, to look like a headline. What you do is telling that this line is a headline. You do not try to make your document look like a report, but you tag it to be a report. So you tag the text with the appropriate <tag>.

The big advantages of this approache are:

You do not need to mess around with fontsetting, line gaps or anything directly connected to the layout.
You describe your document in a more abstract way so it's more reusable and can be mapped to different media types.
If you ever tried the reuse a document written in a specialized wysiwy layout for html then you know what I'm talking about.

In addition in all sgml-style documents you will find named symbols This is a concept to expand the charset of the document and to avoid inconsitences in decision of the parser, how to interpret or map some special characters.

How should the parser know weather a < character is starting a tag or should be printed directly. This is solved by the named character lt . If you write < this one will result to < in your text. For a list of the named symbols see Named Symbols .

Hint for the new user: It might be a good idea, to download this document not only as a dvi or ps document, but also to download the sgml source. This offers you the chance to look into the sources, if you find something within this article, wich might fit your needs.

3. A minimalistic document

In this section you'll find what you'll need for a minimalistic linuxdoc dtd conform document. It's intended to give a first touch. Skip this section, if you already now the principles.

3.1 Step By Step

The steps you have to do to create a nice linuxdoc document and map it to the form you need are:

Take a plain text editor of your choice.
Create a file and name it (or later save it as) e.g. start.sgml .
Type the document
Save the file and close your editor.
Run the checker by typing sgmlcheck start.sgml .
If you get errors reported, reopen your document in your editor again and try to correct it
The error messages of sgmlcheck will give you a hint about the type of error and also line and column where it occurred.
. Run the checker again until no more errors occur.

Now you have to decide what's your document for. Take the apropriate parser mapper combination and translate your document. To find the mappers available in the SGML-Tools see table SGML-Tools mappers for sgml documents .

SGML-Tools mappers for sgml documents
type	to produce

`sgml2html start.sgml`	Hypertext markup language for web browsers
`sgml2lyx start.sgml`	Lyx or KLyx wysiwym textformat
`sgml2info start.sgml`	Info page for UN*X info
`sgml2latex start.sgml`	DVI output
`sgml2latex --output=tex start.sgml`	pure tex output
`sgml2latex --output=ps start.sgml`	postscript output
`sgml2rtf start.sgml`	rich text format
`sgml2txt start.sgml`	pure text

3.2 A Startup Document

We start with a simple document (the numbers and colon in the beginning of the line are for explanation, don't type it!):


1: <!doctype linuxdoc system>

2: <notes>

3: <title>
A Small Linuxdoc Example</title>

4: <p>
Hello <em>
world</em>
.</p>

5: <p>
<bf>
Here</bf>
 we are.</p>

6: </notes>

Now we take a look at the single lines:

A linuxdoc document has to start, like all SGML conform documents, with the preamble . If you like you can take it as a piece of necessary magic, or you can try to find more information about SGML. The preamble is indicating to the SGML-parser, which dtd (document type definition) it should use for checking the syntax of the document.
Open the document class : You have to decide, wich type of document you want to write. See section Document Classes for detailed description about that document classes . The necessary header information, wich is depending on the document class is also explained there. In our case we place a <notes> tag forming a note, wich is indicating a simple unstructured document.
Even if optional it's a good idea to give a title to the document. That's done with the <title> tag.
A paragraph marked by the <p> tag, containing the word world wich is inline emphasize d by the <em> tag.
Another completely tagged paragraph, with another word inline boldface d by the <bf> tag.
Here we close the open document class tag.

The same example may be written a little bit shorter, by leaving out tags which are placed automatically by the parser, and by using shortened tags:


1: <!doctype linuxdoc system>

2: <notes>

3: <title>
A Small Linuxdoc Example
4: <p>
Hello <em/world/.
5:
6: <bf/Here/ we are.
7: </notes>

Now we look at the single lines again:

The preambel .
The document class (also unchanged).
The title . It's not closed, because the p tag in the next line is implicitely closing it.
The paragraph is implicitly closing the title . The emphasize tag is noted in short form. The short notation you can use only if your tagged text doesn't contain a litteral / . The paragraph is not explicitly closed in this line.
The empty line here is the reason, why you don't need to close the previous paragraph and don't need to open the next one. A empty line is interpreted as a end of the current paragraph and the start of a new one.
Another paragraph (not opened directly), with another short inline tag.
Closing the open document class tag, wich is implicitly also closing the still open paragraph.

Maybe now it's a little bit more clear, who you have to work with tags.

4. Document Classes


<!element linuxdoc o o 
        (sect | chapt | article | report | 
         book | letter | telefax | slides | notes | manpage )>

This is describing the overall class of the document, so naturally it has (leave alone the doctype definition) to be the first tag enclosing your whole document. Some of the tags namely the sect and chapt (see section Sectioning Tags ) doesn't make any sense taken them standalone despite being included as part of more complete classed document, so we'll describe them later as a part of the other document classes. Decide first which of the top mentioned document classes fits the type of the document you want to write best.

To find a detailed description of the document classes see table Document classes .

Document classes
Chapter	Class tag

Article Tag	`<atricle>`
Report Tag	`<report>`
Book Tag	`<book>`
Letter Tag	`<letter>`
Telefax Tag	`<telefax>`
Slides Tag	`<slides>`
Notes Tag	`<notes>`
Manpage Tag	`<manpage>`

To me the article class is the most important one. That�s the reason why it�s described first and most detailed.

4.1 Article Tag


<!element article - -
        (titlepag, header?,
         toc?, lof?, lot?, p*, sect*,
         (appendix, sect+)?, biblio?) +(footnote)>


<!attlist article
        opts cdata "null">

You can see that the article needs some tags included. They will be explained in consequence.

The options attribute (opts ) takes a comma separated list with thy different style (LaTeX .sty ) sheets to inlude within the document.

Titlepage Tag


<!element titlepag o o (title, author, date?, abstract?)>

The Titlepage Tag (


titlepag

) is implicitly placed as soon a you started your document class . You don't need to write it explicitly. Anyway you have to note it's mandatory tags. It's purpouse is to describe the layout and elements of the titlepages.

Title Tag


<!element title - o (%inline, subtitle?) +(newline)>

Each document class wich owns a titlepage of course needs a title , wich is noted down with a


<title>

tag. You don't need to close thatone. A title may contain a subtitle started by the


<subtitle>

tag.

If you look at the headerpage of this document you'll find it to be mapped from the tags:


<title>
Linuxdoc Reference
<subtitle>
A introduction to the linuxdoc dtd

Author Tag


<!element author - o (name, thanks?, inst?,
                        (and, name, thanks?, inst?)*)>

Usually you place the (your) name here. People should know who wrote the document, so you place a


<author>

tag. If you don't note the


name

tag it�s imlicitly placed. The author has also optional items wich can be tagged within the


author

tag.

If you want to say thanks to anyone (might be somebody providing usefull information) you place it within the <thanks> tag. Next, if your writing is done in your position of an institution staff member, place it within the <inst> tag.

The <and> tag is starting the whole story again, as if there would be a second author tag would have been started. Clearly thisone is for coauthors.

Date Tag

If you want to mark your document with a date , you can do that with the <date> tag.

It's not checked weather you really place a valid date here, but don't abuse it.

Abstract Tag

This tag is intended for an abstract description of your document. Don't mix the <abstract> tag withh an indruduction wich is likely to be placed inside the first section of your document (see section Sectioning ).

Header Tag


<!element header - - (lhead, rhead) >
<!element lhead - o (%inline)>
<!element rhead - o (%inline)>


<header>

tag specifies what should be printed at the top of each page. It consists of a left heading i.e.


<lhead>

and a right heading i.e.


<rhead>

). Both elements are required, if a heading is used at all, but either may be left empty, so that the effect of having only a left or right heading can be achieved easily enough.

As we will see, an initial header can be given after the title page. Afterwards, a new header can be given for each new chapter or section. The header printed on a page is the one which is in effect at the end of the current page. So that the header will be that of the last section starting on the page.

Table Of Contents Tag

If you place the <toc> tag, a table of contense will be generated, by looking the section heading, and adding references.

In a hyperref document, this might be hyperrefs, in a LaTeX document you will come to see the pagenumbers.

Only the sections major to the


sect3

will be included.

List Of Figures Tag

If you place the <lof> tag, a list of figures will be generated, by looking the captions of the figures, and adding references.

List Of Tables Tag

If you place the <lot> tag, a list of tables will be generated, by looking the captions of the tables, and adding references.

Body

Here you place various sections according section Sectioning . There is no body tag . The body starts with the first chapter , section or paragraph .

Appendix Tag

In the end of the article you can place the <appendix> tag

Really you shouldn't think about people (e.g. m.d.s knifing your belly here.

, wich starts a area of appended sections. The


appendix

tag implies a different section numbering type to the following section tags.

Bibliography Tag

It's intended to gather all the <cites> and <ncites> you used within your document. The <biblio> tag will be replaced by a bibliography according the mapping type of the document, maybe by hyperrefs maybe by section numbers or anything wich might be useful.

Until now I've not been able to create a .bbl file, so I wasn't able to verify.

Footnote Tag

A footnote may be place in any spot of your document. Exactly the spot in yout document where you are placing the <footnote> tag should be the one where the reference to the tagged text shuld be rendered. It should be used for additional information, wich is not necessary for understanding the primary purpouse of yor document but might be usefull, interesting, or funny.

Whereas the last one is not always true, even if you try.

anywhere within the article.

4.2 Report Tag


<!element report - -
        (titlepag, header?, toc?, lof?, lot?, p*,
         chapt*, (appendix, chapt+)?, biblio?) +(footnote)>

The report is a document class with a chapter oriented approach. So within a document clasified by a


<report>

tag the toplevel is grouped by the


<chapt>

tag (see Sectioning ). The rest of the structure is identical to the article class Article Tag .

4.3 Book Tag


<!element book  - -
        (titlepag, header?, toc?, lof?, lot?, p*, chapt*,
         (appendix, chapt+)?, biblio?) +(footnote)>

You will notice that the book element is identical to the report Report Tag . So anything valid there is also valid if you classify your document with a


<book>

tag.

4.4 Letter Tag


<!entity  % addr "(address?, email?, phone?, fax?)">


<!element letter - -
        (from, %addr, to, %addr, cc?, subject?, sref?, rref?,
         rdate?, opening, p+, closing, encl?, ps?)>

Also the purpose of the letter document class should be quite self explaining. Place a <letter> tag if you want to write one.

The letter's tags ar described in table Tags in a letter

Tags in a letter
tag	mandatory	what's it

from	yes	from sender
address	no	sender's address
email	no	sender's email
phone	no	sender's phone
fax	no	sender's fax
to	yes	receiver
address	no	receiver's address
email	no	receiver's email
phone	no	receiver's phone
fax	no	receiver's fax
cc	no	carbon copy
subject	no	letters subject
sref	no	sender's reference
rref	no	receiver's reference
rdate	no	received date??
opening	yes	opening
paragraphs	yes	see Paragraphs
closing	yes	closing
encl	no	enclosure
ps	no	post scriptum

4.5 Telefax Tag


<!element telefax - -
        (from, %addr, to, address, email?,
         phone?, fax, cc?, subject?,
         opening, p+, closing, ps?)>

Overall the structure is same to the letter class. The only difference is that with the


<telefax>

tag the receiver's


<fax>

tag becomes mandatory.

Should be obvious why.

4.6 Slides Tag


<!element slides - - (slide*)>

The slides class is intended for overhead slides and transparencies. So the structure of a document classified by a


<slides>

tag is a very simple one. It contains single slide(s) startes by a


<slide>

tag. Nothing else. If not explicitly written the first slide is started implicitly.

Slide Tag


<!element slide - o (title?, p+)>


<slide>

tag is only allowed within the slides document class. A slide may contain:

A title (see section The Title Tag ) and one or more paragraph s (see section Paragraphs ). That's all.

4.7 Note Tag


<!element notes - - (title?, p+)>

Intended as a class for personal notes the structure is even more simplified than the slides document class (see The Slide Tag ). After classifying a document with the


<notes>

tag only a title (see section The Title Tag ) and one or more paragraph s (see section Paragraphs ) are allowed.

4.8 Manual Page Tag


<!element manpage - - (sect1*)
        -(sect2 | f | %mathpar | figure | tabular |
          table | %xref | %thrm )>

This document class is intended for writing manual pages , fitting the need of the

man

programm. In a document classified by a


<manpage>

tag the topleve section tag is the


sect1

tag (see section Sectioning ), for easy pasting manual pages into an article or book document class. The exception here to the nortmal sectioning is, that there is only one subsection level allowed (


sect2

5. Inlines


<!entity % inline
        " (#pcdata | f| x| %emph; |sq| %xref | %index | file )* ">

Inlines may occure anywhere within the text, and doesn't have any influence to the textflow or logical structure of the document.

#pcdata

Parsed character data is just normal written text within the flow wich may contain other inlines.

f

Inline mathematical formulas according to the maths.dtd . See The Formula Tag .

x

The external tag wich is bypassing the parser. Tagged data walks directly into the mapped file. See chapter The External Tag for detailed information.

%emph;

Emphasizes of the text. See chapter Emphasizes .

sq

Shortquotes within the textflow. See chapter The Short Quote Tad .

%xref

XReferecnces within the text or external references. See chapter Labels and References .

%index

Again I can't explain this one. If you can, please mail.

file

Again I can't explain this one (I only could guess about picture files in eps). If you can, please mail.

6. Sectioning


<!element chapt - o (%sect, sect*) +(footnote)>

<!element sect  - o (%sect, sect1*) +(footnote)>

<!element sect1 - o (%sect, sect2*)>

<!element sect2 - o (%sect, sect3*)>

<!element sect3 - o (%sect, sect4*)>

<!element sect4 - o (%sect)>

The sectioning

Also the chapt tag is a sectioning tag.

is done by the according elements, forming the section tree. They are bringing the various paragraphs within our document to follow a nice tree. The top level tag and the allowed depth is varying with the document class (see section The Document Class ).

The normal hierarchy is


chapt
    sect
        sect1
            sect2
                sect3
                    sect4

Just take a book, look the table of conetents and you will see.

Each of the tags out of the sectionings has nearly the same syntax. All of them owe a heading . The heading tag is placed implicitly if you don't note it down. Also the each of the sectioning tags may contain a header tag, changing the current document header (see section The Header Tag ).

Within the you may place subordinate sections and paragraphs (see Paragraphs ).

Some of the sectioning tags may only appear in special document classes ( Document Classes ).

Hint:: It's wise to place a label tag after the text of the section tag, even if you don't want to refer to the section Labels and references . Later when your document grows you might want to.

7. Paragraphs


<!entity % sectpar
        " %par; | figure | tabular | table | %mathpar; |
          %thrm; | %litprog; ">


<!entity % par       
        "  %list; | comment | lq | quote | tscreen ">


<!entity % litprog " code | verb ">

Each of the here described tags form a paragraph.

For obvious reason a paragraph is normally

The behaviour of the exceptions figure and tabular are explained there.

starting and ending with a new line.

How else you would notice it's a paragraph ?

There are some tags, wich always form a paragraph, and one way to form a paragraph implicitly. There are various types of paragraphs, because not every type of paragraph is allowed to appear in every document class in every place.

The different types of paragraphs are explained in the next sections. For more details about %litprog; see Literate Programming .

7.1 Normal Paragraph

Normal paragraphs can be formed in two ways:

Paragraph tag

The <p> tag is starting a new paragraph . This tag is mandatory if you want to finish a section header without explicitly closing the sect tag. In this case <p> tag then closes the <sect> tag automatically.

Empty Newline

A empty line between two paragraph is implicitly starting a new paragraph . Take care within descriptive lists. There a empty <tag> tag will not be paragraphed by an empty line.

7.2 List-like Paragraphs


<!entity % list
        " list | itemize | enum | descrip ">

This four tags indicate the starting of a list-like paragraph. Within each of the lists the single items are separated by an item tag .


<!element item o o ((%inline; | %sectpar;)*, p*)>

As you can see, a item may again contain paragraphs (and therefore also may contain other lists - even of a different type).

List Tag


<!element list - - (item+)>

The list tag will be mapped to a nacked list without bullets, numers or anything else.

To see it, I place a small example:


<list>

<item>
A point
<item>
Another one
<item>
Last
</list>

Will look (depending on the mapping) like:

A point

Another one

Last

Itemize Tag


<!element itemize - - (item+)>

The itemize tag will be mapped to a list with bullets, wich is usually place for lists where the order of the items is not important.

A small example:


<itemize>

<item>
A point
<item>
Another one
<item>
Last
</itemize>

Will look (depending on the mapping) like:

A point
Another one
Last

Enum Tag


<!element enum - - (item+)>

The enum tag will be mapped to a list with numbers.

A small example:


<enum>

<item>
A point
<item>
Another one
<item>
Last
</enum>

Will look (depending on the mapping) like:

A point
Another one
Last

Descrip Tag


<!element descrip - - (tag?, p+)+>

The descrip tag will be mapped to a descriptive list. The concept here is a little bit different than with the other types of lists mentioned above.

Here you place a tag (this time the tag's name is really litteraly tag ) wich is described later on.

A small example:


<descrip>

<tag/sgml/structured general markup language.
<tag/html - hypertext markup language/
A sgml implementation.
It contains some concepts about linking information together in a very
convenient way.
This made it to be so successful and to become the standard for documents
published by the internet.
<tag/internet/A worldwide connected internet (internet here as a
technical term)
</descrip>

Will look (depending on the mapping) like:

sgml: structured general markup language.
html - hypertext markup language: A sgml implementation. It contains some concepts about linking information together in a very covenient way. This made it to be so successfull and to become the standard for documents published by the internet.
internet: A worldwide connected internet (internet here as a technical term)

7.3 Figures and Tables

The <figure> and the <table> tags form very special paragraphs. Not always they stay within the normal textflow. Both of the tags can hold a loc ( loction ) attribute wich is telling how to handle the flow of this special paragraph.

The value of the loc attribute is a string of up to four letters, where each letter declares a location at which the figure or table may appear, as described in table Table Locations .

Table Locations
h	here	At the same location as in the SGML file
t	top	At the top of a page
b	bottom	At the bottom of a page
p	page	On a separate page only with figures and tables

The default value of the loc attribute is top .

Table Tag


<!element table   - - (tabular, caption?)>

As you can see a table consists of the <table> tag itself, including a <tabular> tag and a optional <caption> tag.

The <tabular> tag may also be placed without a <table> tag so it is described in detail in it's own section (see Tabular Tag ).

The caption is used also to place the entry for the list of tables if you stated one (see The List Of Tables Tag ).

A short example will show how it's working together.


<table loc="ht">

<tabular ca="lcr">

Look|this|table@
Isn't|it|nice@
1.234|mixed|columns
</tabular>

<caption>
A sample table
</table>

A sample table
Look	this	table
Isn't	it	nice
1.234	mixed	columns

The caption "A sample table" would be the name in the list of tables .

Figure Tag


<!element figure - - ((eps | ph ), img*, caption?)>

The usage of the


<figure>

tag is equivalent to the


<table>

tag. Instead of the


<tabular>

tag you place either a


<eps>

or a


<ph>

tag.

Encapsulated Postscript™ Tag


<!attlist eps
        file cdata #required
        height cdata "5cm"
        angle cdata "0">

The


<eps>

tag is intended for including a external file in encapsulated postscript™ format into the document.

The attributes of the <eps> tag are:

file

The file attribute needs the file name of a encapsulated postscript™ file ending with a .ps suffix. The mandatory .ps suffix must not be written.

height

The height of the space the file is zoomed to. If you don't specify it defaults to 5cm. Take care that there's no spcae between the number and the length unit (i , cm ).

angle

The angle is given in normal degrees (0-360) and as the number is increasing the file is rotated counter clockwise.

A example:


<figure loc="here">

<eps file="logo" height="4cm" angle="15">

<img src="logo.gif">

<caption>
A included encapsulated postscript&trade;
</figure>

The img tag is ignored by LaTeX-mapping and useful for html, 'cause most browsers don't know about eps.

A included encapsulated postscript™ file.

The caption here would go to the list of figures as decribed in section The List Of Figures Tag .

Placeholder Tag


<!attlist ph
        vspace cdata #required>

This tag doesn't place anything but keeps a clean space for good old manual picture pasting. The space kept free is destined by the


vspace

attribte. Caveat: The numerical argument for the


vspace

attribte needs a unit directly behind the number. Don't leave a space there (same as for the


height

attribute in Encapsulated Postscript™ Tag .


<figure loc="ht">

<ph vspace="5cm">

<caption>
A blank space.
</figure>

Results to:

A blank space for gluing a photo

At this point you might want to look for your scissors and the glue.

7.4 Tabular Tag


<!element tabular - - 
       (hline?, %tabrow, (rowsep, hline?, %tabrow)*, caption?)>

The


<tabular>

tag is interpreted as an own paragraph, if it is written standalone. Together with a


<table>

tag it gets part of the paragraph of the


<table>

tag (see Table tag ).

Within the tabular tag you have rows an collumns wich are separating the text. You have to have at least one collumn and one row.

Wouldn't be very usefull otherwise.

The <tabular> tag has a mandatory ca attribute for collumn allignement . The collumn allignement holds a single character for each collumn in their order from left to right. The chracters you may place per collumn described in table Collumns allignements

Column alignments
char	alignment

l	left
c	centered
r	right

In theory you should be able to place a | into the ca attribure for drawing a horizontal line for separating two collumns. The problem: It doesn't work. The parser accepts it nicely, only the LaTeX output will map | to {$|$} wich is of course the set for four collumns with invalid collumn allignement for all four collums. I'll try to figure out what to do about it.

The columns within the <tabular> tag are separated by a collumn separator , the <colsep> tag. The character | is translated to <colsep> so you can also place that one instead

Less typing, more fun.

What's valid for collumns is also valid for rows. You separate the by a row separator , the <rowsep> tag. The character @ is translated to <rowsep> .

Optional you can place a horizontal line with the <hline> tag. Take care with that one: The SGML tools will parse it nicely weather you place it in front of the row you want under the line, or behind the end of the row you want over it. But the only place to write it without causing the parser to shout "error" is to write it dircetly and without space or newline behind the row separator.


<tabular ca="lcr">

Look|this|table@<hline>

Isn't|it|nice@
1.234|mixed|columns@
</tabular>

Results in table Sample table for tabular tag

Sample table for tabular tag
Look	this	table

Isn't	it	nice
1.234	mixed	columns

Attention:: In LaTeX mapping everything works nice if you place a tabular tag without a table tag , only in the other mappings (e.g. html) it will be messed up.

7.5 Mathematical Paragraph


<!entity % mathpar " dm | eq ">

A mathematical paragraph consits either of a displayed formula , tagged by <dm>

No, sorry, not for Deutschmark! ;-)

or an equation , tagged by


<eq>

. They work very much the same.

Both of these tags contain a mathematical formula. See Mathematical Formulas for the tags valid here.

Note:: Because neither Netscape nor Microsoft has seen any need to add mathematical mappings to their browsers (like demanded and defined by w3c ), there is no nice way of mapping, or at least displaying the math stuff in html. So if you view the online version, feel free to wonder what nonsense this man is telling here. Might be you should take a glance at the postscript version.

Displayed Formula Tag

This tag displays a mathematical formula as a paragraph . The formula is mapped centered as a single line

No guarantee for that. You know: Mapping is a matter of taste.


<dm>
(a+b)<sup/2/=a<sup/2/+2ab+b<sup/2/</dm>

Is mapped to: (a+b)² =a² +2ab+b²

Equation Tag


<dm>
(a+b)<sup/2/=a<sup/2/+2ab+b<sup/2/</dm>

Is mapped to: (a+b)² =a² +2ab+b²

7.6 Theorem Paragraph


<!entity % thrm 
        " def | prop | lemma | coroll | proof | theorem ">


<!element def - - (thtag?, p+)>

<!element prop - - (thtag?, p+)>

<!element lemma - - (thtag?, p+)>

<!element coroll - - (thtag?, p+)>

<!element proof - - (p+)>

<!element theorem - - (thtag?, p+)>

As you can see the different types of theorem paragraphs are nearly identical. The only exception wich is a little bit different is the proof wich doesn't own a


thtag

. For all the others the


thtag

is giving the tag of the theorem paragraph.

Yust try to use that one, wich is fitting the meaning of what you are typing.


<thrm>

<thtag>
Alexander's thrm</thtag>

Let <f>
&lt;fi/G/</f>
 be a set of non-trivially achievable subgoals
and &mu; an order on <f>
&lt;fi/G/</f>
. &mu; is abstractly
indicative if and only if it is a linearization of
<f>
<lim>
<op>
&mu;</op>
<ll>
<fi/G/</ll>
<ul>
&ast;</ul>
</lim>
</f>
.
</theorem>

The thrm is replaced by the adequate tag.

Maybe somebody knowing about mathematics would be shocked about my abuse of the types, but I'm lazy so I simply copied the examples:

Definition (def ): Alexander's Definition