woody@rpp386.cactus.org (Woodrow Baker) (03/02/90)
O.k., I have a preliminary draft of an automatic posting. It is rather long.
I am posting it here for discussion. Has anything been left out? Is anything
not needed? etc. I am NOT interested in flames. I am trying to create
sometthing useful, and am seeking some constructive ideas. Comments
should be emailed if possible. Please keep them constructive, not
destructive. Thanks.
Automatic posting
This posting is brought to you by
Woody Baker
Rt.1 Box I
Manor, Tx. 78653
woody@rpp386
This posting was developed to answer routine questions. If your question
falls under one of the listed questions below, you likely will find the
answer here. Please read the post before posting the question. This has
2 benefits. The first is that your question gets answered faster. The
second one is that it reduces traffic on the group.
NOTE: THIS IS A LONG FILE! There are a lot of questions and information.
if you don't want to read it, you should exit now.
What are the colored books, and where can I get them?
How can I speed up printing?
How can I compress data so it transmits faster?
What coding styles are in general use and which shall I use?
What are dictionaries and how do they work?
How can I access the file server?
Where and how can I access PD fonts?
How can I convert PostScript to bitmaps?
How can I get bit maps back from the printer?
Why doesn't the hi bit get through?
What is EPS and where can I get information on it?
What are the colored books?
These books are the baseline information on PostScript. They should be on
ALL PostScript programmers bookshelf or desktop. They are nick-named for
their jacket colors.
RED BOOK PostScript Language Reference Manual
Adobe. Publisher: Addison-Wesley
ISBN 0-201-10174-2
LC# QA76.73.P67P67
BLUE BOOK PostScript Tutorial and Cookbook
Adobe. Publisher: Addison-Wesley
ISBN 0-201-10179-3
LC# QA76.73.P67P68
GREEN BOOK PostScript Language Program Design
Adobe. Publisher: Addison-Wesley
ISBN 0-201-14396-8
LC# QA?????
ORANGE BOOK Real World PostScript
Stephen F. Roth editor Publisher: Addison-Wesley
ISBN 0-201-06663-7
LC# Z286.D47R4 1988
Printer Supplement. Usually shipped with each printer. Covers special
features, and setup operators for the various printers.
For the beginning PostScript programmer, read the GREEN book first with the
RED book handy as reference. I personally don't like the coding style used
in the GREEN book, but the important thing is to make your code clear,
readable and maintainable. Next read the BLUE book, again with the RED
book as a reference. The ORANGE book is a diverse collection of articles
dealing with the real world, and specific applications.
The BLUE book has a problem with many of the examples, such as circletext.
The font used to set the programs is Helvetica. It is easy to mistake
( ) for () That is, it looks like () but should be ( ).
What style should I use?
First off:
DON'T use Don Lancasters' style. He compresses his code so he can get more
stuff in his column in the Computer Shopper. It's a MESS!
This one has been hashed over completely. Opinions voiced on this topic
generally ignite a raging fire-fight. There are 3 basic coding styles, and
the general consensus is that you should be clear, consistent and easy to
read and maintain. Most of these styles are also shared with 'C', as the
PostScript language shows it's 'C' heritage.
Style 1. Probably the most general style. Similar to styles used
in most other languages. Familiar to the widest group of
people in general. In my opinion easiest to maintain and
read.
/procedurename
{
body
} def
variable 0 eq
{
condition body
}
{
condition body
} ifelse
Group like operations together. For example,
currentpoint 5 add exch 25 sub exch moveto (hello) show
gets treated as
currentpoint 5 add exch
25 sub exch
moveto (hello) show
Style 2. IMHO, harder to read and maintain, but space efficient.
The style primarily used in the GREEN book. Close to the
Indian Hill 'C' standard.
/procedurename { %def
body
} def
variable 0 eq { %ifelse
condition body
}{
condition body
} ifelse
Style 3. More cryptic, but more space efficient.
/procedurename {
body }def
variable 0 eq {
conditionbody }{
conditionbody
}ifelse
Pick a style and be consistent. Style 1 is probably the easiest and most
widely understood style.
How can I speed printing up?
There are actually 2 issues here.
1. Throughput of the comm channel
2. The way the code is written
1a. Serial
Versions 38.0 and greater, allow the baudrate to be set up. The code
fragments below illustrate this. The baud rate can be set as high as
57K baud. There are people successfully using 19200, and 38400. These
seem to be rather common. Don Lancaster uses 57,600 baud for ONE WAY
printing. He can shed further light on it. Call him at 602-428-4073.
Remember that position 1 is ALWAYS 1200 baud PostScript, so that you can
recover if you screw up. You MUST get your handshaking right for baudrates
like these. The PC class machines don't understand XON/XOFF without some
kind of spooler or driver. I like Superspl from AST. It works.
1b. Parallel
Use it if you have it. It is generally much faster. The return channel
will be the 9 pin serial port. It must be setup to the correct baudrate
if you are going to use it.
example code. Refer to your printer supplement for what works on your
printer.
%
% set handshaking to dtr
%
statusdict begin
25 sccbatch exch pop 4 eq
{
stop % if already set, then leave it
} if
serverdict begin 0 exitserver
statusdict begin 25 19200 4 setsccbatch
%
% set handshaking to XON/XOFF
%
statusdict begin
25 sccbatch exch pop 0 eq
{
stop
} if
serverdict begin 0 exitserver
statusdict begin 25 19200 0 setsccbatch
%
% tell us which
%
/Times-Roman findfont 20 scalefont setfont
100 300 moveto
(Serial flow control is now )show
statusdict begin
25 sccbatch exch pop 4 lt
{
(xon/xoff)
}
{
(dst/dtr)
}ifelse
show
showpage
2. Coding
Optimizing coding, speeds PostScript up in 2 ways. Reducing execution
time and reducing transmission time. Generally for simple stuff, transmission
time is the bottleneck. The basic transmission reduction optimization,
involves shortening the PostScript commands to 1 or 2 letter commands.
The most common definitions
/l lineto def /ff findfont def /GS gsave def
/m moveto def /sf setfont def /GR grestore def
/c curveto def /SP showpage def /f fill def
/s scale def /rm rmoveto def /SG setgray def
/SH show def /rl rlineto def /MF makefont def
/st stroke def /rc rcurveto def
It also helps to reduce the font names. The scheme most generally used
is to create an abbreviation of the font name, and tack on one of the
following "suffixes" B --Bold BO --BoldOblique BI --BoldItalic
O --Oblique I --Italic and <space> for normal.
/H Helvetica def
/HB Helvetica-Bold def
/HBO Helvetica-BoldOblique
/HO Helvetica-Oblique
Speeding execution up.
The most commonly overlooked technique is to use bind def, rather than just
def for procedure names. The reason for the speed up, is that the
interpreter replaces the name in the internals with a pointer to the routine
and thus does not have to scan tables or dictionaries looking for a
name. The second way to speed things up is related. Leave as much stuff
on the stack as possible, rather than using variables. The downside of this
is that it makes the code EXTREMELY difficult to follow and debug. This has
also been hashed over. It is easier to maintain code that has everything
held in variables, but you pay a time penalty for doing so. Leaving
intermediate values on the stack tends to obfuscate the code, but does
increase speed of execution.
Data compression has been discussed at length. It may or may not buy you
anything, depending on the type of data and speed of printer. It can be
slower than uncompressed data in total throughput. There have been several
compression routines posted.
Putting repetitive blocks into a font, and using the cache can dramatically
speed things up.
How can I convert PostScript code to bitmaps?
Basically, you have several choice at the moment. All of them except 2 do
NOT involve Adobe. One of the commercial computer resident PostScript
interpreters can do it for you. Ultrascript, Goscript and Freedom of the
Press will do it. Sun workstations do it. NEWS does it. Display Postscript
does it also. The second Adobe involvement is a downloaded routine that
dumps the bit map back up the serial link. All attempts to get them to
turn loose of it have failed. Lasertalk contains it. It might be
extractable from the code. Since Display Postscript allows the capture
of bit map screens, it seems inconsistent to not provide the routine
for the printer, but that is currently the way it is. I personally would
love to get my fingers on the routine from Lasertalk.
Further topics are going to depend on the following info, so:
How to access the file server.
mail ps-file-server@adobe.COM
send help ....will get you a copy of the instructions
send Index ....Will get you a copy of the index
send Index Documents ...Will get you a copy of the Documents index
send Documents "name" ...Will get you "name" document.
Please read the help file first.
Where can I get public domain fonts?
mail font-server@mims-iris.waterloo.edu
send help ....same as above
send Index ....same as above
NOTE: There are some restrictions, so read the help file, and then
send for README.1st.......
Where can I get info about the color operators and language extensions?
from the Adobe file server.
What is encapsulated postscript and where can I get information on it?
The Adobe file server has a complete set of specs' on EPS. It will
happily send it to you on request. Unfortunately, EPS is not quite as
standard as it should be. Applications can claim EPS computability and
NOT be able to use EPS files from other apps. This is generally the fault
of the apps. All it takes is a subset of EPS to be "compliant". IMHO it
has not been totally developed and thought out. I guess it is better than
nothing however. Certain applications depend on this-n-that piece of
information to be present in an EPS file. If it isn't, it can't use the
EPS file. The MAC seems to be the worst offender. You can capture a
file going to the printer from the MAC keyboard, but then you need to
edit it to even get it to print. Using the COMMAND K technique to
capture a file, you have to change a bunch of stuff. There is a program
floating around called MacPS that does this cleanup for you. There are
lines dealing with setdefaulttimeouts and sccinteractive that must be
commented out. There are also 2 flushfile's that cause problems. The
best thing to do is to get MacPS
Dictionaries:
These seem to be a hard concept for many people to grasp. My own personal
model is a file. I tend to think of dictionaries as an overlay file that
carries it's variables with it. I can open and load it (begin), close
and quit (end). The contents DON'T go away. The dictionary and variables
stay around in VM and can be opened or put on the dictionary stack and
used at any time.
How can I turn HP emulation on.
This is somewhat printer dependent. Dumping the internal dictionaries
in interactive mode and examining the contents is the way to find out how.
In general, there is an array of procedures that handles the switch on
the printer. There is 1 routine per switch setting. The newer printers
have exechplj exchpgl and diabloexec defined in general. These handle
everything needed to start the emulator. HOWEVER: doing so from PostScript
will leave PostScript in charge of the serial port. You will then have to
enable cr/lf for the printer, as PostScript unfortunately converts CR/LF
pairs into simple lf's. For the HP, you must send ESC &k3G . Control
D will exit you. In some implementations, you can exit from the switch
selected mode, or so I've been told, with ESC 7f 04. On some printers
there is also a sethardwareiomode and setsoftwareiomode that deal with
this problem.
The serial port under PostScript is a non-transparent 7 bit rather than
standard 8 bit port. This basically keeps graphics stuff out. This has
been hashed around also. Short of a machine language patch, there will
be no way to get 8 bits down the serial link to PostScript. In addition
you can't get certain control codes through. Parallel is not quite so
hamstrung.
What tools are available for debugging PostScript?
Depending on your system:
erhandler.ps from Adobe file server is a downloaded page-printing
errorhandler. I could not get along without it.
MAC-Lasertalk among others
SUN-NeWS or X/NeWs and PSIBER
imagetops, fbps are also available.
XPS is an interpreter for X
How can I get a printout of a page rather than an execution.
There have been several utilities posted for this. The most comprehensive
one is:
%!-Adobe-1.0
%%Title: asciiprint.ps
%%Creator: Ben Cranston <zben@umd2.umd.edu>
%%CreationDate: Thu Feb 8 1990
%%Pages 0
/Courier findfont 10 scalefont setfont
/colwid (m) stringwidth pop def
36 756 moveto
256 string
{ %exec
{ %loop over file
dup currentfile exch readstring exch
{ %loop FF
(\f) search exch
{ %loop LF
(\n) search exch
{ %loop CR
(\r) search exch
{ %loop TAB
(\t) search exch
{ %loop BS
(\b) search exch
show
not { exit } if
pop currentpoint exch colwid sub exch moveto
} loop %BS
not { exit } if
pop currentpoint exch 36 sub colwid div .49 add cvi
8 add dup 8 mod sub colwid mul 36 add exch moveto
} loop %TAB
not { exit } if
pop 36 currentpoint exch pop moveto
} loop %CR
not { exit } if
pop 36 currentpoint exch pop
11 sub dup 25 le { %if
pop showpage 756
} if
moveto
} loop %LF
not { exit } if
pop showpage 36 756 moveto
} loop %FF
not { exit } if
} loop %over file
pop showpage
} bind exec
The tab code has been changed to make it more readable and modifiable.
The two 8s are the tab stops, you should be able to change them to any
other number. The only other change is the indentation at three should
be a tad more readable than the old indentation at two.
1. FF (form feed) causes a break to the first character position on a new
page. If FF is given at the very end of a file a blank page is produced.
2. LF (line feed) causes a break to the first character position of a new
line of the page, except when that would be below a certain point, in which
case a break to the top of the next page occurs instead (unmarked "if").
3. CR (carriage return) causes a break back to the first character position
of the CURRENT line.
4. TAB (horizontal tab) causes a break to the next multiple of 8 characters
from the left margin. The magic constant 248 is 0xF8 which throws away the
bottom 7 bits. The tab spacing could probably be changed if one were to
make the appropriate adjustment to this number.
5. BS (backspace) causes the print position to move one character width back
to the left.
Tabs:
1 22 333 4444 55555 666666 7777777 88888888 9999
Underlining type 1:
___________ type 2:
There is a formfeed at the end of this line --->
A simple one can be found in the GREEN book, but it operates in line mode
like a teletype almost.
/buff 128 string def
/emulate
{
{
currentfile buff readstring
exch show not
{
exit
} if
} loop
showpage
} bind def
%
% usage
%
72 750 moveto /Courier findfont 10 scalefont setfont emulate
text follows to be printed. Each line will be isolated when a NEWLINE
is encountered, and then printed.
A final note:
I have been maintaining a running archive of the PostScript group since
Jan 24, 1990.
Cheers
Woody
p.s. Sorry for the length. If I tried to answer more questions this
would get real long.
Oh, and one other thing: If I've made a technical error, let me know about
that as well.
Cheers
Woody