Bug 691131

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