Laser-Lovers-Request@WASHINGTON.ARPA (Moderator) (02/24/86)
Info-Postscript for Laser Lovers Digest Sunday, February 23, 1986 1:10PM
Volume 1, Issue 9
Today's Topics:
MacWrite Generating Bogus PostScript?
postscript V25
LaserWriter(s) PostScript Language Update to follow
Language changes
LaserWriter Plus information
Hardware support for PostScript
%%BoundingBox
----------------------------------------------------------------------
Date: Sat 8 Feb 86 15:56:21-PST
From: Jim Lewinson <a.Jiml@SU-GSB-WHY.ARPA>
Subject: MacWrite Generating Bogus PostScript?
Someone at our site has a MacWrite document that will not print on the
LaserWriter. If one inserts a page eject prior to the diagram subtitle,
it will print, however, doing things like changing the font will not help
the situation. I played with the postscript and found that if I inserted a
"showpage" right before a certain line I would get some output, but if I put
it after I never saw a thing. Of course, this may not mean much, since I
don't know PostScript.
The files aren't large, but I'm not going to include them since most people
won't want to see them. I have put them on SU-Score.ARPA for people
to grab if they want to look at them. The MacWrite document is in
[SU-SCORE.ARPA] PS:<JIML>UNPRINTABLEFILE.HQX (In BinHex 4.0 format),
and the PostScript is in <JIML>UNPRINTABLEPOSTSCRIPT.TXT. (Text format)
If someone wants me to mail them the files, let me know.
Does anyone see what we are doing wrong, or is it just a bug?
Thanks,
Jim Lewinson
ARPA: Jiml@SU-SCORE.ARPA
------------------------------
Date: Tue, 18 Feb 86 16:05:42 est
From: Eric Gisin <egisin%waterloo.csnet@CSNET-RELAY.ARPA>
Subject: postscript V25
Are there more extensions to PostScript on the LaserWriter+?
For example, is there any control over the serial line protocol?
It's difficult to emulate any real printers when CR is mapped to LF.
Is there a V25 ROM upgrage for the original LaserWriter?
------------------------------
Date: Wed 19 Feb 86 08:27:42-PST
From: John Reuling <Reuling@SU-SCORE.ARPA>
Subject: LaserWriter(s) PostScript Language Update to follow
The next two messages contain PostScript print files for the new
Apple LaserWriter and LaserWriter Plus PostScript Language Update
documentation.
These messages will be kept on ARPANET site SCORE.STANFORD.EDU in
the directory <INFO-POSTSCRIPT> as files LASERWRITER-1 and
LASERWRITER-2.
Users on the Internet may retrieve these files via anonymous FTP.
(Please don't FTP files from Score between 9am and 5pm weekdays.)
-John
-------
[[Laser lovers moderator's note: Because of their large size, I am
unable to include the source of these messages in the info-postscript
digest. I will send these messages to the Usenet feed for inclusion
in mod.computers.laser-printers. I suggest that those of you with
Internet access obtain the files from the Score directory if you're
interested. If you do not have access to the Internet or to the
Usenet, send me a note and I'll mail you the files. Please don't
request a mailed copy unless you really don't have another way to get
the material---this for reasons of fairness to the intermediate sites
that will have to pass along the material to you. Send requests to
laser-lovers-request@washington. --Rick ]]
------------------------------
From: adobe!taft@decwrl.DEC.COM (Ed Taft)
Date: 18 Feb 1986 1744-PST (Tuesday)
Subject: Language changes
Several additions have been made to the standard PostScript language.
These additions are upward-compatible and do not affect the function of
any existing PostScript programs. The language is now at version number
38.0; this version is present not only in the LaserWriter Plus but in
PostScript printers now being shipped by QMS, DataProducts, and
Linotype.
The new language facilities are of a "system programming" nature:
they do not offer any new page description capabilities. In general,
PostScript programs that are intended to be compatible with all
PostScript printers should not make use of the new features. However,
it is possible for a program to determine whether or not the new
features are present and to invoke them conditionally.
The new facilities are summarized below. Complete information is
contained in the LaserWriter Plus supplement mentioned in message 1,
as well as in corresponding supplements for each of the other PostScript
printers.
(1) Packed arrays. These are an alternative data type for representing
PostScript procedures, providing a significant (50 to 75 percent)
reduction in the amount of VM required to store them. Page
descriptions with large preambles can benefit significantly from using
the packed array facility.
(2) Immediately evaluated names. These essentially are a means of
obtaining the effect of the "bind" operator selectively. They are used
heavily by built-in PostScript programs, but are of lesser interest to
user-defined programs.
(3) Compressed characters. The font cache is now able to retain much
larger character bitmaps than before and often to consume less space while
doing so. This isn't so much a language change as an implementation
improvement; however, there do exist some new cache control parameters
and some operators for manipulating them.
------------------------------
From: adobe!taft@decwrl.DEC.COM (Ed Taft)
Date: 18 Feb 1986 1741-PST (Tuesday)
Subject: LaserWriter Plus information
This and the next two messages are in response to several questions
and comments about the LaserWriter Plus, recent PostScript language
changes, and hardware support for PostScript.
1. LaserWriter Plus
The LaserWriter Plus is strictly a software upgrade to the LaserWriter.
The only hardware change consists of replacing the ROMs with new
devices having twice the capacity as the old. Existing LaserWriters can be
upgraded to the new ROMs; see your Apple dealer.
The new ROM software is substantially different from the old in four
main areas:
(1) New fonts. In addition to the original Times, Helvetica, Courier,
and Symbol families, the following font families are built-in: Avant
Garde, Bookman, New Century Schoolbook, Palatino, Zapf Chancery, and
Zapf Dingbats. This expands the original 13 typefaces to 35. The increase in
ROM space from .5 to 1.0 megabyte is entirely consumed by new fonts.
(2) PostScript language extensions. These are discussed in the next
message.
(3) LaserWriter-specific functional changes. These include expanded
serial communication capabilities (higher baud rates, optional DTR flow
control), support for European paper sizes (A4 and B5), and a few
others.
(4) Implementation improvements. Nearly all the problems in the
original LaserWriter software have been fixed. Additionally, for many
types of documents, page throughput is significantly improved. The
primary source of improvement is a new printing strategy that enables
imaging of a page to be overlapped with execution of the PostScript
description for the next page; formerly these were done serially.
Technical documentation for the LaserWriter Plus exists in the form of
a supplement to the original LaserWriter documentation (Appendix D of
the PostScript Language Reference Manual). This documentation is being sent
to Info-PostScript as a couple of Scribe-produced PostScript files; it will
also be copied to the Laser-Lovers archives and perhaps to other places
(watch your usenet newsgroups). It will eventually be incorporated into
Apple's "Inside LaserWriter" package, but I do not know when that will
happen.
Ed Taft
Adobe Systems, Inc.
Notices:
PostScript is a trademark of Adobe Systems Incorporated.
Helvetica, Palatino, and Times are trademarks of Allied Corporation.
Avant Garde, Bookman, Zapf Chancery, and Zapf Dingbats are trademarks
of International Typeface Corporation.
Scribe is a trademark of Unilogic Ltd.
------------------------------
From: adobe!taft@decwrl.DEC.COM (Ed Taft)
Date: 18 Feb 1986 1750-PST (Tuesday)
Subject: Hardware support for PostScript
Several people have suggested hardware enhancements (e.g., faster CPUs,
RasterOp chips, etc.) to improve the performance of PostScript
printers. Naturally, this is a topic of great interest to us at Adobe.
I'd like to share a few of our current thoughts with you. Please note
that I am talking only about current products; I am not speculating
about future ones.
Adobe's approach to PostScript has been first to define a fully general
software model for the programming language and page description
capabilities and only then to consider how hardware can be employed to
accelerate the software. Experience with a pure software implementation
of PostScript (of which the LaserWriter is a good example) gives us an
understanding of what parts of the implementation would benefit most
from hardware support.
There are three major activities that together account for most of the
execution time in Adobe's implementation of PostScript. These are:
(1) Low-level raster manipulations, principally painting character
bitmaps and filling trapezoids located at arbitrary bit boundaries.
For typical pages, this activity dominates everything else if all
characters are already in the font cache.
(2) Character scan conversion. This is a very compute intensive
operation because the original character definitions are at a high
level and are being pushed through the full PostScript graphics
machinery. In particular, there is a lot of arithmetic, both fixed and
floating point.
(3) PostScript input scanning and interpretation. This includes
parsing the input stream, constructing tokens, looking up names,
pushing and popping stacks, etc. The amount of time consumed by this
activity varies considerably according to the type of page description
and the programming style. A text document that consists primarily of
strings and calls to simple PostScript procedures consumes relatively
little time in the interpreter; a document that executes a lot of
PostScript code for each mark placed on the page consumes
proportionately more.
Of course, I have deliberately left out time spent waiting for input data or
waiting for the print engine. The effect of a slow communication channel or
a slow print engine can completely dominate everything else. More to the
point, obtaining the best performance requires the ability to perform
communication, execution, and printing activities in parallel.
The above three activities benefit from significantly different kinds of
hardware support. (Of course, in a strictly software implementation, a
faster CPU should speed all three activities.) Considering them in order:
(1) Simple hardware for shifting and masking makes a substantial
difference here; the full generality of RasterOp is not needed. The idea is
to minimize the number of CPU instructions and memory cycles needed to
perform simple, repetitive bit moving operations. A shifter-masker is
included in the Adobe Redstone controller, versions of which are used in all
present PostScript printers except the LaserWriter. This activity is one
that would benefit greatly from having a separate, parallel processor; its
interface with the rest of PostScript would be quite simple.
(2) Efficient arithmetic is of particular importance here. Also, since a
vast amount of code is being executed and all of it is written in a
high-level language (C in the case of Adobe's implementation), the overall
quality of compiled code is important. Apart from arithmetic, no single
component dominates, so it's not practical to assembly-code much of it.
(3) Here is a place where some special hardware and/or microcode might
help. The PostScript interpreter's data structures and algorithms are
sufficiently straightforward that custom hardware may be practical. Whether
or not this makes sense economically depends on how much time is spent in
the interpreter relative to everything else, which, as I said, is highly
application dependent.
------------------------------
Date: Thu, 20 Feb 86 14:19:54 est
From: ned%UPenn-Grasp%upenn.csnet@CSNET-RELAY.ARPA
Subject: %%BoundingBox
One of the most important comment conventions defined for PostScript is the
BoundingBox comment: it lets other programs know exactly where the marks on
the page will fall when the PostScript code is run. It is extremely valuable
information, as there is no other way to determine it, other than actually
running the PostScript. If we are to write any great PostScript tools which
know how to include one PostScript program in another, we have to make sure
that this comment is created whenever feasible. Here at Penn, we are working
on a preprocessor for ditroff which will include a PostScript file as an
illustration. The preprocessor knows how to read the BoundingBox comment to
get the size of the figure, but unfortunately, not everything generates this
comment as it should. In particular, MacDraw seems not to, and that is a
tremendous shame, because whenever I've discussed this preprocessor with
other people, they've always responded with, "You mean I'll be able to draw
diagrams with MacDraw, and put them in troff automatically?!?!", and I've
got to say, "Well, you can, but it won't really be as easy as it should,
because for some reason Apple decided not to do things properly." Apple, if
you're reading this: DO THIS NOW. I imagine it would be very easy for
MacDraw to generate this information, it knows the extent of the drawing.
Many users will not want to try to hack around with the measuring to get it
to fit precisely. For any other developers out there, Please, please, please
put in this comment. Don't assume that you know everything people will want
to do with your programs. Everyone in the business of using PostScript will
be happier if we all try to follow these guidelines.
Ned Batchelder University of Pennsylvania
(ned@UPenn.CSnet) CIS Dept, 200 South 33rd Street
(215) 898-5617 Philadelphia, PA, 19104-6389
------------------------------
End of Info-Postscript for Laser Lovers Digest
**********************************************