<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - pdftoppm doesn't render eci_altona-test-suite-v2_technical2_x4.pdf correctly" href="https://bugs.freedesktop.org/show_bug.cgi?id=68986#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - pdftoppm doesn't render eci_altona-test-suite-v2_technical2_x4.pdf correctly" href="https://bugs.freedesktop.org/show_bug.cgi?id=68986">bug 68986</a> from <a class="email" href="mailto:Thomas.Freitag@alfa.de" title="Thomas Freitag <Thomas.Freitag@alfa.de>"> Thomas Freitag</a> <pre>Created <a href="attachment.cgi?id=97471" name="attach_97471" title="output of test "P"">attachment 97471</a> <a href="attachment.cgi?id=97471&action=edit" title="output of test "P"">[details]</a> output of test "P" After a really long time I yet found to continue working on this bug. As You probably remember, the openjpeg community created a bugfix for our LAB image problem and announced it to be in version 2.1. Therefore I checked out this openjpeg beta release, compiled it and applies my patch based on Adrian's one of <a class="bz_bug_link bz_status_NEW " title="NEW --- - 0.22.0 does not find openjpeg-2.0.0" href="show_bug.cgi?id=58906">bug 58906</a>. Even if it renders now the LAB image, there are still big differences between the rendered output and the reference image, s attachment. Therefore I looked into the technical parameters of test "P' (s. <a href="http://www.eci.org/_media/de/eci_altona-test-suite-v2_technical2_documentation_eng-4.pdf">http://www.eci.org/_media/de/eci_altona-test-suite-v2_technical2_documentation_eng-4.pdf</a>), and I wondered that they speak nearly about avery image of a image with ICC profile, but the PDF contains nearly always only images with DeviceXXXX colorspace, but and that's funny, the dictionaries have a Intent member. Therefore I looked into the PDF specification again and found the following interesting statement in section 8.6.5.6: When a device colour space is selected, the ColorSpace subdictionary of the current resource dictionary (see 7.8.3, "Resource Dictionaries") is checked for the presence of an entry designating a corresponding default colour space (DefaultGray, DefaultRGB, or DefaultCMYK, corresponding to DeviceGray, DeviceRGB, or DeviceCMYK, respectively). If such an entry is present, its value shall be used as the colour space for the operation currently being performed. I'm quite sure that I already stumbled about this clue long time ago and fixed that, but I encountered that either this fix is lost or it was not complete. So I implemented this in a first try in Gfx::doImage() and, surprising, the regression was gone :-)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>