How should OS X paint programs save user data in their PasteBoard PDF insert?

Question

A bit of history. In those days when the outstanding Mac vector clipboard was PICT, the program could paste its own data into PICT. PICT can be inserted into another application. At some later date, the same drawing could be selected and put on the clipboard and pasted back into the original program. The source program will retrieve its user data and restore the original selection for live editing.

Today, the dominant vector buffer buffer is PDF, which is an excellent format, but Apple does not provide any means to place one user information in PDF using Apple PDF APIs. (If I'm wrong, let me know.) Only standard lines, such as title, author, etc. And it seems that new applications often do not bother to return the original image to the clipboard if the choice consists solely of the original. In addition, applications such as Word save the first page of pasted PDF files.

Is there anything I can do today to get a “shared journey” from my application to another application? If it was the perfect solution to support Apple and other applications? Must it look like PICT and be a standard custom blob embedded in PDF, or should there be a separate type of vendor circuit board that applications store in parallel with visible graphics? If the first, should you keep the blob at the document or page level? I would prefer not to try to hack anything, how to hammer XML in the author field.

Answer 1

It seems that there is a new API that will be available in 10.7 (and already available on iOS), which allows you to include arbitrary (XML-based) metadata.

void CGPDFContextAddDocumentMetadata (CGContextRef context, CFDataRef metadata) CG_AVAILABLE_STARTING(__MAC_10_7, __IPHONE_4_0); 

This will insert a compressed metadata stream referenced by the Root dictionary. All I have to do is call the API, which magically appeared in the header file CGPDFContext.h. Obviously, this does not help me support OS X versions up to 10.7, but it seems like a long-term solution, and at the same time, we can crack the PDF to fit that.

Here's a blog post that I wrote on this subject.

Answer 2

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

Reference

Code example

-W

Answer 3

Is there any reason why everything that your application needs cannot be expressed in PDF format and hidden? Despite the fact that there are many complaints in the press about PDF problems, Apple has nothing to do with them, and the fact is that it is actually very nice to make beautiful pictures on both screens and papers.

What API are you looking at?

Answer 4

You need a higher level API. The low-level CGPDF ... API will probably be less useful to you than directly using Cocoa. (If you are not using Cocoa, help you.) You can do whatever you need using standard Cocoa PDF support, as well as separate drop-down lists in CoreGraphics to increase efficiency. (Cocoa is great, but sucks in a high-performance graphic drawing.)