*start*
01886 00024 USt
Date:  3-Jun-82 10:24:01 PDT (Thursday)
From: stepak.pa
Subject: Notes on InterScript Impl Mtg. - 6/2/82
To: interdoc.pa

General overview of the events of the meeting.  Additions, deletions, and comments are welcome.

Purpose of meeting:  Discuss who will do what, by when, etc.

content doesn't have scope
attributes have scope

---------------------------------------------------------------

	sample:   {para$ a_1 <foo> a_2 <fum>}

	revised sample: { ... {a_1} {text$<foo>} {a_2} {text$<fum>}}
	
Throwing away "cont$"s and all but outer "{"s :

	2nd revised sample:{ ... a_1 <foo> a_2 <fum>  ...}

---------------------------------------------------------------
		
some are bindings, some aren't ...

trees will have: left/right siblings, parent, child(ren)

Structure of each node:
		cont: REF ANY  (ISObj -Interscript object)
		private: REF ANY _ NIL
		context: REF ANY _ NIL
	
structure in script:
			{lhs   mode   value}

	lhs: left-hand-side (text, var1, var2, ...)
	binding mode: (_, $)
	value space: (number, string, 'expression',
		     boolean, expression, node ...)

Could build the dictionary while parsing is going on (tokenizer builds tree...)

string: external representation is in ASCII.

a.b _ 5		"a." would signify what context we're in.

Binding mode:	_	gets
		:	global (associated with root of tree)
			name is declared at the root.
		a:=	'a' is declared globally

need a standard parser tree.
private nodes will be different.

---------------------------------------------------------------

Scenario:

	parser/	-->  editor  -->  some   -->  tree
	 tree	     		  tree	      writer
	 
---------------------------------------------------------------

Jim Mitchell will be away: June 6 -  June 20.
Phil will be away: June 24 - July 7
Jane will be away: June 21 - July 12

Jim Mitchell will start work on a parser/tokenizer when he returns.

*start*
01443 00024 USt
Date:  3-Jun-82 18:34:39 PDT (Thursday)
From: Ayers.PA
Subject: InterDoc Meting Bayhill 100G 9:00 Friday 4 June
To: Interdoc

Brief synopsis of the previous meeting:

We define, with Gael Curry:

  "essence" -- those aspects of a document which survive pagination.
  "substance" -- those aspects of a document which survive filing and mailing.

We now define

  "artifacts" - those aspects of a document which are substance and are not essence.

The previous meeting began with an attempt by Curry and Ayers to have the Script carry the artifacts as "guesses" (recall that a guess is an accelerator that must be considered false).  After working this for a while, the group together came to the realization that we were playing around and that the "artifact" should be a legitimate Interscript construct.

We suggest that there be a tag "Artifact$" which can be applied to a node.  The semantic meaning of this tag is:

  If you, an editor, wish to eliminate artifacts -- that is to delete
  the aspects of a document which do not survive pagination -- then you
  can replace this node by its content.

Thus, to carry the artifact that a word is of style "emphasis" but looks bold, even though emphasis=italic, because the user just changed the style and we have not reformatted the document (a good example, from Gael, of an artifact) you could emit a script

  ... <regular > {Emphasis% {Artifact$ bold% <word >} ...
*start*
01662 00024 US 
Sender: Newton.ES
Date:  9-Jun-82 14:59:08 PDT (Wednesday)
Subject: Review of proposed Xerox character code standard
To: AllES^, AllEOS^.eos, AllPA^.pa
From: The Xerox Character Code Working Group
Reply-To: ESmura, Newton

There will be a meeting to review the proposed Xerox character code standard on Monday, June 14 in El Segundo A&E in room 1494.  It will be from 9am to 12 noon, or at most 4 hours.

The purpose of the Xerox Character Code Standard is to permit multilingual textual information to be stored and transmitted in the form of a sequence of numerical codes. The numerical codes are called character codes and a sequence of them forms the body of what is called a string.  When two information-processing systems agree on a standard interpretation of character codes and a standard format for strings, they may communicate text without danger of degrading its information content.  The particular standard presented here is to be used throughout Xerox Systems.  It is a generalization of familiar ISO and ANSI standards, motivated by the desire to handle symbols beyond simple punctuation and text in languages beyond English.

All organizations with a technical interest in the standard are requested to send a representative to this review.  We would like to restrict attendance to active reviewers, especially since the conference room only holds about 18 people.  If you plan to attend, please reply to this message, so that we may get further information (and copy of the standard) to you before the discussion.
 

/The Xerox Character Code Working Group, chartered by the Printing Standards Subcommittee of the SISB
*start*
00542 00024 US 
Date: 10-Jun-82 13:46:21 PDT (Thursday)
From: GCurry.ES
Subject: Documents, Editors and Interchange (terms)
To: Ayers.pa, Stepak.pa, Karlton.pa, deLaBeaujardiere.pa
cc: InterDoc.pa

I Star-mailed you a draft document of some of the terminology that we have been using to talk about documents lately.  This is not the document model description, but a prelude to it.

If someone is going by PARC, I'd appreciate their dropping off a hardcopy for Scott, Jim and Jim.  Otherwise I can make copies tomorrow morning.

Gael
*start*
00620 00024 US 
Date:  2-Jun-82 13:28:45 PDT (Wednesday)
From: deLaBeaujardiere.pa
Subject: Editor-specific info
To: Ayers.pa, GCurry.es, Horning.pa, Mitchell.pa, Stepak.pa
cc: deLaBeaujardiere.pa

1.  On page 33 of Jim & Jim's document ("Towards..."), there is something about an editor "invok[ing] its name as the very first item in the root node..." as a way to transform editor-specific properties into the interchange standard.  I don't understand a word of this.  Can someone shed light?

2.  Editor-specific informations versus private encodings:  is the former a special case of the latter?

	Jean-Marie
*start*
00487 00024 USt
Date: 21-Jun-82 18:06:03 PDT (Monday)
From: Karlton.PA
Subject: InterScript implementation
To: Mitchell
cc: Stepak, Karlton

Jim,

On [Ivy]<Karlton>InterScript>, I have stored ScriptNode.mesa ScriptTree.mesa and ScriptTreeImpl.mesa. I would like to discuss them with you and make whatever changes I need to before I go off to Florida on Thursday for 2 weeks. Is there any chance of that happening? I will be in meetings tomorrow (Tuesday) until about 3:00.

PK
 
*start*
00507 00024 USt
Date: 24 June 1982 1:39 pm PDT (Thursday)
From: Mitchell.PA
Subject: Re: Interscript Documentation Planning
In-reply-to: Ayers' message of 20-Jun-82 20:14:00 PDT (Sunday)
To: Ayers
cc: Interdoc, Geschke

I think that Chuck is giving us good information.  It suggests to me that we
ought to have two growing documents as part of our work, one that will become
the standard and is a reference manual, and one with LOTs of examples and how
to handle them in InterScript.

Jim Mitchell

*start*
01023 00024 USr
Date: 24 June 1982 2:02 pm PDT (Thursday)
From: Mitchell.PA
Subject: Re: InterDoc Meeting Friday 18 June at 9:30 (note slightly later time)
In-reply-to: Ayers' message of 14-Jun-82 15:15:09 PDT (Monday)
To: Ayers
cc: InterDoc

One thing in your minutes bothered me.  I am VERY wary of doing to
InterScript what was done to InterPress, vis., making a tight, non-ASCII private
encoding.  It made some sense for InterPress because a master is really a derived
object.  An InterScript script is NOT a derived object; it is "coin of the realm"
when it comes to editable documents.  Because a script is a primary object that
must necessarily have a long lifetime, it is important that the normal,
interchange encoding be simple and straightforward.  We don't want to be faced
with the very large problem of converting scripts from one private encoding to
another once there are 100,000 Stars in the world and millions of documents in
an antiquated private encoding.  Let's keep it simple.

Jim Mitchell 

*start*
00274 00024 USt
Date: 24 June 1982 2:39 pm PDT (Thursday)
From: Horning.pa
Subject: Re: InterDoc Meeting Friday 18 June at 9:30 (note slightly later time)
In-reply-to: Mitchell's message of 24 June 1982 2:02 pm PDT (Thursday)
To: Mitchell
cc: InterDoc

Hear! Hear!

*start*
00942 00024 USt
Date: 25 June 1982 5:04 pm PDT (Friday)
From: Horning.pa
Subject: Re: Outline of Interscript Standards Document
In-reply-to: Ayers' message of 15-Jun-82 11:26:48 PDT (Tuesday)
To: Ayers
cc: Interdoc


Question one: 

  The Interpress introduction is quite short -- one page.  This seems due 
  to two things: readers already know something about printing, and 
  explanations aren't part of a standard.

  Do we want/need an extended discussion of Interscript and how it 
  fits into the world .. roles of editors, "Interscript is silent 
  on rendering" and the other slides?

Yes, we need it. A start can be modelled on "Towards . . ."


Where does it belong?

NOT in the standard. In a "Companion" or "Tutorial" document.


Question two: 

  Do you like the Interpress arrangement of laying out the language and
  then telling you what it's good for?

Yes, for a standard. Get to the heart of the matter early.

*start*
00654 00024 USt
Date: 25 June 1982 5:08 pm PDT (Friday)
From: Horning.pa
Subject: Re: On FormattedPara$ and Friends
In-reply-to: Ayers' message of 17-Jun-82 10:21:32 PDT (Thursday)
To: Ayers
cc: InterDoc


Point one: since the FormattedPara$ contains a Para$, we don't have to call it a
"FormattedPara$", but can call it a "FormattedThing$".

Fine. Or just Formatted$


Point two: . . . This makes one of them redundant.

As discussed this morning, not really. The restriction that a Formatted$ node
contains just two subnodes (each of which may have a large amount of internal
structure) may help considerably in avoiding complexity.

Jim H.

*start*
00614 00024 USt
Date: 29-Jun-82 16:05:58 PDT (Tuesday)
From: Ayers.pa
Subject: <string one > <string two>
To: InterDoc

It would be helpful if we agreed that a sequence of string literals is semantically equivalent to one long string literal which is the concatenation of them.  

E.g. the fragment  " <string one > <string two> " is exactly the same, semantically, as the fragment " <string one string two> ".

Anyone have any trouble with this?

[The above is useful in dealing with encoding issues.  It lets the emitter of a script know that he won't be required to output any very-long literals.]

Bob
*start*
00872 00024 USt
Date: 29 June 1982 4:33 pm PDT (Tuesday)
From: Mitchell.PA
Subject: Re: <string one > <string two>
In-reply-to: Ayers' message of 29-Jun-82 16:05:58 PDT (Tuesday)
To: Ayers
cc: InterDoc

I don't think the fragment  " <string one > <string two> " should be exactly the
same, semantically, as the fragment " <string one string two> ".  

First of all, if the editor wanted them to be one string, it could write them as one
string.  Secondly, a TEXT$ node should be capable of taking a sequence of
strings as its contents (perhaps this solves your problem?).  Thirdly, consider a
node such as

    { PAGEBOX$ <Header string> <Footer string> }

I claim this node has two independent pieces of content, one for a heading, and
one for a footing.  Combining them into one string would be incorrect.

In summary: down with implicit concatenation!

Jim M.

*start*
00317 00024 US 
Date: 29-Jun-82 17:07:16 PDT (Tuesday)
From: GCurry.ES
Subject: Re: Document Models?
In-reply-to: Mitchell.PA's message of 29 June 1982 4:34 pm PDT (Tuesday)
To: Mitchell.PA
cc: GCurry, McGregor.PA, Horning.PA

Scott and I were planning to meet from 9:00 to 11:00.  Let us try for then.

Gael
*start*
00421 00024 USt
Date: 29-Jun-82 17:21:06 PDT (Tuesday)
From: Ayers.pa
Subject: Re: Re: <string one > <string two>
In-reply-to: Mitchell's message of 29 June 1982 4:33 pm PDT (Tuesday)
To: Mitchell
cc:  InterDoc

I totally agree with your example { PAGEBOX$ <Header string> <Footer string> }
and withdraw my unbaked suggestion.  [Especially since I looked at encodings again and the supposed need went away.]

Bob
*start*
01641 00024 USt
Date: 29-Jun-82 17:20:30 PDT (Tuesday)
From: GCurry.ES
Subject: Re: <string one > <string two>
In-reply-to: Mitchell.PA's message of 29 June 1982 4:33 pm PDT (Tuesday)
To: Mitchell.PA
cc: Ayers.PA, InterDoc.PA

I have been having some trouble with this, too.  How about the following point of view:

Bracket notation is supposed to allow us to talk about the "parts" of a document.  Every independent part of a document should be enclosed in brackets, as in
	{ <part> }.
Characters (not runs of text) are (the most basic) parts of a document.  When we wanted to describe the string "some BOLD text", we should have been writing
  {s}{o}{m}{e}emphasis _ TRUE{b}{o}{l}{d}emphasis_FALSE{t}{e}{x}{t}.
I believe that we have been using {c1 c2 c3 ... cn} as an ENCODING for {c1}{c2}{c3}...{cn}.  We plainly need SOME encoding for this common case.  

Suppose for the sake of discussion that we instead choose the encoding
  [c1 c2 c3 ... cn].
Then I view Bob's question (expressed in these terms) as whether 
  [c1...cn][d1...dm] = [c1...cn d1...dm]
to be manifestly true, since it is a question about sequence concatenation (correct me if that is not what you were asking, Bob).

I think your example was a case of true structure in the text (which must not be lost by concatenation).  But in the notation above, the segment
  { PAGEBOX$ {Chapter 2} {InterScript} }
would be represented as 
  { PAGEBOX$ {[Chapter 2]} {[InterScript]} },
which REALLY means
  { PAGEBOX$ {{C}{h}{a}{p}{t}{e}{r}{ }{2}} {...} }.

It seems that sometimes we use
  {c1 ...cn}
to mean {c1}...{cn}, and other times
to mean {{c1}...{cn}}.

Gael
  
*start*
00680 00024 USt
Date: 30 June 1982 9:54 am PDT (Wednesday)
From: Horning.pa
Subject: Re: <string one > <string two>
In-reply-to: Ayers' message of 29-Jun-82 16:05:58 PDT (Tuesday)
To: Ayers
cc: InterDoc

Bob,

I vaguely remember this coming up before, and being answered the other way. I
think the issue had something to do with vague plans to allow the content of a
node to be indexed. Then the question was: How many pieces do you have? Of
course, if a string is NOTHING but an abbreviation for a sequence of character
literals (and specifically NOT a vector of characters), then it still doesn't matter.

Is anyone else's memory better than mine on the topic?

Jim H.

*start*
01241 00024 USt
Date: 30-Jun-82 10:08:41 PDT (Wednesday)
From: Ayers.pa
Subject: Re: <string one > <string two>
In-reply-to: Horning's message of 30 June 1982 9:54 am PDT (Wednesday)
To: Horning
cc: InterDoc

Let me describe the circumstances that caused me to bring this up.

In Interpress, a "string" is a vector of integers.

In the "Xerox encoding" of Interpress, there are several ways of representing a vector of integers, some more compact than others.  In particular, the arrangement with the 377s is compact, but there are some integers (e.g. 255) that cannot be represented usig that arrangement -- if you have such an unfortunate integer in your "string", you have to use a less compact encoding.

Let's just assume that we adopted the Interpress "Xerox encoding" for strings (= vectors of integers) in Interscript.  Now I am asked to build the transducer that converts from the reference encoding form ( < something > ) to the Xerox encoding form ( vector of integers ).  I can't buffer the whole sring, because it might be 100000 characters long.  So I don't know if it contains a 255-character.  So I can't use the nice compact form of the "Xerox encoding" UNLESS I can break up the long string into short pieces.

Bob
*start*
02414 00024 USt
Date: 30 June 1982 10:39 am PDT (Wednesday)
From: Mitchell.PA
Subject: Re: <string one > <string two>
In-reply-to: GCurry.ES's message of 29-Jun-82 17:20:30 PDT (Tuesday)
To: GCurry.ES
cc: Mitchell, Ayers, InterDoc

I basically like Gael's view that a node {c1 c2 c3 ... cn} is an encoding for
{c1}{c2}{c3}...{cn}, but I think it needs an extra level of brackets, i.e., 
{{c1}{c2}{c3}...{cn}}.  In fact, I am now of the opinion that a node {x1 x2 ...
xn} where the x's may be either bindings or values (I am assuming that all
indirections, etc. have been expanded) is equivalent to {{x1}{x2}...{xn}}.  The
implementation that Phil Karlton and I are doing maps the surface syntax {x1 x2
... xn} into the abstract syntax {{x1}{x2}...{xn}}.

In a previous message (reproduced in part below) I outlined some of the more
primitive Interscript nodal tags and their associated (relevant) contents.  That
message is relevant here because I don't agree with Gael's mapping 
    {<some> emphasis_T <bold> emphasis_F <text>}
into
    {{s}{o}{m}{e} emphasis_T {b}{o}{l}{d} emphasis_F {t}{e}{x}{t}} 
Rather, its abstract syntax should be
    {{CHAR$ 's 'o 'm 'e} emphasis_T {CHAR$ 'b 'o 'l 'd} emphasis_F {CHAR$ 't
'e 'x 't}}
where by 's I intend the ASCII character code that corresponds to the character
"s".  

Here is the partial message to which I referred above.

Jim M.
-------------------
Date: 15 Feb. 1982 6:04 pm PST (Monday)
From: Mitchell.PA
To: Interdoc.PA
Subject: First cut at defining some marks and attributes

------------------------------------------------------------------------

Primitive nodes:

A string value <sequence of characters> is syntactic sugar for a node of the form

	{CHAR$ c0 c1 ... cN}  

where the ith character (i in [0..N]) of the original string constant has been
mapped into a number, ci.

Examples: <abcdefg> is the same as {CHAR$  97 98 99 100 101 102 103}

------------------------------------------------------------------------

Text nodes:

Mark: TEXT

Contents:  the evaluated contents of a TEXT node can only be a sequence of
strings of text (or, equivalently, a sequence of CHAR nodes).  It cannot contain
any other kind of nested subnodes.  

Examples:	{TEXT$ <Now is the time for ... party!>}
		{TEXT$ <Now ><is ><the ><time ><for ><... ><party><!>}

------------------------------------------------------------------------

-------------------


*start*
00347 00024 USt
Date: 30-Jun-82 12:24:54 PDT (Wednesday)
From: Ayers.pa
Subject: Abbreviation as a LHS ??
To: InterDoc

What do we say about the following?  [Please correct for any bogus use of the wrong assignment operators]

  abbreviation _ "para.margin" .....  abbreviation _ 17

It seems to me like there is a real problem here.

Bob
*start*
00479 00024 USt
Date: 30-Jun-82 13:44:25 PDT (Wednesday)
From: delabeaujardiere.PA
Subject: Re: <string one > <string two>
In-reply-to: Mitchell's message of 29 June 1982 4:33 pm PDT (Tuesday)
To: Mitchell
cc: Ayers, InterDoc

Re { PAGEBOX$ <Header string> <Footer string> },

I would rather see something like

{ PAGEBOX$ header _ <Header string> footer _ <Footer string> }.

I like the idea that <mighty long string> can become <shorter string1> ... <shorter string n>
*start*
00700 00024 USt
Date: 30 June 1982 3:20 pm PDT (Wednesday)
From: Horning.pa
Subject: Re: Abbreviation as a LHS ??
In-reply-to: Ayers' message of 30-Jun-82 12:24:54 PDT (Wednesday)
To: Ayers
cc: InterDoc

Bob,

Presently, the formal semantics we have written says that the LHS of a binding
is not evaluated. In the example you cite, abbreviation would first be bound to
"para.margin" and later to 17.

There is no great conceptual difficulty in rewriting this part of the semantics, if
there is agreement that this should mean para.margin _ 17 under well-defined
circumstances (identifier bound to quoted expression which has the form of a
name?). The difficulty will be in deciding.

Jim H.

*start*
00622 00024 USt
Date: 30 June 1982 3:30 pm PDT (Wednesday)
From: Mitchell.PA
Subject: Re: Abbreviation as a LHS ??
In-reply-to: Ayers' message of 30-Jun-82 12:24:54 PDT (Wednesday)
To: Ayers
cc: InterDoc

  abbreviation _ "para.margin" .....  abbreviation _ 17

There is no problem here.  The left-hand side of a binding is never evaluated
(except in the sense that a qualified name is "followed" from component identifier
to component identifier).

The same is not true of right-hand sides; e.g.,

 abbreviation _ 'para.margin' ...  para.margin_7   foo_abbreviation+5

would leave foo with the value 12.

Jim M.

*start*
01321 00024 USt
Date: 30-Jun-82 15:43:32 PDT (Wednesday)
From: Ayers.pa
Subject: Re: Abbreviation as a LHS ??
In-reply-to: Horning's message of 30 June 1982 3:20 pm PDT (Wednesday)
To: Horning
cc: InterDoc

My current position (not tightly bound):

1. Right now we do not distinguish between "abbreviations" and "variables" -- that is the usages:

  abbreviation _ "bold _ TRUE" .... <word > abbreviation <word>
  variable _ 17 ...  <word > variable <word>

are the same syntactically, though the usage (the intent) is clearly different.  I see nothing wrong with making sbbreviations syntactically different, both in their definition and in their invokation, if that helps anything.

2. If we would like to abbreviate LHSs, and I see merit in doing that, we clearly need some syntactic arangement to distinguish the abbreviation definition from the LHS use of an abbreviation that should get expanded.

3. I am looking at "encoding" Interscript.  It would be very useful to be able to say that the emitter of a script can take any long token (e.g. "page.margin") and abbreviate it (e.g. to "a1").  But we can't say that until we have an arrangement where I can expand an abbreviation in a LHS.

4. There is no #4 that would offer a concrete proposal to deal with the above.  But I'll throw this out anyway.

Bob
*start*
00964 00024 USt
Date: 30 June 1982 6:00 pm PDT (Wednesday)
From: Mitchell.PA
Subject: Re: <string one > <string two>
In-reply-to: delabeaujardiere's message of 30-Jun-82 13:44:25 PDT (Wednesday)
To: delabeaujardiere
cc: Mitchell, Ayers, InterDoc

(1)  I am of the opinion that values should be stored as attributes only if they
are intended to be inheritable (i.e., have scope).  In the earlier examples given, it
was contents that were being discussed, so I stuck to that paradigm.  The
particular PAGEBOX$ example I gave is also a paradigm of a large number of
examples in which it will make sense to have more than a single string as
contents.

(2)  The latter part of my message said that you could make <mighty long string>
become <shorter string1> ... <shorter string n> in a TEXT$ node, which seems to
be all that is of interest here.  So I claim that gives you the capability you seek
without resorting to changing contents to attributes.

Jim M.

*start*
01157 00024 USt
Date: 30-Jun-82 17:37:57 PDT (Wednesday)
From: Ayers.pa
Subject: Some More on Abbreviations
To: InterDoc

Claim: the "abbreviation" mechanism, which is basically the "variable" mechanism with a little sugar, is slightly peculiar.

Consider
  abbreviation _ "bold _ TRUE".
One would like to assert that this is just like
  variable _ 7
with the quotes being required simply to delimit the RHS, but this isn't really the case.

Consider the parallels
  variable _ 7 ... variable _ variable + 1
  abbreviation _ "7" ... abbreviation _ abbreviation + 1
I believe that the results are that both 'variable' and 'abbreviation' contain the integer 8.  This reinforces the suggestion that the quotes are only necessary to delimit an otherwise-wrongly-parsed RHS ....  

BUT what about:
  variable _ 4 + 3 ... variable _ variable * variable
  abbreviation _ "4 + 3" ... abbreviation _ abbreviation * abbreviation
Does the first yield 49 and the second yield 19?  I think so.

Thus I discover that we have been playing in the area of "strip off the quotes one pair at a time" a la teco, and I, for one, haven't thought things through.

Bob 
  
*start*
00952 00024 USt
Date: 30 June 1982 5:44 pm PDT (Wednesday)
From: Horning.pa
Subject: Re: Abbreviation as a LHS ??
In-reply-to: Ayers' message of 30-Jun-82 15:43:32 PDT (Wednesday)
To: Ayers
cc: InterDoc

Bob,

The decision not to syntactically distinguish between abbreviations and variables
may be wrong, but it wasn't an oversight.

The claim was that this would simplify interchange between editors that had
different ideas about the names for attributes (and even which ones were basic
and which derived), since one could always stick an abbreviation for a
non-standard attribute name at the front of the document
	lineHeight = "font.size+line.leading"

I'm fairly sure that no one has actually attempted to make use of this feature in
non-trivial ways, and it may even be better to attempt to standardize both
concepts and names. But this was seen as a technical quick fix that might avoid
a certain amount of political battling.

Jim H.

*start*
00992 00024 USt
Date: 30-Jun-82 18:04:52 PDT (Wednesday)
From: Ayers.pa
Subject: Re: Abbreviation as a LHS ??
In-reply-to: Horning's message of 30 June 1982 5:44 pm PDT (Wednesday)
To: Horning
cc: InterDoc

Aha! The example I was looking for!  You suggest

  The claim was that this would simplify interchange between editors
  that had different ideas about the names for attributes (and even
  which ones were basic and which derived), since one could always
  stick an abbreviation for a non-standard attribute name at the front
  of the document
	lineHeight = "font.size+line.leading"

But suppose I stick exactly that ^^ abbreviation at the front as you suggest.


First, I'd better not assign into "lineheight". 

Seond, considering the fragment ... temp _ lineHeight * 2 ... I had better
REALLY say
       lineHeight = "(font.size+line.leading)"
This was a well-known 'bug' in the PL/1 implementation of "macros"

Should we take some time/thought and revisit this area?

Bob
 
*start*
00235 00024 USt
Date: 30 June 1982 7:45 pm PDT (Wednesday)
From: Horning.pa
Subject: Re: Abbreviation as a LHS ??
In-reply-to: Ayers' message of 30-Jun-82 18:04:52 PDT (Wednesday)
To: Ayers
cc: InterDoc

True, True, Probably.

*start*
01022 00024 USt
Date: 25 June 1982 4:57 pm PDT (Friday)
From: Horning.pa
Subject: Re: InterDoc Meting Bayhill 100G 9:00 Friday 4 June
In-reply-to: Ayers' message of 3-Jun-82 18:34:39 PDT (Thursday)
To: Ayers
cc: Interdoc

[Sorry this is so late. I had meant to elaborate, but this morning's meeting
suggested that it might still be relevant.]

"Essence/Substance"

I think that it may be more fruitful to look at "equivalence." Two documents may
be equivalent (for some purpose/under some relation) without being identical.
An interesting characterization of transformations and encodings is which
distinctions they preserve, and which they lose. There need not be a strict
ordering on such equivalences (i.e., the equivalence classes under one relation
may be incomparable with those under another).

"Artifacts/Transients"

Presumably the distinction here hinges on whether "accidental" characteristics
are considered part of the document, or merely of the way it is currently being
viewed (rendered?).

Jim H.

*start*
00553 00024 USt
Date: 29-Jun-82 16:38:56 PDT (Tuesday)
From: Ayers.pa
Subject: On Identifier Replacement
To: InterDoc

Q: Given a script with usages of the private (not 'well known') identifier "foo" and no instances of the identifier "x1234", do you get an equivalent script by replacing all instances of the identifier "foo" by "x1234"?

I'm leaning to saying "yes" -- making private identifiers generally replaceable.

That means that the "name" of a style (e.g. 'Emphasis') needs to be captured somewhere other than in the identifier.

Bob

*start*
00444 00024 USt
Date: 29-Jun-82 18:33:54 PDT (Tuesday)
From: Ayers.pa
Subject: Encodings: Prevalence of Small Integers in Scripts
To: InterDoc

The "Xerox Encoding" of Interpress chose to allow integers -4001<i<28768 to be encoded in only two bytes in the master.

Are small integers popular in Interscript?

Should we do something similar?

What is an appropriate range?  [Interpress's was chosen to allow eleven inches in micas]

Bob
*start*
02168 00024 USt
Date: 30-Jun-82 11:44:54 PDT (Wednesday)
From: GCurry.ES
Subject: Re: <string one > <string two>
In-reply-to: Mitchell.PA's message of 30 June 1982 10:39 am PDT (Wednesday)
To: Mitchell.PA
cc: GCurry, Ayers.PA, InterDoc.PA

Let me try to make a case that the extra level of brackets should not be there.

PROPOSED PRINCIPLE: Changing form designations (e.g., styles, looks) in a document should not change its structure (which is content).

PROBLEM: Represent the two strings "some BOLD text" and "some bold text", which are considered to have the same content, but different form.

ALTERNATIVE #1: <c1 ...cn> ::= {c1...cn} ::= {{c1}...{cn}}.
Then if we MUST express "some BOLD text" as
  ...<some> emphasis_T <BOLD> emphasis_F <text>..., we have
  ...{{s}{o}{m}{e}} emphasis_T {{S}{O}{M}{E}} emphasis_F {{t}{e}{x}{t}}...,
which has structure
  ...{{}{}{}{}} {{}{}{}{}} {{}{}{}{}}...;
"some bold text" on the other hand would be represented as
  ...<some bold text>..., which is
  ...{{s}{o}{m}{e}{s}{o}{m}{e}{t}{e}{x}{t}}, with structure
  ...{{}{}{}{}{}{}{}{}{}{}{}{}}.

ALTERNATIVE #2: <c1...cn> ::= {c1}...{cn}.
Then "some BOLD text" would be expressed as
  ...<some> emphasis_T <BOLD> emphasis_F <text>..., we have
  ...{s}{o}{m}{e} emphasis_T {S}{O}{M}{E} emphasis_F {t}{e}{x}{t}...,
which has structure
  ...{}{}{}{} {}{}{}{} {}{}{}{}...;
"some bold text" would be represented as
  ...<some bold text>..., which is
  ...{s}{o}{m}{e}{s}{o}{m}{e}{t}{e}{x}{t}, with structure
  ...{}{}{}{}{}{}{}{}{}{}{}{}....
In this case the structure is constant over changes of form.

I think it is right that {x1...xn} ::= {{x1}...{xn}}.

I am not even taking issue (necessarily) with the definition
  <string> ::= { 's 't 'r 'i 'n 'g }.

The question I am asking instead is whether we have 
a convenient way of talking about a sequence of characters
  (such as ['s 't 'r 'i 'n 'g])
which is not construed as the introduction of structure.

Furthermore,when we speak about text like "some BOLD text" typically,
shouldn't it be expressed as 
  [some] emphasis_T [BOLD] emphasis_F [text],
rather than
  <some> emphasis_T <BOLD> emphasis_F <text>?

Gael 
*start*
01939 00024 USt
Date: 21-Jun-82 11:16:26 PDT (Monday)
From: Ayers.PA
Subject: Minutes of 18 June Meeting
To: Interdoc

The main discussion started on the issue of what "look superscripted" IS and turned into an issue about how things like "bold _ TRUE" interact with fonts.  Points:

  Superscripts are not really "raised and smaller"

  Probably should be a primitive, and not just a style that converts to
  "raised and smaller" because there are complicated printing issues 
  [this point presented by Scott]

  It was suggested that we might find many many primitives if we took
  that tack; so we tried to list many charcter looks similar to superscripted
  in the above sense; we couldn't.

  So we agreed that superscript IS special and deserves its own primitive.

  Ayers tried the line that "there is a (logical) 'superscript' font just
  like there is a (logical) 'strikeout' font -- therefore superscript is 
  a font shift".

  But it was noticed that we don't WANT to handle superscript, or strikeout,
  or bold as a (logical) font shift, because we would dearly like a 
  paragraph containing mixed Helvetica and Helvetica Bold to contain
  mixed TimesRoman and TimesRoman Bold if the USER hits "make it TimesRoman"
  and this requires that, at some level, the boldness be disjoint from the
  font-face.

  So then we realized that we even have a problem with boldness.  Setting
  "bold _ TRUE" is not the same thing as altering the font from "Helvetica"
  to "Helvetica Bold".  

  What does an editor DO when it sees "bold _ TRUE"?  Suppose the current font
  (the actual one used in printing) is "Helvetica Light".  Suppose that the
  current font is "Futura" and there is a "Futura Heavy" but isn't any such
  thing as "Futura Bold".  Whose problem is this?

  Ayers has an action item to check on DIN standards for boldness and italicness.
  [I've forwarded a message from Zack that doesn't sound promising.]


*start*
00792 00024 USt
Date: 20-Jun-82 15:22:51 PDT (Sunday)
From: Ayers.PA
Subject: Interscript 83 Documentation Standards
To: Irby
cc: Interdoc

It seems appropriate to write the Interscript Standard documentation in Star.

  [I thought for quite a while to do it in Bravo, owing to the immaturity
  of the NS8000 net at Bayhill.  Recent events have convinced me to give
  Star a try.  If you want details of the tradeoffs, drop me a line.]

I have stored a documentation template as "McKinley > PubliC Ayers > S. I. S. Section Template"

Owing to the absence of styles in Star, it will be quite difficult to make any typographic or layout changes to the documentation once it has begun.  I therefore ask you to check this template and inform me of any inadequacies/bugs immediately.

Bob
*start*
01578 00024 USt
Date: 15-Jun-82 11:26:48 PDT (Tuesday)
From: Ayers.PA
Subject: Outline of Interscript Standards Document
To: Interdoc

Here is a table of contents from the InterPress 82 Standard:

1. Introduction
2. The Base Language
  2.1 Introduction
  2.2 Types and literals
  2.3 State
  2.4 Operators
  2.5 The Xerox encoding
3. Global Structure and External Interface
  3.1 The skeleton
  3.2 Environments and names
  3.3 Printing instructions
4. Imaging Operators
  4.1 Imaging model
  4.2 Imager state
  4.3 Coordinate systems
  4.4 Transformations
  4.5 Current position operators
  4.6 pixel arrays
  4.7 Color
  4.8 Mask operators
  4.9 Character operators
  4.10 Spacing correction
5. Pragmatics
  5.1 Subsets
  5.2 Numerical precision
  5.3 Error handling
Appendices
  A. References
  B. Types, primitives, and standard vectors
  c. Interpress name registry
Glossary
Index

I suggest that we emulate this arrangement as closely as is appropriate.

Question one: 

  The Interpress introduction is quite short -- one page.  This seems due 
  to two things: readers already know something about printing, and 
  explanations aren't part of a standard.

  Do we want/need an extended discussion of Interscript and how it 
  fits into the world .. roles of editors, "Interscript is silent 
  on rendering" and the other slides?  Where does it belong?

Question two: 

  Do you like the Interpress arrangement of laying out the language and
  then telling you what it's good for?  To me, this seems wrong for a 
  tutorial, but quite proper for a standard.

Bob