🚀 go-pugleaf

In article <zisk-181292180203@macne003.boston.us.adobe.com> zisk@adobe.com (Stephen Zisk) writes:
(justification on the printer...)
> This works well, but puts the load onto the PostScript interpreter.

<stringwidth> seems to be a cheap operator. 

> For tests, short jobs, and personal use, this is fine, but if you
> are writing a driver with performance in mind, you should at least
> consider doing the job on the host.

I don't know about that. I've used text-to-Postscript preprocessors, and
even on printers with a cheesy 68000 I've got better results in terms of
page speed letting the printer do this sort of thing. It seems that parsing
Postscript (breaking up numbers, words, etc) is relatively expensive
compared to executing the Postscript code... at least, that's what my
informal timings (printing a sizeable text file in MP, TEXTPS, PPS, and
other front ends) seem to imply.

As always, your milage may vary. Run tests both ways and see what happens.

Personally, I would prefer it if programs made decisions like this as late
as possible, so I can print a document with a different font (say, my printer
doesn't handle Palatino and the company is too cheap to buy a softfont)
without screwing things up too badly.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"