Months of Runaround From KDP Support: Font Embedding Fails...HELP!

[KevinH]

Hi Hitch,

I am not claiming it is the only rule and I am not claiming that it explains all cases. I am just saying it fits Peter's usage case almost exactly.

Since you have one example of something similar to Peter's strange case, did it in fact use or include a named font family on a p tag (not even necessarily an embedded font - Peter's was not) that could in fact have covered the bulk (50% or more) of the text, and then been made an implied "main" body font?

If so, that would confirm that mode of rejecting fonts, and we can then build a font tool of our own to test for cases like this.

Take care,

KevinH

[Peter Ahlstrom]

I'm going to do some more tests here today, if I can find the time.

I did notice both the "font does not exist!" and "invalid URL" issues from the log before, and tried everything I could think of to fix them. Since they went away when I got it to work, I considered them to be essentially bogus error messages.

There is definitely some kind of font-fix step in KDP before KDP's kindlegen is called. KDP will subset ttf fonts during that step (at least, in my previous book, KDP verifiably subsetted my two headings fonts, though it only included all the needed characters if they appeared early enough in the font file—I think I mentioned that earlier in this thread, or another one).

[Peter Ahlstrom]

Originally Posted by quiris

The algorithm that I use in my epubQTools (--myk-fix option) and I can confirm that it works in many many books prepared by this tool.

To avoid font stripping problem:
1) The main font must be set up for body tag.
2) The main font must not be used in other selectors except above body tag.
3) Use other fonts according your wishes
4) CSS style file with above styles must be linked with every XHTML file in ebook.

Well, I just tried this, and...it worked.

I had tried #1 before, and I had tried #4 before, but not at the same time. Combining all 4 steps definitely solved my problem.

To reiterate: I was embedding one font used for headers, but I was specifying a pre-installed font (Palatino or serif) to be used for most (but not all) of the body text.

Now I have Palatino specified in the body tag in the CSS file. I don't mention Palatino anywhere else in the CSS or the html (no wait, yes I did have it mentioned in a p style tag on the title page, and it still worked! I just now removed it from that tag since it's redundant, and this didn't make it stop working.) I now have only one CSS file. When I want to change the body font in other sections, I do that in div tags (in the CSS file).

All headers using the one embedded font are also explicitly classed, but that was from a different suggestion earlier in the thread, and it may not have anything to do with the success or failure of this book.

So anyway, what quiris said to do fixed everything for me. Thank you, quiris.

[KevinH]

Hi Peter,

My 2 cents ...

I don't think rule 2 is at all consistent with quiris's responses from KDP/PD and his test sample. In that particular test case actually adding the implied "main" font to the h1 tag prevented it from being converted from default and made font embedding work.

This is a direct violation of his rule 2:

2) The main font must not be used in other selectors except above body tag.

So you finding that it did not matter or cause problems in the p tag on the title page, seems to be consistent with what KDP/PD responded (and not with rule 2).

quiris, ... do you have an example where violating only rule 2) actually caused a problem?

Thanks,

KevinH

[shamanNS]

Sorry to barge in 2 weeks late, but here are my 2 cents:

Concerning rule 2): I'm not sure it that is really "a must" but if you set main font in body tag CSS there is no point and no reason to put the same font family in any other CSS classes.

One thing is certain: you should always declare main font family in body tag CSS, even when it is the only font used in entire book. After you've done that you're free to override and embed as needed.

[quiris]

Originally Posted by KevinH

quiris, ... do you have an example where violating only rule 2) actually caused a problem?

Currently I don't have an example, but I am absolutely sure that I had to remove all main font declarations (except body tag) to avoid font stripping problem during experiments a couple of months ago.

[dgatwood]

Originally Posted by shamanNS

Concerning rule 2): I'm not sure it that is really "a must" but if you set main font in body tag CSS there is no point and no reason to put the same font family in any other CSS classes.

Unfortunately, I'm pretty sure that's not true. We have no control over what random junk a reader vendor decides to put in their default stylesheet, so there's no guarantee that the font for H1 currently defaults to "inherit" on all reading platforms, much less that it will continue to do so. IMO, a proper level of paranoia requires you to explicitly specify the font for headings if it matters to you.

[shamanNS]

@dgatwood: I was speaking primarily about CSS & ebooks that are targeting Kindle devices. Also, it is matter of proper implementation of html and CSS, and there it shouldn't be a choice if by default child tag inherits from parent. CSS specification says that font-family is inherited. And body tag is top most parent.

I do agree that Amazon should fix their devices software to handle those situations which are "valid CSS" even if they are showing lack of basic understanding how CSS works. KDP guide does state that you should define main font in body tag CSS but that doesn't mean that things should fall apart in disastrous ways if someone codes their books (CSS) in redundant manner.

[dgatwood]

Originally Posted by shamanNS

@dgatwood: I was speaking primarily about CSS & ebooks that are targeting Kindle devices. Also, it is matter of proper implementation of html and CSS, and there it shouldn't be a choice if by default child tag inherits from parent. CSS specification says that font-family is inherited. And body tag is top most parent.

It has nothing to do with the spec's inheritance behavior; if the reader's stylesheet has:

PHP Code:

h1 { font-family: ... ; } 


then setting the font on the body won't do the trick. I don't entirely trust them not to set default heading fonts that are different from the body font in the future. After all, if it makes sense for book authors to do so...

[shamanNS]

Not sure what you mean when you write "reader's style sheet"? If you refer to "user agent style sheet" (= device/renderer defaults) then the "author style sheet" (= epub's css) has higher priority and overrides device defaults. Or are we talking about crappy mobile apps that are ignoring ebooks style sheet by abusing "!important"?

[dgatwood]

Originally Posted by shamanNS

Not sure what you mean when you write "reader's style sheet"? If you refer to "user agent style sheet" (= device/renderer defaults) then the "author style sheet" (= epub's css) has higher priority and overrides device defaults. Or are we talking about crappy mobile apps that are ignoring ebooks style sheet by abusing "!important"?

Yes, I mean the UA stylesheet. The author stylesheet has higher importance, true, but as I understand it, importance matters only for matching rules; they don't cause the author stylesheet's inherited values to be promoted higher than explicitly matching rules in the UA stylesheet.

Because your stylesheet doesn't provide any rules that match against the h1 tag (your body tag rule matches only on the body), and because the h1 tag's style has already been set to a value other than inherit by the UA stylesheet, that altered value from the UA stylesheet should win.

BTW, I just tested this using Safari, and that's the way it handles this conflict, which means it is very likely that every WebKit-based reader (including every KF8 reader, iBooks, etc.) is likely to handle it similarly.

The bottom line is that if you care about the font for a particular element, you must have at least one CSS rule that actually matches that element. If it is critical, be explicit.

The easiest way to fix it is probably to use "body, body *" instead of just body, but who knows how KindleGen will handle that.

[dgatwood]

Originally Posted by quiris

The algorithm that I use in my epubQTools (--myk-fix option) and I can confirm that it works in many many books prepared by this tool.

To avoid font stripping problem:
1) The main font must be set up for body tag.
2) The main font must not be used in other selectors except above body tag.
3) Use other fonts according your wishes
4) CSS style file with above styles must be linked with every XHTML file in ebook.

I made my CSS follow those rules. It still gets all the fonts stripped. I tried ensuring that all font styles appear only in the KF8 slice by wrapping them in an @media query. I even tried ripping out every fallback font that wasn't included in the EPUB book.

So there's definitely more to it than this. Perhaps the font stripping is triggered if any selector causes a font to be reset to the same font value that it was set to before, regardless of whether the font is the main font?

Perhaps they're using a CSS parser that's even more broken than the nightmare that KindleGen uses?

Compounding the problem is the fact that it is taking longer and longer to submit each file. I'm submitting test books with nothing but fonts, and they're taking more than twenty minutes each.... And it's only their site that's slow, so it isn't a problem on my end.

Originally Posted by KevinH

So they must then be unpacking the kindlegen using their own unpacking code, rebuilding an epub to result in font files being lost?

That's exactly what they're doing. When you create one sans-source and upload it, you can see the custom-built EPUB as the "source" if you extract the resulting MOBI file. Blech. For all the effort they expend trying to "fix" content that probably isn't broken even if the submitter went out of his or her way to make it hard for them to do so, you'd think they would at least have a lightweight escape hatch, where the submitter could say, "I know what I'm doing," and get KDP to pass the content through unadulterated.

For that matter, IMO, the threshold should probably be the fact that somebody submitted a MOBI file to begin with, instead of one of the more generic formats... but I digress.

[dgatwood]

Originally Posted by dgatwood

I made my CSS follow those rules. It still gets all the fonts stripped. I tried ensuring that all font styles appear only in the KF8 slice by wrapping them in an @media query. I even tried ripping out every fallback font that wasn't included in the EPUB book.

Moreover, I removed all CSS except for the CSS for the body tag and the CSS for the main body font, and it still failed.

body {
	font-family: "DG Didot", "New Century Schoolbook",
		"Century Schoolbook", "Bookman Old Style", Bookman, Serif;
}

@font-face {
  font-family: 'DG Didot';
  font-style: normal;
  font-weight: normal;
  font-kerning: normal;

  src: url('fonts/DGDidot/DGDidot-Regular.ttf') format('truetype');
}

@font-face {
  font-family: 'DG Didot';
  font-style: normal;
  font-weight: bold;
  font-kerning: normal;

  src: url('fonts/DGDidot/DGDidot-Bold.ttf') format('truetype');
}

@font-face {
  font-family: 'DG Didot';
  font-style: italic;
  font-weight: normal;
  font-kerning: normal;

  src: url('fonts/DGDidot/DGDidot-Italic.ttf') format('truetype');
}

@font-face {
  font-family: 'DG Didot';
  font-style: italic;
  font-weight: bold;
  font-kerning: normal;

  src: url('fonts/DGDidot/DGDidot-BoldItalic.ttf') format('truetype');
}

But bizarrely, removing the fallback fonts:

	font-family: "DG Didot", serif;

seems to have fixed the font stripping problem. However, I tried that before, and it didn't work. The only other significant change I've made since that prior attempt was changing:

  src: url('fonts/DGDidot/DGDidot-BoldItalic.ttf') format('opentype');

(which was technically wrong, but completely tolerated by every reader I tried) to:

  src: url('fonts/DGDidot/DGDidot-BoldItalic.ttf') format('truetype');

Neither change on its own was sufficient.

I'll know in a few minutes if these two fixes plus your four rules are sufficient or just necessary.

[dgatwood]

Originally Posted by dgatwood

I'll know in a few minutes if these two fixes plus your four rules are sufficient or just necessary.

Necessary, but not sufficient. And with it taking ten minutes or more to upload each file, it may take a while to figure out what else is going on.

[dgatwood]

Squirrelly doesn't begin to describe what I'm seeing from KDP:

body {
        font-family: "DG Didot", serif;
}

works, but:

body {
        font-family: "DG Didot", serif;
        -webkit-font-smoothing: antialiased;
        font-smooth: always;
        -webkit-font-smooth: always;
        -moz-font-smooth: always;
        -moz-osx-font-smoothing: grayscale;
        -webkit-line-box-contain: block inline replaced !important;
        line-box-contain: block inline replaced !important;
        text-rendering:geometricPrecision;
}

doesn't. Unfortunately, that code works around critical font rendering bugs in WebKit, many of which likely affect Kindle (untested).

Grr.

Edit: It looks like:

    text-rendering:geometricPrecision;

is the line that's breaking the online previewer.