Quote:
Originally Posted by NiLuJe
I think Hitch is aware of that, since I dimly remember bringing it up here once before, but one reason KDP might be so finicky with custom fonts is the (heavily? weirdly? patched) font rendering engine used on the eInk Kindles. Since the K3, we (when playing with custom font hacks) have demonstrated that it sometimes horribly mangles some fonts, or just plain crashes when rendering some fonts. And it's specifically an issue with Amazon's patches, since replacing the library responsible for font rendering with a recent vanilla copy miraculously solves everything (well, except truetype fonts with broken bytecode, of course, but those are relatively few and far between, and easy to check for, since they're broken on anything using FreeType's BCI).
Don't ask me why they haven't bothered fixing it since the K3, though ;D. Although they did close a somewhat easily accessible undocumented entry point for system-wide user-configurable custom fonts at one point of FW 5.x's life, probably for that reason.
|
Yes, and another change has been made, recently, by Amazon, at the KDP (within the last 7-10 days). Books that worked fine, last week, will have fonts stripped, this week. I haven't sourced it yet, but seriously: a book that would upload and display the embedded fonts perfectly 7 days ago will not now--same file. It's enough to make your teeth grind. they also did more "fixing" to the SRL, so everbobdy: your workarounds for THAT aren't working any longer, either, if you were using workarounds. Amazon actually knows that they broke THAT, because they are telling publishers--wait for it--that yhey are fixing the SRL's MANUALLY.
We haven't quite figured out what's changed (back to fonts). Depending on the book-building method, some (zipped html files) are working, but KP- and KG-built mobi's aren't (from the SAME source files, mind you). It's enough to make ya take up serious drinking.
Oish.
Hitch