| Back to Table of Contents | Next: The document element tags |
Document processing with mom uses markup tags to identify document elements such as headings, paragraphs, blockquotes, and so on. The tags are, of course, macros, but with sensible, readable names that make them easy to grasp and easy to remember. (And don’t forget: if you don’t like the “official” name of a tag — too long, cumbersome to type in, not “intuitive” enough — you can change it with the ALIAS macro.)
In addition to the tags themselves, mom has an extensive array of macros that control how they look and behave.
Setting up a mom doc is a simple, four-part procedure. You begin by entering metadata about the document itself (title, subtitle, author, etc.). Next, you tell mom what kind of document you’re creating (eg chapter, letter, abstract, etc...) and what kind of output you want (typeset, typewritten, draft-style, etc) — essentially, templates. Thirdly, you make as many or as few changes to the templates as you wish; in other words, create a style sheet. Lastly, you invoke the START macro. Voilà! You’re ready to write.
As is to be expected, mom has defaults for everything. If you want to know a particular default, read about it in the description of the pertinent tag.
I fear the following may not be adequately covered in the documentation, so just in case:
Mom takes evenly-aligned bottom margins in running text very seriously. Only under a very few (exceptional) circumstances will she allow a bottom margin to “hang” (ie to fall short).
In order to ensure even bottom margins, mom uses the “base” document leading in effect at the start of running text on each page (ie the leading used in paragraphs) to calculate the spacing of every document element. Prior to invoking START, this is set with the typesetting macro LS, afterwards with the document control macro DOC_LEAD.
Because mom relies so heavily on the base document leading, any change to the leading or spacing on a page will almost certainly have undesirable consequences on that page’s bottom margin unless the change is fully compensated for elsewhere on the page.
In other words, if you add a few points of space somewhere on a page, you must subtract the same number of points somewhere else on that same page, and vice versa.
If it’s a question of adding or subtracting full line spaces between or within document elements, you can do so by using the “v” unit of measure with whatever spacing macro you choose — ALD, RLD, SPACE — and mom won’t object. “v” means “the current leading”, so she isn’t confused by it. And since “v” accepts decimal fractions, you can add/subtract half linespaces and quarter linespaces with “v” as well, provided you compensate for the fractional linespace somewhere else on the page.
If all this seems like too much work, mom provides a special macro to get you out of trouble if you’ve played around with leading and/or spacing. The macro is called SHIM (like those little pieces of wood carpenters use to get their work even, level and snug), and it’s described below.
SHIM doesn’t take any argument. Use it whenever you’ve played around with the leading or spacing on a page and you need to get mom’s document leading back on track.
For example, say you want to insert an image into a document with PDF_IMAGE or PSPIC.
Images and graphics aren’t usually conveniently sized in multiples of the document leading, which means that when you insert the picture, you disrupt mom’s ordered placement of baselines on the page. This will certainly result in a bottom margin that doesn’t match the bottom margins of your document’s other pages.
The solution is to insert SHIM after the image, like this:
<text>
.PDF_IMAGE <args> or .PSPIC <args>
.SHIM
<text>
SHIM instructs mom to insert as much or a little space after the picture as is needed to ensure that the baseline of the next output line falls where mom would have put it had you not disrupted the normal flow of output lines with the picture.
And say, on previewing the above example, you find the image
doesn’t centre nicely between the lines of text, you can
adjust the image position either by passing a baseline adjustment
to PDF_IMAGE, or by using
ALD
or
RLD
before PSPIC. To demonstrate,
<text>
.PDF_IMAGE <args> -3p
.SHIM
<text>
and
<text>
.RLD 3p
.PSPIC <args>
.SHIM
<text>
both raise an image slightly within the space allotted for it while
ensuring that text underneath falls exactly where should.
By default, mom automatically applies shimming
In documents where paragraphs are not spaced, automatic shimming is almost always desirable. In documents where paragraphs are spaced by an amount less than the document leading, or which have numerous graphics, headings, and quotes, you may want to disable shimming, either globally or on a tag-by-tag basis.
To disable automatic shimming, invoke the macro, .NO_SHIM, either in the style sheet section of your document (ie after PRINTSTYLE and before START), or just before HEADING, QUOTE, BLOCKQUOTE, PDF_IMAGE or FLOAT.
Note: .NO_SHIM also disables the SHIM macro itself.
To re-enable automatic shimming and the SHIM macro itself, use .NO_SHIM OFF (or QUIT, END, X, etc).
There are four parts to setting up a mom doc (three, actually,
with one optional). Before we proceed, though, be reassured that
something as simple as
.TITLE "By the Shores of Lake Attica"
.AUTHOR "Rosemary Winspeare"
.PRINTSTYLE TYPESET
.START
produces a beautifully typeset 8.5x11 document, with a
docheader
at the top of page 1,
page headers
with the title and author on subsequent pages, and page numbers at
the bottom of each page. In the course of the document, headings,
citations, quotes, epigraphs, and so on, all come out looking neat,
trim, and professional.
For the purposes of this tutorial, we’re going to set up a short story—My Pulitzer Winner—by Joe Blow. Thankfully, we don’t have to look at story itself, just the setup. Joe wants the document
Joe Blow has no taste in typography. His draft won’t look pretty, but this is, after all, a tutorial; we’re after examples, not beauty.
The first step in setting up any document is giving mom some reference information (metadata). The reference macros are:
You can use as many or as few as you wish, although at a minimum,
you’ll probably fill in TITLE (unless the document’s a
letter) and AUTHOR. Order doesn’t matter. You can separate
the
arguments
from the macros by any number of spaces. The following are what
you’d need to start Joe Blow’s story.
.TITLE "My Pulitzer Winner"
.AUTHOR "Joe Blow"
.DRAFT 7
.REVISION 39
Once you’ve given mom the reference information she needs, you tell her how you want your document formatted. What kind of document is it? Should it be typeset or typewritten? Is this a final copy (for the world to see) or just a draft? Mom calls the macros that answer these questions “the docstyle macros.”, and they're essentially templates.
Mom has defaults for DOCTYPE and COPYSTYLE; if they’re what you want, you don’t need to include them. However, PRINTSTYLE has no default and must be present in every formatted document. If you omit it, mom won’t process the document AND she’ll complain (both to stderr and as a single printed sheet with a warning). Moms—they can be so annoying sometimes. <sigh>
Adding to what we already have, the next bit of setup for Joe
Blow’s story looks like this:
.TITLE "My Pulitzer Winner"
.AUTHOR "Joe Blow"
.DRAFT 7
.REVISION 39
\#
.DOCTYPE DEFAULT \"Superfluous; mom uses DOCTYPE DEFAULT by default
.PRINTSTYLE TYPESET
.COPYSTYLE DRAFT
Notice the use of the
comment line
( \# ), a handy way to keep groups of macros visually
separated for easy reading in a text editor.
This step—completely optional—is where you, the user, take charge. Mom has reasonable defaults for every document element and tag, but who’s ever satisfied with defaults? Use any of the typesetting macros here to change mom’s document defaults (paper size, margins, family, point size, line space, rag, etc), or use any of the document processing control macros. This is the style-sheet section of a document, and must come after the PRINTSTYLE directive. Failure to observe this condition will result in PRINTSTYLE overriding your changes.
Joe Blow wants his story printed in Helvetica, 12 on 14, rag right,
with
page footers
instead of
page headers
and a single asterisk for the
linebreak
character. None of these requirements conforms to mom’s
defaults for the chosen PRINTSTYLE (TYPESET), so we change them
here. The setup for Joe Blow’s story now looks like this:
.TITLE "My Pulitzer Winner"
.AUTHOR "Joe Blow"
.DRAFT 7
.REVISION 39
\#
.DOCTYPE DEFAULT
.PRINTSTYLE TYPESET
.COPYSTYLE DRAFT
\#
.FAMILY H
.PT_SIZE 12
.LS 14
.QUAD LEFT \"ie rag right
.FOOTERS
.LINEBREAK_CHAR *
The final step in setting up a document is telling mom to start document processing. It’s a no-brainer, just the single macro, START. Other than PRINTSTYLE, it’s the only macro required for document processing.
Here’s the complete setup for My Pulitzer Winner:
.TITLE "My Pulitzer Winner"
.AUTHOR "Joe Blow"
.DRAFT 7
.REVISION 39
\#
.DOCTYPE DEFAULT
.PRINTSTYLE TYPESET
.COPYSTYLE DRAFT
\#
.FAMILY H
.PT_SIZE 12
.LS 14
.QUAD LEFT \"ie rag right
.FOOTERS
.LINEBREAK_CHAR *
\#
.START
As pointed out earlier, Joe Blow is no typographer. Given that all he
needs is a printed draft of his work, a simpler setup would have been:
.TITLE "My Pulitzer Winner"
.AUTHOR "Joe Blow"
.DRAFT 7
.REVISION 39
\#
.PRINTSTYLE TYPEWRITE
.COPYSTYLE DRAFT
\#
.START
.PRINTSTYLE TYPEWRITE, above, means that Joe’s
work will come out “typewritten, double-spaced”,
making the blue-pencilling he (or someone else) is sure to do much
easier (which is why many publishers and agents still insist on
typewritten, double-spaced copy).
When J. Blow stops re-writing and decides to print off a final,
typeset copy of his work for the world to see, he need only make two
changes to the (simplified) setup:
.TITLE "My Pulitzer Winner"
.AUTHOR "Joe Blow"
.DRAFT 7
.REVISION 39
\#
.PRINTSTYLE TYPESET \"first change
.COPYSTYLE FINAL \"second change
\#
.START
In the above, .DRAFT 7, .REVISION 39, and
.COPYSTYLE FINAL are actually superfluous. The draft
and revision numbers aren’t used when COPYSTYLE is FINAL,
and COPYSTYLE FINAL is mom’s default unless you tell
her otherwise.
But... to judge from the number of drafts already, J. Blow may very well decide his “final” version still isn’t up to snuff. Hence, he might as well leave in the superfluous macros. That way, when draft 7, rev. 62 becomes draft 8, rev. 1, he’ll be ready to tackle his Pulitzer winner again.
The reference macros give mom the metadata she needs to generate docheaders, page headers, and covers. They must go at the top of any file that uses mom’s document processing macros.
• Arguments must be enclosed in double-quotes
The title string can be caps or caps/lower-case; it’s up to you. In PRINTSTYLE TYPESET, the title will appear in the docheader exactly as you typed it. However, mom converts the title to all caps in page headers unless you turn that feature off (see HEADER_<POSITION>_CAPS). In PRINTSTYLE TYPEWRITE, the title always gets converted to caps.
TITLE accepts multiple arguments, each surrounded by double-quotes. Each argument is printed on a separate line, permitting you to create multi-line titles in your docheaders.
Note: If your DOCTYPE is CHAPTER, TITLE should be the title of the opus, not “CHAPTER whatever”.
• Arguments must be enclosed in double-quotes
Note: This macro should be used only if your DOCTYPE is DEFAULT (which is mom’s default). If your DOCTYPE is CHAPTER, use TITLE to set the overall document title for cover pages, document cover pages, and page headers or footers.
When you’re creating a single document, say, an essay or a short story, you have no need of this macro. TITLE takes care of all your title needs.
However if you’re collating a bunch of documents together, say, to print out a report containing many articles with different titles, or a book of short stories with different authors, you need DOCTITLE.
DOCTITLE tells mom the title of the complete document (as opposed to the title of each article or entitled section), and appears
Moreover, DOCTITLE does not appear in the PDF outline , as its presence in window title would make it redundant.
The doctitle string can be caps or caps/lower-case; it’s up to you. In PRINTSTYLE TYPESET, by default, the doctitle in page headers is all in caps, unless you turn that feature off (see HEADER_<POSITION>_CAPS). In PRINTSTYLE TYPEWRITE, the doctitle always gets converted to caps.
DOCTITLE accepts multiple arguments, each surrounded by double-quotes. Each argument is printed on a separate line, permitting you to create multi-line document titles for use on Covers and/or Doc covers.
Note: If your DOCTYPE is CHAPTER, you don’t need DOCTITLE. TITLE takes care of everything.
• String arguments must be enclosed in double-quotes
The subtitle string can be caps or caps/lower-case. I recommend caps/lower case.
SUBTITLE accepts multiple arguments, each surrounded by double-quotes. Each argument is printed on a separate line, permitting you to create multi-line subtitles.
If the optional argument, COVER or DOC_COVER,
is given to SUBTITLE, the remaining string
arguments represent the subtitle that will appear on cover or
document cover pages (see the
Introduction to cover pages
for a description of the difference between “document
covers” and “covers”). Thus, it is possible to have
differing subtitles appear on the document cover, the cover
(“title”) page, and in the document header. An extreme
example would be:
.SUBTITLE "The Docheader Subtitle"
.SUBTITLE DOC_COVER "The Document Cover Subtitle"
.SUBTITLE COVER "The Cover Subtitle"
The first invocation of .SUBTITLE establishes the
subtitle that appears in the docheader at the top of the first page
of a document. The second invocation establishes the subtitle that
appears on the document cover; the third establishes the subtitle
that appears on the cover (“title”) page.
If you don’t require differing subtitles for doc cover and cover pages, .SUBTITLE, without the optional first argument, is sufficient, provided you give the word, SUBTITLE, as an argument to the macro DOC_COVER or COVER
Alias: EDITOR
• String arguments must be enclosed in double-quotes
Each author string can hold as many names as you like, eg
.AUTHOR "Joe Blow"
or
.AUTHOR "Joe Blow, Jane Doe" "John Hancock"
Mom prints each string that’s enclosed in double-quotes on a
separate line in the
docheader,
however only the first string appears in
page headers.
If you want mom to put something else in the author part of page
headers (say, just the last names of a document’s two
authors), redefine the appropriate part of the header (see
header/footer control).
The strings can be caps or caps/lower-case. I recommend caps/lower case.
If the optional argument, COVER or DOC_COVER,
is given to AUTHOR, the remaining string arguments represent the
author(s) that will appear on cover or document cover pages (see the
Introduction to cover pages
for a description of the difference between “document
covers” and “covers”). Thus, it is possible
to have differing authors on the document cover, the cover
(“title”) page, in the document first-page header and
subsequent page headers/footers. An example might be:
.AUTHOR "Joe Blow"
.EDITOR DOC_COVER "John Smith" "and" "Jane Doe" \" EDITOR is an alias for AUTHOR
.AUTHOR COVER "Joe Blow" "(assisted by Jane Doe)"
The first invocation of .AUTHOR establishes the author
that appears in the docheader at the top of the first page of
a document and in subsequent page headers/footers. The second
invocation establishes the authors (editors, in this instance) that
appear on the document cover; the third establishes the author(s)
that appear(s) on the cover (“title”) page.
If you don’t require differing authors for doc cover and cover pages, .AUTHOR, without the optional first argument, is sufficient, provided you give the word, AUTHOR as an argument to the macro DOC_COVER or COVER
The chapter number can be in any form you like—a digit, a roman numeral, a word. If you choose DOCTYPE CHAPTER, mom prints whatever argument you pass CHAPTER beside the word, “Chapter”, as a single line docheader. She also puts the same thing in the middle of page headers.
Please note that if your argument to CHAPTER runs to more than one word, you must enclose the argument in double-quotes.
If you’re not using DOCTYPE CHAPTER, the macro can be used to identify any document as a chapter for the purpose of prepending a chapter number to numbered head elements, provided you pass it a numeric argument. See PREFIX_CHAPTER_NUMBER.
If you’re not writing in English, you can ask mom to use the
word for “chapter” in your own language by telling her
what it is with the CHAPTER_STRING macro, like this:
.CHAPTER_STRING "Chapître"
You can also use CHAPTER_STRING if you want “CHAPTER” (all caps) instead of “Chapter” (caps/lowercase) in the doc- and page-headers.
• Arguments must be enclosed in double-quotes
If, either in addition to or instead of “Chapter
<n>” appearing at the top of chapters, you want your
chapter to have a title, use CHAPTER_TITLE, with your title enclosed
in double-quotes, like this:
.CHAPTER_TITLE "The DMCA Nazis"
CHAPTER_TITLE accepts multiple arguments, each surrounded by double-quotes. Each argument is printed on a separate line, permitting you to create multi-line chapter titles in your docheaders.
If you’ve used
CHAPTER
to give the chapter a number, both “Chapter <n>”
and the chapter title will appear at the top of the chapter, like
this:
Chapter 1
The DMCA Nazis
In such a case, by default, only the chapter’s title will appear in
the
page headers,
not “Chapter <n>”.
If you omit CHAPTER when setting up your reference macros, only the title will appear, both at the top of page one and in subsequent page headers.
The style of the chapter title can be altered by control macros, eg CHAPTER_TITLE_FAMILY, CHAPTER_TITLE_FONT, etc. The default family, font and point size are Times Roman, Bold Italic, 4 points larger than running text.
DRAFT only gets used with
COPYSTYLE DRAFT.
If the COPYSTYLE is FINAL (the default), mom ignores DRAFT. DRAFT
accepts both alphabetic and numeric arguments, hence it’s
possible to do either
.DRAFT 2
or
.DRAFT Two
Mom prints the argument to .DRAFT (ie the draft number) beside the word “Draft” in the middle part of page headers.
A small word of caution: If your argument to .DRAFT is more than one word long, you must enclose the argument in double-quotes.
You may, if you wish, invoke .DRAFT without an argument, in which case, no draft number will be printed beside “Draft” in headers or footers.
If you’re not writing in English, you can ask mom
to use the word for “draft” in your own language by
telling her what it is with the DRAFT_STRING macro,
like this:
.DRAFT_STRING "Jet"
Equally, DRAFT_STRING can be used to roll your own solution to
something other than the word “Draft.” For example, you
might want “Trial run alpha-three” to appear in the
headers of a draft version. You’d accomplish this by doing
.DRAFT alpha-three
.DRAFT_STRING "Trial run"
If you wanted only “Trial run” to appear, entering .DRAFT without an argument as well as .DRAFT_STRING "Trial run" is how you’d do it.
Note: If you define both a blank .DRAFT and a blank .DRAFT_STRING, mom skips the draft field in headers entirely. If this is what you want, this is also the only way to do it. Simply omitting invocations of .DRAFT and .DRAFT_STRING will result in mom using her default, which is to print “Draft <number>”.
REVISION only gets used with
COPYSTYLE DRAFT.
If the COPYSTYLE is FINAL (the default), mom ignores the REVISION
macro. REVISION accepts both alphabetic and numeric arguments, hence
it’s possible to do either
.REVISION 2
or
.REVISION Two
Mom prints the revision number beside the shortform “Rev.” in the middle part of page headers.
A small word of caution: If your argument to .REVISION is more than one word long, you must enclose the argument in double-quotes.
You may, if you wish, invoke .REVISION without an argument, in which case, no revision number will be printed beside "Rev." in headers or footers.
If you’re not writing in English, you can ask mom
to use the word for “revision,” or a shortform
thereof, in your own language by telling her what it is with the
REVISION_STRING macro, like this:
.REVISION_STRING "Rév."
Additionally, you may sometimes want to make use of mom’s
COPYSTYLE DRAFT
but not actually require any draft information. For example,
you might like mom to indicate only the revision number of
your document. The way to do that is to define an empty
.DRAFT and .DRAFT_STRING in addition to
.REVISION, like this:
.DRAFT
.DRAFT_STRING
.REVISION 2
Equally, if you want to roll your own solution to what revision
information appears in headers, you could do something like this:
.DRAFT
.DRAFT_STRING
.REVISION "two-twenty-two"
.REVISION_STRING "Revision"
The above, naturally, has no draft information. If you want to roll your own .DRAFT and/or .DRAFT_STRING as well, simply supply arguments to either or both.
• Argument must be enclosed in double-quotes
The argument passed to COPYRIGHT is only used on cover or doc cover pages, and then only if the argument COPYRIGHT is passed to COVER or DOC_COVER. Do not include the copyright symbol in the argument passed to COPYRIGHT; mom puts it in for you.
If the optional argument, COVER or DOC_COVER,
is given to COPYRIGHT, the string argument represents the copyright
information that will appear on cover or document cover pages (see
the
Introduction to cover pages
for a description of the difference between “document
covers” and “covers”). Thus, it is possible to
have differing copyright information on the document cover and on
the cover (“title”) page. An example might be:
.COPYRIGHT DOC_COVER "2010 John Smith and Jane Doe"
.COPYRIGHT COVER "2008 Joe Blow"
The first invocation of .COPYRIGHT establishes the
copyright information that appears on the document cover; the second
establishes the copyright information that appears on the cover
(“title”) page.
If you don’t require differing copyright information for doc cover and cover pages, .COPYRIGHT, without the optional first argument, is sufficient, provided you give the word, COPYRIGHT, as an argument to the macro DOC_COVER or COVER
• String arguments must be enclosed in double-quotes
The argument(s) passed to MISC are only used on cover or doc cover pages, and then only if the argument MISC is passed to COVER or DOC_COVER. MISC can contain any information you like. Each argument appears on a separate line at the bottom of the cover or doc cover page.
For example, if you’re submitting an essay where the prof has
requested that you include the course number, his name and the date,
you could do
.MISC "Music History 101" "Professor Hasbeen" "Dec. 24, 2010"
and the information would appear on the essay’s cover page.
If the optional argument, COVER or DOC_COVER,
is given to MISC, the string arguments represent the miscellaneous
information that will appear on cover or document cover pages (see
the
Introduction to cover pages
for a description of the difference between “document
covers” and “covers”). Thus, it is possible to
have differing miscellaneous information on the document cover and
on the cover (“title”) page. An example might be:
.MISC DOC_COVER "Music History 101" "Professor Hasbeen"
.MISC COVER "Spring Term Paper"
The first invocation of .MISC establishes the miscellaneous information that appears on the document cover; the second establishes the miscellaneous information that appears on the cover (“title”) page.
If you don’t require differing miscellaneous information for doc cover and cover pages, .MISC, without the optional first argument, is sufficient, provided you give the word “MISC” as an argument to the macro DOC_COVER or COVER
• Arguments must be enclosed in double-quotes
• Arguments must be enclosed in double-quotes
The arguments passed to COVERTITLE or DOC_COVERTITLE are only used on cover or doc cover pages, and then only if the argument COVERTITLE or DOC_COVERTITLE is passed to COVER or DOC_COVER.
The only time you require a COVERTITLE or DOC_COVERTITLE is when none of the required first arguments to COVER or DOC_COVER fits your needs for the title you want to appear on cover (or doc cover) pages.
COVERTITLE and DOC_COVERTITLE accept multiple arguments, each surrounded by double-quotes. Each argument is printed on a separate line, permitting you to create multi-line titles on your cover and/or doc cover pages.
• Arguments must be enclosed in double-quotes
Except for DOCTITLE, mom does not, by default, provide PDF viewers with a document title. You may set one, if you like, with PDF_TITLE.
The docstyle macros tell mom what type of document you’re writing, whether you want the output typeset or “typewritten, double-spaced”, and whether you want a draft copy (with draft and revision information in the headers) or a final copy.
The arguments DEFAULT, CHAPTER and NAMED tell mom what to put in the docheader and page headers. LETTER tells her that you want to write a letter.
Mom’s default DOCTYPE is DEFAULT. If that’s what you want, you don’t have to give a DOCTYPE command.
DEFAULT prints a docheader containing the title, subtitle and author information given to the reference macros, and page headers with the author and title. (See Default specs for headers for how mom outputs each part of the page header.)
CHAPTER prints “Chapter <n>” in place of a docheader (<n> is what you gave to the reference macro, CHAPTER). If you give the chapter a title with CHAPTER TITLE, mom prints “Chapter <n>” and the title underneath. If you omit the CHAPTER reference macro but supply a CHAPTER_TITLE, mom prints only the chapter title.
The page headers in DOCTYPE CHAPTER contain the author, the title of the book (which you gave with TITLE), and “Chapter <n>” (or the chapter title). See Default Specs for Headers for mom’s default type parameters for each part of the page header.
NAMED takes an additional argument: a name for this particular kind of document (eg outline, synopsis, abstract, memorandum), enclosed in double-quotes. NAMED is identical to DEFAULT except that mom prints the argument to NAMED beneath the docheader, as well as in page headers. (See Default specs for headers for how mom outputs each part of the page header.)
Additionally, if you wish the name of this particular kind of
document to be coloured, you can pass DOCTYPE NAMED a
third (optional) argument: the name of a colour pre-defined (or
“initialized”) with
NEWCOLOR
or
XCOLOR.
For example, if you have a doctype named “Warning”,
and you’d like “Warning” to be in red, assuming you’ve
pre-defined (or “initialized”) the color, red, this is
what the DOCTYPE entry would look like:
.DOCTYPE NAMED "Warning" red
By default, the string passed to DOCTYPE NAMED is underlined in the docheader, and on document-cover pages and cover (“title”) pages. (See the Introduction to covers for the difference between “doc cover” and “cover” pages.)
You can use the macro DOCTYPE_UNDERLINE to set the weight of the underline and its distance from where the doctype-name appears in the docheader (doc covers and covers handle underlining of the doctype-name differently; see COVER_UNDERLINE), or simply toggle doctype underlining on or off. Mom’s default is to underline the doctype-name.
The order of arguments is weight, optionally followed by gap, where “gap” is the distance from the baseline of the doctype-name to the underline.
The weight argument is given in points, or fractions thereof, and must not have the unit of measure, p, appended. Like RULE_WEIGHT, weights must be greater than 0 and less than 100. Mom’s default for DOCTYPE NAMED underlining is 1/2 point.
The gap argument can be given using any unit of measure, and must have the unit of measure appended to the argument. The distance of the gap is measured from the baseline of the DOCTYPE NAMED name to the upper edge of the underline. Mom’s default gap for named-doctype underlining is 2 points.
As an example, suppose you want the doctype-name underlined in the
docheader with a 2-point rule separated from the doctype-name by 3
points. The way to accomplish it is:
.DOCTYPE_UNDERLINE 2 3p
If you wanted the same thing, but were content with mom’s
default gap of 2 points,
.DOCTYPE_UNDERLINE 2
would do the trick.
If you merely want to toggle the underlining of the doctype-name in docheaders on or off, invoke .DOCTYPE_UNDERLINE by itself to turn the underlining on, or .DOCTYPE_UNDERLINE OFF (or NO, X, etc.)
Please note that if you supply a weight to DOCTYPE_UNDERLINE, and optionally a gap, you also turn the underlining of the doctype-name in docheaders on; if this is not what you want, you must turn the underlining off manually afterwards.
LETTER tells mom you’re writing a letter. See the section Writing Letters for instructions on using mom to format letters.
• Required for document processing
Must come before any changes to default document style
PRINTSTYLE tells mom whether to typeset a document, or to print it out “typewritten, doubled-spaced”.
Important: This macro may not be omitted. In order for document processing to take place, mom requires a PRINTSTYLE. If you don’t give one, mom will warn you on stderr and print a single page with a nasty message.
Just as important: PRINTSTYLE must precede any and all page and style parameters associated with a document. This applies primarily to, but is by no means restricted to, PRINTSTYLE TYPESET. PRINTSTYLE sets up complete templates that include default papersize, margins, family, fonts, point sizes, and so on. Therefore, changes to any aspect of document style must come afterwards.
TYPESET, as the argument implies, typesets documents (by default in Times Roman; see TYPESET defaults). You have full access to all the typesetting macros as well as the style control macros of document processing.
As mentioned above, PRINTSTYLE TYPESET must come before
any changes to mom’s default typographic settings. For
example,
.PAPER A4
.LS 14
.PRINTSTYLE TYPESET
will not changes mom’s default paper size to A4,
nor her default document leading 14 points, whereas
.PRINTSTYLE TYPESET
.PAPER A4
.LS 14
will.
With TYPEWRITE, mom does her best to reproduce the look and feel of typewritten, double-spaced copy (see TYPEWRITE defaults). Control macros and typesetting macros that alter family, font, point size, and leading are (mostly) ignored. An important exception is HEADER_SIZE (and, by extension, FOOTER_SIZE), which allows you to reduce the point size of headers/footers should they become too crowded. Most of mom’s inlines affecting the appearance of type are also ignored (\*S[<size>] is an exception; there may be a few others).
In short, TYPEWRITE never produces effects other than those available on a typewriter. Don’t be fooled by how brainless this sounds; mom is remarkably sophisticated when it comes to conveying the typographic sense of a document within the confines of TYPEWRITE.
The primary uses of TYPEWRITE are: outputting hard copy drafts of your work (for editing) and producing documents for submission to publishers and agents who (wisely) insist on typewritten, double-spaced copy. To get a nicely typeset version of work that’s in the submission phase of its life (say, to show fellow writers for critiquing), simply change TYPEWRITE to TYPESET and print out a copy.
If, for some reason, you would prefer the output of TYPEWRITE single-spaced, pass PRINTSTYLE TYPEWRITE the optional argument, SINGLESPACE.
If you’d prefer a monospace family for PRINTSTYLE TYPEWRITE other than than mom's default, Courier, you can change it with .TYPEWRITER_FAMILY <family> (or .TYPEWRITER_FAM). Since groff ships with only the Courier family, you will have to install any other monospace family yourself. See Adding fonts to groff.
If you’d like a smaller or larger point size for for PRINTSTYLE TYPEWRITE (mom’s default is 12-point), you can change it with .TYPEWRITER_SIZE <size>. There’s no need to add a unit of measure to the <size> argument; points is assumed. Be aware, however, that regardless of point size, mom’s leading/linespacing for TYPEWRITE is fixed at 24-point for double-spaced, and 12-point for single-spaced.
In PRINTSTYLE TYPEWRITE, mom, by default, underlines anything that looks like italics. This includes the \*[SLANT] inline escape for pseudo-italics.
If you’d prefer that mom were less bloody-minded
about pretending to be a typewriter (ie you’d like italics and
pseudo-italics to come out as italics), use the control macros
.ITALIC_MEANS_ITALIC
and
.SLANT_MEANS_SLANT
Neither requires an argument.
Although it’s unlikely, should you wish to reverse the sense of these macros in the midst of a document, .UNDERLINE_ITALIC and .UNDERLINE_SLANT restore underlining of italics and pseudo-italics.
Additionally, by default, mom underlines
quotes
(but not
blockquotes)
in PRINTSTYLE TYPEWRITE. If you don’t like this
behaviour, turn it off with
.UNDERLINE_QUOTES OFF
To turn underlining of quotes back on, use UNDERLINE_QUOTES without an argument.
While most of the control macros have no effect on PRINTSTYLE TYPEWRITE, there is an important exception: HEADER_SIZE (and by extension, FOOTER_SIZE). This is particularly useful for reducing the point size of headers/footers should they become crowded (quite likely to happen if the title of your document is long and your COPYSTYLE is DRAFT).
Mom’s default COPYSTYLE is FINAL, so you don’t have to use this macro unless you want to.
COPYSTYLE DRAFT exhibits the following behaviour:
Important: If you define your own centre part for page headers with HEADER_CENTER, no draft and/or revision number will appear there. If you want draft and revision information in this circumstance, use DRAFT_WITH_PAGENUMBER.
COPYSTYLE FINAL differs from DRAFT in that:
Note: The centre part of page headers can get crowded, especially with DOCTYPE CHAPTER and DOCTYPE NAMED, when the COPYSTYLE is DRAFT. Three mechanisms are available to overcome this problem. One is to reduce the overall size of headers (with HEADER_SIZE). Another, which only works with PRINTSTYLE TYPESET, is to reduce the size of the header’s centre part only (with HEADER_CENTER_SIZE). And finally, you can elect to have the draft/revision information attached to page numbers instead of having it appear in the centre of page headers (see DRAFT_WITH_PAGENUMBER).
In order to use mom’s document element macros (tags), you have to tell her you want them. The macro to do this is START.
START collects the information you gave mom in the setup section at the top of your file (see Tutorial – Setting up a mom document), merges it with her defaults, sets up headers and page numbering, and prepares mom to process your document using the document element tags. No document processing takes place until you invoke .START.
• Required for document processing
START takes no arguments. It simply instructs mom to begin document processing. If you don’t want document processing (ie you only want the typesetting macros), don’t use START.
At a barest minimum before START, you must enter a PRINTSTYLE command.
In the third (optional) part of setting up a document (the stylesheet; see Tutorial – Setting up a mom document), you can use the typesetting macros to change mom’s document-wide defaults for margins, line length, family, base point size, leading, and justification style.
Two additional style concerns have to be addressed here (ie in macros before START): changes to the docheader, and whether you want you want the document’s nominal leading adjusted to fill pages fully to the bottom margin.
From time to time (or maybe frequently), you’ll want the overall look of a document to differ from mom’s defaults. Perhaps you’d like her to use a different family, or a different overall leading, or have different left and/or right page margins.
To accomplish such alterations, use the appropriate typesetting macros (listed below) after PRINTSTYLE and before START.
More than one user has, quite understandably, not fully grasped the significance of the preceding sentence. The part they’ve missed is after PRINTSTYLE.
Changes to any aspect of the default look and/or formatting of a mom
document must come after PRINTSTYLE. For example, it might seem
natural to set up page margins at the very top of a document with
.L_MARGIN 1i
.R_MARGIN 1.5i
However, when you invoke .PRINTSTYLE, those margins
will be overridden. The correct place to set margins—and
all other changes to the look of a document—is after
PRINTSTYLE.
Note: Don’t use the macros listed in Changing document-wide typesetting parameters after START prior to START; they are exclusively for use afterwards.
When used before START, the
typesetting macros,
below have the following meanings:
L_MARGIN Left margin of pages, including headers/footers
R_MARGIN Right margin of pages, including headers/footers
T_MARGIN The point at which running text (ie not
headers/footers or page numbers) starts on each
page
B_MARGIN* The point at which running text (ie not
(see note) headers/footers or page numbers) ends on each page
PAGE If you use PAGE, its final four arguments have the
same meaning as L_ R_ T_ and B_MARGIN (above).
LL The line length for everything on the page;
equivalent to setting the right margin with
R_MARGIN
FAMILY The family of all type in the document
PT_SIZE The point size of type in paragraphs; mom uses
this to calculate automatic point size changes
(eg for heads, footnotes, quotes, headers, etc)
LS/AUTOLEAD** The leading used in paragraphs; all leading and
spacing of running text is calculated from this
QUAD/JUSTIFY Affects paragraphs only
LEFT*** No effect
RIGHT*** No effect
CENTER*** No effect
------
*See FOOTER MARGIN AND BOTTOM MARGIN for an important warning
**See DOC_LEAD_ADJUST
***See Special note
Other macros that deal with type style, or refinements thereof (KERN, LIGATURES, HY, WS, SS, etc.), behave normally. It is not recommended that you set up tabs or indents prior to START.
If you want to change any of the basic parameters (above) after START and have them affect a document globally (as if you’d entered them before START), you must use the macros listed in Changing document-wide style parameters after START.
In a word, these three macros have no effect on document processing when invoked prior to START.
All mom’s document element tags (PP, HEAD, BLOCKQUOTE, FOOTNOTE, etc.) except QUOTE set a fill mode as soon as they’re invoked. If you wish to turn fill mode off for the duration of any tag (with LEFT, RIGHT or CENTER) you must do so immediately after invoking the tag. Furthermore, the change affects only the current invocation of the tag. Subsequent invocations of the same tag for which you want the same change require that you invoke .LEFT, .RIGHT or .CENTER immediately after every invocation of the tag.
If you routinely make the same changes to mom’s defaults in order to create similar documents in a similar style—in other words, you need a template— you can create style-sheet files and include, or "source", them into your mom documents with the macro, INCLUDE. The right place for such style sheets is after PRINTSTYLE and before START.
Say, for example, in a particular kind of document, you always
want main heads set in Helvetica Bold Italic, flush left,
with no underscore. You’d create a file, let’s call it
head-template, in which you’d place the pertinent HEAD
control macros.
.HEAD_FAMILY H
.HEAD_FONT BI
.HEAD_QUAD L
.HEAD_UNDERLINE OFF
Then, in the preliminary document set-up section of your main file,
you’d include the style sheet, or template, like this:
.TITLE "Sample Document
.AUTHOR "Joe Blow
.PRINTSTYLE TYPESET
\#
.INCLUDE head-template
\#
.START
The blank comment lines ( \# ) aren’t required, but
they do make your file(s) easier to read.
If the file to be included is in the same directory as the file
you’re working, you simply enter the filename after
.INCLUDE. If the file’s in another directory, you must
provide a full path name to it. For example, if you’re working in
a directory called /home/joe/stories and your
style-sheet is in /home/joe/style-sheets, the above
example would have to look like this:
.TITLE "Sample Document
.AUTHOR "Joe Blow
.PRINTSTYLE TYPESET
\#
.INCLUDE /home/joe/style-sheets/head-template
\#
.START
INCLUDE is not restricted to style sheets or templates. You can include any file at any point into a document, provided the file contains only text and valid groff or mom formatting commands. Neither is INCLUDE restricted to use with mom’s document processing macros. You can use it in plain typeset documents as well.
Experts: INCLUDE is an alias for the groff request, .so. Mix 'n' match with impunity.
Although it doesn’t really matter where you define/initialize colours for use in document processing (see NEWCOLOR and XCOLOR in the section Coloured text), I recommend doing so before you begin document processing with START.
The macro, COLOR, and the inline escape, \[<colorname>], can be used at any time during document processing for occasional colour effects. However, consistent and reliable colourizing of various document elements (the docheader, heads, linebreaks, footnotes, pagenumbers, and so on) must be managed through the use of the document element control macros.
Note: If you plan to have mom generate a table of contents, do not embed colour inline escapes (\[<colorname>]) in the string arguments given to any of the reference macros, nor in the string arguments given to HEAD, SUBHEAD or PARAHEAD. Use, rather, the control macros mom provides to automatically colourize these elements.
• Must come after LS or AUTOLEAD and before START
DOC_LEAD_ADJUST is a special macro to adjust document leading so that bottom margins fall precisely where you expect.
When you invoke .DOC_LEAD_ADJUST, mom takes the number of lines that fit on the page at your requested leading, then incrementally adds machine units to the leading until the maximum number of lines at the new leading that fit on the page coincides perfectly with the bottom margin of running text.
In most instances, the difference between the requested lead and the adjusted lead is unnoticeable, and since in almost all cases adjusted leading is what you want, it’s mom’s default and you don't have to invoke it explicitly.
However, should you not want adjusted document leading, you must
turn it off manually, like this:
.DOC_LEAD_ADJUST OFF
If you set the document leading prior to START with
LS
or
AUTOLEAD,
DOC_LEAD_ADJUST OFF must come afterwards, like
this:
.LS 12
.DOC_LEAD_ADJUST OFF
In this scenario, the maximum number of lines that fit on a page at
a
leading
of 12
points
determine where mom ends a page. The effect will be that last lines
usually fall (slightly) short of the “official” bottom
margin.
In PRINTSTYLE TYPEWRITE, the leading is always adjusted and can’t be turned off.
Note: DOC_LEAD_ADJUST, if used, must be invoked after LS or AUTOLEAD and before START.
Additional note: Even if you disable DOC_LEAD_ADJUST, mom will still adjust the leading of endnotes pages and toc pages. See ENDNOTE_LEAD and TOC_LEAD for an explanation of how to disable this default behaviour.
• Must come before START; distance requires a unit of measure
By default, mom prints a
docheader
on the first page of any document (see
below
for a description of the docheader). If you don’t want a docheader,
turn it off with
.DOCHEADER OFF
DOCHEADER is a toggle macro, so the argument doesn’t
have to be OFF; it can be anything you like.
If you turn the docheader off, mom, by default, starts
the running text of your document on the same top
baseline
as all subsequent pages. If you’d like her to start at a different
vertical position, give her the distance you’d like as a second
argument.
.DOCHEADER OFF 1.5i
This starts the document 1.5 inches from the top of the page PLUS
whatever spacing adjustment mom has to make in order to ensure that
the first baseline of running text falls on a “valid”
baseline (ie one that ensures that the bottom margin of the first
page falls where it should). The distance is measured from the top
edge of the paper to the
baseline
of the first line of type.
Tip: Since no document processing happens until you invoke .START—including anything to do with docheaders—you can typeset your own docheader prior to START (if you don’t like the way mom does things) and use .DOCHEADER OFF with its optional distance argument to ensure that the body of your document starts where you want. You can even insert a PostScript image file (see PSPIC).
In PRINTSTYLE TYPEWRITE, the look of docheaders is carved in stone. In PRINTSTYLE TYPESET, however, you can make a lot of changes. Macros that alter docheaders must come before START.
A typeset docheader has the following characteristics:
Or, if the DOCTYPE is CHAPTER,
The family is the prevailing family of the whole document. Title, subtitle, author and document type are what you supply with the reference macros. Any you leave out will not appear; mom will compensate:
Note:
If your DOCTYPE is CHAPTER and you have both “Chapter
<n>” and a “Chapter Title” (as above), mom
inserts a small amount of whitespace between them, equal to
one-quarter of the leading in
effect. If this doesn’t suit you, you can alter the space by
including the
inline escapes,
\*[UP]
or
\*[DOWN],
in the argument you pass to
CHAPTER_TITLE,
like this:
.CHAPTER_TITLE "\*[DOWN 2p]Why Not Patent Calculus?"
or
.CHAPTER_TITLE "\*[UP 2p]Why Not Patent Calculus?"
By default, a docheader starts on the same
baseline
as
running text.
If you’d like it to start somewhere else, use the macro,
DOCHEADER_ADVANCE, and give it the distance you want (measured from
the top edge of the paper to the first baseline of the docheader),
like this:
.DOCHEADER_ADVANCE 4P
A
unit of measure
is required.
Note: If HEADERS are OFF, mom’s normal top margin for running text (7.5 picas) changes to 6 picas (visually approx. 1 inch). Since the first baseline of the docheader falls on the same baseline as the first line of running text (on pages after page 1), you might find the docheaders a bit high when headers are off. Use DOCHEADER_ADVANCE to place them where you want.
By default, mom centers the docheader. If you’d prefer to have your docheaders set flush left or right, or need to restore the default centering, invoke .DOCHEADER_QUAD with the quad direction you want, either LEFT (or L), RIGHT (or R) or CENTER (or C).
By default, mom sets the docheader in the same family used for running text. If you’d prefer to have your docheaders set in a different family, invoke .DOCHEADER_FAMILY with the family you want. The argument to DOCHEADER_FAMILY is the same as for FAMILY.
For example, mom’s default family for running text is Times
Roman. If you’d like to keep that default, but have the
docheaders set entirely in Helvetica,
.DOCHEADER_FAMILY H
is how you’d do it.
Please note that if you use DOCHEADER_FAMILY, you can still alter the family of individual parts of the docheader with the macros listed here.
The following macros let you change the family of each docheader element separately:
Simply pass the appropriate macro the family you want, just as you would with FAMILY.
The following macros let you change the font of each docheader element separately:
Simply pass the appropriate macro the font you want. R, B, I and BI have the same meaning as they do for FT. You may also use any of the style extensions provided by mom.
The following macros let you adjust the point size of each docheader element separately.
Mom calculates the point size of docheader elements from the point size of paragraphs in running text, so you must prepend a + or - sign to the argument. Points is assumed as the unit of measure, so there’s no need to append a unit to the argument. Fractional point sizes are allowed.
Simply pass the appropriate macro the size adjustment you want.
The
leading
of docheaders is the same as running text. If you’d like your
docheaders to have a different leading, say, 2 points more than the
lead of running text, use:
.DOCHEADER_LEAD +2
Since the leading of docheaders is calculated from the lead of running
text, a + or - sign is required before the argument (how much to add
or subtract from the lead of running text). No
unit of measure
is required; points is assumed.
If you want to colourize the entire docheader:
.DOCHEADER_COLOR <color name>
You must pre-define (or “initialize”) the colour with
NEWCOLOR
or
XCOLOR.
The following macros let you change the colour of each docheader element separately. You must pre-define (or “initialize”) the colour with NEWCOLOR or XCOLOR.
It is not recommended that you embed colour (with the inline escape, \*[<colorname>]) in the strings passed to TITLE, CHAPTER_TITLE, SUBTITLE, AUTHOR or the name you give DOCTYPE NAMED. The strings passed to these macros are used to generate page headers and footers, with the result that an embedded colour will cause the string to be colourized in headers and/or footers as well. (If you want headers or footers colourized, or parts thereof, use the header/footer control macros.)
If you’re not writing in English, you can change what mom
prints where “by” appears in docheaders. For example,
.ATTRIBUTE_STRING "par"
changes “by” to “par”. ATTRIBUTE_STRING
can also be used, for example, to make the attribution read
"Edited by".
If you don’t want an attribution string at all, simply pass
ATTRIBUTE_STRING an empty argument, like this:
.ATTRIBUTE_STRING ""
Mom will deposit a blank line where the attribution string normally
appears.
If the optional argument, COVER or DOC_COVER,
is given to ATTRIBUTE_STRING, the string argument represents the
attribution string that will appear on cover or document cover pages
(see the
Introduction to cover pages
for a description of the difference between “document
covers” and “covers”). Thus, it is possible to
have different attribution strings on the document cover page, the
cover (“title”) page, and in the first-page docheader.
An extreme example would be:
.ATTRIBUTE_STRING ""
.ATTRIBUTE_STRING DOC_COVER "Edited by"
.ATTRIBUTE_STRING COVER "by"
The first invocation of .ATTRIBUTE_STRING establishes a
blank attribution string that will be incorporated in the first-page
docheader. The second will print “Edited by” on the
document cover; the third will print “by” on the cover
(“title”) page.
If you don’t require differing attribute strings for doc cover pages, cover pages, or the first-page docheader, .ATTRIBUTE_STRING, without either of the optional first arguments, is sufficient.
Note:
The type specs for the attribution line in docheaders are the
same as for the author line. Although it’s highly unlikely
you’ll want the attribution line in a different family, font,
or point size, you can make such changes using
inline escapes
in the argument to ATTRIBUTE_STRING. For example,
.ATTRIBUTE_STRING "\f[HBI]\*[SIZE -2p] by \*[SIZE +2p]\*[PREV]"
would set “by” in Helvetica bold italic, 2 points
smaller than normal.
Setting documents in columns is easy with mom. All you have to do is is say how many columns you want and how much space you want between them (the gutters). That’s it. Mom takes care of everything else, from soup to nuts.
If you want your type to achieve a pleasing justification or rag in columns, reduce the point size of type (and probably the leading as well). Mom’s default document point size is 12.5, which works well across her default 39 pica full page line length, but with even just two columns on a page, the default point size is awkward to work with.
Furthermore, you’ll absolutely need to reduce the indents for epigraphs, quotes, and blockquotes (and probably the paragraph first-line indent as well).
• Should be the last macro before START
The second argument requires a unit of measure
COLUMNS takes two arguments: the number of columns you want on
document pages, and the width of the
gutter
between them. For example, to set up a page with two columns
separated by an 18 point gutter, you’d do
.COLUMNS 2 18p
Nothing to it, really. However, as noted above, COLUMNS should
always be the last document setup macro prior to
START.
Note: Mom ignores columns completely when the PRINTSTYLE is TYPEWRITE. The notion of typewriter-style output in columns is just too ghastly for her to bear.
Mom’s tabs (both typesetting tabs and string tabs) behave as you’d expect during document processing, even when COLUMNS are enabled. Tab structures set up during document processing carry over from page to page and column to column.
Mom takes care of breaking columns when they reach the bottom margin of a page. However, there may be times you want to break the columns yourself. There are two macros for breaking columns manually: COL_NEXT and COL_BREAK.
.COL_NEXT breaks the line just before it, quads it left (assuming the type is justified or quad left), and moves over to the top of the next column. If the column happens to be the last (rightmost) one on the page, mom starts a new page at the "column 1" position. This is the macro to use when you want to start a new column after the end of a paragraph.
.COL_BREAK is almost the same as .COL_NEXT, except that instead of breaking and quadding the line preceding it, mom breaks and spreads it (see SPREAD). Use this macro whenever you need to start a new column in the middle of a paragraph.
Warning:
If you need COL_BREAK in the middle of a blockquote or (god help
you) an epigraph, you must do the following in order for COL_BREAK
to work:
.SPREAD
\!.COL_BREAK
During document processing, most of the typesetting macros affect type in the document globally. For example, if you turn kerning off, pairwise kerning is disabled not only in paragraphs, but also in headers, footers, quotes, and so on.
Typesetting macros that alter margins and line lengths affect running text globally (or at least try to), but leave headers/footers and footnotes alone. (To indent footnotes, see the full explanation of the FOOTNOTE macro.)
Mom’s tabs (both typesetting tabs and string tabs) behave as expected in running text during document processing. Tab structures that do not exceed the line length of running text are preserved sensibly from page to page, and, if COLUMNS are enabled, from column to column.
Some typesetting macros, however, when used during document processing, behave in special ways. These are the macros that deal with the basic parameters of type style: horizontal and vertical margins, line length, family, font, point size, leading, and quad.
Mom assumes that any changes to these parameters stem from a temporary need to set type in a style different from that provided by mom’s document element tags. In other words, you need to do a bit of creative typesetting in the middle of a document.
The following lists those typesetting macros whose behaviour during document processing requires some explanation. (Please refer to Top and bottom margins in document processing for information on how mom interprets T_MARGIN and B_MARGIN in document processing. Additionally, see ADD_SPACE if you encounter the problem of trying to get mom to put space at the tops of pages after the first.)
Normally, mom establishes the top and bottom margins of running text in documents from the values of HEADER_MARGIN + HEADER_GAP and FOOTER_MARGIN + FOOTER_GAP respectively. However, if you invoke T_MARGIN or B_MARGIN either before or after START, they set the top and bottom margins of running text irrespective of HEADER_GAP and FOOTER_GAP.
Put another way, in document processing, T_MARGIN and B_MARGIN set the top and bottom margins of running text, but have no effect on the placement of headers, footers, or page numbers.
Occasionally, you may want to insert space before the start of running text on pages after the first.
You might have tried using ALD or SPACE and found it did nothing. This is because mom normally inhibits any extra space before the start of running text on pages after the first.
If you need the space, you must use the macro, ADD_SPACE, in conjunction with NEWPAGE.
• Requires a unit of measure
ADD_SPACE takes as its single argument the distance you want mom to advance from the normal baseline position at the top of any page after the first (ie the one on which the docheader is normally printed). A unit of measure is required.
For example, say you wanted to insert 2 inches of space before the
start of
running text
on a page other than the first. You’d accomplish it with
.NEWPAGE
.ADD_SPACE 2i
which would terminate your current page, break to a new page, print
the header (assuming headers are on) and insert 2 inches of space
before the start of running text.
Since adding space in this way is almost sure to disrupt mom’s ability to guarantee perfectly flush bottom margins, I highly recommend using the SHIM macro immediately after ADD_SPACE.
In the normal course of things, you establish the basic type parameters of a document prior to invoking START, using the typesetting macros (L_MARGIN, FAMILY, PT_SIZE, LS, etc). After START, you must use the following macros to make global changes to the basic type parameters of a document.
• Requires a unit of measure
• Requires a unit of measure
• Requires a unit of measure
• Does not require a unit of measure; points is assumed
• Does not require a unit of measure; points is assumed
Important:
Do not use DOC_LEAD in the middle of a page! It should always and
only be invoked immediately prior to a new page, like this:
.DOC_LEAD <new value>
.NEWPAGE
Note: Even if you don’t pass DOC_LEAD the optional argument ADJUST, mom will still adjust the leading of endnotes pages and toc pages. See ENDNOTE_LEAD and TOC_LEAD for an explanation of how to disable this default behaviour.
You need do nothing special to terminate a document. When groff finishes processing the last input line of a file, the page is ejected, subject to whatever routines are needed to complete it (eg printing footnotes or adding the page number).
It happens sometimes, however, that a last line of running text, falling on or very near the bottom of the page, tricks groff into breaking to a new page before terminating. The result is a blank page at the end of the formatted document.
The situation is rare, generally occurring only when some additional macro is required after the input text, eg to exit a list or terminate a quote. To prevent it from ever happening, I recommend getting into the habit of following the final input line of all your mom files with .EL. Depending on the fill mode in effect, you may also have to append the “join line” escape, \c, to the final line.
Thus, for normal text at the end of a paragraph, which is in fill
mode,
and they all lived happily ever after.
.EL
or for ending a
LIST
(also in fill mode)
.ITEM
peaches, pears, plums
.EL
.LIST OFF
whereas, at the end of a
QUOTE
(which is in nofill mode),
Shall be lifted\[em]nevermore!\c
.EL
.QUOTE OFF
Notice that the .EL comes after the last line of input
text, not any macros following.
Note: \*[B] cannot be used as a replacement for .EL when terminating a document.
| Back to Table of Contents | Top | Next: The document element tags |