KDP error on a single page (text outside margins)

[Sofia25629549ta0q]

Hi,

I'm stuck with this error. It's weird because the object on the right (the one that is being flagged as the error) is a master page and is applied to the entire book BUT it is only in this page that they say the text is outside margin. 😞

Has anyone ever encountered this before?

I tried moving the head to the left a lot of times and still getting the error. 😞

[Rishabh_Tiwari · Accepted solution]

Hi,

Thank you for reaching out. Can you check if any empty text frame was created outside permitted margins? If yes, please remove that and test again. 

Thanks

Rishabh

[rob day · Accepted solution]

It's weird because the object on the right (the one that is being flagged as the error) is a master page and is applied to the entire book

Hi @Sofia25629549ta0q , Is the orange band the text frame and has it been overridden on the page? If it has been overridden, turn on invisibles and check to make sure the end of story marker is on the same line as the text and there is not an added return forcing the text to cross over the margin line:

[Sofia25629549ta0q]

IT WORKED! Thank you so much!!

[James Gifford—NitroPress]

I gave up on my current battle. KDP is stubbornly calling simple bleed graphics "content near the trim line" and I just don't have the stamina to keep trying to figure out the difference. 😛

I do note all of your text is inside the text-safe area (now, with that correction), but they seem fine with your bleeding orange tab, which is equivalent to what they're complaining about in my book. Maybe they just don't like me any more. 🙂

[rob day]

Hi James, I've never used KDP, but I was guessing they are using some kind of preflight script to look for text characters with xy coordinates outside of the safe margin area, and they are not distinguishing white space characters (invisibles) from visible glyphs?

When you check your pages are you turning on invisibles and making sure there are no white space markers outside of the safe area margin?

[James Gifford—NitroPress]

Yeah, I am aware of all the variables. I've been doing KDP/Lulu/etc. publication for quite some time and usually the rejection reasons are... understandable if not particularly sensible.

KDP in particular uses an almost wholly automated system to process books. It is absolutely opaque and while they make much of "being helpful," simply telling you that the error is on pages 26 and 125 is not usually of any help. You just have to keep changing things until you've properly appeased the ghods, or just give up and do a more vanilla layout. There is no way to reach a human being or advanced AI system that can discuss the issue and/or grant exceptions to the processing rules, even when the rules are wrong. It's... maddening.

An example I've posted before: The book in my sig is published in both paperback and Kindle. (It's a signature example of my dual-format publication methods, besides being a repository of those methods; paging Dr. Recursion here.) In the first edition, I had a back cover blurb that contained the phrase "Also available in a Kindle edition, of course."

It was rejected for "Cover identifies publication as an incorrect format."

I spent three weeks trying to get that copy past the AI review — including putting a "post it note" on the cover art — and finally just gave up..

My current project is a slim little book with an odd internal layout, intended to be a reading companion to a famous American novel. The verso pages are blank — well, they contain space for "Your Notes" — while all the relevant notes for the novel are on recto pages. You can tuck the left side of the book into the novel hardcover and manage it easily. (Frankly, I thought one or another aspect of this layout, such as recto-only page numbering, would trip the AI rejection. But no, I am being allowed to be creative, for a change.)

For further convenience, I want/ed to put chapter number thumb tabs on the pages. There are only 20, and in the original layout they were numbers in text frames with a dark gray background, something like this:

This was rejected several times for "content near the trim line"... but only on a few double-digit pages. No amount of horizontal positioning relative to text safe area and trim margin would pass.

So I laboriously converted all the tabs to images, so that the numbers would not be interpreted as "content."

No dice.

So the current submission has these instead, barely useful enough to bother with but submitted as something of an experiment to see if the AI is just being arbitrary about wholly graphic bleeds:

I await the AI's blessing. 😛

(And for those who do know something of KDP et al. processes, yes, I have bleeds selected and am conforming to all the rules that have allowed things more like the OP's colored page tabs in prior works. As nearly as I can tell from the rounds of cryptic error messages, KDP simply doesn't want any text, or text-like content, outside the inner text margin, not even for "decorative" purposes. The AI simply isn't smart enough — or not given enough leeway — to allow "micro content" like numbered tabs in this region.)

[James Gifford—NitroPress]

And just to close this out, the simple line tab passed inspection. So my conclusion is that any kind of text outside the safe-text area will trip this "text near trim line" error, even if a monkey on Xanax can tell the text is supposed to be there.

With the OP's project, the colored page tab is irrelevant, but even that tiny bit of empty rollover text is enough to trigger the border-invasion alarms.

So the only way you can do thumb tabs with any kind of markers is if all the text — A B C etc. included, and either live fonts or images — is within the text zone, which is rather deep for a small book. Sigh.

[rob day]

but even that tiny bit of empty rollover text is enough to trigger the border-invasion alarms.

Right, I think the end of story marker, which you can see with invisibles turned on and in my captures, has to be with the line of text—a return would put it into the margin. I don‘t think there is a way to catch that with an InDesign Preflight Rule, but an InDesign script could find the end of line x,y position.

[James Gifford—NitroPress]

So much of what KDP demands is outside any standard formatting rules. You could find ways to script or preflight them, but in the end, it's like checking old page proofs... pretty much all manual. And there's always one more opaque spell incantation rule to figure out from vague feedback.

KDP desperately needs a 'pro' option, whether it's gated by pay, qualification, whatever. Having an entire publication portal that assumes all users are morons and thus having absolutely no meaningful communication is just insane. (Having worked with hundreds of first-time author/publishers, I can understand why they wouldn't want to put in a department of 1,000 extremely patient tutors, but when pros have to backward-disassemble cryptic and absolutely inflexible rejection notices... it would be nice to be able to engage a pro at that end to say "That back cover blurb isn't claiming to be a Kindle edition, see?")

Not gonna happen, but it's the price we pay for world publication and marketing that Lulu, for example (which does have a better tier of publisher support) can't match.

[James Gifford—NitroPress]

Just to be clear, KDP can be absolutely maddening about this kind of stuff. I have more problems with print editions than with Kindle ones, and my batting average for resolving the problem in my favor is below the Mendoza Line.

You are not dealing with anyone sensible or empowered to actually analyze an issue; you are most likely battling an AI that insists element X falls outside the list of layout rules. You're not likely to win, and if ther's a way to elevate these claims to wetware (or at least a smarter AI) I've never found it. For one thing, the "problem" may not be just this one page or object; I've had books with an element on hundreds of pages and told it's faulty on "pages 23, 41, 68 and 124." The next pass will name a few other, apparently random pages. It's Whac-a-Mole and can't be resolved.

The only thing you have going for you is that this is limited to the one page with that illustration. I would first make sure that NO element on that page is outside the margins, including invisible strays and legitimate elements that might be "almost" at or over the margin. Nudge everything in a tad, especially that page flag so that the text is more within the line. Rob's note that there may be a stray empty line below the visible text is a good one,

Good luck. I am battling almost exactly this same problem, with a book that uses thumb-tabs to locate chapters. KDP stubbornly refuses to accept them because "content is outside the trim line" — and I even converted the tabs from text frames to JPEG images so that they are not interpreted as 'content.' I will almost certainly have to solve the issue as several times before: delete the d*mn tabs.

Good luck to both of us. 🙂

[J E L]

FWIW, I have run into the same problem with KDP. The same element (close-to, but still within the trim line) found on one or two pages throws off the error when that exact element is the same on all the other pages. I've called support and they fixed it pronto!

[James Gifford—NitroPress]

KDP support has proven to be almost impossible to reach and then, for all of the usual reasons including that of outsourcing to heavily-accented countries that can only do things from the playbook in front of them, usually useless. But glad to hear you had a positive outcome; I think I had one, once.

It's like engaging any of the tech support systems where the reps are either not really up to the task, confined to a prewritten playbook or horribly burnt out, and from both training and experience start with the weary list of "Is the computer plugged in? Is it turned on?" level of 'help.' It takes forever to get them to agree that an anomaly is not going to bring Jeff's empire to rubble, and then if you're lucky they'll actually okay the exception.

Not really useful. I would happily pay or go through a vetting process or whatever to be able to reach someone up to speed, with an intelligible accent, who will listen to a reasonable claim, and is then empowered to either fully explain the problem from the production end or grant a waiver for reasonable variations.

Hell, I'd chip in on a team of technical writers who can keep up with the endless changes to the system and fully document all the features, requirements, errors, best-practices etc. The help system is a mix of extremely overwritten pages, pages only an internal developer can make sense of, and (far too much) outdated or 'lost' material that does not come up in a reasonable search for help. All connected with a spiderweb of links that will often send you in a frustrating loop without ever connecting to anything like the page with the answer you're looking for.

[J E L]

I'm sorry that was your experience. I've been successful many times. I submit my phone number with the account ID or whatever they require, and they call within the hour. 

[J E L]

Honestly, I don't know how this can't be helpful, but you do you, @James Gifford—NitroPress.

[James Gifford—NitroPress]

A callback, sometime later in the day, from someone with limited communication, limited range of action and no ability to understand a problem not outlined in their playbook is not terribly useful, no.

And the online help is a disastrous, mis-categorized, mess akin to an explosion in a three-story library. Yes, the answer is probably in there if you keep fishing for it long enough and don't lose patience being directed to the same four incomplete or outdated pages over and over.

Glad it works for you.

Note, perhaps, that I tend to do rather complex books. I'm sure those who do completely linear novels and narrative works have a much easier time of it. Maybe I just run into errors few other publishers trip.

ETA: And, not to keep piling on here, but there's a difference in a resolution that gets you to do something their way/within their automated approval system, and getting a resolution that is perfectly reasonable but requires some kind of override. I can usually work my way through the first, as I did on these thumb tabs — I know what they wanted, but I wanted to see if (for example) non-text characters would pass the safe-text rule. It's the ones where I want to do something perfectly proper, perfectly standard, perfectly tradtional, and even well-executed where the system arbitrarily says "No Way, Buster" — have yet to win on any of those, even when the cryptic errors are fully unraveled, and if you can explain the back-cover content issue above to me, in small words, I'll concede the whole topic here. 🙂

[James Gifford—NitroPress]

In something over a decade, I think I've had one "successful" interaction with KDP support. The back-cover blurb problem above was fumbled by two (IIRC) reps who weren't sure what a blurb was, but kept slowly explaining to me that I couldn't claim one edition/format to be a different one. I felt like I was in one of those old Shecky Greene routines where he's trying to get the four-year-old to give the phone to Daddy.

I'm not just having a grump attack here. Working around these KDP headaches is far, far too large a part of every project unless I stay with absolutely vanilla choices for everything. Having something as simple, traditional and necessary as numbered thumb tabs — well within the print margin — rejected by an utterly opaque error message means I lose even then.

But, OP problem solved, things learned, nuf sed.