PDF compiles my book cover with washed out CMKY colors

So the epub will compile my cover image as-is (thankfully), but if I include the full-color cover in a pdf compile (I only do this for ARC PDF copies, not KDP/printer copies, as those are black and white), it converts it to a CMKY color-palette.

I’ve compiled 4 books this way without noticing, but book 5 uses a deep red that comes out… a washed out rusty brown. After much digging, a CMKY conversion seems to be the problem. I’m just wondering why it would need to convert to CMKY for a digital/pdf rendering?

Left: How it should look, Right: How it renders in PDF

The difference can be seen in the little cracks, too.
Have you tried compiling without the cover and rather adding it using Calibre ?

I am pretty sure it can be done for a PDF
I’ll run a quick test.

[EDIT] Hmm… Seems like you’d have to rather produce your PDF from your epub. But perhaps, if you’ve got a lot of different formatting, you could convert your PDF to epub, add the cover, and finally convert it back.
I don’t know what kind of results you’d get.
I am only proposing this in case there is no in-Scrivener solution.

Might be worth looking for an app that allows you to do it in the PDF directly. (Some PDF editor app.) As Calibre is able to manage PDFs in its library, but not edit them. It is more ebook oriented…

1 Like

Have you tried the “optimize for print on demand” option in the PDF Settings pane of the Compile format?

It’s probably optimized as a prepress format. CMYK is an ink color space.

I would think the quickest solution would be to replace the cover with the RGB version using a PDF editor like Acrobat Pro or Preview (MacOS).

I use Sigil, but I take your point. Unfortunately, the epub isn’t as pretty as my print-version and has been dumbed down a bit, or I’d just offer the epub for ARC. I want them to see how nice it looks as a printed product, as I took a lot of time to make it look on-par with anything a big publisher would produce (vs. tell-tale indie)

I’d go with @popcornflix 's proposed solution.
Scrivener in itself is not designed to handle images.
Use a proxy, and figure out a way to switch it for the real thing later on.

And yes, your cover looks much better as “the way it should be”. :wink:

Still muddy with “optimize for print on demand” checked

When I drop the image into Preview, it’s cropped funny. I may have to fiddle with this option a bit if it’s the only solution, but it feels like it could be an issue for a handful of people who want brightly colored graphics in their pdf compilations.

People who want print-ready output should use tools designed to produce such output. Which Scrivener is not. (Or is only for a fairly narrow definition of “print ready.”)


I don’t need it for the POD file though. I want it for digital pdf distribution to beta/ARC readers.

Same answer, though. Scrivener does not offer the kind of control that you are seeking.

PDF uses CMYK because it is fundamentally a print format, and CMYK is the print standard. If you want to force an RGB image into a PDF document, you will need a smarter PDF creation/editing tool than Scrivener’s.

Incidentally, one alternative would be to create (or ask your cover artist to create) a version that uses brighter CMYK colors. With access to the original work, you have a lot more options than an automated conversion engine does.

I’m the cover artist, and unfortunately Vectornator has taken to crashing at every turn. :-/ I’m an old-hat (professionally) with Photoshop and Illustrator, but I just can’t afford all the subscription b.s. and they have (in the past) continued charging me exorbinant fees long after I cancelled in every way/shape/form until I just blocked Adobe from my credit card. So color me unimpressed by their subscription model and being forced into it. And sadly, I’ve never quite mastered Gimp.

When it works, Vectornator is usually fine for what I want.

I can’t personally vouch for them, but a number of people here in the forum like Affinity Photo/Designer/Publisher as alternatives to the Adobe suite.

1 Like

I’ll second that. I dropped Adobe back when CS6 stopped working because I’ll never subscribe to software. I switched to Affinity at the time, and haven’t been disappointed since. They charge a reasonable one-time fee and that’s it. Maybe they’ll have a paid upgrade in the future, I don’t know, but it has been years since and I’m still using the latest version with the license I bought back then.

As a former Adobe user, you should find their UI a lot more familiar than Gimp. I love Gimp, don’t get me wrong, but it does have its own way of doing things.

1 Like

I suggest you use your graphics program to produce the CMYK version yourself. If the program is worth its salt, it will do the best job of converting your RGB to CMYK while preserving visual intent. Then set your compile to use that cmyk cover image when you compile to PDF.

Also, always embed the color profile you are using in your graphics development in the output image. This will give your image the best chance of looking right in different digital contexts.

If your cover still looks washed out after all that, maybe you should check how it appears in other pdf readers. Maybe your pdf reader sucks.

(While you could as a last resort go back and increase the saturation or whatever in the cmyk version, there is some danger in this. If you don’t know why it doesn’t come out right, you may be correcting for something others would not encounter on their systems. In which case you would have made a cover that will then appear gawdy on their systems. So, don’t compensate, gain color control. )


Try Calibre. It’s free, and you can just drop in your epub, copy the cover, drop in the PDF and paste the cover and you’re done. Calibre is also great for testing all your finished ebooks.

1 Like

Since this discussion, I’ve come to the conclusion that it’s just using a different aspect ratio than everything else in existance. There’s the PDF width x height, the KDP epub width x height, the audible width x height, the goodreads width x height the… yeah. Everybody’s got their own standard which makes it anything but. I guess I would’ve figured pdf compiling would just shrink it to fit rather than cropping it. (Although I noticed there was a warning that it would crop it for the first time the other day).