SampleSheet.tioga
Last Edited by Horning on December 17, 1982 12:11 pm
Last Edited by Beach, May 15, 1984 10:41:46 am PDT
Last Edited by: Subhana, May 31, 1984 3:27:50 pm PDT
CEDAR DOCUMENT STYLE (Mark property value: centerVersoHeader)
CEDAR DOCUMENT STYLE (Mark property value: centerRectoHeader)
CEDAR 5.2 — FOR INTERNAL XEROX USE ONLY (Mark property value: centerVersoFooter)
CEDAR 5.2 — FOR INTERNAL XEROX USE ONLY (Mark property value: centerRectoFooter)
Cedar Document Style  title node
A Sample Sheet  subtitle node
Release as [Indigo]<Cedar5.2>Documentation>SampleSheet.tioga, .press

© Copyright 1984 Xerox Corporation. All rights reserved.
Abstract: This sampler is intended to show "some of everything" from the standard Cedar.style for use with Tioga. It should serve as a reminder of the formats and looks available for preparing uniformly formatted Cedar programs, documentation, and memoranda. It also contains itemized lists of the formats and looks. Mostly, though, the contents are a jumble, words collected to add versimilitude to an otherwise bald and unconvincing assemblage.  abstract nodes
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304
  — boilerplate node


For Internal Xerox Use Only
Contents  contents nodes, begins new page
Node Format Sampler
Formats
Programs, Prose
Looks
Programs
Text
Prose, References, Poetry
Forms
Memo
— pagebreak node to separate contents from first heading
Node Format Sampler  This is a head Node
This is a body paragraph node, nested under the head node (actually, in the branch of which the head node is the root). Note that nesting is displayed on the screen by a small indent which is not reflected in the hardcopy form. This is a body node, nested in the head node. This is a body node, nested in the head node. This is a body node, nested in the head node. This is a body node, nested in the head node. This is a body node, nested in the head node.
Some people find that this indentation on the screen helps them to keep track of the nesting structure of their documents. If, on the other hand, you find it more distracting than helpful, you should change the ScreenRule for Nest in Cedar.style to be the same as the PrintRule. Some node formats cause indentation that is independent of nesting. This indentation is larger than the indentation that indicates nesting. This note node illustrates the difference. It is not nested in the body node above.
However, this note node is nested in the note above it, and hence gets the sum of the two relative indentations.
A nested head node
This is a body node, nested in the head node. This is a body node, nested in the head node. This is a body node, nested in the head node. This is a body node, nested in the head node.
This is a block node, also nested in the head node. This is a block node, also nested in the head node. This is a block node, also nested in the head node. This is a block node, also nested in the head node. This is a block node, also nested in the head node. This is a block node, also nested in the head node. This is a block node, also nested in the head node.
This is an indent node, also nested in the head node. This is an indent node, also nested in the head node. This is an indent node, also nested in the head node. This is an indent node, also nested in the head node. This is an indent node, also nested in the head node. This is an indent node, also nested in the head node.
This indent node is nested in the previous one (hence indented relative to it). This indent node is nested in the previous one (hence indented relative to it). This indent node is nested in the previous one (hence indented relative to it).
This is a quote node. It is nested in the head node, not the indent node. This is a quote node. It is nested in the head node, not the indent node. This is a quote node. It is nested in the head node, not the indent node. This is a quote node. It is nested in the head node, not the indent node.
And this is a center node, nested in the head node.
Another nested head node
This is a body node, nested in the head, with an embedded program fragment. This is a body node, nested in the head, with an embedded program fragment. This is a body node, nested in the head, with an embedded program fragment.
Sample: CEDAR PROGRAM -- This is an example node
IMPORTS Something -- Online comment in a code node
EXPORTS Another
= { IF a < b THEN a ← b }.
This is a continuation node, nested under the body node with the embedded program fragment. This is a continuation node, nested under the body node with the embedded program fragment.
1. This is an item node. Item nodes are typically nested in other nodes, and contain the elements of displayed lists (note the hanging indent).
2. This is an item node. Item nodes are typically nested in other nodes, and contain the elements of displayed lists (note the hanging indent).
3. This is an item node. Item nodes are typically nested in other nodes, and contain the elements of displayed lists (note the hanging indent).
This is another item node. This is another item node. This is another item node. This is another item node. This is another item node. This is another item node. This is another item node. This is another item node.
This lead2 node is set with more leading, which leaves more space between lines, e.g., to accomodate LARGE TYPE. The choices are lead1, lead2, and lead3. This lead2 node is set with more leading. This lead2 node is set with more leading. This lead2 node is set with more leading. This lead2 node is set with more leading. This lead2 node is set with more leading.
This is a
table node. Only
simple tabs are available.
A table1  node has
smaller tabs for more columns.
A table2 node has even
smaller tabs for still more.
While a table3 node has yet
smaller tabs for lots of columns.
This is a pageBreak node. (Contents are appropriate only if they are to appear at the very bottom of the page.)
Node Format Summary
Much of the control of the format of a document can be handled consistently by associating "formats" with nodes of the document. The set of formats selected for Cedar is intended to cover the common kinds of textual units in documentation, memos, and programs. It is best to pick a small subset of them for any particular document.
Formats for defaults
default is applied automatically to any node that has no explicit format.
root is applied automatically to a document once at the root node if that root node has not other format.
Formats for use in programs
code is intended for program statements that do not require special spacing. Nesting is reflected by indentation.
unit is intended for program statements that start a new logical unit, and hence should have some extra space in front.
Formats for use in prose
block is intended for block-style paragraphs.
body is intended for ordinary paragraphs with the first line indented.
center is intended for centered paragraphs.
chapter is intended for a chapter heading, begins a new page and extra large type.
contents is intended for headings in tables of contents. The same type fonts are used as for head, but with less leading, and with indentation corresponding to nesting structure.
continuation is intended for nodes that logically "continue" previous nodes (e.g., following an example or an itemized list), and hence should not have extra leading at the beginning.
display is intended for displayed equations, etc. embedded in text paragraphs.
example is intended for things like program statements included within explanatory text, and gets extra indentation to set it off.
head is a "generic" format for headings that will expand to one of head1, . . ., head5, as a function of the level of nesting. If it is used in place of the more specific head formats, heading nodes can be copied, levels can be added or removed, etc., with minimum effort.
indent is intended for paragraphs that are to be indented (relative to the containing node). In the usual case, this is a head, rather than the preceding body node, although the difference is not visible on the hardcopy. See also quote and note.
item is intended for elements of an itemized list (like this one). Items are indented relative to their containing node, and continuation lines are further indented. A convenient tab stop is available to line up short item labels, like "1.<tab>mumble".
lead1, lead2, and lead3 are like block, except that they have progressively more inter-line leading, which can be useful for paragraphs with larger format, superscripts, etc.
letterHead1 and letterHead2 are intended for business letter head. Some special spacing is necessary to position the letterhead properly.
logo is intended for the Xerox logo line at the start of a document. It does more than just set the font to Logo24, it provides extra space before and after, extends into left margin, etc.
memoHead is intended for the heading lines at the start of memos.
note is intended for fine points. Someday we will have real footnotes.
pageBreak is intended to force a new page. It shouldn't have contentunless you want it at the very bottom of the page.
quote is intended for displayed quotations.
ragged is a ragged-right formatted (flush right aligned) block.
reference is intended for items in reference lists [van Leunen 1978].
table is intended for tables with widely-spaced columns.
table1, table2, and table3 provide successively smaller tab stops to accomodate more columns.
tight is intended for paragraphs to be formatted with less leading.
widowSaver is intended for body paragraphs with the last line forced to fill the entire line. The usual application is during manual pagination of a document when a paragraph must cross a page boundary.
Formats for use on a title page
abstract is intended for paragraphs of the abstract on the title page.
authors is intended to list the authors.
boilerPlate is intended for the Xerox logo and PARC address at the bottom of the title page.
subtitle uses a slightly smaller font, and can be used under a title.
title is intended for titles, typically at the start of a document.
unleaded is intended for the nodes that define the running head and feet.
Looks
It is good practice to use the "abstract" (or "intentional") looks wherever possible (e.g., Annotation, rather than Bold, Emphasis, rather than Italic, Keyword, rather than Smaller). This will make it possible to produce other versions of the document where different decisions have been made about the appropriate way to display some abstract property. Also, it is better to avoid looks entirely, if the information can be captured in the format of the containing node (none of the headings in this document have Bold looks).
Looks a b c d e f g h i j k l % n o p q r s t u v w x y z.
look.a annotation font
look.b bold font
look.c Cedar comments
look.d down for subscriptlower and a smaller font
look.e emphasis
look.f fixed-pitch fontGacha
look.g GreekHippo
look.h hidden by asterisks (unfortunately prints normally)
look.i italic
look.k Cedar KEYWORDS
look.l larger font
Ð.m Math font
look.n Cedar procedure names
look.o other fontHelvetica
look.p plain font and regular sizeoverrides node format
look.q quaint XEROX logo—for boilerplate format
look.r regular faceoverrides node format
look.s smaller font
look.t  Tioga font
look.u up, for superscripthigher and a smaller font
look.x extra large
look.y yarbitrary for strikeout
look.z zarbitrary for underlined
Look.s Format block. Mohammed (also Mahomet, Muhammad; 570?-632) asserted a doctrine of unqualified monotheism (suras 8, 22, 33-37, 89, 91, Koran).
Look.l Format lead1. Scholarly writing is formal, accurate, and allusive. It has to be. It does not have to be wooden, finicking, and cabalistic. The idea of this book is to help you achieve the first set of characteristics without sinking into the second.
Look.x Format lead2. "There is no God but Allah."
Of course, a variety of looks can be mixed in a single paragraph, although the appearance of the result is often somewhat less than pleasing. Ai Bj
Programs
Cedar Comment Standing on its own as a unit node
File: SimpleExample.mesa
Last edited by: Cattell on May 12, 1982 3:05 pm
DIRECTORY
IOStream, Process, Rope, UserExec;
SimpleExample: MONITOR
IMPORTS IO: IOStream, Process, R: Rope, UserExec =
BEGIN
ROPE: TYPE = R.ROPE;
windowCount: INT ← 0; -- a count of the number of calculators on the screen
ReverseName: UserExec.CommandProc = BEGIN
Reverses the user's login name and prints it out in the exec window.
userName: ROPE ← UserExec.GetNameAndPassword[ ].name;
execStream: IOStream.Handle ← exec.out; -- exec was passed as arg to this proc
backwordsName: ROPE ← NIL;
Remove ".PA" if it is on the end of the user name, and check for user name Ritchie.
dotPos: INT ← userName.Find["."];
IF dotPos#-1 THEN
userName ← userName.Substr[0, dotPos];
IF userName.Equal[s2: "Ritchie", case: FALSE] THEN
execStream.PutF["Hi, Bob\n"];
Now reverse the name: convert chars to upper cases and concatenate them in reverse order
FOR i: INT DECREASING IN [0..userName.Length[ ]) DO
backwordsName ← backwordsName.Cat[R.FromChar[R.Upper[userName.Fetch[i]]]]
ENDLOOP;
execStream.PutF["Your user name backwards is: %g\n", IO.rope[backwordsName]];
END;
Start code registers a Calculate and ReverseName command, which must be invoked for this program to do anything:
UserExec.RegisterCommand[
name: "Calculate", proc: MakeCalculator, briefDoc: "A simple adding machine"];
UserExec.RegisterCommand[
name: "ReverseName", proc: ReverseName, briefDoc: "Reverses your user name"];
END.
CHANGE LOG
Created by Cattell on 21-Apr-82 13:55:09
Changed by Cattell on May 25, 1982 10:58 am
added use of RegisterCommand to fire up a Calculator viewer instead of creating it when program first run.
Text
Prose
Scholarly writing is formal, accurate, and allusive. It has to be. It does not have to be wooden, finicking, and cabalistic. The idea of this book is to help you achieve the first set of characteristics without sinking into the second.
Let us not deceive ourselves. "There is no God but Allah" is a more gripping sentence than
Mohammed (also Mahomet, Muhammad; 570?-632) asserted a doctrine of unqualified monotheism (suras 8, 22, 33-37, 89, 91, Koran).
By its very nature, scholarly prose lacks the rhetorical virtues of reckless passion. Custom and propriety hem the scholar in on every side. His obligation to his material and his obligation to his sources restrain him. He may not gloss over imperfections, smooth out irregularities, turn a blind eye to objections, no matter what good effects these temptations might offer in the way of clarity and simplicity.
On the other hand, the built-in limitations of scholarly prose are no excuse for bad writing. Bad scholarly prose results, as all bad prose does, from laziness and hurry and muddle. Good scholarly prose is probably even harder to produce than other kinds of good prose. All that means is that the scholar must work even harder at it. [van Leunen 1978]
References
[Carroll 1865]
Lewis Carroll
Alice's Adventures in Wonderland
Washington Square Press edition, 1960
[Knuth 1968]
Donald E. Knuth
The Art of Computer Programming, vol. 1
Addison-Wesley
[van Leunen 1978]
Mary-Claire van Leunen
A Handbook for Scholars
Knopf
Poetry  The Mouse's Tale
Fury said to
a mouse, That
he met in the
house, Let
us both go
to law: I
will prose-
cute you.
come, I'll
take no de-
nial: We
must have
the trial;
For really
this morn-
ing I've
nothing
to do.'
Said the
mouse to
the cur,
Such a
trial, dear
 sir, With
 no jury
 or judge
 would
 be wast-
 ing our
 breath.'
 I'll be
 judge,
 I'll be
jury,
said
 cun-
 ning
 old
 Fury:
 I' ll
 try the
 whole
 cause
 and
 con-
 demn
death.' you to
[Carroll 1865]