Created attachment 17204 [details] Example pdf with DeviceGray objects The `ColorConversionStrategy`-related conversions silently skip DeviceGRAY colors (e.g. for text). When using the following command, user might expect that everything would be converted to CMYK: > gswin64c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sColorConversionStrategy=CMYK -sOutputFile=out.pdf inp.pdf However, the output pdf still got DeviceGRAY text and color. (Example input attached) Same for conversion to `RGB`. The following phrase in the documentation (related to `-sSourceObjectICC`) https://www.ghostscript.com/doc/9.26/GS9_Color_Management.pdf sounds like GRAY should work just like RGB or CMYK: "In addition to CMYK and RGB types given above, the user can also specify Graphic GRAY, Image GRAY and Text GRAY objects". Note that: * Adobe pdf creation (e.g. Distiller) works the same way, and provide the following documentation on this: - "Convert All Colors To CMYK Converts color spaces to DeviceGray or DeviceCMYK according to the options specified in the Working Spaces menu. All Working Spaces must be specified.", see: https://helpx.adobe.com/acrobat/using/pdf-conversion-settings.html https://helpx.adobe.com/acrobat/11/using/pdf-conversion-settings.html - A table on page 38 the following doc explicitly shows that DeviceGRAY remains DeviceGRAY unless "Use Device Independent Color", https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDFCreationSettings_v9.pdf * Adobe "Acrobat -> Tools -> Convert Colors" tool https://helpx.adobe.com/acrobat/using/color-conversion-ink-management-acrobat.html can easily convert DeviceGRAY objects to CMYK or whatever. And, personally, I've initially expected gs (and Distiller) to work like that too. Thus, AFAIU, gs behaves "as desired", but the docs are a bit misleading. The suggestion: It would be nice, if the the mentioned phrase "... the user can also specify Graphic GRAY, Image GRAY and Text GRAY objects." would be accompanied with e.g. "However, DeviceGRAY is treated as a special case, and is not actually converted to CMYK/RGB - it remains DeviceGRAY unless "Use Device Independent Color" is used (in which case it becomes ICCBasedGray)".
Just for reference: * This was also discussed here: https://ghostscript.com/irclogs/2019/03/10.html ... https://ghostscript.com/irclogs/2019/03/15.html * This was mentioned few years ago here: https://stackoverflow.com/questions/38310916/pdf-batch-conversion-from-srgb-to-cmyk#comment64167806_38314025 .
(In reply to i3v from comment #0) > The `ColorConversionStrategy`-related conversions silently skip DeviceGRAY > colors (e.g. for text). That's expected behaviour, as I already indicated. Since DeviceGray can be mapped directly to the K channnel of CMYK, there is no need to colour convert it. > The following phrase in the documentation (related to `-sSourceObjectICC`) > https://www.ghostscript.com/doc/9.26/GS9_Color_Management.pdf > sounds like GRAY should work just like RGB or CMYK: > "In addition to CMYK and RGB types given above, the user can also specify > Graphic GRAY, Image GRAY and Text GRAY objects". That document does not apply, more or less at all, to the pdfwrite device. In general the pdfwrite device goes to extreme lengths to maintain colour dpecifications from the input unchanged in the output. When ColorConversionStrategy is specified the colour management engine is used, and also when objects have to be rendered (for example when outputting to earlier versions of PDF. > The suggestion: > It would be nice, if the the mentioned phrase "... the user can also specify > Graphic GRAY, Image GRAY and Text GRAY objects." would be accompanied with > e.g. "However, DeviceGRAY is treated as a special case, and is not actually > converted to CMYK/RGB - it remains DeviceGRAY unless "Use Device Independent > Color" is used (in which case it becomes ICCBasedGray)". No, because that document refers to the rendering devices, not to the pdfwrite device. The behaviour for rendering devices is as described.
(In reply to Ken Sharp from comment #2) > (In reply to i3v from comment #0) > > That document does not apply, more or less at all, to the pdfwrite device. > ... > No, because that document refers to the rendering devices, not to the > pdfwrite device. The behaviour for rendering devices is as described. Hmm.., My initial impression was the opposite - everything I've tried, except "Text_GRAY" (and other "*_GRAY") do work fine for `-sDEVICE=pdfwrite`. I won't say I've tried everything described in that doc, but those fancy example color conversions for the "text_graphic_image.pdf" do work. Also, I've never seen explicit "this document does not apply to `-sDEVICE=pdfwrite`" there. Even though it might be the case that Color Management is rarely used with pdfwrite, it would be nice if the behavior would be documented. AFAIU, there's no special "Color Management for `-sDEVICE=pdfwrite`" doc. ----------------------------------------------------------------------- For `-sDEVICE=tiff32nc`, I do see that DeviceGRAY color conversion results depends on the "Text_GRAY" line, e.g. adding > Text_GRAY default_gray.icc 0 1 0 to "objsrc_profiles_example.txt" and running > gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sColorConversionStrategy=CMYK -sSourceObjectICC=objsrc_profiles_example_v2.txt -sOutputFile=%1_v2.tiff %1.pdf makes black text cmyk(0.7255, 0.6784, 0.6706, 0.8902) while the original "objsrc_profiles_example.txt" http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=toolbin/color/src_color/objsrc_profiles_example.txt;hb=eec855c9baeaa73c0208ed439fbbf1a0d48a447e or plain > gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sColorConversionStrategy=DeviceCMYK -sOutputFile=%1_v8.tiff %1.pdf makes black text cmyk(0, 0, 0, 1). Thus, indeed, `Text_GRAY` do work somehow for `-sDEVICE=tiff32nc`. ----------------------------------------------------------------------- So, my original suggestion is incorrect in the sense, that it is missing "for `-sDEVICE=pdfwrite`". The more appropriate version would be: "However, for `-sDEVICE=pdfwrite`, DeviceGRAY is treated as a special case, and is not actually converted to CMYK/RGB. ..."