How Should an OS X Drawing Programs Store Custom Data in its PDF PasteBoard Flavor?

Question

A little history. In the days when the pre-eminent Mac vectored clipboard flavor was PICT, a program could insert its own data into the PICT. The PICT could be pasted into another application. At some later date, the same drawing could be selected and put on the clipboard, and pasted back into the originating program. The originating program would extract its custom data and regenerate the original selection for live editing.

These days, the dominant vectored clipboard flavor is PDF, which is a fine format, but Apple does not provide any means to put one's custom data into a PDF using Apple's PDF generating APIs. (If I'm wrong about this, please let me know.) Just standard strings like the title, author, etc. And it seems that new applications often do not bother to put the original graphic back on the clipboard if the selection consists solely of the original. Also, applications like Word only keep the first page of pasted PDFs.

Is there any thing I can do today to get "round trip" editing from my app to an arbitrary other app? Baring this, what would be the ideal solution for Apple and other apps to support? Should it be like PICT and be a standard custom vendor blob embedded in PDF, or should there be a separate vendor pasteboard type that apps keep in parallel with the visible graphic? If the former, should the blob be kept at the document or page level? I would prefer not to try anything hacky, like jamming XML into the author field.

Answer 1

Is there any reason why whatever it is your application needs to draw cannot be expressed in PDF format and hidden? While there are plenty of complaints about PDF's irksome limitations in the pre-press industry, Apple has nothing to do with them, and the fact of the matter is that it's really pretty good at making pretty pictures appear on both screens and pieces of paper.

Which API are you looking at?

Answer 2

Another hack would be to use the PDFKit to add annotations with your extra data in them -- I'm not sure if those would be copied/pasted correctly by target programs, but it's worth a try.

Reference

Example Code

-W

Answer 3

You need a higher level API. The low-level CGPDF... API probably will be less useful to you than directly using Cocoa. (If you're not using Cocoa, God help you.) You can do everything you need to do by using the standard PDF support in Cocoa, plus selected drop-downs into CoreGraphics directly for efficiency. (Cocoa is great, but sucks at highly efficient graphics drawing.)