On 25.03.2010, at 16:33, manolo gouy wrote: > I have reorganized the new Fl_Device and Fl_Abstract_Printer classes > and their subclasses so that the code is compilable without > print support. I believe this is good in itself, and possibly also > for embedded devices.
Sure, that's good. > I wonder whether the introduction of print support could be a concern > for the use of FLTK in restricted environments and see 3 possibilities: > > 1. Make no change (Fl_Abstract_Printer and subclasses in libfltk) + 0.8 > 2. Move these classes to libfltkimages - 1 > 3. Create a libfltkprint for print support classes + 0.2 > Any comments ? If it can be compiled (and linked) w/o print support, this is IMHO good enough for now. I don't work with any embedded devices, but I assume that embedded devices would use static linking for their applications. If this is correct, then we don't need to bother making another lib (for that reason). However, if my assumption is wrong, then it might be useful to create a different lib for printing support. This one would obviously depend on libfltkimages (for image printing functions), but image support would not necessarily also need printing. The conclusion is to have both parts in different libs, so that someone who needs images but no printing can use a shared lib w/o printing support. So far my comments. Can you estimate how big (in KB) the printing functions (lib) would be? Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
