🚀 go-pugleaf

-----------------------(repeated header)-----------------------------

Elements of E-Text Style
Version 1.0
9 August 1993

This file should be named ESTYLE10.TXT or estyle10.txt.


Copyright (c) 1993 by John E. Goodwin.  All Rights Reserved.

You may make and distribute verbatim copies of this work for non-
commercial purposes using any means, provided this copyright notice is 
included in all such copies.

Contact:  John E. Goodwin
          P.O. Box 6022
          St. Charles, IL  60174
          jegoodwin@delphi.com

[John Goodwin is available to consult, write, and teach courses on E-
text issues and Internetworking]


Abstract:  This manual discusses how to use electronic text (E-text) as 
a communications medium distinct from the print media.  The manual is 
written in a non-technical style, such as a humanist-of-little-brain 
might enjoy reading.  

  o  You can learn how to write effective E-text for personal, business, 
and scholarly communication.  

  o  It includes sections on preparing forms and texts for electronic 
response and on writing effective and business-like E-mail letters.  

  o  There is a brief section on Standard Generalized Markup Language, a 
coding standard of interest to humanists.


Just to prove how non-technical it all is, here is an exceptional lapse 
into technical jargon, in case you know what the Internet and FTP 
archives are:

    This work is a companion volume to _E-Mail 101_, available free as
    ftp://mrcnext.cso.uiuc.edu:/etext/etext93/email025.txt.


<title>  Elements of E-Text Style

  =Preface=     An Apology for E-Text

  =Part I=      Writing for an E-Text Audience

  =Part II=     Specific Differences of Style and Mechanics

  =Part III=    A Very Brief Style Manual

  =Appendix A=  Technical Details:  Relationship to SGML and TEI

  =Table I=     Full Table of Contents  (go to very end of this file)

------------------------(begin part 3 of 3)---------------------------

<Part III>  A Very Brief E-Text Style Manual

  =Section 3.1=  Backups and Saving Work

  =Section 3.2=  Compressed Files

  =Section 3.3=  Version Control

  =Section 3.4=  Use of Word Processing Features

  =Section 3.5=  Character Set and Font

  =Section 3.6=  Outlining and Hierarchies

  =Section 3.7=  Text Inclusions

  =Section 3.8=  Esoterica

This chapter is meant as a concrete example of the suggestions in the 
previous two chapters, in the form of a "style manual".  You should take 
these guidelines as suggestions you may want to adopt, not as rigid 
rules.


<Section 3.1>  Backups and Saving Work

RULE 1.1  You should always keep two copies of any electronic text you 
would mind not having one day, one on your hard disk and one on a 
floppy.  The floppy is far more likely to fail, so you should consider 
keeping two floppies.

A common scheme if you don't work at home is to keep two backups, one at 
home and one at work.  Alternate which one you revise so that you will 
always have the most recent one at home and the next most recent at 
work.  This is so that if a fire or other disaster destroys your work 
records you still have the most recent copy.

If you work at home, make sure your two sets of backup disks are in 
different places.  That way an accident with a strong magnetic field 
(found near motors, in telephones, in TV monitors, etc.)--or a spilled 
cup of coffee--will not wipe out both copies.

RULE 1.2  (Archive copies) You should have *both* an archive copy of 
each important "milestone" version *and* a set of backups.  Backups are 
usually snapshots of your system.  If you delete a file from your hard 
disk and then revise your backup, you will no longer have the file on 
your backup disk!  Even if you put your backup set aside from time to 
time as an archive of "My System, December 1992", One day, you will 
decide to recycle those disks and lose your copy.

The Moral:  you need both an archive copy of each important project and 
a revolving set of backup disks.  (I call mine "A" for archives and "B" 
for Backups).

Checklist:

  o  original working copy on hard disk

  o  second copy on hard disk for really important files

  o  daily archive of important work, organized by project

  o  most recent revolving backup set at another location (weekly or 
monthly; more often for critical files).

  o  second most recent backup set on site.

Remember the basics:  *at least* one backup and don't put your eggs all 
in one basket.  If you think I sound paranoid about this backup stuff, 
trust me.  Do this or you will get burned one day.  I know what I am 
talking about.

RULE 1.3  (Exception to Backups) An exception can be made for E-text 
that can be easily obtained over the network if you don't modify it and 
*if* getting a replacement would not be burdensome.  In effect, the 
network is your backup copy.  But beware that what is on the network 
today may not be there forever.

You can also "forget" about backups (but not archive copies) if your 
computer is on a local area network and you know for a fact that backups 
are made over the network on a regular basis.  Many businesses, 
recognizing that most persons would rather risk losing a months work 
than spend five minutes backing it up, make systematic backups, often 
using automatic systems that work at night, when the network is quite.
That is nice, but remember that you can still lose nearly an entire 
day's work if disaster strikes just before you go home for the day.

RULE 1.4  (Saving Your Work) Unless your word processor has an autosave 
and recover feature, you should develop the habit of saving your work at 
least every fifteen minutes and whenever you get up to leave your 
workstation.


<Section 3.2>  Compressed Files

It is possible to compress text files to around half their original 
size.  Of course, you have to uncompress them before reading, but in 
effect you can double your hard disk size with *software*.  File 
compression is becoming a standard feature of many programs and systems.  

Compression works because text has very regular patterns that can be 
encoded more compactly than the standard encoding.  Files that have more 
random bit patterns--binary files like programs or graphic images--
seldom compress more than a few percent.  

RULE 2.1  Never compress any file except a text file.

I would be a bit leery of compression.  It trades memory, which is 
fairly cheap, for your time, which is expensive.  Also, it complicates 
the strategies your software has to use--what happens if your system 
goes down in the middle of uncompressing an important file?  

Compression is here to stay, but I recommend you follow this rule:

RULE 2.2  Only compress things you keep around for archival purposes--
old reports and projects, things you want at your finger tips but don't 
use day-to-day.  

To give some further guidelines, compression makes a lot of sense in 
these cases:

  o  compressed files make good archive copies, at least if you are 
keeping the file to feel safe and not because you need it regularly.

  o  compressed files are good for network transfers because, for text 
files at least, they cut the time in half.

  o  more subtlely, there is a limit to the amount of hard disk you can 
safely use--you shouldn't use more than you can backup in 10 minutes a 
week or half an hour a month.  

If you make your own backups on floppies, that means that 80 Megabytes 
is about tops.  More than that and you have 100 backup disks (times two 
sets!) to deal with.  Probably you get sloppy.  File compression means 
you can get twice as much stuff on your disk without increasing the 
backup burden, so you save both time and space.  

SUMMARY  The most important thing to remember about file compression is 
that there is a trade off between time and disk space.  The fact that 
you can get twice as much on your hard disk is traded against the fact 
that it takes time to compress and uncompress files.  Given that memory 
is very cheap this is not always a good trade.  The most likely outcome 
is that by keeping too much useless stuff on disk you're setting 
yourself up to waste a lot of time.  


<Section 3.3>  Version Control

Version control is important.  It is easy to keep on top of *if* you 
bother.  If you don't, one day you will modify the second most recent 
version of a long manuscript and then have to figure out the differences 
between two variant documents and "merge" them into your next draft.  
Then again, you could give up all the work you did and go back to the 
old version.  Or maybe you would like to follow this rule:

RULE 3.1  Versions should be numbered consecutively in "dotted decimal" 
notation.  

E.g., 2.4.1 means version 1 of sub-version 2.4 of main version 2.0.  You 
can add the version number to the heading of the file or make it part of 
the file name.  This is hardest to do in DOS, where filenames look like 
DRAFT241.TXT meaning version 2.4.1.  

Version 0.1 up to, but not including 1.0, are reserved for "drafts".  
Version 1.0 is the first public release and Version 1.0.1 its first 
minor revision.

RULE 3.2  In general, the primary version of your work should be in the 
format your word-processing program considers to be "native".  Plain 
text files should be derived from this master copy.

Creating a plain text version and then re-importing it to the word 
processor will often result in problems.  The word processor's native 
format (the one that understands all the nifty features) is proprietary; 
i.e., it is not directly portable to other systems like plain text.  
Something is lost translating proprietary format to plain text and back 
again.  The most common problems are:

  o  A "hard" return is located at the end of every line, making editing 
difficult because you constantly have to adjust the length of each line 
by hand, or else use the "fill" command on each paragraph;

  o  Unusual "line wraps" result from incompatible line lengths;

  o  Lists of items that are supposed to be on separate lines are 
compressed into paragraphs;

  o  Visual formatting like the spaces or tabs before an indented block 
quote, vertical bars alongside paragraphs, and similar things are 
scrambled.

  o  Structures requiring elaborate spacing or tabbing like outlines, 
tables, or section headings are confused;

  o  Double and single spacing is mixed up.

  o  Special symbols and codes are no longer readable.

These problems cause severe version control headaches unless you follow 
the "master copy" strategy.

SUMMARY  Strategies for avoiding these problems in general are given in 
the next section.  But in general you can avoid them if you follow this 
basic strategy:

  (1)  Always consider native format the "primary" version and plain 
text the "derived" version.

  (2)  Never use any feature of your word processor that can't be easily 
translated into the plain text version.

The next two sections concentrate on just which features you can use.  


<Section 3.4>  Use of Word Processing Features

From the standpoint of creating effective E-text it is extremely 
important to understand the following concepts:

  hard return :  a control character that signals the end of a line of 
text.  The actual code, an ASCII character, varies from computer to 
computer.  This is a source of many formatting problems.

  filling : many word processors are capable of adjusting the length of 
lines automatically in a process called paragraph filling.  This can 
either be automatic or on command.  In the older method, the line 
"wraps" when you reach the end, but if you make editing changes you have 
to select the "fill" command.  Newer word processors constantly refill 
the paragraph as you make changes, adjust margins, etc.

  formatting codes and markup : in order to represent all the effects 
you can create on paper using a text file, it is necessary to add 
additional characters that control the formatting of the document--
italics and underlining, fonts, superscripts, and the like.  These codes 
can be typed letters like ".cl" or "</p>"; or they can be "invisible" on 
the screen but nevertheless present in the underlying file.

  bit-mapped vs. character-oriented screens : The screen is represented 
in the computer memory as a series of black and white dots, called 
pixels ("picture elements").  There are two kinds of screens, those that 
can only represent characters and those that can draw any graphic shape 
(including any screen font ever devised, any line or shapes, patterns, 
and complex artistic images like photographs and computer drawings).  
Character-oriented terminals only have

  WYSIWYG : "What You See Is What You Get" is a strategy adopted by many 
word processing systems that run on bit-mapped terminals.  A single 
underlying file can create 

  font size and rulers : fonts in a traditional character-oriented 
screen are all the same size--usually 80 or 132 characters per line.  In 
a bit-mapped system the fonts can have any size.  Some fonts are fixed 
width, meaning that any character takes up the same width (and hence 
there are the same number in every line); in proportional fonts the 
characters have different widths.  The line expands and contracts when 
you change letters.  


    With these concepts in mind, we can discuss how to create E-text 
that is meant to be read as E-text.  The main problem is that not every 
word processor can read files from every other word processor.  The 
least common denominator is the plain text file, or ASCII file.  ASCII 
means "American Standard Code for Information Interchange".  The ASCII 
code includes the characters commonly found on an American typewriter 
keyboard plus some "control characters" representing actions like 
"carriage return" or "horizontal tab".  The issue of which characters 
you can use is discussed in the next section.

When using a word processor you have to be careful because it is not 
always obvious which features will come out well in plain ASCII.  Word 
Processors compete on the basis of their wonderful features.  Often, 
however, the fancy features you paid for cannot be used in the real E-
text world.  They are oriented towards producing pretty paper, but will 
*confuse* other computers unless they are running identical software.  

You will not be able to represent 

  o  bolding

  o  italics

  o  underscores

  o  superscripts

  o  subscripts

  o  indenting and margins (except by spacing--not tabbing)

  o  soft returns

  o  multiple proportional fonts

  o  double columns

  o  special symbols or formulas

  o  included graphics and spreadsheets

and so on and so on.  This means that you must forgo essentially 
anything that needs a formatting code.  In newer WYSIWYG word 
processors, it may be hard to tell what is formatting and what isn't.  
In general, you have to think like a typewriter.  *sigh*

RULE 4.1  Change to a non-proportional font, preferably 10 point (elite) 
or 12 point (pica) and 6 inch distance between margins.  This works out 
to 72 characters for elite or 60 for pica.

To be safe, lines should not exceed 72 characters; but in no event 
should there be more than 80 characters without a hard return.  

Actually, 60 characters per line (12-point non-proportional font with a 
six inch ruler) is more portable, because it can be read both on 
standard 80 character screens and with the default settings of most word 
processors.  If you use the 72 character line, some users may have to 
select the whole text and convert it to Courier-10 to read it in a 
WYSIWYG word processor without funny line wrapping.  Not all users are 
that sophisticated, so you are better off using a 60 character line 
unless you have a special reason to go with 72.  Also, short lines are 
easier to read, as you will learn in any speed reading course.

RULE 4.2  Don't justify the text, but keep all text "ragged right", like 
typescript.  

RULE 4.3  Don't hyphenate words.  Let the right column look uneven.

If someone is using a different screen width, your hyphenated word could 
end up looking like "this in the mid-dle of the text".  Also, SEARCH 
commands choke on hyphenation.  There is probably nothing you can do to 
prevent your word processor from breaking words that have "real" hyphens 
in them and happen to fall at the end of a line (remember this when 
*you* have to search).

RULE 4.4  Start text flush with the left margin and don't add spaces to 
create an indented effect.  Do not use indentation, tab stops, or 
spreadsheet like tables to format your text.

If you want to include spreadsheet data, use Comma Separated Value (CSV) 
text like this:

     "January Actual","January Budget" <hard return>
     23201.45,20000.00 <hard return>

You can cut and paste this into any Spreadsheet program.  

RULE 4.5  If you use the autofill feature to avoid having to type 
return, make sure your word processing program has a feature that will 
insert "hard" returns at the end of each line when you create your plain 
text output file.

In Microsoft Word, this is the "Save as Text with Linebreaks" command.  
If you use "Save as Text" you get returns at the end of every 
*paragraph*, not every *line*.  Someone with an old-fashioned text 
editor--one that likes hard returns after every line--will see *very* 
long lines (and probably truncate them to boot).  You may have to 
experiment to find the equivalent command in your system.

RULE 4.6  Don't use special characters like non-breaking spaces or 
optional hyphens to dictate where line breaks occur.  These features are 
not portable.

RULE 4.7  Try to prevent your word processor from hyphenating words on 
its own.  

It's OK to break a word that has a "hard" hyphen at the hyphen.  That 
is,  if a hyphen is a normal part of the word's spelling and the word 
processor decides to break the word at the hyphen, don't worry.  But you 
should try to avoid breaking sentences that have dashes--like this--at 
the double dash.  Sometimes the word processor will break a double dash 
in half.

RULE 4.8  Use single spacing with two hard returns between paragraphs.

Many WYSIWYG word processors allow single, double, or triple spacing 
between lines.  In the text file, however, there is not necessarily two 
returns between each paragraph.  Double spaced text *is* much easier to 
read on a screen, but it is hard to re-paragraph.  The two returns 
between each line tend to make word processors think that each line is a 
paragraph.  

In general, it is easier to 

RULE 4.9  Keep paragraphs short, say around 10 lines.

Paragraph breaks form a visual guide for the eye.  A book that has 
paragraphs spanning whole pages is hard to read.  Similarly, on a 24 
line screen it may be difficult to read paragraphs longer than 20 lines.  
Even if you naturally express yourself in paragraphs of 7 to 10 
sentences, you should break your progression of thought into shorter 
segments after writing it down, if you want to reach your audience.  If 
I see a paragraph that fills the whole screen, I tend to want to scroll 
down and skip ahead.  


<Section 3.5>  Character Sets and Fonts

In order to be portable, a document must be coded as a text file.  The 
American Standard Code for Information Interchange (ASCII) represents 
each character as a seven bit number.  There are variant dialects of 
ASCII, especially for languages other than English, but the variations 
do not affect the subset we will be discussing.  In particular, there 
are many extensions of ASCII to eight bits, of which Latin-1 is the most 
popular.  These extensions are *not* portable, and hence not discussed 
further.  

In order to be as portable as possible, ASCII text , or plain text, must 
observe a number of conventions:

Rule 5.1 Use only the 84 character subset of ASCII consisting of the 
twenty-six letters of the English alphabet (both upper and lower case), 
the ten digits, and twenty-two punctuation marks in Table 1 below.  Do 
*not* use the ten bad characters:

  o  dollar sign

  o  pound sign (number sign)

  o  at-sign

  o  carat (circumflex)

  o  tilde

  o  back quote 

  o  backslash

  o  vertical bar, and 

  o  curly brackets 

These symbols do not translate well into character sets in other 
countries.

               TABLE 1.  The 22 Legal Punctuation Marks
  o  comma

  o  period

  o  colon

  o  semicolon

  o  exclamation point

  o  percent sign

  o  ampersand

  o  asterisk

  o  parentheses

  o  hyphen

  o  underscore

  o  plus sign

  o  equals sign

  o  square brackets

  o  apostrophe

  o  double quote

  o  angle brackets (less-than and greater-than signs)

  o  question mark

  o  and (forward) slash.  

More briefly:

     !%&*()-_=+[];:'",.<>?/

The reason why these characters are fine and others aren't is obscure.**

  **  There is an international standard, ISO-646 that adapts ASCII to 
non-English languages.  Part of its character set, the "invariant 
subset",  is the same on all keyboards.  There are also obscure problems 
translating ASCII to its IBM mainframe equivalent, EBCDIC.  Even the 22 
legal characters are too many in some circles.

RULE 5.2  The only "white-space" allowed are spacebar and line endings 
(carriage returns).  Horizontal tabs and other "control characters" are 
not portable.

Actually you can use tabs for text that is not going to pass through 
unusual or difficult conversions.  For example, if you are sharing a 
Spreadsheet by E-mail you can probably exchange a tab-formatted file 
rather than using the (safer) Comma Separated Value format.  

Sticklers will point out that Rule 5.2 means we allow an 87 character 
subset of ASCII.


<Section 3.6>  Outlining and Hierarchies

RULE 6.1  Impose a relatively rigid outline (hierarchy) on your 
manuscript and reflect that hierarchy in a rigid formatting scheme for 
the section and chapter headers.

E.g., this manual uses angle brackets *plus* two spaces *plus* a section 
title.  Each section is preceded by two blank lines, each part by three.  
Sections are numbered in dotted-decimal form.  

Conventions like these allow casual searching, or "navigation" of the 
document.  Unless you have a "hypertext" document that lets you skip 
around easily, such guideposts are necessary.


    In designing markup conventions, you should keep in mind that it is 
more valuable to represent *logical* structure than to try to mimic the 
*physical* appearance of a printed page.  Thus, 

  o  it is wasteful to use vertical space to try to mimic vertical 
layout of a printed page, because the resulting effect looks 
disconcerting on the screen.  Use the number of blank lines to represent 
the logical structure of the document instead.

  o  use flush left headers for the top levels, indent a couple of 
spaces for lower level.  At the very lowest logical level, just skip an 
extra line between paragraphs and don't bother with a separate title for 
the header.

  o  try "tagging" important breaks with special characters like angle 
brackets, a row of hyphens "----------", or a decorative break like 
this:

                    +     +     +     

  o  don't overuse all caps in titles, especially for Section breaks.  
They scream too loudly.  You can't really mimic the print-based effect 
of small caps on the screen.

  o  don't bother developing elaborately different formats for headers 
that are seen infrequently (e.g. chapters, parts, or "books").  
Concentrate instead on the sections, sub-sections and minor breaks.  The 
"wide-area" structure is more simply represented by dotted-decimal and 
the low level structure by visual formatting.  

Remember that the global appearance of the document is much less 
important than it is for a book, since the user never sees the document 
as a whole, only small local sections.  In fact, the highest level 
logical divisions are probably not visual at all--they are the breaks 
between computer *files*, or even a directory hierarchy.  And--ever more 
commonly--hierarchies of *computers*!  This leads us to the next rule.

In preparing your outline, remember the following rule:

RULE 6.2  Never nest a hierarchy or outline more than three levels deep 
without hiding some of the structure.

There is a great deal of structure in the computer world.  

Countries contain 

  domains contain 

    networks contain 

      companies contain 

        individual computers (nodes) contain 

          directories contain 

            subdirectories contain 

              documents contain 

                chapters contain 

                  sections . . . (*whew* that was ten levels).  

You *must* try to hide some of this structure from your reader.  The 
easy way to do this is to narrow in on the local focus and pretend that 
what we're looking at right now is the *only* thing in the world.  It is 
impossible to read a document and simultaneous think of its place in the 
wide world.  Forget the tree structure of the whole network or computer 
system; let the reader focus on the local tree-structure.

And, whatever you do, don't let the reader know they are more than three 
levels deep.


<Section 3.7>  Text Inclusions

We have already discussed basic formatting issues like paragraphing, 
line length, and basic layout.  This section concentrates on the myriad 
details that bedevil the typist.  We save most of the *really* technical 
stuff like tables, foreign languages, and formula, for =Section 3.9=.  
In this section we discuss very common inclusions in text--


<Section 3.7.1>  Alternate Fonts

RULE 7.1  Use markup to represent *logical* emphasis rather than 
particular font effects.  

Here are some typical reasons and traditional *print* renderings:

  o  emphasis (italics or underlining)

  o  strong emphasis (bolding, all caps)

  o  interior dialog (italics)

  o  editor's emphasis (italics)

  o  foreign language phrase (italics)

  o  book title (italics, underline)

  o  article title (quotation marks)

  o  new term, index term, glossary item (italics, quotes, underline)

As you see, italics are overused and the choices are not always 
consistent.  In order to make your meaning PERFECTLY CLEAR, it is best 
to observe this rule:

RULE 7.2  Prefer delimiters for marking inclusions.  Use different 
delimiters for different purposes.

A delimiter is a character or pair of characters that is used fore and 
aft to set off text.  

It is not a bad idea to develop a set of guidelines for how to render 
each sort of inclusion.  Here is what I use:

  o  now *this* is emphasis (and *strong* emphasis)

  o  as I said, markup is part of =la vie=.

  o  or we can introduce a new "term" like this (See "taxonomy").

  o  book titles, like _Elements of Style_, are a snap.

I also have a series of conventions I use for special situations that 
arise in scholarly text, such as multiple languages or included math 
text.

By the way, avoid the effect that results when you try to 
_mimic_print_media_by_underlining_in_this_fashion_.  The result is 
tedious and leads to long words that don't wrap well.  In E-text, a pair 
of underlines is just another delimiter, nothing more.

RULE 7.3  In E-text, always place punctuation *outside* delimiters.

     Otherwise, the E-text looks "silly."  Better:  "silly".

In print, you put the punctuation after a quotation on the "inside."  
This looks good in print but terrible on the screen.  If your E-text is 
destined for computer screens (and automated search programs) it is 
better put the punctuation on the "outside".  If this disturbs you, 
remember that in the last century the printers rule (as I have seen in 
many books,) was to put *commas* inside parentheses as well as inside 
quotation marks.  We are allowed to change these conventions from time 
to time.


<Section 3.7.2>  Quotations and Included Blocks of Text

     There are a number of ways to include quoted or included
     materials.  One, favored in print, is to push the margin
     of included text inwards, like this.

You should use this technique *very* sparingly.  It requires a hard 
return and hand spacing for each line.  Reformatting (to shorten the
passage, say) is very difficult.  WYSIWYG word processors let you shift 
margins on a per-paragraph basis.  This feature is not transportable so 
you can't use it for E-text.

In E-mail correspondence you often see the convention that a right angle 
bracket in the left column sets off correspondence.  Often, this 
continues to the point of inanity:

     >>> I said I don't like the President's new policy
     >> O yeah?
     > Yeah.
     O yeah?
     >  Not only that, you're an idiott
     Well so are you.  And you don't spell good either.

Our ability to reconstruct the whole train of correspondence is a poor 
trade for legibility.  

Another device to avoid is the frequent use of vertical bars alongside 
text to indicate changes.  Although most computer keyboards have a 
"vbar" (usually a shift-backslash) this character does not travel well 
and the visual effect is lost in some fonts or if the line length 
changes.

An alternative to the vertical bar is to mark changed sections with 
double brackets:

[[Our new improved widget has 
a longer lifetime and
higher customer satisfaction
rating.]]

More elaborate schemes for marking changes are discussed in the section 
on Editing and Marked Sections.

In summary, we have this rule:

RULE 7.4  Avoid block quotes and text with vertical lines to represent 
additions or changes.  Just use conventional quotation marks or a 
special "delimiter" like double square brackets.


<Section 3.7.3>  Lists

There are two basic kinds of list, ordered** and unordered.  Unordered 
lists often have "bullets" in front of the items.

  **  Also called enumeration's.

RULE 7.5  Indent list items at least two spaces and make sure list items 
are in separate "paragraphs", i.e. with a blank line between each item.

This prevents formatting problems that occur when the word processor 
decides that a list is actually a paragraph and pours it, bullets and 
all, into a rectangular shape.

RULE 7.6  Do not use a "hanging indent" for list items.  Let subsequent 
lines run to the left margin.

  o  This is an example of a list item
     that looks good in print but
     is hard to re-format in E-text.

  o  This second list item is more typical
of E-text.  You can reformat it without deleting
lots of spaces at the beginning of each line.

Also, as mentioned in Part II, the visual effect of straight line 
margins is less important in E-text.  You don't gain all that much 
visually by going for the pretty-but-hard-to-format look.


<Section 3.7.4>  Cross References, Hypertext, and Embedding

References to other parts of the text should be set off so they can be 
found.  Cross-references are of several sort, all related:

  o  Cross-References to other parts of the document:  See Section 3.4,  
See "UNIX" in glossary, Page 43.

These cross references are essentially pointers that urge you to leap 
over the intervening text.  This is easy in print media, where you have 
all the pages in your hand.  With a computer program you have to use the 
comparatively clumsy method of manipulating the keyboard or mouse to 
move around.  With plain text, the only rational approach is to use the 
"search" or "find" command of the word processor to locate the passage.  
The art comes in guessing good "strings" (sequences of letters) to 
"search" for.

  o  Hypertext references (outline overview, hypertext menu and 
references)

Many word processors allow you to "navigate" a document by traversing an 
outline overview.  In what amounts to the same thing, "hypertext" 
programs often implement the natural tree-structure of a document by a 
series of menus representing the possible "branches" available at each 
"node".  This is the computer equivalent of the dime-store "interactive 
adventure book" in which you get to choose the plot developments by 
making choices like "If you want to rescue the damsel go to page 43; if 
you want to kill the ogre, go to page 136."

  o  External File References

Here the point is that we can name other files and directories--and even 
other computers, e.g. "rtfm.mit.edu:/pub/usenet" means subdirectory 
"usenet" of directory "pub" on computer node "rtfm" at M.I.T.

  o  "Bibliographic Citations" of print media

The Bibliographic citation, either as a hypertext link in the text 
(footnote) or as a list of references (menu) is a subject of great 
attention in print media, with all sorts of elaborate formatting rules.

  o  Embedded Figures and Included Files

Very often, word processors (and long computer programs) have a master 
file that looks something like this:

     include <Front.Matter>
     include <Chapter.1>
     include <Chapter.2>
     include <Chapter.3>
     include <Chapter.4>
     include <Chapter.5>
     include <Appendix.A>
     include <Index>

This master document sews together a bunch of smaller files.  In 
advanced programs, you may be unaware that this process, called file 
inclusion, or embedding, is taking place.  

File inclusion is especially common as a solution to the following 
problem:  how do you include material that is "foreign" to textual 
matter, say a graphic image or drawing.  If you just cut and paste the 
text, the program will mistake it for part of running text, often with 
dire consequences.  The solution is to keep the offending material in a 
separate file and have only the file reference in the text itself.  Then 
all the word processing program has to do is 

You can immediately see that all these are applications of a single 
idea, the idea of a "pointer", or "reference".  One part of the document 
points to another.  We are supposed to imagine--and the program is 
supposed to make us think--that there is a bridge from one place to 
another, or that the reference can be expanded to that we can enter into 
the other file or location and get back again.  Thus, the "See 
Reference", hypertext link, or external file reference really amount to 
the same thing.

The point is that in all cases we need is someway to represent the 
starting point (reference or pointer) and ending point (anchor point) of 
the arrow.  The World Wide Web uses Hypertext Markup Language (HTML).
An HTML cross-reference looks like this:


The corresponding target, or anchor, is marked this way:



One soon tires of making up unique names to allow each cross-reference 
to mate with its anchor.  It is more natural to use the document's 
natural tree structure (perhaps represented by dotted decimal) for 
anchor identification.  Admittedly, this lends itself to dangling 
references like "See page 25" when page 37 is the correct page for 
version 2.3.  Correcting these references is probably less work than 
typing the ungainly syntax of an HTML cross-reference.

If we are not creating a source document to connect to the World Wide 
Web, a simpler method is to delimit the reference with equals signs, 
=See Index=, and the anchor point with angle brackets.  This has an 
added advantage if you are using equals signs to delimit italic text, 
since glossary entries are often rendered in italics.  You can see how 
natural this is given the section marking scheme adopted here (See 
=Section 26.6.4= below).

  <=Index>  This is the anchor point for the index reference made in the 
above paragraph.  The equals sign is optional.  It just serves to mark 
the tag <index> as an anchor point.  

RULE 7.7  Delimit glossary entries, index entries, See references, and 
so on with equals signs.  Use a consistent notation, such as angle 
brackets, to mark the anchor points.

The World Wide Web attempts to link documents with cross-references 
(hypertext links) on a global scale.  The notation developed for this 
project is called a universal reference locator (URL) and is very 
similar to 

     protocol://node:/directory/file:port

E.g.:

     ftp://ftp.ncsa.uiuc.edu:/pub/education/README:80.

     news://comp.sys.mac


The "protocol" part has to do with the method of getting the document 
(and thus implicitly with the classification scheme).  The examples here 
are File Transport Protocol and Usenet News, two common document 
retrieval systems.  "ftp.ncsa.uiuc.edu" is a computer, "comp.sys.mac" is 
a "newsgroup".  "/pub/education/README" is a file in a directory called 
"/pub/education"; and "80" is a "port number".  These details only 
concern the retriever, who may be just a computer program.

The URL notation is easily adapted to other hierarchical schemes used 
outside the computing world, especially if the syntax rules are relaxed 
a bit.  Here are some ideas:

For Books:

  dewey://stcharles.pub.lib:270.23.07:gilson:4  (St. Charles Public 
Library, Dewey Decimal, Author Ettienne Gilson, copy 4).

  LoC://QA.22.4:  (a library of Congress citation)

  ISBN://123-24-55

For a Journal Article:

  journal://Time:1990.23.56-69

For the Phone System:

  voice://1.708.840.8069  (A voice number)

  fax://1.708.840.8069  (A FAX number)

  internet://jgoodwin:adcalc.fnal.gov  (E-mail address)

  postal://Box.6022:St.Charles:IL:60174  (Surface mail)

Or something like that.  

RULE 7.8  Use Universal Reference Locators (URLs) for worldwide computer 
file references.  Campaign for its extension to other obvious (paper and 
telephonic) information sources.


<Section 3.7.5>  Editing and Marked Sections

RULE 7.9  Indicate short deletions [and additions] with square brackets.  
If you need to tell them apart add a plus or minus sign in front.  
Indicate the version of the change by a version number (single number or 
dotted decimal) after the sign.

     This regulation shall apply to each +1[and every] tax payer -2[, 
except members of this legislature].

We can thus reconstruct the history of this text:

     Version 0:  This regulation shall apply to each taxpayer, except 
members of this legislature.

     Revision 1:  This regulation shall apply to each and every 
taxpayer, except members of this legislature.

     Revision 2:  This regulation shall apply to each and every 
taxpayer.

This principle can be extended to whole sections of text except that it 
is better to use double square brackets since the text itself may 
contain "innocent" brackets.

-2.3[[  . . . ]]  means that this section is omitted in Version 2.3.

This notation soon becomes wearisome after multiple and intricate 
revisions.  Jim Warren has devised a visual format that makes collating 
multiple versions in tabular or outline form:

012
    This regulation shall apply to each 
      and every
    taxpayer
       , except members of this legislature
    .

RULE 7.10  For complicated additions and deletions, such as those found 
in legal matter, use Warren format.

Here are three examples of the formats we have been discussing:


[[include example here]]


One final rule:

RULE 7.11  Don't space between ellipsis.  Instead, leave one blank space 
before and after:  ( ... ).  

Word processors do not necessarily recognize ellipses as a single 
"thing".  The gracious effect of spacing created by a typewriter seems 
lost on a computer screen.


<Section 3.7.6>  General Style and Conventions

This section is about rules that are conventional to almost all typing.  
A brief list is included here for completeness:

RULE 6.12  Add two spaces after each major break (period or question 
mark, colon, etc.) and two spaces after minor pauses (comma, semicolon).  

An exception is made for periods that are part of an abbreviation or 
initials of a name, where the rule is:

RULE 6.13  Allow one space after each initial in a name but not between 
initials of an abbreviation:  J. E. Goodwin, St. Charles, Ill., U.S.A.

RULE 6.14  Represent a double dash with two hyphen and do not allow 
spaces on either side of the dash--instead like this.

RULE 6.15  Certain Latin abbreviations do not have internal spaces, nor 
are they in italics:  i.e., e.g., etc.



<Section 3.8>  Esoterica

99% of all ordinary E-text written in English does not need this 
Section.  But the issues discussed here greatly effect certain kinds of 
text:

  1. Texts requiring traditional scholarly adjuncts such as citations, 
cross-references, indexing, bibliographies, glossaries, critical 
apparatus, and figures;

  2. Scientific and mathetmatical texts that use formulas extensively;

  3. Statistical text with frequent use of numbers, uncertainties (plus 
or minus), scientific notation, and tabular material.  Such text occurs 
commonly in the physical and social sciences, e.g. reports of 
experiments.

  4. Texts in one language that discuss another (language textbooks, 
grammars, dictionaries, commentaries, many works in the humanities); 


<Section 3.8.1>  Inclusions in Languages Other than English

In English, where diacritical marks are rare, foreign languages are.  It 
is important to distinguish between =transcription= and 
=transliteration=.  In transcription, an attempt is made to render the 
word as nearly as possible using the English alphabet, with or without 
diacritics.  Precision .  Transliteration is an attempt to represent the 
*spelling* of the word in the non-English alphabet.  Great effort is 
made, in designing the tranliteration system, to make the 
transliteration reversible, so that the exact original text can be 
recovered by a knowledgable human or program.

These two possible approaches to including non-English text lead to two 
different rules, depending on intent:

RULE 8.1  Set off foreign phrases with the same delimiters used in place 
of italics (usually equals signs).

RULE 8.2  Use special delimiters (for example plus signs or asterisks) 
to signal special notations used for *tranliteration*.

No attempt is made to distinguish three uses of "equals-italics"--
foreign language italics, cross-reference signal, and miscellaneous 
italics.  As in print, these can usually be distinguished by context.


    Beyond representing foreign phrases exactly, one might want an 
informal notation for representing the diacritic marks that do 
occasionally occur in English.  Using these is probably pedantic in 
ordinary E-text, but from time to time they may be useful, e.g. in 
grammatical discussions:

RULE 8.3  In ordinary English texts it is not usual to use diacritical 
marks, even when the English word technically has them, such as:  
fac?ade, ro=le, coo%rdinate, blesse!d.  

If absolutely necessary, we recommend: 

  acute accent: ne/e

  grave accent:  blesse!d

  circumflex accent, tilde, or macron:  ro=le, nolo= contendere

  diaeresis or umlaut:  coo%dinate

  cedilla:  fac?ade

The choice of symbols is based in portability (which excludes, for 
example a tilde or circumflex).  Also, the notation is just a little 
ugly to discourage its overuse.


    E-texts that discuss foreign languages present special problems.  
Here are some suggestions:  

  1.  The basic convention is that the primary language is unmarked, and 
the secondary language delimited by asterisks: *E pluribus unum*, or by 
equals signs =E pluribus unum=.  

The choice of delimiter used requires some thought.  In Latin, asterisks 
should be used so that equals signs can be used to represent macrons:

     Ve=ni=, vi=di=, vi=ci=.

Unless there are considerations like these, the asterisk is chosen for 
the most frequent use in the text (usually italics-for-emphasis) because 
it is less obtrusive and most conventional.

Since such text do not usually contain quotations, double quotes may be 
used to represent translations or definitions:

     =E pluribus unum= means "from many, one."

In printing, both the foreign text and the translations are often 
rendered in a different style.  If italics are needed for other 
purposes, they should be delimited by asterisks:

     =E pluribus unum= is *so* Eighteenth Century.

  2.  If the text contains a selection of many different languages, 
special delimiters are used to segregate languages that use the Latin 
alphabet from others.  In this case no effort is made to choose one 
secondary language as "the" secondary language.  Instead, the delimiters 
are used to mark alphabets that differ visually from the Latin alphabet.

=  =   Languages using the Latin Alphabet, other than the primary 
language (in effect "language italics").

*  *   Greek

+  +   Hebrew

/  /   International Phonetic Alphabet

Other delimiters can be constructed =ad hoc=, such as  &&[ ... ]&& or
+/ ... /, (* ... *) and so on.

Just a reminder:  the recommendations here are strictly for informal use 
in the context of "flat" ASCII files, e.g. for casual communication, or 
as character-oriented output from a program that uses a proprietary 
format or SGML for internal use.  Any substantial work with multiple 
languages is probably worth the effort to use something other than E-
text for the *underlying* representation.  In particular, scholars 
should consider the Text Encoding Initiative's recommendation.  

Even with an elaborate underlying markup system, however, the problem 
remains of how to render the foreign language text, perhaps a text that 
does not even use the Latin alphabet, on a character-oriented screen.  


<Section 3.8.2>  Footnotes, Cross-References, and Bibliographic 
Citations

There are two issues here:  how to write the citation and where to put 
it.  As to the first issue, citation schemes that work well in print are 
often cumbersome in E-text.  The answer to the second issue is 

RULE 8.4  Place footnotes at the foot of the paragraph, or else gather 
them in an appendix at the end of the work.

Another common place to put notes, at the end of a Chapter, should be 
avoided since it is a relatively hard place to find, compared to the end 
of the file.  

The inclusion of footnotes in the body of the text with special 
delimiters, as is done by any word processors, is a concession to print-
oriented production of text.  It places the footnote where the *program* 
wants it.  From the standpoint of the reader, there may as well not be a 
footnote at all!

RULE 8.5  The footnote mark should be as unobtrusive and short as 
possible:  usually ** or ++, [34], or [Wells85].

     . . . as discussed in the paper by Wells.[Wells85]  Another . . .

     . . . again makes this point in Ref.[36], where the bias . . .

     . . . See the Nichomachean Ethics+[NE,1150a]. . . .


Footnotes with a single asterisk could be confused with an "emphasis" 
delimiter.  Putting asterisks in brackets, [*], seems long-winded.

RULE 8.6  Footnote sequencing should not continue across physical files.  
Use dotted decimal notation to refer to "long-range" footnotes:  [2.15] 
means footnote 15 in chapter 2.


    Designing a good bibliographic citation scheme for E-text means 
breaking away from print models. Long dashes and hanging indents are 
useless in E-text.  Also, most readers, if they read notes at all, will 
synchronize two windows so that notes can be read in one and the text in 
another.  *Therefore* it is better to make your annotated bibliography 
follow chapter organization than to make it alphabetical or 
chronological.  

In general, it is a good idea to gather bibliographic references in one 
place and *not* put them in footnotes, as is common in print.  This is 
because many of the citations will be URL's (see =Section 3.7.4=), which 
mar the appearance of the text.**

  ** This assumes the E-text is not being prepared for linkage to the 
World Wide Web!  In this context, our discussion applies more to the 
output of a WWW server than to its input.


<Section 3.8.3>  Formulas and Statistical Text

There is a great deal of scope for developing new mathematical notations 
that work well with E-text.  I can only make a few recommendations and 
observations here.

RULE 8.7  Use square brackets to set off "math italics", especially 
variable names embedded in ordinary text.  Omit the brackets for 
displayed equations.

This rule is necessary to make variables stand out.  Human eyes that are 
used to picking out subtle font differences find it hard to read text 
that refers to variables like a where a is the unknown.  To repeat, [a], 
where [a] is the unknown.

RULE 8.8  Separate displayed material by one blank line before and 
after, and indent consistently (five spaces recommended).

Here is a well know example:

     E = m c[2]


     E[2] = p[2]c[2] + m[2]c[4]

where [E] is the total energy, [m] is the rest mass, and [c] is the 
speed of light in a vacuum.  


    Scientific notation is a travesty in type.  One commonly sees such 
attempts as 1e12, 2.005+/-.01, or 2 x 10 5.  We recommend quoting 
numbers in the following fashion:

     1.0E+12, 2.005(10), and 2.E+5.

To my eye, at least, the following rules are useful:

RULE 8.9A. Always use a sign after the "E" in exponential notation;

RULE 8.9B. Always express the decimal in floating point numbers and 
precede a decimal point by a zero, i.e. 0.05, not .05.

RULE 8.9C  Represent symmetric tolerances in parenthesis after the base 
number.

A little care here is considerate of the reader and helpful for 
subsequent typesetting.

RULE 8.10  In running text, superscripts and subscripts could be 
represented the same way as footnotes in the main guidelines, viz.  

     2+[20] = 4+[10], 

although the FORTRAN notation 2**20 = 4**10 is more perspicuous.  

RULE 8.11  Subscripts and superscripts that do not represent powers but 
represent labels, are conveniently handled like array subscripts:

    a(1,3) = b(2,4) instead of a+[1]-[3] = b+[2]-[4].

The array indices might use square brackets instead of parentheses.

RULE 8.12  For the mixed case of subscripts for labeling and 
superscripts for powers, we recommend:

    a1[2] = a2[2] or a1**2 = a2**2 or a(1)[2] = a(2)[2].

The first approach is better suited for long formulas with many powers:

    (x+y)[3] := x[3]+x[2]y+xy[2]+y[3]

    (x+y)**3 := x**3 + x**2*y + x*y**2 + y**3.

RULE 8.13.  Complex expression like summations and integrals can be 
handled informally as follows:

     (1/n)*sum(i=0,n; x(i)[2]) or int(x=0,infty;x[-2]).

RULE 8.14  Matrices, tables, and outlines are handled in a consistent 
fashion.   

       7,  18,     19
     -43,  72,  930.1
    -1.1,  18,    100

Whereas in print vectors and Matrices are represented by boldface 
letters, in E-text it is probably best to adopt Paul Dirac's bra-ket** 
notation, first developed for Quantum Mechanics.  Here, the vector "v" 
is represented as [v>.  This notation is well-developed and *can* be 
typed in E-text.  

  ** The name comes from the following construction:  <bra] c [ket>.  
The vector is called a "ket", the dual vector a "bra", and [c] is the 
operator matrix.


<Section 3.8.4>  Verse, Drama, and Liturgy

RULE 8.15  Each line is a separate paragraph.  There should be two hard 
returns between lines and three between stanzas.  

Alternatively, two returns may mark stanzas, with lines beyond the first 
indented by white space (one space recommended).  Three returns can mark 
longer segments.  Only one of these two methods should be used in any 
one work.

RULE 8.16  Do not try to mimic vertical or horizontal spacing of a 
printed source, unless the visual effect of the poem is the main 
concern.

RULE 8.17  Run on lines (say past 80 characters) can be represented by a 
slash (/) at the beginning of the line.  

RULE 8.18  An asterisk, *, is used to mark caesura, pause, or breathing 
mark.  

This should be preceded and followed by a space (or return) to prevent 
its confusion with a footnote or emphasis delimiter.

RULE 8.19  Use asterisks to delimit stage directions or rubrics.

RULE 8.20  Use special delimiters to mark speakers, roles, or questions 
and answers.  Follow these with two spaces.

This helps the reader skip from part to part.  Ampersands and periods 
make unobtrusive delimiters.  Brackets are visually more striking:

     &Ham.  To be or not to be.

     &Pol.  That is the question.

*or this*

     &V.  The Lord be with you.

     &R.  And with thy spirt.

*or this*

     &Q.1.5  What is LINUX?

     &A.  LINUX is a small, free UNIX-like operating system for 386 
computers.


<Section 3.9>  Electronic Forms and Tests

E-text is often used as a medium for distributing forms, tests, and 
other items to be filled out and returned.  Often, these forms mimic 
paper counterparts at the expense of their purpose--to be easy to fill 
out and return.  Here are some rules:

RULE 9.1  Avoid the multiple column format common on paper forms.

As soon as you start to fill out the form, the columns don't line up.

RULE 9.2  Skip a line between questions.

This avoids the dread re-formatting problem.

RULE 9.3  Place a left open bracket wherever an answer is required, but 
not a right closing one at the end.

In order to fill in a checkbox, you have to position the cursor exactly 
in the middle of the box, delete a character and type and "x".  It is 
easier to position a cursor at the end of the line and start typing 
right away.

RULE 9.4  Avoid checkboxes.  Ask for a one-character typed answer 
instead.

RULE 9.5  Leave four hard returns (three blank lines)  between "short 
answer" questions

The responder begins typing at the beginning of the second blank line.

RULE 9.6  Do not use spaces or underscores to show blanks; use periods 
or hyphens instead.  Put them on the line *below* the response area (so 
the responder doesn't have to erase them and lose count!).

     Your state or province:  [
                               --

     Your zip or postal code:  [
                                -----

This cues the responder as to desired length of the response.  Blanks 
are invisible, except in certain word processors, and underscores are 
often run together, so you can't count them easily.  

This sort of form is easy to fill out:

Your city of residence (20 characters max): [Chicago, Illinois
                                             --------------------.


<Section 3.10>  The E-Mail Business Letter

The paramount rule in writing an effective E-mail business letter is 
brevity.  

RULE 10.1  In general, you should omit as much of the traditional 
apparatus of the business letter as you can,

since the mailing system may well add lots of unwanted detail.  An 
effective letter can be as short as:

     From: jegoodwin
     To: anotheruser
     Subject: E-mail
     <blank line>
     This is what I have to say.  =John=

RULE 10.2  Always begin E-mail with a single blank line.

This is to allow some visual separation from the mail header.

RULE 10.3  For short (one paragraph) messages, use only the paragraph 
and your name, in-line with the last sentence.

Since brevity is the rule, anything beyond a one-paragraph note should 
be carefully trimmed.  The model below is about the *maximum* you can do 
and still have a brief effective letter.  Feel free to omit anything 
unnecessary.

At most, an E-mail letter will have the following parts:

  1. Mail Header

Do not add a letterhead** or mailing address.  The mail system will add 
enough garbage as it is.  Your info goes at the end of the letter.

  ** An exception is in resumes and advertisements, where catching the 
readers attention is of paramount importance.  There, lots of whitespace 
and visually arresting designs are welcome.  The effect wears off 
quickly, however, so think twice before adding eye-catching effects to 
all your E-Mail.

  2. Greeting

This is optional.  "<skip one line>Dear Sir or Madam<Skip another line>" 
(if you don't know the sex of the person you are writing--very 
frequently the case, with E-mail), or "Dear George" or simply "George--"

  3. Body

This follows the principles in the rest of this manual.  Remember:  
flush left.

  4. Closing and Signature

The closing optional.  "<skip line>Your Name<skip line>" is fine.
If you want one, don't indent it a half page, as is customary in print.  

Suggested formal closings are "Sincerely", "[Best] Regards", and 
"Thanks".  I generally avoid "Thanks in advance", since it implies that 
either you aren't thankful if the person doesn't respond (which is 
ungracious); or you don't plan to thank them if they do (which is 
churlish).

You may use special delimiters to mark your signature, but keep these 
light and tasteful.  I sign =John Goodwin=.  Other persons use two 
slashes before there name or add a plus (for clergy), etc., etc.  This 
is more distinctive than a signature file.

  5. Contact information

Since the reader is most likely to contact you just after reading the 
letter, but info here.  

RULE 10.4  Keep contact information short, probably only your E-mail 
address and phone number (two of each, at most)

RULE 10.5  Use the international style for phone numbers:  e.g.,
+1 708 840 8069 (work).  

  Note:  "+1" is the Country Code for the U.S.A.

RULE 10.6  Never, NEVER, include a character-drawing or funny quote in a 
signature file.

     ////
     [oo]    <-- This is me!!!   "Remember O Man that Dust Thou Art"
     ----

Many persons use a "dot-signature" file that is automatically appended 
to all their E-mail.  The effect is almost invariably puerile and 
tasteless.  If you include it twice you can add "incompetent" to the 
list.

Here is how it looks all together:

     To:    blah blah
     From:  blah blah
     Subj:  blah blah
                                    <--blank line required
     Dear Sir or Madam:             <-- or Dear George, or Dear Ms.Smith

     [Body of text]

     [Body of text]

     [Last paragraph] 

     Sincerely,  <--optional close

     =Your name=  <--use signature delimiters for visual effect

     [Your Contact information]


<Section 3.11>  The Final Rule

And lest the reader forget, 

RULE B.  All Rules are Made to Be Broken.

Rules summarize experience and judgment.  In this manual I have tried to 
reflect my own judgment as to what is appropriate, functional, and 
aesthetically pleasing.  I have not always succeeded.  If I have spurred 
the reader to consider their own style and refine it for their own 
purposes, I will have achieved all my end in writing this manual.  Above 
all, remember, dear reader, 

          Question Authority.  It's wrong.


                    +     +     +

<Appendix A>  Technical Details:  Relationship to SGML and TEI

Many of the concerns addressed in this manual are common to participants 
in the Text Encoding Initiative (TEI) and other users of the ISO 
standard, Standard Generalized Markup Language (SGML, see =Section 
2.9=).  I would like to emphasize, for their benefit, that this manual 
describes a *presentation format* and not an encoding format.  It is 
perfectly possible to create an SGML- or TEI-compliant file that uses 
the format discussed in this manual as a visual output format.  

There are very distinct advantages to having a visually appealing, 
informal, character-oriented format, like the one advocated here, in 
which the logical structure (i.e. markup) is still present, but not 
visually intrusive.  SGML compliant systems may well produce such a flat 
file at the request of a user, or the screen output may be cut from the 
program's display window and pasted into such a file.  This style manual 
has tried to describe design principles that will make the resulting 
flat file useful and appealing to read.

Naturally, there are many uses for such a format outside SGML systems as 
well; and a certain uniformity, or at least attention to design 
principles, can only help make the texts created more useful.  

The advantages of SGML or TEI encoding will only come about if word 
processors that hide the markup process from the casual user become 
commonplace and interoperable.  Probably, a low-end freeware editing 
system will have to be created.**  Until that time, welcome or not, flat 
ASCII is not only a visual format, but an interim interchange standard 
as well.  

  **  Such a system is being created for the LINUX operating system.

Once again:  this is not a new encoding or input format, nor is it 
primarily intended as an interchange standard; it is a suggested format 
for visual *output* that happens to be maximally transportable at the 
present moment.

                    +     +     +

<Table I>  Table of Contents

=Part I=    Writing for an E-text Audience

    =Section 1.1=  Why Write for an E-text Audience?

    =Section 1.2=  Is it Possible to Write E-Text and Print at the Same 
Time?

    =Section 1.3=  Differences between E-Text and Print Media

    =Section 1.4=  Version Control


=Part II=   Specific Differences of Style and Mechanics

    =Section 2.1=   Differences Traceable to Physical Media

    =Section 2.2=   Differences in Style

    =Section 2.3=   Differences in Process

    =Section 2.4=   Differences in Repertoire

    =Section 2.5=   Differences in Layout

    =Section 2.6=   Searching and Hypertext

    =Section 2.7=   Copyright Issues

    =Section 2.8=   The Parts of a Book

    =Section 2.9=   The General Theory of Markup (SGML)

    =Section 2.10=  Summary:  Basic Tricks of the Trade


=Part III=  A Very Brief E-Text Style Manual

    =Section 3.1=  Backups and Saving Work

    =Section 3.2=  Compressed Files

    =Section 3.3=  Version Control

    =Section 3.4=  Use of Word Processing Features

    =Section 3.5=  Character Set and Font

    =Section 3.6=  Outlining and Hierarchies

    =Section 3.7=  Text Inclusions

        =Section 3.7.1=  Alternate Fonts

        =Section 3.7.2=  Quotations and Included Blocks of Text

        =Section 3.7.3=  Lists

        =Section 3.7.4=  Cross-References, Hypertext, and Embedding

        =Section 3.7.5=  Editing and Marked Sections

        =Section 3.7.6=  General Style and Conventions

    =Section 3.8=  Esoterica

        =Section 3.8.1=  Inclusions in Languages Other than English

        =Section 3.8.2=  Footnotes, Cross-References, and Bibliographic 
Citations

        =Section 3.8.3=  Formulas and Statistical Text

        =Section 3.8.4=  Verse, Drama, and Liturgy

    =Section 3.9=   Electronic Forms and Tests

    =Section 3.10=  The E-Mail Business Letter

    =Section 3.11=  The Final Rule


                    +     +     +

(end of _Elements of E-Text Style_)

------------------------(end part 3 of 3)-------------------------