<r_z_aret@[EMAIL PROTECTED]
> wrote in message
news:3fa01746.19333329@[EMAIL PROTECTED]
> I may be missing something. StrechBlt copies from DC to DC, so I
> assume it will work with any sort of DC, including a printer DC. Thus,
> I figured you could do something like:
> a) "draw" on a hidden DC instead of the actual printer DC, then use
> StrecthBlt to copy and rotate everything to the actual printer DC
> or
> b) "draw" on the original printer DC, but copy to and from a
> tem****ary, hidden DC, so you can rotate once.
I don't believe this, or any solution involving blitting, will work, and I
think Feng Yuan (who is more qualified than me on GDI) agrees.
Consider the amount of data involved if you treat a page of A4 as a bitmap
when targetting a 300dpi printer -- far more than one screen's worth.
Trying
to use StretchBlt on this would involve creating a memory DC the size of
the
page, bringing the whole page (that the application printed) into memory,
and copying from one to the other. Then copying the whole lot back to the
printer. Printer drivers avoid dealing with all this data at once by
banding
their output; that is, dividing it into strips and processing each strip
at
once. The solutions in this thread have tried to deal with everything at
once which, even on current PCs, is a heck of a lot.
In my opinion, the best ways of dealing with this are:
1. Inserting a transform into the printer DC before the application sends
any data
2. Hooking into the printer driver somehow to reverse all the coordinates
3. Printing onto transparent acetate and turning it round, then
photocopying
that onto a sheet of paper
--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/
|
