There are a few files that are still producing errors with the current icc_work branch (r10783): Never finishes: gs -o test.pdf -sDEVICE=pdfwrite -r72 ./tests_private/comparefiles/Bug689189.pdf gs -o test.ppm -sDEVICE=ppmraw -r72 ./test.pdf /typecheck in run: gs -o test.pdf -sDEVICE=pdfwrite -r72 ./tests_private/comparefiles/Bug690164.ps gs -o test.ppm -sDEVICE=ppmraw -r72 ./test.pdf /typecheck in run: gs -o test.pdf -sDEVICE=pdfwrite -r72 ./tests_private/ps/ps3cet/15-05.PS gs -o test.ppm -sDEVICE=ppmraw -r72 ./test.pdf seg fault: gs -o test.pbm -sDEVICE=pbmraw -r72 -dJOBSERVER ./tests_private/pdf/PDFIA1.7_SUBSET/CATX4373.pdf seg fault: gs -o test.pbm -sDEVICE=pbmraw -r72 -dJOBSERVER ./tests_private/pdf/PDFIA1.7_SUBSET/IA3Z0070.pdf
The rendering of fonts when viewing via the x11cmyk{,2,4,8} devices is often corrupted. That corruption is worse when using the icc_work branch than it is with 8.71, especially when using -dUseCIEColor.
regarding issues with x11cmyk{,2,4,8}, care to provide some screenshots? It might be useful to look at x11cmyk in combination with Bug 690998 (icc_work branch also shows more problem at color depth 15/16 with x11 than trunk, vs depth 24).
In the following attachments, the filenames start with 871 for 8.71 or icc for the icc_work branch; those done with UseCIEColor have cie in the filename; r100 is for -r100 and the last component is the DEVICE, with "x11" elided. The corruption happens for all text when the resolution is in [77,106] dpi. Outside of that range it renders OK. The colours are all off for the 2bit and 4bit devices; it looks like the dithering is wrong. In the 2bit case, if you render tiger the orange is dithered with black rather than with white; perhaps the polarity is wrong? In the 4bit case, the dithering results in mostly just black; sometimes a single splash of colour will show up, such as the center line of tiger's tongue or a bit of darker orange just over its nose.
Created attachment 6003 [details] 871_cie_r100_cmyk.png
Created attachment 6004 [details] 871_cie_r100_cmyk2.png
Created attachment 6005 [details] 871_cie_r100_cmyk4.png
Created attachment 6006 [details] 871_cie_r100_cmyk8.png
Created attachment 6007 [details] 871_r100_cmyk.png
Created attachment 6008 [details] 871_r100_cmyk2.png
Created attachment 6009 [details] 871_r100_cmyk4.png
Created attachment 6010 [details] 871_r100_cmyk8.png
Created attachment 6011 [details] icc_cie_r100_cmyk.png
Created attachment 6012 [details] icc_cie_r100_cmyk2.png
Created attachment 6013 [details] icc_cie_r100_cmyk4.png
Created attachment 6014 [details] icc_cie_r100_cmyk8.png
Created attachment 6015 [details] icc_r100_cmyk2.png
Created attachment 6016 [details] icc_r100_cmyk4.png
Created attachment 6017 [details] icc_r100_cmyk8.png
I forgot to mention that the icc_work gs will only look for the iccprofiles directory in $CWD and %rom%. It does not search in $gsdatadir or any of the directoried in $GS_LIB or $GS_LIB_DEFAULT. Nor does make install install them anywhere. This is understandable presuming Mike uses %rom% or always runs tests from the root dir of a checkout, but use of %rom% is not common on Linux or BSD distro builds and I doubt that I am unusual in also not using it for test builds. Also, here is the ps I used for the screenshots: %! /Times-Bold findfont 24 scalefont setfont gsave 2 60 translate 0 0 moveto 0 1 1 0 setcmykcolor (Red) show 54 0 translate 0 0 moveto 1 0 1 0 setcmykcolor (Green) show 72 0 translate 0 0 moveto 1 1 0 0 setcmykcolor (Blue) show grestore gsave 2 36 translate 0 0 moveto 1 0 0 0 setcmykcolor (Cyan) show 60 0 translate 0 0 moveto 0 1 0 0 setcmykcolor (Magenta) show 96 0 translate 0 0 moveto 0 0 1 0 setcmykcolor (Yellow) show grestore gsave 2 6 translate 0 0 moveto 0 0 0 0.1 setcmykcolor ('White') show 96 0 translate 0 0 moveto 0 0 0 1 setcmykcolor (Black) show grestore showpage based on examples/colorcir.ps. Interestingly, using x11cmyk{,8} to view pdf or ps output from cairo from printing a filled-out pdf from evince does not show the anomolies that the ps above does. At least not at 96 or 100 dpi. x11cmyk{2,4} still have problems dithering. Oh, and if I change that PS above to use 36 pt Times-Bold instead of 24 pt the corruption also vanishes. So the bug I see is not just dpi dependent, but font px/em dependent. Further testing shows that using a type1 font found by name in the Resource/Font directory rather than via Fontmap can change the colours if UseCIEColor is set (at least after today’s commits).
James Cloos, Please provide the source document that created these, or better yet re-run since there have been many changes since the icc branch has been merged into the trunk.
Created attachment 6409 [details] This is based on colorcir.ps, using cmyk colours, excluding the cicles This is the ps file I used to generate those PNGs. It is based on examples/colorcir.ps; rendering just the coloured names, but using setcmykcolor instead of setrgbcolor. At one point, the icc branch was slow enought that I could see, when rendering cmykcolorcir.ps (colorcir.ps with setrgbcolor calls changed to setcmyk calls), that the text was rendered OK at first, and only messed up later. It’ll be a few hours before I can test out the current trunk with these. I’ll be able to try it out on both 32bit and 64bit when I do.
I was able to get to it sooner than I had thought. At least for the 64 bit box. The bug is still there in trunk. Given its age, it may be specific to how the x11cmyk device uses its framebuffer? Also, it could not find the iccprofiles dir no matter where I installed it under $prefix/share/ghostscript. I tried each of these: $prefix/share/ghostscript/iccprofiles $prefix/share/ghostscript/8.72/iccprofiles $prefix/share/ghostscript/8.72/Resources/iccprofiles ./iccprofiles It used to work in $prefix/share/ghostscript/8.72/iccprofiles and ./iccprofiles before the merge. I had to link the icc files themselves into $PWD in order to UseCIEColor, so the --disable-compile-inits case remains kaputt.
And here is an example command line: :; for ij in $(seq 50 110);do icon "dpi=${ij}"; /opt/iccgs/bin/gs -r${ij} -g$[ij * 3]x$[ij * 5 / 4 + 1] -dBATCH -sDEVICE=x11cmyk -dUseCIEColor cmyknames.ps ; done The corruption shows up at -r lower than 107. It takes about 800 dpi or more clearly to see the halftone which the x11cmyk device tries to use. At 300 dpi you can see how that halftone is "squeezed". My guess is that at below 108 dpi it get fuddled beyond recognition. (It took me a bit today to fully remember the details.)
I just noticed that the rendering bug also shows up when using the x11mono device. The threshold is the same: <107 dpi fails, >=107 dpi is OK. I think that confirms that the bug is due to how halftones are done.
The image corruption shown in my screenshots above is gone (I tested gs-9.02 and yesterday’s ghostpdl-master). Using the x11cmyk device, though, master does not halftone the text the way gs used to; that may be why the corruption no longer occurs.
The problems listed in the Comment #0 no longer occur with head (9b9d97a5a2c299595048c72fa10e1a2b2845ff58) and so I'm closing this bug. If there are any issues remaining with the cmyk output as listed in comments #1 through #24 please open an independent bug (as should have been done in the first place). (In reply to comment #0) > There are a few files that are still producing errors with the current icc_work > branch (r10783): > > Never finishes: > gs -o test.pdf -sDEVICE=pdfwrite -r72 ./tests_private/comparefiles/Bug689189.pdf > gs -o test.ppm -sDEVICE=ppmraw -r72 ./test.pdf > > /typecheck in run: > gs -o test.pdf -sDEVICE=pdfwrite -r72 ./tests_private/comparefiles/Bug690164.ps > gs -o test.ppm -sDEVICE=ppmraw -r72 ./test.pdf > > /typecheck in run: > gs -o test.pdf -sDEVICE=pdfwrite -r72 ./tests_private/ps/ps3cet/15-05.PS > gs -o test.ppm -sDEVICE=ppmraw -r72 ./test.pdf > > seg fault: > gs -o test.pbm -sDEVICE=pbmraw -r72 -dJOBSERVER > ./tests_private/pdf/PDFIA1.7_SUBSET/CATX4373.pdf > > seg fault: > gs -o test.pbm -sDEVICE=pbmraw -r72 -dJOBSERVER > ./tests_private/pdf/PDFIA1.7_SUBSET/IA3Z0070.pdf