[email protected] wrote:
> Author: manolo
> Date: 2010-03-16 05:03:48 -0700 (Tue, 16 Mar 2010)
> New Revision: 7275
> Log:
> Fixed WIN32 printing of RGB images without transparency. Still
> print_window_part() problem.
[...]
> + if(Fl_Device::current()->type() == Fl_Device::gdi_printer) {
> + // if print context, device and logical units are not equal, so
> SetDIBitsToDevice
> + // does not do the expected job, whereas StretchDIBits does it.
> + // TODO with Fl_Printer::print_window_part(), StretchDIBits does not
> work well
> + // with large captures whereas SetDIBitsToDevice does.
Ooh, yes, I see. That's a *known* (MS) problem !
http://support.microsoft.com/kb/111865
It hit me when I tried to do something similar for my own printing
purposes. It's bad - really bad.
I didn't understand why the code in fluid (see fluid/fluid.cxx,
lines 1110-1113) used StrechDIBits in a line-by-line loop, but after
trying it with a big block, I knew :-(
If you need more information, you can try to google with
StretchDiBits site:microsoft.com - or this direct link
<http://www.google.de/search?q=StretchDiBits%20site%3Amicrosoft.com>
But that's really bad in a context where there is already some kind
of blocking done (in fl_draw_image). Maybe it would help to reduce
the blocking size before doing all this if the context is printing,
but I didn't look at the code...
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
