This is another long-standing Bad Bug. It’s clearly broken, easy to demonstrate, and difficult to believe it would be allowed to persist. I realize that in writing about these, I open myself to criticism along the same lines. In a way, I welcome it. Maybe we’ve got a Bad Bug in our software that’s getting in your way. If so, blog about it passionately. Rally others to your cause. Write us and insist we take a second look.
Bad Bug #2 is in Core Graphics. Both renderings below are of the same PDF document. On the left, the document is rendered using PDFKit. On the right, the document is rendered using CoreGraphics.
I filed this bug with Apple at OS X 10.11.1, and there have been three dot releases with no fix. While it’s possible to work around the bug by drawing into an NSView rather than using Core Graphics, that’s not really an acceptable workaround. It’s also difficult to detect exactly what causes the bug, as it does not impact all CMYK nor all overprint mode (OPM) documents. In other words, trying to work around this would create a huge performance hit.
Fortunately, the bug is “cosmetic” in nature, meaning that although the colors are presented incorrectly to the user when a PDF is drawn using Core Graphics, the underlying colors are correct when viewed in other PDF applications. This isn’t much solace to us and PDFpen, but it is much better than the alternatives.
Please feel free to reproduce and file duplicate bug reports, and we’ll keep our fingers crossed that this is addressed in macOS Sierra.
UPDATE (July 18, 2016):
Turns out, the bug is limited to PDFs with transparency layers.
The workaround is to wrap the drawing in begin / end transparency layer calls:
CGContextRef context = (CGContextRef)[[NSGraphicsContext currentContext] graphicsPort]; CGContextBeginTransparencyLayer(context, NULL); CGContextDrawPDFPage(context, page); CGContextEndTransparencyLayer(context);
Keeping my fingers crossed it gets fixed in macOS Sierra.