🚀 go-pugleaf

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