Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!sun-barr!newstop!texsun!csccat!larry
From: larry@csccat.UUCP (Larry Spence)
Newsgroups: comp.lang.postscript
Subject: Re: *COMPLETE* Postscript Descripti
Message-ID: <3436@csccat.UUCP>
Date: 28 Dec 89 23:50:05 GMT
References: <17492@rpp386.cactus.org> <99500009@p.cs.uiuc.edu>
Reply-To: larry@csccat.UUCP (Larry Spence)
Organization: Computer Support Corporation. Dallas,Texas
Lines: 30

In article <99500009@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes:
>
>Re: Postscript printers that image the page using several bands
>
>To free up the band buffer, it must be printed.  But then the next
>band must already be imaged because printing is now in progress.
>Since a band can be extremely complex, even a clever band-buffering
>scheme might fail if the page is very complex.
>
>Low-end Xerox Interpress laser printers use banding, and will screw up
>complicated graphics (especially scaled bitmaps) because of this
>phenomena.  I know of no workaround.

Same goes for the Genicom 300 dpi printers that use their proprietary ACE
PDL (similar to PostScript).  They're blazingly fast, but there seems to 
be some sort of intersections-per-scanline limit.  When you hit the limit,
it just repeats the previous scanline over and over until the complexity
drops back below the limit.  The visual effect is that your text/graphics 
get "stretched" vertically in the offending area.  Actually, this happened
in their beta units, so maybe they've fixed it, but I think it's inherent
in their rasterizing method.

I also read somewhere that Adobe considered this sort of scheme and even
implemented it as "SubScript" (I'm not kidding).  They decided the lack
of guaranteed results was too high a price to pay for the speed.

-- 
Larry Spence
larry@csccat
...{texbell,texsun,attctc}!csccat!larry