*start*
03981 00024 US
Date: 30 Jan. 1981 1:58 pm PST (Friday)
From: VanOrden.EOS
Subject: Press Software
To: Ramshaw.PA
cc: Paeth, Dale, VanOrden
Lyle,
I heard that you are trying to locate all of the Press software sources and
documentation. The following msg summarizes the work that I did a year ago. I
hope that it is useful to you. Some work was done after this by us at EOS to
upgrade the software to run under OS18.
Evelyn
------------------------------------------------------------
Date: 24 Jan 1980 9:47 am (Thursday)
From: VanOrden.EOS
Subject: Changes and Additions to Press Software
To: Maleson.PA, Butterfield.PA, Geschke.PA, Guibas.PA, Ramshaw.PA,
Starkweather.PA, Watanabe.PA, Wyatt.PA, Damouth.WBST, DMurray.WBST,
Knox.WBST, Roetling.WBST
cc: Lansford, Hains, Dale, VanOrden
The following is a list of changes and additions that were made to the Press
software so that it will (1) run under OS 17; and (2) handle references to remote
files stored on IFS:
A. Changes to "Press":
(1) All BCPL source files were recompiled under OS 17
(2) OS-17-compatible BFS and TFS "br" files were obtained from MAXC
(3) "PressInitUtils.bcpl" was changed to accomodate the OS 17 changes of TFS
(4) "PressInit.bcpl" has a new routine called "StripServerDir" which strips the
server-name/directory-name, if present, from the file names in the External File
Directory Part of the press file
B. New "PreProcess" Program:
A new program called "PreProcess" has been developed for the purpose of
retrieving with FTP the files that are specified in the External File Directory
Part of the press file. Here is the new sequence of operations that now occur
when running "Press" as a server:
(1) "EFTP" receives a press file over the Ethernet and places it in on the Diablo
(2) "PreProcess" examines the press file for an External File Directory Part
(3) "PreProcess" retrieves with the FTP package each file specified in the
External File Directory Part into contiguous files on the Trident (T-80 or T-300)
(4) "Press" is invoked to print the press file
(5) "TFU" is invoked to delete files from the Trident that were retrieved with
"PreProcess"
(6) Repeat steps (1) through (5)
Note: If a press file does not contain an External File Directory Part, steps (3) and
(5) are skipped
C. Changes to "MakePress":
"MakePress" is a program written by Joe Maleson which creates a press file
containing printing specifications for AIS data. Here is a list of the changes:
(1) A more convenient menu was created
(2) Longer input file names are handled so that there is room for a
server-name/directory-name (only 20 characters were allowed previously; the
limit is now 255)
(3) The server-name/directory-name, if present, is stripped from the file names
for the "GetDotsFromFile" entities**
(4) The default values for the Halftone Screen Angles were changed
**D. Conventions for Programs that Build Press Files
(1) REMOTE FILE NAMES may appear only in the External File Directory Part
of the press file. File names appearing in other places (i.e. in the
"GetDotsFromFile" entities) must be LOCAL FILE NAMES.
(2) The format for REMOTE FILE NAMES is as follows:
"[servername]<dirname>filename" (without sub-directory(s))
"[servername]<dirname>subdir>filename" (with sub-directory(s))
Everything between the "[" and the rightmost ">" is stripped when forming the
LOCAL FILE NAME.
E. Where to Obtain Everything:
(1) Press.Run [xeos]<press>Press.Run
Press sources [xeos]<press>sources>PressSources.dm
Press brs [xeos]<press>br>PressBrs.dm
Press cms [xeos]<press>sources>PressCms.dm
(2) PreProcess.Run [xeos]<press>preprocess>PreProcess.Run
PreProcess sources [xeos]<press>preprocess>PreProcess.dm
(3) MakePress.Run [xeos]<press>makepress>MakePress.Run
MakePress sources [xeos]<press>makepress>MakePress.dm
Evelyn Van Orden
------------------------------------------------------------
*start*
00911 00024 US
Date: 11 March 1981 11:34 am PST (Wednesday)
From: Ramshaw.PA
Subject: Press 2.15 release
To: Dale.EOS, Hains.EOS, Warnock, GWilliams, Paeth.EOS, Starkweather
Reply-To: Ramshaw
cc: Ramshaw
Glen Williams is asking to check out the Press sources to do some work for
Starkweather. Hence, I was finally moved to make a decision about the
positioning of characters with respect to objects and rectangles, to resolve
the controversy between the ObjectStyle and 2.14 bootleg versions that
have been floating around. At Dale's request, I decided in favor of the
ObjectStyle rule: it seems to make SIL drawings using Template look better,
even though my experiments lead me to believe that the 2.14 rule is actually
the "correct" rule from a theoretical point of view.
Hence: Press 2.15 is now released, implementing the ObjectStyle rule, on
[Maxc2]<Press>. Take it away, Glen...
Lyle
*start*
01666 00024 US
Date: 20 March 1981 3:07 pm PST (Friday)
From: Ramshaw.PA
Subject: Press bug fix
To: Dale.EOS, Warnock, Hains.EOS, Paeth.EOS, Starkweather, ABell, Petit
Reply-To: Ramshaw
cc: Pasco, Thacker, Baskett, Swinehart, Suzuki, GWilliams, Ramshaw
Folks, version 2.16 of press is hereby released by Glen Williams and myself.
The major change is a bug-fix related to color VLSI plots as follows: for
complicated reasons related to leftovers and priority overlay order, every
time that the current hue, saturation, or brightness is changed in a Press
file, a new value of a quantity called the "sync code" is generated. The
old Press was simply assuming that the sync code would never get higher
than 10,000. And largish VLSI plots produced by Icarus and by Chipmunk
were running afoul of this unstated and unchecked limit, causing rectangles
to drift down the page, sometimes getting lost and sometimes turning black.
The new Press has upped the limit to 32,750 and is supposed to give you
an error message (by falling into Swat) if you exceed this bound. With
work, it might be possible to raise the bound from 32K to 64K, but I'm not
going to do this unless pushed (and maybe not even then). Thus,
producers of very large color VLSI check plots would be well advised
to output their rectangles in groups that are the same color, instead of
resetting the hue, saturation and brightness between every two rectangles.
(Note that the latter approach involves three new sync codes
per rectangle in the current implementation, not just one!)
Press maintainers: retrieve the new Press.run, Press.syms, AND Press.Errors
from [Maxc2]<Press>,
Lyle
*start*
01751 00024 US
Date: 30 March 1981 6:43 pm PST (Monday)
From: Ramshaw.PA
Subject: Press 3.0 is released
To: Hunt, Dale.EOS, Warnock, Paeth.EOS, GWilliams, Starkweather, Geschke, Orr
Reply-To: Ramshaw
cc: Ramshaw
Press 3.0 is now out on [Maxc2]<Press>; just some more bug fixes and minor
features. (I changed major versions from 2 to 3 just to give the illusion of
progress.)
Changes:
i) Bob Hunt contributed some fixes to the Versatec code for empty pages, and
also new things for his TC200 printer.
ii) Glen Williams and I fixed the microcode bitmap rotator: heaven only knows
how the old one ever worked, if it ever did. (And we only used up one of the
two free locations in the RAM...)
iii) I offer you a NEW FEATURE (at the request of Bob Hunt), in particular,
a new command line switch. If you say "Press/L", then Press will determine
what pixels a rule covers by a method that guarantees that all rules of the
same mica width (or height) will come out the same number of pixels wide
(or high), regardless of where they are positioned on the page. This property
is valuable for printing SIL graphics on low resolution devices, for example.
Unfortunately, any method of scan converting that has this property cannot
also have another critical property: namely, that a page covered precisely once
by rules in mica-space will have each pixel covered exactly once as well.
Thus, Press/L will handle SIL graphics rather well, but will do horrible
things to John Warnock-style images built up out of lots of little Show-Dots.
Conversely, the standard Press (without /L) will make John happy, but
would make SIL graphics on low-resolution printers look worse. Now you
can pay your money (to me?) and take your choice.
Lyle
*start*
05384 00024 US
Date: 1 April 1981 5:22 pm PST (Wednesday)
From: Lansford.EOS
Subject: Pressing
To: Putman.PA
cc: Hains, GWilliams.PA, VanOrden, Lansford
Following is a summary of work done to make Puffin life easier.
The idea was to build Press files with references to External Files, typically
containing high resolution scanned images. The externally referenced files would
be FTP'ed to the Press printer, printed by Press and deleted.
Joe Maleson had already added an External File Directory to the Press file
format, but some necessary machinery had not been implemented. Changes were
made to:
Press, by Van Orden and Lewis
MakePress, Van Orden
PressEdit, Lansford
Smalltalk, Paeth
and a new program, PreProcessor, written by Van Orden. The Press changes are
believed to have gone in the OS18 release. The PressEdit changes were also
released. The MakePress, PreProcessor and Smalltalk changes have not gotten out.
propose to have Chuck Hains officially release the changed MakePress, and
Evelyn do the same for PreProcessor. When Alan resurfaces, we'll work out
something there. We will try to get this done by Monday.
MakePress and the Smalltalk stuff is important because as far as I know, they are
the only way to make a Press file containing External File references.
You need a Press disk with TFU.run, EFTP.run, PreProcess.run, Press.run and
PressServer.cm
Past history
*start*
03980 00024 US
Date: 30 Jan. 1981 1:58 pm PST (Friday)
From: VanOrden.EOS
Subject: Press Software
To: Ramshaw.PA
cc: Paeth, Dale, VanOrden
Lyle,
I heard that you are trying to locate all of the Press software sources and
documentation. The following msg summarizes the work that I did a year ago. I
hope that it is useful to you. Some work was done after this by us at EOS to
upgrade the software to run under OS18.
Evelyn
------------------------------------------------------------
Date: 24 Jan 1980 9:47 am (Thursday)
From: VanOrden.EOS
Subject: Changes and Additions to Press Software
To: Maleson.PA, Butterfield.PA, Geschke.PA, Guibas.PA, Ramshaw.PA,
Starkweather.PA, Watanabe.PA, Wyatt.PA, Damouth.WBST, DMurray.WBST,
Knox.WBST, Roetling.WBST
cc: Lansford, Hains, Dale, VanOrden
The following is a list of changes and additions that were made to the Press
software so that it will (1) run under OS 17; and (2) handle references to remote
files stored on IFS:
A. Changes to "Press":
(1) All BCPL source files were recompiled under OS 17
(2) OS-17-compatible BFS and TFS "br" files were obtained from MAXC
(3) "PressInitUtils.bcpl" was changed to accomodate the OS 17 changes of TFS
(4) "PressInit.bcpl" has a new routine called "StripServerDir" which strips the
server-name/directory-name, if present, from the file names in the External File
Directory Part of the press file
B. New "PreProcess" Program:
A new program called "PreProcess" has been developed for the purpose of
retrieving with FTP the files that are specified in the External File Directory
Part of the press file. Here is the new sequence of operations that now occur
when running "Press" as a server:
(1) "EFTP" receives a press file over the Ethernet and places it in on the Diablo
(2) "PreProcess" examines the press file for an External File Directory Part
(3) "PreProcess" retrieves with the FTP package each file specified in the
External File Directory Part into contiguous files on the Trident (T-80 or T-300)
(4) "Press" is invoked to print the press file
(5) "TFU" is invoked to delete files from the Trident that were retrieved with
"PreProcess"
(6) Repeat steps (1) through (5)
Note: If a press file does not contain an External File Directory Part, steps (3) and
(5) are skipped
C. Changes to "MakePress":
"MakePress" is a program written by Joe Maleson which creates a press file
containing printing specifications for AIS data. Here is a list of the changes:
(1) A more convenient menu was created
(2) Longer input file names are handled so that there is room for a
server-name/directory-name (only 20 characters were allowed previously; the
limit is now 255)
(3) The server-name/directory-name, if present, is stripped from the file names
for the "GetDotsFromFile" entities**
(4) The default values for the Halftone Screen Angles were changed
**D. Conventions for Programs that Build Press Files
(1) REMOTE FILE NAMES may appear only in the External File Directory Part
of the press file. File names appearing in other places (i.e. in the
"GetDotsFromFile" entities) must be LOCAL FILE NAMES.
(2) The format for REMOTE FILE NAMES is as follows:
"[servername]<dirname>filename" (without sub-directory(s))
"[servername]<dirname>subdir>filename" (with sub-directory(s))
Everything between the "[" and the rightmost ">" is stripped when forming the
LOCAL FILE NAME.
E. Where to Obtain Everything:
(1) Press.Run [xeos]<press>Press.Run
Press sources [xeos]<press>sources>PressSources.dm
Press brs [xeos]<press>br>PressBrs.dm
Press cms [xeos]<press>sources>PressCms.dm
(2) PreProcess.Run [xeos]<press>preprocess>PreProcess.Run
PreProcess sources [xeos]<press>preprocess>PreProcess.dm
(3) MakePress.Run [xeos]<press>makepress>MakePress.Run
MakePress sources [xeos]<press>makepress>MakePress.dm
Evelyn Van Orden
------------------------------------------------------------
*start*
00517 00024 US
Date: 2 April 1981 9:26 am PST (Thursday)
From: Lansford.EOS
Subject: Pressing
To: Putman.PA
cc: Hains, GWilliams.PA, VanOrden, Lansford
Update:
If you're in a hurry, retrieve MakePress, PressServer.cm and PreProcess from
[xeos]<press>.
Chuck says that he has had trouble getting recent Press' to print the files created
by MakePress. He wants to look into this re: the March 30 version. He also wants
to make some minor changes that should be done in a week.
Will keep you posted.
Bob
*start*
01057 00024 US
Date: 12 April 1981 9:10 pm PST (Sunday)
From: Ramshaw.PA
Subject: Press 3.2 is released
To: Hunt, Dale.EOS, Warnock, Paeth.EOS, GWilliams, Starkweather, Geschke
To: Orr, Dahlquist
cc: Ramshaw
Folks, Press 3.2 is hereby released (there was no version 3.1). Only a few
minor patches this time; this release is mostly to provide a stable base
for Glen Williams's hacking to come. Changes:
- Press now checks to see if bank 1 exists on your XM Alto before
deciding to use it to put the character rasters in
- during installation, Press asks Versatec users whether they would
like the top or the left edge of their pages to emerge first
(the analogue for Versatec's of the "landscape/portrait" question)
- the limit on the number of ShowDots that affect a single band has
been increased a little, from 30 to 120; but don't expect high
performance, please, since if there are more than 4 ShowDots
that image in a single band, Press will be getting to them
by repeatedly opening and closing files (!)
Lyle and Glen
*start*
00932 00024 US
Date: 22 May 1981 3:20 pm PDT (Friday)
From: putman.PA
Subject: makepress
To: gwilliams
cc: putman
here it is
---------------------------
Date: 1 May 1981 2:34 pm PDT (Friday)
From: Hains.EOS
Subject: MAKEPRESS
To: KNOX.WBST, PUTMAN.PA
cc: Lansford
Thanks to NWong, there is a new version of Maleson's MakePress on
[RoseBowl]<Press>Makepress.run. Please try it if you need a makepress.
We should be releasing it soon.
Changes include automatic entry of file size, rotation, & Bitsize, as well as
automatic sizing calculations to retain x-y square ratio.
Also note output inches is X100 instead of X10, and that output now defaults to
one-to-one pixel to printer unit.
A high precision calculation for press micas is made in the special default case of
one-to-one.
Chuck.
------------------------------------------------------------
------------------------------------------------------------
*start*
00513 00024 US
Date: 28 July 1981 5:42 pm EDT (Tuesday)
From: Sauvain.WBST
Subject: Wabash is available!
To: @WabashInterest.dl
Reply-To: Sauvain
We are pleased to announce the availability of a public release of the Wabash
Mesa-based press printing software.
Wabash is now available to Webster area users on a regular basis on the Tioga
server. It is also available in disk image form for remote users to try out.
For more details, see [ERIE]<Express>Wabash>HowToUse.press and
Installation.press.
*start*
00788 00024 US
Date: 4 Aug. 1981 6:47 pm EDT (Tuesday)
From: Sauvain.WBST
Subject: Wabash Sources
In-reply-to: GWilliams.PA's message of 3 Aug. 1981 4:55 pm PDT (Monday)
To: GWilliams.PA
cc: Sauvain, DMurray
Sure - source for the current Wabash system is stored on [ERIE]<Express> in
several dump files. Suggest you load FetchWabash.cm from the dump file
[ERIE]<Express>Wabash>GenWabash.7-28-81.dm, and execute as much of it as
you want (login as Sauvain, password Green). This will pull all the Wabash
source onto your disk. May take 2000 Diablo pages or so, there are currently 71
modules with a total of 15000 lines of code.
Dump file names are suggestive of function, I can perhaps provide path finding
help if there are specific areas of interest.
Richard Sauvain
*start*
01826 00024 US
Date: 28 July 1981 1:38 pm PDT (Tuesday)
From: Deutsch.PA
Subject: BitBlt specification
To: LRG↑
cc: ISL↑, Lyon
Reply-To: Deutsch
Dick Lyon has made the following interesting point about the specification of
BitBlt. (At least, it's interesting to me -- maybe you knew about it all along.)
Our current BitBlt takes three parameters D(estination), S(ource), and P(attern),
and assigns (pixel-by-pixel)
D ← func(D, S & P).
P is of fixed size, is replicated as necessary to match the size of S, and is aligned
in a particular way with D. However, if one is working with objects of arbitrary
shape, one would like to replace the P argument by a true mask which defined
the (filled) outline of the source shape. Calling such an argument M, the
desired operation of BitBlt would be
D ← if M than func(D, S) else D,
i.e. only change D at the points selected by M. At present, one can fill arbitrary
outlines with a stipple pattern by letting S = the filled outline and P = the
pattern, but one can't do operations with shapes defined by a non-rectangular
outline.
It seems to me that the D-S-M specification is more useful than the present
D-S-P arrangement. If you have D-S-M and want D-S-P, you can still fill
rather large areas (rectangular or not) quickly with stipple patterns by repeated
calls on BitBlt starting with a pattern of modest size (like the present 16 x 16); I
don't know whether other uses of the stipple pattern have turned out to be
useful, but I suspect not. On the other hand, if you have D-S-P and want to
simulate D-S-M, you have to create an auxiliary bitmap A and do something like
A ← D.
A ← func(A, S).
A ← A & M.
D ← D & not M.
D ← D or A.
If D-S-M is really better than D-S-P, it's too bad we didn't specify it that way
for the release. What do you all think?
*start*
02021 00024 US
Date: 29 July 1981 10:40 am PDT (Wednesday)
From: Ingalls.PA
Subject: Re: BitBlt specification
In-reply-to: Your message of 28 July 1981 1:38 pm PDT (Tuesday)
To: Deutsch
cc: LRG↑, ISL↑, Lyon, Ingalls
Reply-To: Ingalls
There are certainly some nice aspects to Dick's proposal, but I'm not bothered by
the spec that we put out. I find it hard to evaluate the masking spec without
having to live with it. The plusses and minusses which come to mind are:
Plusses:
1) This is certainly what one wants for animation. However, all animation I've
played with has been amenable to implementation with 2 BLTs per image; the
first does DEST & notMASK (mask being the hull of all solid colors), and the
second does DEST or FIGURE. Still, a factor of 2 is always nice.
2) Another application of significance is cursors with opaque white (this is
especially nice when you work with solid blacks. This falls in the same 2-BLT
category as animation above. Speed can be important here to avoid flicker by
doing it during retrace.
Minusses:
1) There is some strategy to be worked out for doing our current grays - do we
stick with 16x16 patterns, or allow any size. If the latter, then there's more logic
in the areal repetition.
2) If you really mean many 16x16 BLTs to fill an area with gray, this may be a
lot of overhead for setting up. Avoiding that overhead is just more logic.
3) Also, what about the gray seaming? The D-S-M spec leaves S as general
purpose, so that some other mechanism is needed to handle the alignment -
either another parameter to specify it, or some special preparation at a higher
level.
4) Finally, the inner loop needs more state and more per-word overhead to
stream through the mask. I can imagine ways around this when the mask is
known to be just a gray pattern but, again, it's more logic.
Overall, I think I like what we've got. I'd say if someone's in an NIH mood, we
should encourage them to try the other way, and see how they like it when
they're done.
*start*
01688 00024 US
Date: 24 Sept. 1981 2:26 pm PDT (Thursday)
From: Pasco.PA
Subject: Introducing: Ramtek Color Impact Printer
To: VLSI↑, ISL↑, CSL↑, LilacLovers↑, LSIInterest↑, RamtekUsers↑
Reply-to: Pasco
An alternative color printer is now in operation in the VLSI System Design Area
"Purple Lab", room 2015B. It's a Ramtek 4100 color impact printer, having four
nine-wire ballistic print heads (each with a different colored ink ribbon) on a
moving carriage. It prints 70 dots per inch on 15" by 11" paper.
A public distribution list, RamtekUsers↑ has been created. If you wish to
receive further announcements on the subject, please use Maintain to add
yourself to RamtekUsers↑.PA.
A simple interface program, Aries.run, is now available to drive the printer
from ".ram" format color-bitmap files. Work is underway to create a Magic
output module to generate ".ram" files from LSI layout files (e.g. CIF, Icarus).
(The scenario is fully analagous to the Magic Versatec ploting system where
Oliver.run drives the Versatec plotter from ".bits" format black-and-white
bitmap files.) People wishing to write other software to generate ".ram" files
will find the format documented in [Ivy]<Pasco>Plotting>RamFileFormat.Press.
An Alto II, with network name "Color" is interfaced with the 4100. A disk
labelled "Pasco Ramtek" is maintained with a current copy of Aries.Run. For
now, the procedure to print a file is to walk to Color, (on the Color keyboard)
FTP-retrieve your ".ram" file, then type "Aries <name>.ram". For demonstration,
there exists a sample file on the disk called "foo.ram".
Any volunteers wanting to bring up Press would be welcome.
Rich Pasco
*start*
00844 00024 US
Date: 12 Oct. 1981 3:13 pm PDT (Monday)
From: Stone.PA
Subject: AIS
To: Knox.wbst
cc: Zack.wbst, ISL↑.PA
Reply-To: Stone
Keith,
I have written a Pilot/Mesa 6 version of the AIS file read/write routines as
described in chapter 3 of the AIS manual. I support everything except the
following features: multiple samples/pixel, pack/unpack, bits/pixel other than 2,
4, 8, and 16, trident disks. I have tried to remain true to the BCPL version,
making only small, clarifying changes in the calling procedures where I felt the
old form was due to BCPL limitations.
The code is on [ivy]<stone>ais>AIS.mesa, AISFormat.mesa, AISImpl.mesa. It has
not been extensively tested yet, and may undergo a clean-up and
bullet-proofing step at some point.
Please feel free to make comments, criticisms, suggestions...etc.
Maureen
*start*
00998 00024 US
Date: 5 Oct. 1981 10:37 am PDT (Monday)
From: Stroll.ES
Subject: Graphics composition/page makeup
To: electronicpublishinginterest↑.pa
cc: Stroll.ES
Reply-To: Stroll.ES
We've recently issued a report on image processing/manipulation for graphics
composition and page makeup that could be of some interest to you. The
particulars are:
Authors: Stroll, Zoltan, et al.
Accession No.: S81-00026
Abstract: This study introduces post scan image processing system concepts for
graphics composition / page makeup, complete with electronic image data
resampling (scaling/resolution conversion, rotation, filtering), masking, cropping,
halftoning, and decoding functions. Two competing system designs are
presented, including system intelligence partition, performance estimation, and
tradeoff analysis.
Security Classification: Private Data
You can obtain a copy from the Xerox Library. Please channel any feedback you
may have to me via Laurel or mail (A3-79).
Zoltan
*start*
01907 00024 USm
Date: 14 Oct. 1981 11:00 am PDT (Wednesday)
From: Ramshaw.PA
Subject: Mesa mod and Stinger's fonts
To: GWilliams
cc: Warnock, Ramshaw
Glen,
Part 1:
On the issue of computing D: you came to me yesterday afternoon with a
problem because you had implemented my 'mod' by just calling the Mesa 'mod'
function, and that didn't work on negative arguments. I recommended fixing
this hassle by implementing 'mod' correctly. In fact, in this particular case,
there is an easier way to proceed. What we are trying to do is to compute
D = ((xvyu)) mod L.
Well, it turns out the you can prove that the inquality
|xvyu| < L
will always hold. Thus, in this particular case, you don't need to call any flavor
of 'mod'; just do the following:
begin
. . .
z←(xv-yu);
if z<0 then z←z+L;
D←z;
. . .
end.
Point 2:
Julian commented to me in the hall that Stinger is now running at 384, and
hence will be able to handle all the real fonts. Here is what you should do
when it comes time for updating Stinger's font dictionary:
(i) You want to include splines in the dictionary, since Stinger runs
Press, and hence can make use of them.
(ii) You also want to include all the standard rasters, rotated correctly for
a printer that scans up the page.
(iii) But you can't allow this dictionary to include any MultiChars IX'es,
since Press can't handle them.
This means that we don't really have a good dictionary for the new Stinger
currently on line:
Lilac's dictionary has the rasters in the wrong rotation.
Clover's dictionary has MultiChars IX'es, and doesn't have splines.
Giving it a few moments thought, I think that the best plan for building a font
dictionary for the new Stinger is:
Start with Clover's dictionary, and run my RotateDict over it with a
rotation of 0. This will get rid of the MultiChars IX'es. Then, merge in
Splines.Fonts.
Lyle
*start*
00134 00024 US
Date: 21 Oct. 1981 4:09 pm PDT (Wednesday)
From: GWilliams.PA
Subject: Press Password
To: GWilliams
BEADGCF
*start*
00629 00024 US
Date: 4 Dec. 1981 3:48 pm PST (Friday)
From: GWilliams.PA
Subject: New "Press" Release
To: ComputerResearch↑.pa, Dale.EOS, Bain.Dlos, Fisher.es
cc: GWilliams, Ramshaw
Reply-To: GWilliams
Folks,
Press 3.4 is hereby released. Lyle and I fixed the bug [now don't throw bricks] in
Press that we introduced 3 versions ago in fixing a "color change" bug. It caused
Press to break on complicated documents with many fonts.
Please feel free to ship "Press" files to either Stinger or Lilac (in Palo Alto) of
extraordinary length and complexity. Press can handle them now.
Humbly,
Glen Williams
Lyle Ramshaw
*start*
04347 00024 US
Date: 20 Jan. 1982 11:47 pm PST (Wednesday)
From: Ramshaw.PA
Subject: Press 3.7 and PrePress 2.5 are released
To: Baskett, Petit, Wilhelm, Dale.EOS, ISL↑.pa, Orr, DBrown
To: Hunt, Geschke, Starkweather, Pellar.EOS, LaPrade.EOS
cc: Ramshaw, GWilliams
Reply-To: Ramshaw, GWilliams
------------------------------------------------------------------------------
[Maxc]<Press>Press.Run, Press.Syms, and Press.Errors (all three!):
------------------------------------------------------------------------------
Yet another new version of Press is available, calling itself version 3.7 (3.6 was
never released). The new features are:
i) If your file asks to be printed in Transparent mode, an arbitrary
number of color changes are allowed. For non-Transparent files,
the limit is still 64K color changes.
ii) There is a new switch, Press/F. This switch asks Press to be picky
about font matches. If it is set, Press will call Swat once for each
font request in your Press file that cannot be "perfectly" matched,
telling you the family, size, face, and rotation of the offending
request.
By now, there are quite a few switches that Press recognizes, and many of them
are probably generally unknown. Here is a list of this switches whose existence
is suggested by a quick glance at the code; I am not promising that all of these
switches actually work as I have described, of course...
From the command line:
/C - do only the "C" pass.
/D - debug: if installed for Slot device, ship output raster to the
display, a screenful at a time.
/F - be picky about font matching: call Swat with an announcement of
each font request that can't be "perfectly" matched. Continuing
with ↑P will substitute the best match found.
/I - install.
/L - go for local fidelity rather than global fidelity: see discussion below.
/M - do metering.
/O - don't try and merge rasters on the fly with the Orbit; that is,
do a software scan conversion ("C" pass) even if it doesn't seem
to be necessary.
/P - do only the "P" pass.
/R - bit-reverse each scan-line before printing it, hence generating
a mirror-imaged image.
/S - do only the "S" pass.
/T - please print in Transparent mode: each new printing
command simply adds more ink to the page, rather than
later imaging commands overlapping and obscuring
earlier ones.
/U - don't use microcode.
/V - be verbose about error conditions.
Four of these switches can also be requested from word 14b=12. of the document
directory: N, R, and T have the same meaning as above, while S is used instead
of O in this context.
Discussion of /L semantics, Local Fidelity versus Global Fidelity:
Consider a rectangle that the Press file has specified with mica
coordinates, either to be imaged in some color or to be the frame of some
Show-Dots. Press normally defines a pixel to be "inside" this rectangle if and
only if its center is inside the ideal mica-sided rectangle. This definition has the
pleasing property that, if the Press file contains a collection of rectangles that
partition the plane, then each pixel in the image will be "inside" one and only
one rectangle. This property is crucial for the kind of Press file produced by
John Warnock's code.
Unfortunately, this definition also has the property that rectangles of the
same mica height and width in different locations can end up having different
pixel heights and widths. At low resolutions, this quantization effect can be
annoying, since the lines in your SIL diagrams will be different numbers of
pixels in width.
If you give Press the /L switch, then the width and height of each
rectangle are quantized independently of the rectangle's position. This technique
strives for local fidelity, and will make SIL diagrams and the like look better. It
is not the default condition because the resultant gaps and overlaps of adjoining
rectangles make John Warnock's style of Press file look execrable.
------------------------------------------------------------------------------
[Maxc]<Alto>PrePress.Run, PrePress.Syms:
------------------------------------------------------------------------------
Version 2.5 of Prepress is released; the new version properly rounds points to
micas when accepting sizes from the command line, instead of truncating.
Lyle
*start*
00885 00024 US
Date: 15 Jan. 1982 2:11 pm PST (Friday)
From: Ramshaw.PA
Subject: Press version 3.5 is released
To: Baskett, Petit, Wilhelm, Dale.EOS, ISL↑.pa,
cc: Ramshaw, GWilliams
Reply-To: Ramshaw, GWilliams
Glen and I are hereby releasing Press 3.5, which is available on [Maxc]<Press>
as usual. The changes are:
i) longer font directories will make it past PreFontMake in some cases
ii) up to 64K color changes are allowed, rather than only 32K.
I suspect that it might be possible to allow an arbitrary number of color changes
for Press files that ask to be printed in Transparent mode (such as plots of
integrated circuits), but my first attempt to make that work failed, and I have not
yet gone back to figure out why. If anyone starts to be bothered by the current
64K limit on Transparent files, please let me know and I will consider trying
harder.
Lyle
*start*
01530 00024 US
Date: 30 Jan. 1982 11:27 pm PST (Saturday)
From: Ramshaw.PA
Subject: Press version 3.8 is released (VLSI version)
To: Baskett, Petit, Wilhelm, Dale.EOS, Hunt, ISL↑.pa, Swinehart, Orr, DBrown
cc: Thacker, Ramshaw, GWilliams
Reply-To: Ramshaw, GWilliams
Yet another version of Press is hereby released, on [Maxc]<Press>:
i) The limit on the number of buffer-loads of band entries that
can be generated during the S pass for one page has been
raised from 100 to 150.
ii) The code for merging these buffer-loads together into the
final bands lists has been corrected, simplified,
and shortened. The new version works correctly even
when the merging tree has height greater than 2.
Change (ii) was essential for imaging Forest Baskett's data path chip design. The
data path chip image generates 83 buffer-loads of bands list (at about 8K words
per load). The in-degree of the merging tree is set at 8; hence, any image with
more than 64 buffer-loads causes a merging tree of height 3.
Dan Swinehart ripped the same buggy old merge code out of Spruce long ago,
and replaced it; but his replacement only handles a single four-way merge, not
a general merging tree.
A hardcopy of Forest's chip is on the wall near Lilac. There sure are a lot of
rectangles. Note that a spot on Lilac's drum has wreaked havoc with the circuit
near the lower right-hand corner. It is sobering thought that the folks in ICL
have to avoid faults that are much smaller than that, even proportionately.
Lyle
*start*
01843 00024 US
Date: 2 Feb. 1982 12:15 pm PST (Tuesday)
From: Geschke.PA
Subject: MesaPress file format
To: GWilliams, Warnock
cc: Thacker, Starkweather, Geschke
Glen and John,
Would you please respond to Chuck's last question in the attached msg.
requesting the file format to be used in driving the reticlemaker?
Chuck
---------------------------
Date: 2 Feb. 1982 11:11 am PST (Tuesday)
From: Thacker.PA
Subject: Reticle Generator
To: Starkweather, Geschke
cc: Thacker
In pursuit of parallelism, the following thought occurred to me:
Let us assume that the mechanical changes Gary is now making to the RG do not
work, i.e., the speed of the scanner still fluctuates more than say .2 bit times in
the course of a scan line. If this is the case, no amount of correction that is
measured during one scan and applied during the next will work.
For the entire system to work, it will be necessary to go to a grating clock. This
was originally discarded due to electronic complications, and because of the
belief that the scanner's motion would be smooth, even if the speed was not
precise. Both these assumptions are now questionable.
We should begin to reconsider this approach NOW, not later. If you will tell us:
(a) How many bits there are per grating pulse (the fewer the better), and
(b) How many grating clock pulses there are before the plate exposure starts
(how long we have to lock the bitclock oscillator - the more the better),
we could start the design of a phase-locked bitclock. I do not believe that if the
two numbers are reasonable, we should have too much trouble.
Also, could you (or your designee) tell us what the format of the files you want
to drive the machine with is, so that we can fix Chipmonk to make them?
Thanks
Chuck
------------------------------------------------------------
*start*
03922 00024 US
Date: 2 Feb. 1982 4:37 pm PST (Tuesday)
From: GWilliams.PA
Subject: MesaPress file format (long message)
To: Thacker
cc: Geschke, Warnock, Starkweather, GWilliams
Chuck,
The bit flinger is currently set up to print one-image files.
The format of the file the MesaPress requires is the same as that of Press.bits.
Press.bits has leader information that is followed by the scan lines in block
format.
The leader page is 1024 words in length (page 1 of the Trident file).
The format of the leader page is described by the FirstPage Mesa record below.
FirstPage: TYPE = MACHINE DEPENDENT RECORD
[ nPages: CARDINAL ← 1,
pageGSize: CARDINAL ← SIZE[PageG],
printerMode: CARDINAL, --3=portrait, 8=Landscape
password: CARDINAL ← PressPassword,
pageGs: ARRAY[0..92) OF PageG --enough to fit on a Trident
Page
];
As shown in the initialization, nPages should be set to one. "pageGSize" is 11D
(nD means the number "n" in deciman). "printerMode" should be set to 3 or 8,
depending on the manner in which the page is scanned: 3 if scanned in portrait
mode, 8 if landscape (up the page, lengthwise) mode.
It is necessary to follow the password by one PageG record. This describes
attributes of the page to be printed.
PageG: TYPE=MACHINE DEPENDENT RECORD --Press's PageG Structure
[FirstBand: CARDINAL, --lowest used band
LastBand: CARDINAL, --highest used band
BitMargin: CARDINAL, --Margin and
BitWc: CARDINAL, --word count of scan lines
BandPos: LONG CARDINAL, --File position of band stuff
BitPage: CARDINAL, --File position of bits (units = 1024 words)
CopyCrucial: [0..1), --True if different version needed for
differrent copies
SimplePage: [0..1),
ColorPass: [0..2), --for color printers: 0=magenta, 1=yellow, 2=cyan,
3=black
ColorUsed: [0..1), --true if color used (scan conversion used this)
blank: [0..2048],
PageNumber: CARDINAL, --From original Press file.
nRecords: CARDINAL, --For spruce-like operation
fontLoad: CARDINAL]; --ditto
PressPassword: INTEGER = 27183;
In order to explain the PageG components, it is necessary to describe the format
of the scan data. Scan lines appear in the file in uncompressed format. They are
arranged in blocks of 16 scan lines for historical reasons. Therefore, a block of
scan lines will take some integral number of Trident pages. That part of the last
page of the block that is not used for scan data is ignored by the bit flinger (and
by Press). The next block appears at the beginning of the next Trident page.
For example, if the scan lines are 1600 bits each, one "band", or block, would
require 1600 words of space, or CEILING[1600/1024] = 2 Trident pages. Thus, in a
Press.bits file, the leader page would be the first data page of the file, followed
by two-page band buffers of 16 scan lines each.
Now, the PageG:
The position of the image on the page is controlled by two quantities: FirstBand
and BitMargin. FirstBand is numbered from 1 such that scan line zero appears as
the first scan line of FirstBand. This is used to set the left margin on a landscape
machine, or the top margin on a portrait machine. To start your image at logical
scan address 45 on the page, you would set FirstBand = 3, and zero out the first
12 scan lines' worth of space. Thus the first scan line would be output after the
scanner waits 44 scans.
LastBand is essentially FirstBand+numberOfBandsYou'reOutputting-1.
BitMargin is the number of bits into the page to position the beginning of the
scan; on a landscape machine, this determines the bottom margin, and on a
portrait machine, the left margin. I believe this number is truncated to a multiple
of 32 bits on the new SLOT card.
BitWc this is the count of 16-bit words in the scan line.
Ignore bandPos, CopyCrucial, SimplePage, ColorPass, ColorUsed, blank,
PageNumber, nRecords, and fontLoad.
Set BitPage to 1.
Let me know if you need any other information.
Glen
*start*
00594 00024 US
Date: 20 Feb. 1982 12:05 pm EST (Saturday)
From: Zack.wbst
Subject: VLSI Decompression and Decryption
In-reply-to: Mitchell.PA's message of 19 Feb. 1982 1:20 pm PST (Friday)
To: Mitchell.PA
cc: Marshall, Zack, FontStandards↑
WRC is currently working on a VLSI font decoder for future printers. Dave
Damouth suggests that decryption be built into the chip, but since the design is
already underway (by Sid Marshall), to do so will require fast action. Suppose
we go with the NBS encryption standard. Do you foresee any difficulties with
using it on fonts?
-- Greg
*start*
01612 00024 US
Date: 22 Feb. 1982 10:47 am PST (Monday)
From: Mitchell.PA
Subject: Re: VLSI Decompression and Decryption
In-reply-to: Zack.wbst's message of 20 Feb. 1982 12:05 pm EST (Saturday)
To: Zack.wbst
cc: Mitchell, Marshall.wbst, FontStandards↑.wbst
I'm not sure what a "VLSI font decoder" is supposed to do, but I assume it is a
relatively high bandwidth device (otherwise why not use software?) with
real-time speed requirements. Now a page/second printer with 400 pixel/inch
resolution consumes more than 15Mbits/second (400*400*8.5*11). The fastest DES
chip I know of goes at 10Mbits/second and is a VERY complicated IC. So if my
assumption about the VLSI font decoder is correct, it is not reasonable to put DES
decryption into it as well.
Besides, I see no good reason to keep fonts encrypted up to the point they are
actually used to spew out bits. When a print server acquires a font, it should
decrypt it immediately. After all, the customer is trusting the printer's software
to be correct in a number of ways that are as critical as this (e.g., it doesn't drop
paragraphs or lines of text). Furthermore, if encryption is good for fonts, it is
much better for documents that a company doesn't want to go over the Ethernet
in the clear. Encryption is a function that is useful in a number of ways and
places and therefore ought to be generally available (this argument would be less
strong if the cost and complexity of encryption were comparable to an ALU,
which we do now sprinkle all over rather than attempting to share among
separate pieces of hardware).
Jim Mitchell
*start*
00586 00024 US
Date: 22 Feb. 1982 2:48 pm EST (Monday)
From: Marshall.WBST
Subject: Re: VLSI Decompression and Decryption
In-reply-to: Zack's message of 20 Feb. 1982 12:05 pm EST (Saturday)
To: Zack
cc: Mitchell.PA, Marshall, FontStandards↑
Reply-To: Marshall
The NBS encryption standard is too slow for real-time bit generation of
characters. Decryption algorithms could be used but would enormously
complicate the debugging effort. I think that encryption is a separate issue and
that a uniform approach towards protecting fonts, software, files etc. be adopted.
--Sidney
*start*
01257 00024 US
Date: 22-Feb-82 13:45:48 PST (Monday)
From: Pany.ES
Subject: Re: VLSI Decompression and Decryption
In-reply-to: Zack.wbst's message of 20 Feb. 1982 12:05 pm EST (Saturday)
To: Zack.wbst
cc: Mitchell.PA, Marshall.wbst, FontStandards↑.wbst
Reply-To: Pany.ES
Greg, the VLSI Decompressor effort implies that Webster selected a specific compression algorithm. Can you tell us which it is? How suitable is it to handle Kanji characters?
On the subject of font encryption, either the leak is within Xerox or it is without Xerox.
If within, no encryption method can help -- I think.
If without, the question is whether the important information is in the bitmaps themselves or in the whole; I think the time consuming task is to tune the font bitmaps; but, in that case, security is virtually non-existent, as getting to the bitmaps is as easy as intercepting, in the case of the 804x Print Server (Star Print Server) for instance, the video stream running from the Dandelion to the Raven (i.e., as easy as monitoring an easily tapped line). Perhaps we should encrypt the video stream as well! But then, all that has to be done is intercept (optically) the modulated laser beam....
So the idea is interesting, but I am skeptical.
Claude.
*start*
00750 00024 US
Date: 26 Feb. 1982 3:17 pm PST (Friday)
From: Stone.PA
Subject: ShowAis
To: ISL↑
cc: Stone
Reply-To: Stone
Folks,
I have been doing some new packaging on ShowAis, which is the program that
displays the color AIS files on the color monitor on Lexington. The package now
includes John's image processing routines.
Ususal procedure: Run [ivy]<stone>ais>showais.cm (usually resident on
Lexington's disk). This will fetch the relevant files, start up JaM and then load
ShowAis.
If something breaks while running showais.cm, boot the client, then try
running: [ivy]<stone>ais>NewShowAis.cm
which recompiles the world and then proceeds like ShowAis. Let me know if
you have to do this so I can fix ShowAis.cm.
Maureen
*start*
00931 00024 US
Date: 1 March 1982 4:28 pm PST (Monday)
From: McBain.ES
Subject: Img Format Specification
PrintForm: InternalMemo
To: (Distribution)
cc: Harry Isler A2-43 <ESMail>
cc: Chuck Lotstein M1-59 <ESMail>
cc: Tom Melton A2-26 <ESMail>
cc: Ed Regan A1-66 <ESMail>
cc: George Shenoda A2-43 <ESMail>
cc: Bhushan.WBST, Dashiell, Hsieh, Imhoff, Joiner, Manley, Mendelson,
Moulding, Newlin.PA, Ogostalick, WShultz, Warnock.PA, GWilliams.PA, McBain
A technically correct version of the Img Format Specification can be found on
[Oly]<IS>Img.press
There will be no further changes to this format which affect current project
implementation without the approval of the affected projects. There will be a
subsequent release which contains major format changes. For those of you who
reviewed the 24-Feb copy, today's release contains no substantive changes.
Thank you all for your comments and cooperation.
/Dwight
*start*
01742 00024 US
Date: 2 March 1982 6:34 pm PST (Tuesday)
From: paeth.PA
Subject: PreProcess
To: Putman, GWilliams
cc: paeth
I've hacked up the old PreProcess program, so that it has less bugs, likes OS19,
and is easy to use. It can be found on [Ivy]<mpchip>press>PreProcess19.run and
.dm
It's late and I can elaborate later, but basically, typing
PreProcess Foo.press {server} // you don't really type the {}, they are an option
Causes the file Foo.press to be scanned over. IF it is a press file THEN IF it
contains an external file directory THEN IF at lease one of the file names
contained in said directory begins with a '[, THEN IF the microcode load is
successful (it won't be on a D0, but you won't swat either), then the program
goes out to said file on said fileserver, and retrieves it to the trident.
It is rather clever about this, on T300's it looks hard for a suitable logical drive
for the file, in any event, it calls DiskFindHole to find a contiguous spot large
enough for the data, initializes the file, and then copys the external file into it.
Unlike before, the program quits normally, without kludging up rem.cm
It is now the user's responsibility to keep the trident from filling up with .ais
files.
If the optional "server" parameter is specified, then all works as before, except
that the "server" string overrides all server specs contained in file reference.
Please also note that a file with no REMOTE external reference, ie, no "[" isn't
touched, so that a press file referencing, say, FOO.AIS will NOT be retrieved
from IVY, even if one types a
"PreProcess FileContainingFooReference.press IVY"
Happy to talk more. g'nite.
OH YEAH, ITS ALL FULLY UNTESTED!!! (don't got me no alto...)
/Al
*start*
00337 00024 US
Date: 2 March 1982 6:36 pm PST (Tuesday)
From: paeth.PA
Subject: Mesa, Printing, etc
To: GWilliams
cc: paeth
You up on Blanchard and his group at Webster and Wabash printing software
and stuff? I'm rather interested in it, and how it compares to InterPress, your
work, etc etc etc.
Just curious old me.
/Al
*start*
00906 00024 US
Date: 4 Feb. 1982 12:26 pm PST (Thursday)
From: McBain.ES
Subject: Re: Documentation
In-reply-to: GWilliams.PA's message of 3 Feb. 1982 4:28 pm PST (Wednesday)
To: GWilliams.PA
cc: McBain, Warnock.PA
Ron Rider's compression algorithm is a superset of the algorithm used by the 9700
and Seminole (a scanner), both PSD products. The 9700 algorithm is documented
in something called the Img format, an Interpress file transmitted by Seminole.
I'm the author of the Img Format Spec. It's in a state of flux at the moment. I'll
put a copy of the working document on
[Oly]<IS>ImgFS.press
You can use that document to write code from, just keep in mind that there will
be some changes. They probably won't be serious if you parameterize things
like positon of the elements. Most of the compression stuff is already committed
to hardware and relatively safe from change.
/Dwight
*start*
00691 00024 US
Date: 3 March 1982 5:16 pm PST (Wednesday)
From: GWilliams.PA
Subject: Press version 3.9 is released
To: Baskett, Petit, Wilhelm, Dale.EOS, Hunt, ISL↑.pa, Swinehart, Orr, DBrown
cc: Thacker, AlBrown, Ramshaw, GWilliams
Reply-To: GWilliams
Press 3.9 is hereby released, on [Maxc]<Press>. We uncovered a storage allocation
time bomb that gets aggravated by fairly random events. Most of these events
showed up on the Puffin printer while attempting to print files as innocuous as
Sil files. The bug announces itself through Swat that zero is not executable.
In moving valuable data to a "permanent zone", Press was overwriting other
valuable data...
Glen and Lyle
*start*
00544 00024 US
Date: 5 March 1982 6:08 pm PST (Friday)
From: Pier.PA
Subject: Reticle Maker Software
To: Thacker, Starkweather, ABell
cc: Geschke, Warnock, Pier, GWilliams
File [ivy]<pier>Reticle>Reticle.press contains a schematic drawing of a band file
and a Mesa interface description of the objects in the band file. Please question
me if anything is unclear. The interface only describes the type of object used
to represent black rectangles. MesaPress running on ReticlMaker will eat such
files and produce bitmap images.
Ken
*start*
00679 00024 US
From: Pasco.pa @ PARC-MAXC
Date: 7-Mar-82 9:08:08 PST
Subject: Affordable color printer
To: LSIInterest↑
cc: Putman, DLyon@SRI-KL
A new color impact printer for under $2000 shows promise for low-throughput LSI checkplotting applications. The Integral Data Systems' "Prism" printer, with its DotPlot and Color options provides 84-spot-per-inch, 4-color (black,cyan,magenta,yellow) bitmap graphics. It has a single printhead with a 4-lane ribbon. To print 4-colors, the head makes 4 passes over each swath, with the ribbon elevated differently each time (like two-color typewriter ribbons). Product review in Byte, March, 1982, pp. 44-49.
- Rich
*start*
00790 00024 US
Date: 7 March 1982 5:15 pm PST (Sunday)
From: GWilliams.PA
Subject: Re: Reticle Maker Software
In-reply-to: Pier's message of 5 March 1982 6:08 pm PST (Friday)
To: Pier
cc: Thacker, Starkweather, ABell, Geschke, Warnock, GWilliams
Ken,
This is just a procedural note. In your message describing the Mesa interface
that describes the bands objects, you said "MesaPress running on ReticlMaker
will eat such files and produce bitmap images."
We in ISL know that that software is not completely written or even bound. Bell
and Thacker, I believe, don't. Could the message have been interpreted that the
software will eat the files "immediately"?
Glen
P.S. I'm ready to integrate your module into my MesaPress system when you are;
let's try it tomorrow morning.
*start*
00463 00024 US
Date: 7 March 1982 8:12 pm PST (Sunday)
From: Pier.PA
Subject: Re: Reticle Maker Software
In-reply-to: GWilliams' message of 7 March 1982 5:15 pm PST (Sunday)
To: GWilliams
cc: Pier, Thacker, Starkweather, ABell, Geschke, Warnock
Apologies for any confusion. "Will" is to be taken as the indefinte future tense
it literally is. Actually, a week or two should do it, barring unforseen
complications in the vanilla Alto/Mesa world.
Ken
*start*
00442 00024 US
Date: 8 March 1982 5:19 pm PST (Monday)
Sender: GWilliams.PA
From: GWilliams.PA
Subject: Bands file hacking
To: Pier, Warnock
cc: GWilliams
Ken,
Here's the interface you can use to get the functions I provided for accessing the
Trident and managing core. I'll be needing a similar interface from you so we
can plug your stuff into GetBitsFromBandsFile.
Glen
<GWilliams>MesaPress>Sources>
PressBandsDefs.mesa!1
*start*
00480 00024 US
Date: 15 MAR 1982 0101-PST
From: RAMSHAW at PARC-MAXC
Subject: Press 4.0: So, who's perfect?
To: sek at SU-AI, kim, dbrown, gwilliams
cc: warnock, mcdaniel, wilhelm, orr
I just realized that the "odd number of intersectins" bug in Press
is almost certainly my own! I forgot when rewriting the band
segment merge code a couple of versions back that the merge must
be stable. I will try to issue a fix for this problem sometime
today (Monday),
Lyle
*start*
04230 00024 US
Date: 15 March 1982 11:28 am PST (Monday)
From: Pier.PA
Subject: Band Files
To: ABell, Thacker, Petit, Starkweather
cc: Warnock, GWilliams, Pier
Reply-To: Pier
Please IGNORE my previous definition and picture for band files. It has bugs.
However, after considering that there may be millions of rectangles in a reticle
band file, I think encoding as tightly as possible is very worthwhile, and I am
willing to write and support the code in order to save millions of words and
microseconds.
Proposal: Reticle band files contain a herald record (as before) with ID,
bandCount, bandWidth, bandHeight, etc. Then, following are all the rectangles
for band 0, then an end object, then all rectangles for band 1, an end object ...
up thru band 639. A rectangle object is encoded in either of two forms:
SHORT: three words, 0: xmin, 1: ymin, 2: byte: deltaX, byte: deltaY.
LONG: four words, 0: xmin, 1: ymin, 2: xmax, 3: ymax.
xmin, xmax, ymin, ymax are 15 bit quantities in [0..25,000)
Bit 0 of a rectangle object is 0 IF SHORT ELSE 1.
A LONG object with xmin=ymin=xmax=ymax=77777B is an END object.
My intent is that these files can be created using byte/word streams without
having to back up in a stream.
Please read this over and respond to the proposal.
Answering some questions Alan Bell has already posed:
1.) What is the device number for reticle maker: 3.
2.) The field size for the band field is 8 bits. The
maximum band is 630. Where do the 2 extra bits go:
That's a bug. Band numbers are 12 bits in new herald.
3.) How should I handle trapeziods?
I was told (assumed??) that only black rectangles were required. If you
really need trapezoids, we have to add them to the encoding.
4.) Can I use values of bandHeight less than that in the document?
A number that is a power of 2 would be a little easier.
The herald values are derived: given ~62 KWords of band buffer
available in an Alto IIXM and
a scan length of 1536 words(25000/16), the maximum number of
scanlines that will fit in the buffer is around 40. You are free to use
smaller numbers, say 32.
5.) Should the bands be sorted in the band file?
Absolutely. But, only in Y, traversing the bands. Not needed in X.
I did not specify sorting in the previous message, but
that is fundamental to the band file architecture.
6.) What coordinate system is used. (Where is 0,0 and +X,+y).
0,0 in upper left corner. Top to bottom, left to right,
just like an Alto screen.
7.) How can software be tested? Will this format be useable
on printers other than reticlemaker?
This format could be run on other printers assuming that the
MesaPress software package for ReticleMaker can be loaded onto
say Stinger. It currently can. Since this is a refinement of the
larger band file format developing for InterPress, most of it has
been tested already. I would appreciate one of the clients writing
a small test file soon.
Note that the herald object is the same as the general one used in current band
file formats.
HeraldObject: TYPE = MACHINE DEPENDENT RECORD [
mark(0): INTEGER = 23456D, -- password
flags(1:0..3): Flags ← [type: herald, rect: FALSE], --binary 1010 in this field for
--reticles
band(1:4..15): BandX ← 7777B, -- unused
singleFile(2:0..0): BOOLEAN,--TRUE
unused(2:1..9): [0..777b], device(2:10..15): BandDevice,-- 3 is reticle band device
bandCount(3): CARDINAL, --number of bands for this device [1..640]
bandHeight(4): CARDINAL, --height of each band in scanlines [1..40]
bandWidth(5): CARDINAL --width of each band in words = 1563D
];
Coord: TYPE = [0..25,000)
ShortObject: TYPE = MACHINE DEPENDENT RECORD [
long(0:0..0): BOOLEAN ← FALSE, xmin(0:1..15): Coord,
xmax(1:1..15): Coord,
deltaX(2:0..7): BYTE, deltaY(2:8..15): BYTE
];
LongObject: TYPE = MACHINE DEPENDENT RECORD [
long(0:0..0): BOOLEAN ← TRUE, xmin(0:1..15): Coord,
xmax(1:1..15): Coord,
ymin(2:1..15): Coord,
ymax(3:1..15): Coord,
];
EndObject: TYPE = MACHINE DEPENDENT RECORD [
long(0:0..0): BOOLEAN ← TRUE, xmin(0:1..15): Coord = 777777B,
xmax(1:1..15): Coord = 777777B,
ymin(2:1..15): Coord = 777777B,
ymax(3:1..15): Coord = 777777B,
];
*start*
00213 00024 US
Date: 15 March 1982 11:51 am PST (Monday)
From: Pier.PA
To: ABell, Thacker, Petit, Starkweather
cc: Warnock, GWilliams, Pier
In previous message, 777777B should be 77777B in end objects.
*start*
00673 00024 US
Date: 15 Mar 1982 16:11 PST
From: Ramshaw at PARC-MAXC
Subject: Press version 4.0 is released
To: Kim, SEK@SU-AI, Dale.EOS, Hunt, ISL↑.pa, Orr, DBrown
cc: GNelson, Swinehart, McDaniel, Wilhelm, Ramshaw, GWilliams
Reply-To: Ramshaw
Press 4.0 is available on [Maxc]<Press>:
Press.Run, Press.Syms, AND Press.Errors.
This version repairs a bug that I introduced: I didn't realize when rewriting the
band-segment merging code several versions ago that the merge had to be
stable. This should eliminate the spurious "odd number of intersections" Swat
traps that we have been experiencing lately.
(Press 4.0 is already installed on Lilac.)
Lyle
*start*
01499 00024 US
Date: 16 March 1982 8:53 am PST (Tuesday)
From: Satterthwaite.PA
Subject: Cedar 2.5 Compiler and Binder Switches
To: CedarUsers↑
Reply-To: Satterthwaite
By popular request, here is a tabualtion of the switches recognized by the Cedar
2.5 compiler and binder. If you use one of the standard executives to run the
compiler and binder, defaults in your user.cm take precedence over the defaults
listed below. Switches not listed have no current effect. See also SDD's Mesa
Users' Handbook.
Switch Default Interpretation
Compiler:
a FALSE Address fault acceptable for NIL checks
b TRUE Bounds checking
c TRUE compile for Cedar (special FORK)
d FALSE call Debugger on compiler error (else just log error)
f TRUE use Floating point microcode
g TRUE loG goes to compiler.log (else use foo.errlog)
j FALSE cross-Jumping and tail-Jumping optimizations
l TRUE allocate space for code Links
m TRUE reference counting Microcode
n TRUE Nil pointer checking
p FALSE Pause after compilation with errors
s TRUE Sort (by static frequency) global vars & entry indexes
u FALSE Uninitialized variable checking
w TRUE log Warning messages
y FALSE complain about KFCB (potentially non-resident code)
Binder:
a FALSE copy All (code and symbols)
c TRUE copy Code
d FALSE call Debugger error
g TRUE loG goes to binder.log (else use foo.errlog)
p FALSE Pause after config with errors
s FALSE copy Symbols
w FALSE pause after config with Warnings
*start*
04745 00024 US
Date: 16 March 1982 11:29 am PST (Tuesday)
From: Pier.PA
Subject: Revised Band File Format
To: ABell, Thacker, Petit, Starkweather
cc: Warnock, GWilliams, Pier
Reply-To: Pier
It appears there are really 25,400 bits per scanline, 5080 to the inch. That still
fits in <= 40 scanlines per band. Also, some bugs in the record formats are
corrected below, so delete yesterday's message:
---------------------------
Date: 15 March 1982 11:28 am PST (Monday)
From: Pier.PA
Subject: Band Files
To: ABell, Thacker, Petit, Starkweather
cc: Warnock, GWilliams, Pier
Reply-To: Pier
Please IGNORE my previous definition and picture for band files. It has bugs.
However, after considering that there may be millions of rectangles in a reticle
band file, I think encoding as tightly as possible is very worthwhile, and I am
willing to write and support the code in order to save millions of words and
microseconds.
Proposal: Reticle band files contain a herald record (as before) with ID,
bandCount, bandWidth, bandHeight, etc. Then, following are all the rectangles
for band 0, then an end object, then all rectangles for band 1, an end object ...
up thru band 639. A rectangle object is encoded in either of two forms:
SHORT: three words, 0: xmin, 1: ymin, 2: byte: deltaX, byte: deltaY.
LONG: four words, 0: xmin, 1: ymin, 2: xmax, 3: ymax.
xmin, xmax, ymin, ymax are 15 bit quantities in [0..25,400)
Bit 0 of a rectangle object is 0 IF SHORT ELSE 1.
A LONG object with xmin=ymin=xmax=ymax=77777B is an END object.
My intent is that these files can be created using byte/word streams without
having to back up in a stream.
Please read this over and respond to the proposal.
Answering some questions Alan Bell has already posed:
1.) What is the device number for reticle maker: 3.
2.) The field size for the band field is 8 bits. The
maximum band is 630. Where do the 2 extra bits go:
That's a bug. Band numbers are 12 bits in new herald.
3.) How should I handle trapeziods?
I was told (assumed??) that only black rectangles were required. If you
really need trapezoids, we have to add them to the encoding.
4.) Can I use values of bandHeight less than that in the document?
A number that is a power of 2 would be a little easier.
The herald values are derived: given ~63 KWords of band buffer
available in an Alto IIXM and
a scan length of 1588 words(25400/16), the maximum number of
scanlines that will fit in the buffer is around 40. You are free to use
smaller numbers, say 32.
5.) Should the bands be sorted in the band file?
Absolutely. But, only in Y, traversing the bands. Not needed in X.
This is a coarse bucket sort, with the bands being buckets.
I did not specify sorting in the previous message, but
that is fundamental to the band file architecture.
6.) What coordinate system is used. (Where is 0,0 and +X,+y).
0,0 in upper left corner. Top to bottom, left to right,
just like an Alto screen.
7.) How can software be tested? Will this format be useable
on printers other than reticlemaker?
This format could be run on other printers assuming that the
MesaPress software package for ReticleMaker can be loaded onto
say Stinger. It currently can. Since this is a refinement of the
larger band file format developing for InterPress, most of it has
been tested already. I would appreciate one of the clients writing
a small test file soon.
Note that the herald object is the same as the general one used in current band
file formats.
HeraldObject: TYPE = MACHINE DEPENDENT RECORD [
mark(0): INTEGER = 23456D, -- password
flags(1:0..3): Flags ← [type: herald, rect: FALSE], --binary 1010 in this field for
--herald types
band(1:4..15): BandX ← 7777B, -- unused
singleFile(2:0..0): BOOLEAN,--TRUE
unused(2:1..9): [0..777b], device(2:10..15): BandDevice,-- 3 is reticle band device
bandCount(3): CARDINAL, --number of bands for this device [1..640]
bandHeight(4): CARDINAL, --height of each band in scanlines [1..40]
bandWidth(5): CARDINAL --width of each band in words = 1588D
];
Coord: TYPE = [0..25,400)
ShortObject: TYPE = MACHINE DEPENDENT RECORD [
long(0:0..0): BOOLEAN ← FALSE, xmin(0:1..15): Coord,
ymin(1:1..15): Coord,
deltaX(2:0..7): BYTE, deltaY(2:8..15): BYTE
];
LongObject: TYPE = MACHINE DEPENDENT RECORD [
long(0:0..0): BOOLEAN ← TRUE, xmin(0:1..15): Coord,
ymin(1:1..15): Coord,
xmax(2:1..15): Coord,
ymax(3:1..15): Coord,
];
EndObject: TYPE = MACHINE DEPENDENT RECORD [
long(0:0..0): BOOLEAN ← TRUE, xmin(0:1..15): = 77777B,
xmax(1:1..15): = 77777B,
ymin(2:1..15): = 77777B,
ymax(3:1..15): = 77777B,
];
------------------------------------------------------------
*start*
02183 00024 US
Date: 18 March 1982 1:12 pm CST (Thursday)
From: Killen.DLOS
Subject: New Contract Arrangement
To: SunriseForum↑.dlos
cc: SunriseContract↑.dlos, Liddle.pa, Lynch.pa, Pier.pa, Hall.pa, Southerland.pa,
Thacker.pa, Conway.pa, Taylor.pa, Killen
Reply-To: Killen
Hi,
We at Unicorn have decided to take a different tack on compensation for
contributions to the Unicorn project by members of SunriseForum↑.
Instead of dollars, we now intend to provide equipment to those with whom we
reach a mutual agreement. Such equipment is primarily intended for
development of Unicorn software and/or hardware modules and would be on
permanent loan to the individual doing the work.
Let me once again iterate my statement on "strings": Given good faith and the
completion of a project before any departure from the employ of Xerox Corp., and
in the absence of distinct threats to security (e.g. personal bankruptcy and your
creditor is IBM..) prior to IMO of Unicorn, there ARE NO STRINGS. We simply
never expect to see the equipment again.
Equipment needs to relate to the project - Unicorn as we know it and perhaps to
future advanced models; and the amount will be based on the same fundamental
basis that we have worked on before -- commensurate with the work magnitude
and the success of the product. So you would get a Unicorn with peripherals up
front, and if what you do sells or helps us be a real winner in the marketplace,
we agree on the equipment needed and what you need, and we will take care of
getting it shipped to you.
We feel strongly that this is in the interests of everyone concerned -- it avoids
putting you in conflict of interest. A conflict could arise if your management
felt that you were getting paid from two sources -- them for your regular job,
and Unicorn for an extracurricular activity that would possibly divert energy
from your assigned tasks. We want you and your management to be comfortable
with this. If you have any questions, please contact me:
Don Killen
Xerox Corp.
1720 Regal Row - Suite 100
Dallas, TX 75235
Intelnet 8*723-1230 --- Outside line: (214)689-1230
Thanks for your time and support !!
Don
*start*
00664 00024 US
Date: 18 March 1982 12:02 pm PST (Thursday)
From: Pier.PA
Subject: Revised Band File Format
To: ABell, Thacker, Petit, Starkweather, McCreight
cc: Warnock, GWilliams, Pier
Reply-To: Pier
Print [ivy]<pier>ReticleBandFormat.press for a new and hopefully correct band
file format.
Also, the coordinates (xmin, ymin, xmax, ymax) should be band relative. That is,
x coordinates don't change from the global reticle coordinate system, but y
coordinates have the y value of the start of their band subtracted out. This will
save the printer from doing that conversion on every y coordinate for BITBLT
into the reticle band bitmap buffer.
Ken
*start*
01025 00024 US
Date: 18 March 1982 4:37 pm PST (Thursday)
From: Starkweather.PA
Subject: Re: Revised Band File Format
In-reply-to: Your message of 18 March 1982 12:02 pm PST (Thursday)
To: Pier
cc: Starkweather, ABell, Thacker, Petit, Starkweather, McCreight, Warnock,
Gwilliams
Ken, after reviewing the new band format for Reticles, it seems that since the Y
coordinates of objects are band relative, Ymin and deltaY can never exceed 40
and hence will fit within a byte. DeltaX on the other hand could be 15 bits.
Why not change the short object format to xmin(15 bits), deltaX(15 bits), and
ymin(8 bits) where deltaX was previously specified and then deltaY (8bits) can
be left at its current specification. This would permit all rectangles to be short
objects and eliminate the need for long objects. Things could be left the way
they are except that rectangles having deltaX in excess of 256 bits must become
long objects and the value of relative band count is diminished. Please advise if
you agree.
Gary
*start*
01135 00024 US
Date: 18 March 1982 4:53 pm PST (Thursday)
From: Steffensen.PA
Subject: Liberty Ship Schedule
To: Junk↑
cc: Steffensen
Reply-To: Steffensen
The SS Jeremiah O'Brien, America's last unaltered Liberty Ship will be open to
the public with the triple expansion steam engine running and the original coal
stove galley in operation on the third weekend of each month in 1982 (with the
exception of May, July, and December) as per this schedule:
March 20-21 Chocolate chip cookies free on board, Sat., 20th
April 17-18
May 15 Annual Seamen's Memorial Bay Cruise, Sat., 15th
(advance reservations required, $50) ship closed Sunday
June 19-20 Live Big Band Music on board, Sat., 19th
July 3-4
August 21-22
September 18-19
October 16-17 Steam Winch demonstration, Sat., 16th
November 20-21
December Not open
Hours: 10:00 AM to 3:00 PM
Location: Pier 3 East, Fort Mason, San Francisco
Donation: $2/adults; $1/seniors & children; $5/families
Info per: SS Jeremiah O'Brien, Golden Gate National Recreation Area,
National Park Service, Fort Mason, San Francisco 94123
Telephone 415/441-3101
*start*
01008 00024 US
Date: 19 March 1982 9:40 am PST (Friday)
From: Pier.PA
Subject: Re: Revised Band File Format
In-reply-to: Starkweather's message of 18 March 1982 4:37 pm PST (Thursday)
To: Starkweather
cc: Pier, ABell, Thacker, Petit, McCreight, Warnock, Gwilliams
Yep. Hmmm. OK. Terminal senility may be setting in. So we have only one form
of reticle band object:
LongCoord: TYPE = [0..25400);
ShortCoord: TYPE = [0..40];
Object: TYPE = MACHINE DEPENDENT RECORD [
xmin(0): LongCoord,
deltaX(1): LongCoord,
ymin(2: 0..7): ShortCoord, deltaY(2: 8..15): ShortCoord
];--two words and two bytes = 3 words
Delightful. This also makes exploding simpler and faster because all objects are
the same size, 3 words. Let's make the end object 3 words as well, even though
a single bit in position 0 could do it. So:
EndObject: TYPE = RECORD[firstWord,secondWord,thirdWord: CARDINAL =
177777B];
Mesa Culpa. (Groan).
Ken
PS: revised picture sometime today on [ivy]<Pier>ReticleBandFormat.press.
*start*
00352 00024 US
Date: 25 March 1982 11:51 am PST (Thursday)
From: Pasco.PA
Subject: Versatec Documentation
To: LSIInterest↑
Reply-to: Pasco
Miscellaneous "how-to-use-it" folklore for "Vice", the Versatec printer in
the VLSI Systems Design Area, has been distilled from old messages and
placed on [Ivy]<Pasco>Plotting>Versatec.press.
- Rich
*start*
01126 00024 US
Date: 19 March 1982 4:46 pm PST (Friday)
From: Ramshaw.PA
Subject: Press version 4.1 is released
To: DNelson, Scharfetter, Jung, PMartin, Dale.EOS, Hunt, ISL↑.pa, Orr, DBrown
cc: Ramshaw, GWilliams
Reply-To: Ramshaw
Press 4.1 is available on [Maxc]<Press>:
Press.Run, and Press.Syms.
This version repairs a bug that has presumably been there since the beginning.
In particular, the Cell Design System from El Segundo writes Press files that ask
for hue=255=377b. Of course, only hues in the range [0..240) really mean
anything, but the theory is that asking for a hue in the range [240,255) is the
same as asking for hue=0. Unfortunately, that is not what the code was actually
doing! Instead, a request for hues greater than 239 would sometimes cause an
array to be accessed out of bounds, and hence the world to collapse.
[I also removed a debugging Swat trap in the band-merging code that shouldn't
have been left in 4.0 but was.]
ICL folks: 3 copies of the two CDS files that were breaking are now on top of
Lilac.
Darrah and Julian: Press 4.1 is already installed on Lilac.
Lyle
*start*
00537 00024 US
Date: 19 March 1982 9:51 am PST (Friday)
From: Thacker.PA
Subject: Re: Revised Band File Format
In-reply-to: Pier's message of 19 March 1982 9:40 am PST (Friday)
To: Pier
cc: Starkweather, ABell, Thacker, Petit, McCreight, Warnock, Gwilliams
Any you guys thought that it would be trivial to set up a format for the reticle
generator! Hah!
The lesson is to do things in parallel where possible. If we had started this a
year ago, it would be done now, and we would be making reticles.
Grouchily yours,
chuck
*start*
00491 00024 US
Date: 21 March 1982 6:10 pm PST (Sunday)
From: Pier.PA
Subject: Mesa Bands
To: GWilliams
cc: Pier
Glen-
I am currently living dangerously on a set of BCDs mostly copied from your
Mesa disk. We had some consistency problems the day Movie↑ screwed up
Laurel. I'd like to get current sources and BCDs available on IFS, so I can look
at and create MesaBands and ReticleBands from scratch if needed.
The BCDs on [ivy]<Pier>MesaPress> are the ones in question.
Ken
*start*
00682 00024 US
Date: 22 March 1982 1:47 pm PST (Monday)
From: GWilliams.PA
Subject: Re: Mesa Bands
In-reply-to: Your message of 21 March 1982 6:10 pm PST (Sunday)
To: Pier
cc: GWilliams
Ken,
Your feeling of living dangerously is misplaced. All the files you need have
been of IFS since last week, including the sources. There are a few that are not
on my directory. They are EFTPDefs.bcd EFTPRecv.bcd EFTPSend.bcd. They are
under <Mesa>, as is TinyPup.bcd. MesaTfs.bcd is under <GWilliams>MesaTfs>.
If your concern is that the create date of the files on your d0 are not the same as
those on the IFS, not to worry: the IFS ones agree with what is on my disk.
Glen
*start*
00565 00024 USm
Date: 22 March 1982 6:42 pm PST (Monday)
From: Pier.PA
Subject: Revised Band File Format
To: ABell, Thacker, Petit, Starkweather, McCreight
cc: Warnock, GWilliams, Pier
Reply-To: Pier
Print [ivy]<Pier>Reticle>ReticleBandFormat.press for a new and hopefully final
band file format.
New features include a herald object defaulted to the canonical parameters for
ReticleMaker, and a new object called HornetHerald you can use for putting test
output on Stinger. Also find new definitions to correspond to the picture on the
press file.
Ken
*start*
01118 00024 US
Date: 31 March 1982 12:16 pm PST (Wednesday)
From: MERRY.PA
Subject: Hornet and Jasmine
To: Geschke.PA
cc: Adele, Orr, Putman, Warnock, GWilliams, Merry
Dear Chuck,
I wanted to let you know how pleased we are to have our Hornet and the
extended loan of the Jasmine scanner.
Dan has done a great job in putting together a printer that looks very promising
in the area of producing good quality text-graphics. His enthusiasm and
appreciation of our desires has been a joy for me and a tribute to your good
judgment in having him in your group. The Hornet will, I think, allow us to
more effectively pursue some of our experiments in text-graphics.
The Jasmine will also be a boon to our efforts. Thanks so much for making it
available to us.
I very much appreciate the cooperation we have gotten from your group and
yourself, Chuck. Both Jon and Glen have often put up with our interruptions,
and Julian has been most helpful in getting the Hornet and Jasmine installed.
Our goals are closer with your contributions, and I hope that the value is felt by
all.
THANK YOU!!!
Diana
*start*
03117 00024 US
Date: 6 April 1982 2:40 pm EST (Tuesday)
From: DMurray.WBST
Subject: Wabash Valentine's Release
To: WabashInterest↑
Reply-To: DMurray
This message announces the 2-14-82 Wabash release. Since the dl has been quiet
for a while, it seems appropriate to point out recent changes.
Fonts
Wabash maintains a 3-level font cache (memory, local disk, remote disk)
and automatically retrieves needed system fonts from a standard IFS
file server. This relieves the need for a large font data base at the
printer. On our experimental Penguin, we keep 40 fonts locally and
300-400 "fonts of record" are on the [Cask] IFS. (ClearingHouse later!)
Private fonts continue to be accepted via the FTP connection and applied
to Press files sent at the same time. This is a great tool for font developers
as they can easily see the recent changes to their artwork. The Quartz
font families were developed this way.
Pictorials
Wabash now accepts a generalized tile size MxN (M must be a power of
2). The microcode is faster and I've seen pictures as large as 8" x 6" on
the Penguin.
We're making changes to make Wabash and Gemini compatible. Shortly,
it will be easy to merge AIS pictures into pre-formatted Bravo text.
Early output looks great.
Color (non-black objects)
The 2-14 release prints color objects (non-black). That is, it substitutes
a gray inkwell for the color and then images the text, rules, splines, etc.
The inkwell bitmaps reside in an Inks3.oc font; our standard set has 16
inkwells, thanks to Chuck Dvorak. Since inks are a font, you can send
your inks via the private font mechanism (indicated above).
This is a first attempt at inkwell colors and some problems remain in the
mapping of HSB to ink ID and priority. For a first try, print the file
<Sil>ColorChart.press; then use Sil to make some shaded boxes, etc. I'd
avoid Griffin and overlays until we implement macros.
Miscellaneous
Job spooling and processing is much improved; much better printer status
reporting.
Increased decomposition speed for standard text proceesing; all disk IO is
now faster (goes directly from disk to XM, skipping bank 0).
VideoFiles are accepted from the net (BandLists and RasterLoads). Those
using the VFU pattern generator package can run off-line or save your
favorite file and print it later. VFU has been extended and improved.
The command line interface was dropped; no invocations via com.cm.
That's about it for now. To get started with disks, code, inks, fonts, etc. you can
contact John <Blanchard> (8-222-2166) or me.
For the near future, we will complete the work on inks, link up with the AIS
Gemini subsystem, produce a real breakpage, and establish communications with
the NPA front-end which will off-load spooling, make-ready operations, and
client communications). Also we have been experimenting with compressed
formats for large characters (96+ points) and/or high resolution. These should be
incorporated as well. Those of you interested in using inkwells for true color
should contact me separately.
Dan
*start*
00634 00024 US
Date: 2-Apr-82 17:11:46 PST (Friday)
From: Israel.pa
Subject: Experimental File Service
To: StarUsers↑.es
Reply-To: Israel.pa
cc: SDD-AD↑
Friends,
A new file service will soon appear in OSBU North. Called "FAXTotem", it is a vehicle for voice and facsimile advanced development work. It is NOT a public file service, so please don't expect any files you may store there to be there when you get back later. Its software and file system content are likely to change without notice.
The server is located in the area opposite Rockhopper. Please contact me if you have a need to use this machine.
Jay.
*start*
00448 00024 US
Date: 7 April 1982 4:47 pm PST (Wednesday)
From: Starkweather.PA
Subject: Reticlepress
To: Pier
cc: Warnock, GWilliams, Putman, Starkweather
Ken, I am having trouble with the scanlines coming out scrambled. Rather than
relate the details here I will see you tomorrow morning to relate the problems.
I am referencing Glen and Dan so that we can check any other concerns. I will
use the DLP-1 to check the system etc.
Gary
*start*
01472 00024 US
Date: 15 APR 1982 1041-PST
From: SPROULL.PA
Subject: Comments on recent Telepress spec
To: telepressdesign↑.es
cc: sproull, warnock, geschke
I have a couple of comments on the Telepress draft spec recently
publicized. I have not studied the document in great detail, so my
comments are not "nits," but rather somehwat more general:
1. (Important) It seems to me that an important interaction between a
printer and programs that create files for it has been omitted from
Telepress, namely the ability for the creator to obtain a "metric
master" as described in the Interpress spec that contains information
about the printer's environment: font widths, etc. While obtaining
this file will be an infrequent occurrence, it seems to me it ought
to be one of the standardized interactions with the printer. (By
contrast, functions to install various printer-dependent files such
as forms and fonts don't, it seems to me, need to be handled in a
standardized way.) The point is that a program (or workstation
containing the program) ought to be able to become connected to the
Ethernet and to obtain in a standard way enough information to print
a file. Presumably the clearinghouse will point to a printer, but
what about the font metrics?
2. (Less important) What is the general mechanism by which particular
printers will extend Telepress if need be? Should the Telepress
design spell out extension strategies that are deemed acceptable?
Bob
*start*
00506 00024 US
Date: 16 April 1982 1:58 pm PST (Friday)
From: GWilliams.PA
Subject: Reticle printing
To: Starkweather, Petit, ABell, McCreight
cc: Pier, Warnock, Thacker, GWilliams
I recently changed ReticlePress to change its Slot buffer allocation scheme to
accomodate 25K+ scan lines. As you may have heard, it is alive and well; Gary
made a nice reticle yesterday.
The most recent version may be found on [IVY]<GWilliams>Reticle as
ReticlePress.bcd. There are no operational changes.
Glen
*start*
01999 00024 USm
Date: 16 April 1982 11:22 am PST (Friday)
From: GWilliams.PA
Subject: Re: File Editing Etiquette (somewhat long message)
In-reply-to: Pier's message of 15 April 1982 11:33 am PST (Thursday)
To: Pier
cc: GWilliams, Warnock
Ken,
We should agree soon on a release procedure so that maintenance is more orderly.
I'd like to address the ramifications of this in this message. The balance of this
message illustrates a fundamental difference we have on this matter, and a
proposed solution.
When last we talked, you told me you were going to put a file on the user's disk
that would tell you whether to process a reticle or an "Interpress" bands file.
What I don't understand is why you don't use that information in deciding
which file to look up in, say, PressBandsOps.
Instead of opening one file or the other based on the information at hand, you
replicated the module with only the filename lookup changed. Lately I have
added functionality to another file I gave you access to, PressNetListener. I
found that, again, there are two versions with only one line of code different.
The task of updating parallel sets of code is not easily orchestrated, and in these
cases, easily avoidable.
For instance, the two modules PressNetListener and ReticlePressNetListener each
call the same procs from my GetBitsFromBands: ShowBandsInit and ShowBands.
In PressNetListener you import the procs from one defs module and from
ReticlePressNetListener you import the same proc names from a different one.
This is unnecessary. You need only one defs file (the two are identicle anyway)
and then just bind the appropriate module in the Configuration. This would
make the whole issue of "nearly duplicate" files vanish, and indeed is the
primary reason the configuration language exists.
I know that we both would like to move on in our respective projects, but if we
are to maintain these projects it seems to me that we should not add unnecessary
complexity.
Cheers,
Glen
*start*
00570 00024 US
Date: 16 April 1982 2:04 pm PST (Friday)
From: GWilliams.PA
Subject: Press version 4.2 is released
To: DNelson, Scharfetter, Jung, PMartin, Dale.EOS, Hunt, ISL↑.pa, Orr, DBrown
cc: Ramshaw, GWilliams
Reply-To: GWilliams
Press 4.2 is available on [Maxc]<Press>:
Press.Run, and Press.Syms.
This is a minor change that shouldn't affect anyone not making reticles. The
change (adding an item to structure PageG) was necessary to maintain a degree
of compatibility with MesaPress and ReticlePress.
Gary: This version is already on the DLP.
Glen
*start*
00524 00024 US
Date: 19 April 1982 6:58 pm PST (Monday)
Sender: GWilliams.PA
From: GWilliams.PA
Subject: Press version 4.3 is released
To: DNelson, Scharfetter, Jung, PMartin, Dale.EOS, Hunt, ISL↑.pa, Orr, DBrown
cc: Ramshaw, GWilliams
Reply-To: GWilliams
(Oh no, not again)
Press 4.3 is available on [Maxc]<Press>:
Press.Run, and Press.Syms.
This version takes advantage of the new information of the Bits file to display
very high resolution images (for the reticle maker) using the /d option of Press.
Glen
*start*
00754 00024 US
Date: 23-Apr-82 12:17:29 PST (Friday)
From: Beeley.ES
Subject: Re: Comments on recent Telepress spec
In-reply-to: SPROULL.PA's message of 15 APR 1982 1041-PST
To: SPROULL.PA
cc: telepressdesign↑, warnock.PA, geschke.PA
Reply-To: Beeley.ES
Font information through Telepress was considered and shelved for the time being because (a) the type of information is complex (ie, what characters, what character sets, what rotations, etc) and not always fully known by the Telepress server and (b) we didn't have a client that needed it. This topic, no doubt, will be revisited in the future.
Extensions to Telepress will presumably be handled by the (ad hoc) Telepress committee. All suggestions via this dl are welcome!
//John
*start*
00677 00024 US
Date: 28 April 1982 4:36 pm EDT (Wednesday)
From: Bernard.WBST
Subject: ReadPress Release
To: ISL↑, WabashInterest↑
cc: Bernard
Mesa ReadPress has been released to [Erie]<Express>utilities>. The new version
has been released as ReadPress.image. The bcd files are not stored in the dump
file. The new version allows you to pause between printed pages. It also
contains facilities for parsing the old tile formats as well as the new tile formats
being used by Wabash and Gemini.
ps: Wabash will currently handle both tile formats in Press files. Tiled images
created with AISTile as well as the ones created with Gemini will be properly
parsed.
*start*
00279 00024 US
Date: 29 April 1982 4:27 pm PDT (Thursday)
From: Balch.PA
Subject: draft Telepress standard available
To: TelepressDesign↑.es
cc: Suk, Balch
The latest version of the Telepress standard is stored as
[iris]<StdsDrafts>telepress>telepress.press
*paula
*start*
01623 00024 US
Date: 3 May 1982 9:16 am EDT (Monday)
From: Harrington.wbst
Subject: New Wabash Release
To: WabashInterest↑
Reply-To: Harrington.WBST
We are proud to announce the release of the next (and probably final) major
revision of Wabash. Beginning this May, Tioga will again be available as a
print server.
This latest revision improves the response seen when transmitting a job. This was
done by continuing to listen for jobs except when actually printing.
The revision supports the NPAprint protocol used by the NPA Document
Coordinator.
The revision also interfaces with the soon to be released Gemini system for
editing and formatting documents containing both text and pictorials.
Documents printed by the new system are accompanied by a personalized break
page, complete with information about who printed it, when it was done, what
was printed, and any errors or abnormalities which may have occured.
The system preserves the integrity of graphic objects. This was not the case for
our previous release and was visible where two differently colored objects
overlapped. Unfortunately, prioity of overlapping objects is still not handled
very well, and sometimes what you think of as one object (such as a border
generated by Griffin) is in fact several objects in the Press file. The moral is if
you don't like surprises, then don't overlap differently colored objects.
Our new release has a provision for a compressed font format (rulette-encoded).
Large sized fonts can be encoded into this format to save space. We can now
support more and larger fonts than was previously possible.
*start*
00932 00024 US
Date: 3 May 1982 10:05 am PDT (Monday)
From: Ramshaw.PA
Subject: Press 4.103
To: Warnock, Wyatt
cc: GWilliams, Ramshaw
John and Doug,
Stinger is now running with a bootleg special version of Press, called 4.103; the
only difference from 4.3 is Metering of font data. In particular, for each file
printed, the filename, creator name, and date (as strings) are dribbled to the file
Press.Meter. Then, for each page, the number of distinct character codes that
appear on that page and the total space that the rasters for those characters
occupy (in Orbitized format, at 384 bpi, counting the two-word header for each
character) is dribbled in binary. In addition, the same two statistics are output
for each font load as a whole. (It would be much harder to get data that would
span more than one font load.) See me for more details; Doug, I left the
appropriate BCPL definitions on your desk,
Lyle
*start*
00831 00024 US
Date: 28 April 1982 8:28 am PDT (Wednesday)
From: putman.PA
Subject: Re: Mouse Pad
In-reply-to: Garner's message of 27 April 1982 11:15 pm PDT (Tuesday)
To: Garner
cc: GWilliams, Putman, Paeth, Orr
Robert
Things have changed some since we printed pads for Martin.
We now have a dedicated operator for the platemaker.
To get a file printed; give a copy printed on stinger of the file you want printed
to Julian Orr and a pointer to where the file lives. your output should be ready
within a day or two (usually) be sure to mention the long scan conversion to
Julian so that we can leave it to convert overnight.
To print on stinger you use any of the printing commands you would use
for a dover except that if the machine is printing it does not spool.
the command line you used will work fine.
Dan
*start*
01041 00024 US
Date: 28 April 1982 10:03 am PDT (Wednesday)
From: Paeth.PA
Subject: Re: Mouse Pad
In-reply-to: Garner's message of 27 April 1982 11:15 pm PDT (Tuesday)
To: GWilliams
cc: Garner, Putman, Paeth
"Martin told me that the .press file took a long time to convert ('over night')."...
Some Press ideas
(1) long conversion is probably because each little hexagon is in fact 6 2-knot
splines, which must be flooded. Unfortunately, no hierarchical mechanism
(named symbols...) exists in press, short of fonts. Perhaps a Mouse.fonts should be
created, which contained one font with characters being simply hexagons of
increasing sizes. This would probably be at least on order of magnitude fix.
(2) That favorite question of mine: Press on a Dorado. Ken Pier demonstrated
MesaPress to me the other day, on a trident Alto. Although its press.bands was
different, I'm told its press.bits is identical (to alto press). Could one run Press
(Mesa) on a Dorado, and then use Alto Press on the .bits to do the bit flinging?
/Al
*start*
00811 00024 US
Date: 28 April 1982 2:26 pm PDT (Wednesday)
From: GWilliams.PA
Subject: Re: Mouse Pad
In-reply-to: Paeth's message of 28 April 1982 10:03 am PDT (Wednesday)
To: Paeth
cc: GWilliams, Garner, Putman
Sure,
The current way reticles are created is by taking a <mesa> bands description
(these bands are not to be confused in any way with bcpl Press's bands stuff)
and telling mesapress to take that format, blow it up into a press.bits, which is
printed by the same command.
I wrote all the code except the Band-blower-upper; you should consult Ken
about the band descriptors.
Given that you have a file of band descriptors, you pull it over to the printer's
trident, naming it "Bands". Then, type "Mesapress bands" to the exec and the
file will be printed as advertised.
Cheers,
Glen
*start*
00410 00024 US
Date: 30 April 1982 10:22 am PDT (Friday)
From: Paeth.PA
Subject: Re: Mouse Pad
In-reply-to: Paeth's message of 28 April 1982 10:03 am PDT (Wednesday)
To: Paeth
cc: GWilliams
Back to the "creating mouse pads" again, the objective being that it not take
overnight.
Is the fastest route now to create a bands file of hexagons (say, in JaM), on a
Dorado, and MesaPress it to make pads?
*start*
00353 00024 US
Date: 30 April 1982 11:10 am PDT (Friday)
From: GWilliams.PA
Subject: Re: Mouse Pad
In-reply-to: Your message of 30 April 1982 10:22 am PDT (Friday)
To: Paeth
cc: GWilliams
Yes. I believe you want to get hold of Pier's module that loads into Cedar
graphics; it creates a bands file suitable for printing with Mesapress.
Glen
*start*
00582 00024 US
Date: 27 April 1982 11:15 pm PDT (Tuesday)
From: Garner.PA
Subject: Mouse Pad
To: GWilliams
cc: Putman, Paeth, Garner
Glen (or Dan),
Before he left, Martin Haeberli used the platemaker to create some prototype
optical mouse pads (a dense hexagonal pattern). Could I do the same this week?
Martin told me that the .press file took a long time to convert ("over night").
How do I go about getting it made? (I won't be in Wed.)
Also, can I use Stinger to try it out first? Is Stinger up? Do I just say "empress
stinger/h x.press" ?
Thanks,
Robert
*start*
03104 00024 US
Date: 13-May-82 15:53:08 PDT (Thursday)
From: Ladner.pa
Subject: Telepress Manual
To: TelepressDesign↑.es
cc: Ladner.pa
Reply-To: Ladner.pa
I am in the process of reorganizing the Telepress manual to bring it in line with the other standards that we are in the process of generating. While doing this, there are several enhancements I would like to make to the specification to make it more intuitive. John Beeley suggested that I solicit reactions to the changes from group members.
The first set of changes I would like to make are purely cosmetic. The names of some of the procedures and types, I believe, could be improved upon, namely:
a) Except for Print, the procedure names do not indicate that they are in fact operations, as opposed to data items. To make it more obvious, I would like to change
PrinterProperties to GetPrinterProperties
PrinterStatus to GetPrinterStatus
PrintRequestStatus to GetRequestStatus
b) If the above changes are made, less stilted names can be used for the various types. I would like to change
PrintOptionsSequence to PrintOptions
PrinterPropertiesSequence to PrinterProperties
PrintRequestStatusReply to RequestStatus
StatusOfPrinter to PrinterStatus
MediaSequence to Media
c) To maintain consistency of field naming, since there is a field called "recipientName", the field "sender" should be changed to "senderName".
d) To bring the specification into line with common usage, I would like to change
beginningPageNumber to beginningPlateNumber
endingPageNumber to endingPlateNumber
pagesToPrint to platesToPrint
(these all occur in the "PrintOptionsSequence" type)
e) To be most explict, I would like to change the name of the error SpoolFull to SpoolingQueueFull.
I would like to make a set of changes that are of a slightly substantive nature. By and large these changes make for a neater Courier specification. The changes do modify the specification slightly, but are almost invisible.
f) Instead of having one error with an enumerated argument for the different errors that may arise, it has been suggested to define an explicit error for each.
g) Regardless of the outcome of f), it has been suggested to add the errors PrintObjectTooLarge and InsufficientSpoolSpace to further refine the error SpoolFull.
h) Regardless of the outcomes of f) and g), it has been suggested to change the numbers of the errors so that they are consecutive.
i) I would like to eliminate the type StatusOfRequest and define the enumeration directly in the type PrintRequestStatusReply (as far as I can tell, the only place it is used) as is done with all of the other enumerations.
j) It has been suggested that to conform with common usage, the order of the fields "length" and "width" in the record "variable" in the type "Papers" be reversed.
In order to get the Telepress document edited in a timely fashion, I need an indication of your reactions to these changes at an early date. I suggest responses be in my hands by May 18. Unless I receive strong objections, I'm going to proceed with these changes.
*start*
00801 00024 US
Date: 15 MAY 1982 0640-PDT
From: SPROULL.PA
Subject: Your cosmetic changes proposed
To: ladner
cc: telepressdesign↑.es
On the whole, I'm for it. There is one small issue, however.
It may be that the term "plate" is in common usage in some
quarters, but the term "pgae" is used throughout the Interpress
definition. Since the fields that refer to "plates"
(or "pages") are really used to edit the Interpress master in a
trivial way before it is printed (the editing operation is to select
certain "page bodies" from the master), I would suggest you preserve
the Interpress terminology. Otherwise there will be confusion to
someone who reads the Interpress and Telepress
documents and finds "plates" used in Telepress with no ereference
to such an object in Interpress.
Bob
*start*
00565 00024 US
Date: 22 March 1982 6:42 pm PST (Monday)
From: Pier.PA
Subject: Revised Band File Format
To: ABell, Thacker, Petit, Starkweather, McCreight
cc: Warnock, GWilliams, Pier
Reply-To: Pier
Print [ivy]<Pier>Reticle>ReticleBandFormat.press for a new and hopefully final
band file format.
New features include a herald object defaulted to the canonical parameters for
ReticleMaker, and a new object called HornetHerald you can use for putting test
output on Stinger. Also find new definitions to correspond to the picture on the
press file.
Ken
*start*
01223 00024 US
Date: 6-May-82 8:53:31 PDT (Thursday)
From: Beeley.ES
Subject: TelepressSpec extension
To: AlBrown.pa
cc: TelepressDesign↑, Nikora, Balch.PA, Beeley
Reply-To: Beeley.ES
I have recently become aware that there is no way for a client making a Print call to distinguish between a document ("printObject") being (a) too large to ever be spooled on the target server or (b) too large to be spooled currently or (c) the fact that the queue itself is full. We currently have one ErrorType for these 3 cases: spoolFull.
I propose that we add two ErrorTypes:
printObjectTooLarge -- case (a)
insufficientSpoolSpace -- case (b)
which, together with spoolFull, should cover the three cases.
A server may only raise 'spoolFull' or 'insufficientSpoolSpace' but at least the 'printObjectTooLarge' ErrorType will be available for the discriminating server. [For the 8044, case (a) can be handled by either breaking the doc up into smaller pieces or, possibly, judiciously deleting fonts at the server.]
Note that adding these (or others) at this late date should have no affect on the standardization process. Not adding them may cause problems if they get added in some later implementation.
//John
*start*
01368 00024 US
Date: 14 June 1982 11:48 am PDT (Monday)
From: Ramshaw.PA
Subject: Versatec landscape/portrait switch in Press
To: Knox.wbst
cc: GWilliams.pa, Swinehart.pa, Venable.wbst, Ramshaw
Keith,
Dan caught me talking about Versatec plotting in the hall today, and told me
about your recent inquiry. I put a Versatec landscape/portrait switch into the
installation dialogue for Press some time ago (back in version 3.2, to be precise;
we are now up to 4.3). In particular, if you state that the output device is a
Versatec, the installation dialogue asks you whether you would like the left edge
or the top edge of the Press page to come out first.
I will put you on the list of people to be told about new releases of Press so that
you can keep up to date. [Glen, let's try to remember to send release messages to
Know.wbst and Venable.wbst as well as the usual crowd.] So far, we are still
using [Maxc]<Press> as the official release directory. If you want to know what
has changed in versions since 2.10 or so when Glen and I took over, read the
comments at the beginning of Press.Bcpl, a part of the dump file PressSources.dm
on [Maxc]<Press>.
I hope that things are going well back at Webster, and that the gypsy moths
aren't too bad this year. We've been lucking out on medflies so far. Ask your
wife to say hello to Lynn for me,
Lyle
*start*
01811 00024 US
Date: 25-Jun-82 16:41:17 PDT (Friday)
From: Beeley.ES
Subject: Revised EtherPrint Protocol
To: TelepressDesign↑
My appologies if this got to you twice.
------------------------------
Date: 25-Jun-82 9:42:41 PDT (Friday)
From: Ladner.pa
Subject: Revised EtherPrint Protocol
To: NetStandards↑.WBST, (W. Swanstrom, DLOS 185)DLOSMail.DLOS, (Wendell
Shultz, ESDS)ESMail.ES, (M. Townsend, ESDS A226)ESMail.ES, (P. England,
ES)ESMail.ES, (D. Wilkie, TOHQ 6800)MCMail.WBST, (K. Oikawa, FUJI XEROX)ESMail.ES, (C. Jacobson, DLOS 129/550)DLOSMail.DLOS, (J. Flach, Roch 023)MCMail.WBST, (J. Woolbright, HADB G221)ESMail.ES, Hruschak.Wbst, Ladner.PA, Redell.PA, Ellis.PA, Shoch.PA, Asai.PA, (Norm Reed, DLOS)DLOSMail.dlos
cc: Nekora.PA, Murphy.PA, McCrystal.PA, Vargas.pa, Ladner.pa
Reply-To: Ladner, Linden, White
The revised version of the EtherPrint (ne Telepress) protocol is filed as
[Idun]<Protocols>Specs>July82>Telepress.press
This is a 30 page document formatted for two-sided printing.
This new document makes reference to a table that is a Star document. It is filed as
[Tundra]<AlphaStds>Standards Drafts - July>EtherPrint Paper Sizes
This document contains only the chart which shows the various ISO and JIS standard paper sizes, and so I intend to wait until the next meeting to distribute copies to those of you without a Star workstation. (Message me if you would like to have a copy mailed to you.)
This revision incorporates those changes the subcommittee instructed to be made, corrects errors, and makes some small changes in the definition (without changing the functionality). A list of the changes made is filed as
[Idun]<Protocols>Specs>July82>TelepressChanges.press
This is a one page document.
----------------------------------------------------------------
*start*
04567 00024 US
Date: 29-Jun-82 10:05:23 PDT (Tuesday)
From: Beeley.ES
Subject: Re: EtherPrint Questions
In-reply-to: Ladner.pa's message of 28-Jun-82 14:04:27 PDT (Monday)
To: Ladner.pa
cc: Beeley, TelepressDesign↑
Reply-To: Ladner.pa, Beeley.ES
Bob,
Following each paragraph is my response to the questions forwarded from Jerry Elkind.
"3. Shouldn't the EtherPrint protocols require authentication of the client's
credentials? Otherwise anyone anywhere on the network can cause the printing
resource to be used, even though they may not be authorized to do so. In the
environments where printing is charged to individuals or to accounts**, the
capability for authenticating and authorizing use would seem to be important.
This comes up first on page 301, where dependencies are identified."***
** The 9700 has extensive accounting features and will probably drive its definition. See response to 5, below.
*** Authentication is a valid concern and an area we covered in our earlier design discussions where we decided that it should be included in the extensions to the protocol. At the time of our discussions the Authentication proposal was not well defined and the correct solution to this problem was not fully understood.
"4. Medium: Is it sufficient to have paper as the only medium? Doesn't the
9700 have a microfiche option**, and aren't there requirements for adding other
kinds of media as well, such as transparencies and cover stock?*** A small nit: in Interpress I believe we have used meters as the unit of measure; shouldn't we do
the same here?**** Also, for the sake of clarity and education of programmers, it
would be a good idea to define, at least in Appendix B, the dimensions of all the
paper sizes that we reference.*****"
** This is why we defined the "Medium" as a CHOICE. There are other possiblities and the CHOICE can eventually expand from paper to microfilm or whatever in subsequent updates. Again, since the 9700 offers the microfiche option, those folks will probably drive its definition.
*** As for "transparencies and cover stock" (or paper weight, color, letterhead or other preprinted, etc), this is beyond EtherPrint and has to left for Interpress Instructions for at least two reasons: (a) it deals with the page-by-page printing instructions and (b) the instructions, once defined, should remain with the master. This leaves the question of determining what a particular printer can handle unanswered. Maybe, as has been suggested, we'll have to return an Instructions-like construct which gives the spectrum of capabilities and inventory at a particular printer.
**** Interpress uses meters because it handles fractions and can perform transformations and scaling on the measurements to reduce it to usable values. Milimeters (and inches) is the typical measurement for defining paper sizes.
***** I agree, the dimensions should be defined in the spec. (They were all there at one time.)
"5. Print Attributes and Print Options: Accounting typically requires more than
just the sender name, and there should be provision for an account identifier to
which charges can be accumulated.** Also, I would think it important to have as
one of the print options a security classification identifier***. There are also other finishing options, such as a stacker, the ability to offset sets, the use of
mailboxes, microfiche output, etc.****"
** I believe that the 9700 folks wanted the accounting info in the Interpress Instructions since a lot of their clients that would be using Interpress would not (at least intially) be using EtherPrint.
*** I don't know what a "security classification identifier" would mean. Is this something that gets printed or some hint about where it is to be printed or how to handle it once its been printed?
**** Some of these were covered in our discussions but we concluded that the current options represented a common, generic capability for our range of printers. There is provision for extensions to EtherPrint by adding to the PrintOptions choices.
"6. Printer Properties: Shouldn't it be possible to determine the fonts available on a printer**, the type of printer***, whether or not it has a microfiche output, etc.?****"
** Yes, it is both desirable and possible (in an EtherPrint extension) to determine fonts. But what further properties does one want to know about the fonts: sizes, orientations, character subsets, resident at the printer or ...?
*** Please define "type of printer".
**** Possible in an EtherPrint extension.
*start*
01088 00024 US
Date: 24 June 1982 12:44 am PDT (Thursday)
From: Morris.PA
Subject: Bravo to Tioga Conversion
To: CedarUsers↑
Reply-To: Morris
I have written a program to do simple-minded conversion of Bravo files to Tioga
files. It is available via [ivy]<morris>BravoToTioga.df. To convert the file
X.bravo to X.doc, the Tioga version, run and call BravoToTioga X.
An upward compatible version of Document.style will be brought over with
BravoToTioga. You will need to use this version until the next release when it
will become the standard.
This program preserves all the font information and roughly approximates the
indenting of your bravo document. It does not attempt to produce a document
that looks identical to the bravo one. It does not preserve leading, justification,
or centering; it pretty easy for you to do these over again if Tioga's defaults
don't suit you. Tioga does not currently support, tab stops, overstriking,
underlining, or sub/superscripting. However, BravoToTioga does preserve
underlining information by giving characters the "u" look.
*start*
01105 00024 US
Date: 1 July 1982 1:17 pm PDT (Thursday)
From: Rumph.eos
Subject: DeSpruce V1.1 released
To: Allen.wbst, PrintServiceInterest↑.es
cc: Dale, Hains, Rumph
Reply-To: Rumph
DeSpruce is a program for removing Spruce headers from press files. Spruce
headers (put on by Laurel and BravoX) cause press.run and possibly Wabash
printing software to swat. This release of DeSpruce fixes a bug associated with
large files, and also is smaller, runs faster and doesn't require a scratch file,
freeing the associated disk space.
It can be retrieved from [RoseBowl]<Alto>DeSpruce.run, with sources on
[RoseBowl]<AltoSource>DeSpruce.bcpl.
To run, type "DeSpruce <Filename>," where <Filename> is a press file, with or
without a Spruce header. When DeSpruce exits, the header, if there was one,
will be gone from the press file. On Press printers, it is recommended that the
"server" command line look like this sample file, "Server.cm":
EFTP temp.press from 0;DeSpruce Temp.press;Press print Temp.press;@Server
Bug reports, comments and questions should be addressed to Rumph.eos.
Dave
*start*
00758 00024 US
Date: 21 June 1982 5:51 pm PDT (Monday)
From: Beach.PA
Subject: Press black/white halftone colors
To: GWilliams
cc: Ramshaw, Beach
My recent experience with printing color press files on Stinger combined with
Maureen Stone's reshaping of the color world in Cedar Graphics leads me to
suggest that we change our black/white Press printers to do a better job of
selecting a halftone screen.
Maureen's scheme is to use the NTSC television mapping of color into black and
white monochrome. Using the resulting intensity as a grey value permits the
graphics package to choose an appropriate screen grey. I would love to have
Press use the same mapping to select among the various grey halftone screens
available to Press.
Cheers
Rick
*start*
02187 00024 US
Date: 20-Jul-82 10:54:48 PDT (Tuesday)
From: Fisher.ES
Subject: Laser Printer Competition?
To: GWilliams.pa
Are you interested in this? Maybe SUN will take up on this effort as Symbolics is moving in that direction.
------------------------------
Date: 20-Jul-82 8:52:04 PDT (Tuesday)
From: Fisher.ES
Subject: Laser Printer Competition?
To: SDD-PFSvc↑.es
cc: Fisher.es, Nikora.ES, Newman.es
Reply-To: Fisher.ES
Folks:
I found this mesage interesting considering the Unix folks seem determined to get laser printing via the Cannon model marking engine. With nearly everyone and his brother selling Unix on a 16 bit micro, maybe this is the wave of the future for that marketplace? It isn't Interpress82, etc but then most of our customers probably don't appreciate the implementing ideas.
------------------------------
Mail-from: Arpanet host SRI-CSL rcvd at 20-JUL-82 0259-PDT
Mail-from: ARPANET host SRI-UNIX rcvd at 24-Jun-82 0844-PDT
Date: 24 Jun 1982 at 1026-CDT
From: Bill Lee <lee@utexas-11>
Subject: Re: PIC graphics package
To: mullen at NRL-CSS, mo at LBL-UNIX
cc: unix-wizards at SRI-UNIX
Via: Utexas-11.ArpaNet; 24 Jun 82 8:38-PDT
Remailed-date: 19 Jul 1982 2004-PDT
Remailed-from: the tty of Geoffrey S. Goodfellow <Geoff at SRI-CSL>
Remailed-to: Unix-Wizards: ;
In regard to your query about device-independent troff, it is now
available from AT&T. It comes with filters that drive Mergenthaler
202s, APS-5s, CAT4s and CAT8s, Tektronix 4014s, and Canon laser
printers. It also includes two graphic languages (PIC and IDEAL)
that can be used in conjunction with troff or directly. The new
troff permits up to 128 different sizes and 256 fonts and arbitrary
character sets. New EQN, TBL, and REFER preprocessors are included
as well as several macro packages. It requires separate I/D space.
Available now from AT&T (919) 697-5000. Price is $400 for educational
licenses and any number of CPUs can be licensed under a single
agreement. Additional agreements are $200. Turnaround time is
rumored to be 5 weeks.
----------------------------------------------------------------
----------------------------------------------------------------
*start*
02213 00024 US
Mail-from: Arpanet host MIT-MC rcvd at 23-JUL-82 1546-PDT
Date: 23 Jul 1982 1533-PDT
From: Richard Furuta <Furuta at WASHINGTON>
Subject: Re: Laser printer request.
To: WAGGONER at RUTGERS, Info-Printers at MIT-MC
cc: Furuta at WASHINGTON
In-Reply-To: Your message of 23-Jul-82 1328-PDT
The laser printers that we've found of interest so far are:
1. Xerox 8044/8045 (about $30,000 to 35,000--12 pages per minute, 300
dots per inch). But it seems to be hard to convince Xerox to
release the Interpress specifications so this may be limited to
being driven from Stars. Unilogic Scribe will probably support
it in time. Interpress has been said to be Xerox's new
standard language. 10 mB Ethernet interface.
2. Imagen and its interface to LBP-10. Uses the Canon LBP-10 which
is 240 dots to the inch. Around $30K. 10 pages/minute.
Supported by Unilogic Scribe, TeX, and the new TROFF. RS-232
interface. Some talk of ethernet interface.
3. Symbolics and its interface to LBP-10. Still awaiting information
on this one. Possibly $25K. Talk of all sorts of interfaces
(unibus, RS-232, ethernet, etc.). People seem quite excited by
this one.
4. Dec LN01. Based on the same print engine as Xerox 8044/45. Still
awaiting information on this one. This one is also attracting
attention.
5. Xerox 2900 (I think that's the number). A Laser Printer Diablo.
About $19K.
6. Miscellaneous others on which we don't have much information--Perq
interface to Canon LBP-10, Lilith interface to Canon LPB-10 ($15K
for the printer; the Lilith interface to the Canon--a Lilith costs
$15K and an ethernet board goes for about $3K); General Optronics'
laser printer (I don't know anything else about it).
I hope this is what you wanted to hear. It isn't quite clear from
your note if you are interested in printers in this range or if you
want the next higher range.
We also hear rumors of some fantastic products on the horizon.
In the meanwhile, we continue to crank material out on our trusty old
Versatec.
One of these days, someone should set up an Info-Laser-Printers list,
I suppose.
--Rick
-------
*start*
01127 00024 US
Mail-from: Arpanet host MIT-MC rcvd at 23-JUL-82 1615-PDT
Date: 23-Jul-82 6:29PM-EDT (Fri)
From: John O'Donnell <Odonnell at YALE>
Subject: Re: Laser printer request.
To: Waggoner at RUTGERS
Cc: Info-Printers at MIT-MC
In-Reply-To: Your message of 23 Jul 1982 1628-EDT
I have to recommend the Imagen Imprint-10. It meets all the requirements
you describe; it has nice quality output, is supported by TEX, SCRIBE, and
TROFF, has spooler/driver software for 4.1BSD UNIX, VAX/VMS, and TOPS/20,
has full METAFONT compatibility and a reasonable (and growing) font
library.
We've had one since January and have printed over 75000 pages. We have
replaced the drum once (at 55,000 pages; normal life is from 30000 to
60000 pages) and replaced a seperator belt. Once a week we clean the
corona wires. Total maintenance time: 5 minutes per week, plus 1/2 hour
to replace drum and belt.
Ours is driven off a VAX 750 running 4.1BSD and is interfaced on a terminal
line. We expect to switch to a Centronics-style parallel interface
(and speed up font downloading) shortly.
-------
-------
*start*
00844 00024 US
Date: 2 Aug. 1982 5:21 pm PDT (Monday)
From: Starkweather.PA
Subject: RPG Pattern
To: RobertAllen
cc: McCreight, GWilliams, Geschke, Starkweather
Bob, on [MAXC]<Starkweather> is a file called bandata.onoff080282. This file has
some on and off patterns of equal spaces and patterns. There are only 125 bands
in the file and hence it should not take too long to print. There is no data
beyond about 30 mm on the plate. Please run this for me when you can so that
I can observe how the pattern reproduces. The patterns vary in width and space
from 0.1 mm to 0.01 mm or 20 bits to 2 bits. As soon as you run this pattern let
me know and I can pick up the plate and enlarge some of the patterns on the
projector over in my lab at 100X on Polaroid 8x10. This should give me some
insight into any astigmatism concerns.
Gary
*start*
02243 00024 US
Date: 3 Aug. 1982 5:07 pm PDT (Tuesday)
From: Orr.PA
Subject: Error Messages from our printers
To: ISLPrint↑
Reply-To: Orr
Stinger and Quoth have different error messages which will be displayed on the
server Alto screen in times of stress.
Stinger has only one: K0. Most of the time this means that the printer is out of
paper. If so, or if there's a paper jam, the LED next to the Start Test button will
be lit. Read the directions on the printer for loading the paper cassette, do so,
lift the top of the printer and close it again, swat out of the K0 state, do press
reprint, and then type @Server.cm to put the machine back on the air. K0 may
also indicate a paper jam, in which case you open the top of the machine,
remove the paper gone astray {should be self-evident: everything not in the
paper cassette or output tray is considered to be astray}, close the machine and
proceed as above. K0 may also indicate incompatibility with your file; if the
LED is not lit, swat and do a press reprint. This may help; if not, it doesn't like
your file and you should change it.
Quoth [formerly Lenore], has three error messages. K0 indicates an undefined
printing error which is not recoverable. Check the LED display on the printer
and follow any codes displayed there to track down paper jams. It may also
indicate dissatisfaction with your file, and a swat and press reprint may help
here, too.
K1 on the Alto display indicates that the printer is out of paper. The LED
display atop the printer will say C4. Follow the directions on the printer to
replenish the paper supply, being sure to replace each paper cassette in the slot
from which it came; if it's still not happy, wiggle the paper cassettes and the
locking handle until it is.
K2 indicates that the printer has shut itself down from lack of use [a feature of
Raven printers]. The print request will start up the Raven again; until it is
ready it will display L1 on the LED display. When it is ready, the display will
go blank again; at that time, hitting CR will cause the file to print.
I trust this clarifies some of the confusion which Quoth, in particular, has
occasioned. If not, come talk to me or send me questions.
Julian
*start*
00419 00024 US
Date: 5 Aug. 1982 2:42 pm PDT (Thursday)
From: Pier.PA
Subject: ReticlePress revision
To: McCreight, GWilliams
cc: Pier
I made the change to expand each rectangle, per Ed's request. It is untested. A
(possibly useless) version of ReticlePress.bcd can be found on
[ivy]<pier>Reticle>XReticlePress.bcd.
The new source (bcd), if needed, is
[ivy]<pier>Reticle>ReticleBandsImpl.mesa (.bcd).
K
*start*
02789 00024 US
Date: 12 Aug. 1982 2:26 pm PDT (Thursday)
From: Orr.PA
Subject: FYI
To: GWilliams
Subject: We've been invaded!!!!
To: Kwaquerz82↑
From: Snake
Earth has been invaded. The most common aliens in the galaxy, the Space
Cadets, are once more present on this planet, weaving their plots against reality,
coherence, the ability to stand upright, and a straight face. No more the obvious
aliens, no tentacles, green slime, extra eyes or mandibles, no, now the foul
fiends have adopted human bodies [well, almost human] in their search for
dominance. Their vile stratagem is simple: They offer you a pipe, this clears
the space between your ears, favorite dwelling site of space cadets, then they
haul in a mobile home, use your sewer hookup, and presto!!! No, sorry, that's
another scenario . . . then they drop a cute little scorpion in your ear, it turns
around three times and presto! right between your very eyes, you're now an
alien Eichler, open beam ceiling and all.
And what stands between these dastards and the desecration of all we hold dear,
Mommie Dearest, imitation apple pie, and Japanese-made polyester flags with the
stars crooked? Why, nothing but a handful of ducks! For reasons best known to
themselves, these fowl fiends like to play Sophtspheroid. With "normal" human
opponents, everyone whom they can suck up to their pipe succumbs
immediately, they get distracted in subdividing these new housing tracts, and
that's too much like work. Others refuse the pipe and beat them senseless; cadets
derive little pleasure from this [except for a few slightly twisted ones, of
course]. Ducks, on the other hand, their lot in life does not immediately become
vacant, no, between their ears is such a dense, matted, tightly-curled,
impenetrable mass of pickerel weed that there's not room for a neuron to turn
around, let alone a fully-fledged scorpion, and I've seen some with heavy
feathers, pard. Ducks, if possible, get even denser between the ears when
exposed to pipes, and the remaining open spaces are always awash with duck
juice; some eminent alienists have gone completely gaga and had to be carried,
screaming, back to their cupboards after attempting to make sense out of a
fully-loaded duck.
And so the contest goes, pipes full of pickerel weed, aliens full of duck juice; by
the end of reeling around the bases, the ball is fowl and the cadets are so far
gone in space that the earth is saved, at least until the next game. At least so
far. The ducky defense has always held firm [ducks don't fall over, having flat
feet and low centers of gravity], but tonight?
"He's dead, Jim."
"Beam me up, Mr. Spoque, kwaque, kwaque, kwaque!!!"
Snake
------------------------------------------------------------
*start*
00500 00024 US
Date: 2 Sept. 1982 12:20 pm PDT (Thursday)
From: Plass.PA
Subject: New indigo account
To: RWeaver
cc: Stone, Warnock, Plass, Wyatt, GWilliams, Ramshaw
Please create a files-only indigo account as follows:
name: FontWorld
size: 1000 pages
access: copy [indigo]<SirPress>, plus give write access to ISL and Ramshaw, and
delete privilege to Stone, Warnock, Plass, Wyatt, GWilliams, Ramshaw.
password: STDIX
(This account is a place for Cedar font software to grow.)
Michael
*start*
00348 00024 US
Date: 4 Oct. 1982 2:01 pm PDT (Monday)
From: Rumph.eos
Subject: Re: PressBits and AIS.run
In-reply-to: Knox.wbst's message of 1 Oct. 1982 4:56 pm EDT (Friday)
To: Knox.wbst
cc: Dale, GWilliams.pa, Rumph, Hains
Keith,
Your slapped together version can in fact read bits files produced by Press 4.4.
Thanks so much.
Dave
*start*
00444 00024 US
Date: 3 Oct. 1982 9:25 am PDT (Sunday)
From: GWilliams.PA
Subject: Re: Limitation of press printer program
In-reply-to: Ramshaw's message of 1 Oct. 1982 9:56 am PDT (Friday)
To: Ramshaw
cc: Putz, GWilliams, Krasner
I don't have any info on that problem. I will be looking at the Press AIS code
for another problem in a few weeks (I'll be in Rochester next week). I'll let you
know if I find anything edifying.
Glen
*start*
00362 00024 US
Date: 5 Oct. 1982 6:54 pm PDT (Tuesday)
From: dale.EOS
Subject: Re: PressBits and AIS.run
In-reply-to: Knox.wbst's message of 1 Oct. 1982 4:56 pm EDT (Friday)
To: Knox.wbst
cc: Dale, GWilliams.pa, Rumph, Hains
Keith:
Thank you very much for doing this so quickly. We successfully obtained the
AIS files from the Press.bits file.
Dale
*start*
00828 00024 US
Date: 7 Oct. 1982 10:33 am PDT (Thursday)
From: Ramshaw.PA
Subject: Re: Limitation of press printer program
In-reply-to: Putz's message of 1 Oct. 1982 4:55 pm PDT (Friday)
To: Putz
cc: Ramshaw, GWilliams
Steve, the plot thickens. All of your test Show-Dots print fine on Lilac; but
when I try both Quoth and Stinger, I get the same results that you got, with
only the 1 bit/sample and 8 bit/sample images coming out. I have taken a first
glance at the code of PreDots, and I don't understand what the hell is going on.
I'll keep you posted.
(What version of Press is Jedi running? Is it 4.3? Also, what are the halftone
screen parameters with which it is installed? I'm grasping at straws, you
understand, trying to figure out why Lilac is different from the other Press
servers around.)
Lyle
*start*
00923 00024 US
Date: 7 Oct. 1982 10:52 am PDT (Thursday)
From: Ramshaw.PA
Subject: Re: Limitation of press printer program
In-reply-to: Putz's message of 1 Oct. 1982 4:55 pm PDT (Friday)
To: Putz
cc: Ramshaw, GWilliams
Steve,
Ah-ha! I think I have found the problem: the code in Press for rotating bitmaps
currently only handles 1 bit/sample and 8 bits/sample (each with different
special microcode for speed). Thus, if the Dots data in the Press file has its scan
lines going in the same direction as the scan lines of the printing engine
(vertical for Jedi, horizontal for Lilac), then any sample size will work. But, if
the Dots data scan lines run perpendicular to the output device scan lines, then
only 1 bit/sample and 8 bits/sample are supported at the moment. This doesn't
look too easy to fix, unfortunately: fixing it would demand writing some new
code, and probably even new microcode.
Lyle
*start*
00499 00024 US
From: Putz.PA
Date: 7-Oct-82 19:16:03 PDT
Subject: Re: Limitation of press printer program
In-reply-to: Ramshaw's message of 7 Oct. 1982 10:52 am PDT (Thursday)
To: Ramshaw
cc: Putz, GWilliams
Lyle,
Thanks for solving the mystery! I tried some examples using landscape mode (i.e. direction 8) and they work fine at 4 bits/sample. Since the color monitor I'm using (for gray-scale) is horizontal anyway, this is not a terrible constraint for now.
Thanks again.
-- Steve*start*
00702 00024 US
Date: 28 Sept. 1982 6:03 pm PDT (Tuesday)
From: Rumph.eos
Subject: AIS files from Press.bits
To: Knox.wbst
cc: GWilliams.pa, Dale, Rumph
Keith,
I recently tried, for the first time in quite a while, to extract color separations, as
AIS files, from press.bits. AIS 4.4 went into swat with the message:
GetPressPage: cannot find that page
I had used Press 4.4 to format a 1 page, 4 color bits file, and had asked AIS to
reformat page 1, the magenta separation. I suspect that Glen Williams (or Lyle
Ramshow) has changed the format of the bits file slightly, hence the copy to
Glen of this message. Could you look in to this problem when you get the
chance?
Thanks,
Dave
*start*
00736 00024 US
Date: 29 Sept. 1982 9:35 am PDT (Wednesday)
From: GWilliams.PA
Subject: Re: AIS files from Press.bits
In-reply-to: Rumph.eos's message of 28 Sept. 1982 6:03 pm PDT (Tuesday)
To: Rumph.eos
cc: Knox.wbst, GWilliams, Dale.eos
Yes, Dave, I changed the format of the Press.bits file to add a word to the "Page
Goodie" structure so that the BandWidth is now a parameter rather than a
constant. This was done to enable us to scan out very long scan lines to
experimental devices here. I just heard that this has caused problems in the ais
stuff and will look into it as soon as possible.
Glen
PS If you need the layout of the PageG, you can consult
[maxc]<Press>PressDecls.dm. Inside that is PressInternals.df.
*start*
01021 00024 US
Date: 1 Oct. 1982 9:47 am PDT (Friday)
From: Ramshaw.PA
Subject: Press query
To: GWilliams
cc: Ramshaw, Putz
Glen, Steve Putz from down the hill sent me the following message concerning a
Press printing hassle on Jedi. I will copy you on my response:
Lyle
---------------------------
Date: 30 Sept. 1982 5:35 pm PDT (Thursday)
From: Putz.pa
Subject: Limitation of press printer program
To: Ramshaw
cc: Krasner, Putz
Lyle,
Is there a document which says exactly how much of the Press format
specification is supported by Press.run?
In particular, it appears that our hornet, Jedi, will not print digital images at
other than 1 or 8 bits/pixel. I have an application using 4 bits/pixel, and it
would be nice not to have to create files twice as large as necessary.
It would be nice to have documentation of the capabilities of Press.run, so I don't
waste too much time finding these things out.
Thanks for helping.
-- Steve
------------------------------------------------------------
*start*
00820 00024 US
Date: 1 Oct. 1982 9:56 am PDT (Friday)
From: Ramshaw.PA
Subject: Re: Limitation of press printer program
In-reply-to: Putz's message of 30 Sept. 1982 5:35 pm PDT (Thursday)
To: Putz, GWilliams
cc: Ramshaw, Krasner, GWilliams
Steve, a quick glance at the code for Press suggests that it should be able to
handle ShowDots at 4bits/sample just fine. Exactly what were the symptoms
when you tried to do this on Jedi?
Glen, do you know why 4bits/sample wouldn't work? Both the bcpl code for
ScanPutHalfTone and the microcode seem to be written to handle an arbitrary
sample size.
Steve, I don't know of any documentation on the program Press worth
mentioning. One of my recent release messages had a list of the possible
switches and their meanings, but that is all that comes to mind,
Lyle
*start*
00929 00024 US
Date: 1 Oct. 1982 4:56 pm EDT (Friday)
From: Knox.wbst
Subject: Re: PressBits and AIS.run
In-reply-to: Dale.EOS's message of 1 Oct. 1982 12:46 am PDT (Friday)
To: Dale.EOS
cc: GWilliams.pa, Knox, Rumph.EOS, Hains.EOS
Dale,
Apparently you are in a hurry to reformat these images. Therefore I have
slapped together up an untested, highly unpredictable, temporary version of
Ais.run which may be able to read the new format of the Press.Bits file.
Look for:
[RoseBowl]<Knox>Ais.run
[RoseBowl]<Knox>Ais.Errors
This is not a released version, but it may hold you over until it can be released.
I have not tried it yet, so I don't even know if it will work at all.
The code change is based on a report given to me by Al Paeth, who said that the
basic incompatible change was that a fourth global word was added at the
beginning of the Press.Bits file which is the Press.Bits password, #65057.
Keith
*start*
01399 00024 US
Date: 14 Oct. 1982 5:16 pm PDT (Thursday)
From: Ramshaw.PA
Subject: The Braiding of Floating Point Lines
To: CSL-Notebook
cc: ISL↑.pa, Ramshaw
Reply-To: Ramshaw
File: [Ivy]<Ramshaw>Braiding>Braiding.Press
This Entry Updates: none
Attributes: formal, technical, graphics algorithms, arithmetic
References: none
Abstract: Two lines in the plane are either coincident, parallel, or intersect
exactly once---this is a fact of Euclidean geometry. Suppose, however, that one
is using a floating point number system to approximate the real numbers. Can
the errors in the floating point arithmetic make it appear as if two lines intersect
more than once? In particular, think of each line as a function that returns a
floating point value of the ordinate y for each floating point value of the
abscissa x. We will say that two lines braid if there exists a sequence of three
values for the abscissa a < b < c such that, at a and c, the first line is
strictly higher than the second, while at b, the second is strictly higher than
the first. This note presents enough bad examples to suggest that any
straightforward implementation of lines over the floating point numbers will
include pairs of lines that braid. It is possible to avoid braiding, but it isn't
easy; we will close by sketching one braid-free implementation, using double
precision arithmetic.
*start*
00344 00024 US
Date: 26 Oct. 1982 5:14 pm PDT (Tuesday)
From: Plass.PA
Subject: Unified fonts for Cedar, revisited.
To: ISL↑, Ramshaw
cc: Plass
Reply-To: Plass
UFonts.mesa is now called UnifiedFonts.mesa. Get the latest from
[Indigo]<FontWorld>UnifiedFonts>UnifiedFonts.mesa and
[Indigo]<FontWorld>UnifiedFonts>UnifiedFonts.press
*start*
00852 00024 US
Date: 23 Nov. 1982 3:50 pm CST (Tuesday)
From: Olivier.DLOS
Subject: Press Files on a "31" drive
To: Putman.PA
cc: GWilliams.PA, Olivier
Dan,
You asked me this morning about the PRESS version I have for a Diablo 31 disk
drive. It comes up with: press -- 6/5/79 Version 1.
The disk has the following press files:
press.bands
.bits
.errors
.fonts
.L01
.L02
.meter
.run
.scratch
.state
I hope this helps. If this sounds like something you need, I can make some kind
of arrangements to send you a copy of the disk. As far as I'm concerned, I guess
it doesn't really make much difference which kind of drive I run press on. I'm
getting a couple of T-80 drives from the Cactus server (they are upgrading to
T-300) so it would probably be a good idea to use one of those (if I can find a
place for them here).
Richard
*start*
03164 00024 US
Mail-from: Arpanet host MIT-MC rcvd at 29-NOV-82 1138-PST
Date: 29 Nov 1982 1059-PST
From: Chris Ryland <g.Ryland at SU-SCORE>
Subject: Re: inexpensive laser printers & misinformation
To: info-vax at SANDIA, info-printers at MIT-MC, mark.umcp-cs at UDEL-RELAY
Brian Reid's recent missive concerning laser printers was mostly quite
informative, but on the issue of the IMAGEN vs. Symbolics printing systems,
he is rather misinformed and, I think it is fair to say, blatantly vitriolic.
NB: I work for IMAGEN, but I'll try to keep my remarks objective.
The Symbolics Canon-based printer is NOT based on the LM-1 or LM-2 or any
such beast; if it were, it would cost about $125K! It has a custom 68000
board stuck inside the Canon. Brian says the Symbolics system has "extremely
good software support for various printing formats, including those used
by TRoff, TeX and Scribe." (this is in contrast to the IMAGEN printer, he
claims, which supports TRoff output "at substantially degraded quality.")
Sorry, Brian, both Symbolics and IMAGEN support TRoff in exactly the same
way, with exactly the same quality of output: TRoff's CAT output is converted
to the native language of the printer in question. Further, Scribe DOES NOT
support the Symbolics printer. It may in a few months, but check with
Unilogic for details. Scribe DOES support the IMAGEN printer, and since
Unilogic has an IMAGEN printer, it will probably always have rather good
support for it.
Brian claims the Symbolics printer can "use Chaosnet or Ethernet links
at additional cost." Ignoring the confusion of hardware vs software
protocols, that is false at the current time. Symbolics is planning (I've
heard) to offer 10mb Ethernet hardware with Chaosnet protocols (just fine
if you have Lisp machines) sometime in first quarter '83. Let me point out
that IMAGEN will offer 10mb Ethernet hardware, with both Chaosnet and
TCP/IP software, within 3 months (1 March 82).
Back to the "substantially degraded quality" of output from the IMAGEN
printer. Besides being false, it will get more false, as IMAGEN will be
offering, as part of the first commercial release of the software in its
printer, a native CAT emulation mode to avoid the host overhead of
the conversion from CAT to native language.
Brian's claim that the firmware is extremely flakey, requiring a reset
every 4 jobs he prints, can only come from some extreme confusion about
something. IMAGEN has 70+ systems in the field, and none of them have
complained about such a situation (neither has Brian complained to us
directly, so that we might clear up any problems which he might have).
Also note that Stanford has 17 systems, all of them bought at 10% list
price, and that part of IMAGEN's agreement with Stanford is that they
would maintain them themselves; thus, Brian's claim that he can't get
any support out of IMAGEN is puzzling.
If you are still convinced by Brian's misleading statements, try contacting
some of IMAGEN's customers. Most of them are extremely happy (modulo the
inherent problems with the LBP-10, which, as a wet process printer, has
drawbacks).
--Chris Ryland
-------
*start*
08190 00024 US
Date: 6 Dec. 1982 7:06 am PST (Monday)
From: MMacKay.ES
Subject: More Opinions on Laser Printers
To: Filbrich, Hansford, ElectronicPublishingInterest↑.PA, PageImaging↑.ES,
MayflowerInterest↑.ES
cc: RAcosta, DFlynn, Shipper, PNeumeister, Pellar, Reilly
Reply-To: MMacKay
I have attached three more interesting letters on the topic of the Arpa
community's experiences/opinions of the inexpensive laser printer market. Please
note the last one is from a 2700 user!
//Michael
---------------------------
Mail-from: Arpanet host SRI-CSL rcvd at 4-DEC-82 1657-PST
Mail-from: ARPANET host SANDIA rcvd at 29-Nov-82 1108-PST
Mail-from: ARPANET site SU-SCORE rcvd at 29-Nov-82 1203-MST
Date: 29 Nov 1982 1059-PST
From: Chris Ryland <g.Ryland at SU-SCORE>
Subject: Re: inexpensive laser printers & misinformation
To: info-vax at SANDIA, info-printers at MIT-MC, mark.umcp-cs at
UDEL-RELAY
Remailed-date: 4 Dec 1982 1047-PST
Remailed-from: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-to: Info-VAX@SRI-CSL: ;
Brian Reid's recent missive concerning laser printers was mostly quite
informative, but on the issue of the IMAGEN vs. Symbolics printing systems,
he is rather misinformed and, I think it is fair to say, blatantly vitriolic.
NB: I work for IMAGEN, but I'll try to keep my remarks objective.
The Symbolics Canon-based printer is NOT based on the LM-1 or LM-2 or any
such beast; if it were, it would cost about $125K! It has a custom 68000
board stuck inside the Canon. Brian says the Symbolics system has "extremely
good software support for various printing formats, including those used
by TRoff, TeX and Scribe." (this is in contrast to the IMAGEN printer, he
claims, which supports TRoff output "at substantially degraded quality.")
Sorry, Brian, both Symbolics and IMAGEN support TRoff in exactly the same
way, with exactly the same quality of output: TRoff's CAT output is converted
to the native language of the printer in question. Further, Scribe DOES NOT
support the Symbolics printer. It may in a few months, but check with
Unilogic for details. Scribe DOES support the IMAGEN printer, and since
Unilogic has an IMAGEN printer, it will probably always have rather good
support for it.
Brian claims the Symbolics printer can "use Chaosnet or Ethernet links
at additional cost." Ignoring the confusion of hardware vs software
protocols, that is false at the current time. Symbolics is planning (I've
heard) to offer 10mb Ethernet hardware with Chaosnet protocols (just fine
if you have Lisp machines) sometime in first quarter '83. Let me point out
that IMAGEN will offer 10mb Ethernet hardware, with both Chaosnet and
TCP/IP software, within 3 months (1 March 82).
Back to the "substantially degraded quality" of output from the IMAGEN
printer. Besides being false, it will get more false, as IMAGEN will be
offering, as part of the first commercial release of the software in its
printer, a native CAT emulation mode to avoid the host overhead of
the conversion from CAT to native language.
Brian's claim that the firmware is extremely flakey, requiring a reset
every 4 jobs he prints, can only come from some extreme confusion about
something. IMAGEN has 70+ systems in the field, and none of them have
complained about such a situation (neither has Brian complained to us
directly, so that we might clear up any problems which he might have).
Also note that Stanford has 17 systems, all of them bought at 10% list
price, and that part of IMAGEN's agreement with Stanford is that they
would maintain them themselves; thus, Brian's claim that he can't get
any support out of IMAGEN is puzzling.
If you are still convinced by Brian's misleading statements, try contacting
some of IMAGEN's customers. Most of them are extremely happy (modulo the
inherent problems with the LBP-10, which, as a wet process printer, has
drawbacks).
--Chris Ryland
-------
---------------------------
Mail-from: Arpanet host SRI-CSL rcvd at 4-DEC-82 1711-PST
Mail-from: ARPANET host SANDIA rcvd at 1-Dec-82 0026-PST
Mail-from: ARPANET site SU-SCORE rcvd at 1-Dec-82 0126-MST
Mail-from: SU-NET host Shasta rcvd at 1-Dec-82 0026-PST
Date: Wednesday, 1 Dec 1982 00:25-PST
To: Randy Frank <FRANK at UTAH-20>
Cc: mark.umcp-cs at UDEL-RELAY, info-vax at SANDIA
Subject: Re: inexpensive laser printers
In-reply-to: Your message of 1 Dec 1982 0040-MST.
From: Brian Reid <reid%Shasta at SU-Score>
Remailed-date: 4 Dec 1982 1047-PST
Remailed-from: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-to: Info-VAX@SRI-CSL: ;
The last I heard from DEC engineering, through my contacts out here at
the DEC Western Research Lab in Palo Alto, the LN01 as delivered will
not be able to print bitmaps. It's basically not possible to print
full-page bitmaps over a Unibus given their speed and addressing
capability; you must have some kind of a controller between the
computer and the printer. Whether that controller is a full-page frame
buffer (12 megabits for the LN01) or a clever synthesis interface like
the Imagen printer uses, you can't send that kind of traffic over a
Unibus. So if they are getting it to work at all with bitmaps, they are
either building a much fancier controller, building an SBI interface or
a Massbus interface (both expensive), or pulling some trick that I
can't even imagine.
I'll believe a 2700 printing Interpress (or any other
Scribe-generatable format) when I see it. I'm not holding my breath. If
those guys really wanted to make printers and not glorified
typewriters, they could have done so a long time ago.
---------------------------
Mail-from: Arpanet host SRI-CSL rcvd at 4-DEC-82 1722-PST
Mail-from: ARPANET host SANDIA rcvd at 1-Dec-82 0745-PST
Mail-from: ARPANET site CMU-CS-A rcvd at 1-Dec-82 0841-MST
Mail-From: CMUFTP host CMU-PSY-A received by CMU-10A at 1-Dec-82
10:39:47-EST
Date: 1-DEC-1982 10:31
From: LUCAS@CMU-PSY-A@CMUA
To: INFO-VAX@SANDIA@CMU-CS-A
Subject: re: inexpensive laser printers
Remailed-date: 4 Dec 1982 1047-PST
Remailed-from: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-to: Info-VAX@SRI-CSL: ;
We have just begun a trial lease of a Xerox 2700 and, while it leaves
much to be desired, I feel that Brian Reid's criticisms of the machine are
a bit overstated:
--It is true that the 2700 is not nearly as flexible as the 9700, but it
WILL accept down loaded fonts (on a page-by-page basis if necessary)
and allows up to maybe 3 or 4 fonts to be stored simultaneously and
arbitrarily mixed on a page. Text may be positioned at arbitrary
absolute positions, and it can draw vertical and horizontal lines
of nearly any width (no diagonals, though). It's resolution of
300 dots/inch is identical to the 9700's.
--At 12 pages/min, it is rather more than marginally faster than a
double-daisy printer. It is also faster than the Canon LPB-10
which is spec'd at 10 pages/min.
--At $19K, I believe it is the least expensive of the currently available
choices. More interestingly, it can be leased it for about $600/month,
plus a page charge after 5000 copies. This includes the same kind of
quick-response maintenance that Xerox provides for their copiers.
On the other hand, here are our most serious complaints about the 2700:
--Xerox refuses to provide detailed technical information about such things
as font file formats. (If anybody manages to figure out how to create
new fonts, we'd sure like to hear about it.)
--The apparent inability to download bitmap graphics is most unfortunate.
--The limits on number of fonts/page and overall page complexity imposed
by the device's memory limitations may turn out to be a problem, but we're
not sure yet.
As for advice: I completely agree that now is not quite the
time to buy a bottom of the line laser printer. In this regard, the
ability to lease the 2700 and to have Xerox maintain it is the best thing
that machine has going for it.
After surveying our options, our decision was to lease a 2700 on
a fairly short-term basis, and to wait until something better comes along.
-Pete Lucas
------------------------------------------------------------
*start*
08516 00024 US
Mail-from: Arpanet host MIT-MC rcvd at 26-NOV-82 1420-PST
Mail-from: ARPANET host SANDIA rcvd at 26-Nov-82 0901-PST
Mail-from: ARPANET site SU-SCORE rcvd at 26-Nov-82 1003-MST
Mail-from: SU-NET host Shasta rcvd at 26-Nov-82 0901-PST
Date: Friday, 26 Nov 1982 08:50-PST
To: mark.umcp-cs at Udel-Relay
Cc: info-vax at Sandia
Subject: inexpensive laser printers
From: Brian Reid <reid@Shasta at SU-Score>
Remailed-date: 26 Nov 1982 1322-PST
Remailed-from: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-to: info-printers at MIT-MC
This is a slightly premature time to buy an inexpensive laser printer,
because the availability of good printers on the market is going to get
quite a bit better soon. Let me tell you, though, what is available now.
But first some background information.
A laser printing system consists of a marking engine, an interface that
can operate that marking engine, and a set of supporting software,
including fonts, conversion programs, and so forth.
There are only 2 marking engines available in commercial products in
the U.S. today; all of the laser printers that are available are built
out of these. The first is the Canon LBP-10, the second is the Xerox
XP-12. The LBP-10 is a wet-toner system, capable of rectangular pixels
480/inch horizontally by 240/inch vertically. The Xerox XP-12 is a
dry-toner system, capable of round pixels 384/inch apart, but delivered
from Xerox configured for 300/inch. All printer products that are
available today built around the LBP-10 print 2 rectangles per pixel,
giving an effective "spot size" of 240/inch; all printer products that
are available today built around the XP-12 operate it at about
300/inch. The XP-12 is essentially a Xerox 3300 copier, with a laser
scanner and a small amount of electronics added. I do not know the
Canon copier model number to which the LBP-10 is equivalent.
Wet process gives extremely good image resolution and good contrast;
dry process is capable of being faster, and is substantially cheaper to
operate. It is possible to tune a dry-process system to give resolution
and contrast that is just as good as a wet-process system, but they
seem to drift out of tune more quickly. Wet-process imaging systems
give of noxious fumes (primarily a chemical called Isopar-G), and
should not be operated in a room where people work. Dry-process imaging
systems do not give off fumes, but there has been some controversy over
the toxicity of the toner particles. Essentially all high-end copiers
that you have seen, such as Xerox and IBM and Kodak, use dry-process
imaging; many low-end copiers use wet process.
I have seen prototypes of numerous fantastic new marking engines,
primarily of Japanese manufacture, that are a lot better than either of
these devices, but I am not aware of any currently-available printing
system that uses any of the next-generation marking engines yet; they
might hit the market in about a year if everything goes right.
Very well; time to get on to the printers that are available made out
of these components.
2 companies currently offer printing systems made out of the LBP-10.
Symbolics, of Cambridge Mass, offers a system based on their LM-2
processor. The Symbolics system costs something like $24K, as I recall,
and has extremely good software support for various printing formats,
including those used by TRoff, TeX, and Scribe. The Symbolics system
can connect to your computer over its line-printer interface, which is
reasonably fast, and can also use Chaosnet or Ethernet links at
additional cost. I have never seen an official statement from Symbolics
about the fonts that come with the printer and/or can be bought with
it, but the Symbolics printers that I have seen sported a large
collection of fonts gleaned from a wide variety of sources; I was
somewhat suspicious as to the copyright status of some of them.
Imagen, of Palo Alto CA, offers an LBP-10 system based on the Sun
processor. The Imagen printer was designed to be a TeX printer, though
it can print TRoff output (at substantially degraded quality) by means
of a conversion program. A Scribe option is recently available that
permits Scribe to generate files for the Imagen Canon. The Imagen Canon
connects to its host computer over a 9600-baud terminal line. My lab at
Stanford has 2 Imagen Canons, and we have had no end of trouble with
them, and have had absolutely zero luck in getting any support out of
Imagen even though they are right in the same city as us. The software
is unbelievably flaky; about every 4th time I go to print a file on it
I have to go power-cycle the controller because the firmware has
wedged. Nevertheless, the thing does more or less work, and continues
to work without maintenance, which is a good thing given that we can't
find anybody to maintain it or teach us how to maintain it. The
software development person recently at Imagen is an old friend of
mine, and he recently promised me that "things are going to get better".
We have contemplated trading in our Imagen Canons for Symbolics Canons,
but if we did that we'd still just have Canon LBP-10 printers, which
aren't wonderful enough to make that cross-country trade worth the
hassle. I have no experience with Symbolics support and maintenance,
but I have a hard time believing that it is as bad as Imagen.
4 companies currently make printers out of the Xerox XP-12, but none of
those offerings is entirely satisfactory. Xerox Printing Systems makes
their model 2700 laser printer by adding an 8086-based controller and a
couple of fonts to the XP-12. It is my opinion that Xerox has no
business calling the 2700 a laser printer, because it doesn't really
offer any more functionality than a double-daisy printer, and is
marginally faster. The 2-page ads that Xerox takes out in Scientific
American in which it implies that the 2700 is somehow a slower version
of their 9700 printer (third of a million dollars and worth every penny
of it) are bordering on fraud; the 2700 is completely unsatisfactory
for any text processing application. DEC sells the equivalent of the
2700, and calls it the LN01, but doesn't try to pretend that it is a
full-capability laser printer. I have also heard that Wang makes a
product out of the XP-12, and I would assume that it is functionally
similar to the 2700, which is to say it is a monofont word processing
printer.
Xerox Office Systems makes their 8045 printer out of the XP-12 also.
The 8045 is a real printer; it can print pretty much arbitrary
combinations of text and graphics. Nevertheless, there are several
reasons why it is not the printer that you want. The first reason is
that Xerox won't really sell you one. Or at least they wouldn't sell me
one. Whenever I have asked about buying an 8045, the salesman told me
that they wouldn't sell me one unless I bought some number of Star
workstations. The second reason is that the 8045 is expensive; it comes
with a full Star processor and a 40-megabyte disk. The price that was
quoted to me in July 82 was around $40K. The third reason that you
don't want an 8045 is that Xerox refuses to divulge the file format for
it. The 8045 uses a file format called Interpress, which is extremely
nice and wonderfully general and all that, but you will have to resort
to industrial espionage if you want to find out how to make files in
Interpress format, and my spies at Xerox tell me there is not much
chance of that changing.
There is a company somewhere in the southeast, Atlanta I believe,
called Quality Micro Systems, that offers a printer built out of the
XP-12. They showed it at the Siggraph conference in Boston in June (I
did not attend). I am not aware of any QMS printers having been
delivered to customers, and I haven't got a clue as to what QMS is
going to do for software and fonts; I consider it quite unlikely that
QMS will come up with anything that I want to buy anytime in the next
12 months.
The bottom line is that if you want a printer right now, you should buy
a Symbolics Canon or an Imagen Canon. Based on my own personal
experience I would strongly recommend that you go with Symbolics
instead of Imagen, but the Imagen is cheaper. I am sufficiently
frustrated by all of this that I am building my own printer out of the
XP-12, but it will be at least 6 months before my printer and its
associated interfaces and software are up and running, and another 6
months to a year before somebody is able to manufacture copies of it.
Brian Reid
Stanford
*start*
07700 00024 US
Date: 18 Jan. 1983 11:33 am PST (Tuesday)
From: Putz.pa
Subject: Re: Digital Image Data Compression
In-reply-to: GWilliams' message of 13 Jan. 1983 2:26 pm PST (Thursday)
To: GWilliams
cc: Putz, Krasner, Ingalls
I have done a little experimenting, and have come up with a tentative
compressed bitmap file format. Please give me any reactions or suggestions to the
information below.
Background
-----------
We basically deal with four kinds of digital images in SCG:
1. Smalltalk screen images (1024 x 808 x 1) or subsets thereof. These normally
have a halftone gray background and several windows containing mostly text.
2. Bitmap images composed in the Smalltalk Form Editor (up to 1024 x 680 x 1).
These are mostly hand-drawn, and vary greatly in content and style.
3. AIS images from a Jasmine scanner (up to 700 x 900 x 8 @ 85 samples/inch).
Many of these are of black-and-white material, and are thresholded to increase
contrast.
4. Bitmap images scanned by a TC200 telecopier (2016 x 2600 x 1 @ 239
samples/inch). Many of these will be scanned text, for character recognition.
The TC200 can also be used as a printer.
My latest interest in data compression is for the TC200 output, but while I'm at
it, I would like to tackle the problem for our other digital images.
File Formats In Use
-------------------
We currently use the following encodings and file formats:
".form" format:
A 4 word header containing:
1 -- specifies ".form" format
width -- bits per scan line
height -- number of scan lines
offset x -- the form origin offset, usually zero,
offset y sometimes negative (two's-complement).
Followed by height * floor ((width + 15) / 16) words of data.
Each scan line is padded to the next word boundary.
"Form storeOn:" encoding (used by the Smalltalk Galley Editor):
A Smalltalk (text) expression which, when evaluated, creates a Form
object. e.g.:
(Form extent: 300@200
fromCompactArray: #(
'scan line 1 run-encoded as a string'
'scan line 2 run-encoded as a string'
...etc...
'scan line 200 run-encoded as a string'
)
offset: 0@0)
Of course, the actual strings contain arbitrary characters with values from
0 to 255. Occurances of the single quote character are doubled. The run
encoding used is:
For consecutive runs of any byte value, <0> <count> <value>.
For a single non-zero byte value, <value>
For a single zero byte, <0> <0>
".ais" format (generated by Jasmine scan program):
AIS File format is described in detail elsewhere. The AIS files we use
have a 1024 word header, are UCA (Uncompressed Array) coding type,
contain 8 bits/sample, and are unblocked. The beginning of the header
looks like:
AIS password (102252b)
header length (1024)
type | length (1 bitShift: 10) + 10
scanCount
scanLength
scanDir (3)
samples/pixel (1)
coding type (1 = UCA)
bits/sample (8)
words/SL (scanCount/2)
SL/block (-1 = no blocking)
padding/block (-1 = no blocking)
0 (end of header parts)
The data starts at word 1024 and consists of sequential scan lines
containing scanCount bytes each.
".bits" format (generated by TC200 scan program):
I don't know what the header format is. All I know is that the header is
14 pages (of 256 words) long. The data is divided into 32 page blocks.
Since the image is 2016 bits wide (126 words), there are two words of
padding at the end of each block of 65 scan lines. There appear to be
about 2600 scan lines.
Note that this bears no relation to the Versatec Plotter ".bits" format.
Is this similar to the format of "Press.bits"?
I would like to know what the complete file format is.
Data Compression Statistics
--------------------------
I have experimented with some different run-encoding schemes.
The "Form storeOn:" encoding appears to give a compression ratio of about 1.4
(30% savings) when applied to Form Editor forms (Dan's measurements).
A binary version of the same compression scheme does slightly better at about
1.72 (42% savings).
If the byte <174> is used instead of <0> to indicate a run, the compression goes
up to 1.78 (44%).
If I use your trick of xoring each scan line with the previous one, the ratio is
1.87 (47%).
Combining the xor trick and using <174> instead of <0> gives a compression ratio
of 1.96 (49% savings).
I then tried a different run-encoding which is more like the one you described.
It only encodes solid black and white runs. The main difference is that it is still
byte oriented.
Runs of <0> or <255> bytes are encoded as <flag> <colorBit|count>.
Actual flag bytes are represented by <flag> <0>.
All other bytes simply occur as <value>.
Using <0> as the flag gives a compression (on the same data) of 1.83 (45%).
Using <174> as the flag gives 1.89 (47%).
Using xoring and a <0> flag gives 2.01 (50%).
Using xoring and a <174> flag gives the best result so far, 2.11 (53% savings).
On another set of forms (mostly portions of Smalltalk screens), this last method
gave a compression of 2.74 (64% savings).
On a page of text scanned with the TC200, the ratio was about 8:1 (87%), while
on a complicated drawing, only about 5:1 (80%).
Note that Glenn Krasner found that straight run-encoding, always using two
bytes per run, gives about 1.5 compression (33% savings).
I would be interested in running your compression algorithm over some of this
data and comparing the results. I didn't implement your algorithm because of its
complexity, but if it performs much better it might be worth it.
A Compressed Bitmap File Format
---------------------------------
I have tentatively designed a file format using the last compression algorithm
mentioned above. It is based on the AIS File format:
AIS password (102252b)
header length (12)
type | length (1 bitShift: 10) + 9
scanCount
scanLength
scanDir (3)
samples/pixel (1)
coding type (2 = Compressed Array?)
bits/sample
origin x
origin y
0 (end of header parts)
The run-encoded data starts at word "header length". As in the previous
encodings, the scan lines are always padded to the next even byte before
run-encoding, but the run-encoded scan line is not padded (i.e. scan lines may
start on odd bytes).
The origin x and origin y words are two's-complement integers which are the
negative of the offset values in the ".form" format.
I have also designed an optional "scan line index" part for the header, allowing
more efficient access to portions of the data without decoding all previous scan
lines:
type | length (5 bitShift: 10) + length
increment (k)
scan 1 length number of bytes in first scan line encoding
scan k+1 length number of bytes in k+1st scan line encoding
scan 2k+1 length ...
...etc...
See AIS File documentation for complete syntax of AIS File headers.
A typical index increment (k) might be 16.
Compressing 8-bit AIS Images
-----------------------------
By leaving in the bits/sample entry, this scheme could be used for 8 bit/sample
AIS files also, although based on some very limited experiments, I was surprised
to find that the compression obtained was only about 1.45 (31%) and moreover
that the results were slightly better (1.48, 32%) when the xor trick was not used.
Since many of our AIS images are heavily thresholded anyway, I am considering
reducing them to 4 bits/sample. Not only will this immediately cut the amount
of data in half, but the run properties should improve quite a lot, since "noise" is
removed from the data. This should give an overall compression ratio of 4 or 5.
I would also be interested in other compression schemes which do better on this
kind of data.
*start*
00836 00024 US
Received: from MIT-MC.ARPA by PARC-MAXC.ARPA; 24 JAN 83 10:31:46 PST
Return-path: <@MIT-MC:ACUFF@RUTGERS>
Date: 24 Jan 1983 1309-EST
From: Rich Acuff at Ohio State <Acuff@RUTGERS>
Subject: Three laser printers.
To: Info-Printers@MIT-MC
At Ohio State we are considering three laser printers: The Xerox
2700, The Symbolics LGP, and the Imagen Imprint 10. From the info we
have on software, reliability, quality, speed, and price it seems that
the Imprint 10 is the best of the three. Does anybody have any
comments that haven't gone by before and aren't in the sales lit.?
Specifically, Imagen seems real angious to sell us one of their
machines, while Symbolics has a "well, ok, here is the sales info"
attitude. Is this reflected in the after-sale support from either
company?
Thanks,
-- Rich
-------
*start*
00330 00024 US
Date: 5 Jan. 1983 3:53 pm PST (Wednesday)
From: Pier.PA
Subject: PD Format Memo Available
To: ISL↑
cc: Pier
Reply-To: Pier
If you are coming to the Interpress meeting tomorrow, you may want to read
[IVY]<Pier>PDFormat>PDFormat.press
which is a memo and figures describing the proposed PD format.
Ken
*start*
00388 00024 US
Date: 10 Jan. 1983 4:58 pm PST (Monday)
From: Pier.PA
Subject: PD Format Memo
To: ISL↑, McCreight, Rider.ES
Reply-To: Pier
The "final" version of the PD Format-Version 1 description is available on
[IVY]<Pier>PDFormat>PDFormat.press
We are seeking a new, pronounceable name for PD files. Any and all
suggestions are welcome. Please reply within a week.
Ken
*start*
00215 00024 US
Date: 27 Jan. 1983 5:11 pm PST (Thursday)
From: GWilliams.PA
Subject: Printers
To: Clark
cc: GWilliams, Paxton
Larry,
I stopped by to chat about printers. Would you give me a call?
Glen
*start*
00264 00024 US
Date: 25 Jan. 1983 5:12 pm PST (Tuesday)
From: GWilliams.PA
Subject: PD Files
To: Pier, Paxton
cc: GWilliams
Ken, I could use a dummy, or mocked-up PD file to have something to shoot for
in preliminary testing. Is this a problem?
Glen
*start*
00383 00024 US
Date: 25 Jan. 1983 6:51 pm PST (Tuesday)
From: Pier.PA
Subject: Re: PD Files
In-reply-to: GWilliams' message of 25 Jan. 1983 5:12 pm PST (Tuesday)
To: GWilliams
cc: Pier, Paxton
If I don't have a PD file generator hooked to CedarGraphics within say a week, I
will take a day out and write a special purpose program to generate a mocked-up
PD file. OK?
Ken
*start*
08393 00024 US
Received: from MIT-MC.ARPA by PARC-MAXC.ARPA; 1 FEB 83 12:02:18 PST
Return-path: <@MIT-MC:CMP.COHEN@UTEXAS-20>
Date: 1 Feb 1983 1232-CST
Sender: CMP.COHEN at UTEXAS-20
Subject: Re: Three laser printers.
From: CMP.COHEN at UTEXAS-20
To: Acuff at RUTGERS
Cc: Info-Printers at MIT-MC
Message-ID: <[UTEXAS-20] 1-Feb-83 12:32:27.CMP.COHEN>
In-Reply-To: Your message of 24 Jan 1983 1309-EST
Here are what rumors/facts/misunderstandings I know about the Imagen
Imprint-10, the Symbolics LGP-1, and the Xerox 2700, &c. (Any of you out
there who know better, please correct me.)
1. The Xerox 2700 uses the same print engine as the Xerox Star, but
has an entirely different interface, which is said to be a "loser".
It is said to be designed (more or less) as a line printer replacement
(presumably for printing business reports, etc.) You cannot define
your own fonts, although Xerox will sell you multiple fonts.
2. Both the Symbolics LGP-1 (Laser Graphics Printer 1), and the
Imagen IMPRINT-10 are based on the same print engine (sold to OEM's
by Canon.) It has a resolution of 240 dots per inch, which is the
minimum that is usable. Both Imagen and Symbolics build an interface
based on a M68000, to convert reasonable input (ASCII characters and
font information, etc.) into the video signal required by the print
engine. The two interfaces (of course) interact with the host computer
using different protocols and different print file formats.
We have three laser printers on campus: an IBM 6670, an Imprint-10, and
an LGP-1, so I will give a few impressions of each.
3. The IBM 6670 is given to the user by IBM with minimum font support.
You can drive it from your 370 using the Script formatter. The 6670
will hold 4 fonts, and you must define the entire font. Fonts can
only be defined at the beginning of a page (and underlined text is a
separate font!) The 6670 will accept normal line printer input with
ANSI carriage control. (E.g., it will automatically convert overprinting
using "+" in column 1 to bold face.) IBM does not support user defined
fonts, but it turns out that you can build your own font files if you
want to. The print quality is quite good, comparable to the Xerox 2700,
I would say. (This machine belongs to the Computation Center, and I
don't know much about it.)
4. The Imprint-10. Imagen has been selling these longer than Symbolics,
and they make much of the fact that they have lots of "field experience"
with their product. The Imprint-10 will take Metafont fonts. (Metafont
provides the Canon as an output device option.) They provide C programs
that are supposed to convert CAT files to their IMPRESS format. They
are intended to work on a VAX; I don't know how well they work on a
DEC-20. (After having a student spend some time trying to bring them up
on the 20, we got the Imprint-10 driver for Scribe, and use that
directly.) There is a DEC-20 program to convert TeX DVI files to
IMPRESS format. We have only tried the convert on a few DVI files; it
worked on some, but broke on others. I don't know the details. They
also provide a program that will convert an ASCII file to print in an
arbitrary font.
At the moment you can only drive the printer over an RS-232 line
(maximum speed is 9600 baud, I believe. That is as fast as we can go,
anyway.) They provide a program that will check to see if the printer's
TTY line is free, and (if so) assigns it, sends a file to the printer,
and then deassigns the TTY line. This requires the user to wait until
the printer is free, and actually run the job himself. We have
developed a TOPS-20 spooler that runs under QUASAR, with an interface
similar to the PRINT command. Imagen plans to produce an Ethernet
interface "sometime this spring."
[Side note: We have experienced intermittent print job errors ever since
we got the spooler up. This has finally been diagnosed after several
calls to Imagen, and some prodding. Every IMPRESS file starts with a
"job name", which is documented as an ASCIZ string, and serves no
function other than to be printed out on the Imprint-10's console. No
string length limitation is mentioned in the documentation. Imagen
finally informed us that the string should be no longer than 50 characters
or it would overwrite something in memory. None of our job names were
longer than 50 characters, but cutting the limit to 10 characters did
appear to solve the problem.]
5. The Symbolics LGP-1. We have one of these, also connected to a
DEC-20. The interface and file format are somewhat simpler than the
Imagen, but (over the RS-232 interface) you cannot get the printer
status. They have a built-in fonts that allow you to use the LGP-1 as
a line printer with 82 lines per page. Currently the LGP-1 will accept
graphics output intended for a Tektronix graphics terminal, and print
it. They also say they will support Diablo and GSI CAT formats, but I
don't know whether that will be in the device itself, or whether they
intend to put filters on the host.
The LGP-1 offers Centronics and Unibus interfaces, also. We are using
the RS-232 interface, because the printer is remote from the central
site. They take a straight byte stream (unlike the Imprint-10, which
uses a packetized stream with acknowledgements to build a reliable byte
stream), and we have not experienced any problems with this scheme. I
believe that over the other interfaces the host can get status
information from the printer. (Certainly their LISP machines get status
back from the printer, and they go through the UNIBUS connection.)
Symbolics is small company started by some people from the MIT AI Lab.
They got a bunch of venture capital to build LISP machines. The LGP-1
is another product, and their board of directors would not let them sell
the LGP-1 separately from the LISP machines until they could arrange an
adequate maintenance network. I believe that they have arranged to have
General Instruments or TRW do the local maintenance.
Unilogic is supposed to provide Scribe support for the LGP-1 sometime
soon. We are driving it from Impress files and DVI files using an ELISP
driver to do the conversion.
The Symbolics machine appears to have slightly more font memory than the
Imprint-10.
Symbolics intends to produce an Ethernet interface sometime "this
spring".
[Side note: We received the Symbolics LPG-1 early, curtesy of our local
sales rep. We called their expert in Cambridge, and he gave us
instructions on installation over the phone. It took about 30 minutes,
and was no problem. Imagen had an installer come in to unpack and set
up their beast. The Imprint-10 installation does involve installing
their interface boards, as well as setting up the print engine. Unlike
the Symbolics boards, which fit into the Canon cabinet, the Imagen
boards are based on the SUN processor, and are a different size,
requiring a small box be attached to the printer cabinet.]
6. There was a rumor that Symbolics and/or Imagen is looking around for
a higher resolution print engine, but I have not heard that directly.
7. DEC's LN01 is based on the same Xerox print engine as the 2700 and
the Star print server. Xerox OEM's the engine to DEC and Wang, who then
build their own interfaces and resell it. I don't know anything about
the quality of these interfaces.
8. Brian Reid of Stanford has designed a new interface for that same
print engine. It drives the printer at 400 dots per inch. (The Xerox
interfaces only drive it at only 300 dots per inch, because they can't
generate the video to keep up at 400 dots per inch.) There is a
possibility that this may become a product, and become generally
available. It will take PRESS file format as input.
9. Delfax (a Canadian company) makes an "ion deposition" print engine.
It is rated at 240 dots per inch, but output does not look nearly as
good as the Canon printers. However, this beast does produce 60 pages
per minute. They want to OEM this printer to someone who will build an
interface for it. Last summer they were talking with Symbolics, more
recently I heard they were talking to BBN.
The price info I have is: retail for the LGP-1 is $25K retail, and
slightly over $23K to universities. The Imprint-10 is $29K retail, and
$24,900 to universities with 50% down and 50% net 30 days. I don't know
about the rest.
-- Rich
*start*
02535 00024 US
Received: from MIT-MC.ARPA by PARC-MAXC.ARPA; 12 FEB 83 05:15:41 PST
Return-path: <@MIT-MC:imagen!cpr@Berkeley>
Date: 12 Feb 83 05:08:15 PST (Sat)
From: imagen!cpr@Berkeley.ARPA
Message-Id: <8301121308.23995@UCBVAX.BERKELEY.ARPA>
Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83])
id AA23995; 12 Feb 83 05:08:15 PST (Sat)
To: acuff@rutgers.ARPA, cmp.cohen@utexas-20.ARPA, info-printers@mc.ARPA
Rich: A few corrections from an IMAGEN employee. You're comparing with the
old IMAGEN (release 0) product; the new (release 1) product, which was
announced publicly last week, completely changes the comparison basis.
At the moment you can only drive the printer over an RS-232 line...
Imagen plans to produce an Ethernet interface "sometime this spring."
The IMPRINT-10 can be driven over a serial line, with various protocols
(packetized, error-correcting/detecting; serial xon/xoff or rts/cts;
simpler packet, error-detecting protocol (again, xon/xoff or rts/cts); etc),
a Centronics parallel interface, a DEC DR-11C or DR-11W interface,
an IBM 2780/3780 bisynch interface, or an Ethernet 10MB, TCP/IP interface.
The IMPRINT-10 can accept documents in a variety of forms, currently
Impress (a page-layout language with full graphics, including polygon
draw with various pen widths, polygon fill with arbitrary texture, graphics
plane magnification (useful with bitmap screen copies, etc.), and all four
virtual page orientations), Tektronix 4014 (tm), Diablo (tm),
line printer (1- and 2-up, landscape and portrait), and others.
The Symbolics machine appears to have slightly more font memory than the
Imprint-10.
Not true if you get the 1MB memory option for the IMPRINT-10; then
they're about equal.
6. There was a rumor that Symbolics and/or Imagen is looking around for
a higher resolution print engine, but I have not heard that directly.
All I can say is that IMAGEN is indeed building a compatible family
of printers with a range of resolutions and speeds.
The price info I have is: retail for the LGP-1 is $25K retail, and
slightly over $23K to universities. The Imprint-10 is $29K retail, and
$24,900 to universities with 50% down and 50% net 30 days.
The IMPRINT-10 now has a base price of $17,500, with software and hardware
options added from there; you can add memory, resident fonts,
communications interfaces, languages (e.g., Impress).
(The base price gets you a printing system with one simple
emulator, viz. line printer, Diablo, or screen dump.)
*start*
00608 00024 US
Date: 16 Feb 1983 05:05 PST
From: GWilliams at PARC-MAXC
Subject: Press version 4.6 is released
To: Kim, SEK@SU-AI, Dale.EOS, Hunt, ISL↑.pa, Orr, DBrown
cc: GNelson, Swinehart, Wilhelm, Ramshaw, GWilliams
Reply-To: GWilliams
Press 4.6 is available on [Maxc]<Press>:
Press.Run, Press.Syms, AND Press.Errors.
Press behaves rather interestingly when outputting a very large number of dots.
Rounding errors occur that can cause the appearance of a few undesirable scan
lines at the bottom of a print.
This happened while I was on vacation; Lyle found and fixed the problem.
Glen
*start*
00983 00024 US
Date: 11 Feb. 1983 10:41 am PST (Friday)
From: Ramshaw.PA
Subject: Press status
To: GWilliams
cc: Larson, Ramshaw
Glen, Eric and Gary S. came to me this week with a Press problem, which I
tracked down to an inadequacy in the technique used for magnifying or
reducing bitmaps. I coded up the best easy fix that I could think of, and then
tried to build a new Press; but the PressInternals.df that came off of Maxc
turned out to be out of date: it didn't have the "bandwidth" field added to
PageG. I broke into the two partitions on your Dolphin, (by installing a new OS,
sorry about that) hoping that I could find the right version of PressInternals.df
there, but with no luck. So I produced a bootleg version of press by just
removing the "PageG.bandwidth" code from Press.bcpl, and gave that to Eric to
try. I haven't heard back from him yet on whether this bootleg version
([Ivy]<Ramshaw>Press>Press.run; souces on same subdirectory) worked,
Lyle
*start*
00341 00024 US
Date: 14 Mar 1983 17:35 PST
From: GWilliams at PARC-MAXC
Subject: Press version 4.7 is released
To: Kim, SEK@SU-AI, Dale.EOS, Hunt, ISL↑.pa, Orr, DBrown, Paeth
cc: GNelson, Swinehart, Wilhelm, Ramshaw, GWilliams
Reply-To: GWilliams
I made some small changes to falicitate color processing for the VLSI folks.
Glen
*start*
00436 00024 US
Date: 15-Mar-83 17:18:13 PST
From: Wyatt.pa
Subject: IPDefs available on PreISL
To: Release Master <Wyatt.pa>
cc: ISLImplementors↑
Reply-To: Wyatt
IPDefs -- some basic Interpress definitions
------------------
DF file: [Indigo]<PreISL>Top>IPDefs.df
Implementor: Wyatt
IPXeroxEncoding incorporates changes for Interpress 2.0.
-------------------------------------------------------------------------------
*start*
00437 00024 US
Date: 15-Mar-83 18:07:05 PST
From: Wyatt.pa
Subject: PressReader available on PreISL
To: Release Master <Wyatt.pa>
cc: ISLImplementors↑
Reply-To: Wyatt
PressReader -- lists the contents of a press file in readable text form
------------------
DF file: [Indigo]<PreISL>Top>PressReader.df
Implementors: Wyatt, Shore
Recompiled.
-------------------------------------------------------------------------------*start*
00309 00024 US
Date: 28 March 1983 4:05 pm PST (Monday)
From: Sproull.PA
Subject: Press installation
To: GWilliams
Glen,
Is there a distribution list you use to annoucne new versions of Press? I'd like to
send around a message to try to find a few things out about all installations of
Press.
Bob
*start*
00193 00024 US
Date: 28 March 1983 4:08 pm PST (Monday)
From: Sproull.PA
Subject: <printingdocs>
To: ISL↑
Reply-To: Sproull
Does anyone know the password to [maxc]<printingdocs>
Bob
*start*
01219 00024 US
Date: 8 Mar 83 10:16:04 PST (Tuesday)
From: Ayers.PA
Subject: fyi
To: GandPInterest↑
----------------------------------------------------------------
Date: 7 Mar 83 19:56:25 PST (Monday)
From: Ayers.PA
Subject: FYI: Should I (we?) Have Been Surprised By This?
To: Elkind, Shoch, Wheeler.wbst, White
cc: Ayers
----------------------------------------------------------------
Date: 7 Mar 83 19:39:21 PST (Monday)
From: Ayers.PA
Subject: The (Interpress) Standard is Here (but it's not ours)
To: IPDesign↑
The current Byte magazine (actually February/March/April) carries an article describing the draft ANSI X3L2 standard
"North American Presentation-Level-Protocol Syntax"
It is Interpress8x, complete with device independence, ink&mask model, scaling, moveTo/lineTo, maskFill, color, text, arcs, composed operators ...
My first impression: They have done a pretty darn good job. Not as good as Interpress, but pretty good, much better than adequate, and we kept quiet about Interpress, so they will become the STANDARD and they deserve to.
Bob
----------------------------------------------------------------
----------------------------------------------------------------
*start*
02434 00024 US
Date: 3 March 1983 10:29 am PST (Thursday)
From: Ramshaw.PA
Subject: request for Press work
To: GWilliams
cc: Ramshaw
Glen, do you have any ideas about the following tale of woe? I vaguely recall
that the Press that drives Lenore has to be urged on past some K-state each time
that the Raven has idled down; do the documents come out OK after the
K-state?
Lyle
---------------------------
Date: 3 March 1983 10:50 am EST (Thursday)
From: Knox.wbst
Subject: Press.run K0
To: Ramshaw.pa
cc: Knox
Lyle,
I have a problem with Press.run to present to you. I hope that you, as official
Press maintainer, can help us with a new release, if necessary. I realize that
Press is old code and that it not easy to make new releases, but this problem
causes quite a lot of problems with our server operations.
Whenever Press runs into a problem (printer not ready, out of paper, etc.) it
displays the letters K0, K1, K2, etc. It then waits until the problem has been
corrected and tries again. When it does try again, it always prints out garbage.
We have never seen it recover successfully from a K# error. In addition, it
continues to spew out garbage pages until the Alto is rebooted.
The problem gets worse with our current printer server arrangement. We have
two Altos connected to the same 6500 printer. When one Alto is printing and the
other Alto tries to print at the same time, the second Alto K0's. After the first
Alto finishes printing, the second Alto sets the printer lines high and leaves
them on, causing the printer spew out garbage pages until someone manually
intervenes. These collisions are happening more and more frequently and are
causing many headaches.
It seems to me that there are several possible ways of fixing the problem.
1) Fix the error recovery mechanism so that Press recovers properly when there
is a collision. This is probably not an easy task.
2) Copy a command file (Press.cm?) into Rem.cm and boot. This clears the Slot
lines and lets Press try again. We would probably put the command "Press
Reprint; @Server.cm@" into our command file.
3) Not try to fix the error recovery mechanism, but at least clear the Slot lines
so that the printer doesn't continue to spew out garbage pages.
How about it? Is there any possibility that you could fix this problem for us?
Many thanks.
Keith
------------------------------------------------------------
*start*
00263 00024 US
Date: 4 March 1983 12:24 pm PST (Friday)
From: GWilliams.PA
Subject: Re: request for Press work
In-reply-to: Your message of 3 March 1983 10:29 am PST (Thursday)
To: Ramshaw
cc: GWilliams
I'll look into it, and send him a message.
Glen
*start*
00604 00024 US
Date: 4 March 1983 12:32 pm PST (Friday)
From: GWilliams.PA
Subject: Press K0
To: Knox.wbst
cc: GWilliams, Ramshaw
Are you running a 6500 from a SLOT card? We have similar problems with
older SLOT cards in that they don't return status to the Alto.
The Alto will hold print request high as a result of the SLOT not returning
status (i.e., the code tries to reset, but the microcode is unsuccessful). It then
thinks an error happened that had no relation to the printer (such as disk
errors). If you could tell me more about your exact configuration, it would help
me.
Glen
*start*
01265 00024 US
Date: 4 March 1983 7:02 pm EST (Friday)
From: Knox.wbst
Subject: Re: Press K0
In-reply-to: GWilliams.PA's message of 4 March 1983 12:32 pm PST (Friday)
To: GWilliams.PA
cc: Knox, Ramshaw.PA
Glen,
Yes, we are running the 6500 from a SLOT card. The 6500 is also equipped with
a HESSO laser scanner. Our SLOT cards have been around for a long time, so I
assume that they are some of the older ones. Are you saying that the newer
ones (perhaps ones that Gary has built) don't have this problem?
We used to run the 6500 from a single Alto, but we now have two Alto's (each
with their own SLOT card) and a Perkin-Elmer computer connected to the
printer. The Perkin-Elmer doesn't have any problem with collisions. It just
waits until the printer says that it is ready and then it prints. However, when
one of the Alto's tries to print when the printer is busy and doesn't become
ready before the Alto times out, the Press software K0's and cannot seem to
recover.
A printer being driven by only one Alto (as I assume that yours are) would not
really be bothered by this inability to recover, since it would happen very
infrequently. Unfortunately, in our system it happens more often and requires
manual intervention to correct.
Keith
*start*
01086 00024 US
Date: 7 April 1983 2:35 pm PST (Thursday)
From: Evans.EOS
Subject: Alto/Raven Print Server
To: AllDLOS↑.dlos, AllEOS↑.eos, AllES↑.es, AllHENR↑.henr, AllLB↑.lb,
AllPA↑.pa, AllRX↑.rx, AllWBST↑.wbst, AllXRCC↑.xrcc,ALLDC↑.dc,
AllSTHQ↑.STHQ
Reply-To: Evans
If you have no need for an Alto/Raven Press Print Server please disregard this
message.
EOS is going to begin a build of an interface board that attachs a Raven (used in
the 2700 and the 8044) printer to an Alto. The combination can then be used as a
Press Print Server or a Press Printer directly. The speed of the unit is slower
than the Penguin/Spruce server but the cost is very much less and no page is
too complex. A minor modification to the Raven allows the use of all of the fonts
currently used with a Penguin/Spruce server.
The board, developed at PARC, will go in either an Orbit or normal backplane
Alto. It may also be used as a 64K slot in other applications.
(Note that Press requires that the Alto have a Trident attached.)
If you would like more details please contact me.
Bill
*start*
01310 00024 US
Date: 9 Apr 1983 16:47 PST
From: GWilliams at PARC-MAXC
Subject: XCP code
To: Magnotti.wbst, adobe!putman%Shasta@SU-Score
cc: GWilliams
Vic,
I've finished the code and tested a good part of it. I tried to reach you by phone
yesterday and today, but missed you. I'll try to reach you before I leave for
Europe.
In any case, try it, play with it, and let me know if our communications broke
down anywhere. I'm sending source and the .com file. The file to run is
XCPTest.com. It doesn't type a "hello" message. It immediately tries to put the
machine through a power-up cycle.
After that, it types a message that says to type a "W" when the fuser is warm.
At that point, it loops waiting on Page request. Note that for that to work, the
Page request line should be routed through a flip-flop. That hardware isn't on
my board so I tricked it up by holding ground then +5 to P3B4.
On receipt of the page request, the code should print a page then go back and
look for page request again. The code is in there to do repeated pages without
shutting down.
If you want to recompile the code, compile XCPTest.c. It's a little tricky to do on
an Apple, and I wouldn't suggest it unless you can't resist.
By the way, 4-color Press works.
Hope to catch you before I leave.
Glen
*start*
10236 00024 US
Date: 11 April 1983 1:07 pm PST (Monday)
From: Evans.EOS
Subject: Alto/Raven Print Server
To:
Kelly.ES,rutkaus.lb,jcastro.es,BHardy.RX,Shookm.dlos,GYoung.PA,Hirst.RX,
Coleman.Wbst,hewitt.henr,dgustafson.XRCC,rlcampbell.ES,KAHRS.PA,VCornyn.es,
BELLI.WBST,Reilly.es
cc: Orr.PA,Evans,DonStewart,GWilliams.PA
The following paragraphs give the details on the Raven Interface and its
operation. In the past I have found that not everybody is aware of all the details
and differences of some of the systems we use. Therefore I included some
general information on printing to answer some of the questions you may have.
(Sorry that it made this so long.)
Alto Configuration:
The Alto may be either an Orbit or regular back plame machine. If it is
normally used to run Spruce the Orbit boards must be pull out (at least an inch)
for Press/Raven operation. Likewise the Raven board must be pulled loose for
Orbit operation. If the Alto has an Orbit backplane there cannot be a Trident
mux installed as there are not enough slots then for the interface.
Alto Disk Requirments:
The Alto must have one Model 31 and either a T300 or T80 Trident. We have
not been able to operate the unit with the Shugart that is used in some Spruce
configurations.
Press vs. Spruce Printing:
The Penguin runs as a Spruce printer. This means that it will spool input, i.e.,
it backs up printing jobs in a queue and the formation of the image is done in
real time during the printing of a page. This formation of the image is done by
a four board set, Orbit, which take the character bit maps from the Alto memory
and "ors" them in real time. Thus all bit maps of the characters must be in the
Alto memory before the printing of the page starts. Even then, for complex
pages, the unit gets behind which causes a breakup in the output. If not all of
the bit maps requried can be placed in the Alto memory you get a "Page Too
Complex" message. Before starting the printing of a page Spruce orders the press
file contents into a "Band List" so that it may read the directions for printing
during the time the image is transferred to the engine.
Press differs from Spruce in that: One, it does not Spool its input--it requires the
press file to present on the Model 31. Two, it does not form the the image in
real time, rather it makes up the image first on the Trident in a file call
Press.bits. Since this opertion is not time dependent there is no such thing as a
too complex page for a press printer. However, note that during the time that
Press.bits is being formed the Alto does nothing else--this is the reason there is
no spooling available, also that the formation of the image on disk is much
slower than the use of an Orbit.
The nonreal time operation of Press/Slot prints slows things down and one does
not get the 12 pages per min except during a reprint or during the time that the
paper is going through the engine. The times to print a document are closer to
those you get with Star than with Spruce.
Press Server:
To operate Press in a server mode we use a command file that runs EFTP till a
document is received as Temp.press. Then a short program called DeSpruce is urn
to remove the spruce headers from BravoX documents (if you do not use BravoX
this could be removed). The last command in the file is for the running of press
to print Temp.press. The server is thus not available to another user untill it
gets back into EFTP after the current printing.
If the doucment is Empress'ed the number of copies asked for will be printed.
however, if it is a BravoX document and printed from within BravoX, only one
copy will be printed.
The output does not have the cover sheets that Spruce puts on the front of a job.
Press Server Speed:
About the best we have ever seen for the running of Despruce and Press
production of one page is 40 seconds. The worst time for one page was a page of
music that took 20 minutes (it did not use any fonts only splines). In general
the time depends not only on the number of pages printed but their complexity.
If you would like me to print one of your press files and send you the times let
me know.
Press Software:
The unit uses the current version of Press with a very minor mod to the
microcode to reset the board. Everything is available on [Rosebowl]. A
document on the operation of press named "Pressops.press" may be available on
your local file server. If not, then try [Rosebowl]Altodocs>pressops.press.
Further questions on this form of Press should be sent to GWilliams at PARC.
Image Printing:
The Press/Raven can print AIS files if they are on the Trident. The only
difficulty we have had with this is that under some unknown conditions Press
cannot rotate some images and you must use AisRotate.
Raven Printer (876):
The Raven is the engine that is used in the 2700 and the 8044/8045 NS servers.
It is a 300 dot per inch, 12 page per min unit. From what I have seen, the 2700
form has the offset stacker and the 8000 form does not. At EOS we have only
used the 8000 form which has the product ID of 876. Note that the print times do
not include setup time of the server before it starts printing.
Raven Quality:
The Raven does not produce as good of quality as a Penguin in most cases.
Large black areas are usually very poor. I have seen this cause poor edges when
36 point fonts are used. Our experience has also been that the unit tend to vary
quite bit in just how well they do. Sopmetimes just stiring the toner can make a
lot of difference (had to call the repair person out to find that out). In general
we find that for the cost you cannot complain--8044 users don't.
Raven Availability:
We have obtained 6 of the Ravens from OPD (or who ever they are now). Once
they figured out how to do the paperwork for a stand alone printer it took about
3 weeks ARO. One Raven has come from WBST without going through the OPD
route and it took about the same amount of time. (Beware that the local OPD
people may not understand a non server printer and can hold up the paper
work--our first order took 4 months.)
Raven Costs:
The cost from OPD has been about $4478. It was less form WBST.
Raven Resolution and Fonts:
The standard Raven is a 300 dot per inch printer. Press will support this
resolution by setting the parameter when Press/i is done. However, EOS is using
the printer like a Penguin and wanted to use the fonts that we normally use
with our Penguin/Spruce server. To do this we change the crystal and reset the
bit clock switches in the Raven so that the bit clock and polygon run at the rate
of a 384 dot per inch printer (Penguin). (This increases the address ability of
the unit not its true resolution.) In this way a copy of the Spruce.fonts can be
used for Press.fonts and we get the full set of fonts. However, we have found
that the extended set of fonts used in Bravox, e.g., the Em space, does not print
using the Press software. The modifications to the Raven take about 15 min and
are reversable.
Raven Service:
Even with the modifications installed in the Raven our local branch of the 8044
maintainers will service the printer. They do require that you be able to print a
white page, a black page and some form of font output. We keep these press files
on our unit at all times. We have never had a failure that required the
changing of the boards that were modified--in which case the crystal would
need to be swaped or the switches changed on the the new one. Note that for
service Press can be set for 300 spots per inch and unmodified boards run.
Interface Board:
The board we use was designed at PARC and is refered to as the 64K Slot. It
operates in the same fashion as the older slot card. It has two line buffers which
are alternated during the printing. The bits fed to the buffers are those that will
be placed on the page, i.e., it does not modify the video. It is designed using
some ECL chips so that the max output ;rate is far above that need for a Raven.
Control of the Raven is by a microporcessor on the board that converts the single
lines of a slot card to the ASCII like communication of the Raven Five Wire
Interface. Provision also exists on the board to drive almost any type of slot type
of interface via the position of jumpers (both ECL and TTL type are supported).
More information on the use of the board for other than the Raven should be
addressed to Orr.PA.
Board Construction:
Up to now the construction has been StitchWeld. However the number of boards
has been growing so the board will be moved to PC which will be much better
for a large number of users. The current build will be by EOS, with PARC
managing the conversion to PC.
Board Availability:
The conversion to PC has just started so we expect to start loading and testing
the boards in 6 to 8 weeks. The problem with this is that we need to order
parts--to order parts I need to know how many we are going to build. Thus this
cycle of seting the number could add a few weeks to the time.
Baord Price:
The price will be acutal costs. For the Stitch Weld versions, with Raven cable,
this was about $1300 to $1400. The cost of going to PC will be divided among all
of the boards and may raise the costs. We feel that the advantages of PC are
enough to allow the price to be higher. (One SW board we placed has already
had the wires damaged and the repair takes quite a bit of time.)
A reasonable transfer agreement would state "not to exceed $2000 per board". We
will try to keep the cost as low as possible.
Board to Raven Cable:
We will supply any cable beyond that supplied with the Raven that may be
required.
Board Repair:
EOS is placing these boards outside of Xerox and will maintain the board for
sometime to come on an actual cost basis. However understand that we will do
this when "time is available" so there may not be a fast turnaround.
Board Spares:
If you need the unit to operate at all times it would be best to consider ordering
a spare. We do not intend to have keep a supply of boards at EOS.
Future Builds:
None are planned at the present time.
----------
I hope that I have covered most of the details. If not, send me your questions.
Bill
*start*
00585 00024 US
Date: 11 April 1983 4:51 pm PST (Monday)
From: Sproull.PA
Subject: Orbit, P machine documentation
To: isl↑,swinehart
Reply-To: Sproull
For those of you who absolutely cannot pass up an opportunity to sample the
latest lies and half-truths, there is a new version of the Orbit guide on
[maxc]<printingdocs>orbitguide.press, and a description of P-machine protocols
and the like on [maxc]<printingdocs>pmachine.press. (The latter has only
Pimlico and Puffin documentation in it; no one ever wrote Penguin
documentation, or if they did, I didn't find it.)
Bob
*start*
00612 00024 US
Date: 15 April 1983 4:36 pm PST (Friday)
From: Evans.EOS
Subject: Slot Board
To: Orr.PA
cc: GWilliams.PA,Starkweather.PA, Evans.EOS,DonStewart
I now have money on hand for 13 boards and should have one transfer
agreement for two more next week (in the mail today). This does not include
any for the 19 responses to the message to the world.
What is the status of the PC operation???????
It looks as if I will go ahead and order parts for these boards--I cannot wait
much longer. I am worried that I will need to SW several boards to cover what
is needed in the short term.
Bill
*start*
01196 00024 US
Received: from WASHINGTON.ARPA by PARC-MAXC.ARPA; 7 MAY 83 12:34:25 PDT
Received: from MIT-XX by WASHINGTON.ARPA with TCP; Sat 7 May 83 12:29:16-PDT
Date: 7 May 83 15:26 EDT
From: Chris Ryland <CPR@MIT-XX.ARPA>
Subject: Re: NCC
To: Furuta@WASHINGTON.ARPA, laser-lovers@WASHINGTON.ARPA
In-Reply-To: Your message of 7-May-83 1447-EDT
The IMPRINT-5 is a pre-product right now, so anything I might tell about it
is tentative. But, yes, all IMAGEN image processors are built around a
common core, so it speaks Impress, line printer, diablo, etc., the same
as the IMPRINT-10, and has the same hardware interfaces: serial of various
flavors, parallel, bisynch, and, soon, Ethernet. The print engine itself
is the LBP-10/480, and thus it's wet process (which is a good thing at
this high resolution, if you want near-phototypesetter quality, using
magazine stock paper), and a true 480 x 480 pixels per inch. Note
that using the obvious approach to building laser printers, viz., painting
into a bitmap and dumping it to the laser, doesn't work unless you're
willing to dedicate about 4 megabytes to the bitmap. Oh yes, it's 5
pages a minute, vs. 10 for the LBP-10.
-------
*start*
00497 00024 US
Date: 4 April 1983 11:46 am PST (Monday)
From: Sproull.PA
Subject: PD printing
To: ISL↑
Reply-To: Sproull
Quoth, Stinger, and Lilac now have servers running that will print either PD or
Press files. For documentation on PD file format, see
[maxc]<printingdocs>pdformat.press. For documentation on the PDPrint program,
see [maxc]<printingdocs>pdprintops.press. (Documents also stored on
[indigo]<pd>.) Please bang on this program, and report bugs and comments to me.
Bob
*start*
00710 00024 US
Date: 4 APR 83 13:12 PST
From: SPROULL.PA
Subject: PDserver
To: gwilliams
Ifixed theproblem andput the PD/Press serverback up.The real problem
iswith Press:if you say/O ona machine thatdoes not have anOrbit,
you get theresult you observed. In the previous version ofDecide, it
issued Press/Obecause that's what the command line for Lilac required,
but that screws up Stinger/Quoth. So thenew version copies anyswitches
to Decide into switches to Press/PD. So the server.cm on Stinger/Quoth
says "Decide tridenttemp.press", while the one on Lilia says
"Decide/O tridenttemp.press".
P.S. You might consider fixing the Press bugnext time there's
a good reason to diddle Press.
Bob
*start*
01143 00024 US
Date: 25 April 1983 10:39 am PDT (Monday)
From: Evans.EOS
Subject: Slot Code
To: GWilliams.PA
cc: Orr.PA, Evans
I hate to take you back in time but....
A Mr. Tsao at Diablo wants two of the slot boards to run a thermal printer.
However, this print requires an "online command" before printing and an
"offline command" at the end of the printing. He states that otherwise the
thermal unit is the same as a Raven.
I have gone through the code in fivewireslot.bca and see no problem in suppling
the online command. The end of the operation is not so clear. Am I right in
concluding that the turn off of PageSync to the slot occurs at the end of the time
out at NothingWaiting: in the code?? It is true that the Alto mc will not set
the reset of the slot board (and the 6801) till this change in PageSync has
occured??? (I have not looked into the operation of the Slot mc in the Alto so
when things occur is only a guess.) Would there be any problem in delaying
the turnoff of PageSync until the offline command has been issued??
Do you run the Gnat with this slot board--with or without modification??
Bill
*start*
00937 00024 US
Date: 5 May 1983 2:23 pm PDT (Thursday)
From: Evans.EOS
Subject: Press/Interpress
To: GWilliams.pa
cc: Hains, Evans
Glen,
If you have talked to me on the phone about press disregard this message.
We are trying to find out if any work has been done on automatic press to
interpress conversion. Do you know of any work or know someone that we
could contact who might have some information on this subject??
I sent a message with a question on the code for the slot board while you were
in Europe--modify it as I have found that the thermal printer does not need to
be but in the offline state at the end of the page. I still would like to know how
press treats the page sync relative to the turning off of the slot board. In the
code you at one time had used the page delivered status to reset page page sync,
do you remember why you changed from this to the timer approach to turning it
off??
Thanks
Bill
*start*
07485 00024 USm
Date: 6 May 83 19:48:03 PDT (Friday)
From: Mallgren.PA
Subject: IGC Conference trip report
To: SDD-AD↑, GandPInterest↑
Reply-To: Mallgren.PA
Last week I attended a conference on "Interactive Integration of Text, Graphics, and Pictures" in Andover Massachusetts. It was a conference about automated systems for doing page make-up. These are known in the publishing industry as pagination systems.
The 50 or so attendees were a mixture of people directly involved in printing and publishing and representatives of small companies that make pagination equipment. The end-users were there to learn about available systems. The vendors were there to disseminate information about their products and find out what the competition is doing. Most of the presentations were by vendors, although a couple were by users describing their experiences with particular equipment.
I learned a lot about the publishing industry and what kinds of needs these people have. By and large, they are a very conservative group. Their two overriding concerns are quality and cost effectiveness. Any equipment they buy must meet their needs exactly; they are not willing to sacrifice the quality of their own product just to make their job easier.
There seem to be three broad markets for pagination equipment:
1) newspapers
This area is very specialized and is heavily layout oriented. Typical systems show the layout of a page on the screen, allowing the user to define rectangular areas and assign text blocks, ads, or photographs to them. Each page is laid out by hand; the system handles the formatting of text into the defined areas, including continuation across pages. Few fonts are required and (obviously) "newspaper quality" is good enough.
2) graphic arts, ad make-up
Here everything is done on a single page basis and the emphasis is on high quality output with elaborate page layouts, heavy use of graphics, and extremely diverse font requirements. This area is currently the least automated of the three.
3) books, manuals, reports, etc. (includes "tech. pubs.")
The third major area includes multiple-page documents containing primarily text with embedded pictures. Layout requirements are likely to be expressible as a set of standards that can be applied to an entire document. Two subareas are defined by the quality required of the final result. Commercial publishers generally require higher quality than in-plant operations.
Automatic pagination systems currently on the market fall into 4 categories:
1) algorithmic/batch pagination
These are the "document compilers". Formatting commands are embedded into the text as it is entered. The result cannot be seen until it comes out of the typesetter or proof printer. Systems of this kind are applicable to books, manuals, and a lot of in-plant publishing.
2) layout driven
Newspaper systems (described above)
3) interactive
The opposite of batch pagination. Each page is laid out manually (on a CRT) in the form it will appear when printed.
4) interventional
This is a batch pagination system with a screen for previewing the result. It is possible to see the output before committing it to hard copy. but it is still necessary to rerun the job to make changes.
Currently, no system does a complete job of integrating text, line art, and continuous tone images and getting to a phototypesetter in one step. Most commonly, only the text appears in the output with holes reserved for illustrations. The illustrations themselves are inserted manually. There were two systems I saw, however, that I thought were especially interesting. One provides Doodle-like editing facilities for scanned line art and continuous tone images; the other embodies many of the advanced document formatting and layout facilities we have in mind for Star.
Imagitex image processing system.
Hardware:
Desktop digitizer
input format: 8 1/2 x 11" or 5 x 11"
resolution: 475 dpi or 775 dpi
grey levels: 256
speed: 1 to 1 1/2 min per page
Disk storage
2 158 megabyte drives
A single image requires between 2 megabytes (line art)
and 20 megabytes (continuous tone).
Workstation
dual 68000 processors
11 x 11" tablet
19" color display
640 x 512 x 10 bits
Price: $115,000
The system supports cropping, sizing, rotation, moving/copying, and airbrushing, as well as operations on the grey level mapping, including contrast/brightness control, posterization (contouring), thresholding, and spot color. (A separate bit map is produced for each color.) There are three different display resolutions, so that it is possible to see up to 16 images on the screen at a time or to work at the bit level in a portion of a single image. All editing operations are available at any resolution.
Disadvantages are that there is no support for text, and there is currently no hardcopy output device.
Xyvision composition and pagination system
Hardware (full-blown version):
system control unit
68000 processor
768K byte RAM
1-4 70 megabyte Winchester disks
2 graphics workstations
68000 processor with 768K byte RAM
16-bit display list processor with 1 megabyte RAM
11.5 x 11.5" B&W bitmap display (89 dpi vertically, 178 dpi horizontally)
4 text-only editing terminals
dot matrix printer
Canon laser printer
Price: $150,000
Supports both batch and interactive pagination. Handles headings, footnotes, sidenotes, hyphenation, widow/orphan control, floating illustrations, cross references, and table of contents generation. Also it has a spelling checker and at least a simple version of styles. There are two modes of display, one showing embedded formatting commands, and a "presentation mode" that shows the page as it will appear when printed. It can display a single page, 2 or 4 pages simultaneously, or one page plus the 2 pages on either side at reduced scale. Documents can be recomposed (paginated) all at once (claim: 3 seconds/page) or in smaller segments (e.g. paragraph, section). In presentation mode, formatting changes can be made to a page directly, but these changes are lost if the page is recomposed.
Disadvantages: not yet being shipped, no graphics facilities (graphics at least a year away).
Xerox was mentioned a lot at the conference, primarily in the context of laser printers and Ethernet.
Many of the vendors talked about networking, but no one seems to be doing it yet.
Laser printers are considered useful for final output in in-plant printing and as "proof printers" otherwise.
Star and Lisa were usually mentioned in the same breath, and, currently, they are not taken seriously for this market. I heard two somewhat contradictory remarks: that "the Xerox strategy of expecting office workers to do formatting and layout is probably wrong", and that "combining the document creation and formatting functions may be the way a good deal of publishing is done in the future".
From what I saw of these people's needs, I don't think what we have now will sell to anyone in this market. Our document formatting facilities are just too incomplete, and it is impractical to generate all illustrations with structured graphics. However, I think we could have a strong entry in the in-plant publishing market by just getting scanned images and complete document formatting facilities into Star. Adding a good phototypesetter would broaden our market even further.
-- Bill
*start*
00534 00024 US
Date: 10 May 1983 4:24 pm PDT (Tuesday)
From: GWilliams.PA
Subject: Re: Press/Interpress
In-reply-to: Evans.EOS's message of 5 May 1983 2:23 pm PDT (Thursday)
To: Evans.EOS
cc: GWilliams, Hains.EOS
Bill,
When you speak of turning off page sync, do you mean the 6800? If so, when
you speak of turning off page sync based on a timer approach, I'm confused. I
don't remember having used a timer in the 6800 to turn off page sync. However,
there is a timer that Press watches. Is that what you mean?
Glen
*start*
01406 00024 US
Date: 11 May 1983 9:01 am PDT (Wednesday)
From: Evans.EOS
Subject: Re: Press/Interpress
In-reply-to: GWilliams.PA's message of 10 May 1983 4:24 pm PDT (Tuesday)
To: GWilliams.PA
cc: Evans, Hains
I maybe asking you questions that were in Dan's area as they have to do with
the code for the 6801. The code is on your directory so I had assumed that you
wrote it (of course too much time may have passed). Let me know if this is not
the case.
Page sync is set in the slot interface by the 6801 when that status character is
received from the Raven. To turn it off at a later time you had two sections of
code for the 6800.
First, when the status character "pagedelivered" arrived you removed the page
sync signal out of the board to the Alto. This code is commented out and not
used. I would like to know why--if you remember.
Second is the way it is done now in the proms. When page sync is set, a count
is set for the number of times the 6801's timer will compare. This just lengthens
the timer total time. When the total time expires the pagesync signal to the Alto
is reset.
My main question in all of this why did you move from the status in clearing
the pagesync signal. The thermal printer and spitfires run at different rates
than the raven but I want the same prom to run all three and must try to use
the status but if you had problems then????
Thanks
Bill
*start*
01354 00024 US
Date: 11 May 1983 2:47 pm PDT (Wednesday)
From: GWilliams.PA
Subject: Re: Press/Interpress
In-reply-to: Evans.EOS's message of 11 May 1983 9:01 am PDT (Wednesday)
To: Evans.EOS
cc: GWilliams, Hains.EOS, Paxton
Bill,
Yes I did write the code and yes it was a long time ago. I'd forgotten the
complications that had to be worked around.
In a nut shell, I had to use a time out in order to make the Raven work correctly
with Press. It turns out that "pagedelivered" comes from the Raven too late to
continue printing if it is a multi page document, as the Raven would shut down.
There is another signal, I believe it is readyToFeed or some such, that the Raven
hands back during the printing of the first page that means it can take another
feed command. You can't use that for timing info as you're in the middle of
flinging bits.
You might ask why one can't remember we got a readyToFeed and send that
down to the Raven during the current print, but you might be on a one-page
run or the end of a multi-page run. The main problem there being one of
needing more communication from Press. I chose not to restructure the workings
of Press if I could avoid it.
If you're designing an ESS, you might want to work in a scheme that allows you
to "prenotify" the Raven (or thermal printer or spitfire) as mentioned here.
Glen
*start*
00470 00024 US
Date: 12 May 1983 8:47 am PDT (Thursday)
From: Evans.EOS
Subject: Re: Press/Interpress
In-reply-to: GWilliams.PA's message of 11 May 1983 2:47 pm PDT (Wednesday)
To: GWilliams.PA
cc: Evans
Thanks for the info--hated to take you back that far. I am now trying to make a
few simple mods for the thermal printer. (The first attempt didn't work.)
Your experience says that there must be a prom for each printer--a fact well
worth knowing.
Bill