manolo gouy wrote: >> For complete PS >> output we would probably need full postscript device support, but that >> might be tricky and maybe only doable with FLTK's (planned) device >> separation - that might be far in the future(?). > > Can anybody give me a pointer to what is this "device separation" ?
There were thoughts to separate the OS-specific parts and the non-OS-specific parts, so that there could be one directory for each OS and related functions. Thus, the src/ directory would only contain non-OS-specific functions and call OS-specific functions through an extra layer, where appropriate. IIRC the primary idea is to be able to write only basic OS or device dependent drawing functions for porting to another OS or device (e.g. framebuffer). This could probably also be used to "switch" devices during runtime (such as the normal screen, [Fl_]Offscreen, [Fl_]Printer, and maybe [Fl_]PostScript, Cairo, ... or whatever. 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. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
