Hello,
I am working on a Launch Daemon (part of a DLP). One of its requirements is to modify PDF files on the fly—specifically, to reduce the page count and truncate the document to meet specific size criteria. I am planning to use the CoreGraphics framework, specifically CGPDFDocumentRef, CGPDFPageRef, and CGDataConsumerRef to rebuild the document in memory and write the modified version. However, since CoreGraphics is historically tied to the graphic subsystem, could you please confirm if the specific PDF-handling subset of CoreGraphics (CGPDFDocument, CGPDFContext) is completely session-independent, memory-safe, and daemon-safe to use from a launch daemon context without any Aqua session?
If using CoreGraphics in this context is discouraged, what are the recommended best practices or native alternatives for performing headless PDF modifications within a system daemon on modern macOS?
Thank you in advance!
I expect that this will work, but I can’t do this:
could you please confirm if the specific PDF-handling subset of CoreGraphics … is completely session-independent, memory-safe, and daemon-safe … ?
The problem here is one of layering. Because these APIs exist within Core Graphics it easy for them to become accidentally bound to the window server [1]. So, even if that’s not the case right now, it’s hard for us to guarantee that the implementation won’t change in the future.
But there’s a trade-off here. There is no lower-level PDF API, so the alternatives are to use CG or bring your own PDF library. Unless your product already has such a thing, the latter will add a constant maintenance burden. So, you have to trade off between that and the potential risk of an urgent, and complex, update if CG breaks on you.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] PDF seems like a simple thing, but it’s not. Most notably, it touches fonts, and those are never simple.