The customer reports: For no apparent reason, the pdf14 device is allocating its transparency buffers for all Spot colors - even those that are not colorants of the output device. You can see that clearly in pdf14_buf_new, the parameter "n_chan" is always equal to the total number of spot colors in the file. This is very strange because in pdf14_cmykspot_putimage, when the data are finally mapped to the output device, the channels corresponding to the non-colorant spots are absolutely not used. And besides, the get_color_comp_index() of pdf14 correctly calls the get_color_comp_index() of its target device to determine if a spot is, or not a colorant. So why rasterizing separately the non-colorant spots? That's hard to understand. The result is that with file having both transparency and spot colors, the memory consumption (and the processing time) of gs is proportional to the number of spots present in the file - even when the output device specifies to use the alternate space for all the spots. Note that tiffsep, by default, produces an additional plate for each spot color, so the extra-processing time and memory usage is more or less justified in that case. But if you restrict the number of output colorants with SeparationColorNames and SeparationOrder parameters, like our own device, it isn't. I attach some test files showing clearly the problem. Here are my timings (in seconds) for each of them, at very high resolution: Without transparency (with respectively 0, 1, and 24 spots, and only CMYK output): NoTrans_0.pdf: 570s NoTrans_1.pdf: 580s NoTrans_24.pdf: 580s With transparency (0,1,8,16 and 24 spots, again CMYK output): Trans_0.pdf: 3106 Trans_1.pdf: 3551 Trans_8.pdf: 5555 Trans_16.pdf: 7577 Trans_24.pdf: 9543 This is with our custom device, but you can probably reproduce twith tiffsep, specifying SeparationColorNames/SeparationOrder on the command line. However, maybe you'll have some difficulties with tiffsep because of bug #689581. Maybe that would be better to fix this one once for all before going to this one. Note that the file of bug #690157 is also showing the problem (it has more than 1000 Spot colors), but is a little bit pathological (no real file will have that many spots. That can only happen with Pantone test files).
Created attachment 4673 [details] files.tar.gz
I don't see this occuring at all. If a CMYK output device is selected, then the blending buffers are CMYK sized (or smaller if the blending space is different) and all the spot colors are mapped using the tint transform. pdf14_put_image is used NOT pdf14_cmykspot_put_image. That is used if a sep type of device is used (or one that understands all the spot colors). Perhaps this issue existed prior to all the changes that I did with respect to transparency.
Reopen of this bug. I now understand that if tiffsep is used and /SeparationColorNames and /SeparationOrder are specified we should only allocate the buffers necessary for the spot colors given in SeparationOrder plus the standard colorants. This is currently not done but rather a buffer is allocated based upon the number of spot colors in the document. The tiff sep description in the documentation is clear that /SeparationOrder will specify the number of separations that will be produced. The number of colorants for the PDF14 transparency device should be based upon the number of non standard spot colorant names in this list + the number of standard colorants.
Created attachment 5726 [details] bug690218.diff Testing this fix now....
Fixed with commit 10414.
Customer reports this is not fixed. Looking into this....
Verified that this problem still exists. The pdf14 device is getting the number of spot colors from p14dev->devn_params.page_spot_colors during the c-list reader phase. This parameter is the number of colorants used in the source document. The value is used to specify the size of transparency buffers regardless of the device's true spot color capabilities as specified with a command like -c "<< /SeparationColorNames [ /Cyan /Magenta /Yellow /Black ] /SeparationOrder [ /Cyan /Magenta /Yellow /Black ] >> setpagedevice".
I have a fix for this now. Doing some testing to verify no other problems occur.
Fixed with rev11330
Changing customer bugs that have been resolved more than a year ago to closed.