Path: utzoo!attcan!uunet!wuarchive!brutus.cs.uiuc.edu!apple!apple.com!parent
From: parent@apple.com (Sean Parent)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Meaning of visRgn in offscreen bitmaps + whinings about PrintManager.
Message-ID: <3906@internal.Apple.COM>
Date: 25 Aug 89 00:13:16 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 81
References:<22321@andante.UUCP> <30755@ucbvax.BERKELEY.EDU> <34168@apple.Apple.COM> <1336@speedy.mcnc.org> <3733@internal.Apple.COM> <1342@speedy.mcnc.org> <3801@internal.Apple.COM> <1346@speedy.mcnc.org>

Let me preceed this by saying that I am not a PostScript expert. I don't 
work with PostScript at all, however, I do work in the PrintShop.

In article <1346@speedy.mcnc.org> kk@mcnc.org (Krzysztof Kozminski) writes:
> Yes, but the scaling is the simplest possible when 'exact bimap image' is
> turned ON: 1 pixel of image maps into 4x4, 2x2 and 1x1 at the 100%, 50%, 
25%.
> Why isn't there a CASE in the LW driver to handle these special values
> efficiently? (BTW, 100% with 'exact bimap image' turned OFF takes ~10 
times
> longer than with ON - this I can easily understand).

The LW driver does not scale the BitMap PostScript does. What would the 
case statement do?
Remember the LaserWriter Driver is written as a general purpose PostScript 
Driver. It drives the LaserWriter Classic, +, NT, NTX with variouse ROM 
revisions and the QMS ColorScript, and variouse other PostScript devices. 
Sometimes it has to talk to the device through a server.

> I've just looked it up in the Adobe manuals: Hex or binary turns out to 
be
> the same bits (unless LW driver tries to do some fancy data compression
> while sending it over).

No, the hex data is twice the size of binary data. That is the data is 
sent as ASCII digits like:

     4F56

Each nibble requires 1 byte to transmitt.

> The way I figure it out, it should take about 3 seconds to print a 
full-page
> bitmap at 25% reduction with 'exact bimap image' turned ON. (this is 
assuming
> transfer rate about .5Mbytes per second - I seem to recall this value 
from
> somewhere in the IM).  Can anybody tell me why it ain't so?

Yes, it should take only 3 seconds. Or even 6 seconds sent as HexData. But 
there is overhead in packaging the data, overhead in sending it (can you 
say busy networks and protocall layers), then PostScript gets
its grubby little hands on it and takes a merry amount of time :-P

> Yes, perhaps I should be more specific: how come 'srcOr' is supported
> (the only mode not supported for bit image transfer is 'srcXor') and
> 'patOr' is not? For a while I had a little routine that implemented
> 'patOr' for 'PaintRect' by filling a small 16x16 bitmap with the
> desired pattern, and then repeatedly doing CopyBits from it to cover
> the destination rectangle, while taking care of the proper alignment as
> well. Before even getting this to work, I've found out that doing my

Well, that would work fine for rectangles but what about Ovals Arcs, 
RoundRect, Polygons? These are handled by creating a spot function in 
PostScript that mimics the pattern and draws the object with this spot 
function.

> own entire image and copying it over is faster.  Now what is so
> complicated about the above that it could not be implemented by Apple
> in the first place?

There is nothing so complicated about it. In fact, the fastest thing would 
be to image the entire page with QuickDraw and send one big BitMap to your 
device. But then you have to know the printers resolution and build a 
Raster Engine into the LaserWriter Driver (Oh I wish QD could scale 
objects correctly) And then you can't handle PostScript in the document 
and QuickDraw doesn't currently support outline fonts (but will soon) and 
QuickDraw doesn't currently support rotation. You could pre-scan a page 
for these items and transfer modes and such and decide what image to send 
to the printer. But what if an App wants to send everthing? How do you 
explain that the entire page looks slightly differently when they use XOR 
on an object? (Apple Outline Fonts and PostScript do not look identical, 
niether do QD ovals and the ones drawn by PostScript).

These are difficult problems and the 7.0 architecture will help by 
allowing specific drivers to be written to support a device to the fullest 
extent possible. Printing is getting better all the time (compare the 6.0 
LaserWriter driver to the previous version (5.2?)).

Sean Parent
I have my opinions and my employer has his/hers.