/usr/share/color/icc/ghostscript/srgb.icc is not the right color profile to use for this. (I asked Artifex about this before, inquiring why PDF/A conversion with Ghostscript doesn't use this file automatically when you ask it to make a PDF/A. They said it's the wrong kind of profile. I can look up details if you want)
Thank you! This is very useful information. If it's not too much trouble for you, I'd love to write down the reasoning and also send bug reports to the places where this is done wrong elsewhere or correct people on stackoverflow.
Honestly, I personally have no clue (and care very little) about PDF/A output. All I did was to see what ghostscript does to make a PDF compliant and then replicate that in img2pdf. Finally, I sent the result to this validator: https://www.pdf-online.com/osa/validate.aspx
As for the choice of profile: you are right, it would probably make sense to switch the profile with different input color spaces. Unfortunately, I could not find a free CMYK profile, so instead I made it such that the --pdfa option is taking an optional argument so that the user can supply the correct profile. Additionally, I doubt that it's possible to always automatically determine the right profile in all situations. If that were possible, then it would not be necessary to embed it in the first place -- this also makes me highly sceptical of automatic online converters to PDF/A...
The issue is that the Ghostscript srgb.icc is for sRGB to CIE LAB (for input), and PDF/A requires a profile from CIE LAB to sRGB (output).
My earlier, now edited-out comment about providing color profile based on input image colorspace was not correct. When the output intent of a PDF/A is a screen, only a sRGB profile is required. (If one wanted to create a PDF/A intended for printing, it would make sense to provide an additional /OutputIntents entry for CIE LAB to CMYK output profile.)
As I understand it, a color managed PDF viewer should use any image color profiles to convert all content in the document to a CIE LAB representation, and then convert that to sRGB with the provided color profile. (And finally, the operating system would convert sRGB to the monitor's color profile.)
*By jbarlow83 on 2020-06-10T19:36:45.956Z*
/usr/share/color/icc/ghostscript/srgb.icc is not the right color profile to use for this. (I asked Artifex about this before, inquiring why PDF/A conversion with Ghostscript doesn't use this file automatically when you ask it to make a PDF/A. They said it's the wrong kind of profile. I can look up details if you want)
The Debian sRGB one should be fine and you can also bundle it because it's free.
https://packages.debian.org/sid/icc-profiles-free
---
*By josch on 2020-06-11T06:26:27.148Z*
---
Thank you! This is very useful information. If it's not too much trouble for you, I'd love to write down the reasoning and also send bug reports to the places where this is done wrong elsewhere or correct people on stackoverflow.
Honestly, I personally have no clue (and care very little) about PDF/A output. All I did was to see what ghostscript does to make a PDF compliant and then replicate that in img2pdf. Finally, I sent the result to this validator: https://www.pdf-online.com/osa/validate.aspx
As for the choice of profile: you are right, it would probably make sense to switch the profile with different input color spaces. Unfortunately, I could not find a free CMYK profile, so instead I made it such that the `--pdfa` option is taking an optional argument so that the user can supply the correct profile. Additionally, I doubt that it's possible to always automatically determine the right profile in all situations. If that were possible, then it would not be necessary to embed it in the first place -- this also makes me highly sceptical of automatic online converters to PDF/A...
---
*By jbarlow83 on 2020-06-11T07:09:14.714Z*
---
Found it
https://stackoverflow.com/questions/35705099/ghostscript-why-must-i-provide-a-pdfa-def-ps-for-pdf-a-conversion
The issue is that the Ghostscript srgb.icc is for sRGB to CIE LAB (for input), and PDF/A requires a profile from CIE LAB to sRGB (output).
My earlier, now edited-out comment about providing color profile based on input image colorspace was not correct. When the output intent of a PDF/A is a screen, only a sRGB profile is required. (If one wanted to create a PDF/A intended for printing, it would make sense to provide an additional /OutputIntents entry for CIE LAB to CMYK output profile.)
As I understand it, a color managed PDF viewer should use any image color profiles to convert all content in the document to a CIE LAB representation, and then convert that to sRGB with the provided color profile. (And finally, the operating system would convert sRGB to the monitor's color profile.)
---
*By josch on 2020-08-06T22:20:53.628Z*
---
Status changed to closed by commit c7db805dee604e7a40aa9db30816fa32a107b2f9
By jbarlow83 on 2020-06-10T19:36:45.956Z
/usr/share/color/icc/ghostscript/srgb.icc is not the right color profile to use for this. (I asked Artifex about this before, inquiring why PDF/A conversion with Ghostscript doesn't use this file automatically when you ask it to make a PDF/A. They said it's the wrong kind of profile. I can look up details if you want)
The Debian sRGB one should be fine and you can also bundle it because it's free.
https://packages.debian.org/sid/icc-profiles-free
By josch on 2020-06-11T06:26:27.148Z
Thank you! This is very useful information. If it's not too much trouble for you, I'd love to write down the reasoning and also send bug reports to the places where this is done wrong elsewhere or correct people on stackoverflow.
Honestly, I personally have no clue (and care very little) about PDF/A output. All I did was to see what ghostscript does to make a PDF compliant and then replicate that in img2pdf. Finally, I sent the result to this validator: https://www.pdf-online.com/osa/validate.aspx
As for the choice of profile: you are right, it would probably make sense to switch the profile with different input color spaces. Unfortunately, I could not find a free CMYK profile, so instead I made it such that the
--pdfaoption is taking an optional argument so that the user can supply the correct profile. Additionally, I doubt that it's possible to always automatically determine the right profile in all situations. If that were possible, then it would not be necessary to embed it in the first place -- this also makes me highly sceptical of automatic online converters to PDF/A...By jbarlow83 on 2020-06-11T07:09:14.714Z
Found it
https://stackoverflow.com/questions/35705099/ghostscript-why-must-i-provide-a-pdfa-def-ps-for-pdf-a-conversion
The issue is that the Ghostscript srgb.icc is for sRGB to CIE LAB (for input), and PDF/A requires a profile from CIE LAB to sRGB (output).
My earlier, now edited-out comment about providing color profile based on input image colorspace was not correct. When the output intent of a PDF/A is a screen, only a sRGB profile is required. (If one wanted to create a PDF/A intended for printing, it would make sense to provide an additional /OutputIntents entry for CIE LAB to CMYK output profile.)
As I understand it, a color managed PDF viewer should use any image color profiles to convert all content in the document to a CIE LAB representation, and then convert that to sRGB with the provided color profile. (And finally, the operating system would convert sRGB to the monitor's color profile.)
By josch on 2020-08-06T22:20:53.628Z
Status changed to closed by commit
c7db805dee