bitmaps

NTDEV
1

I dont know whetehr this is the right place to post this problem, but it
does have something to do with drivers so…

well, I am trying to add some functionality to the bitmap rendering plugin
of the DDK samples.

As of now this sample just dumps the bitmap of the page rendered to a file
on the disk. I also want it to do additionally (upon user rwquest) fire a
print of the same to the default printer.

Well, the problem arises when I try doing it.

the StretchDIBits function i am using to put the bitmap on the printer DC
returns 0 and also get last error is 0, but the corresponding print is a
blank page!!! I cannot understand why this is happening.

I wrote the printign code in a DLL the exported function takes a fle name
and prints it. It worls fine for small BMP files, and the return code for
StretchDIBits is correct.

But bitmap.dll dumps a 7.5 Megs bmp for a single page, and this
StretchDIBits is not able to render.

any clues how to solve this>

–

  • amitr0
2

hi amitr

try to reduce dpi for printing.

It can be found in GPD file for your driver

hope this helps

jrc

3

no this would redurce the quality of teh prints. is this a limitation in the
StretchDIBits implementation?

On 9/13/06, xxxxx@gmail.com wrote:
>
> hi amitr
>
> try to reduce dpi for printing.
>
> It can be found in GPD file for your driver
>
> hope this helps
>
> jrc
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–

- amitr0

4

btw, even on the lowest resolution 150x150, the bitmap size is around
1.5megs, and still the function StretchDibBits fails!!!

On 9/13/06, amitr0 wrote:
>
> no this would redurce the quality of teh prints. is this a limitation in
> the StretchDIBits implementation?
>
>
>
>
> On 9/13/06, xxxxx@gmail.com wrote:
> >
> > hi amitr
> >
> > try to reduce dpi for printing.
> >
> > It can be found in GPD file for your driver
> >
> > hope this helps
> >
> > jrc
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
>
> –
>
>
> - amitr0
>

–

- amitr0

5

amitr0 wrote:

btw, even on the lowest resolution 150x150, the bitmap size is around
1.5 megs, and still the function StretchDibBits fails!!!

Which DC are you passing to StretchDIBits? A printer? Are you using
SRCCOPY as the ROP? What is the color format of the DIB?

Have you tried “banding” the stretch, so you do a few scans at a time?

You also might want to consider the fact that the GDI stretches are
stupid stretches. They just duplicate the nearest neighbor; there is no
interpolation. If you want quality, you might want to write your own
interpolating stretcher.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

>Which DC are you passing to StretchDIBits? A printer?
Yes.

Are you using SRCCOPY as the ROP?

Yes

What is the color format of the DIB?

256 colours

Have you tried “banding” the stretch, so you do a few scans at a time?

No that I haven’t.

You also might want to consider the fact that the GDI stretches are
stupid stretches. They just duplicate the nearest neighbor; there is no
interpolation. If you want quality, you might want to write your own
interpolating stretcher.

That comes later…first we need a working concept!

I debugged this stupid bug to the level of Bmo files itself. Ok the problem
is here. Lets say I have a bitmap prinped by the bitmap rendering plugin at
50x50 dpi.

It saves the bitmap, and it is viewable in all viewers.

So far so good. Now I use the MS ShowDib sample to print this bitmap, it
uses the same technique I am using to print a bitmap saved ina file. I get a
blank page out of it!!!

Ok, so I now open this same bitmap in Paint and without any modifications I
“save As” another BMP. Through a hex editor, I see lots of changes in the
two files. I print the new file (generated by MS_PAINT) through ShowDib and
again get a blank page!!!

Ok so I say, and now this time I open the original bmp (generated by bitmap
rendering plugin) through MS_PAINT, and add some drawings to it. DO a save
as, and fire a print through ShowDib, I get an exactprintout of the
document!!!

I do not understand this funda at all!!!

So I open the original bitmap with irfan view, do a save as (without any
modifications), and then fire a print through ShowDib, and it prints it!!!

Needless to say, the file saved from irfan is also structurally different
from the original file!!!

Is this a problem with the way showdib prints???

Please suggest!!!

amitr0

7

Amitr0 sent me these bitmaps, and this is what I found:

The ones that won’t print are top-down format. The ones that do are bottom-up.

So I’m pretty sure the origin used for his source rectangles is the bottom left corner. It needs to be the upper left (this is stated in the API documentation for StretchDIBits).

The original bitmap file is also broken in several respects:

(1) The file header size didn’t include the size of the color table, hence was 1024 bytes too small. Fortunately none of the programs used to read this file used the value, and just loaded the entire file. It only takes one careful app to screw that for you (all the apps corrected this when the image was saved from them).

(2) The reported bitmap size is 395 x 520, but the image size says that it is actually 396 x 520. This would cause each scan line to be skewed by one pixel. The image used isn’t very complex, and has tons of white space, so this didn’t show up visually, but it’s sure going to cause you headaches soon enough if you don’t fix it.

(3) The DPI settings were put in the “pixels per meter” fields. Since there are nearly 40 inches per meter, these numbers are WAY off (says each pixel is meant to be almost an inch in size). This usually isn’t going to cause much trouble, as the values don’t get used in a meaningful way very often. But experience tells me you’re probably borrowing trouble when you take a shortcut like that.
(Also that it will usually occur sometime after you report being ready to ship, and it will be an exec in your company or customer’s company who will find it)

So to sum up, the apps whose output bitmaps your code printed changed the image format to one your broken printing code would print. The original bitmap is further broken in ways that will likely cause additional problems down the line.

8

Nope, this is me in idiot mode. The extra size is padding of the scan lines. I cannot recall if it is WORD or DWORD (I think it is DWORD For DIBs and WORD for DDBs).

9

xxxxx@microsoft.com wrote:

(2) The reported bitmap size is 395 x 520, but the image size says that it is actually 396 x 520. This would cause each scan line to be skewed by one pixel. The image used isn’t very complex, and has tons of white space, so this didn’t show up visually, but it’s sure going to cause you headaches soon enough if you don’t fix it.

Scanlines in a DIB are ALWAYS padded to a dword boundary. A 395 x 530
8-bit DIB will always have 396 bytes per scanline. That last byte is
unused.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.