Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!purdue!decwrl!adobe!greid From: greid@adobe.com (Glenn Reid) Newsgroups: comp.lang.postscript Subject: Re: Why is Display Postscript Fast when Printer Postscript is Slow? Message-ID: <133@adobe.COM> Date: 20 Dec 88 01:51:15 GMT References: <1481@helios.ee.lbl.gov> <2164@daisy.UUCP> Sender: news@adobe.COM Reply-To: greid@adobe.COM (Glenn Reid) Organization: Adobe Systems Incorporated, Mountain View Lines: 41 In article <2164@daisy.UUCP> cplai@daisy.UUCP (Chung-Pang Lai) writes: >In article <1481@helios.ee.lbl.gov> forrest@ux1.lbl.gov (Jon Forrest) writes: >]I'd like to hear comments about how Display Postscript is fast >]enough to be used as a display system whereas Printer Postscript >]seems to be the bottleneck on many laser printers. >]What are the other differences that make the speed of >]Display Postscript so much better? >] >]Jon Forrest Lawrence Berkeley Lab., 486-4991 >]forrest@lbl.gov (internet) >]ucbvax!lbl-csam!ux1!forrest (uucp) >]FORREST@LBL (bitnet) > >These I heard from other sources: >1. 72 dpi vs 300+ dpi is a big difference. >2. Display PS cheats when handling small size font. They use bitmap > font when you can't tell the difference. >3. They pass pre-scanned tokens instead of sending streams of ASCII > postscript code. >I heard the above, don't blame me for any mistake. > 1. Yes, there are fewer bits to render. This helps, especially when software is rendering the bits (rather than hardware). 2. "cheats" isn't quite the right word. You CAN tell the difference, which is exactly why bitmap fonts are used. It isn't a performance optimization (the font cache would handle that). It is done strictly for the better appearance of hand-tuned bitmap fonts at small point sizes. 3. Yes, pre-scanned tokens is part of the streamlined front-end interface to the interpreter, and this also helps. There are also cached paths, graphic state objects, and lots of language extensions to help with interactive rendering. I hope this helps. Glenn Reid Adobe Systems