MacArthur, Ian (SELEX GALILEO, UK) wrote in the thread called "Layout Manager":
[Matt wrote:] >>>> FLTK 3 with FLTK 2 API, 1.3 innards, and a 1.3 compatibility layer? [Ian:] >>> Yes please! >>> Maybe freeze 1.3 first though... [Matt:] >> Certainly. I'll wait fro printing support though ;-) [Ian:] > Seems like 2/3 of that pretty much works: > If we had *nix printing support too... > (I'm assuming simply dumping the screen image to the printer will be a > bit too coarse.) The "easy" way: Unfortunately we'd need more than that. We would need a full page offscreen image to render a page and dump _that_ to the printer using PostScript. ... Or, thinking about it a little more, we could (and probably should) combine both, i.e. use an Fl_Offscreen to render an image for the basic functions like Fl_Printer::print_widget() and write this image to the PS output file using the current origin and scaling. Code for this already exists (more or less) in fluid. There's also a printer selection dialog that we can use. IMHO this could be doable in a short time frame (for some value of short ;-). Alternative: 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. What it does (in a very short form): a) add an abstract (not sure about that) class Fl_Output_Device and redirect all drawing calls to virtual member methods of Fl_Output_Device. b) implement Fl_*Output* classes for screen output (using the existing functions) c) implement classes like Fl_GDI_Printer for printing to a GDI printer. That's almost the same as what we have, because it only needs some different scaling than the screen device. Same for Mac (exists already). d) implement a class Fl_PS_Printer for all drawing methods in PostScript. We could probably use Roman's class here. According to his test output (device.cxx[2], also included in our current printing subversion branch [3]), this works very well. So, what can we do ? (1) cleanup, maybe add rotating [4], merge the printing development branch back to the current 1.3 branch, and use it w/o Linux/U*x/PS support. The current version would pop up an error message. (2) additionally try to implement basic PS printing support with images, as described above. I could give it a try... (3) use full PS support with the Fl_Device approach. My current opinion is that we could do (1) and probably (2) for FLTK 1.3, but do (3) later in FLTK 1.4 / 3.0 or whatever version this will be. BTW: IIRC, using the Fl_Device approach has been discussed already and would also help to separate the OS dependent functions in a cleaner way. Thus, this would be a point an the roadmap anyway. Opinions, better ideas, implementations welcome ... For testing the current implementation, please check out the Fl_Printing subversion development branch at [3]. BTW: this is all due to the great work of Manolo. BIG THANKS ! Albrecht ------------------------------------------------------------------------ [1] <http://phy19.phy.tcd.ie/fltk/Fl_Device/fltk-1.1.4-Fl_Device.tar.gz> [2] < http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3-Fl_Printer/test/device.cxx> [3] <http://svn.easysw.com/public/fltk/fltk/branches/branch-1.3-Fl_Printer> [4] see STR #2310: <http://www.fltk.org/str.php?L2310> _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
