Created attachment 63925 [details] [review] Solves the lab problem with indexed deviceN images Because You marked bug 51548 as fixed, I open now a new bug for a patch which solves the problem with DeviceN images with alternate Lab colorspace in level 3 PostScript. After my discussion with the ghostscript guys (s. http://bugs.ghostscript.com/show_bug.cgi?id=693163) I was able to solve that problem, too. As a testcase You can use the samples of the freely available patches from the Ghent PDF workgroup, 08_DeviceN patches, creating the output with pdftops and option level3 or level3sep. BTW, when examine the output of these samples I encountered that also filling with DeviceN colors is not correct with level3 or level3sep option (not the images, I mean the square ahead "Spot color gradient"): even if the DeviceN colorspace is written in the PostScript output, the filling is done with setcmykcolor and therefore looses the correct (spot) color information and cannot be correctly separated. You can see that only when You rip it in a CMYK colorspace with ghostscript, i.e. -dDEVICE=tiffcmyk. Then You'll get an X instead of the correct check mark. But this is another problem and therefore I'll open an additional bug after I be able to solve that.
This changes the codepage for level2, too, no? Is that right?
(In reply to comment #1) > This changes the codepage for level2, too, no? Is that right? No, definitely no changes for level2 (and I also tested that before uploading the patch). There are two changes in this code a) change DecodeABC and RangeABC for csLab, but only if level is level3 or level3Sep b) change tintTransfomFunc but also only if level is level3 or level3Sep
Just to be sure (sorry for being stubborn), does it mean that "map01 && deviceNCS->getAlt()->getMode() == csLab" is only true in level3?
(In reply to comment #3) > Just to be sure (sorry for being stubborn), does it mean that "map01 && > deviceNCS->getAlt()->getMode() == csLab" is only true in level3? Seems as if You speak about line 6519. If so, please have a look at line 6509: You reach line 6519 only if (level == psLevel3 || level == psLevel3Sep).
bah, can't read, sorry you are right as usual
Can you have a look at the output of md5sum altona_technical_1v2_x3.pdf c524ab2cd02240b12eab3ee9f8887a9f altona_technical_1v2_x3.pdf It seems that when run on --level3 there is some black boxes in the new version while it "works" in the old version. That if we trust gs, of course
(In reply to comment #6) > Can you have a look at the output of > md5sum altona_technical_1v2_x3.pdf > c524ab2cd02240b12eab3ee9f8887a9f altona_technical_1v2_x3.pdf > > It seems that when run on --level3 there is some black boxes in the new version > while it "works" in the old version. That if we trust gs, of course You mean the black boxes on W4 or W5? Here the output with acrobat X is okay, so let me see why once again ghostscript means to show something different. And I can also see difference between acrobat reader on column C5 or C11, but that also appears either in level2 or using acrobat X, so that could be another problem... I'll come back after having a deeper look into it (and reduce the PDF objects with acrobat X first, it's nearly impossible to look into it in detail, my dual core laptop got 100 % CPU usage over minutes).
(In reply to comment #7) > You mean the black boxes on W4 or W5? Here the output with acrobat X is okay, > so let me see why once again ghostscript means to show something different. And I was able to repair it without loosing the enhancements of this patch. > I can also see difference between acrobat reader on column C5 or C11, but that > also appears either in level2 or using acrobat X, so that could be another > problem... I'll have a look into that later, so if the patch is okay for You, too, close this bug, please.
Created attachment 64183 [details] [review] Repairs the altona output
Commited
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.