I have attached a PDF-file from one of our customers. This PDF-file can not be loaded with the current gs8.54, or any version below. It just gives a lot of Warnings and then the applications stays without exiting. The GS-interpreter seems to have problems with some color space name. Can you have a look at it?
Created attachment 2381 [details] test file
This seems to be a JPX stream problem. We are in an infinite loop at line 457 of zimage.c which says: while ((avail = sbufavailable(s)) <= (min_left = sbuf_min_left(s)) + num_aliases - 1) { Both avail and min_left are zero. Since 0 <= 0, we stay in the loop. Since I do not know enough about the stream logic, I do not know what is supposed to break this impasse. Ralph and Ray have been playing with this logic so I am passing this one back.
P1, infinite loop.
Confirmed this is a JPXDecode problem.
This is no longer a hang.
I am running rev. 8814 with the 'jasper' JPX decoder. I haven't tried the Luratech decoder. On Windows I observe an infinite loop (hang) when trying to process: /Im0 Do This occurs with the command line params: -dPDFDEBUG -r80 -dNOTRANSPARENCY /artifex/bugs/ratio/bug_688807.pdf but without the -dNOTRANSPARENCY it still hangs atthe same place. It is looping in 'image_file_continue' calling s_process_read_buf(s) to get more data, but after calling the process function, sbufavailable(s) still returns 0. The EOFC condition is not returned so we continue looping. From the first call to process_read_buf, we get 0x7fe bytes, then on the second call we get 0x528 bytes, then subsequent calls produce no data.
Some progress: The hang occurs with the ppmraw device. I get /rangecheck in --run-- with x11alpha before the JPXDecode filter is instantiated. There are some errors in the state machine in s_jpxd_process which are causing us not to respect the stream calling conventions. Is is part of the cause for the hang. However, the filter is trying to return sRGB data, when the image is CMYK. The PDF image dictionary has an overriding ICCBased color space with 4 components (presumedly CMYK) but we do not pass this down into the filter as we should, and do with Indexed color spaces. Further, the JPX stream itself specifies an enumerated CMYK color space, backed by an ICC CMYKLab profile (Europe ISO Coated FOGRA27). Jasper ignores this, and assumes that any image with 3 or more components is sRGB. The resolution of the second part is two-fold: We should check ICCBased color spaces in JPXDecode image dictionaries and if the number of components is 4, assume they are CMYK. This should allow the stream logic to return the correct number of channels. The jasper library should also be extended to handle the CMYK extensions from the JPX format required by PDF.
This issue is resolved as of r8819, which implements override of jasper's incorrect fallback from ICC-based CMYK to sRGB by the ICCBased CMYK in the image dictionary. The file renders correctly now.