sg1q+@andrew.cmu.edu.UUCP (07/12/88)
Roy Smith presented some questions about when to write difficult but simplified code for the sake of printer efficiency. I'm not quite sure whether you're comparing programming time vs. printer speed, or the speed of the computer vs. the speed of the printer. In the first case, printer time almost always costs less than programmer time, plus it aggravates at laserwriter a lot less than it aggravates me to do all that stupid math :-) In the second case, unless you want to spend as much time writing good code to do the work of the printer on the source computer as Adobe did writing the PostScript interpreter in the first place, you're are probably much better off using all the neat stuff that's already there. (like 45 rotate) It seems kind of silly to have all the power of the PostScript interpreter, and then ignore it. I'd rather let Adobe do their job, and I'll do mine. All this is not to say that there aren't things you might want to do to make things easier for the printer, but in general "if it ain't broke, don't fix it." In other words if it it isn't taking an inordinate amount of time for something to print out, don't worry about it. The places where PostScript starts to whine are more at the level of imaging, not simple path manipulation. -Simon Gatrall sg1q+@andrew.cmu.edu
greid@ondine.COM (Glenn Reid) (07/14/88)
The place where PostScript starts to whine is actually at the language
interpretation level, not at the imaging level. Imaging is fast, because
there is a compiled program that is doing the imaging. There is also
a compiled program that is reading bytes from the input stream, making
them into tokens and language elements, converting ASCII number
representations into binary numbers, looking up names, and generally
carrying out the task of interpreting your program. We call that the
interpreter, naturally. It is fast, but the interpreted program itself
is, well, it runs at interpreted speed.
Rotating a scanned image is easily handled by two tokens and one
operation in the interpreter, but lots of work by the imaging code:
45 rotate
It would be silly to try to rotate bits on the host computer rather than
do this.
However, centering text, for example, involves measuring the text,
dividing by 2, and moving to the proper point on the page, and involves
quite a bit of interpretation and PostScript language manipulation
to do it:
(text to be centered) 100 100
moveto dup stringwidth pop 2 div neg 0 rmoveto show
(text to be centered) 87.3 100
moveto show
There is roughly a 5 to 1 advantage in interpretation time in the second
method, and all that is required on the host end is a few simple bits
of arithmetic. This is a case where the code should be executed on the
host, even though it is probably a little LESS source code to put it in
the PostScript program. It is an interpreter language, don't forget. It
might run 100 times more slowly to do it in PostScript than in C
(wild figure).
The idea with PostScript is first to stop and look at what it does for
you (we call it the imaging model). In order to use the imaging model,
you then do whatever is necessary in terms of setup on the host end.
In order to print text, for example, what you need is the font, the
text itself, and its location on the page.
The fact that PostScript is a programming language should not encourage
you to perform division or compute arctangents with it. Use it simply
to optimize the job of imaging where you can:
/S {
moveto show
} bind def
(text to be centered) 87.3 100 S
(more text to center) 89.1 90 S
...
I hope this helps.
Glenn Reid
Adobe Systems