Months of Runaround From KDP Support: Font Embedding Fails...HELP!

[Tony_A20]

Originally Posted by Peter Ahlstrom

I had a weird error with KDP and font embedding yesterday. KDP reencoded the fonts (that I was using for headings) and stripped out unused letters—except some of the "unused" letters were actually used on an html file toward the end of the ebook, and viewing the Paperwhite view in Kindle Previewer had those letters replaced with a default font. It looked terrible. (On the Kindle Fire preview pages, it was loading the font from my computer, so the error wasn't visible.)

I fixed this by making a "display:hidden" paragraph on the title page of the book that used all of those letters. Now the previously missing letters are embedded correctly and displayed fine on that late html file. The only letters that are missing from the embedded fonts now are the ones that are actually not used in the book.

Before I got this error, my fonts were refusing to embed at all (after running through KDP; kindlegen embedded them fine). I fixed that error by following the advice earlier in this thread: explicitly classing any tag that used an embedded font and getting rid of multiple-classed tags.

That seems like a good trick to use in a pre-emptive manner. I've added a single line paragraph of the upper and lower case alphabet for each of the two embedded fonts I'm using.

<p class="font1" style="display: none;">abcdefghijklmnopqrstuvwxyz…etc</p>

I haven't tried to upload through KDP yet, but with Hitch's warnings ringing in my ears I think your fix is something to use. Thanks.

Tony

[Hitch]

Originally Posted by Tony_A20

That seems like a good trick to use in a pre-emptive manner. I've added a single line paragraph of the upper and lower case alphabet for each of the two embedded fonts I'm using.

<p class="font1" style="display: none;">abcdefghijklmnopqrstuvwxyz…etc</p>

I haven't tried to upload through KDP yet, but with Hitch's warnings ringing in my ears I think your fix is something to use. Thanks.

Tony

Make SURE you test everything you have "hidden" on real, no-kidding iOS devices. Seriously.

Hitch

[Peter Ahlstrom]

I wouldn't do the hidden thing (preemptively) unless KDP was definitely dropping individual characters like it was in my case.

And yes, I tested the azk file on my iPad, and the hidden paragraph stayed hidden. (I've never had problems with hiding things before, but I'll be careful to test this in the future.)

In my case, this is the code I used:
<p style="display:none;"><span style="font-family:font1">poiqwenmZWJ,</span><span style="font-family:font2">s</span></p>

I could have used classes, but my defined classes were only for heading styles, so it was quicker just to use style tags.

I don't mind doing a favor to the font designer by not embedding the characters that aren't in the book. (font2 had been properly embedding all used characters except for the lowercase s; font1 had been embedding many fewer characters than it was supposed to.) In fact, I sometimes do this by extracting the embedded font from the PDF of the print version of the book, so the ePub version also does not include the unused characters.

[Hitch]

Originally Posted by Peter Ahlstrom

I wouldn't do the hidden thing (preemptively) unless KDP was definitely dropping individual characters like it was in my case.

And yes, I tested the azk file on my iPad, and the hidden paragraph stayed hidden. (I've never had problems with hiding things before, but I'll be careful to test this in the future.)

In my case, this is the code I used:
<p style="display:none;"><span style="font-family:font1">poiqwenmZWJ,</span><span style="font-family:font2">s</span></p>

I could have used classes, but my defined classes were only for heading styles, so it was quicker just to use style tags.

I don't mind doing a favor to the font designer by not embedding the characters that aren't in the book. (font2 had been properly embedding all used characters except for the lowercase s; font1 had been embedding many fewer characters than it was supposed to.) In fact, I sometimes do this by extracting the embedded font from the PDF of the print version of the book, so the ePub version also does not include the unused characters.

We've had iOS weirdness with the KF7 versions for iOS displaying things (not necessarily fonts, but just generally) that were supposed to stay "hidden," so it's a warning I give everyone who plans to hide something. It might be fixed now, but a year ago, it was giving me major agita.

I routinely subset fonts. For a million good reasons, but half because the filesize is better when large fonts are subset. The other is naturally, to protect the font designer.

I'm glad that it all worked out for you.

Hitch

[Peter Ahlstrom]

New book, new problem.

I was having the same font embedding problem with KDP as before, but the workaround was not functioning. After much trial and error (I commented out all font-family lines in the CSS and then added them back in one-by-one, then made a new CSS file with the offending line included and applied it to the html files one-by-one until it stopped working), I now have a book file where the custom font works in one half of the book but not the other half.

The offending line? Setting the font-family of the p (whether classed or unclassed) to Palatino,serif (just using the Palatino font installed on the device). If that CSS is included in the second half of the book, KDP strips out all font-family references and deletes my custom header font entirely.

"half of the book" gives a very strange effect.

• If I take the first non-working chapter and paste its entire contents into a previous chapter's file, using the Palatino font CSS in that pasted file, the font embedding works.
• If I take the first non-working chapter and duplicate it in place, then change the CSS link in the first copy of the chapter, but not the second copy, the font embedding still works. If I then delete the second copy, the font embedding now fails again.
• If I take my file and delete all the chapters after the last one that works, and upload only a half document (I made sure to also delete the now-unused images and TOC references), the fonts get stripped again.
• If I remove the CSS from the last 3 working files, and then add it to the first non-working file, the fonts embed correctly. But then if I add it to the second non-working file, it doesn't embed correctly.
• If I remove the CSS from a few more files, then add it to the last file (which is the longest html file), the embedding works. But I have to remove the CSS from exactly enough earlier files.

I also tried two methods of defining the font. One file version had the font defined in a div around all the paragraphs, and one version had the font defined for the p tag with no divs. In both cases, it works only when this is applied to one half of the book and fails as soon as that CSS is applied to one more html file after the halfway mark.

I also replaced the file completely with the book I talked about a few posts ago (a book that has 2 custom header fonts and specifies Palatino,serif for the p tag throughout)—and everything displays as expected.

This is complete nonsense. I enjoy a challenge, troubleshooting something where certain actions lead to predictable results. Here, the only predictable thing is that I can get the font to work in one half but not the other half. But only on this book, not on any previous book I've made. It's maddening.

Now, you may say "Well, just don't define the font for p." That's relatively fine on Kindle Fire and iOS, since the default font there is a serif font. But on Kindle Paperwhite the default font comes up sans-serif if I leave it undefined. I want to use sans-serif for each chapter's introductory text and then serif when the chapter proper starts. All previous Kindle books I've made have no trouble setting the p font as Palatino,serif. Why this book is suddenly different is driving me up the wall.

And yes, just converting through Kindle Previewer keeps all the fonts correctly. It's only uploading to KDP that produces the problem.

[Hitch]

Yes. That. ^

We've had this happen with fonts that we KNOW work. We had it happen with Arial, in a book, almost exactly; it worked for X chapters, and then just stopped working. We tried the same sort of 'bracket navigation' troubleshooting that you did--if we removed it from the previous chapter, it worked. If we added that chapter back in, it stopped working. EVERYTHING you tried, we tried.

We also tried specifically defining the body font; we tried defining it for P; we tried using spans. Spans seem to have a "limit" of some kind, but again, that's based on this particular book. I've posted about this before; it seems contraindicated, because, then, if that's true, WTH is happening with all those INDD books, which are spanned-to-death?

We ended up switching out two "foofy" fonts--they were a calligraphy font and a h/w font--and swapped up to other fonts. The damn book just wouldn't work. I still do not know, to my satisfaction, the WHY. Just like you don't know the WHY.

There is something, somewhere, in the KDP that barfs. I don't have a clue what it is, but...when the mobi is parsed, something goes wrong, and not consistently. Not consistently with particular fonts, either. Nor with the same font, on different books. And, yes: it's in the KDP, not KG/KP. At the build, it looks PERFECT; it's only after upload that everything has gone awry.

Sorry this isn't helpful, in reply, but I wanted you to know that the moment I saw your post, I knew exactly what had happened, at least, in terms of symptoms, if not diagnoses. Let me guess: setting your "body font" to serif isn't working for you, for PPW, either?

Hitch

[Peter Ahlstrom]

Yep. I tried it in the body tag too, and spans. No dice.

At this point, I've essentially thrown in the towel and declared that some chapters will look a bit different than others. Far less than ideal, but since this is an anthology with different authors, it shouldn't be too jarring for the readers if some of the authors' stories look different from the others'.

Sigh.

[KevinH]

Hi Peter,
Have you tried using a "diff" tool on the rawml and headers generated by running KindleUnpack with raw and dump flags enabled on both the working kindlegen version and the half-working KDP version? As you unpack you can copy the full log of the output to files as well and "diff" those as well.

It may tell you something. Alternatively, if you can post both versions someplace and pm me I would be happy to do that and see if anything jumps out at me.

Take care,

KevinH

Originally Posted by Peter Ahlstrom

New book, new problem.

I was having the same font embedding problem with KDP as before, but the workaround was not functioning. After much trial and error (I commented out all font-family lines in the CSS and then added them back in one-by-one, then made a new CSS file with the offending line included and applied it to the html files one-by-one until it stopped working), I now have a book file where the custom font works in one half of the book but not the other half.

The offending line? Setting the font-family of the p (whether classed or unclassed) to Palatino,serif (just using the Palatino font installed on the device). If that CSS is included in the second half of the book, KDP strips out all font-family references and deletes my custom header font entirely.

"half of the book" gives a very strange effect.

• If I take the first non-working chapter and paste its entire contents into a previous chapter's file, using the Palatino font CSS in that pasted file, the font embedding works.
• If I take the first non-working chapter and duplicate it in place, then change the CSS link in the first copy of the chapter, but not the second copy, the font embedding still works. If I then delete the second copy, the font embedding now fails again.
• If I take my file and delete all the chapters after the last one that works, and upload only a half document (I made sure to also delete the now-unused images and TOC references), the fonts get stripped again.
• If I remove the CSS from the last 3 working files, and then add it to the first non-working file, the fonts embed correctly. But then if I add it to the second non-working file, it doesn't embed correctly.
• If I remove the CSS from a few more files, then add it to the last file (which is the longest html file), the embedding works. But I have to remove the CSS from exactly enough earlier files.

I also tried two methods of defining the font. One file version had the font defined in a div around all the paragraphs, and one version had the font defined for the p tag with no divs. In both cases, it works only when this is applied to one half of the book and fails as soon as that CSS is applied to one more html file after the halfway mark.

I also replaced the file completely with the book I talked about a few posts ago (a book that has 2 custom header fonts and specifies Palatino,serif for the p tag throughout)—and everything displays as expected.

This is complete nonsense. I enjoy a challenge, troubleshooting something where certain actions lead to predictable results. Here, the only predictable thing is that I can get the font to work in one half but not the other half. But only on this book, not on any previous book I've made. It's maddening.

Now, you may say "Well, just don't define the font for p." That's relatively fine on Kindle Fire and iOS, since the default font there is a serif font. But on Kindle Paperwhite the default font comes up sans-serif if I leave it undefined. I want to use sans-serif for each chapter's introductory text and then serif when the chapter proper starts. All previous Kindle books I've made have no trouble setting the p font as Palatino,serif. Why this book is suddenly different is driving me up the wall.

And yes, just converting through Kindle Previewer keeps all the fonts correctly. It's only uploading to KDP that produces the problem.

[Peter Ahlstrom]

I sent you a private message, Kevin. Thanks.

[quiris]

The algorithm that I use in my epubQTools (--myk-fix option) and I can confirm that it works in many many books prepared by this tool.

To avoid font stripping problem:
1) The main font must be set up for body tag.
2) The main font must not be used in other selectors except above body tag.
3) Use other fonts according your wishes
4) CSS style file with above styles must be linked with every XHTML file in ebook.

[Hitch]

Originally Posted by quiris

The algorithm that I use in my epubQTools (--myk-fix option) and I can confirm that it works in many many books prepared by this tool.

To avoid font stripping problem:
1) The main font must be set up for body tag.
2) The main font must not be used in other selectors except above body tag.
3) Use other fonts according your wishes
4) CSS style file with above styles must be linked with every XHTML file in ebook.

Quiris:

Have you run into the bizarro-world font-stripping issues, as described by Peter in his most recent post? And has what you've said, above, fixed it? I'm asking because, AFAIK, we've tried this, on that one book that I mentioned--the one I could never wrangle into submission--and it didn't work.

Hitch

[quiris]

Hitch, the algorithm was used on several dozen ebooks with many different main fonts with success. Of course I can not guarantee that it will be work on every book.

[Hitch]

Originally Posted by quiris

Hitch, the algorithm was used on several dozen ebooks with many different main fonts with success. Of course I can not guarantee that it will be work on every book.

Quiris:

I wasn't looking for a guarantee. I was wondering if you'd run into the same issue or phenomena that Peter and I have described. I'm not dismissing the "several dozen eBooks;" but in 2500+ ebooks, I've had ONE that had this issue. I've had others that had the infamous font-stripping problem, and we found that if we replaced a particular font, the issue ceased (e.g., Papyrus, which I can guarantee is devil-spawn at KDP, amongst others). However, this ONE book, the one that was almost identically symptomatic as Peter's--nothing worked.

We had to remove the Arial, period. We ended up going with a serif body font, and identifying the two "speakers" by using italics versus regular, and then, and only then, did the two other fonts, the calligraphy and the h/w fonts, work. It was absolutely bizarre, in terms of trouble-shooting. We spent several hundred manhours--literally--trying to tame this thing. We put two different crews on it. Nothing, and I mean, NOTHING, worked.

So, that's why I'm asking if you've even SEEN this. For any competent bookmaker, it's just not that common. Can you clarify what you mean when you say, "above," in your 2? You mean, only in headings, or...? I'm not following your intent.

Hitch

[quiris]

Hitch, answering your question: No, I don't see such strange problem.

it's just not that common. Can you clarify what you mean when you say, "above," in your 2? You mean, only in headings, or...?

I mean that main font must be used only for styling body tag.

[Hitch]

Originally Posted by quiris

Hitch, answering your question: No, I don't see such strange problem.


I mean that main font must be used only for styling body tag.

OK, so:

You mean, you could not, for example, use Arial at 1em for the body, and Arial @3em for an h1? Not to be pedantic, just clarifying your express intent.

Hitch