Bug 691883

Created attachment 7123 [details]
icc.nowts.ps

Created attachment 7124 [details]
xxx.ps

This is reproduced with HEAD (rev 12039) on Windows built with VS 2008.

We'd really like to dump wts in favor of Michael's new method of generating
halftone screens. Assigning to Michael so when the new halftone screen method
is ready, we can close this bug.

Hopefully we can implement the new method so that the following will still
work and generate an appropriate screen (extracted from the top of xxx.ps):

	<< /UseWTS true >> setuserparams 
	<<
	    /AccurateScreens true
	    /HalftoneType 1
	    /HalftoneName (Round Dot Screen) cvn
	    /SpotFunction { 180 mul cos exch 180 mul cos add 2 div}
	    /Frequency 137
	    /Angle 37
	>> sethalftone

I'd like to increase this by 1 step in importance, because gs can't process PDFs created for printing and archived for safekeeping. That probably prevents printing those files on Linux.

I had put more info here:
https://bugzilla.novell.com/show_bug.cgi?id=696814

The problem seems to be with gs 9 reading the PDF, because gs 9 also segfaults with a PDF created by gs 8.62 using -dUseCIEColor.

Can you attach the PDF that causes the segfault?

Created attachment 7703 [details]
Test PDF crashing ghostscript 9.

Sure, it's trivially created with basic tools, as I described in comment 4, including a short script to create the test file and to show the crash.

Crash confirmed on Windows debug build of origin/master (68bf978)

Fails with call stack:

gsicc_new_iccsmask(gs_memory_s * memory=0x504c1010)  Line 175 	

gsicc_initialize_iccsmask(gsicc_manager_s * icc_manager=0x01dce810)  Line 194

gs_begin_transparency_mask(gs_state_s * pgs=0x01dbe050, const 

gs_transparency_mask_params_s * ptmp=0x000ce500, const gs_rect_s * pbbox=0x000ce4d8, int mask_is_image=0x00000001)  Line 587

zbegintransparencymaskimage(gs_context_state_s * i_ctx_p=0x01dce970)  Line 324

When the icc_manager has a 'memory' pointer that is NULL (0x00000000)

Interestingly, the profiles that are initialized (such as default_gray) have
valid 'memory' pointers.

Assigning to Michael Vrhel, but someone else might be able to track this down
since it is so easily reproduced.

Please disregard -- comment was for another bug.

Latest:

$ gs904 -q -dBATCH -dSAFER -dQUIET -dNOPAUSE -sPAPERSIZE=letter -g10200x6600 -r1200x600 -sDEVICE=bitcmyk -dCOLORSCREEN -dMaxBitmap=500000000 -sOutputFile=xxx.bitcmyk     icc.nowts.ps  xxx.ps
Segmentation fault (core dumped)
$ 

In:

0x08479902 in wts_get_samples ()

We are going to drop all support for the 'WTS' stuff. Its "inventor" is no
longer available, and it doesn't work (generates bad screens) for enough
cases that we are dropping it in favor of Michael's new code that generates
ordered dither screen threshold arrays.

While the use of 'icc.nowts.ps' sort of implied that WTS was not being used,
the 'xxx.ps' is what turns on WTS mode.

Closing this as WONTFIX, since without the code in xxx.ps that turns on WTS,
the file runs fine.

The code I commented out at the top of xxx.ps was:
	<< /UseWTS true >> setuserparams 
	<<
	    /AccurateScreens true
	    /HalftoneType 1
	    /HalftoneName (Round Dot Screen) cvn
	    /SpotFunction { 180 mul cos exch 180 mul cos add 2 div}
	    /Frequency 137
	    /Angle 37
	>> sethalftone

Ray can you clarify please what bug you are talking about here?

Both the 2 .ps attached to this bug report run fine for me with gs 9.00, but the test PDF I attached crashes gs immediately.

Volker: I am answering Rick Richardson's original issue and responding to his
comment #11. Running the file you (Volker) submitted using:

gswin32c -r1200x600 -sDEVICE=bitcmyk -g10200x6600 -o x.cmyk test-gs.pdf

works fine.

Please open a separate bug if you have some options with this PDF that causes
current gs to crash.

If you are running gs with a 'prefix' .ps file that sets up WTS, then we will
not support it.

So, with 9.04:

$ gs904 -q -dBATCH -dSAFER -dQUIET -dNOPAUSE -sPAPERSIZE=letter \
    -g10200x6600 -r1200x600 -sDEVICE=bitcmyk -dCOLORSCREEN \
    -dMaxBitmap=500000000 -sOutputFile=tp-def.out \
    -sOutputICCProfile=/usr/share/foo2zjs/icm/CPWL12W.icm \
    $FILE

$ foo2zjs -r1200x600 -g10200x6600 -p1 -m1 -n1 -d1 -s7 -z3 -c \
    -u 192x2 -l 192x96 -T3 -J '' -U '' -B -A -D0 < tp-def.out > tp-def.prn

And the 9.0 OutputICCProfile needs to be CMYK instead of RGB?  And that's it???
No WTS crap? No icc2ps to convert to Color Rendering Dictionary (which was RGB in gs 5/6/7/8)?

Nice(?), but now I have to use my ColorMuki to prepare CMYK profiles for lots of printers.  magicolor 1600,2300,2430,2530, samsung clp-300/315/325, hp CP1025nw, etc...  It is a LOT of work!!!

Thanks Ray. I am not explicitly setting any prefix file beyond what gs runs with these commands:

echo "This resulting PDF will segfault ghostscript"
date >test-gs
enscript --media=A4 --output=- --mark-wrapped-lines=arrow --ps-level=1 \
 --font=Courier10 --baselineskip 1.0 --columns=1 --portrait --marg=50 \
 --header='test-gs|$D{%a %d-%h-%Y %T}|Page $% of $=         ' \
 --no-header --title=test-gs test-gs \
 > test-gs.ps
ps2pdf14 -sPAPERSIZE=a4 -dFIXEDMEDIA -dPDFSETTINGS=/printer \
 -dMaxSubsetPct=100 -dSubsetFonts=true -dEmbedAllFonts=true \
 -dCompressFonts=true -dUseCIEColor -dHaveTrueTypes=true \
 -dHaveTransparency=true \
 test-gs.ps
echo "(test-gs.pdf)run" | gs

Which to be honest I was just expecting to work, it has for the past umpteen years but it doesn't with gs 9.00.
Originally I reported that in
http://bugs.ghostscript.com/show_bug.cgi?id=692370
I can't say whether this has anything to do with this WTS. The above works again in gs 9.02, but if that (by any path) uses this WTS there will be a problem again. If it doesn't have anything to do with WTS problem solved (well for gs, not for Linux systems, they can't just upgrade gs).

Rick,

I am not sure if I am reading some sarcasm in comment 15.  Are you saying that earlier releases of ghostscript required less work to get good color? In a proper CRD work flow or ICC based work flow, you would need to characterize your printer.  In the past, you would do that by creating a CRD, which would require measurements with your ColorMuki.  Today, you do it with an ICC profile, which would require measurements with your ColorMuki or you can go and download the canned profile from the manufacturer.   

The old flow of mapping from source colors to sRGB via the internal CRD and then going to CMYK is far from optimal in terms of performance and color fidelity.

In gs 8.72 and before, I used the ColorMunki (and others) to profile the various printers via CRD. These were RGB profiles of 372 to 1000+ patches. WTS was used to dither them correctly because gs had a default dithering which was no good.  foo2zjs was used convert them from bitcmyk to the JBIG printer stream.  These were done from 2003 to 2011.  I have about 200,000 printers out there and running free linux, although some are B/W and some have been to put to rest.

Now I have to re-profile them with CYMK.  Obviously, this is a lot of work.

Richard,

It is possible to convert the CRD's that you had created to equivalent ICC profile's to use with 9.04 without making a single measurement.  However, I am a bit confused on how it is that you obtained CMYK values with what you described, unless you were creating RGB CRDs and letting GS do a generic conversion to CMYK.  If that is the case, then you could still readily create an equivalent CMYK profile from this complete mapping, hence avoiding any additional measurements, however the original mapping is certainly suboptimal and likely to suffer from gamut limitations.

Unfortunately, the printed color is dependent upon the halftone method that is used.  So due to the deprecation of WTS you would likely have issues if you were doing CRD's or ICC profiles.  

The reality of the situation is that we live in an ICC-based world.  The other reality is that we are developing a set of tools to create dithered ordered screens and also stochastic screens, which one can use to create screens specifically for a particular printer.  These screens will be applied in a very fast manner using SIMD operations in ghostscript.  In the long run, relying upon externally specified screens and ICC profiles is a good thing for you in that they will always work across a variety of devices and rendering engines and do not rely upon specialized code that can be deprecated or that is poorly supported.

Yes. Agreed, ICC is the way to go.  But this is what I got from a user:

wolf writes:

"The results were horrible. It seems ghostscript 9.04 did a lot of
damage to its colour correction code. After some playing with the gs
executable, I noticed the following.

‐ The type 1 halftone screen that foo2zjs‐wrapper and foo2zjs‐pstops
uses seems to be used as‐is for all colours. The 8.71 GS takes the
defined halftone screen and rotates it for each colour. The off‐the‐
shelf GS 9.04 does not, keeping the same values for each colour.
Instead of getting a good continuous colour gradient, you get
quantized colours that you can not profile properly. I changed the
type 1 to a type 5 with each colour defined as a type 1 screen with
explicit angles. This restored proper functionality.

- What the foo2zjs-wrapper does to pass the colour profile to GS seems
to be ignored by the executable. I tried to use the -sOutputICCProfile
to at least let me use a profile on the printer. This seemed to work
ok, but the profile used had to be a CMYK one, not an RGB one."


So, right now, gs9+ doesn't work using any approach!

Richard,

What do you mean gs 9+ does not work with *any* approach?  It works with what should be the most flexible and straight forward approach, which is that one needs to supply to gs the ICC profile and the halftone screen that is appropriate to use for a specific printer.  The profile and the screen need to be designed for the device.  This is the approach desired by manufactures of RIP software solutions as well as printer manufacturers.  foo2zjs‐wrapper and foo2zjs‐pstops need to be updated to make proper use of this.  If I can assist you in that transition, please let me know.

Well, the code that I have been using fails miserably under 9.x.  So I have to re-profile ALL printers to use 9.x.  It is a "Flag Day".  Normally, I would use
the old 8.+ code and then profile one printer at a time to take advantage of 9.+ Color Management.  Printers, say, the old Konica-Minola MC 2300DL could wait their turn and use only the old code.

Michael wrote (in comment #19):
  It is possible to convert the CRD's that you had created to equivalent ICC
  profile's to use with 9.04 without making a single measurement.
  ... [depending] on how it is that you obtained CMYK values with what you
  described, unless you were creating RGB CRDs and letting GS do a generic
  conversion to CMYK.  If that is the case, then you could still readily create
  an equivalent CMYK profile [sub optimal].

  Unfortunately, the printed color is dependent upon the halftone method that
  is used.  So due to the deprecation of WTS you would likely have issues if
  you were doing CRD's or ICC profiles.

However, if you use Michael's tool to create ordered dither threshold arrays
with the same parameters as you used for WTS, then the halftone _should_ be
quite close (as far as TRC/dot gain effects) to the WTS screening.

From this, you should be able to switch halftoning and still use the data
from your previous (RGB) profiles (possibly with the conversion Michael
mentioned).