Hi,
I'm afraid not. I was hoping for some additional error messages in the kindlegen build log to provide hints as to what the underlying issue really is. Unfortunately, there seems to only be the log built *after* the fonts have been stripped.
So unless KDP provides you with some additional information about what errors they are seeing it or why the fonts were stripped, we are stuck coming up with theories and then testing them via KDP runs.
I am truly surprised that submitting a kindlegen ebook without added source runs into the same problem. Is there one website or set of reference that describes the rules you and others have devised by trial and error to try to maximize the chances of success with an embedded font? There may be some overlap among them that might hold a clue. Other than that we are stuck debugging a black box. The ones that fail, remove the font so nothing useful is generated by their special kindlegen run. The ones that succeed have no problem.
Peter's test case is an interesting one in that changing just one more xhtml file from linking in one stylesheet to a very very similar stylesheet is enough to break the process, eventhough both stylesheets are valid and very nearly identical. And there does seem to be a 50% rule of some sort in play here, but it is not a max text limit, just a proportion limit. If Peter adds extra pages using the one style sheet, he can add the same number of extra pages using the other, and the fonts will stay, but if he changes just one more to use story.css instead of style.css, all fonts are stripped. So one of the differences between the two css sheets is somehow involved in this 50% rule, but I am still not sure which ones as there were a small handful of rules in style.css that did not exist in story.css. If Peter is right and it is the use of the Palatino font face, then it must in some way be related to how it is being used.
I will keep looking.
Take care,
KevinH
|