Hi Peter,
I examined your not-working example and can see that they did just completely strip the font out. The build.log embedded in the src shows the error was that your custom font is actually missing (can't be found!) And if you look at the embedded src archive you can see the font file is not there. So the problem is in the KDP process but it occurs before they run it through their special version of kindlegen.
So they must be unpacking and preprocessing the submitted epub in some way before processing it and when they put it back together they drop the fonts for some minor error.
If you submit a mobi, they must do the same process to its embedded source.
Have you tried submitting a mobi generated by kindlegen where you use the -dontaddsouce option? This should prevent them from preprocessing an epub and hopefully prevent the issue.
Also after reading what you wrote, I am betting, the issue is not the amount of text but which style sheet is linked-in the most often. I am guessing, whichever one is linked-in more often becomes the "main" sheet and as long as the main sheet does not have an issue and the font urls are there, embedding will be more likely. You could try subsetting all of the truly embedded fonts and urls into their own sheet and link that sheet into all documents, and moving the non-embedded font-face to it own sheet and only linking to it when necessary.
All of what I said is at least not inconsistent with what you said in your post. My theory is some preprocessing code somewhere is looking for a "main" sheet and the main sheet must be absolutely perfect otherwise pieces of it are ignored and the embedded fonts are never found.
And interestingly, a specific metadata element is added when embedded fonts are included:
528 : 'override-kindle-fonts_(528)',
When fonts are embedded this metadata item is set to "true". What is interesting here is that it literally says the the kindle device should "override" its fonts not "augment" them.
So something else to try is to also embed a Palitino font as a test to see what if any impact it has an the problem (so all named font faces with specific (non-generic) names are embedded).
If anyone knows anyone involved at Amazon, would you please check if they pre-process submitted epubs in any way before passing them to their internal kindlegen for KDP, cause its build log indicated that the font itself never made it and that was why it was "stripped-out".
I will keep looking but I don't use KDP and using kindlegen 2.9, all works as expected so I can't debug the process first-hand.
Hope something here helps.
KevinH
Quote:
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. |