|
GDI+ draws transparent/alpha blend PNGs to the printer DC.
Using the PNG from here[^] I replaced the StretchDIBits() call
in PrintPicture() with
Gdiplus::Graphics graphics(hdc);
Gdiplus::Bitmap SrcBitmap(L"C:\\test.png", FALSE);
graphics.DrawImage(&SrcBitmap, 10,10,400,400);
and it worked fine.
My initial test with an image list didn't draw anything. It should have at least drawn without
transparency. I'm looking into this further.
Using masked blts with XOR/AND may work too but I'm too lazy to try....maybe I will 
-- modified at 12:07 Wednesday 3rd January, 2007 - Fixed typing
|
|
|
|
|
Actually, I tried GDI+ before: it did not print anything at all.
Let me look into it again.
|
|
|
|
|
I tried this code using GDI+. It works ok on screen, but prints nothing
|
|
|
|
|
hmm it works on Epson Stylus Photo 1280 - I haven't tried on laserjet yet.
|
|
|
|
|
Using an image list I added this
CBitmap bitmap;
bitmap.LoadBitmap(IDB_BITMAP2);
CImageList imagelist;
imagelist.Create(400, 400, ILC_COLOR24|ILC_MASK, 1, 1);
imagelist.Add(&bitmap, RGB(0x00,0xFF,0x00));
ImageList_Draw(imagelist, 0, hdc, 360, 10, ILD_TRANSPARENT);
where IDB_BITMAP2 is a 24-bit bitmap with background RGB(0x00,0xFF,0x00).
It draws transparently fine BUT always uses the background color of the DC (it doesn't blend
with what's already drawn on the dc).
So, drawing the imagelist bitmap on top of the PNG image leaves a white rect around the bitmap.
Drawing the PNG image on top of the imagelist bitmap works correctly - it alpha blends the PNG
image with the underlying bitmap.
|
|
|
|
|
Well, in this case you _know_ your background: IDB_BITMAP2 represents it. But
problem is, in case of printer's DC, I don't have such a bitmap (that's what I was trying to get with BitBlt). And it's not a monochrome background (that'd make my life easy!) so it just does not work for me.
I am still strugling to print a PNG (or even a bitmap) with GDI+. It won't
|
|
|
|
|
Yuriy2003 wrote: Well, in this case you _know_ your background: IDB_BITMAP2 represents it.
Right. I was just reporting my findings  I didn't even think it would draw on the printer's
dc transparently, but it does.
Yuriy2003 wrote: I am still strugling to print a PNG (or even a bitmap) with GDI+. It won't
 And it prints to the screen fine, with alpha blending?
|
|
|
|
|
Yes, on screen DC it works perfectly. Always did.
|
|
|
|
|
I've seen that the BitBlt from the dc isn't going to work but using GDI+ to draw a PNG
on the printer dc isn't working? If not then it's a lame driver. It should at minimum
draw without blending/transparency.
|
|
|
|
|
Yes. There's something wrong between my GDI+ and printer. Problem is,
graphics.DrawImage() is void, does not return any values, so I can't check for errors. Is there a special GDI+ initialization for printer device, maybe?
All initialization I am doing is calling GdiplusStartup:
Gdiplus::GdiplusStartup(&m_gdiplusToken, &gdiplusStartupInput, NULL);
|
|
|
|
|
Graphics::DrawImage should return a Status enum == 0 (Gdiplus::Ok) on success.
GDI+ Initialization should be fine as you have it (that's what I'm using):
Gdiplus::GdiplusStartupInput StartupInput();
if (Gdiplus::Ok != Gdiplus::GdiplusStartup(&GdiPlusToken, &StartupInput, NULL))
{
...failed
}
You are using a Graphics object constructed using the printer DC right?
Mark
|
|
|
|
|
Yes, I am passing it a printer's DC.
P.S. Now I am trying to build an separate executable that uses GDI+ (I suspect the image might be not printed because of clipping or something else I don't control, although GDI functions work (wrongly)), and I can't even compile it. Gives me ton of compiler errors. The other project is a DLL, and it compiles fine. Same IDE, Visual Studio 2003. I am having a bad day.
|
|
|
|
|
Have some news. I was able to compile and build the code using GDI+ in a standalone app. It actually printed the image (the DLL using the same code is not printing), not the size I expected, but on a b/w printer it actually printed it with a shadow! On the color printer though, it still ignored background for all pixels with alpha (transparency) values greater than 0. It's still a big step forward. Now I am looking into why it's not working off the DLL, and why it's printing image of a diffferent size.
|
|
|
|
|
Cool
I forgot to mention - are you using StretchBlt or StretchDiBits anywhere still? You may want to
set the stretch mode properly if necessary and restore it after the stretch operation. I noticed
that in the code I've been testing from (although it made no difference in the problem).
To get a blend of more than one alpha-blend image you may need to do it all in a memory DC then
do one blt to the printer DC - I think GDI+ can handle that. I've been unable to get a blend on
a printer DC. The printer DCs behave write-only so any operations requiring reading colors
already there fail...
|
|
|
|
|
Mark, just want to let you know that I finally was able to print PNG with GDI+ correctly (that is, correct size). There's still a minor problem with shadows on color printers, but I can live with it. Apparently, the size of image that I have to pass to DrawImage() is different from that used in StretchDIBits() as destination coordinates. Looks like DGI+ does its own stretching. This is why my original code using GDI+ was returning successful code but did not print: the image was beyond the page size. Thank you for your help.
P.S. Where are you located (physically)?
|
|
|
|
|
Yuriy2003 wrote: just want to let you know that I finally was able to print PNG with GDI+ correctly (that is, correct size).
Good! Glad you got it working, at least for the most part
I'm in CA, USA.
Mark
p.s. Sorry I had to reply to a different message since this forum software fails when the message
heirarchy gets too deep.
|
|
|
|
|
Are you working/employed?
|
|
|
|
|
Yuriy2003 wrote: Are you working/employed?
Both, yes....self employed. You? Why?
|
|
|
|
|
No, I am just working.
Well, I see you post a lot of messages on this forum, so you must have some time for this. My company is hiring people right now, lots of interviews etc. I could recomment/refer you if you are interested, but we're in NJ.
|
|
|
|
|
Yuriy2003 wrote: No, I am just working.
Well, I see you post a lot of messages on this forum, so you must have some time for this. My company is hiring people right now, lots of interviews etc. I could recomment/refer you if you are interested, but we're in NJ.
Cool. I appreciate it. I don't necessarily have the time but I take the time.
I'm at my computer so many hours a day finishing a project I started 5 years ago so I always
have the same solution open on my monitors along with a little test application project
to test code I post in the forums. It's good for me to refresh on things I haven't used in a
long time plus I learn new stuff often so that makes it worth hanging out in the forum.
Otherwise I'm just grinding away at the same GDI/DirectX/Database/Socket code all day long!
Mark
|
|
|
|
|
Five years? What is this project doing?
|
|
|
|
|
Also, you could try BitBlt of the printer DC right to a screen/window DC - that'll show you what's
in the printer DC's bitmap
|
|
|
|
|
Well, I can see it in a debugger too.
|
|
|
|
|
What happens if you create a 32bpp bimap and blt the printer's bitmap to it.
Then you don't have to worry about the printer's bitmap format.
// hDC is printer's DC in this case
HDC hCaptureDC = CreateCompatibleDC(hDC);
// img structure contains width, height, etc. for the image
HBITMAP hCaptureBitmap = CreateBitmap(img->width, img->height, 1, 32, NULL);
HGDIOBJ h = SelectObject(hCaptureDC, hCaptureBitmap);
ret = BitBlt(hCaptureDC, 0, 0, img->width, img->height, hDC, x, y, SRCCOPY);
|
|
|
|
|
CreateCompatibleBitmap() is supposedly safer. This is why I am using it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
