See e.g.: http://code.google.com/p/sumatrapdf/issues/detail?id=411 http://code.google.com/p/sumatrapdf/issues/detail?id=560 http://code.google.com/p/sumatrapdf/issues/detail?id=567 Could this be related to the ICC profile not being respected?
Created attachment 5740 [details] minimal testcase Adobe Reader doesn't render "/DefaultCMYK cs 1 0 0 0 scn" the same as "/DefaultRGB cs 0 1 1 scn". The latter appears as expected while the former seems to be transformed (gamma corrected?) during the CMYK-to-RGB conversion. This is at least the issue from http://code.google.com/p/sumatrapdf/issues/detail?id=756 and quite likely from some of the other reports as well.
Our default color conversion from CMYK to RGB is the very simple and fast but very inaccurate algoritm from the PDF spec. We also ignore ICC colorspaces. The plan is to use lcms for color management.
Note that there is no "standard" CMYK colorspace. Adobe Acrobat Reader uses (AFAIK) US SWOP Web Coated conversion when colors are CMYK. What is "correct" is a matter of opinion unless one specifies the CMYK to device independent (CIE XYZ) color conversion using a PostScript ColorSpace array (as Ghostscript currently uses) or an ICC profile. While this is reported against MuPDF, Ghostscript allows for the "DefaultCMYK" colorspace to be specified and allows for an (almost identical) match to Adobe Acrobat Reader. This is actually a request to enhance MuPDF to add color conversion capability similar to Ghostscript. Note that any enhancement should take into account all of the design that is part of the Ghostscript ICC based color management since there are MANY issues beyond CMYK colors affecting correct colors and the transparency blending.
*** Bug 691632 has been marked as a duplicate of this bug. ***
*** Bug 692063 has been marked as a duplicate of this bug. ***
*** Bug 694445 has been marked as a duplicate of this bug. ***
What is the status of this bug? If I want to "upvote" this problem with my customer id (200), should I then create a new duplicate of this bug and set the Customer field on that, or can I edit the current bug?
(In reply to Michael Toftdal from comment #7) > What is the status of this bug? We have already improved the CMYK conversion that is used. We do not yet have a color managed workflow, though this is on our roadmap. I cannot give you a completion date for this though. > If I want to "upvote" this problem with my customer id (200), should I then > create a new duplicate of this bug and set the Customer field on that, or > can I edit the current bug? It would probably be worth opening a new bug, and attaching example files etc to that. Often what appears to be the same problem on the surface can have different underlying causes, and it would be bad for us to spend time solving what we think is your problem only to discover that it was something else.
LCMS2 color management was introduced in dd58ea5e2ff7e6b61cc5a5b6fd950fb62e92b8be I have checked the output of the attached file as well as the documents mentioned in sumatrapdf bugs 411, 560, 567, 662, 820 and 875 which are directly or indirectly referenced in this bug report. The rendering now looks similar to that of Acrobat Reader.
So I missed to copy the initial character of the commit id, the proper is dd58ea5e2ff7e6b61cc5a5b6fd950fb62e92b8be.