Hi, Brion Vibber <brion@xxxxxxxxx> writes: > Cocoa apps (those written with the NeXT-derived toolkit) use TIFF for > transferring raster images. Older apps (like Photoshop) tend to use > PICT, which is a metafile format encapsulating calls to the QuickDraw > drawing library. Using the Cocoa NSPasteboard interface, I can copy a > TIFF and it performs the conversion to PICT for me, but when pasting I > need to handle both formats. We use gdk-pixbuf to handle the clipboard image data. So far we only use the PNG format but it would be reasonable to extend this to the full range of formats supported by gdk-pixbuf. There's an API that we can use that allows us to retrieve the list of supported formats and the associated mime-types. There's a tiff loader in GTK+ but no way to save TIFF files. There doesn't seem to be support for PICT (except perhaps in a 3rd party pixbuf loader that I don't know about). So the best way to address this would probably be to write a PICT loader and either get it into GTK+ or bundle it with GIMP for MacOS X. > How is image cut-n-paste handled on Win32? Windows apps use DIB > (.bmp) format for clipboard transfer; does the GDK backend handle > DIB<->PNG conversion? I took a quick look around > gdkselection-win32.c & friends but didn't see anything obvious. It would not be the job of the backend to handle the format conversion. The backend only needs to expose the clipboard in a compatible manner (e.g. data with associated mime-types). It's the application's job to handle the actual clipboard data. Of course it would be nice if everyone could agree on using PNG but that's unfortunately not how it works. So in order to use the win32 clipboard we will need to support BMP support in gdk-pixbuf. This is there fortunately but it seems to be limited to reading. Sven
