[Poppler-bugs] [Bug 34053] Poppler ignores rendering intents and always uses INTENT_RELATIVE_COLORIMETRIC

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34053

Thomas Freitag <Thomas.Freitag at alfa.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #43180|0                           |1
        is obsolete|                            |

--- Comment #12 from Thomas Freitag <Thomas.Freitag at alfa.de> ---
Created attachment 83659
  --> https://bugs.freedesktop.org/attachment.cgi?id=83659&action=edit
use icc profile in OutputIntents if possible

You were already quite close to a solution, Albert. There is just one main
difference in my patch: it tries to use the icc profile in OutputIntents, if
possible, and that solves it.
If You look at the patch and compare it with Yours, You'll see that the most
other changes come due to the fact that You change the colorspace caching from
gfx to outputdevice in the meantime, but to keep Your patch running we at least
need the state to get the current rendering intent.
Another small change is in caching: because the transformation depends now on
the current rendering intent, a cached icc based colorspace can not be used if
the rendering intent changed in the meantime. But that was just missing in Your
patch.
And as I already told on the mailing list: to see differences in the altona pdf
(and much easier to see in the GWG 7er series), You have to render in CMYK
(because the profile in OutputIntents is a CMYK profile). Therefore You need to
compile with the SPLASH_CMYK directive and can't use the -png-format parameter,
use -jpegcmyk instead as pdftoppm parameter.

Two open points in my opinion: 
1. Because the display profile now depends on the PDF, we can't use a static
variable for it anymore. It will not make any difference if just one
apllication uses the poppler library at the same time, and so I would prefer to
solve that in a second step (store the display profile in the doc instance and
use the static as default).
2. We have now the second case where we definitely need the library compiled
with SPLASH_CMYK (the other is the overprint usage). Shouldn't we make
SPLASH_CMYK defined by default, and perhaps remove it completely in an
additional step? I know that the library become bigger in size, but is this
really such important?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20130805/f1c0b06a/attachment-0001.html>