I am very proud of the fact that I have been able to write, edit, illustrate, design and produce all my books using only free and open-source software. I did not spend a penny on proprietary software or other creators or service providers. Even the OS is FOSS. I transitioned to Linux a decade ago.
However, it has bugged me from the beginning that my book covers were not made from CMYK PDFs, which is the default for the print medium. I create my book covers in GIMP. It does not output in CMYK. It only supports RGB colourspace, which is the default for display screens. I searched the Net for answers but the engines all just linked to ImageMagick documentation or the same useless StackOverFlow questions.
Creating a book cover image and exporting it to PDF
The cover templates provided by Amazon KDP includes
- a PNG with cover outlines and bleed margins. It also has an embedded colour profile — sRGB IEC-61966-2.1.
- a CMYK PDF created from this PNG
In Inkscape, I create most of the cover elements and export it as a PNG. I drop this PNG on the cover template PNG in GIMP and export a final PNG, taking care to include the template colour profile as is.
I then use ImageMagick to convert the final PNG to create a cover PDF.
magick cover.png cover.pdf
This creates the PDF but the colourspace of the image in the PDF will be RGB. This is not suitable for printing. Some or all the colours can be different. The difference could be barely noticeable to gross-out ugly.
I spent most of yesterday and tried to find a way to create a CMYK PDF. The solution is very simple.
magick cover.png -colourspace CMYK cover.pdf
Earlier, I tried to include a CMYK colour profile.
magick cover.png \
-profile "/usr/share/color/icc/ghostscript/default_cmyk.icc" \
cover.pdf
Adding CMYK profiles made no difference. The ImageMagick identify
program reported that the PDF used sRGB colourspace nevertheless.
Adding the -colourspace
option made all the difference. identify
confirmed the change.
magick cover.png \ -colourspace CMYK \ -profile "/usr/share/color/icc/ghostscript/default_cmyk.icc" \ cover.pdf
Why do CMYK PDFs look washed out?
While identify
confirmed that all the PDFs created with the -colourspace
option were CMYK PDFs, the PDFs themselves looked bad. In some colours were slightly different. In another, a purple cover looked violet. What the heck is that?
Apparently, it has to do with some colour theory. RGB colourspace uses additive colours because the pixels emit light. CMYK colourspace uses subtractive colours because they have to reflect light on white paper. Let that sink in.
I remained doubtful until I saw the book preview on KDP. The colours looked perfect.
You can confirm that the PDF is fine by using -jpegcmyk
option of the pdftoppm
utility. If you the ordinary -jpeg
or -png
option, it will look as bad as the PDF.
Situation on Amazon KDP
While identify
considers the PDF as a CMYK PDF similar to the (the old) templates, it is not clear how well Amazon KDP can process these PDFs.
In the upload page, the thumbnail shown is clearly not considering the CMYK nature of the PDF. The terminal window is not totally black.
In the whole-book preview, the covers are converted almost properly. The terminal window is dark but the book covers look slightly discoloured.
What are KDP users supposed to do? In the past, Amazon was using the Adobe PDF library and the templates were CMYK PDFs. Now, they are using the BFO PDF library and they are providing sRGB PDFs. The people who coded the print preview page are considering are CMYK PDFs. Those who coded the upload page thumbnail are treating them as sRGB PDFs. On the Amazon sales page, they never considered CMYK. The covers are washed out as ever.
In other news
In the Linux Command-Line Tips & Tricks book, I made a few updates:
- a mistake in the descriptions of patterns. I had confused them with Regular Expressions.
- the odd nature of exit codes of the
let
built-in command. - errors that can happen because shell script functions resplit words in arguments passed to it
UPDATE (24-November-2022)
I changed the cover again.