On 7 Feb 2010, at 9:28, Albrecht Schlosser wrote: > > Anyway: the problem with using vector drawing, filling, etc. > with PostScript would be to redirect all drawing functions > to the PostScript device (driver) and to implement a full set > of drawing primitives, together with all that is needed to > hold the current device context (as far as needed). OTOH, > using Fl_Offscreen and writing the Fl_Offscreen as an image > to the PS device would probably be rather simple (see fluid), > because there are already mechanisms to switch to offscreen > drawing.
Still, if we can write the code to do the postscript rendering, it will produce *much* smaller files (and probably better looking output) than the Fl_Offscreen approach. A little while back a colleague and I wrote a bit of code that used Cairo to generate printer output (the client wanted PDF output specifically) and that worked OK. But to do that, we had written an application-specific intermediate layer that could generate either fltk or cairo output... So not really useful here. Actually worked OK, though if we enabled cairo for on-screen rendering it was noticeably slow on some hosts... Also, since the client was mainly targeting Macs, we found that the fltk/quartz output (anti-aliased automatically by the Apple rendering layer) actually looked as good or better than the cairo anti-aliased drawing anyway... So: Theoretically we could use cairo with its postscript back-end in the same way, for general fltk printer output - though that would introduce a dependency that I am not all that keen on. If someone had code that would allow us to generate PS output directly from fltk calls though.... well, that would be "handy". About 20-plus years ago, I wrote a PS to CGM "interpreter" for a display unit we had. On the basis of that work, I'm pretty sure I'm not the person to be writing a PS output engine... _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
