spencer@eecs.umich.edu (Spencer W. Thomas) (04/14/89)
I ran into a number of confusing things when writing a program to print bitmaps recently. (I might add that my first printing experience was very good -- I just called my normal drawing routine, and it printed.) I figured the way to print a bitmap was with CopyBits (seems logical). Reading the manual seemed to indicate that the right thing to do was to put the printer into DraftBits mode (from IM Vol 5 and/or TN 128): This call forces draft-mode (i.e., immediate) printing, and will allow bitmaps to be printed via CopyBits calls. Ok. No problem. I eventually traced my bombs down to IconWrapInit, and removed it. There were a couple of strange things from the beginning: one was that ThePort->portBits.bounds was (0,0,0,0), and the second was that, no matter what destination rectangle I gave, I always got one bit/pixel on the printer (i.e., I couldn't get CopyBits to shrink or expand my bitmap). Ok, I sez, no problem, I'll just expand 'em myself (I needed a factor of 2 -- I should say that the debugging was done on a LW IISC, so no PostScript). I made a little bitmap twice as big as one row (i.e., 2 rows high, and twice as wide), and CopyBits-ed into that, then printed it. Nothing came out on the printer! Really strange. So, I made a bitmap twice as big as my whole image (which was already about 1k x 1k) and printed from that. That worked ok. I was still bugged, though, and did some more experimenting. My conclusion was that CopyBits to the printer (LW IISC, anyway) used the SOURCE rectangle for both the source and destination bitmaps! Thus, the reason I could print the big bitmap was that I was incrementing the source rectangle as I printed. The reason the small (2 row) bitmap apparently did not print was that it was always printing on the same two rows of the printer, and the last row printed was all white. There were some other oddities that I thought I detected, but I'm not now sure whether they were real. The biggest one of these was that a CopyBits from one in-core bitmap to another would apparently not work if ThePort was the printer port, but would work fine if ThePort was a window (even though I was not doing anything to either the printer or the window with this CopyBits operation). Does anybody know what was really going on here? Was I seeing a bug (or bugs) in the LW IISC driver? Is this the way that CopyBits is supposed to work to a printer? Do I really need to invoke DraftBits to CopyBits to a printer? (If so, this breaks the "printer == screen" philosophy of printing.) Is there really no way to make CopyBits expand or shrink a bitmap on its way to the printer? In confusion, -- =Spencer (spencer@eecs.umich.edu)