Vincent Povirk madewokherd@gmail.com wrote:
I tested printing quite a bit of different documents with an application I have here and all of them get printed correctly with the patch. Before the printed pages were just blank. What do you think is better for a user?
It's not good if things work by coincidence in one case that's important to you, and then we can't fix other cases later (or we can't fix other cases without breaking yours).
I don't understand your objection, nothing prevents you from improving my patch. Printing something is still better than printing nothing, consdier this as adding a partial implemenation in the place of a stub. GdiAlphaBlend is not supported by printers, that's a matter of the fact, using StretchBlt for now is better than doing nothing and even not printing a FIXME or returning an error to an application. Feel free to implement it differently, until that my implementation is suffice for many applications.
If neither of those things are possible, the best we can do is to do ALL of our drawing through alpha_blend_pixels (by using a GpGraphics without an hdc), compose the result internally, and blit the result with a mask based on the resulting alpha values when GdipFlush or GdipDeleteGraphics is called.
Did you test it under Windows? Does it really do it that way?
I heard a rumor that native draws by reading screen bits and writing back modified screen bits. This is consistent with what I know about the GDI+ API (in particular, it seems to be the only way to fully control gamma correction, which the API allows). I have not made any attempt to verify this.
Obviously this can't work for a printer.