🚀 go-pugleaf

*** FLAME ON ***
In article <558@atari.UUCP> dyer@atari.UUCP (Landon Dyer) writes:
>Naturally, if you are using postscript, you *must* image a page,
>because postscript is so very slow....

this is horse-puckey!!  postscript *is* slow, but it is NOT because it uses
a full-page bitmap.  don't be ridiculous.  it takes far *less* effort and
time to print from a full-page bitmap than to traverse a display-list for
complex graphics.
*** FLAME OFF ***

>The same memory non-constraints apply to the ST.  It is possible to
>get surprisingly complex output by banding in real time.  These same

if you are doing *simple* page output, you can get by with display-lists
(i.e. no full-page bitmap).  however, it is possible to break this mechanism.
for example, full-page bitmap graphics are not possible.  this is obvious by
the fact that a bitmap is memory, and if the memory is not available, you 
can't create the bitmap. 

true, for text-only, or text with VDI primitives that can be collected and
processed via display list, you don't need a full-page bitmap.  GSS VDI/CGI
printer drivers work this way.  (remember that GSS wrote the original VDI for
DRI.)  if you need large bitmaps, you are screwed.  also, in a display-list
engine, the time to process the the image increases exponentially with the
complexity of the data, rather than linearly as with a full-page bitmap.  this
is because the list must be traversed *many* times to draw the appropriate 
scanlines of the overlapping primitives.  it gets somewhat less than elegant.
display-list engines also need memory/tempfiles for storing the display-list
and the pass bands.

with memory becoming virtually free, why not give the people something they
can truly use, rather than an incomplete tool?  i'd hate to pay alot of $$
for a high-quality output device that didn't do all i wanted/needed.

-- jdm
-- John D. Miller, Graphic Software Systems, Inc.  Beaverton, OR
--