Vincent Povirk <madewokh...@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. -- Dmitry.
