Created attachment 11094 [details]
Patch for tiffsep device

Hmm, if the original separation was not specified as CMYK (and perhaps even if it was) then the CMYK equivalents are not strictly 'correct'. I'm not certain (this is one for Michael) but I assume the CMYK values will have been produced by littleCMS and so will not be the ones in the original input file.

In the case of ICCBased PDF input, the CMYK equivalents for a Separation or DeviceN will definitely depend on the colour management.

I'm also uncertain about sticking random data into a TIFF file. I've had a quick peruse of the TIFF 6.0 spec, and while its certainly possible to pack extraneous data between the tags and image data in a TIFF file, I'm not certain this is 100% legal and may potentially confuse TIFF readers.

I'm assuming this is being used to 'colorise' the TIFF output, that is to convert the grayscale image into a CMYK image, presumably for proofing purposes.

I'd like to hear some opinions from other staff before we decide whether to adopt this patch. Also, who owns the tiffsep device anyway ?

Consulting during the Tuesday meeting. I misunderstood the patch, and the colour equivalents are going to stdout, not to the TIFF file. Personally I'd like to see this controlled by a device parameter to avoid people getting output on stdout they aren't expecting.

The CMYK values are the tint transform values when the alternate space is CMYK, they may be colour managed when the alternate is some other space (Gray or RGB), hoping to hear back from Michael about this. I'd like to see a comment added to the code when we know for sure, just because someone will ask one day.....

Created attachment 11095 [details]
Patch with the changes noted in the comment

When I run this with a test file of my own it prints the separation name as 'Cyan' which is incorrect. This is because num_comp is 1. It looks like the code in print_cmyk_equivalent_colors isn't sophisticated enough to deal with PostScript files which only have Separation colours and not CMYK. I've changed the code to deal with that.

I also changed stpcpy to strcpy and moved the definition of int_num to the head of the function out of the body, as this won't compile properly on some platforms otherwise.

I added a comment to print_cmyk_equivalent_colors with the information Micahel provided about where the CYK values are derived from.

Finally I added a new device parameter PrintSpotTransforms which defaults to false, if true it prints the CMYK values just as before. Checked with a release build to ensure no problems were found, and cluster tested.

It would be useful if someone could cast an eye over this.

Thanks, Ken, I'll have a look. From your comments, I think "PrintSpotTransforms"
is not as clear as "PrintSpotCMYKtint" or "PrintSpotCMYKequiv", or just the
simple "PrintSpotCMYK" -- Transforms doesn't make much sense unless one knows
about the "Tint Transform" in the spec.

My gripe with the original was the unclear output, eg:
   %%SeparationColor: 23915 327 31449 1310 PANTONE 369 C
instead of something like:

    %%SeparationColor: "PANTONE 369 C" CMYK equiv: [23915 327 31449 1310]

Both can be parsed readily, but mine is more human friendly (which since I
am one -- at least until late at night -- I prefer).

(In reply to Ray Johnston from comment #5)
> Thanks, Ken, I'll have a look. From your comments, I think
> "PrintSpotTransforms"
> is not as clear as "PrintSpotCMYKtint" or "PrintSpotCMYKequiv", or just the
> simple "PrintSpotCMYK"

I was trying to keep the name short and relatively easy to type, I didn't like the abbreviation of equiv, and equivalent was just too long and hard to type right.

PrintSpotCMYK would be OK by me if you prefer that.


> My gripe with the original was the unclear output, eg:
>    %%SeparationColor: 23915 327 31449 1310 PANTONE 369 C
> instead of something like:
> 
>     %%SeparationColor: "PANTONE 369 C" CMYK equiv: [23915 327 31449 1310]
> 
> Both can be parsed readily, but mine is more human friendly (which since I
> am one -- at least until late at night -- I prefer).

Yeah I thought about changing that, it made more sense from my POV to have the ink name follow the SeparationColor: comment, as you have it above. I'm happy for you to change it that way if you want to do it, would be nice to hear from mlen here also.

We also need to know if mlen has completed a CLA.

Created attachment 11096 [details]
Modified patch

OK so further to Ray's comments. The switch is now PrintSpotCMYK and the output is of the form 

%%SeparationColor: "ink name" 100% ink = %d %d %d %d CMYK

So we see the ink name more easily, and the description includes the fact that 100% of the spot colour maps to a given CMYK value.

This also fixes a bug in the previous patch (which nobody noticed!) causing all the CMYK values to be wrong.

mlen I need to know if this format of output is suitable for you. It would be helpful also if at least one person would test this.

Patch committed in 3a035a2a9e94196920f99a18670ee96202f67bb9