Am 21.02.2010 22:16, Matthias Melcher wrote: > > On 21.02.2010, at 20:44, Roman Kantor wrote: > >> Indeed this printing patch was done through device abstraction. > > That sounds just fantastic! Can we still combine this with the work done for > 1.3 printing? > > +1 on this!!
Yes, indeed, I'd favor the Fl_Device abstraction, too. AFAICT this could both be integrated, and we could do cherry-picking to get the best of both. But the problem is the time frame for such a big reorganisation. Although the simple "conversion" from basic drawing function calls to Fl_Device methods looks easy, I can't tell if this would be doable in an acceptable time to fit in a 1.3 release schedule. And, as Roman wrote, image drawing is a big problem. But this problem is currently already visible: fl_draw_image() is _not_ cross platform compatible, because it supports alpha channels only on Mac, but Fl_RGB_Image::draw() supports alpha channels on all platforms. OTOH, real PostScript rendering can IMHO not be done without the device abstraction, and even the plan B (offscreen image rendering) would probably need different offscreen functions (not macros as they are today). I suspect that we would need some sort of stack to save the display context (and IIRC I've seen something like that in the Fl_Device code). Thus, the main question is: start a new (IMHO big) project of Fl_Device abstraction now and postpone the 1.3 release, or try to release 1.3 soon and wait for 1.4 to do the device abstraction. If this would be done, we could have full printing support for Mac and Windows, but only restricted (or none) for *nix: methods like Fl_Printer::draw_widget() could probably be implemented by offscreen rendering, but the full drawing functions can not be implemented w/o also changing the offscreen functions. Or something like that... still thinking about it ... Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
