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

[Mathew Reuther]

I've been trying to get font embedding to work in my books (for KDP) for months with no success. KDP support has said "we're busy researching" or "you're doing it wrong, do it like we say"...

The problem is that from the VERY beginning I have done it the way they say to do it. They say that they "recently changed" how embedding is supposed to be specified, but that is how I have always done it, because the way Kindle handles it is to specify in CSS, which is exactly how it's done for epub.

I create in Sigil, and upload and epub (with a couple of small format changes like the cover image being large and not declared as a separate html file and metadata switch to mobi format) to KDP. When the resultant file is produced, fonts have been completely stripped. (Confirmed using MobiUnpacker.)

I have tried using different fonts, and different types of fonts. My files convert cleanly in Kindle Previewer (in Windows) and Calibre. The resultant mobi files, when uploaded to KDP, have the fonts stripped from them.

I have spent literally weeks of work on this issue to no avail. I've tried dozens of different options of what type of font, which font, what converter I run a font through, etc. Nothing matters.

I am at a complete loss as to why this is happening. I have slammed my head against the wall of KDP support for months, and am quite frankly left with 3 options. 1) ask here, 2) try and strike a deal with a "pro" to embed the fonts (I need literally no formatting, just the fonts to survive upload), or 3) chew my way further up the Amazon chain.

So, as far as following the guidelines go, I have declared @font-face as Amazon recommends (the only place they talk about it is in their fixed-layout section, but relatively obviously, it's how you need to declare for a normal ebook as well.

An example of how I am calling fonts in the books:

(obviously in Styles\core-styles.css)

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

As it should be, the .ttf, or .otf file I refer to is always contained in the Fonts directory. I have verified that these fonts are then absent in the files which come back from Amazon's KDP converter. (I have also attempted to remove the font-weight and font-style css elements to no avail. They don;t seem to make a difference one way or another for this issue.)

When I call a font, I am doing so like this:

p.toc-minor {
font-family : display-font;
text-indent: 0;
margin: 0 0 0.2em 0;
font-size: 125%;
}

The css styles are then called in the html files like so:

<p class="toc-minor"><a href="../Text/TitlePage.xhtml">Title Page</a></p>

This should result in a slightly larger than normal, unindented display font version of the words "Title Page" that has only a small bottom margin. That's in fact exactly what it does...everywhere but on the KDP-converted file.

***

I appreciate any wisdom that anyone might possibly be able to share. I am an absolute perfectionist where it comes to getting things to display as well as possible cross-platform. I am attempting to follow the feel of the print version and make it so that ebook buyers at Amazon have an experience similar to those at Barnes & Noble or Kobo, or wherever.

But at this point I am completely baffled by why I can format something perfectly (even using Amazon's own desktop software) and have it fail time and time again on upload.

KDP support is convinced that my code is the problem. But if that's the case, they have yet to be able to point out exactly what I'm doing wrong. Maybe one of you can.

[Mathew Reuther]

Oh, and as a note: Sigil automagically declares fonts in relevant manifest section, so that's being handled. (Just in case someone thinks "hey, that needs to happen..." it has, just not hand-coded.)

[DiapDealer]

Exactly what version of the ebook are you "getting back" from KDP? And what do you view it with? If it's a MOBI-only version (and not the KF8 version), that would explain why the fonts are gone. MOBI doesn't support embedded fonts.

I ask because I have no idea how KDP works.

[Mathew Reuther]

Originally Posted by DiapDealer

Exactly what version of the ebook are you "getting back" from KDP? And what do you view it with? If it's a MOBI-only version (and not the KF8 version), that would explain why the fonts are gone. MOBI doesn't support embedded fonts.

I ask because I have no idea how KDP works.

For some reason quick reply ate my reply!

Thanks for the reply. I appreciate it! I am in fact referring to the KF8 half of the resultant .mobi file Amazon returns. In the version generated by Amazon's Kindle Previewer (which is their KindleGen with a GUI) I can use MobiUnpacker to verify that the fonts have been included in the appropriate location.

But in the version I retrieve from Amazon after KDP has thrashed on it, those fonts have indeed been stripped.

[RbnJrg]

Originally Posted by Mathew Reuther

An example of how I am calling fonts in the books:

(obviously in Styles\core-styles.css)

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

As it should be, the .ttf, or .otf file I refer to is always contained in the Fonts directory. I have verified that these fonts are then absent in the files which come back from Amazon's KDP converter. (I have also attempted to remove the font-weight and font-style css elements to no avail. They don;t seem to make a difference one way or another for this issue.)

When I call a font, I am doing so like this:

p.toc-minor {
font-family : display-font;
text-indent: 0;
margin: 0 0 0.2em 0;
font-size: 125%;
}

The css styles are then called in the html files like so:

<p class="toc-minor"><a href="../Text/TitlePage.xhtml">Title Page</a></p>

Maybe with the font-family name inside quotes, things will work. Try this:

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

And:

p.toc-minor {
    font-family : "display-font";
    text-indent: 0;
    margin: 0 0 0.2em 0;
    font-size: 125%;
}

Of course, I suppose that core-styles.css is properly linked to the .html files where your custom fonts are used. Also I would change the "core-styles.css" name; maybe core_styles.css could be better.

Regards
Rubén

[Mathew Reuther]

Originally Posted by RbnJrg

Maybe with the font-family name inside quotes, things will work.

Of course, I suppose that core-styles.css is properly linked to the .html files where your custom fonts are used. Also I would change the "core-styles.css" name; maybe core_styles.css could be better.

Regards
Rubén

Thanks for the suggestions. I just noticed that I was trying both ways in one file (with and without quotes) so I standardized and it still made no difference, unfortunately.

As far as the pointer, yes, it's fine. And the name should be irrelevant considering it's able to read all styles. Literally the only issue is the fonts. All the other CSS works perfectly.

But thanks a ton for taking the time to offer suggestions. I really appreciate it!

[Hitch]

Originally Posted by Mathew Reuther

Thanks for the suggestions. I just noticed that I was trying both ways in one file (with and without quotes) so I standardized and it still made no difference, unfortunately.

As far as the pointer, yes, it's fine. And the name should be irrelevant considering it's able to read all styles. Literally the only issue is the fonts. All the other CSS works perfectly.

But thanks a ton for taking the time to offer suggestions. I really appreciate it!

I saw your post on the KDP forums, and I have to ask: why aren't you simply converting the ePUB with KG or KPreviewer and uploading the resulting mobi file, which will prevent the loss of fonts? Why are you uploading the source ePUB instead of the completed book?

P.S.: You are declaring the font-faces first in your stylesheet, right? Above everything else? And, where's your format declaration? (truetype or opentype?) And you're not using Type1's, right?

Hitch

[Mathew Reuther]

Originally Posted by Hitch

I saw your post on the KDP forums, and I have to ask: why aren't you simply converting the ePUB with KG or KPreviewer and uploading the resulting mobi file, which will prevent the loss of fonts? Why are you uploading the source ePUB instead of the completed book?

P.S.: You are declaring the font-faces first in your stylesheet, right? Above everything else? And, where's your format declaration? (truetype or opentype?) And you're not using Type1's, right?

Hitch

I thought I was clear, but in any case, yes, I can convert to mobi and upload and the fonts are still stripped. (Verified present after conversion via Previewer/Calibre, verified stripped after KDP.)

The font faces are declared in the core-styles.css which is referenced by the html. They are right up at the top. They are not type 1s (I tossed a type one out, actually), and it does not matter if I use open type or true type as the results are the same (fonts stripped)... (I must note that I have alternating read posts by people who swear by one or the other, do you have a suggested type? converting is not a huge issue, after all.) All told I've tried about 10 fonts, multiple file formats of many of them, and none of survived.

If you have a suggested font format (otf/ttf) I will certainly go from there as I continue to try and troubleshoot. But the Kindle Previewer does not throw a single warning on the fonts I'm working with currently, so I am at a loss as to why they're not making it through KDP. :/

I even tried specifying a body font on the off chance that KDP was requiring one before allowing header/display fonts to be used, but that didn't work.

I am literally open to any suggestions or tips.

Thanks a ton for replying!

(P.S. I realized I missed answering one question. The fonts are in the manifest, of course.)

[Hitch]

Originally Posted by Mathew Reuther

I thought I was clear, but in any case, yes, I can convert to mobi and upload and the fonts are still stripped. (Verified present after conversion via Previewer/Calibre, verified stripped after KDP.)

The font faces are declared in the core-styles.css which is referenced by the html. They are right up at the top. They are not type 1s (I tossed a type one out, actually), and it does not matter if I use open type or true type as the results are the same (fonts stripped)... (I must note that I have alternating read posts by people who swear by one or the other, do you have a suggested type? converting is not a huge issue, after all.) All told I've tried about 10 fonts, multiple file formats of many of them, and none of survived.

If you have a suggested font format (otf/ttf) I will certainly go from there as I continue to try and troubleshoot. But the Kindle Previewer does not throw a single warning on the fonts I'm working with currently, so I am at a loss as to why they're not making it through KDP. :/

I even tried specifying a body font on the off chance that KDP was requiring one before allowing header/display fonts to be used, but that didn't work.

I am literally open to any suggestions or tips.

Thanks a ton for replying!

(P.S. I realized I missed answering one question. The fonts are in the manifest, of course.)

Matt(hew):

The only thing I see, at all--and of course, none of us are looking at the actual ePUB--is that after your font calls, you don't have the actual type declaration, e.g.:

	src:url("../Fonts/OratorStd.otf") format("opentype");

...as the last line in the CSS for each font. The format () part. And not to be a pain, but can you give us how you manifested them? I don't see anything overtly incorrect with your coding, and we use embedded fonts in mobis all the time. I mean, ALL the time, for title pages, chapter heads, etc.

Hitch

[Mathew Reuther]

Be as exacting as you'd like. I am not bothered at all. I was not aware that there was a (format) argument which could even be included. Is that something you typically use? I've never seen it laid out like that. Do you recommend using that format declaration as a standard in your css? (and what is the format declaration then for truetype? "truetype"?

As for the mainifest, here is an example of what they look like. This is, mind you, auto-generated by Sigil...I do not hand code it:

(inside the manifest section of the content.opf file)

<item href="Fonts/display-font.ttf" id="display-font.ttf" media-type="application/x-font-ttf" />

<item href="Fonts/header-font.otf" id="header-font.otf" media-type="application/vnd.ms-opentype" />

Now, as a test, if you could just tell me the name of a font or two that you know will work that come from a source that is free (fontsquirrel, dafont, google fonts, etc.) I can try to use those and see what happens. That way we know that the fonts themselves DO work in another file.

[RbnJrg]

Originally Posted by Mathew Reuther

Be as exacting as you'd like. I am not bothered at all. I was not aware that there was a (format) argument which could even be included. Is that something you typically use? I've never seen it laid out like that. Do you recommend using that format declaration as a standard in your css? (and what is the format declaration then for truetype? "truetype"?

As for the mainifest, here is an example of what they look like. This is, mind you, auto-generated by Sigil...I do not hand code it:

(inside the manifest section of the content.opf file)

<item href="Fonts/display_font.ttf" id="display_font.ttf" media-type="application/x-font-ttf" />

<item href="Fonts/header_font.otf" id="header_font.otf" media-type="application/vnd.ms-opentype" />

Now, as a test, if you could just tell me the name of a font or two that you know will work that come from a source that is free (fontsquirrel, dafont, google fonts, etc.) I can try to use those and see what happens. That way we know that the fonts themselves DO work in another file.

Ah, ah, ah. It seems that we have something here According to your manifiest, you are declaring the font as:

href="Fonts/display_font.ttf"

But you, ARE USING in the path, in @font-face:

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

Can you see? You are using "display-font.ttf" in @font-face but in the manifiest the font is refered as "display_font.ttf"

It seems that here could be the cause of your troubles. Use "display_font.ttf" and "header_font.otf" for all declarations. Also, if neccesary, rename the fonts in your Fonts folder.

Regards
Rubén

[Mathew Reuther]

This is a typo/mismatch that is happening in this thread, not in the file. Thanks for noting it. I've corrected my latest post just for consistency.

(In case it's not clear, I am using placeholder names for the fonts as the actual font names are not overly relevant...I have tried many different fonts, all with the same result. So I am looking at the entire thing as an abstract.)

[Hitch]

Originally Posted by Mathew Reuther

Be as exacting as you'd like. I am not bothered at all. I was not aware that there was a (format) argument which could even be included. Is that something you typically use? I've never seen it laid out like that. Do you recommend using that format declaration as a standard in your css? (and what is the format declaration then for truetype? "truetype"?

As for the mainifest, here is an example of what they look like. This is, mind you, auto-generated by Sigil...I do not hand code it:

(inside the manifest section of the content.opf file)

<item href="Fonts/display-font.ttf" id="display-font.ttf" media-type="application/x-font-ttf" />

<item href="Fonts/header-font.otf" id="header-font.otf" media-type="application/vnd.ms-opentype" />

Now, as a test, if you could just tell me the name of a font or two that you know will work that come from a source that is free (fontsquirrel, dafont, google fonts, etc.) I can try to use those and see what happens. That way we know that the fonts themselves DO work in another file.

Sure. How 'bout good old Liberation Sans? I know that works, it's a go-to for us. Also, let's see...GandhiSans-Regular (I think that's a Google font, but it might be DaFont), League_Gothic, which is a truetype (again, forget where from); OratorStd; Century Schoolbook (truetype). Those happen to be at the top of my brain at the moment, because we just did some books that had those, and I know factually all of those work at KDP. Does that help?

Those font declarations in the manifest look fine. Yes, in the CSS it's: format() with the one word type, either "opentype" or "truetype" in the parenthesis, replete with quotemarks.

What's weird to me is that you say your fonts are surviving being Genned (KG or KP); they work in your ePUBs, but somehow, they're being stripped at the KDP. That's just bloody peculiar. This has been going on for months? You upload a working, functioning mobi with embedded fonts, and the preview is font-less? Man. That's

Hitch

[Mathew Reuther]

Originally Posted by Hitch

Sure. How 'bout good old Liberation Sans? I know that works, it's a go-to for us. Also, let's see...GandhiSans-Regular (I think that's a Google font, but it might be DaFont), League_Gothic, which is a truetype (again, forget where from); OratorStd; Century Schoolbook (truetype). Those happen to be at the top of my brain at the moment, because we just did some books that had those, and I know factually all of those work at KDP. Does that help?

Makes me cringe that some of those have been in my test pool. LeagueGothic-CondensedRegular, for example. That one came to me in otf (off of fontsquirrel's link) and KindlePreviewer warned that it's a PostScript font...tried anyway, and it was stripped.

But I will give it a shot with some of the others. Thank you very much for giving me a sampling to work from.

Those font declarations in the manifest look fine. Yes, in the CSS it's: format() with the one word type, either "opentype" or "truetype" in the parenthesis, replete with quotemarks.

I'll add that into my @font-face declarations then.

What's weird to me is that you say your fonts are surviving being Genned (KG or KP); they work in your ePUBs, but somehow, they're being stripped at the KDP. That's just bloody peculiar. This has been going on for months? You upload a working, functioning mobi with embedded fonts, and the preview is font-less? Man. That's

Hitch

I agree, and I've been around and around with KDP support on this and they tell me that they are researching it, then send me some pathetic wrong answer over a month later, or they just tell me I am doing it wrong. But according to their documentation, I'm not.

So, yeah...

Facepalm indeed.

And for the record, if it is useful, I am happy to hand the file off with some of these sample fonts (since we know they should work) just to see if touching the epub is useful. I really feel pretty awful talking to a professional formatter and basically begging for help, but the reason I have gone to the the time and effort of researching how to do this properly myself is because I believe that keeping the process in house is, in the long run, a much better option. (Assuming you can figure out how to do it right...which at this point it seems that I can't! Everything was going well until I wanted to take that one last little professional step and give the headers a bit to set them off by embedding fonts. Now, months later I am finally at the point of public begging for help. *sigh*)

[Hitch]

Originally Posted by Mathew Reuther

Makes me cringe that some of those have been in my test pool. LeagueGothic-CondensedRegular, for example. That one came to me in otf (off of fontsquirrel's link) and KindlePreviewer warned that it's a PostScript font...tried anyway, and it was stripped.

But I will give it a shot with some of the others. Thank you very much for giving me a sampling to work from.

Sure. NP.

I'll add that into my @font-face declarations then.



I agree, and I've been around and around with KDP support on this and they tell me that they are researching it, then send me some pathetic wrong answer over a month later, or they just tell me I am doing it wrong. But according to their documentation, I'm not.

So, yeah...

Facepalm indeed.

And for the record, if it is useful, I am happy to hand the file off with some of these sample fonts (since we know they should work) just to see if touching the epub is useful. I really feel pretty awful talking to a professional formatter and basically begging for help, but the reason I have gone to the the time and effort of researching how to do this properly myself is because I believe that keeping the process in house is, in the long run, a much better option. (Assuming you can figure out how to do it right...which at this point it seems that I can't! Everything was going well until I wanted to take that one last little professional step and give the headers a bit to set them off by embedding fonts. Now, months later I am finally at the point of public begging for help. *sigh*)

It's weird. It's going to be something really, really dumb. That doesn't mean that you're dumb; it just means it's going to be some stupid keystroke somewhere. I had some guy who tried and tried and tried to make a fixed-format book, and it kept not working. He finally sent me the whole enchilada, source and all, and I don't remember what the hell it was now, but it was, literally, something like...he'd put a line of code inside the meta instead of inside the manifest. It was that simple. Once I saw it (and I'd be embarrassed to admit how many hours it took me to SEE it), I saw it. It was obvious. But, it's like the "last place you look" shtick. It's going to be something in the CSS or the OPF, I think that's a given. Either that or it's so weird that nobody will ever figure it out.

I assume you're using the latest KindleGen, and you said you'd even tried Calibre to AZW or whatever (K8 format) it is it makes, is that right? And that got stripped, also? Is that correct? Because if that's true, then it's definitely something in the ePUB. I mean, at least that narrows it down somewhat. And this is one book, or have you tried multiple books? (Again--just trying to narrow it down some).

Hitch