Created attachment 14361 [details] Example of incorrect rendering It seems that poppler is incorrectly rendering CMYK colors. Specifically, the attachment is a picture of a cyan (1,0,0,0) filled color which should convert to RGB (0,1,1) but is being converted incorrectly to (0,0.67,0.93). The file GfxState.cc seems to be the culprit. I changed this file by editing the function to contain (sorry but I don't know how to write patches) void GfxDeviceCMYKColorSpace::getRGB(GfxColor *color, GfxRGB *rgb) { double c, m, y, k, k1, r, g, b; c = colToDbl(color->c[0]); m = colToDbl(color->c[1]); y = colToDbl(color->c[2]); k = colToDbl(color->c[3]); k1 = 1 - k; r = (1-c)*k1; g = (1-m)*k1; b = (1-y)*k1; rgb->r = clip01(dblToCol(r)); rgb->g = clip01(dblToCol(g)); rgb->b = clip01(dblToCol(b)); } After changing this function to this, everything seems to work as normal.
Created attachment 14362 [details] [review] Patch for repairing the CMYK to RGB conversion.
My code wasn't quite up to PDF specifications. I have modified my code (to account for this specification) and have learned how to create patches ;). See attachment for the patch. Troy
I opened your sample PDF in Poppler, Ghostscript, and Adobe Reader and compared the color. The results are: Viewer RGB (on a 0-255 scale) ------------------------------------ Poppler (0, 173, 239) Adobe Reader (0, 174, 239) Ghostscript (0, 255, 255) The Poppler results closely match Adobe Reader. Adobe Reader implements color management which gives much better results than a simple (1-c) conversion. I don't know the specifics of what Adobe Reader is doing and the Poppler code for doing the CMYK to RGB conversion has no useful comments. However it is clear that Poppler is doing the same thing as Adobe Reader (for this one color at least).
If you browse to: http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/ghostscript/trunk/gs/Resource/ColorSpace/ you can look at the default colorspace transforms used by current GhostScript. In specific, look at http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/ghostscript/trunk/gs/Resource/ColorSpace/DefaultCMYK where you see the matrix used to emulate what Adobe Reader does. Especially look at the comments to checkin 5401 (from 2004/October), where they mention that the intent is to show what the colours will look like when printed. Clearly xpdf tries to emulate the look of acrobat reader, hense the colour space conversion in GfxState.cc. Poppler probably should support both conversions, preferably with a generic colour space matrix just like GhostScript and other RIPs do.
Well, the problem seems to be that neither Adobe nor Poppler is rendering this particular PDF correctly (even though their renderings are essentially the same). It seems that Adobe isn't following its own PDF Reference at http://www.adobe.com/devnet/pdf/pdfs/PDFReference.pdf since its rendering (for this color) is bad. Section 6.2.4 on page 380 of this document shows the conversion formula for which the patch that I provided implements. So it seems that something is not consistent here. Is Adobe's formula wrong? It seems to be working properly for the patch I provided and the PDF I provided. Is Adobe incorrectly implementing its own formula? Is Adobe even using this formula? Is Adobe incorrectly implementing a formula similar to GhostScript? If this incorrect implementation is in fact what is happening, is Poppler making the same mistake as Adobe in its implementation (since their results seem to be virtually identical)? Is there something wrong with my provided PDF? It was generated from preview.eps which was generated using MetaPost, and it renders as expected in GSView and Evince (which both use GhostScript). It was converted to PDF using GhostScript (namely `epstopdf'). Has this conversion changed the colors? Thoughts?
I asked Leonard Rosenthal (from Adobe) about this: Color - what fun ;). As you know, Poppler/Xpdf uses an explicit algorithm (sometimes called the "Red book" algorithm, since it comes from the Postscript Red Book) to convert among the various DeviceXXX color spaces. However Acrobat and Reader are fully color managed applications, which means that they ALWAYS associate ICC profiles with DeviceXXX colors and use a CMM to convert colors as necessary. Reader users, however, get a "fixed set" of profiles while Acrobat users are able to change theirs (Preferences->Color management) - so there are times where even Acrobat and Reader display different colors when dealing with DeviceCMYK let alone our apps vs. Poppler/Xpdf. There is a second potential area involved which is a setting/preference available in Acrobat & Reader called "overprint preview" which changes the entire drawing model from a standard "screen" model to one that simulates "print". Due to how this works, it's also possible to see color shifts between the two when this preference is set. Finally, and I believe we've talked about this one before - transparency! When transparency is present in a PDF AND no "transparency page group" exists, the PDFRef says that the viewer is free to choose what space to use. Acrobat/Reader chooses CMYK while every other viewer sticks with RGB - thus in such PDFs you see a color shift between our viewers and others. I would LOVE to see someone add color management (using lcms) to Poppler/Xpdf!
Bottom line then ... what does this discussion say about displaying cyan as cyan, say? Does it mean that there should be "two" types of conversions, namely for print and screen? Troy
Should this bug depend on bug #17499 ?
Yeah, why not
Thoughtful analysis ! Speaking of which , if you is interested in merging of two PDF files , I discovered a service here <a href="http://www.altomerge.com/" >AltoMerge.com</a> and also here PDFfiller.com
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/41.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.