KDP stripping custom fonts

[Hitch]

Originally Posted by dgatwood

If you mean my books, then no, it was straight US ASCII. No high ASCII characters except for a handful of entity-encoded bog-standard special characters like curly quotes, em dash, en dash, prime, double-prime, degree, and maybe one or two others.

My best guess is that the KF8 file that came out of KDP actually contained the embedded fonts, but in such a badly broken form that they effectively contained no glyphs.

On OS X, if you opened the file, it used the Mac font system, which correctly refused to open the broken fonts; the result was that it fell back to default fonts, hence it looked like the fonts had been stripped.

By contrast, Kindle Previewer on whatever platform the website uses (Linux?) is much dumber, and tried to use the broken fonts from the bundle, resulting in the missing glyph boxes.

Of course, this still raises the question of why an innocuous line of CSS asking for geometric precision in font rendering would cause KDP to spit out a MOBI containing corrupted font resources, but now that I know that it does, I've removed that line of CSS for now, and everything goes through cleanly, at least for me.

dg:

When you say:

On OS X, if you opened the file, it used the Mac font system, which correctly refused to open the broken fonts; the result was that it fell back to default fonts, hence it looked like the fonts had been stripped.

...what do you mean? Do you mean, KindlePreviewer on a Mac? Something else on a Mac? Can you clarify?

Hitch

[dgatwood]

Originally Posted by Hitch

dg:

When you say:



...what do you mean? Do you mean, KindlePreviewer on a Mac? Something else on a Mac? Can you clarify?

Hitch

Both Kindle Previewer on Mac and the normal Kindle reader app on OS X showed the book as normal text, but with fonts disabled.

My guess is that Kindle Previewer on OS X uses more native APIs than on other platforms. Alternatively, it could just be that there's a known bug in their font code that got fixed on OS X but not on whatever platform they're using for their server-side rendering. Or it could be that the OS X version of KP never got updated, and so never got broken by some regression.

BTW, it turns out that I lied earlier when I said that removing that line fixed all the problems. It fixed all the problems except for one: the micro-sized type in the SVG. That might be caused by font corruption, or it might be caused by something else. I'm still investigating.

Oh, and a random helpful tip: If you use the latest Kindlegen to build your books from an EPUB anyway, you can cut your upload time by about a factor of three by uploading the source EPUB instead of the MOBI.

Edit: scratch that last tip. You end up spending all the extra time waiting for processing on the server side. Apparently, their server's disk performance is abysmal.

[dgatwood]

I found the problem with the SVG, and it's the same issue as in this thread. Someone at Amazon should seriously be subject to a clue bat for not realizing that it is completely wrong to convert px units to rem when it involves inline CSS within an SVG tag.

Horrible, hackish workaround applied, and I've also added information about the bug to the KF8 tips page.

[dgatwood]

One more update; it turns out that the fonts weren't getting stripped out in my case. KindleUnpack v0.75 just didn't unpack the MOBI files correctly when used as a droplet. When I ran the script manually on the command line, all the files were there.

The font-family declarations, by contrast, were stripped. Why text-rendering:geometricPrecision would trigger font stripping is beyond me, but I've already concluded that I'll never understand the way the Amazon Kindle folks think....

But now I'm even more baffled why the online Kindle Preview displayed square boxes instead of glyphs afterwards, unless perhaps WebKit's handling of "text-rendering:geometricPrecision" causes the Kindle's built-in fonts to break their font handling code for some reason.