> manolo gouy wrote: > > > In Mac OS and MSWindows, the clipboard can be routinely used to > > transfer graphical data between applications, in addition to > > transferring text data. These OSes have a standard format for that. > > In MSWindows, it's metafile; in Mac OS it used to be PICT > > and is now PDF. > > I see, that means that you propose to put vector graphics to the > clipboard. That wasn't clear to me before. This would indeed need > another approach than copying an Fl_Offscreen to the clipboard. > > > The objective is to allow the user of an FLTK application to > > draw a graphics, to copy it and to paste it to applications > > such as PowerPoint, Word, Illustrator, OpenOffice that can read > > any graphics-loaded clipboard. > > With Mac OS, the clipboard is best loaded with the same graphics data > > in two forms, PDF, used by those applications that know how to > > handle vector graphics, and jpeg, for those, more numerous > > applications, that can only receive an image. > > I had a quick look at the Windows clipboard format docs. I can see > that the different (2) metafile formats are convertible, but we'd also > need an additional bitmap format to be complete, right? > > What does your existing code do, and/or what exactly would be your > intentions? > > Albrecht
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. 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 (I now have jpeg for that, but can see if png would be possible instead). Mac OS provides generic functions to create an image from PDF data, so these two flavors can be constructed starting from the data written to the graphics contexet. All of this is ready. Nothing is ready for the X11 platform. That's where the question mark is. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
