I want to print a bitmap. To avoid printing small bitmap I set CScrollView mode as MM_LOMETRIC with sizes 3830x1995. I have created the bitmap and made the bitblt to the screen. There were everythig just like I want on the screen and on the print preview but when I printed the document I`ve got very bad result.
It seems to me that printer does not see a bitmap the same way as print preview does. Pay attantion that the first ractangle puts directly on the DC and memDC puts into it. Are there any ideas how to fix this mismatch between print previw and the real printing?
You need to set the mapping mode in the actual device context where you are writing the data. In this case you need to set it into the PrinterDC to make it consistent with the screen settings, and the actual image. See Mapping Modes and Translations | Microsoft Docs[^].
The screen works on 96DPI unless you are in a DPI aware app which if you want to confirm
HDC screen = GetDC(0);
long hPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSX);
long vPixelsPerInch = GetDeviceCaps(screen,LOGPIXELSY);
So it's setup that 96 pixels = 1 inch, not in the real world but that is what 96 pixel represents on screen
When you map it to 0.1mm per device space 25.4mm = 1 inch so 254 pixels now = 1 inch
Now the same works for the resolution of your printer depending on it's resolution
So lets say you are printing at 150dpi on the printer so when you set it to 0.1mm per device unit
1500 pixels = 1 inch on the printer
Normallly the printer select dialog goes close because it knows the screen is 96DPI and it knows what the
printer DPI is but you have messed about with the modes and thrown it out by a fair bit.
It's usually pretty close all by itself
Anyhow the scaling is easy .... correct size = size * effective Printer DPI / effective Screen DPI;
When you select the printer you can get it's DC and pass it into the code above and get it's hPixelsPerInch
and vPixelsPerInch just as you did the screen. Hence you can work out the scale.
Thak you for the answer but there is a problem with the bitmap that is inscribed in the ractangle.
If you look at the print preview - you will see this bitmap well. But if you print the real page you will see that ractangle is printed perfectly but the bitmap (inscribed into ractangle) was cut from the right side and the bottom.
If there was a problem with dpi we would have problems both with the ractangle and with the bitmap.
Print preview: Preview[^]
You aren't getting that memory DC's are basically free you aren't limited to just one and why they exist
Lets see if I can make you understand.
This stuff is only important for bitmaps you can print text all day and never need to know this stuff
1.) When you print bitmaps you make a new memory DC to match the printer not the screen!!!!
HDC SecondDC = CreateCompatibleDC( >>> PrinterDC <<<);
2.) Put your image on the memory DC and you use it to print .. just like you did the screen DC
3.) Now print it.
4.) Now you destroy the memory DC that matches the printer you are done with it.
At no point in that did I change or alter your screen bitmap/DC
What you aren't grasping is why you need a memory DC .. so lets deal with that because it is important.
So a true device DC may have a different planes and colour layout to your image and if that was done
at a driver level, every driver would have to know how to deal with every colour format. So they don't
do that the driver generally knows exactly one colour format usually RGB. The memory context is the
thing that knows all the different formats and is essentially device independent. So when you want to
print what a bitmap what you want is a memory context that matches the PRINTER DC not the screen.
If you understood the above you will understand what they are doing but lets walk thru it
1.) They got the printer DC because that is our device NOT the screen
2.) They got the width and height of the printer from that DC.
3.) They made a memory DC to the printer DC to transfer the image onto (printer DC not screen DC)
4.) They selected the bitmap you want to print to the memory context so it initializes how
to convert the bitmap for the printer.
Then they will transfer all the image and stuff onto the memory DC, then they will copy it to
the printer and then they will throw the memory context away it isn't needed anymore.
The important part here is the memory context that matches the printer is the right scale
and it has the right colour plane organization and it has nothing to do with your display
memory context which is dangling around elsewhere in your code.