Indeed this printing patch was done through device abstraction. Device abstraction has lot of advantages (like independent implementation of new backends); you can eg make small postscript backend (like one included in the patch) or you can go through cairo with full-featured output not only for poostscript/pdf/... but also accelerated (well, whatever cairo does) display rendering.
The abstraction part is actually very easy and can be done gradually without breaking fltk core - see my post from 17/11/2009. The class need to include also two virtual functions(eg activate()/release()) which for screen output would do necessary preparation/release of the drawable and which would be called from within Fl_Window::make_current() function. They also need to have their own ofscreen() functions for building the caches. So I would vote to include the abstraction first(as soon as possible) as keeping recent code inside the default device represents nearly no risk of break things and let people play with their own device implementations completely *OUTSIDE* fltk. Once some device has matured it can be included in fltk/src/some_device subtree, the main candidate would be of course the cairo backend when finished. The early abstraction adoption would also help to keep binary ABI compatibility for longer period even after large rendering implementation changes and introduction of new devices. The biggest problem is abstraction of the image classes - there are three core ones: Fl_RGB_Image, Fl_Pixmap and Fl_Bitmap, the rest does not override draw() methods. The abstraction can be relatively cleanly solved by removing platform-dependent code from the draw() functions of these classes and instead use of "global" fl_draw_image(), fl_draw_pixmap()(which need to be slightly changed) and fl_draw_bitmap() (not yet implemented) and which would just redirected the output to a device offscreen for caching and fast sub-sequent rendering (the classes more-less already do that in this way, in the case of postscript/pdf such a cache can be uses as a dictionary entry to reduce data stream - but that depends entirely on how particular device wish to implement it). But as mentioned above the particular image function abstraction can be done at any time later until binary compatibility freeze is required. Just my 2c. R. PS: If you want to use some postscript code from the Fl_Device patch, use the code from 1.2 tree as it is more recent and known bugs were fixed there. Also win32 printing device is improved but do not use any automatic diff patching against 1.2 tree as 1.2 also include some complete rubbish styling code (sorry, my fault). I would also simplify the inheritance structure of Fl_Device classes compared to the original Fl_Device patch. Albrecht Schlosser wrote: > Am 21.02.2010 15:13, imacarthur wrote: >> >> On 19 Feb 2010, at 9:25, Albrecht Schlosser wrote: >>> >>> I also looked at Roman Kantor's Fl_Device patch [1] for FLTK 1.1.4, >>> and this looks much more like a way to get PostScript rendering to >>> work with printer devices. >> >> NOTE: I think this is what is in the experimental fltk-1.2 tree, is it >> not? >> >> Indeed, the version in fltk-1.2 may actually be later and more complete >> than the version linked...? > > I didn't look at fltk 1.2 (yet), and I didn't suppose to find this > there. Thanks for the hint, I'll take a look. > > Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
