> On 31.03.2010, at 18:54, manolo gouy wrote: > > > My existing code is only for MSWindows and Mac OS X. > > In essence, the system calls CreateEnhMetafile and CGPDFContextCreate > > of each system return a graphics context (fl_gc). With that, > > all graphics requests (all fl_XXX() functions) write to an in-memory > > object that can be put on the clipboard at the end. > > okay, thanks for the explanation. > > > The new class Fl_Clipboard_Writer would have essentially a start() > > and a stop() member functions, and graphics requests made in > > between would go to the clipboard. These could be a > > print_widget() call or a series of fl_XXX() calls decided by > > the programmer. > > > > Because these graphics context are generic objects, both vector > > graphics (say, fl_xyline() or fl_draw()) and images can be written > > to them and pasted to the recipient application without distinction. > > With the caveat for Mac OS to fill the pasteboards with two > > so-called flavors of the same data: one in PDF, one in an image > > format[...] > > But don't we need two formats for Windows, too? A receiver who can > only receive image (bitmap) formats wouldn't be able to read the > metafile format. As I wrote before, I looked at the MS docs [1], and > only the two meta file formats can be converted automatically [2], > thus at least one bitmap format should be provided as well ? > > Albrecht
I have used this functionality for line drawings only, and have found that all receiving applications I tested were happy with a metafile-loaded clipboard. For instance, Paint receives this clipboard even if it transforms it in an image. But I may be wrong, there may be applications that want only a bitmap. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
