|
|
|
date: Tue, 8 Apr 2008 17:18:12 -0400,
group: microsoft.public.win32.programmer.gdi
back
Re: StretchDIBits To Printer In Landscape
Just a guess, but I wonder if this could have something to do with the
size limits when rotating a bitmap?
We have run into similar problems when using any bitmap rotation method,
StretchBlt with a rotation transform, PlgBlt, even BitBlt with a rotation
transform. In our scenario, we would run into an initial failure point
where the image data would be passed, but not show up, and then a
secondary failure point at a greater size where the data would fail to
even be passed. This occurred with any high res DC, such as a Printer or
EMF based on a printer.
A call to MS verified that this is a bug, and that there is no hard upper
limit to work off of. We just had to break the image down into chunks and
blit the smaller chunks, or rotate the bits ourselves.
P.S.
Overall memory does not seem to be the deciding factor. A 4GB machine was
failing at lower thresholds that a 1GB machine for us. It has more to do
with how much free space the internal OS processes that handle the bit
rotation have available at the given moment.
On Tue, 08 Apr 2008 16:18:12 -0500, Microsoft
wrote:
> Hello:
>
> I've run across a problem with the StretchDIBits function that seems to
> be
> printer dependant:
>
> Everything is fine in potrait mode. When I programmatically set the
> printer
> to landscape mode, after which I get a blank document printed. Even
> though
> the StretchDIBits call returns a value equal to the correct number of
> scanlines, and it appears that a printer job of the correct size is
> spooled.
>
> The real puzzler is, that I have a printer that will print the same
> documents correctly in landscape mode. The offending printers are a
> couple
> of Epson InkJet types (1400 & 1280), and an HP Laserjet. The printer on
> which the StretchDIBits works in all cases is a Canon iRC. All these
> printers report to be RC_STRETCHDIB capable.
>
> Any help would be appreciated,
>
> John A. Burns
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
date: Thu, 10 Apr 2008 13:22:40 -0500
author: RMurdock
|
|