Or most likely, create the various intents on the fly and cache them. Recreating each time you encounter them will have performance penalties (since creation of a transform is fairly heavyweight).
Leonard -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Koji Otani Sent: Monday, May 18, 2009 5:12 AM To: [email protected] Cc: [email protected] Subject: Re: [poppler] Testing color management functionality From: "Hal V. Engel" <[email protected]> Subject: Re: [poppler] Testing color management functionality Date: Fri, 15 May 2009 18:11:33 -0700 Message-ID: <[email protected]> hvengel> > hvengel> > Poppler doesn't support overprinting, so #27 and #28 fail. hvengel> > I'm not sure poppler support spot color. hvengel> hvengel> It appears that it does not. hvengel> hvengel> > hvengel> > Colors of vector regions are same as those of pixel regions in #34-#38. hvengel> hvengel> I am sorry I got this wrong. When looking more closely at the documentation hvengel> on the altona site it appears that the differences I am seeing in #34 are not hvengel> vector vs. pixel but rather DeviceCMYK vs. ECI-RGB. The altona documentation hvengel> says: hvengel> hvengel> "Under no circumstances shall a distinct color difference be visible per color hvengel> mode between vector and pixel elements. A subtle color difference between hvengel> the elements of different color modes is acceptable. As a consequence, along hvengel> the virtual line between ECI-RGB and DeviceCMYK (from upper left to lower hvengel> right corner), a subtle color difference may be visible. Color differences hvengel> between elements – vector versus pixel – within the same color mode indicate hvengel> that vector and pixel elements are treated differently" hvengel> hvengel> The difference I am seeing is very pronounced and not at all subtle and is hvengel> along the virtual line between ECI-RGB and DeviceCMYK. I do not see any hvengel> difference between the vector and pixel elements in the same color mode. So hvengel> this indicates a problem with how DeviceCMYK is handled and perhaps other hvengel> Device* color spaces. hvengel> hvengel> Looking at the PDF specification I see that it is possible for the the hvengel> dictionary for a Device* object to have a default color space specified. I hvengel> don't know if the altona document has this but looking at the code it is clear hvengel> that no attempt is made to get or use the default color space for the Device* hvengel> objects. If it is in the document it should be used any time the Device* hvengel> color space is not a match with the output device color space. hvengel> I see. Color management code which I added doesn't touch Device* color spaces. hvengel> #35 I can see a slight difference between the CIELab and ECI_RGB sections. hvengel> Looking at the code it was not doing the white point correction to the XYZ hvengel> values after the calll to getXYZ() in GfxLabColorSpace::getRGB. Fixing that hvengel> corrected the problem. While looking at this I discovered that in hvengel> GfxLabColorSpace::getGray() it had the same problem. I will create a patch hvengel> with this set if fixes. hvengel> hvengel> #36, #37 and #38 do not show any of the difference from changes to rendering hvengel> intent that should be there. hvengel> hvengel> Looking at the code it is always using INTENT_RELATIVE_COLORIMETRIC and there hvengel> is no attempt to get the Intent from the dictionary in hvengel> GfxICCBasedColorSpace::parse(). So the code is not parsing out the intent and hvengel> using that to create the transforms. I had a look at the code but I was not hvengel> able to get the Intent from the dictionary since I am not at all familiar with hvengel> the code base. Perhaps someone who understands how the dictionary stuff hvengel> works could take a look at adding this to GfxICCBasedColorSpace::parse(). hvengel> As Leonard said INTENT can come from several places, it's not so simple to handle INTENT correctly. We have to check if current INTENT is changed and recreate transform if needed. This is why I didn't support INTENT this time. _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
