@make(notes)
@device[file]
@style(indent 0)
@equate[mylabel=comment]
@define[raggedtext=text, justification off]
@modify[itemize, spread 0.5, leftmargin +4, indent -4, rightmargin 0]
@modify[enumerate, spread 0.5, leftmargin +4, indent -4, rightmargin 0]
@pageheading[odd, right "@value<sectiontitle>"]
@pageheading(even, left "SCRIBE")
@pagefooting[odd, right "@value(page)"]
@pagefooting[even, left "@value(page)"]
@string[line="@&_"]
@prefacesection[Preamble]
These notes are intended to be used by persons attending the SCRIBE
course presented by the Training Group, ERCC.
The notes do not claim to be a comprehensive guide to the use of SCRIBE,
though anyone who uses all of the facilities described here should
be able to produce an acceptably formatted document in most
circumstances.

The notes describe in some detail most of the facilities offered by
SCRIBE which are likely to be of use to the normal user, and the use of
these facilitie is illustrated with examples of both input and output
wherever possible.

Users whose requirements outstrip the facilities discussed on the course
and described here will find it necessary to consult the documents listed
in the References section and (probably) to consult the Advisory Service
for detailed advice on how their needs may be met.
@blankspace[2 lines]
Roger Hare.
@Blankspace[1 line]
@value[day] @value[month] @value[year]
@lecture[Text Processing, Simple Formatting, Facecodes]
@label[lecture1]
@section{Text-Processors}
@mylabel[TextProcessors]
Text-processing programs enable the user to input text (a thesis, a book,
an internal memorandum, a letter, a set of lecture notes etc.) to a computer,
usually mingled intimately with some instructions or directives which
tell the text-processing program how the text is to be formatted.
The formatted text may then subsequently be printed on some suitable
output device.

The advantages of text-processors are many and varied, but among the major
ones are:
@begin[itemize]
they offer authors and writers complete control over the format of any
document they are preparing

if suitable high quality output devices are available, 'camera-ready' copy can
be prepared without introducing delays which are costly both in
time and money, by having such copy prepared by other people

it is (usually) easy to incorporate changes (additions, amendments,
deletions) into a document - certainly far easier than having the whole
document re-typed for example
@end[itemize]
Text-processors vary enormously in their complexity and capabilities, from
the ubiquitous 'word-processor' (often incorporating an editor) available on
many microcomputers, to dedicated phototypesetting systems which are
really only suitable for use by trained printers (eg: LASERCOMP).

@section[A Description of SCRIBE]
@mylabel[DescriptionOfScribe]
SCRIBE is a sophisticated text-processing program which falls somewhere in
the 'upper-middle' class of this range, and which enables the user
to prepare both simple and relatively complex documents of various types
at the terminal, and then format them for a variety of output devices.

The implementation of SCRIBE described in these notes is a locally written
version of the SCRIBE documentation system originally written by Brian K Reid
for DECsystem-10 and DECsystem-20 computers and distributed through the
auspices of the DEC User's Society (DECUS).
This version of SCRIBE is now maintained and marketed by Unilogic Inc. of
Pittsburgh and is available for a wide range of computers (but not the ICL
2900!).
The locally written product described here provides a significant
sub-set of the functionality of Unilogic SCRIBE.

Unilogic SCRIBE is available on several machines locally, including the
SERC DECsystem-10 and the ERCC VAX/VMS.
In view of the facts that these machines are unlikely to be available to the
majority of users, and that the functionality of the locally written version
of SCRIBE is likely to be adequate for most needs, these other implementations
and their use are not discussed further here.
Be aware of the fact though that the local version of SCRIBE is largely
compatible with Unilogic SCRIBE, so that any users who later need to
transfer to one of the implementations of Unilogic SCRIBE should not
encounter any insurmountable problems.

Briefly, SCRIBE operates by allowing users to specify their requirements very
broadly in an an input (manuscript) file.
This manuscript file holds both the text to be processed and the users
formatting requirements in the form of SCRIBE directives or instructions which are
inserted into the manuscript file at the relevant points.

When processed through SCRIBE, these instructions are interpreted in the context
of the output device and document type selected and the results
stored in an output (document) file.
The fine detail of how this interpretation is to be carried out is stored in
the form of a SCRIBE database on EMAS (or BUSH), and the user need not be
concerned with this fine detail.
Changing the overall format of a document, or the output device is merely a
matter of changing one instruction in the manuscript file, rather than
reformatting the whole file as would be necessary with some text-processors.

In addition, if the default formats imposed on the user by the SCRIBE database
are not acceptable, the user has available a variety of methods of forcing
changes in these default formats.

For a fuller description of SCRIBE's design philosopy, please see references
@cite[ercc85], @cite[furuta82] and @cite[unilogic84].
Reference @cite[ercc84c] is a reference manual for the local version of
SCRIBE and also contains brief descriptions of how to run Unilogic
SCRIBE on some of the other machines mentioned above.
@subsection{Making SCRIBE Available}
@mylabel[MakingScribeAvailable]
SCRIBE is implemented on both EMAS and BUSH, and forms part of the
standard EMAS Subsystem available automatically to all users.

SCRIBE may however require large temporary files on occasion, so you
should increase the maximum allowable size of such files on your process
with the EMAS command:
Command:OPTION AUXSTACKSIZE=256
@end{verbatim}
This operation is a once and for all operation, that is, it
does not need to be performed at every login, or every time SCRIBE is run.

You are now now in a position where the SCRIBE command may be issued, either
as a monitor level command, or by @t[DETACH]ing a job to the batch stream (which
will be necessary if SCRIBE jobs consuming more than about 30 seconds of
CPU time are to be run efficiently).

The SCRIBE command has the form:
@begin{verbatim}
Command:SCRIBE @b[manuscript],@b[document]
@end{verbatim}
where @b[manuscript] is the manuscript file, and @b[document] is the
optional document file, containing the user's document formatted as
required both in terms of the layout of the document and the required
output device.
If a document file is not specified, SCRIBE will automatically construct
a document file whose name is a concatenation of the SCRIBE document
type and device type, eg: @t[TEXT#LPT].

@subsection[Preparing The Input (Manuscript) File]
@mylabel[PreparingTheInputFile]
This is merely a matter of entering the text to be processed, interspersed with
the necessary SCRIBE instructions or directives into a file on EMAS or BUSH.

There is no restriction on the editors which may be used for this purpose
(though on this course you will be asked to use EDIT or ECCE).
@subsection[Printing The Output (Document) File]
@mylabel[PrintingTheOutputFile]
Once the document file has been produced, it may be listed on a suitable
device by issuing the EMAS command:
@begin[verbatim]
Command:LIST @b[document],@b[device]
@end[verbatim]
where @b[device] is the network name of the printer on which the
ocument is to be printed.

For full details of some of the editors available on EMAS and BUSH, and of the
@t[OPTION], @t[DETACH] and @t[LIST] commands, please consult the EMAS 2900
User's Guide @cite[ercc82].
@section[Getting Started]
@mylabel[gettingstarted]
Despite its wide-ranging functionality which will be described in detail
later, SCRIBE also lends itself to the preparation of very simple
documents.
As an example of this, consider the fact that a manuscript file
consisting exclusively of text (ie: with @b[no] SCRIBE instructions
whatsoever) will be processed by SCRIBE to produce a document file
formatted for a line printer.
The text will be arranged into filled, justified indented paragraphs.
The only requirement that such a manuscript file be processed as
described is that in the manuscript file, the paragraphs must be
separated by blank (empty) lines.

The line printer is SCRIBE's default output device (known to SCRIBE as
@t[LPT]), and the simple rearrangement of the text into filled,
justified and indented paragraphs is is the style of SCRIBE's default
output document type (known as @t[TEXT]).
In this simplest case, the only instructions or 'directives' which are
required are the blank lines which separate the paragraphs.

Thus, the short file:
@begin[verbatim, need 8]
This is a sample of a very short document.

Each paragraph consists of only one sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into filled, justified and indented paragraphs
separated by blank lines.
@end[verbatim]
would produce the following output:
@label[lptoutput]
@begin[text, above 1, below 1, spacing 1, facecode t, indent 2]
This is a sample of a very short document.

Each paragraph consists of only one sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into filled, justified and indented paragraphs
separated by blank lines.
@end[text]
The points about the default device and output style can be emphasised by
modifying the manuscript file as follows:

First, insert a line of the form:
@begin[verbatim]
@@MAKE[TEXT]
@end[verbatim]
at the very start of the manuscript file.
So, our manuscript file now looks like this:
@begin[verbatim]
@@MAKE[TEXT]
This is a sample of a very short document.

Each paragraph consists of only one sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into filled, justified and indented paragraphs
separated by blank lines.
@end[verbatim]
If the file is now processed through SCRIBE again, and the output compared with
that produced from the file with no instructions, they will be the same.

Next, insert a line of the form:
@begin[verbatim]
@@DEVICE[LPT]
@end[verbatim]
at the top of the file (which now contains the @t[@@MAKE] instruction remember),
so the file now looks like this;
@begin[verbatim, need 10]
@@DEVICE[LPT]
@@MAKE[TEXT]
This is a sample of a very short document.

Each paragraph consists of only one sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into filled, justified and indented paragraphs
separated by blank lines.
@end[verbatim]
If this file is now processed through SCRIBE, the output produced will
be no different from that from the file with no SCRIBE instructions
in whatsoever, or from the file with only the @t[@@MAKE] instruction.

Well, the above is all very well as far as it goes, but all we have done
so far is introduce two instructions without having any effect on the
output SCRIBE produces.
@label[thenextthing]
We really want to be in a position where we can alter the general
appearence of our input text not only by reformatting it into filled and
justified paragraphs, but also by changing the appearance of the final
printed text in a detailed way; for example, by rendering text in a bold
typeface for headings, or in italics for emphasis.
This is quite easy to achieve with SCRIBE and is discussed in more
detail below.

Before we do this however, let's look at the two instructions we've already
seen in a little more detail:
@subsection[The @t(@@MAKE) Instruction]
@mylabel[MakeInstruction]
We have seen that the @t[@@MAKE] instruction allows us to specify the type of
document which SCRIBE is to prepare.
All that we have done so far though is to use the @t[@@MAKE] instruction to tell
SCRIBE to prepare its default document type (@t[TEXT]) which it would have
produced even if the @t[@@MAKE] instruction had not been present.

There are however several other document types available with SCRIBE,
and obviously, it is when we wish to produce one of these documents that
the @t[@@MAKE] instruction becomes useful.

These document types include @t[TEXT], @t[LETTER], @t[REPORT], @t[ARTICLE] and
@t[MANUAL].
We shan't say anything more about them at the moment, but they will be discussed
in more detail later (Section @ref[DocumentTypes]).
@subsection(The @t[@@DEVICE] Instruction)
@mylabel[DeviceInstruction]
The @t[@@DEVICE] instruction enables a specific type of output device to be
selected.
The instruction has the form:
@begin[verbatim]
@@DEVICE[@b(devicetype)]
@end[verbatim]
where @b[devicetype] is the name by which the chosen device type is known
to SCRIBE.
As we have seen, the line printer has the name @t[LPT].

SCRIBE 'knows' about only three other device at the moment - these are:
@begin[verbatim, need 4]
@tabclear
@tabdivide[4]
GP300@\@r[The Phillips GP300 dot-matrix printer]
X2700@\@r[The Xerox X2700 laser printer]
FILE@\@r[An unpaged terminal file]
@end[verbatim]
So, if our sample manuscript file is modified once again, this time by replacing the
@t(@@DEVICE[LPT]) instruction with an @t(@@DEVICE[X2700]) instruction:
@begin[verbatim]
@@DEVICE[X2700]
@@MAKE[TEXT]
This is a sample of a very short document.

Each paragraph consists of only one sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into filled, justified and indented paragraphs
separated by blank lines.
@end[verbatim]
and then processed through SCRIBE, the output produced would be formatted for
the Xerox X2700 laser printer (and could only be @t[LIST]ed on such a device!).
It would look like this:
@begin[text, above 1, below 1,spacing 1, indent 2]
This is a sample of a very short document.

Each paragraph consists of only one sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into filled, justified and indented paragraphs
separated by blank lines.
@end[text]

Notice the important difference between this output, and that shown on page
@pageref[lptoutput] - the line printer output is formatted in a fixed width
font (which is all the line printer is capable of), whereas the output 
immediately above is formatted in a proportionally spaced font.

All further examples of SCRIBE output illustrated in these notes are 
formatted for the laser printer, (that is, they have been produced as if
an @t(@@DEVICE[X2700]) instruction were present, though this is usually
not shown).
This makes life easy as the notes are printed on the laser printer.
All examples of SCRIBE input are set in a fixed width typeface in an
attempt to make the input look as much like terminal or screen input as
possible.

It should also be noted at this point that, logically, a manuscript file
may only be formatted for one output device, so the @t[@@DEVICE]
instruction if used must come at the start of the manuscript file,
before any of the text to be processed.
If this is not done, SCRIBE will start processing the manuscript file
to produce a document formatted for the default device type (@t[LPT]),
and will not be able to cope with a change to another device type when 
the @t[@@DEVICE] instruction is encountered.
For the same reason, only one @t[@@DEVICE] instruction may be used in
a manuscript file.
@subsection[The Facecode Environments]
@mylabel[FacecodeEnvironments]
We said a while back (see page @pageref[thenextthing]) that the next
thing we really needed to be able to do to our simple document
was to control the typeface (or facecode) in which various
parts of the text were printed. 
This is in order that we can (say) obtain headings by producing boldface
text, or emphasise text by printing italic text in the document file.
SCRIBE enables us to do this by means of 'facecode environments', which
must be inserted into the manuscript file at the relevant points, and
which will result in the required typeface being used when the
document file is printed, (ie: @t[LIST]ed on a suitable device).

The instructions for using the facecode environments are quite simple,
the manuscript text to be output using a particular typeface is merely
bracketed with a pair of SCRIBE 'delimiters' (which are usually brackets
of one form or another), and preceded by a SCRIBE instruction which
specifies the appropriate typeface.

The SCRIBE facecode instructions include:
@begin[description, spread 0]
@t[@@B(text)]@\which renders the bracketed text in a @b[bold] typeface

@t[@@I{text}]@\which renders the bracketed text in an @i[italic] typeface

@t(@@C[text])@\which renders the bracketed text in a @c[small capital]
typeface

@t[@@G"text"]@\which renders the bracketed text in a @g[Greek/Scientific]
(Greek/Scientific) typeface

@t[@@U<text>]@\which @u[underlines] the bracketed text

@t[@@+(text)]@\which @+[super]scripts the bracketed text

@t[@@-'text']@\which @-[sub]scripts the bracketed text
@end[description]
So, if we wished to modify our simple manuscript file so that (say) some
of the text in the resultant document was underlined, some rendered in
boldface, and some in small capitals, we could modify the manuscript
file as follows:
@begin[verbatim]
@@DEVICE[GP300]
@@MAKE[TEXT]
This is a sample of a @@U[very] short document.

Each paragraph consists of only @@B[one] sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into @@C[filled], @@C[justified] and @@C[indented] paragraphs
separated by blank lines.
@end[verbatim]
and the output would look like this:
@begin[text,above 1, spacing 1, indent 2]
This is a sample of a @U[very] short document.

Each paragraph consists of only @B[one] sentence, and paragraphs
are separated from one another with blank lines.

When processed through SCRIBE, the text in the file is
rearranged into @C[filled], @C[justified] and @C[indented] paragraphs
separated by blank lines.
@end[text]
@subsection[SCRIBE's Command Structure]
@mylabel[CommandStructure]
Although this section is entitled "@value[sectiontitle]", we will
hereafter refer to SCRIBE 'instructions' rather than commands, so that
there is no confusion about whether we are talking about EMAS commands
which are typed in response to the system's @t[Command:] prompt, or
SCRIBE formatting instructions which are entered into the manuscript
file for subsequent processing when a SCRIBE command is issued.

From the brief description of the @t[@@MAKE], @t[@@DEVICE] and facecode
instructions which have gone before, a couple points about the general
structure of SCRIBE instructions should be apparent:
@begin[itemise, leftmargin +2, indent -2, spread 0, need 4]
SCRIBE instructions are always preceded by an @t[@@] character.

SCRIBE instructions often have bracketed portions - the bracketing
characters may be any of the matched pairs @t[()], @t[{}], @t{[]}, @t[" "],
@t[' '] or @t[< >] (though in these notes, the square brackets (@t([ ])) will
usually be used).
@end[itemise]
In addition, one further point should be made - SCRIBE instructions may be entered
in upper or lower case (though in these notes, upper case is used for the sake
of clarity).
@section[Summary]
@mylabel[Summary1]
We'll be using these summaries just to recap very briefly on what has been
said in the preceding lecture - there won't usually be much detail, just
a brief qualitative restatement of what has been said - so here goes:

We have seen that at it's simplest, use of SCRIBE can consist of
processing a file which contains no SCRIBE instructions whatsoever.

A particular output device may be selected by inserting an @t[@@DEVICE]
instruction in the manuscript file - allowable devices are @t[LPT] (line
printer), @t[FILE] (terminal file), @t[GP300] (Phillips GP300) and
@t[X2700] (Xerox X2700).

Different typefaces may be selected by bracketing the relevant text in
the manuscript and preceding it with the appropriate SCRIBE typeface
instruction - @t[@@B] (boldface), @t[@@I] (italic), @t[@@C] (small
capitals), @t[@@G] (greek), @t[@@P] (bold italic) etc.

We will also be using the summaries to introduce a few SCRIBE instructions
which don't fit well into the general functional scheme of things, but which
are nevertheless extremely useful.
These instructions are usually extremely simple to use as well as being
useful, so the minimum of information will be given on how to use them,
you should try them for yourself and try and sort out problems if they
arise by reading carefully the error messages displayed by SCRIBE (you 
should do this anyway!), and using the information to diagnose and correct
your error.

This time, let's just consider the very common requirement that we need
some blank space in our document, perhaps for the insertion of an
illustration of some kind, or to achieve an aesthetically pleasing spacing
on a title page or something like that.
This can be achieved quite simply by inserting a @t[@@BLANKSPACE] instruction
at the relevant point in the manuscript file.
This has the form:
@begin[verbatim]
@@@@BLANKSPACE[@b(vertical distance)]
@end[verbatim]
where @b[vertical distance] is the amount of blank space which will be left
between the base line of the two lines of text surrounding the blank
space, eg:
@begin[verbatim]
@@BLANKSPACE[1 INCH]
@end[verbatim]
would produce this much
@blankspace[1 inch]
blank space.

@need[3]
There are various units of distance which may be used in the @t[@@BLANKSPACE]
instruction, or with any instruction which requires the specification of
a distance of some sort - these will be described in more detail later.
@section[Practical]
@mylabel[Practical1]
For your first practical, convince yourself of the truth of the  claims
made in the first lecture by trying the following:
@begin[enumerate, spread 0.5, leftmargin +2, indent -2]
use the editor of your choice (actually, at the moment you'll need
to use EDIT or ECCE) to create a short text file; then process it
through SCRIBE and list it on the local line printer (@t[.LP25]).
(If you can't be bothered with setting up a file yourself, use the
file @t[PRACTICAL1] which you should find on your SCRIBE process)
Process the manuscript file through SCRIBE and list the resultant
document file - notice the differences between the output and the input.

now, insert @t[@@MAKE(TEXT)] and @t[@@DEVICE(LPT)] instructions
into the manuscript file, process the file through SCRIBE, and list the
output again.

change the @t[@@DEVICE(LPT)] instruction to an @t[@@DEVICE(GP300)]
instruction and process the manuscript again, listing the resultant
document on the local Phillips printer (@t[.DP25]).

Try @u[underlining] some of the words in your file or setting them in
@b[bold] or @c[small capital] typeface (or any of the others which are
available for that matter).
@end[enumerate]
@lecture[More Formatting, Text and Heading Environments]
@label[lecture2]
@section[Text Environments]
@label[TextEnvironments]
In lecture @ref[lecture1], we saw how to format text on a simple basis,
that is, to produce filled and justified text in paragraphs with the first line
of each paragraph indented in the conventional manner.
We also saw how to emphasise text by shifting into (for example) a bold
or italic typeface on output devices which have these facilities available.
We have also mentioned in passing several other typefaces or 'facecode
environments'.

Now, this is all very well as far as it goes, but we are still heavily
restricted in what we can do with SCRIBE - suppose we wanted to produce
some form of numbered list in our output for example? or set off an
important quotation in a way which made it stand out from the
surrounding text?
There are scores of examples like this which @b[could] be formatted 'by hand'
if necessary, but SCRIBE allows us to format such text objects by using
specially defined text 'environments'.

This is done using a process which is really not much more complicated than
naming the environment, that is, by using the @t[@@BEGIN] and @t[@@END]
instructions, coupled with the name of the text environment concerned,
for example:
@begin[verbatim]
@@BEGIN[@b(environment)]
   .
text to be formatted
   .
@@END[@b(environment)]
@end[verbatim]
where @b[environment] is the name of some SCRIBE text environment.

SCRIBE text environments are all defined in the SCRIBE database, so you
do not need to know anything at all about the detail of how a given
environment is set up.
All that is necessary is to know the name of the required environment; how to
set up the text in the input file according to certain simple rules; and how to
use the @t[@@BEGIN] and @t[@@END] instructions.
We've already seen how to use the @t[@@BEGIN] and @t[@@END] instructions in the
generalised example above; let's look at a couple of simple examples of using
a text environment just to get a slightly better idea of how it all works:
@begin[verbatim]
@@BEGIN[QUOTATION]
"There must be a beginning of any great matter, but the continuing to
the end until it be thoroughly finished yields the true glory."
@@END[QUOTATION]

@@BEGIN[VERSE]
I feel no pain dear mother now
But oh, I am so dry!
O take me to a brewery
And leave me there to die
@@END[VERSE]
@end[verbatim]
when processed would look like this:
@begin[quotation, above 1, below 1, indent 2]
"There must be a beginning of any great matter, but the continuing to
the end until it be thoroughly finished yields the true glory."
@end[quotation]
@begin[verse]
I feel no pain dear mother now
But oh, I am so dry!
O take me to a brewery
And leave me there to die
@end[verse]
An alternative way of specifying an excursion into one of SCRIBE's text
environments is to use what is known as the 'short form', which consists
of naming the environment concerned, and placing the text to be
formatted in brackets after the environment name, thus, the same two
examples would look now look like this in the manuscript file:
@begin[verbatim]
@@QUOTATION["There must be a beginning of any great matter, but the
continuing to the end until it be thoroughly finished yields the true
glory."]

@@VERSE[I feel no pain dear mother now
But oh, I am so dry!
O take me to a brewery
And leave me there to die]
@end[verbatim]
and on output would look like this:
@blankspace[2 lines]
@quotation["There must be a beginning of any great matter, but the
continuing to the end until it be thoroughly finished yields the true
glory."]
@verse[I feel no pain dear mother now
But oh, I am so dry!
O take me to a brewery
And leave me there to die]
which are both exactly the same as the first case and serve to demonstrate
the equivalence of the 'long' and 'short' forms of specifying an
excursion into an environment.
In practice, it is usual to limit the use of the short form for
excursions into an environment which do not exceed one line of text, and
to use the long form for all excursions which extend over more than one
line.

The above two examples also illustrate the use of two fundamental types
of text environment - a 'filled' environment (@t[QUOTATION]) and an
'unfilled' environment (@t[VERSE]).

Generally speaking, SCRIBE's text environments fall into one or other of these
two classes which are now described, along with some of the text environments:
@section[Filled Environments]
@mylabel[FilledEnvironments]
In printing terminology, 'filled' means that as much text is placed on the line
as possible without going over the previously defined right margin.
In practice this usually means that due to the varying and unpredictable length 
of the words in a document, there will be some varying amount of space left at
the end of every line in a 'filled' document (unless hyphenation of some
sort is used).
This results in what is known as 'unjustified' text (common in bibles), 
sometimes known as 'ragged right'.

'Filled and justified' means that in filled text, the inter-word spaces are
adjusted so that each line exactly fills the available space, thus giving
a straight right margin (like in these notes).


SCRIBE uses the term 'filled' fairly loosely, to mean either 'filled' or
'filled and justified' as described above, and in practice, 'filled and
justified' is the norm.

Certain types of text environment are by their nature 'filled', for example,
running text is usually filled, so the @t[TEXT] environment produces filled
(and justified) output (see the examples above).
Let's look at some of the filled environments in a bit more detail:
@subsection[The @t(TEXT) Environment]
@mylabel[TextEnvironment]
The @t[TEXT] environment is SCRIBE's default environment and and we've already
seen a short example above (see section @ref[TextEnvironments]).
@t[TEXT] produces filled and justified paginated text, with the first line of
each paragraph indented.
Page numbers are placed at the top centre of each page.

@t[TEXT] is also SCRIBE's default document type (see section
@ref[DocumentTypes]) - but this is the only occasion on which there is a clash
of environment and document type names.

For example, the input:
@begin[verbatim]
@@BEGIN[TEXT]
This is a sample of text to be formatted using SCRIBE's default TEXT
environment.
The output is 'filled and justified' and the first line of each
paragraph is indented by a suitable amount in the conventional
manner.

New paragraphs are taken by inserting a blank (empty) line between
the paragraphs (like the line before the start of this paragraph).

If this example were continued for long enough, you would be able
to see that in addition to filling, justifying and indenting, SCRIBE 
also paginates the output text and places a page number at the top
centre of each page.
@@END[TEXT]
@end[verbatim]
would look like this on output:
@begin[text, above 1, spacing 1, indent 2]
This is a sample of text to be formatted using SCRIBE's default TEXT
environment.
The output is 'filled and justified' and the first line of each
paragraph is indented by a suitable amount in the conventional
manner.

New paragraphs are taken by inserting a blank (empty) line between
the paragraphs (like the line before the start of this paragraph.

If this example were continued for long enough, you would be able
to see that in addition to filling, justifying and indenting, SCRIBE 
also paginates the output text and places a page number at the top
centre of each page.
@end[text]
@subsection[The @t(ENUMERATE) Environment]
@mylabel[EnumerateEnvironment]
Another useful SCRIBE environment is the @t[ENUMERATE] environment which
allows the construction of a numbered list - which is a very common requirement
in many documents.
In this case, the 'paragraphs' are the numbered items, and again, they should
be separated within the environment in the input file by blank lines.
The output produced is filled and justified with each 'paragraph' (or more
properly 'item') being numbered.
The important thing to remember here is that @b[SCRIBE can count!]
This means that you do @b[not] need to insert numbers by hand, and more
importantly, do not need to change numbers by hand (a tedious process), when
at some future date it may be necessary to modify a list by adding or removing
items.
Thus the input:
@begin[verbatim]
@@BEGIN[ENUMERATE]
This is the first item in a short enumerated list.

This is the second - note that 'paragraphs' or items are separated
one from the other with a blank line.

This is the final item in this short list.
Note the fact that in the input there are no numbers, while in the
output there are.
This is because SCRIBE can count.
If you do put numbers in your input file two things will happen; a) you
will get two numbers on each 'paragraph' in the output; b) your numbers
will probably be wrong!
@@END[ENUMERATE]
@end[verbatim]
would produce the following output:
@begin[enumerate]
This is the first item in a short enumerated list.

This is the second - note that 'paragraphs' or items are separated
one from the other with a blank line.

This is the final item in this short list.
Note the fact that in the input there are no numbers, while in the
output there are.
This is because SCRIBE can count.
If you do put numbers in your input file two things will happen; a) you
will get two numbers on each 'paragraph' in the output; b) your numbers
will probably be wrong!
@end[enumerate]
@subsection[The @t(ITEMIZE) Environment]
@mylabel[ItemizeEnvironment]
The @t[ITEMIZE] environment is pretty much like the @t[ENUMERATE]
environment in that it produces a filled and justified list.
The main difference is that the 'paragraphs' (or items) in the list are marked
with a 'bullet' character instead of a number.
Each paragraph (or item) is marked with the same bullet character.
Thus the input:
@begin[verbatim]
@@BEGIN[ITEMIZE]
This is the first item in a short itemised list.

This is the second.
Note that the 'bullet' character remains the same for each item, unlike
the enumerated list described above.

This is the final item in the list.
Note also that although the 'numbering' style is different, the general
appearance of the enumerated and itemised list is similar - the same
margins, the same space above and below the environment and the same
spacing between paragraphs (or items) in the list.
@@END[ITEMIZE]
@end[verbatim]
would produce the following output:
@begin[itemize]
This is the first item in a short itemised list.

This is the second.
Note that the 'bullet' character remains the same for each item, unlike
the enumerated list described above.

This is the final item in the list.
Note also that although the 'numbering' style is different, the general
appearance of the enumerated and itemised list is similar - the same
margins, the same space above and below the environment and the same
spacing between paragraphs (or items) in the list.
@end[itemize]
Well, we've now seen three useful filled environments, enough to be going
on with, so let's have a look at some unfilled environments:
@section[Unfilled Environments]
@mylabel[UnfilledEnvironments]
In printing terminology, the term 'unfilled' means that each line is taken
exactly as it stands, and is rendered into the appropriate typeface without
the lines being filled as much as possible - such an approach also means
that the term 'justified' doesn't really have much significance, though unfilled
lines could in principle be justified - the result would be some pretty
funny looking text though!.

Examples of unfilled text which we come across fairly frequently are poetry,
tables, computer programs etc., and SCRIBE allows us to use various
unfilled environments to achieve the results we require.
Let's have a look at some of them:
@subsection[The @t(FORMAT) Environment]
@mylabel[FormatEnvironment]
This is likely to be the most useful unfilled environment for most users.
It behaves in quite a simple fashion really, that is, each line in the
manuscript file is written to the document file without any
change whatsoever, except that a proportionally spaced font is used in the 
output file.
This means that there is really no concept of a 'paragraph' within the 
@t[FORMAT] environment (or within any of the unfilled environments for that 
matter); blank lines in the input are interpreted according to the convention
outlined above rather than as paragraph separators as would be the case with
a filled environment.

The idea is probably got across best by considering an example - the input:
@begin[verbatim]
@@BEGIN[FORMAT]
This is a sample of the FORMAT environment.
The output is merely an image of the input on a line-for-line basis.

The only departure from this criterion is that
if available, a proportionally spaced
typeface is used.

Additionally, it is important to realise that blank lines are
interpreted as blank lines not as paragraph separators as in
the case of the filled environments.
@@END[FORMAT]
@end[verbatim]
would on output look like this:
@begin[format]
This is a sample of the FORMAT environment.
The output is merely an image of the input on a line-for-line basis.

The only departure from this criterion is that
if available, a proportionally spaced
typeface is used.

Additionally, it is important to realise that blank lines are
interpreted as blank lines not as paragraph separators as in
the case of the filled environments.
@end[format]
@subsection[The @t(VERBATIM) Environment]
@mylabel[VerbatimEnvironment]
The @t[VERBATIM] environment is a little bit like @t[FORMAT], the main
difference being that the output typeface used will be a fixed pitch typeface,
that is, the output more exactly conforms to the idea that the output is an 
exact image of the input.

For example, if we were to use as input, the text:
@begin[verbatim]
@@BEGIN[VERBATIM]
This is a sample of the VERBATIM environment.
The output is merely an image of the input on a line-for-line basis.

Unlike FORMAT however, a fixed pitch
typeface is used.

Again, it is important to remember that blank lines are
interpreted as blank lines not as paragraph separators as in
the case of the filled environments.
@@END[VERBATIM]
@end[verbatim]
the following output would be seen after processing with SCRIBE:
@begin[verbatim]
This is a sample of the VERBATIM environment.
The output is merely an image of the input on a line-for-line basis.

Unlike FORMAT however, a fixed pitch
typeface is used.

Again, it is important to remember that blank lines are
interpreted as blank lines not as paragraph separators as in
the case of the filled environments.
@end[verbatim]
The @t[VERBATIM] environment can be used to set up fairly crude tables, but
there are far better ways of doing this with SCRIBE, these are described in 
detail in lecture @ref[lecture6].
@subsection[The @t(EXAMPLE) Environment]
@mylabel[ExampleEnvironment]
As a final example of the unfilled environment (for the time being),
let's consider the @t[EXAMPLE] environment.

This environment is particularly useful for computing buffs, who quite often
want to include samples of computer input or output in their documents.
It is often desirable to highlight such samples  by indenting them, and this
is exactly what @t[EXAMPLE] does.

Thus, the input:
@begin[verbatim]
@@BEGIN[EXAMPLE]
C     THIS IS A VERY SHORT PROGRAM
C
      PRINT *,'SCRIBE IS GOOD FOR YOU!'
      STOP
      END
@@END[EXAMPLE]
@end[verbatim]
would look like this in the output:
@begin[example]
C     THIS IS A VERY SHORT PROGRAM
C
      PRINT *,'SCRIBE IS GOOD FOR YOU!'
      STOP
      END
@end[example]
So, we've now looked at a few examples of unfilled environments which are
likely to cover most peoples requirements for most of the time.
Let's move on to a 'different' type of environment, namely the heading
environments (actually heading environments are strictly speaking unfilled
environments, but because they have such a well-defined function, they are
given a name which reflects that function).
@subsection[Digression]
@label[Digression1]
Before we do that however, let's just state one of the most important
points about unfilled environments generally.
That is, some environments use a typeface which is different either in detail
(eg: pitch) or overall style from that used as the default for filled text,
@b[but only if such a typeface is available].

This tends to confuse beginners, and the point has not
been stressed until now.
Remember also, that different document types may well have different
typeface settings in the database, and different output devices will almost
certainly have a different range of typefaces available on the target
output device.
The only way to decide which document type/output device suits you is to 
experiment a little - eventually if you decide that nothing satisfies you, you 
may decide to change things to suit yourself - but that comes much later.

In the case where a particular typeface is not available on a given
device, SCRIBE will 'do the best it can' and will produce some sort of useable
output.

Now, let's get back to the heading environments:
@section[Heading Environments]
@label[headingenvironments]
As their name implies, the heading environments are used in SCRIBE to produce
headings (or titles) of varying degrees of prominence in the output.

The heading environments are, as has been stated above unfilled environments
which are grouped together because of their well-defined functionality.
There are three heading environments:
@subsection[The @t(MAJORHEADING) Environment]
@mylabel[MajorHeadingEnvironment]
The @t[MAJORHEADING] environment results in a centred, boldfaced, capitalised
heading, set in a larger typeface than the default one being produced in the
output (but remember the comments made in section @ref[digression1] above).

For example, the input:
@begin[verbatim]
@@MAJORHEADING[The Most Prominent Type of Heading]
@end[verbatim]
would produce as output the line:
@majorheading[The Most Prominent Type of Heading]
Note the fact that we have used the 'short' form of specifying the excursion
into the environment in this case,
This is usual on occasions where only one line will be affected.
Of course, the 'long' form (using @t[@@BEGIN] and @t[@@END]) is still
acceptable.
Note also the fact that SCRIBE places a suitable amount of blank space
above and below the heading in the output in order that it should stand
out well.
SCRIBE will do this automatically, and you do @b[not] need to put blank
lines in your manuscript file to achieve this effect - in fact you are
@b[positively discouraged] from doing so (and this comment applies to
all SCRIBE environments in general)!
@subsection[The @t(HEADING) Environment]
@mylabel[HeadingEnvironment]
The @t[HEADING] environment is pretty much the same as the @t[MAJORHEADING]
environment, except that the title or heading produced is medium-faced (as
opposed to bold), and is produced in the default type size (as opposed to 
a larger one).
Thus a line like:
@begin[verbatim]
@@HEADING[A Slightly Less Prominent Heading]
@end[verbatim]
would produce the output:
@heading[A Slightly Less Prominent Heading]
@subsection[The @t(SUBHEADING) Environment]
@mylabel[SubheadingEnvironment]
The third of the heading environments is @t[SUBHEADING] which produces a
heading which may be mixed case (ie: rendered as typed in the input
file), set at the left hand edge of the page, and which may be
underlined or boldfaced.
Alternatively, it may be capitalised, bold-faced and centred - again,
all this depends upon the document type in use and the fonts available
on the output device in use.

So, the input:
@begin[verbatim]
@@SUBHEADING[The Least Prominent Form of Heading]
@end[verbatim]
would look like this on output:
@subheading[The Least Prominent Form of Heading]
@section[Nesting Environments]
@mylabel[NestingEnvironments]
What do we do if we want (say) a list which is nested - that is a
numbered list, some of whose items are themselves numbered lists.
Well, SCRIBE is smart enough to allow us to 'nest' lists in this way,
and in the case of numbered lists, it will maintain a counter for each
item in each list, and will also number each list in a different style.
Thus, the input:
@begin[verbatim]
@@BEGIN[ENUMERATE]
list 1, item 1

list 1, item 2

list 1, item 3
@@BEGIN[ENUMERATE]
list 2, item 1

list 2, item 2
@@END[ENUMERATE]

list 1 item 4
@@END[ENUMERATE]
@end[verbatim]
would produce the following output:
@begin[enumerate]
list 1, item 1

list 1, item 2

list 1, item 3
@begin[enumerate]
list 2, item 1

list 2, item 2
@end[enumerate] 

list 1 item 4
@end[enumerate]
In general, any SCRIBE environment may be nested within any other SCRIBE
environment, and the depth to which nesting may be carried out is 
arbitrary.
You should be careful however to ensure that the nesting is 'sensible',
for example, it would be a bit silly to nest an itemised list as
part of one of the heading environments which were described in section
@ref[headingenvironments].

You should also notice the different styles of numbering of the nested lists
in the example above.
This is all taken care of by SCRIBE, and the 'numbering' scheme used by
@t[ENUMERATE] (information relating to @t[ITEMIZE] in brackets) is:
first level, an arabic number (a hyphen); second level, a lower case
letter (an asterisk); third level, a lower case Roman number.
After the third (second) level of nesting, the numbering scheme is repeated.
@section[Summary]
@mylabel[Summary2]
We have now seen how to use a few of SCRIBE's text environments; filled ones
(@t[TEXT], @t[ENUMERATE] and @t[ITEMIZE]), unfilled ones (@t[FORMAT],
@t[VERBATIM] and @t[EXAMPLE]) and finally heading environments
(@t[MAJORHEADING], @t[HEADING] and @t[SUBHEADING]).

We also know how to specify excursions into the environments in two
ways, firstly using the 'long' form (that is using the @t[@@BEGIN] and
@t[@@END] instructions), and the 'short' form (that is, using the
@t(@@@b[environmentname][. . . .]) construction).

We've also seen how the use of environments may be nested, which can be
extremely useful - for example when
constructing complicated lists where SCRIBE will take care of any numbering
on your behalf.

So, even if we never learn any more about SCRIBE than we know already,
we are in quite a strong position and can create nicely structured documents
on a variety of different output devices.

Don't leave just yet though, there are lots more goodies to come!

In this section last time, we described the @t[@@BLANKSPACE] instruction
which allowed you to insert some vertical blank space in your documents,
possibly to allow for the insertion of an illustration.

This time, let's consider the case where we want to leave some horizontal
blank space in a document, that is leave some blank space in a line of
our output - perhaps for the pasting in of some quotation in Chinese 
or something along those lines (unfortunately, SCRIBE doesn't speak Chinese!).
This is quite easily achieved by using the @t[@@HSP] instruction which
has the form:
@begin[verbatim]
@@HSP[@b(horizontal distance)]
@end[verbatim]
where @b(horizontal distance) is the relevant distance specified in some
appropriate SCRIBE unit, for example, the text:
@begin[verbatim]
This text demonstrates the use@@HSP[1 INCH]of the horizontal space
instruction.
@end[verbatim]
would produce the following output:
@begin[text, above 1, below 1, indent 2]
This text demonstrates the use@hsp[1 inch]of the horizontal space
instruction.
@end[text]
@section[Practical]
@mylabel[Practical2]
And, for your second practical session, try the following:
@begin[enumerate]
Almost certainly, any document which you are wishing to format 'for real'
in the future will necessitate using some of the text environments
described above.
Try setting up some of those parts of the document using the appropriate
text environment to format them.
If you do not have a suitable text available, merely try using some
of the environments described in the text with the file @t[PRACTICAL1].

At this stage, you could also try changing the target device in your 
@t[@@DEVICE] instruction - try changing it to @t[X2700] so that you can
see how much nicer the output from this device is than that from the line
printer or the Phillips GP300 (if you do this, you should list the output to
device .DP23).
Alternatively, you could change the device to @t[FILE], in order to see how 
easy it is to get a rough draft which is readable at the terminal, (if
you do this, you should just list your output file straight to the
terminal).
@end[enumerate]
@lecture[More Text Environments, Positioning Environments]
@label[lecture3]
We've looked at a few text environments, both filled and unfilled (remember
the heading environments are really just a special case of the unfilled
environment).

SCRIBE has lots more environments which can be quite useful to us.
Let's have a look at some more of them.

We'll take them in the same order as last time, that is filled environments
first, unfilled next, and any 'special' environments last.
@section[Filled Environments]
@mylabel[FilledEnvironments2]
There are really only a couple more filled environments available, these are:
@subsection[The @t(QUOTATION) Environment]
@mylabel[QuotationEnvironment]
The @t[QUOTATION] is intended to be used for exactly what you might
suspect - quotations.

The input:
@begin[verbatim]
@@BEGIN[QUOTATION]
"When everything is moving at once nothing appears to be
moving - as on board ship.
When everyone is moving towards depravity, no-one seems to be moving,
but if some-one stops he shows up the others, who are rushing on, by
acting as a fixed point."
@@END[QUOTATION]
@end[verbatim]
will look like this on output:
@begin[quotation]
"When everything is moving at once nothing appears to be
moving - as on board ship.
When everyone is moving towards depravity, no-one seems to be moving,
but if some-one stops he shows up the others, who are rushing on, by
acting as a fixed point."
@end[quotation]
As you can see, if you wish your quotation marks to appear in the output, you
must put them in yourself.
Really, @t[QUOTATION] is only a slightly different version of @t[TEXT], there
is a little space added above and below the quotation, and the left and right
margins are widened slightly in order to make the quotation stand out
from the surrounding text.
@subsection[The @t(DESCRIPTION) Environment]
@mylabel[DescriptionEnvironment]
The @t[DESCRIPTION] environment is a rather useful addition to the environments
which deal with lists (or the 'itemising' environments as they can also be 
called).
Like @t[ENUMERATE] and @t[ITEMIZE], @t[DESCRIPTION] produces a list in which
each 'paragraph' or item is filled and justified.
The items are marked however not with a number or a 'bullet' character, but
with a first line which is 'outdented'; that is, the first line of each
item sticks out to the left of the body of the text.
The leftmost edge of this first line corresponds to the overall left
margin being used by SCRIBE, and the left margin of the item itself is
moved further to the right than normal.
Thus, the input:
@begin[verbatim]
@@BEGIN[DESCRIPTION]
DESCRIPTION is quite a useful environment, it produces a list in which
the 'numbers' are not really numbers, but a protruding first line which
catches the eye in the same way as a real number or a bullet character.

This environment is basically similar though to the ENUMERATE and
ITEMIZE environments.

Note that the first line of each item is continuous.
When we know a bit more about SCRIBE, we will be able to set up
DESCRIPTION environments so that the first word of each item can be
separated from the rest of the line with some blank space.
This makes the first word even more eye-catching, and DESCRIPTION can
thus be used to create lists in which the 'numbers' are actually words.
Have a look at the SCRIBE Reference Manual @cite[ercc84c] to see what this
looks like.
@@END[DESCRIPTION]
@end[verbatim]
Will, on output be formatted like this:
@begin[description]
DESCRIPTION is quite a useful environment, it produces a list in which
the 'numbers' are not really numbers, but a protruding first line which
catches the eye in the same way as a real number or a bullet character.

This environment is basically similar though to the ENUMERATE and
ITEMIZE environments.

Note that the first line of each item is continuous.
When we know a bit more about SCRIBE, we will be able to set up
DESCRIPTION environments so that the first word of each item can be
separated from the rest of the line with some blank space.
This makes the first word even more eye-catching, and DESCRIPTION can
thus be used to create lists in which the 'numbers' are actually words.
Have a look at the SCRIBE Reference Manual @cite[ercc84c] to see what this
looks like.
@end[description]
@section[Unfilled Environments]
@mylabel[UnfilledEnvironments2]
There are several more unfilled environments which can be quite useful.
Mostly though, they are slightly different 'flavours' of the unfilled
environments we have already seen.
@subsection[The @t(VERSE) Environment]
@mylabel[VerseEnvironment]
The @t[VERSE] environment is suitable for poetry, drama etc. and is really
a little bit similar to @t[FORMAT], except that the left and right margins are
widened a little and, more importantly, where a line of the text is too
long to fit into the available line width, SCRIBE will continue that line
in a new line in the output, which is indented slightly with respect to 
the left margin of the @t[VERSE] environment as a whole.
This is obviously important in the case of poetry where the line structure
must be maintained.
It is probably more accurate to describe the @t[VERSE] environment as
'semi-filled' because of the way it treats these too long lines.
Here's an example:
@begin[verbatim]
@@BEGIN[VERSE]
@comment[The example is a short poem by Christina Rossetti]
A smile because the nights are short!
 And every morning brings such pleasure
Of sweet love-making, harmless sport:
 Love that makes and finds its treasure;
 Love, treasure without measure.

A sigh because the days are long!
 Long long these days that pass in sighing,
A burden saddens every song:
 While time lags which should be flying,
 We live who should be dying.
@@END[VERSE]
@end[verbatim]
would look like this on output:
@begin[verse]
A smile because the nights are short!
 And every morning brings such pleasure
Of sweet love-making, harmless sport:
 Love that makes and finds its treasure;
 Love, treasure without measure.

A sigh because the days are long!
 Long long these days that pass in sighing,
A burden saddens every song:
 While time lags which should be flying,
 We live who should be dying.
@end[verse]
@subsection[The @t(DISPLAY) Environment]
@mylabel[DisplayEnvironment]
The @t[DISPLAY] environment is pretty much the same as the @t[FORMAT]
environment - the only significant difference is that the left and
right margins are widened in the processed text so that it stands
out well.
In practice, this means that the maximum length of line which can be
used with the @t[DISPLAY] environment is less than that which can be
used with the @t[FORMAT] environment.

Thus, if we had:
@begin[verbatim, need 8]
@@BEGIN[DISPLAY]
DISPLAY is a bit like FORMAT.
It uses the usual proportionally spaced typeface,
but the left and right margins are widened.

This means that the available line width is less
when using DISPLAY than when using FORMAT.
@@END[DISPLAY]
@end[verbatim]
in the input, we would see the following in the output:
@begin[display]
DISPLAY is a bit like FORMAT.
It uses the usual proportionally spaced typeface,
but the left and right margins are widened.

This means that the available line width is less
when using DISPLAY than when using FORMAT.
@end[display]
@subsection[The @t(PROGRAMEXAMPLE) Environment]
@mylabel[ProgramExampleEnvironment]
@t[PROGRAMEXAMPLE] is exactly similar to @t[EXAMPLE] except that a fixed
width typeface other than the default style is used if one is available.
This makes @t[PROGRAMEXAMPLE] useful for computing buffs who often wish
to include sample of computer input and output in their documents,
and wish to have it look as if it had been produced on a computer
terminal.

So the input:
@begin[verbatim]
@@BEGIN[PROGRAMEXAMPLE]
C     THIS IS A VERY SHORT PROGRAM
C
      PRINT *,'SCRIBE IS STILL GOOD FOR YOU!'
      STOP
      END
@@END[PROGRAMEXAMPLE]
@end[verbatim]
would look like this in the output:
@begin[programexample]
C     THIS IS A VERY SHORT PROGRAM
C
      PRINT *,'SCRIBE IS STILL GOOD FOR YOU!'
      STOP
      END
@end[programexample]
The point made in section @ref[Digression1] is illustrated here - we said that
@t[EXAMPLE] and @t[PROGRAMEXAMPLE] were exactly the same except that different
fixed width typefaces were used.
The output from the two environments illustrated in these notes uses the same
typeface however.
This reflects the fact that the laser printer has only one fixed width typeface
available, not that SCRIBE is doing something wrong - if we had used the 
Phillips GP300 printer for these notes, we would have seen two different
typefaces in these examples, as the GP300 does in fact have more than
one fixed width typeface.
@section[Positioning Environments]
@mylabel[PositioningEnvironments]
The final group of SCRIBE environments which we are going to consider in
any detail, is another group of unfilled environments which fulfill a
fairly definte purpose, and which are assigned a special name
accordingly.
These are the positioning environments, and they allow you to place text 
at the right, centre or left of a the line on a line-by-line basis.

@subsection[The @t(FLUSHRIGHT) Environment]
@mylabel[FlushrightEnvironment]
The @t[FLUSHRIGHT] environment flushes each line of text in the input hard
against the right hand end of the available line width.
That is, the output is 'right justified' rather than 'left and right justified'
as with normal filled text, or 'left justified' as with 'filled' text.
The easiest way to see what happens is to consider an example - the input:
@begin[verbatim]
@@BEGIN[FLUSHRIGHT]
FLUSHRIGHT is an unfilled environment.
It differs from other unfilled environments in that
each line of text is forced against the right 
margin in the output.

FLUSHRIGHT is one of the 'positioning' environments.
@@END[FLUSHRIGHT]
@end[verbatim]
Would on output look like this:
@begin[flushright]
FLUSHRIGHT is an unfilled environment.
It differs from other unfilled environments in that
each line of text is forced against the right 
margin in the output.

FLUSHRIGHT is one of the 'positioning' environments.
@end[flushright]
@subsection[The @t(CENTRE) Environment]
@mylabel[CentreEnvironment]
The @t[CENTRE] environment takes each line of text in the input and centres
it on a line-by-line basis in the output, so the input:
@begin[verbatim]
@@BEGIN[CENTRE]
CENTRE is an unfilled environment.
It differs from other unfilled environments in that
each line of text is centred in the output file.

CENTRE is another of the 'positioning' environments.
@@END[CENTRE]
@end[verbatim]
Would on output look like this:
@begin[centre]
CENTRE is an unfilled environment.
It differs from other unfilled environments in that
each line of text is centred in the output file.

CENTRE is another of the 'positioning' environments.
@end[centre]
@subsection[The @t(FLUSHLEFT) Environment]
@mylabel[FlushleftEnvironment]
The @t[FLUSHLEFT] environment takes each line of text in the input and flushes
it to the left hand end of the line on a line-by-line basis in the output,
so the input:
@begin[verbatim, need 8]
@@BEGIN[FLUSHLEFT]
FLUSHLEFT is an unfilled environment.
Each line in the input is positioned
at the left hand end of the line in the output.

It is exactly the same as the FORMAT environment
and is provided so that the three 'positioning'
environments form a complete group.
@@END[FLUSHLEFT]
@end[verbatim]
Would on output look like this:
@begin[flushleft]
FLUSHLEFT is an unfilled environment.
Each line in the input is positioned
at the left hand end of the line in the output.

It is exactly the same as the FORMAT environment
and is provided so that the three 'positioning'
environments form a complete group.
@end[flushleft]
@section[Summary]
@mylabel[Summary3]
This lecture has been largely a case of consolidating what we already
knew by describing more of the same sort of thing - text environments.

We have now added more filled (@t[QUOTATION] and @t[DESCRIPTION]) and
unfilled (@t[VERSE], @t[DISPLAY] and @t[PROGRAMEXAMPLE]) environments to
our repertoire, and have been introduced to the 'positioning'
environments (@t[FLUSHLEFT], @t[CENTRE] and @t[FLUSHRIGHT]).

Continuing the theme of briefly introducing a new SCRIBE instruction
in each of the summaries - how do we force SCRIBE to move to the top
of a new page?
This is often necessary (for example, if we want a heading to appear at
the top of a page), and can be done quite simply by using the
@t[@@NEWPAGE] instruction, which when encountered simply moves the
output pointer immediately to the top of the next page.

The @t(@@BLANKPAGE[@b<n>]) instruction behaves slightly differently, this
instruction will continue processing until the current output page is full,
and then leave @b[n] blank pages (so obviously, @b[n]>0).
@section[Practical]
@mylabel[Practical3]
For your next practical, you should try consolidating what you have learnt so
far.

This might mean using some of the new text environments in your own
document(s), or merely reproducing the examples in the notes in order
to convince yourself that the environments do actually work as
advertised.

Whichever you do, ensure that you know which device type you are using, and
that your output is listed on an appropriate printer on the network.
@lecture[Document Types, Sectioning and Indexing]
@mylabel[lecture4]
@section[Document Types and the @t(@@MAKE) Instruction]
@label[DocumentTypes]
We talked briefly about document types way back in lecture @ref[lecture1],
and we also pointed out that the names of SCRIBE's default document type and
text environment were the same (@t[TEXT]) in lecture @ref[lecture2].
This latter fact need not cause any confusion, particularly after we have
discussed the @t[TEXT] environment in the context of other environments 
(lectures @ref[lecture2] & @ref[lecture3]), and the @t[TEXT] document type
in the context of other document types.

When we prepare an input file for SCRIBE it is usual to select an appropriate
document type.
This is done with the @t[@@MAKE] instruction  which was also discussed
in lecture @ref[lecture1].
Let's describe the @t[@@MAKE] instruction in a bit more detail, it has the
general form:
@begin[verbatim]
@@MAKE[@b(documenttype)]
@end[verbatim]
where @b[documenttype] is SCRIBEs name for the type of document which is to
be prepared.

The @t[@@MAKE] instruction if used may only be used once - fairly obviously,
we can only make one document type at a time, and must come at the start of
the manuscript file, that is, before any of the text which is to be
processed.
For example:
@begin[verbatim]
@@MAKE[TEXT]
@@MAKE[MANUAL]
@end[verbatim]
These document types fall into two groups - the unsectioned documents, and
the sectioned documents.
Let's take a closer look at them:
@section[Unsectioned Documents]
@mylabel[UnsectionedDocuments]
There are two unsectioned document types:
@subsection[The @t(TEXT) Document Type]
@mylabel[TextDocumentType]
@t[TEXT] is SCRIBE's default document type, and results in the output
document being formatted as follows:
@begin[itemise, spread 0]
filled & justified

paginated with the page number at the top centre

paragraphs with first line indented

proportionally spaced typeface (if available on the device)
@end[itemise]
and there isn't really much more to say about it than that.
@subsection[The @t(LETTER) Document Type]
@mylabel[LetterDocumentType]
@t[LETTER] is more interesting than @t[TEXT].
It allows you to prepare (personal) letters, and has several special
environments associated with it, these include:
@begin[description, spread 0, leftmargin 1.5 inches, indent -1.5 inches]
@t[RETURNADDRESS]@\an unfilled environment used for the address of the sender

@t[ADDRESS]@\an unfilled environment used for the address of the addressee
- similar to @t[FLUSHLEFT]

@t[GREETING]@\A SCRIBE environment which requires the name of the addresse
as its text, and which produces a greeting of the form 'Dear . . . .' in
the output.

@t[BODY]@\a filled environment used for the text of the letter itself
- similar to @t[TEXT]

@t[CLOSINGS]@\A SCRIBE environment which needs the name of the sender as its 
text, and which produces a closing of the form 'Yours Sincerely . . . .' in
the output.
@end[description]
There are other environments associated with @t[LETTER], but those described
above are likely to be the most useful - they are also listed in the order in
which they are most likely to be used in a letter.
@section[Sectioned Documents]
@mylabel[SectionedDocuments]
The sectioned documents are the most interesting and versatile of the
two groups of document types.
They enable you to set up large documents which may be broken down into
chapters, sections, subsections, appendixes etc.
The important point about the sectioned document types is that they are all
capable of producing a table of contents, and all sections are numbered
automatically by SCRIBE.
The sections themselves are set up using special sectioning instructions which 
are described in detail in section @ref[SectioningInstructions] below.
Let's have a look at the different sectioned documents first though:
@subsection[The @t(ARTICLE) Document Type]
@mylabel[ArticleDocumentType]
Using the document type @t[ARTICLE] in your @t[@@MAKE] instruction allows you
to set up a document which contains numbered sections, subsections, paragraphs,
and appendixes; and, unnumbered sections and prefaces.
A table of contents will be automatically generated and stored at the end of the
output file and will be printed when the document is printed.
This can then be used or not as required.
@subsection[The @t(REPORT) Document Type]
@mylabel[ReportDocumentType]
The document type @t[REPORT] is exactly the same as @t[ARTICLE], except that
numbered chapters are allowed.
These occupy a position in the numbering heirarchy immediately above the
numbered section.
@subsection[The @t(MANUAL) Document Type]
@mylabel[ManualDocumentType]
@t[MANUAL] is exactly the same as @t[REPORT] except that indexing facilities
are available.

to give an idea of what a sectioned document looks like, it's probably
worth mentioning that these notes are set up using a 'private'
document type called @t[NOTES], which is pretty much the same as
document type @t[MANUAL].
@section[Sectioning Instructions]
@label[SectioningInstructions]
Well, we've talked fairly glibly about the sectioning instructions used with
sectioned document types without saying anything very much about them.
Let's have a look at them in some more detail.

Note that in the following examples, no output is shown - this is because every
time this was done, a new section would be generated. 
Instead, I have given examples of input only, and, where possible, the example
reflects one of the sections in these notes.
@subsection[The @t(@@CHAPTER) Instruction]
@mylabel[ChapterInstruction]
The @t[@@CHAPTER] instruction is the most 'senior' of the sectioning
instructions.
It has the general form:
@begin[verbatim]
@@CHAPTER[@b(title)]
@end[verbatim]
where @b[title] is the title of the chapter concerned, for example:
@begin[verbatim]
@@CHAPTER[Document Types and Sectioning Instructions]
@end[verbatim]
The output from such an instruction would look a bit like the lecture
titles in these notes, except that the word 'CHAPTER' instead of
'LECTURE' would be used.
@subsection[The @t(@@SECTION) Instruction]
@mylabel[SectionInstruction]
The @t[@@SECTION] instruction is at the second level in SCRIBE's sectioning
heirarchy, and has the form:
@begin[verbatim]
@@SECTION[@b(title)]
@end[verbatim]
where @b[title] is the title of the section concerned, eg:
@begin[verbatim]
@@SECTION[Sectioned Documents]
@end[verbatim]
Look at the layout of the title of this section if you want to see what
effect the  @t[@@SECTION] instruction has in the output document.
@subsection[The @t(@@SUBSECTION) Instruction]
@mylabel[SubsectionInstruction]
The @t[@@SUBSECTION] instruction is at the third level in SCRIBE's sectioning
heirarchy, and has the form:
@begin[verbatim]
@@SUBSECTION[@b(title)]
@end[verbatim]
where @b[title] is the title of the sub-section concerned, eg:
@begin[verbatim]
@@SUBSECTION[The @@SUBSECTION Instruction]
@end[verbatim]
Look at the layout of the title of this sub-section if you want to see
what effect the @t[@@SUBSECTION] instruction has in the output document.
@subsection[The @t(@@PARAGRAPH) Instruction]
@mylabel[ParagraphInstruction]
The @t[@@PARAGRAPH] instruction is at the fourth level in SCRIBE's sectioning
heirarchy, and has the form:
@begin[verbatim]
@@PARAGRAPH[@b(title)]
@end[verbatim]
where @b[title] is the title of the paragraph concerned, eg:
@begin[verbatim]
@@PARAGRAPH[The @@PARAGRAPH Instruction]
@end[verbatim]
These notes don't use paragraphs, but the title output by a @t[@@PARAGRAPH]
instruction will look a bit like the title of this sub-section - the main
difference being that the numbering will be carried one level deeper.
@subsection[The @t(@@APPENDIX) Instruction]
@mylabel[AppendixInstruction]
The @t[@@APPENDIX] instruction is the most 'senior' of the two sectioning
instructions devoted to appendixes.
It has the general form:
@begin[verbatim]
@@APPENDIX[@b(title)]
@end[verbatim]
where @b[title] is the title of the appendix concerned, for example:
@begin[verbatim]
@@APPENDIX[Extensions to the SCRIBE Command]
@end[verbatim]
The output from such an instruction would look a bit like the main headings
of these notes, except that the text 'APPENDIX' instead of 'LECTURE' would
appear as the first line, and the arabic numbering style is replaced
with roman numbering.
@subsection[The @t(@@APPENDIXSECTION) Instruction]
@mylabel[AppendixsectionInstruction]
The @t[@@APPENDIXSECTION] instruction is the second of the two sectioning
instructions devoted two appendixes and bears the same relation to @t[@@APPENDIX]
 as @t[@@SECTION] does to @t[@@CHAPTER] (or @t[@@SUBSECTION] to @t[@@SECTION] in 
 document type @t[ARTICLE]).
It has the general form:
@begin[verbatim]
@@APPENDIXSECTION[@b(title)]
@end[verbatim]
where @b[title] is the title of the appendix concerned, for example:
@begin[verbatim]
@@APPENDIXSECTION[Specification of Output Device at Run Time]
@end[verbatim]
The output from such an instruction would look a bit like the section headings
in these notes except that the numbering will be roman instead of arabic.
@subsection[The @t(@@UNNUMBERED) Instruction]
@mylabel[UnnumberedInstruction]
The @t[@@UNNUMBERED] instruction produces an unnumbered section title, and 
has the form:
@begin[verbatim]
@@UNNUMBERED[@b(title)]
@end[verbatim]
where @b[title] is the title of the section concerned.
Unlike the titles produced by the heading environments (see section
@ref[headingenvironments]), the title produced by an @t[@@UNNUMBERED]
instruction will appear in the table of contents, eg:
@begin[verbatim]
@@UNNUMBERED[References and Further Reading]
@end[verbatim]
Look at the title of the References section at the end of these notes to see
what sort of title the @t[@@UNNUMBERED] instruction produces.
@subsection[The @t(@@PREFACESECTION) Instruction]
@mylabel[PrefacesectionInstruction]
The @t[@@PREFACESECTION] instruction is used for prefaces, introductions,
forewords etc. which are part of a document but which may exist 'outside'
the normal section numbering scheme.
It has the form:
@begin[verbatim]
@@PREFACESECTION[Preamble]
@end[verbatim]
To see what sort of title the @t[@@PREFACESECTION] produces, look at the
introduction to these notes.

Remember that titles generated by @t[@@PREFACESECTION] will appear in the
table of contents as well.
@section[Indexing Instructions]
@mylabel[IndexingInstructions]
SCRIBE has five indexing instructions available, which may be used to produce
sorted indexes of varying degrees of complexity when using the
appropriate document type (@t[MANUAL]).

Index entries are generated by providing the text to be indexed as the
argument to one or other of the indexing instructions.

The index is generated automatically when the manuscript file is processed
by SCRIBE.
@subsection[The @t(@@INDEX) Instruction]
@mylabel[IndexInstruction]
The simplest of the indexing instructions available within SCRIBE is the 
@t[@@INDEX] instruction - it has the form:
@begin[verbatim]
@@INDEX[@b(text to be indexed)]
@end[verbatim]
where @b[text to be indexed] will form the entry which actually appears in the
index, eg:
@begin[verbatim]
@@INDEX[Index instruction]
@index[Index instruction]
@end[verbatim]
It's a bit difficult to include the output from an indexing instruction
in the body of the notes, so if you want to see the effect of the
@t[@@INDEX] instruction (and all the other indexing instructions), turn
to the short index at the end of these notes.
@subsection[The @t(@@INDEXSECONDARY) Instruction]
@mylabel[IndexsecondaryInstruction]
The @t[@@INDEXSECONDARY] instruction enables two-level indexes to be constructed,
that is, a main index entry can be created with a secondary index subordinate
to it.
The @t[@@INDEXSECONDARY] instruction has the form:
@begin[verbatim]
@@INDEXSECONDARY[PRIMARY="@b(primaryentry),SECONDARY="@b(secondaryentry)"]
@end[verbatim]
where @b[primaryentry] and @b[secondaryentry] are respectively the text
of the main and subordinate entries, eg:
@begin[verbatim]
@@INDEXSECONDARY[PRIMARY="Indexing instructions",
 SECONDARY="Indexsecondary instruction"]
@indexsecondary[primary="Indexing instructions",secondary="Indexsecondary instruction"]
@end[verbatim]
Notice that if necessary, a SCRIBE instruction which is too long to fit
onto one line may be continued on the next line as illustrated in the 
example immediately above.
@subsection[The @t(@@SEEALSO) Instruction]
@mylabel[SeealsoInstruction]
The @t[@@SEEALSO] instruction allows cross-references of the "See also ..."
type to be made within the index, the form is:
@begin[verbatim]
@@SEEALSO[PRIMARY="@b(primaryentry)",OTHER="@b(otherentry)"]
@end[verbatim]
where @b[primaryentry] is the primary index entry, and @b[otherentry] is the
index entry referred to, eg:
@begin[verbatim]
@@SEEALSO[PRIMARY="Seealso instruction",OTHER="Indexing instructions"]
@indexsecondary[primary="Indexing instructions",secondary="Seealso instruction"]
@index[Seealso instruction]
@seealso[primary="Seealso instruction", other="Indexing instructions"]
@end[verbatim]
@subsection[The @t(@@INDEXMAIN) Instruction]
@mylabel[IndexmainInstruction]
The @t[@@INDEXMAIN] instruction has exactly the same form and effect as
the @t[@@INDEX] instruction, except that a boldface page number is
printed - this is useful for highlighting the major index entry for an
item when there are several entries.
For example:
@begin[verbatim]
@@INDEXMAIN[Indexmain instruction]
@indexmain[Indexmain instruction]
@end[verbatim]
@subsection[The @t(@@INDEXSECONDARYMAIN) Instruction]
@mylabel[IndexsecondarymainInstruction]
The @t[@@INDEXSECONDARYMAIN] instruction has exactly the same form and
effect as the @t[@@INDEXMAIN] instruction, except that a boldface page
number is printed - this is useful for highlighting the major index
entry for an item when there are several entries.
For example:
@begin[verbatim]
@@INDEXSECONDARYMAIN[PRIMARY="Indexing instructions",
 SECONDARY="Indexsecondarymain instruction"]
@indexsecondarymain[primary="Indexing instructions", secondary="Indexsecondarymain instruction"]
@end[verbatim]
@section[Contents Page and Index Generation]
@mylabel[ContentsPage]
Let's just make a few points about Contents pages and indexes:

@begin[enumerate]
contents pages are only generated when sectioning instructions are used.

sectioning instructions may only be used with sectioned document types.

a slightly different sub-set of sectioning instructions is available
for different sectioned document types

contents pages are generated automatically when using sectioned document
types - if you don't want them - throw them away (but see the next point).

there is no obligation to use any of the sectioning instructions in a
sectioned document, but if you don't, a table of contents will not be
generated.

indexing instructions may only be used in document type @t[MANUAL].

indexes are generated and sorted alphabetically - this process is
automatic, and cannot be stopped.

there is no obligation to use the indexing facilities, even if the 
document type @t[MANUAL] is being used.
@end[enumerate]
@section[Summary]
@mylabel[Summary4]
In the fourth lecture we have talked a bit more about selecting different
output devices using the @t[@@MAKE] instruction - not much to say about 
this really - it's all fairly simple.

The important part of the lecture was the introduction of the idea of document
types, and the opening up of the possibility of using SCRIBE's sectioning
instructions in a way which lets SCRIBE do the 'organising' for us.

Also important was the introduction of the idea of the indexing facilities.

To recap, we talked about several document types; the unsectioned document
types (@t[TEXT] and @t[LETTER]) and the sectioned document types
(@t[ARTICLE], @t[REPORT] and @t[MANUAL]).

The sectioning instructions we discussed were @t[@@CHAPTER], @t[@@SECTION],
@t[@@SUBSECTION], @t[@@PARAGRAPH], @t[@@APPENDIX], @t[@@APPENDIXSECTION]
(all numbered) and @t[@@UNNUMBERED] and @t[@@PREFACESECTION] (both unnumbered).
Remember that the @t[@@CHAPTER] instruction cannot be used in document type
@t[ARTICLE] and that numbering for appendixes is roman not arabic.
Remember also that there is no obligation to use the sectioning instructions
even if you are using a sectioned document type.
If you do use the sectioning instructions, a contents page will be
generated automatically by SCRIBE.


The final part of the lecture dealt with the indexing instructions.
There are five of these (@t[@@INDEX], @t[@@INDEXSECONDARY], @t[@@SEEALSO],
@t[@@INDEXSECONDARY] and @t[@@INDEXSECONDARYMAIN]).
Indexing instructions may only be used with document type @t[MANUAL] and
the index will be generated and sorted by SCRIBE at the end of its processing.
remember though that if you want an index, the onus is on you to insert
the appropriate indexing instructions.

It is often useful to be able to incorporate additional comments in any
manuscript which are not processed by SCRIBE and do not appear in the
final document. 
There are many reasons why this might be useful, for example listing the
exact source of a quotation rather than just the name of the author, the
text of part of a document which is not yet to be made public (planning
ahead!), etc.
Such insertions are made with the @t[@@COMMENT] instruction which has the
form @t(@@COMMENT[@b<text of comment>]) - the bracketed text (which may
extend over as many lines as necessary) will not appear in the processed
document.
@section[Practical]
@mylabel[Practical4]
Well, there's quite a lot in the last lecture and probably the quickest
way to try all of it out is to set up a 'dummy' document.
Try to set up a sectioned document which has an index, a contents page
and makes use of as many of the sectioning instructions as possible.
Just set up the 'skeleton' of the document, that is, a section title and
an index entry for each section.

Obviously, if you have a real document which you wish to format which has
to be set up using sections and which will need a contents page and an
index, now is the time to set up the skeleton of the document - such a
skeleton, when printed off is a useful planning aid - you can 'fill in
the blanks' later in your own time (and using your own process!).
@lecture[String and Counter Handling, Cross Referencing]
@label[lecture5]
@section[Strings and String Handling]
@mylabel[StringsAndStringHandling]
In computing terms, a 'string' is just a sequence of characters, and for our
purposes, we will take this to mean printing characters.
A string can consist of one or many characters, and in the text-processing
context it is the lengthy strings we are interested in.
Suppose for example the word 'antidisestablismentarianism' was to occur
many times in a document we were preparing.
Apart from the likelihood of typing errors creeping in every time the word is
typed, there is the simple fact that the word is a bit of a bore to type in
any case.

It would be nice if SCRIBE would let us define some sort of 'abbreviation'
for such a long word (or more commonly, phrase consisting of several
words), and also provide a mechanism for referring to the word (or phrase)
by its abbreviation in the input file, but replacing it with the full form
in the output.

Well, obviously SCRIBE does have such a facility, otherwise we wouldn't be 
wasting everybody's time talking about it like this.

Let's look at the way SCRIBE enables us to set up this sort of thing:
@subsection[Defining Strings - The @T(@@STRING) Instruction]
@label[StringInstruction]
In order to set up the text strings discussed above, we must use the
@t[@@STRING] instruction - this has the form:
@begin[verbatim]
@@STRING[@b(codeword)="@b(value)"]
@end[verbatim]
where @b[codeword] is the abbreviated 'name' by which the text string is
known, and @b[value] is the text string itself.
Thus:
@begin[verbatim]
@@STRING[ERCC="Edinburgh Regional Computing Centre"]
@end[verbatim]
defines a string whose 'name' is @t[ERCC] and whose value is @t[Edinburgh
Regional Computing Centre].
Note that the quotation marks (@t["]) are @b[not] part of the string,
but serve to define its limits.

As many strings as required may be set up in this way, and their length may be
quite considerable - the default length for a text string defined in this way
is 1024 characters (including spaces) - which is very roughly 10-15 lines of
text.
@subsection[Referencing Strings - The @t(@@VALUE) Instruction]
@mylabel[ValueInstruction]
Well, we've seen how to define a text string using the @t[@@STRING]
instruction, but how do we get at it in order to include its value
rather than its name in the output?
To do this, we use the @t[@@VALUE] instruction which has the form:
@begin[verbatim]
@@VALUE[@b(codeword)]
@end[verbatim]
where @b[codeword] has the same meaning as before.

For example:
@begin[verbatim]
@@VALUE[ERCC]
@end[verbatim]
@subsection[Defining and Referencing Strings - The Result]
@mylabel[DefiningAndReferencingStrings]
So, we now know how to define and reference text strings.
How are the two put together in the SCRIBE manuscript file in order to
produce the required effect in the output file.
This should become clear if the input below is considered in conjunction
with the immediately following output which would result when such input
was processed.

The input:
@begin[verbatim]
@@STRING[ERCC="Edinburgh Regional Computing Centre"]
The SCRIBE course is only one of a wide range of courses offered by the
Training Group at @@VALUE[ERCC].
@end[verbatim]
The output:
@begin[text, above 1, spacing 1, indent 2]
@string[ercc="Edinburgh Regional Computing Centre"]
The SCRIBE course is only one of a wide range of courses offered by the
Training Group at @value[ercc].
@end[text]
@subsection[Predefined Strings]
@mylabel[PredefinedStrings]
In addition to the strings which may be defined with the @t[@@STRING]
instruction, SCRIBE has built in to it a certain number of 'predefined'
strings.
These predefined strings have all been assigned a name corresponding to
@b[codeword] (see section @ref[stringinstruction] above).
These names are reserved for the predefined strings, and may not be
used for setting up user defined strings.

The predefined strings and their effects are listed below:
@begin[description, leftmargin 14, indent -14, spread 0]
@t[DATE]@\the date

@t[DAY]@\the day of month

@t[DEVICENAME]@\the target output device for the current SCRIBE run

@comment<@t[FILEDATE]@\not used
>
@t[MANUSCRIPT]@\the name of the manuscript file being processed

@t[MONTH]@\the name of the month

@t[PAGE]@\the current document file page number

@comment<@t[ROOTFILEDATE]@\not used
>
@t[SCRIBEVERSION]@\the version number of the SCRIBE program being used for the
current run

@t[SECTIONNUMBER]@\the number of the current section

@t[SECTIONTITLE]@\the title of the current section

@t[SITE]@\the name of the site running SCRIBE

@comment<@t[SOURCEFILE]@\not used
>
@t[TIME]@\the time of day

@t[TIMESTAMP]@\the current time

@t[USERNAME]@\the user process from which the current job is being processed

@t[WEEKDAY]@\the name of the day of the week

@t[YEAR]@\the year number (last two digits only)
@end[description]
The use of the predefined strings is probably best illustrated with an example.
Consider the input:
@begin[verbatim]
These notes describe the use of SCRIBE version @@VALUE[SCRIBEVERSION]
and have been prepared for use with the SCRIBE course presented by
@@VALUE[SITE].

The notes were prepared on @@VALUE[DATE] (or if you prefer the date in
an alternative form; @@VALUE[DAY] @@VALUE[MONTH] @@VALUE[YEAR] which was
a @@VALUE[WEEKDAY]).

The run of SCRIBE which was used to produce the output file was started
at @@VALUE[TIME].
The target output device is @@VALUE[DEVICENAME], and the date and time
at which the run was started can be combined using the TIMESTAMP string
- @@VALUE[TIMESTAMP].

The manuscript file for these notes is called
@@VALUE[MANUSCRIPT] and is stored on the user process @@VALUE[USERNAME].

At this point in time, the job is producing page @@VALUE[PAGE] of the
output file; the current section number is @@VALUE[SECTIONNUMBER], and
the current section title is "@@VALUE[SECTIONTITLE]".
@end[verbatim]
which would produce the following output:
@begin[text, above 1, below 1, indent 2]
These notes describe the use of SCRIBE version @value[scribeversion]
and have been prepared for use with the SCRIBE course presented by
@value[site].

The notes were prepared on @value[date] (or if you prefer the date in
an alternative form; @value[day] @value[month] @value[year] which was
a @value[weekday]).

The run of SCRIBE which was used to produce the output file was started
at @value[time].
The target output device is @value[devicename], and the date and time
at which the run was started can be combined using the TIMESTAMP string
- @value[timestamp].

The manuscript file for these notes is called
@value[manuscript] and is stored on the user process @value[username].

At this point in time, the job is producing page @value[page] of the
output file; the current section number is @value[sectionnumber], and
the current section title is "@value[sectiontitle]".
@end[text]
@section[Counters and Counter Handling]
@mylabel[CountersAndCounterHandling]
SCRIBE has available to it a number of 'counters' which are used to
maintain correct numbering of pages, chapters, sections, subsections
etc.
Every time a page, chapter, section, subsection, etc., is started, the
appropriate counter is incremented by 1 and the result is used to number
the page, chapter section, subsection etc.

Under certain circumstances, it may be desirable to be able to forcibly
change the value of one of these counters - for example, if a large
(greater than 50 pages) document is being prepared, it may be sensible
to split the document down into several manuscript files, each of which
is processed separately.
Obviously, the first page of the second part must follow on directly
from the last page of the first part etc. otherwise the whole idea of
page numbering falls apart.
As things stand, if each part of the document is processed separately,
the resulting document files will all start their page numbering at 1.

Now this is probably fine while working on drafts of the various parts
of the document, but when the final copy is being prepared, the page
numbering must be correct.
This is ensured by forcing the first page of each section of the
document (except the first one) to be the same as the last page of the
preceding section (the reason for this will be explained shortly).

This is done using the @t[@@SET] instruction which is now described:
@subsection[Setting Counters - The @t(@@SET) Instruction]
@mylabel[SetInstruction]
The @t[@@SET] instruction has the form:
@begin[verbatim]
@@SET[@b(counter)=@b(value)]
@end[verbatim]
where @b[counter] is the name of the counter whose value is being set, 
and @b[value] is a number which may be expressed in unsigned or signed
terms (eg: 10, -10, +10), and whose sign and value control the final
value of the counter concerned.
If it is unsigned, the value of the counter is set to @b[value], if
negative it is decremented (decreased) by @b[value]; if positive it is
increased by @b[value].
For example:
@begin[verbatim]
@@SET[PAGE=+100]
@set[page=+100]
@end[verbatim]
We can't show the result of such an instruction in the body of the text,
but look at the page number of the next page (not this one) in order to
see the effect of the @t[@@SET] instruction.

The explanation for the slightly odd effect of the @t[@@SET] instruction
is that when the @t[@@SET] instruction is encountered, the current page
number has been processed.
It is only when a new page is taken, and the page number incremented by
one that the effect of the @t[@@SET] instruction becomes apparent.

We have used the page number as the vehicle for a fairly detailed
explanation of how to use the @t[@@SET] instruction, and what actually
happens when we do.
The same general principle applies whichever of the SCRIBE counters are
being changed.

This is important, because in the general case, if we are dealing with a
document which is large enough to require processing as separate
manuscript files, each of which needs its page numbering setting at the
start, it is quite likely that the document will be large enough to be
divided into chapters or sections etc. and these will need setting
orrectly at the start of each manuscript file as well as the page number
(and in fact, if you are setting up a large document, the obvious point
at which to split the document down into its constituent parts is at the
chapter or section boundaries!).

As an example of this, and to drive home the point, let's reset the value of
the next section:
@begin[verbatim]
@@SET[SUBSECTION=+10]
@set[subsection=+10]
@end[verbatim]
Have a look at the number of the next subsection, and you will see that
the subsection part of the number is 10 greater than it should be.
@subsection[Using Counters - the @t(@@REF) Instruction]
@label[usingcounters]
If we want to refer to the value of a counter in the text, we can use
the @t[@@REF] instruction which has the general form:
@begin[verbatim]
@@REF[@b(counter)]
@end[verbatim]
where @b(counter) is the name of the SCRIBE counter concerned, for
example the text:
@begin[verbatim]
This text is intended to illustrate the use of the @@REF instruction to
access section numbers and replace the @@REF instruction in the document
file with the current value of whichever counter is being used.
Thus, this example is to be found in lecture @@REF[LECTURE], the section
is @@REF[SECTION], and the Subsection is @@REF[SUBSECTION].
@end[verbatim]
if encountered in the manuscript file, would produce the following
result in the document file:
@begin[text, above 1, below 1, indent 2]
This text is intended to illustrate the use of the @@REF instruction to
pick up section numbers and replace the @@REF instruction in the
document file with the current value of whichever counter is being used.
Thus, this example is to be found in lecture @REF[LECTURE], the section
is @REF[SECTION], and the Subsection is @REF[SUBSECTION].
@end[text]
Thus, use of the @@REF instruction enables us to pick up the numerical
value of the current chapter (or lecture in the case of these notes),
section, subsection etc. which is a useful if limited cross-referencing
facility.
The usefulness is limited by the fact that the @@REF instruction used
with counters as described, only allows us to pick up the current value
of a counter, and does not allow us to make cross references to other
parts of a document.
There are ways of doing this however, and they will be discussed in some
detail in lecture @ref[lecture6].

Finally, before leaving the discussion of strings and counters, let's
just set the value of the page number and subsection back to their
proper values.
@begin[verbatim]
@@SET[PAGE=-100]
@@SET[SUBSECTION=-10]
@set[page=-100]
@set[subsection=-10]
@end[verbatim]
Remember though, that these two instructions will not take effect until the
next page is taken and the next section started.
@section[Cross Referencing]
@mylabel[crossreferencing]
We have already seen how crude cross-referencing may be achieved 
using the @t[@@REF] instruction to pick up section numbers (see
section @ref[usingcounters] above).
this is extremely restricted however in that as soon as a new
section is entered, the value returned by @t[@@REF] changes.
In other words, we can only make cross-references to sections within
the current @t[SECTION] (or @t[CHAPTER] in the case of @t[MANUAL]
documents).
This is fairly obviously so restricting as to be almost useless, so
SCRIBE has more sophisticated facilities which allow forward and
backward cross-references to be made to any section within a 
document.

The mechanism by which this is done is briefly as follows.

The point to which a reference is to be made is labelled with an
@t[@@LABEL] instruction.
At the point at which the reference is to be made, the
section number or page number of the point to be referred to is
recalled with either an @t[@@REF] or a @t[PAGEREF] instruction.
Let's have a look at these instructions:
@subsection[The @t(@@LABEL) Instruction]
@mylabel[LabelInstruction]
The @t[@@LABEL] instruction is used to mark points in the manuscript
file to which reference is to be made from elsewhere in the document.
It has the form:
@begin[verbatim]
@@LABEL[@b(codeword)]
@end[verbatim]
where @b[codeword] is a unique string of upto 31 characters which 
identifies the point in the manuscript file to which reference is to
be made, eg:
@begin[verbatim]
@@LABEL[THELABELINSTRUCTION]
@label[thelabelinstruction]
@end[verbatim]
@subsection[The @t(@@REF) Instruction]
@mylabel[refinstruction]
When a reference is to be made to a labelled point in the text, this is
done using a slightly different (and more useful!) form of the @t[@@REF]
instruction which has the form:
@begin[verbatim]
@@REF[@b(codeword)]
@end[verbatim]
where @b[codeword] is the label of the point in the text which is to be
referred to, eg:
@begin[verbatim]
@@REF[THEREFINSTRUCTION]
@end[verbatim]
@subsection[How Does it Work?]
@mylabel[howdoesitwork]
When a @t[@@REF] instruction is encountered in the manuscript file,
SCRIBE notes the codeword associated with the @t[@@REF] instruction
and replaces it with the section number of the section in which the
@t[@@LABEL] instruction with that codeword occurs.

The best way to get an idea of how it all works is to consider an
example.
The input:
@begin[verbatim]
This text illustrates the use of the @@LABEL and @@REF
instructions.
We have previously labelled the section describing the use of
the @@LABEL instruction, and we will now refer back to it
by using an @@REF instruction, thus:

For details of how to use the @@LABEL instruction, please
see section @@REF[THELABELINSTRUCTION].
@end[verbatim]
will when processed through SCRIBE produce the following output:
@begin[text, above 1, below 1, indent 2]
This text illustrates the use of the @@LABEL and @@REF
instructions.
We have previously labelled the section describing the use of
the @@LABEL instruction, and we will now refer back to it
by using an @@REF instruction, thus:

For details of how to use the @@LABEL instruction, please
see section @ref[thelabelinstruction].
@end[text]
Thus we now have available a mechanism whereby we can incorporate
cross references in our documents.
Although the example shown is a 'backward' reference, it is equally
valid to use 'forward' references - though in this case, you will
need to process the manuscript file through SCRIBE twice in order
that SCRIBE can get its numbering right - this is because in the 
case of the forward reference, SCRIBE does not 'know' where the
forward reference is made to on the first processing run.
@subsection[The @t(@@PAGEREF) Instruction]
@mylabel[Pagerefinstruction]
What we have seen so far is all very well, but is restricted to
sectioned documents only, because the @t[@@REF] instruction picks
up the number of the relevant section when it is used.
What do we do if we are either using an unsectioned document type,
or do not wish to use the section numbers when making a cross-reference
when we are using a sectioned document type?

The obvious answer to this question is to use the page number as
our reference point, and we can do this by using the @t[@@PAGEREF]
instruction which has the form:
@begin[verbatim]
@@PAGEREF[@b(codeword)]
@end[verbatim]
where @b[codeword] is the label of the point in the text which is to be
referred to, eg:
@begin[verbatim]
@@PAGEREF[THEPAGEREFINSTRUCTION]
@end[verbatim]
It all works very much the same way as with the @t[@@REF] instruction,
the difference being that
when a @t[@@PAGEREF] instruction is encountered in the manuscript file,
SCRIBE notes the codeword associated with the @t[@@PAGEREF] instruction
and replaces it with the number of the page on which the
@t[@@LABEL] instruction with that codeword occurs.

The best way to get an idea of how it all works is to consider the
same example as before with the @t[@@REF] instruction replaced
with a @t[@@PAGEREF] instruction.
The input:
@begin[verbatim]
This text illustrates the use of the @@LABEL and @@PAGEREF
instructions.
We have previously labelled the point describing the use of
the @@LABEL instruction, and we will now refer back to it
by using an @@PAGEREF instruction, thus:

For details of how to use the @@LABEL instruction, please
see page @@PAGEREF[THELABELINSTRUCTION].
@end[verbatim]
will when processed through SCRIBE produce the following output:
@begin[text, above 1, below 1, indent 2]
This text illustrates the use of the @@LABEL and @@PAGEREF
instructions.
We have previously labelled the point describing the use of
the @@LABEL instruction, and we will now refer back to it
by using an @@PAGEREF instruction, thus:

For details of how to use the @@LABEL instruction, please
see page @pageref[thelabelinstruction].
@end[text]
@subsection[The @t(@@TAG) Instruction]
@mylabel[TagInstruction]
The @t[@@TAG] instruction allows you to label an item, rather than a
page or section, that is, it allows you to refer to a numbered item
in an enumerated list.
The @t[@@TAG] instruction has the form:
@begin[verbatim]
@@TAG[@b(tag)]
@end[verbatim]
where @b[tag] is the 'label' associated with the item which is to be
referred to.

Once an item in a list has been tagged, reference is made to it by 
using the @t[@@REF] instruction in pretty much the same way as
described above for the @t[@@LABEL] instruction.
It is probably best to see how it works by considering a short
example - the input:
@begin[verbatim]
@@BEGIN[ENUMERATE]
Item 1

Item 2
@@TAG[ITEM2]

Item 3
@@END[ENUMERATE]
This text refers back to item @@REF[ITEM2] in the list immediately above.
@end[verbatim]
would produce the following output:
@begin[enumerate]
Item 1

Item 2
@tag[item2] 

Item 3
@end[enumerate]
This text refers back to item @ref[item2] in the list immediately above.
@section[Summary]
@mylabel[Summary5]
We now know how to use the @t[@@STRING] and @t[@@VALUE] instructions to
define and use text strings which are frequently used, and lengthy (and
which are therefore a bore to type into the manuscript file time after
time).

We have also seen that SCRIBE has a number of predefined strings (whose
names may not be used for user defined strings!) whose values may also
be referenced by using the @t[@@VALUE] instruction).

We have seen how control over the value of SCRIBE's various counters may
be exerted by using the @t[@@SET] instruction, and how the actual value
of these counters may be obtained by using the @t[@@PAGEREF] instruction to
reference counters rather than strings, thus enabling a crude and
limited form of cross-referencing to be used.

More sophisticated cross-referencing can be achieved by using the
@t[@@PAGEREF] instruction in combination with the @t[@@LABEL] instruction.
Cross-referencing to a page number can be achieved by using the 
@t[@@PAGEPAGEREF] instruction, and cross-referencing on an 'itemised' basis
by labelling the 'item' with a @t[@@TAG] instruction rather than a
@t[@@LABEL] instruction].

We saw in the previous lecture how to go about using sectioning instructions.
When such manuscript files were processed, you will have noticed that
periodically, SRIBE produced a message something like "@t[COUNTER SECTION=1]",
which announced that the first section was being processed etc. This is
a useful and common way of monitoring the progress of a job.
What if you are not using a sectioned document type though - SCRIBE
does not produce any messages by default when processing such a document.
You can force SCRIBE to produce messages though by using the @t[@@MESSAGE]
instruction at whatever points in your manuscript file seem suitable
(say every 500 lines).
The @t[@@MESSAGE] instruction has the form @t(@w{@@MESSAGE[@b"message text"]})
and when the manuscript file is processed, the text @b[message text] will
be displayed at your terminal when the @t[@@MESSAGE] instruction is encountered.
@section[Practical]
@mylabel[Practical5]
@lecture[Page Headers and Footers, Tabulation]
@label[lecture6]
@section[Page Headers and Footers]
@mylabel[PageHeadersAndFooters]
You will have seen from these notes that SCRIBE allows the use of page
headers and footers which can be varied from page to page.
These page headers and footers may be split up into three 'fields'
which form the left, centre and right hand portions of the page header
or footer.
The page headers may also be varied according to whether the page on
which they appear is odd or even numbered.

The page number is also regarded as being part of the page header or
footer, and as you will be able to see from these notes, it need not
appear in the default position discussed away back in lecture
@ref[lecture1].

All of these page headers and footers have been achieved by using the
@t[@@PAGEHEADING] and @t[@@PAGEFOOTING] instructions.
These are now described:
@subsection[Page Headers - The @t(@@PAGEHEADING) Instruction]
@mylabel[PageheadingInstruction]
The @t[@@PAGEHEADING] instruction allows us control over the text which
appears in the page header.
It has the form:
@begin[verbatim]
@@PAGEHEADING[LEFT="@b(text)", CENTRE="@b(text)", RIGHT="@b(text)"]
@end[verbatim]
where @b[ltext], @b[ctext] and @b[rtext] is the text appearing at the
left, centre and right of the page header respectively.
for example:
@begin[verbatim]
@@PAGEHEADING[LEFT="SCRIBE Reference Manual"]
@end[verbatim]
look at the page headers of the odd numbered pages in these notes to
see what the effect of this @t[@@PAGEHEADING] instruction is.
Don't worry about the fact that we haven't yet said anything about how
to force page headers or footers onto odd and even numbered pages -
this will be discussed later.

Remember also, that although the simple example above might lead you to
believe that only one of the three fields (left, centre and right) can
be used in any given @t[@@PAGEHEADING] instruction, this is not the case.
As long as you are sensible about the lengths of the fields, you may use
all three of them, eg:
@begin[verbatim]
@@PAGEHEADING[LEFT "SCRIBE Reference Manual", CENTRE="DRAFT",
 RIGHT="@@VALUE(PAGE)"]
@end[verbatim]
Several points about the @t[@@PAGEHEADING] instruction, and more
importantly about the way SCRIBE instructions interact with one
another can be made by considering the above example a little further:

Remember, we said right at the beginning of the course (lecture
@ref[lecture1]) that SCRIBE's default page header was a centred page
number.
Well, whenever we use a @t[@@PAGEHEADING] instruction, whatever was
stored in the previous page header is destroyed - that is as soon as we
use a @t[@@PAGEHEADING] instruction, the page numbering disappears from
the document file - the page numbers are still available, we just aren't
printing them any more.
If we actually want page numbers therefore, and also want to use the
@t[@@PAGEHEADING] instruction, we must @b[always] make sure that we
explicitly include the page number in the @t[@@PAGEHEADING] instruction
as shown above.

Notice also how the @t[@@VALUE] instruction is used to access the page
number.
just as described in lecture @ref[lecture5].
We may also embed SCRIBE instructions within the quoted fields which make up
the @t[@@PAGEHEADING] instruction.

Notice also that we do not have to place the page number in the centre
of the page.
The @t[@@PAGEHEADING] instruction may be used to place it wherever we
want (and in fact, we do not have to have the page number at the top of
the page at all - it can be placed at the bottom of the page as in the
case of these notes, but see the discussion of the @t[@@PAGEFOOTING]
instruction for more details).
@subsection[Page Footers - The @t(@@PAGEFOOTING) Instruction]
@mylabel[PagefootingInstruction]
Page footers may be produced by using an instruction which is
exactly analagous to the @t[@@PAGEHEADING] instruction.
This is the @t[@@PAGEFOOTING] instruction, and it has the form:
@begin[verbatim]
@@PAGEFOOTING[LEFT="@b(text)", CENTRE="@b(text)", RIGHT="@b(text)"]
@end[verbatim]
where @b[ltext], @b[ctext] and @b[rtext] is the text appearing at the
left, centre and right of the page footer respectively.
for example:
@begin[verbatim]
@@PAGEFOOTING[LEFT="@@VALUE(PAGE)"]
@end[verbatim]
look at the page footers of the even numbered pages in these notes to
see what the effect of this @t[@@PAGEFOOTING] instruction is.
Don't worry about the fact that we haven't yet said anything about how
to force page headers or footers onto odd and even numbered pages -
this will be discussed now:
@subsection[Odd and Even Page Headers and Footers]
@mylabel[OddAndEvenPageHeadersAndFooters]
Different page headers and footers may be produced for odd and
even numbered pages by modifying the @t[@@PAGEHEADING] or
@t[@@PAGEFOOTING] instruction as follows:
@begin[verbatim]
@@PAGEHEADING[ODD,........
@@PAGEHEADING[EVEN,.......
@@PAGEFOOTING[ODD,........
@@PAGEFOOTING[EVEN,.......
@end[verbatim]
Just in case it isn't obvious what this means, let's spell it out.
If we include the keyword @t[ODD] or @t[EVEN] in a @t[@@PAGEHEADING]
or @t[@@PAGEFOOTING] instruction, that header or footer will appear
only on odd or even pages.

Knowing this, the full story of the page headers and footers used in these 
notes can now be told:
@begin[verbatim]
@@PAGEHEADING[ODD, RIGHT "@@VALUE<SECTIONTITLE>"]
@@PAGEHEADING[EVEN, LEFT "SCRIBE"]
@@PAGEFOOTING[ODD, RIGHT "@@VALUE[PAGE]"]
@@PAGEFOOTING[EVEN, LEFT "@@VALUE[PAGE]"]
@end[verbatim]
Look at the page headers and footers of these notes carefully, and see
if you can work out exactly what effect these four instructions are
having.
@section[Tabulation]
@mylabel[Tabulation]
In many documents, tables are present, and if a text-processor
is to be considered really useful, it should have facilities which enable such
tables to be set up.
Because of the nature of tables, ie: splitting into columns and rows etc.
there is still quite a lot of 'handwork' to do to set tables up succesfully.
This is true of many (if not all) text-processors, and SCRIBE is no
exception.

Let's say a little bit about tables first of all, and define one or two
'jargon' terms which we will be using.
Tables are set up on a typewriter by using what are known as 'tab stops' or
more often just 'tabs'.
These are set up on a typewriter by using a special 'set tab' control,
and, when the typist is laying out a table he or she just moves to the
next tab position every time a new column in the table is to be started.
This is done using a special 'move to the next tab stop' control, rather
than the normal space bar.
In this way, the left hand edges of the columns of the table are
aligned.

When using a text-processor like SCRIBE, there usually exists a mechanism
which allows us to set such tab stops and to move to them as and when
necessary and this is what this section is really all about. 
Let's just say a bit more about tables in the context of SCRIBE though.

The most important point to remember is that tables are intrinsically
unfilled - there is always some space between the columns (and possibly
rows) of a table, and if we wish that space to be preserved in the
document file we must therefore use an unfilled environment.

Tables may be set up using an environment which uses a fixed width
typeface (eg: @t[VERBATIM]), and all the necessary inter-column spaces
can be inserted 'by hand'

It is however far better to use an unfilled environment which uses a
proportionally spaced font (eg: @t(FORMAT)) to set up a table, and
use SCRIBE's tabbing instructions to set and then move to the relevant
horizontal position in the table whenever a new column in a table is to
be started.

Let's look at the group of SCRIBE instructions which will enable us
to do this:
@subsection[Clearing Tabs - The @t(@@TABCLEAR) Instruction]
@mylabel[TabclearInstruction]
Well, strangely enough, the first thing to do before setting any tabs
is to clear any which might be present already (this isn't really all
that strange - a typist would probably clear any tabs on a typewriter
before starting to type up a new table).
This is actually done for much the same reasons as well, in SCRIBE
tabs are 'inherited', that is new tab stops are added to the ones
which are already there, rather than replacing them.
Now, if you are fully in control of the situation, and do know exactly
what tabs you already have set (and want to retain them!), you may
set additional tabs without clearing those already in existence.
In real life however, this is hardly ever the case, and you are strongly
advised to 'clear the decks' every time you start a new table.

This is done with the @t(@@TABCLEAR) instruction which has the
form:
@begin[verbatim]
@@TABCLEAR
@end[verbatim]
and which will simply clear any existing tab stops.
@subsection[Setting Tabs I - The @t(@@TABDIVIDE) Instruction]
@mylabel[TabdivideInstruction]
Once we have cleared any existing tab stops, the next thing we wish
to do is set up some tabs which define the limits of the columns of
our table.
The simplest way to do this is to divide the available line width
into a number of equal width columns.
This is done with the @t(@@TABDIVIDE) instruction which has the form:
@begin[verbatim]
@@TABDIVIDE[@b(n)]
@end[verbatim]
which has the effect of dividing the available line width into @b[n]
equal width columns by setting @b[n]-1 tab stops, each 1/@b[n]th of
the way across the available line width.
The left margin of the available line width acts as the left edge of the
1st column, and the right margin of the available line width acts as the
right edge of the @b[nth] column.

Thus the instruction:
@begin[verbatim]
@@TABDIVIDE[6]
@tabdivide[6]
@end[verbatim]
would divide the page as indicated by the vertical bars below:
@begin[format]
@tabclear
@tabdivide[6]
|@\|@\|@\|@\|@\|@>|
|@\|@\|@\|@\|@\|@>|
|@\|@\|@\|@\|@\|@>|
|@\|@\|@\|@\|@\|@>|
@end[format]
Don't worry about how the move to the tab stops was actually made just
yet, this will be explained in due course.
@subsection[Setting Tabs II - The @t(@@TABSET) Instruction]
@label[tabsetinstruction]
Well, use of the @t[@@TABDIVIDE] instruction is all very well if we
happen to want to set up a table with a number of equally spaced
columns.
In practice this is a very common requirement, but the case where
several unequally spaced columns is needed is probably just as common.
How do we set up a table with columns of unequal widths?

The @t[@@TABSET] instruction allows us to do this, and it has the form:
@begin[verbatim]
@@TABSET[@b(stop1),@b(stop2),...,@b(stopn)]
@end[verbatim]
where the @b(stop)s are distances specified in any of SCRIBE's allowable
horizontal distance units (see below).

The effect of the @t[@@TABSET] instruction is to set tab stops at the
distances specified by the @t[@@TABSET] instruction], eg:
@begin[verbatim]
@@TABSET[0.5INCH, 25. CM, 63.5MM, 45 CHAR, 36PICA]
@end[verbatim]
would result in tab stops being set at 0.5, 1, 2.5, 4.5 and 6 inches,
like this:
@begin[format, need 4]
@tabclear
@tabset[0.5 inch, 1 inch, 2.5 inch, 4.5 inch, 6.0 inch]
|@\|@\|@\|@\|@\|@>|
|@\|@\|@\|@\|@\|@>|
|@\|@\|@\|@\|@\|@>|
|@\|@\|@\|@\|@\|@>|
@end[format]
A couple of further points about tabs may be made:
@begin[itemise]
SCRIBE units for horizontal distances may be any of the following:
@begin[verbatim]
IN, INCH, INCHES
CM, CENTIMETRES
MM, MILLIMETRES
PICA, PICAS
EM, EMS
@comment<QUAD, QUADS>
CHAR, CHARS, CHARACTER, CHARACTERS
EN, ENS
@end[verbatim]
all of which should be more or less self-explanatory except the @t[POINT],
@t[PICA], @t[EM], @comment<@t[QUAD] >and @t[EN].
These are units traditionally used by printers, and you are not
recommended to use them unless you know what they mean.
@blankspace[2 lines]
In addition, these units may only be used for expressing horizontal
distances; and, SCRIBE's default unit for expressing a horizontal
distance is @t[CHAR] (or the equivalent @t[CHARS], @t[CHARACTER]
or @t[CHARACTERS]).
@blankspace[2 lines]
For a discussion of SCRIBE's vertical distance units, please see
section @ref[styleinstruction].

Whatever unit is used, notice that the name of the unit may be
separated from the numerical value of that unit by a space or not,
the choice is yours.
@end[itemise]
@section[Tab Use]
@mylabel[TabUse]
So we now know how to set up tab stops, but how do we actually use them?
@subsection[Positioning Text - The @t(@@\, @@=) and @t(@@>) Instructions]
@mylabel[\=And>Instructions]
The three fundamental 'tabbing' instructions are @t[@@\], @t[@@=] and
@t[@@>] which allow us to move to the next tab stop, centre text between
two tab stops and flush text rightwards to the next tab stop respectively.
To get an idea of how it all works, let's look at the column headings
for a simple table, and progressively position the headings at the left
edge of the columns (the default position), the centre and then the
right hand edge of the columns.
We'll leave the vertical bars in as well so that the column boundaries
are visible.

To keep it as simple as possible, we'll just divide the page into
four equal width columns - this is how to set it up:
@begin[verbatim, need 5]
@@BEGIN[FORMAT]
@@TABCLEAR
@@TABDIVIDE[4]
|Column 1@@\|Column 2@@\|Column 3@@\|Column 4
@@END[FORMAT]
@end[verbatim]
and when it's processed, it looks like this:
@begin[format]
@tabclear
@tabdivide[4]
|Column 1@\|Column 2@\|Column 3@\|Column 4
@end[format]
Notice that in the output above, the vertical bar marking the right
hand edge of the rightmost column is missing.
This is because to place the bar in this position, we need to use the
@t[@@>] instruction, and we don't know about that (yet!).

Moving on to the @t[@@=] instruction, we said that this enables us to
position text in the centre of a column.
The @t[@@=] instruction has to be used in conjunction with the @t[@@\]
instruction in order to achieve this - like this:
@begin[verbatim]
@@BEGIN[FORMAT]
@@TABCLEAR
@@TABDIVIDE[4]
|@@=Column 1@@\|@@=Column 2@@\|@@=Column 3@@\|@@=Column 4
@@END[FORMAT]
@end[verbatim]
producing the following output:
@begin[format]
@tabclear
@tabdivide[4]
|@=Column 1@\|@=Column 2@\|@=Column 3@\|@=Column 4
@end[format]
Finally, let's look at the @t[@@>] instruction which enables us to
flush text to the rightmost edge of a column (and at this point
we'll re-introduce the vertical bar defining the right hand edge of
the fourth column).
This is how we set it up:
@begin[verbatim]
@@BEGIN[FORMAT]
@@TABCLEAR
@@TABDIVIDE[4]
|@@>Column 1@@\|@@>Column 2@@\|@@>Column 3@@\|@@>Column 4|
@@END[FORMAT]
@end[verbatim]
And this is what the output looks like:
@begin[format]
@tabclear
@tabdivide[4]
|@>Column 1@\|@>Column 2@\|@>Column 3@\|@>Column 4|
@end[format]
@section[Other Tabbing Instructions - @t{@@!}, @t{@@/}, @t{@@^}, @t{@@$}@comment", @t{@@&}, @t{@@)}"]
@mylabel[othertabbinginstructions]
There are available several other 'tabbing' instructions available to us which
allow us to do things like overprint, set a tabstop within the text (rather
than by using a @t[@@TABDIVIDE] or @t[@@TABSET] instruction), set a left
margin within the text etc.
Let's have a look at these in a little detail:

First, let's look at the overprinting or 'return marker' facility.
This allows us to overprint text by setting a return marker with the
@t[@@!] instruction, enter some text into the manuscript file, return
to the marker by entering the @t[@@/] instruction and then entering
more text which is printed on top of the previous text.
Thus, in the manuscript file we might have:
@begin[verbatim]
@@BEGIN[FORMAT]
The quick @@!brown fox @@/jumps over the lazy dog.
@@END[FORMAT]
@end[verbatim]
and in the output, the result would be:
@begin[format]
The quick @!brown fox @/jumps over the lazy dog.
@end[format]
The @t[@@^] instruction allows us to set a tab stop from 'within'
the text, rather than by explicitly specifying them with a 
@t[@@TABDIVIDE] or @t[@@TABCLEAR] instruction.
This is useful for unfilled text which might have a commentary
appended on a line by line basis, or line numbers appended like this:
@begin[verbatim]
@@BEGIN[VERSE]
A smile because the nights are short!@@HSP[1.5 INCHES]@@^
 And every morning brings such pleasure
Of sweet love-making, harmless sport:
 Love that makes and finds its treasure;
 Love, treasure without measure.@@\5

A sigh because the days are long!
 Long long these days that pass in sighing,
A burden saddens every song:
 While time lags which should be flying,
 We live who should be dying.@@\10
@@END[VERSE]
@end[verbatim]
which would result in the output looking like this:
@begin[verse]
A smile because the nights are short!@hsp[1.5 inches]@^
 And every morning brings such pleasure
Of sweet love-making, harmless sport:
 Love that makes and finds its treasure;
 Love, treasure without measure.@\5

A sigh because the days are long!
 Long long these days that pass in sighing,
A burden saddens every song:
 While time lags which should be flying,
 We live who should be dying.@\10
@end[verse]
The @t[@@$] instruction allows us to redefine the position of the
current left margin from within the text.
This can be quite useful when leaving space for a small figure
within the text.
The input might look like this:
@begin[verbatim]
@@BEGIN[TEXT]
This text illustrates use of the '@@dollar' instruction which allows you
to re-define the left margin (here!@@$) of the processed text from
within the input text.
Subsequent text will have its left margin positioned at the point in the
output line at which the cursor was positioned when the '@@dollar'
instruction was encountered.
This instruction is useful for leaving small gaps in the text for
figures etc.
The '@@dollar' instruction is a once-only instruction and should be used
within an explicitly named excursion into an environment, (even if it is
the default TEXT environment like this one).
If this is not done, the left margin cannot be reset to the prevailing
value which the rest of the document is using.
@@END[TEXT]
@end[verbatim]
and the output would look like this:
@begin[text, above 1, below 1, indent 2]
This text illustrates use of the '@@dollar' instruction which allows you
to re-define the left margin (here!@$) of the processed text from
within the input text.
Subsequent text will have its left margin positioned at the point in the
output line at which the cursor was positioned when the '@@dollar'
instruction was encountered.
This instruction is useful for leaving small gaps in the text for
figures etc.
The '@@dollar' instruction is a once-only instruction and should be used
within an explicitly named excursion into an environment, (even if it is
the default TEXT environment like this one).
If this is not done, the left margin cannot be reset to the prevailing
value which the rest of the document is using.
@end[text]
@section[Summary]
@mylabel[Summary6]
@section[Practical]
@mylabel[Practical6]
On your process there is a file called @t[TABLE], it looks like this:
@begin[verbatim, need 9]
010203040506070809
020304050607080910
030405060708091011
040506070809101112
050607080910111213
060708091011121314
070809101112131415
080910111213141516
091011121314151617
@end[verbatim]
Using the SCRIBE tabbing instructions, modify the file @t[TABLE] so
that when processed through SCRIBE, the result is a table which looks
like this:
@begin[format, need 9]
@tabclear
@tabdivide[9]
@=01@\@=02@\@=03@\@=04@\@=05@\@=06@\@=07@\@=08@\@=09
@=02@\@=03@\@=04@\@=05@\@=06@\@=07@\@=08@\@=09@\@=10
@=03@\@=04@\@=05@\@=06@\@=07@\@=08@\@=09@\@=10@\@=11
@=04@\@=05@\@=06@\@=07@\@=08@\@=09@\@=10@\@=11@\@=12
@=05@\@=06@\@=07@\@=08@\@=09@\@=10@\@=11@\@=12@\@=13
@=06@\@=07@\@=08@\@=09@\@=10@\@=11@\@=12@\@=13@\@=14
@=07@\@=08@\@=09@\@=10@\@=11@\@=12@\@=13@\@=14@\@=15
@=08@\@=09@\@=10@\@=11@\@=12@\@=13@\@=14@\@=15@\@=16
@=09@\@=10@\@=11@\@=12@\@=13@\@=14@\@=15@\@=16@\@=17
@end[format]
There are at least two ways of doing this - each is about as difficult
as the other so it doesn't matter which way you choose.
Once you've done that you could try inserting vertical bars to mark
the column boundaries.
@b[Don't] use a fixed width typeface, padding out the space between
the columns with blanks - this is not what is required.
@lecture[Changing Things I - Global Changes]
@mylabel[lecture7]
So far in our discussions of SCRIBE, we have made the (dangerous!) 
assupmption that the default formats for different types of document
and environment which are stored in SCRIBE's database are acceptable
to all users all of the time,
Though this is a reasonable assumption most of the the time, obvioulsy
there are going to be occasions when this is not the case, and we have already
seen that simple changes in the layout of page headers and footers may be
achieved by using the @t[@@PAGEHEADING] and @t[@@PAGEFOOTING] instructions.

What do we do however if we wish to implement some much more fundamental
changes to the format of our documents?

SCRIBE allows us several ways of changing the default formats and 
we are now going to look at these in some detail.

In general, the simpler the method of forcing a change on the default
format, the wider-reaching is its effect, and we will consider the
simplest method first.
Global (ie: affecting everything) changes in SCRIBE's formats are
effected using the @t[@@STYLE] instruction:
@section[The @t(@@STYLE) Instruction]
@label[styleinstruction]
The @t[@@STYLE] instruction is used to effect 'global' changes in the
overall appearance of a finished document, for example, we would use
the @t[@@STYLE] instruction to change the line spacing in our document,
or to ensure that the finished document was filled but not justified,
or to change the width of the margins of the whole document.

The @t[@@STYLE] instruction in its simplest form looks like this:
@begin[verbatim]
@@STYLE[@b(keyword) @b(value)]
@end[verbatim]
where @b[keyword] is some style defining parameter, and @b[value]
is the value of that parameter, eg:
@begin[verbatim]
@@STYLE[SPACING 2]
@end[verbatim]
which fairly obviously forces the document file to be double spaced.

In many cases, the @b[value] component of the 'keyword-value' pair
may have associated with it a default unit which may be omitted.
If any other of SCRIBE's valid distance units are to be used, these
must be explicitly specified.
For example, the default unit for vertical spacing is @t[LINES], so
the example above would automatically assume that the required unit
was @t[LINES].
If a different vertical spacing unit was to be used, that unit would
have to be explicitly specified, eg:
@begin[verbatim]
@@STYLE[SPACING 2 CM]
@end[verbatim]
which would result in lines being spaced 2 centimetres apart in the
document file.

In other cases, the @b[value] component of the keyword-value pair will
consist of a single word whose effect is to turn some style property
on or off, eg:
@begin[verbatim]
@@STYLE[JUSTIFICATION OFF]
@end[verbatim]
whose effect would be to turn off the right justification in running
text (which would still be filled however).

If we wish to set more than one style parameter in a document, there are
two ways in which this can be achieved, firstly by specifying each
style parameter in a separate @t[@@STYLE] instruction:
@begin[verbatim]
@@STYLE[@b(keyword1) @b(value1)]
              .
              .
@@STYLE[@b(keywordn) @b(valuen)]
@end[verbatim]
For example:
@begin[verbatim]
@@STYLE[SPACING 2]
@@STYLE[JUSTIFICATION OFF]
@@STYLE[INDENT 0]
@end[verbatim]
or, alternatively, all the keyword-value pairs may be specified in one
@t[@@STYLE] instruction thus:
@begin[verbatim]
@@STYLE[@b(keyword1) @b(value1),...,@b(keywordn) @b(valuen)]
@end[verbatim]
For example:
@begin[verbatim]
@@STYLE[SPACING 2, JUSTIFICATION OFF, INDENT 0]
@end[verbatim]

Another important feature of the @t[@@STYLE] instruction is that as
the effect of the instruction is to have an effect on the whole
document (usually), the @t[@@STYLE] instruction(s) must come at the
start of the manuscript file before any of the text to be processed.
This is not inevitably true, but for the time being you won't go far
wrong if you assume that it is true.

Before we leave this general discussion of the @t[@@STYLE] instruction,
let's just say a bit more about the distance units which are valid
within SCRIBE.
We've already used horizontal distances when using the tabulation 
facilities, but there are a few units which are valid only for vertical
distances, these are: @t[LINE], @t[LINES], @t[PT], @t[POINT] and
@t[POINTS].
The last three are all different abbreviations for the same thing,
the point, which is a unit used by printers. The point is equal
to 1/72 inch and it is the usual unit for expressing the height of
a typeface. 
You are probably better to stick to @t[LINE] or @t[LINES] though,
because apart from the fact that it is SCRIBE's default unit (and
therefore need not be explicitly specified!), it is also more
easily understandable by non-printers.

Apart from the distance units which were specifically mentioned
as being for use with horizontal distances only (see section
@ref[tabsetinstruction]), any of the other SCRIBE distances may be
used for specifying vertical distances.
@section[Style Keywords]
@mylabel[StyleKeywords]
We've introduced the concept of changing the overall document style
by using the @t[@@STYLE] instruction to effect the required changes,
but obviously before we can change the style of the document we must
be able to specify the properties we wish to change.
As implied above this is done with the keyword-value pairs which
form the arguments to the @t[@@STYLE] instruction.
There are quite a lot of these keyword-value pairs which define
style properties and their values, let's have a look at some of them
starting with the three which are probably the most useful (and
which were introduced in the general discussion of the @t[@@STYLE]
instruction above:
@begin[description]
@t[SPACING]@\controls the line spacing in the finished document file.
The default is single spaced, so if we wish to change the spacing
we must specify:
@begin[verbatim]
..,SPACING 2,..
..,SPACING 0.5 INCH,..
@end[verbatim]
or something similar.

@t[JUSTIFICATION]@\controls whether or not justification is turned on or off
in filled text.
The value of the @t[JUSTIFICATION] keyword may be any of @t[ON],
@t[YES], @t[OFF] or @t[NO] and the meanings of these values should
be obvious, for example:
@begin[verbatim]
..,JUSTIFICATION OFF,..
..,JUSTIFICATION YES,..
@end[verbatim]
would respectively turn the justification off and on.

@t[INDENT]@\controls the amount by which the first line of each
paragraph is indented in filled text.
The value associated with the indent may be expressed in any of
SCRIBES' horizontal distance units, eg:
@begin[verbatim]
..,INDENT 2,..
..,INDENTATION 0.25 INCH,..
@end[verbatim] 

@t[LEFTMARGIN]@\specifies the width of the left margin - the horizontal
distance between the physical edge of paper and the global left margin
(beginning only), eg:
@VERBATIM{..,LEFTMARGIN 1 INCH,..} 

@t[RIGHTMARGIN]@\specifies the width of the right margin - the horizontal
distance between the global right margin and the physical edge of paper,
(beginning only), eg:
@VERBATIM[..,RIGHTMARGIN 4 INCHES,..] 

@t[LINEWIDTH]@\specifies the width of a print line - the horizontal distance
between the global left margin and the end of the line (beginning only), eg:
@verbatim[..,LINEWIDTH 60,..] 

@t[BOTTOMMARGIN]@\specifies the vertical distance to be left between the last
line of printing and the physical bottom of paper (beginning only), eg:
@VERBATIM[..,BOTTOMMARGIN 0.75 INCHES,..] 

@t[TOPMARGIN]@\specifies the vertical distance to be left between the top
of the paper, and the first line of printing (beginning only), eg:
@VERBATIM[..,TOPMARGIN 2.0 CENTIMETRES,..] 

@t[SPREAD]@\a vertical distance, added to @t[SPACING] to increase the
inter-paragraph spacing (beginning only), eg:
@VERBATIM{..,SPREAD 0,..} 

@t[PAGENUMBER]@\allows the page number style to be specified, eg:
@verbatim(..,PAGENUMBER "-@@1-",..)
The string @t["@@1"] in this context is known as a @b[template].
Briefly, templates may be used to control the style of numbering of any
numbered environment or counter etc.
The templates available are:
@begin[description, spread 0,leftmargin +4,indent -4]
@t[@@1]@\Arabic cardinal numerals

@t[@@A]@\upper case letters

@t[@@a]@\lower case letters

@t[@@I]@\upper case Roman numerals (1-20 only)

@t[@@i]@\lower case Roman numerals (1-20 only)

@t[@@*]@\sequence of asterisks (1-10 only)
@end[description]
For a fuller discussion of templates and the way in which they may be used to
modify the way in which the enumerated environments and counters are numbered,
please consult the SCRIBE User Manual @cite[unilogic84].

@t[STRINGMAX]@\the maximum number of characters allowed in a delimited string
in the manuscript file, eg:
@verbatim{..,STRINGMAX 100,..}
The default value of @t[STRINGMAX] is 1024.

@t[DOUBLESIDED]@\if @b[value] is set to @t[YES]), forces major headings
and section titles onto odd pages if this option is available in the
document type, eg:
@verbatim[..,DOUBLESIDED YES,..]
If set, @t[DOUBLESIDED] activates the @t[PAGEBREAK UNTILODD]
or @t[PAGEBREAK UNTILEVEN] attribute when encountered in a @t[@@DEFINE] or
@t[@@MODIFY] instruction.
If @t[DOUBLESIDED] is not set, @t[PAGEBREAK BEFORE] is assumed.

@t[SINGLESIDED]@\turns off @t[DOUBLESIDED] if set.
@t[SINGLESIDED] takes no @b[value] keyword.

@t[PAPERLENGTH]@\a vertical distance specifying the paper length.
Only meaningful for those devices with different paper sizes (beginning only), eg:
@VERBATIM[..,PAPERLENGTH 11.5 INCHES,..] 

@t[PAPERWIDTH]@\a horizontal distance specifying the paper width.
Only meaningful for those devices with different paper widths (beginning only), eg:
@verbatim[..,PAPERWIDTH 9.25 INCHES,..] 
@end[description]
@section[Summary]
@mylabel[Summary7]
We've now seen how to effect changes in the overall style of our documents.
Obviously, this can be quite important, for example, the requirements in
this university are (usually) that theses be double-spaced among other
things.
Now, SCRIBE's default spacing for almost everything is single-spaced, so
if you were preparing your thesis using SCRIBE, you would need to use the
@t[@@STYLE] instruction to get the line spacing right.
You would also need to use other @t[@@STYLE] instructions to set other
parameters for a thesis, but we'll leave that as an excercise.

As far as the @t[@@STYLE] keywords are concerned, as we have seen there
are quite a lot of them.
They are presented in the notes (and in the lecture) in the order which
is felt reflects their likely usefulness, thus, @t[SPACING] is likely
to be more usefull than @t[PAPERWIDTH], so don't worry too much about
any of them except the first half dozen or so at the moment.

Before going any further though let's stress one important point - you
should not do anything to affect the overall style of your document
until the last possible moment.
That is work with a draft using the default settings until you are ready
to start producing the final (or near final) copy.
If you do not do this, especially while you are still finding your way
around with SCRIBE, you will never be sure whether some strange effect
which you may be seeing in your document is due to SCRIBE itself, or
to some possibly inconsistent style change which you have introduced
yourself.
Temper this advice with some common sense though - obviously, setting
line spacing to @t[2] or turning justification to @t[OFF] is not going
to have too serious an effect.
Changing the margins however might lead to considerable confusion, 
especially if you are not sure what the default settings are in the
first place.
@section[Practical]
@mylabel[Practical7]
Despite all that has been stated in the summary above, you should now try
changing the style of one of your documents - probably the best idea is
to introduce one change at a time, process the manuscript and look at the
resultant output and compare it with the original produced using SCRIBE's
default settings.
At this stage, it's probably best if you restrict yourself to looking at
the effect of changing the settings for @t[SPACING], @t[JUSTIFICATION],
@t[INDENT], @t[LEFTMARGIN], @t[RIGHTMARGIN], @t[LINEWIDTH],
@t[BOTTOMMARGIN], @t[TOPMARGIN] and @t[SPREAD].
@lecture[Changing Things II - Local Changes, New Environments]
@mylabel[lecture8]
The @t[@@STYLE] instruction enabled us to effect changes in the overall
appearance of our finished document.
What do we do if we wish to effect changes in the final appearance of
only one or two of SCRIBE's environments, or, if we wish to be even
more demanding and effect a change in only a few (even one!) uses
of only one or two environments or even set up a completely new
environment?

To effect changes in the final appearance of all uses of a given
environment, we use the @t[@@MODIFY] instruction; to effect a change in
a single excursion into an environment, we use a modified form of the
@t[@@BEGIN] instruction; and, to set up a new environment we use the
@t[@@DEFINE] instruction:
@section[The @t(@@MODIFY) Instruction]
@mylabel[ModifyInstruction]
The @t[@@MODIFY] instruction enables us to effect changes in the
final appearance of one named environment.
It has the form:
@begin[verbatim]
@@MODIFY[@b(environment), @b(keyword1) @b(value1),..,@b(keywordn) @b(valuen)]
@end[verbatim]
where @b[environment] is the name of the environment whose final
appearance is being modified, and the keyword-value pairs have
the same function as with the @t[@@STYLE] instruction.

There is some degree of commonality between the set of keyword-value
pairs which may be used with the @t[@@STYLE] and @t[@@MODIFY]
instructions, but there are more keyword-value pairs which may
be used with the @t[@@MODIFY] (and @t[@@BEGIN] and @t[@@END] and
@t[@@DEFINE]) instruction.

Before looking at them in detail, let's consider a couple of examples
of an @t[@@MODIFY] instruction to get an idea of how the
thing looks in real life:
@begin[verbatim]
@@MODIFY[TEXT, SPACING 1.5, INDENT 0]
@@MODIFY[QUOTATION, SPACING 1.25, USE B]
@end[verbatim]
which would modify the @t[TEXT] environment so that the line spacing
was set to 1.5 lines and the indentation to zero; and the @t[QUOTATION]
environment so that quotations were rendered in boldface and spaced 1.25.

Such modifications remain in force for all excursions into the named 
environment occurring after the @t[@@MODIFY] instruction.
If at some stage, an additional or different modification is required,
this should be specified in a new @t[@@MODIFY] instruction which will
automatically cancel the effect of any previous @t[@@MODIFY] instruction
relating to the relevant environment.
Remember though that for such modifications to have any effect, the
named environment must be explicitly entered with an @t[@@BEGIN]
instruction (and subsequently left with an @t[@@END] instruction), and
you may not change the appearence of an environment by using an 
@t[@@MODIFY] instruction within the relevant environment.
@section[One-off Modification with @t(@@BEGIN) and @t(@@END)]
@mylabel[modificationwithbegin]
What do we do if we only wish to modify one particular example of
an excursion into an environment in some way?
This is quite a common requirement and SCRIBE allows us to do this
by using a modified form of the 'long' form of using an environment,
that is, by using the @t[@@BEGIN] instruction - it looks like this:
@begin[verbatim]
@@BEGIN[@b(environment), @b(keyword1) @b(value1),..,@b(keywordn) @b(valuen)]
  .
  .
@@END[@b(environment)]
@end[verbatim]
where @b[environment] is the environment which is to be modified for
just this one excursion into it and the @b[keyword]s and their @b[value]s
have the same meaning as above, for example:
@begin[verbatim]
@@BEGIN[TEXT, SPACING 2, INDENT 0, JUSTIFICATION OFF]
  .
  .
@@END[TEXT]
@end[verbatim]
remember that the effect lasts only for the duration of the relevant
excursion into the named environment, and that the @t[@@BEGIN] instruction
must have a matching @t[@@END] instruction in the usual manner.
@section[The @t(@@DEFINE) Instruction]
@mylabel[DefineInstruction]
Finally, let's look at the situation where we wish to define a completely
new environment.
There are many situations where we might wish to do this, for example,
in the case where we have several excursions into a non-standard form
of one of the existing environments, too many for it to be efficient to
use an @t[@@MODIFY] instruction or an @t[@@BEGIN] instruction every
time.
In this case, we can use the @t[@@DEFINE] instruction to set up a new
environment.
We can either do this from scratch or by taking an existing environment
and specifying the changes we wish to make.
The latter is certainly the easiest method, and looks like this:
@begin[verbatim]
@@DEFINE[@b(newenvironment)=@b(oldenvironment), @b(keyword1) @b(value1),..,@b(keywordn) @b(valuen)]
@end[verbatim]
where @b[newenvironment] is the users chosen name for the new environment
being defined, @b[oldenvironment] is the name of the old environment which
is being used as a basis for the definition of the new environment, and the
@w(@b[keyword value]) pairs have the same meaning as above, eg:
@begin[verbatim]
@@DEFINE[RAGGEDTEXT=TEXT, JUSTIFICATION OFF]
@@DEFINE[DRAFTTEXT=TEXT, SPACING 2]
@end[verbatim]
would define two slightly modified forms of the @t[TEXT]
environment which would respectively be unjustified and double-spaced.

One a new environment has been defined in this way, it may be used in
exactly the same way as any of SCRIBE's default environments:
@begin[verbatim, need 8]
@@BEGIN[RAGGEDTEXT]
This example shows the use of the user-defined environment RAGGEDTEXT.
It is basically the same as TEXT except that justification has been
turned off.
Although in this simple case only one attribute of the TEXT environment
was changed when defining RAGGEDTEXT, as many attributes as required
may be altered in the list of arguments to the @@DEFINE instruction.
@@END[RAGGEDTEXT]
@end[verbatim]
and the processed text will appear in the output in the usual way, but
formatted according to the changes effected with the @t[@@DEFINE]
instruction:
@begin[raggedtext, above 1, below 1, indent 2]
This example shows the use of the user-defined environment RAGGEDTEXT.
It is basically the same as TEXT except that justification has been
turned off.
Although in this simple case only one attribute of the TEXT environment
was changed when defining RAGGEDTEXT, as many attributes as required
may be altered in the list of arguments to the @@DEFINE instruction.
@end[raggedtext]
@section[Environment Keywords]
@mylabel[EnvironmentKeywords]
As has already been stated, the set of keywords and values for use with
the @t[@@MODIFY], modified @t[@@BEGIN] and @t[@@DEFINE] instructions is
different from the set for use with the @t[@@STYLE] instruction (though
there is some duplication).

These environment keywords are now described.
@begin{description,leftmargin +12,indent -12}
@t[SPACING]@\sets the line spacing.
@b{value} should be a vertical distance, eg:
@VERBATIM[..,SPACING 2,.. 
..,SPACING 0.25 INCHES,..] 

@t[JUSTIFICATION]@\controls right justification of the output, and may only be
used in a filled environment.
@b{value} should be one of @t[ON], @t[OFF], @t[YES] or @t[NO], eg:
@VERBATIM{..,JUSTIFICATION YES,.. 
..,JUSTIFICATION OFF,..} 

@t[INDENT]@\controls 'start of paragraph' indentation with respect to the
current left margin.
@b{value} should be a horizontal distance, eg:
@verbatim{..,INDENT 0.25 INCH,..
..,INDENT 6,..}
If no unit is specified, @t[CHARS] is assumed.

@t[INDENTATION]@\same as @t[INDENT].

@t[LEFTMARGIN]@\sets the width of the left margin.
@b{value} should be a horizontal distance, eg:
@verbatim[..,LEFTMARGIN 5,..
..,LEFTMARGIN +0.5 INCHES,..]
Signed distances are effected with respect to the prevailing left margin;
unsigned distances are effected with respect to the left hand edge of the
output file 'page' (and thus will produce a left margin of that size when the
output file  is printed).
@t[LEFTMARGIN], @t[LINEWIDTH] and @t[RIGHTMARGIN] are related keywords, and only
two of them may be specified at any one time.

@t[RIGHTMARGIN]@\sets the width of the right margin.
@b{value} should be a horizontal distance, eg:
@verbatim[..,RIGHTMARGIN -5,..
..,RIGHTMARGIN 0.5 INCHES,..]
Signed distances are effected with respect to the prevailing right margin;
unsigned distances are effected with respect to the right hand edge of the
output file 'page' (and thus will produce a margin of that size when the output
file is printed).
@t[LEFTMARGIN], @t[LINEWIDTH] and @t[RIGHTMARGIN] are related keywords, and only
two of them may be specified at any one time.

@t[LINEWIDTH]@\specifies the distance between the left and right margins.
A horizontal distance should be used, eg:
@verbatim{..,LINEWIDTH 65 EMS,..
..,LINEWIDTH 7 INCHES,..}
@t[LEFTMARGIN], @t[LINEWIDTH] and @t[RIGHTMARGIN] are related keywords, and only
two of them may be specified at any one time.

@t[ABOVE]@\specifies the amount of blank space left above an environment.
Units should be a vertical distance, eg:
@verbatim{..,ABOVE 3,..
..,ABOVE 0.5 INCHES,..}
If a unit 'name' (eg: @t[ INCHES]) is omitted, @t[LINES] is assumed.

@t[BELOW]@\specifies the amount of blankspace left below an environment.
Units are as for @t[ABOVE], eg:
@VERBATIM{..,BELOW 2CM,.. 
..,BELOW 4 LINES,..} 

@t[SPREAD]@\specifies the additional vertical space to be added to @t[SPACING]
when setting up the inter-paragraph spacing.
@b{value} should be a vertical distance, eg:
@VERBATIM[..,SPREAD 1,..] 

@t[CAPITALIZED]@\controls whether output text is in upper case.
@b{value} should be one of @t[ON], @t[YES], @t[OFF], @t[NO], eg:
@VERBATIM{..,CAPITALIZED NO,.. 
..,CAPITALIZED ON,..} 

@t[UNDERLINE]@\specifies which characters are to be underlined in the document
file.
@b{value} should be one of @t[OFF], @t[ALPHANUMERICS], @t[NONBLANK] or @t[ALL],
eg:
@VERBATIM[..,UNDERLINE ALL,..] 

@t[FACECODE]@\controls the facecode in which the environment is printed, eg:
@verbatim[..,FACECODE B,..]
For a list of the facecodes supported by the various devices accessible to
SCRIBE, please consult references @cite[ercc84b] and @cite[ercc84c].

@t[CENTRED]@\specifies that text be placed centrally between the prevailing
margins.
@t[CENTRED] does not take a value word, eg:
@verbatim{..,CENTRED,..}
@t[CENTRED] is one of a group of mutually exclusive environment attributes -
@t[CENTRED], @t[FILL], @t[FLUSHLEFT] and @t[FLUSHRIGHT].

@t[FILL]@\forces line filling.
@t[FILL] takes no value word.
@t[CENTRED], @t[FILL], @t[FLUSHLEFT] and @t[FLUSHRIGHT] are mutually exclusive
attributes, eg:
@VERBATIM{..,FILL,..} 

@t[FLUSHLEFT]@\forces each line of text to the current left margin.
@t[FLUSHLEFT] takes no value word, and @t[CENTRED], @t[FILL], @t[FLUSHLEFT] and
@t[FLUSHRIGHT] are mutually exclusive attributes, eg:
@VERBATIM{..,FLUSHLEFT,..} 


@t[FLUSHRIGHT]@\forces each line of text to the current right margin.
@t[FLUSHRIGHT] takes no value word, and @t[CENTRED], @t[FILL], @t[FLUSHLEFT] and
@t[FLUSHRIGHT] are mutually exclusive attributes, eg;
@VERBATIM{..,FLUSHRIGHT,..} 

@t[AFTERENTRY]@\takes a quoted instruction or string as its value.
This instruction is evaluated and inserted into the input on entry to the
environment, eg:
@VERBATIM{..,AFTERENTRY "@@TABCLEAR",..} 

@t[BLANKLINES]@\specifies what is to be done with blanklines found in an
environment.
@b{value} may take the value @t[IGNORED], @t[BREAK] or @t[KEPT,] eg:
@VERBATIM[..,BLANKLINES KEPT,..] 


@t[BREAK]@\controls the output of line breaks at the start and finish of
environments.
@b{value} may be one of @t[BEFORE], @t[AFTER], @t[AROUND] or @t[OFF].


@t[CONTINUE]@\if @W(@t[BREAK AROUND]) or @W(@t[BREAK AFTER]) is set, determines
whether the line following an excursion into another environment resumes the
previous paragraph or starts a new one.
@b{value} may be any of @t[ALLOWED], @t[FORCE] or @t[OFF], eg:
@VERBATIM{..,CONTINUE ALLOWED,..} 

@t[COUNTER]@\specifies which counter applies to the environment, and which
counter is found by @t[@@TAG].
@b{value} should be one of the counter names, eg:
@VERBATIM{..,COUNTER CHAPTER,..} 

@comment{@t[FONT]@\TO BE INSERTED LATER
}
@t[INITIALIZE]@\same as @t[AFTERENTRY].

@t[LEADINGSPACES]@\controls what is done with leading spaces in manuscript file
lines.
@b{value} should be one of @t[IGNORED], @t[COMPACT] or @t[KEPT], eg:
@VERBATIM{..,LEADINGSPACES KEPT,..} 

@t[NEED]@\enables a test for sufficient space remaining on the current page to
be made.
@b{value} should be a vertical distance, eg:
@verbatim[..,NEED 4 LINES,..
..,NEED 3.5 INCHES,..]
If there is not enough space remaining on the current page, a page throw will
be inserted in the output file.


@t[NUMBERED]@\specifies a template for numbering paragraphs in the environment.
Please consult the SCRIBE User Manual @cite[unilogic84] for further details.


@t[NUMBERFROM]@\gives the initial value for the numbering of paragraphs in an
environment, eg:
@VERBATIM(..,NUMBERFROM 4,..) 


@t[PAGEBREAK]@\controls whether the start or end of an environment causes a page
break.
@b[value] may be any of the set; @t[OFF], @t[BEFORE], @t[AFTER], @t[AROUND],
@t[UNTILODD] or @t[UNTILEVEN], eg:
@verbatim[..,PAGEBREAK UNTILODD,..]
The setting of the @t[DOUBLESIDED] keyword with a @t[@@STYLE] instruction may have
a bearing on the effect of a @t[PAGEBREAK] keyword.
Please see section @ref[StyleInstruction] below for details.


@t[REFERENCED]@\is like @t[NUMBERED] but provides a template for
cross-references to the paragraph number.
Please consult the SCRIBE User Manual @cite[unilogic84] for further details.

@t[SCRIPT]@\specifies whether text is to be placed above or below the global
baseline.
@b[value] may be either +1 or -1, eg:
@VERBATIM[..,SCRIPT +1,.. 
..,SCRIPT -1,..] 

@comment{
@t[SINK]@\TO BE INSERTED LATER


}
@t[SPACES]@\specifies how multiple spaces in the manuscript file are treated.
@b{value} should be one of @t[KEPT], @t[COMPACT], @t[IGNORED] or @t[NORMALIZED], eg:
@VERBATIM[..,SPACES COMPACT,..] 

@t[UNNUMBERED]@\states that an environment is to have unnumbered paragraphs.
@t[UNNUMBERED] does not take a value word, eg:
@VERBATIM[..,UNNUMBERED,..] 

@t[USE]@\allows one environment definition to be used within another.
Please see the SCRIBE User Manual @cite[unilogic84] for further details.
@end{description}
@section[The @t(@@EQUATE) Instruction]
@mylabel[EquateInstruction]
@section[Summary]
@mylabel[Summary8]
this lecture has largely been a repeat of the previous one, except
that we have been looking in particular at ways to effect cahnges
in our overall document style of a selective nature using the 
@t[@@MODIFY], @t[@@BEGIN] and @t[@@DEFINE] instructions.
this allows us to excercise very fine control overthe final appearence
of our documents, although the warning given in the summary to the
previous lecture still holds good - don't start making cahnges of this
nature until you are absolutely sure what it is you wish to change and
which environment attributes need changing to achieve the desired effect.

The range of environment keywords is considerably larger than those
available for use with the @t[@@STYLE] instruction, but the same 
principle has been followed in the descriptions above - those keywords
likely to be most useful are described first.
@section[Practical]
@mylabel[Practical8]
Well, by now you should really be convinced that SCRIBE is capable of
doing most if not all of what you are likely to require when formatting
(relatively) simple documents.
However, it is probably a good idea if you try the effect of the 
@t[@@MODIFY], modified @t[@@BEGIN] and @t[@@DEFINE] instructions.
Try altering one of your manuscript files in some way which will
result in only selected environments being changed, or only selected
excursions into the same environment.
You could also try defining a (simple) new environment with the
@t[@@DEFINE] instruction.
It's probably best if you restrict yourself for the time being to
only the first few keywords described above, say the @t[SPACING],
@t[JUSTIFICATION], @t[LEFTMARGIN], @t[RIGHTMARGIN], @t[LINEWIDTH],
@t[ABOVE], @t[BELOW], @t[SPREAD], @t[CAPITALIZE] and @t[UNDERLINE]
keywords.
@unnumbered[References and Further Reading]
@begin[bibliography]
Browning. G.K.S., Automatic Typesetting, University Computing, Vol
@b[6] No 2, pp 95-98, June 1984.
@tag[browning84] 

Furuta. R., Scofield. J., Shaw. A., Document Formatting
systems: Survey, Concepts and Issues, ACM Computing Surveys, Vol @b[14], No 3,
September 1982.
@tag[furuta82] 

Hamilton-Smith. N., Murison. J.M. (editors), EMAS 2900: User's
Guide, ERCC, October 1982.
@tag[ercc82] 

Hare. R.J., McArthur. C.D., McKendrick. A., SCRIBE Reference
Manual, ERCC User Note 67, March 1985.
@tag[ercc84c] 

Hare. R.J., A SCRIBE Primer, ERCC User Note 66, February 1985.
@tag[ercc85] 

Murison. J.M., Phillips GP300 Printer: Character Sets, ERCC User
Note 50, June 1984.
@tag[ercc84b] 

Reid. Brian K., SCRIBE Document Preparation System - User Manual, Unilogic
Ltd., April 1984.
@tag[unilogic84] 

Wilson. A., Editors Available on EMAS 2900, ERCC User Note 46,
January 1984.
@tag[ercc84] 
@end[bibliography]