KDP publishing error - bleeds and background color

[yerkanian]

Hello,

I'm having issues with the KDP previewer regarding a couple of chapter pages that have a background color (a solid color shape). My book is 6x9", and since there are these pages that have a background color that extends to the edges, the document is set to 6.125x9.25" with bleeds. The margins are correct and exceed the minimum requirements.

When I remove the background color (delete the shape), the error goes away, but I want to keep the background color for design purposes.

How can I resolve this issue? Did I do something wrong?

I've attached screenshots of the document setup, the actual document, and the KDP preview.

Thanks in advance for your help!

[James Gifford—NitroPress]

Okay, first know that KDP's proofing system can be maddeningly erratic and capricious. The smallest thing can trigger a fault, whether it makes sense or not, and one kind of fault can trigger an unrelated error. (A common one is "you must increase your bleed area" when trhe problem is actually what it considers live content outside the live-content margins.)

Looking at your examples, I'd check two things: make sure the background rectangle is *exactly* the bleed size, right on the bleed lines. It can't be larger or smaller or misaligned. I'd also bump that PREFACE in a tad from both live margins; it looks a little close to the left margin. Best to make sure the text box is within that margin as well, by bringing it to within a whisker of the bottom and keeping that slight space below.

I will say your left margin looks way too small. An inch is nominal for perfect binding; much below 0.75 inch and the book will be difficult to spread enough to read easily.

[yerkanian]

Dear James, 

Thanks for your quick response. This is absolutely maddening, as I tried so many things to fix this, but still no luck. 

I know it is not the text (P-preface in this case), because I've tried deleting text and importing the file and I still get the error, and I also tried deleting the background color but keeping the text where it is, and the errors were gone. So the issue is with the background. It is exactly the same size as the page and is aligned perfectly. 

I followed KDP's requirements for the margins, and made them even bigger. Their minimums were 0.25 and 0.375, and mines are 0,375 and 0.5. 

I don't have errors on other pages. Only this chapter has pages with the background. 

[yerkanian]

Eventually, I surrendered to KDP and removed the red background. I was able to proceed without errors. 

[rob day]

I surrendered to KDP and removed the red background

Is there any chance the Content of the frame you used for the background color was set to Text and not Graphic or Unassigned?

[James Gifford—NitroPress]

Clever thought, but I doubt it. KDP analyzes submissions from a very peculiar perspective and I doubt any fine differences in the PDF from this choice (Graphics v Text frame) would even come to their attention.

I suspect it's another case where more or less conflicting rules generate an error over some subtle aspect of an inside margin/bleed/nonbleed.

[rob day]

Clever thought, but I doubt it.

The reason I suggested checking content is, my example file has one text frame with only its insertion point. If I export and preflight the PDF, it picks up the font in the empty frame, so KDP’s preflight might be detecting the insertion point as text even though there are no characters?

[James Gifford—NitroPress]

I really don't know, either way. On the one hand, ID's tagging of frames is a fluid and chameleon-like action, and I don't really know how much that assignment passes through the layers of export and print interpretation. I also am pretty sure I used both in the struggle to get thumb tabs in the one book, and both were assiduously rejected for the same error reasons.

It would be worth experimenting with — if KDP lent itself to any kind of experimental loops. But each upload can take 72 hours or more to process, so it's a slow thing, and there's no guarantee the error results would be meaningful or consistent.

I do have a note to try it on my next print book with KDP, though.

[yerkanian]

I checked this of course, and it was a graphic. I also tried making a jpg or png with a solid color, and using an image instead of the shape. It didn't work either 🙂

[James Gifford—NitroPress]

Sometimes that's how it goes. Even having someone look at your ID file may not have turned up any obvious problems.  Unlike Kindle, there's no tool for pre-proofing your submissions. The only way to encounter these errors, and try to outjump them, is to upload the file and see what the online proof system says. (Some KDP regulars maintain a "junk book" in their library, that they can use to upload test files and pages, to try and run down these problems. I haven't had the need, but.)

A couple of things that might have worked/helped:

• Bring the red panel in from the binding so that it runs to the inner margin and bleeds top/bottom/outside. I suspect the "fault" is in that inner bleed, which is erratic in interpretation, hence the alternatives suggested.
• Bring the red panel in to the margins. Not quite what you wanted, but close.
• Per Rob's following suggestion, make sure the red frame was a Graphics Frame; it's just faintly possible that being a text frame could contain something to trigger the warning. I think this very unlikely, though, as KDP simply does not see documents the way we do as ID/PDF users.

I still think you're going to be unhappy with that tight inside margin. Perfect binding in general and KDP in particular, with its 1/4-inch pinch, eat up inside margin space. More than one of my books with a standard 1-inch inside margin are still just a tad tight for easy readability.

You might also/have been unhappy with the solid red page. KDP printing is about as good as you get from a well-maintained office printer, meaning fades, streaks, dropouts and the like are not unknown on color solids. And as printing is done from many different depots,

The problem with KDP as a whole is that Amazon seems unwilling to commit the resources it really needs, and create some dividing line between the reasonably skilled/pro/experienced tier and those attempting to publish a first book from a ragged Word document. The latter absolutely overrun the system, support and forums and it's all but impossible to get help or resolution at a (using the word loosely) pro level. someone in Canada might see a thoroughly ratty copy even though US and UK buyers get excellent results.

Part of this is because KDP relies almost wholly on bots, which are really, really stupid sometimes. When anything gets past bots, it's to reviewers who are not much smarter, probably because they have to operate according to mechanical checklists and not anything like human judgment. (I also suspect, from what interactions I've had, that they are all off-shored and ESL.)

So we do our best, from KDP's ragged, wrong and incomplete instructions to whimsical approval standards and absolutely Soviet-bureacracy dicta about flaws, and what could be a truly great publishing system is merely... another Amazon service.

Two true stories: I recently did a book in which I wanted thumb-tabs, a bit like a dictionary, to locate sections quickly. Long, long story short: if the tabs included anything like content (letters, numbers), even in graphical or inside-the-margin positions, it threw errors. I finally just published with simple thick lines as tabs, identical in every respect to all I'd tried before but with no 'content'... not a peep from the proof system. And not nearly as useful.

Then there was the book that made a point on the back copy it was "also available in a Kindle edition" — which is nothing rare in KDP-land but was specifically noteworthy for this book. I forget how many tries I made at getting past a "Cover misidentifies edition type" error before I just gave up and took the copy off the back cover. Clearly, nothing of cockroach intelligence, much less human, was involved in the checking.

So you just give up and do it their way, however little sense it makes.

[yerkanian]

We are going to print a test and see how it looks, and then maybe make the margins bigger if needed. 
I think removing the red background is not that bad in the end, as I am not sure they would be printing a good quality solid color. 

I doubt I will be printing again with KDP,  but this time client didn't have the budget for a proper publishing/printing house. I usually go to the printing houses and overlook the printing process, and have all the freedom with the layout, so this was challenging to have all these restrictions and requirements.

I will take this case as a lesson...pity I didn't learn how to fix this issue without giving up :))) 

[rob day]

Hi @yerkanian , you say your book’s trim is 6" x 9", but you have added the bleed to the trim—the setup should be this:

The .375" margin is the distance to the trim, because you have included the bleed with the page dimensions the distance from the margin to the trim is actually .25"

[yerkanian]

Hi @rob day 
That's the KDP's requirment, to include the bleeds into the actual document size and not as settings in the indesign. Their system doesn't recognize PDF's bleeds. 

[James Gifford—NitroPress]

Uh, no. You have to set up a page trim size, and then specify bleeds on top of that. You can't just combine them in one page size.

If even one page has bleeds, and you've specified bleeds in the upload, all of the pages can (should) have bleeds defined, even if they're empty.

[yerkanian]

That's what I usually do with normal printers, but I followed their tutorial here: https://kdp.amazon.com/en_US/help/topic/GVBQ3CMEQW3W2VL6

Which says to combine bleeds. 

In any case, I've just tried to do what @rob day suggested, and I got the same errors 😞 

[James Gifford—NitroPress]

KDP's info and help system is absolutely abysmal. (Which, given Amazon's size, gets a multiplier as well.)

Lay your pages out at trim size. Add bleeds. Make sure your background rectangle is exactly bleed size. Anything else you're reading or inferring from KDP is wrong.

ETA: You need an inside bleed as well for KDP. Change that to 0.125 as well.  This varies with the print process and sometimes the phase of the moon. Make sure your bleeds are set up correctly (0 inside, 1/8 inch others) and that you have no content in the live area. If that fails, add a bleed to the inside and try again. This is not a 100% predictable setup.

And again, make sure there is NOTHING over or close to the live content margin. That throws bleed errors even if page layout and bleeds are perfect.

[yerkanian]

Tried it both by adding the bleed to the inside and without it... Nothing works. 
Is there a way to contact their support and ask them to check the file? I couldn't find it on the website, but there should be a way... 

[James Gifford—NitroPress]

Okay, let's back up a little. First, what is the EXACT error the upload or proofing is giving you?

ETA: just to confirm, this is for softcover binding; how many pages, and what paper and interior print option are you choosing?

I also wonder if you're being a bit too clever with the layout (inferring from the sum of posts) — are you or have you been trying to include bleed or bleed page size only on this one page, since no other pages have bleed elements? That won't work.

Do a very simple layout setup, with 0.125 bleed top, outside and bottom, zero inside, and apply it to ALL pages. Move that PREFACE slug up a solid amount from the corner of the live limit; as a solo element it shouldn't disturb your look if it's not right in the corner. And make sure the background color rectangle is (1) exactly the bleed page size; (2) exactly aligned with the bleed margins on all sides; and (3) sent all the way to the back of any stack of elements or layers for the page — that is, not covering up anything including, maybe a stray text box or other extra element.

See if that flies.

As for getting help from KDP... in theory, there are contact addresses buried somewhere in the pages. I've even heard from people who got a reply. I've even-even heard of people who got a useful reply, not gibberish copied from help or some backroom playbook. But I also have two books that had maddening non-errors like this, and after considerable battling, I just gave up and dropped the contested elements. So.

[rob day]

Looks like the text frame for the word PREFACE is right on the margin guide, do you get the error if you move the frame further inside?

[James Gifford—NitroPress]

I noted that already, and it could be an issue — KDP is positively whoopee-cushion about what constitutes "live content" outside that guideline. But I'm betting the incorrect bleed setup is the whole problem here, as those frequently throw misleading/meaningless errors about adding size to the page or having live content issues.

[yerkanian · Accepted solution]

I thought so in the very beginning, and tried moving the text. I deleted the text box for the test, and the error is still there. 
The only thing that makes the errors go away is deleting the red shape. 

[James Gifford—NitroPress]

Good catch. KDP's setup is misleading when it comes to trim size + bleed; see this simple mistake all the time there.

[Flamboyant_codeB831]

Found a solution for having the same issue. The bleed settings were NOT selected accurately in KDP lol! Select Bleed (PDF only).

[James Gifford—NitroPress]

Yes, you have to select bleed, then submit pages that are the exact trim+bleed size, and all content has to be within the trim size margins. An awful lot of people have trouble putting these pieces together, and that's not one of KDP's poorer areas of guideline/explanation. Getting any of it wrong will generate misleading errors, though  — claiming more bleed is needed when the problem is live content outside the print margins, etc.

[eschempf]

I've tried everything to get the bleeds to work and keep getting an error. I know I have the trim size, margins and bleed correct in InDesign. I'm suspecios the problem is in the way I have Acrobat Export set up. It is hard to find a good resource on what boxes and settings should be checked for KDP.