KDP stripping custom fonts

[JSWolf]

Originally Posted by Hitch

Dude!!

I'm SHOCKED! You forgot "...and old and mean." I feel positively DISSED, I tell you. DISSED!

Hitch

Let's just say that when SOON you move to the retirement home, you'll be bringing the broom to bang on the ceiling. "You stop all that noise up there."

[Hitch]

Originally Posted by JSWolf

Let's just say that when SOON you move to the retirement home, you'll be bringing the broom to bang on the ceiling. "You stop all that noise up there."

Shit, Wolfie:

If I could AFFORD retirement, I wouldn't be so freaking cranky!!!!

Hitch

[JSWolf]

Originally Posted by Hitch

Shit, Wolfie:

If I could AFFORD retirement, I wouldn't be so freaking cranky!!!!

Hitch

I never said you'd retire. I bet you can still work from your room in the nursing home as long as you have net access.

[Hitch]

Originally Posted by JSWolf

I never said you'd retire. I bet you can still work from your room in the nursing home as long as you have net access.

LOL. Sad, but probably true.

(Which means, all you guys, I'll be here to haunt you for YEARS yet!!! MWHAHAHAHAHAH. )

Hitch

[dgatwood]

Originally Posted by GJ Coop

I have not yet succeeded with getting the font to embed despite changing to a couple of different Google Webfonts, that's .ttf fonts. One font became distorted so it looked like the hanging letters were dripping down the page in the .mobi in the desktop previewer, might have been tears, or blood. OK, for a crime book, I guess.

Sounds like a problem with the ascender/descender height not being calculated correctly, combined with an overly aggressive font renderer that tries to make lowercase letters taller for "increased" legibility. I've seen this myself. It's usually fixable by correcting the ascender/descender heights and other per-font metrics. That said, it could also be bad hinting.

Originally Posted by Hitch

Ah. Sorry, I misunderstood. I thought you meant six faces. DUHR. (Havign said this: I kid my fellow MR'ers not: we had a book come in today with NINETEEN FONTS. 19! Ye gods! I'm going to be trying to talk this guy down for a while, I can tell.)

Assuming you mean 19 font files and not 19 font families, that doesn't seem extreme at all to me, so long as they're used sensibly to distinguish different types of content. For example:

• Title page font family [plain, italic, bold]
• Chapter number font family [plain]
• Drop cap font family [plain or bold]
• Small cap font family [plain, bold, italic, bold italic]
• Body font family [plain, italic, bold, bold italic
• Block quote/sidebar heading font family [bold]
• Block quote/sidebar font family [plain, bold, italic, bold italic]
• Blank font for a warning that is visible only if the reader overrides your fonts

And you're up to 19 without even doing anything particularly unusual or heinous. That's not even counting fonts that replace missing glyphs in other fonts, for complying with font licenses that don't allow modifications....

What matters is not the number of fonts, but whether they're used sensibly. A work that changes fonts willy-nilly is going to look stupid even if you only have two or three fonts. A work that changes fonts in reasonable ways that make sense given the structure of the content is going to still look reasonable even if there are twenty fonts.

Originally Posted by JSWolf

Your @font is incorrect. This is how you have it.

@font-face {
font-family: "Abel";
font-style: normal;
font-weight: normal;
src: url("../Fonts/Abel-Regular.ttf") format("truetype");
}

And this is what is correct

@font-face {
font-family: "Abel";
font-style: normal;
font-weight: normal;
src: url("../Fonts/Abel-Regular.ttf")
}

As long as "../Fonts/Abel-Regular.ttf" is correct then it should work. You do not put the font format type in the src: line or any line in the CSS style.

There's nothing wrong with specifying the format in an @font-face src declaration:

http://www.w3.org/TR/css3-fonts/#descdef-src

It is strongly recommended for web content, but it matters very little for on-disk content, because the files are already downloaded. Either way, I can't imagine it hurting anything.

[Hitch]

dgatwood:

No, sadly: I meant families--not faces. ;-)

Hitch

[JSWolf]

Originally Posted by dgatwood

There's nothing wrong with specifying the format in an @font-face src declaration:

http://www.w3.org/TR/css3-fonts/#descdef-src

It is strongly recommended for web content, but it matters very little for on-disk content, because the files are already downloaded. Either way, I can't imagine it hurting anything.

It's CSS 3 code and not CSS 2.1. So it's not valid ePub 2 CSS.

[dgatwood]

Originally Posted by JSWolf

It's CSS 3 code and not CSS 2.1. So it's not valid ePub 2 CSS.

Actually, the full syntax predates CSS 2.1, and most certainly is valid EPUB 2 CSS. The @font-face declaration syntax appeared first in CSS 2.0 (complete with the optional format bits), as shown here:

http://www.w3.org/TR/1998/REC-CSS2-1...ml#referencing

Also note that web fonts are not in CSS 2.1 at all. They first appeared in 2.0, but were removed in 2.1, before eventually reappearing in 3.0. The EPUB 2.0 specification explicitly references the older CSS 2.0 documentation for @font-face rules for this reason.

As I said, the only HTML user agents I'm aware of that support @font-face without supporting the full syntax are Microsoft Internet Explorer versions 7.x and 8.x. I'd be shocked if you found an EPUB reader that doesn't support the full syntax. If one exists, it is badly broken and is not in proper compliance with the EPUB 2 specification.

[dgatwood]

Has there been any progress in this area? I just submitted three books to KDP in MOBI format, produced by KindleGen, and the "Preview Copy" that KDP send back had literally every font missing. It looks like for books with significant KF8 content, Amazon KDP's ingest process is broken beyond all repair at this point.

[Hitch]

Originally Posted by dgatwood

Has there been any progress in this area? I just submitted three books to KDP in MOBI format, produced by KindleGen, and the "Preview Copy" that KDP send back had literally every font missing. It looks like for books with significant KF8 content, Amazon KDP's ingest process is broken beyond all repair at this point.

@dgatwood:

No. I don't actually recall everything discussed in this thread; we're pretty well deep into it, ourselves, as we're one of the few commercial firms that will do fonts at all, so...

I can tell you that I just had a replication of the disaster I reported about some messages back, with a book with a serif, a sans-serif, and a "fancy" or display-type font (god help me, Chiller. You can't make this stuff up). All in, 7 total faces (reg, ital, bold for ea. serif and sans-serif) and Chiller. The book was stripped, stem-to-stern. We remade it just under 100x, trying everything we'd learned from the first disaster (not much, mind you, as troubleshooting doesn't seem to provide any sensible answers). Long story short, we ended up doing a serif + Chiller, removing the sans-serif.

There seems to be something--and this is pure speculation, as we've never been able to really GET anything from all the weeks of effort on this--that is a limit of some kind. We KNOW, factually, that there's a span limit of some type. We know that from the testing we did before; at some point, X number of spans "breaks" the book. (e.g., "span style="blabbety", at least, for FONT styling spans). We also know, factually, that this makes NO sense, because INDD-output ePUBs-->MOBI are loaded with spans, that don't seem to break the book.

My working theory is, there's a bug at the KDP that's triggered by encountering...SOMETHING. But the issue is, with so many variables, it's almost impossible to figure out what the hell that is. We have even gotten the point of testing with 3 paragraphs, one header and STILL can't figure out what triggers this odd behavior.

I also don't know if it's something in the CSS. (If you recall the issue that prompted the "help" thread, that was the first around this). We've tried to eliminate all the possibilities, in that arena, as well.

It's like bad aviation accidents--there are, I think, 3 things that have to somehow come together, to make it happen, but I don't know what those three things ARE. I never see this behavior with serif fonts, for example; we only seem to run into it when either:

--A particular font ITSELF doesn't work; e.g., Papyrus. If you replace the font, the problem is fixed, or,
--You have serif, sans-serif, and a display font. When this happens, nothing we try ever seems to "fix" the desired outcome.

We see this when we are using two fonts that work perfectly well (the serif and sans) in other books. So...something about adding the third font just causes chaos.

n.b.: both of the books that had massive issues with this, the second case in my short list above, had MASSIVE amounts of font interspersion, by which I mean, a lot of bold spans (b or spans) inside regular fonts, and a LOT of switching back and forth between serif and sans. So, many changes from font a to font b, and many changes from font a reg to font a italic or bold. I don't know if this is part of the issue, but our troubleshooting SEEMS to indicate that this stripping behavior persists, even if we are down to 3 paragraphs, one header and nothing else. Therefore, I don't THINK it's the number of changes from a to b, GENERALLY.

I'm sorry--I wish I knew more. I'm in the process of preparing yet another lengthy email to Amazon, with all our tests, advising "we tried this, we observed that, this happened, that didn't happen..." to see if they'll get back with us on it. They never did on the last one. Honestly--I think we may actually know more about it than they do, which is sad, because we know, to my mind, next-to-nothing.

Oh, a third/fourth instance: OTF is always a problem, so if you've tried OTF, convert them to TTF, and give that a go, or find a "true" TTF that's similar, and try that. Secondly, Adobe fonts are almost ALWAYS stripped, for some reason, I know not why. There's a guy on the KDP that has this quasi-consipiracy theory that all MS and Adobe fonts are being stripped, due to copyright (licensing) issues, but my experience doesn't support that idea; I've tested that pretty thoroughly, and it's not MS, certainly.

Sorry--wish I had more for you. What fonts were you trying, if I may ask?

Hitch

[dgatwood]

Originally Posted by Hitch

Sorry--wish I had more for you. What fonts were you trying, if I may ask?

With one exception, they were all my own custom fonts, based largely on SIL OFL-licensed fonts, but I've massively reworked the kerning, and in some cases added various 'calt' tables and other features to suit my purposes. Additionally, I corrected various font metrics so that the somewhat quirky font handling code in Kindle readers wouldn't render the fonts in a badly distorted way.

Some are OTF, some are TTF. Every font disappeared. Worse, most of them were still referenced, apparently, causing the online previewer to show square boxes where the letters should be. That's just not right....

KDP's import also mutilated my SVG text, changing the font size to approximately one point tall (unreadable). I can't even imagine what would cause that.

[Hitch]

Originally Posted by dgatwood

With one exception, they were all my own custom fonts, based largely on SIL OFL-licensed fonts, but I've massively reworked the kerning, and in some cases added various 'calt' tables and other features to suit my purposes. Additionally, I corrected various font metrics so that the somewhat quirky font handling code in Kindle readers wouldn't render the fonts in a badly distorted way.

Some are OTF, some are TTF. Every font disappeared. Worse, most of them were still referenced, apparently, causing the online previewer to show square boxes where the letters should be. That's just not right....

KDP's import also mutilated my SVG text, changing the font size to approximately one point tall (unreadable). I can't even imagine what would cause that.

OK: that's a completely *different* problem. The font-stripping problem removes the font folders, entirely, from the built mobi. You're using character slots outside of what Amazon has available, basically, sort of like Mandarin, if I had to guess. In other words, your Unicode is outside of their universe. Now, I could be completely wrong, but that's what happens when we see "custom" fonts, with unicode numbers out of their range. And before you ask, no, I don't know the outlines of their range, but I've certainly seen the effects.

Warning: I'm NOT a font expert. Not at all. You're obviously far more of one than I, I couldn't create a font if my life literally depended on it.

That being said, I know from unhappy experience that trying to use fonts that have any type of mapping outside of the usual (again, for example, some of the Mandarin font(s)),results in what you've described--the sad look of empty boxes. No font, because the device doesn't have the slot for it. (I think that part is right--can one of you massively geekier guys, like @Diap, etc., jump in here and confirm--it's the firmware, right? Rather than the hardware?)

And, again, unless I'm wrong, that SVG is not gunna work, certainly not for text. Not yet. Admittedly, because I have to make books that cover the spectrum, I don't play with SVG a lot (wish I could!), but....

Hitch

[NiLuJe]

@Hitch: Yep, the K2 is not a good citizen in terms of unicode coverage .

It's much, much better on anything KF8-capable, (i.e., FW >= 3.4), and especially on FW 5.x. Complex script shaping is still touch and go, though, but that's another matter entirely. (Note that I'm speaking solely of eInk devices here, since I have zero experience with anything else in Kindle-land).

Speaking of, FW 5.6.1 saw a serious update of the font rendering engine, so some of the weird quirks w/ custom fonts might have been alleviated on those FW. (Pure conjecture, I haven't updated anything to 5.6.x on my end).

[dgatwood]

Originally Posted by Hitch

OK: that's a completely *different* problem. The font-stripping problem removes the font folders, entirely, from the built mobi. You're using character slots outside of what Amazon has available, basically, sort of like Mandarin, if I had to guess.

Nope. US ASCII. No high ASCII characters, a handful of standard special characters like curly quotes, em dash, en dash, prime, double-prime....

My best guess is that the KF8 file that came out of KDP actually contained the embedded fonts, but in a badly broken form that caused them to act like they 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.

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 broken characters.

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....

[dgatwood]

Originally Posted by Hitch

OK: that's a completely *different* problem. The font-stripping problem removes the font folders, entirely, from the built mobi. You're using character slots outside of what Amazon has available, basically, sort of like Mandarin, if I had to guess.

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.