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

Hitch · 02-04-2015, 11:30 AM

Quote:

Originally Posted by dgatwood

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

Code:

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

works, but:

Code:

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:

Code:

    text-rendering:geometricPrecision;

is the line that's breaking the online previewer.

dg:

Listen, I can PROMISE you that:

Code:

    text-rendering:geometricPrecision;

isn't what's breaking previewer on mine, because that line has never seen the light of day at my firm.

FWIW.

BTW: I know, all too well, the painful wait times for each book and the uploads at the KDP. We now have a "standard" 3-para long "book" that we use for testing, when we have one of these, because at least it uploads somewhat faster, but no matter what--it's 2 minutes minimum. {sigh}. Then 32 seconds to open the previewer. It's a bugger, isn't it?

Hitch

dgatwood · 02-05-2015, 10:35 PM

Quote:

Originally Posted by Hitch

dg:

Listen, I can PROMISE you that:

Code:

    text-rendering:geometricPrecision;

isn't what's breaking previewer on mine, because that line has never seen the light of day at my firm.

FWIW.

No surprise there; it's ostensibly new in CSS3, but pretty broadly supported. Except, apparently, by Kindle's previewer. That's really bizarre, given that it has been supported in WebKit since Kindle Fire was barely a gleam in Amazon's eye, but... could be related to their buggy font engine.

Quote:

Originally Posted by Hitch

BTW: I know, all too well, the painful wait times for each book and the uploads at the KDP. We now have a "standard" 3-para long "book" that we use for testing, when we have one of these, because at least it uploads somewhat faster, but no matter what--it's 2 minutes minimum. {sigh}. Then 32 seconds to open the previewer. It's a bugger, isn't it?

Yup. And even more amazing, that site appears to be served up using their cloud platform. Not exactly a ringing endorsement.

Peter Ahlstrom · 02-06-2015, 09:55 AM

Matthew, I just popped in because I noticed that in your long list of fallback fonts it says capital-S Serif rather than lowercase-s serif. Does that make a difference?

JSWolf · 02-06-2015, 10:37 AM

Quote:

Originally Posted by dgatwood

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

Code:

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

works, but:

Code:

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:

Code:

    text-rendering:geometricPrecision;

is the line that's breaking the online previewer.

All of that nonstandard code you put in that horrible looking body style has to go. Basically, it's just the one line that has the font-family that stays. They rest has to go. I would not be surprised if Amazon didn't accept your eBook with all that in it.

Notjohn · 02-07-2015, 08:52 AM

Quote:

Originally Posted by Hitch

dg:
BTW: I know, all too well, the painful wait times for each book and the uploads at the KDP. We now have a "standard" 3-para long "book" that we use for testing, when we have one of these, because at least it uploads somewhat faster, but no matter what--it's 2 minutes minimum. {sigh}. Then 32 seconds to open the previewer. It's a bugger, isn't it?

Hitch

You posted this on Feb 4. I uploaded an 80,000-word epub on Feb 5, and it converted in 45 seconds. (I didn't use the previewer; I was only interested in conversion speeds, since they'd been a subject of contention on the KDP forum.)

So is this a problem you see as a regular thing? Does your test "book" have embedded fonts?

(I see that you have returned to the KDP forum snakepit. A glutton for punishment!)

Hitch · 02-07-2015, 01:55 PM

Quote:

Originally Posted by Notjohn

You posted this on Feb 4. I uploaded an 80,000-word epub on Feb 5, and it converted in 45 seconds. (I didn't use the previewer; I was only interested in conversion speeds, since they'd been a subject of contention on the KDP forum.)

So is this a problem you see as a regular thing? Does your test "book" have embedded fonts?

Generally, I see uploading times of 45secs-2 minutes, or thereabouts. Some do, some don't, have embedded fonts.

Quote:

(I see that you have returned to the KDP forum snakepit. A glutton for punishment!)

I thought that the utter idiocy of the post about how so-and-so was "making a book from a word-processor," which of course, turned out to be completely wrong and thoroughly mischaracterized, needed to be addressed. However, your friend has, as usual, turned it into an utterly nasty and unpleasant experience, so I'm done with that. I keep trying to help newbs, but it's simply untenable.

Hitch

V_Shaft · 08-24-2015, 05:38 AM

I've registered to the forum specifically to post a question regarding font embedding and the KDP conversion from the Pits of Hell.

I've done an epub e-book with 2 embedded fonts in Sigil. These are Anonymous Pro (Regular, Italic & Bold) & Open Sans (Regular, Italic & Bold). Both are well known and widely used ttf fonts.

Now, in the epub, they work perfectly. When uploading my book to KDP... not so much. Just to be clear, this isn't the first e-book I've done and I've made sure - just like every time - that both the epub and the stylesheet itself are validated and contain no errors.

I converted the epub via KindleGen (KG), the latest version. The resulting mobi contains no errors, also. And right enough, after testing with Kindle Previewer (KP) and Kindle for PC (KPC) I was assured the custom fonts work in the converted mobi file.

I then set out to upload that same mobi file to the KDP service. The file uploads, then KDP starts "converting it to Kindle format". When that was over, I downloaded the preview file (the "Download Book Preview File" option) and I get a mobi file that has stripped fonts.

I should clarify what I mean by "stripped":

After I browse the inside contents of the KDP-served mobi file/archive, I found that the font files themselves are left intact, inside the Fonts folder.

Upon examining the stylesheet I found it has been butchered.

The @font-face declarations at the top of the stylesheet (before body and everything else) have also been left intact. They look like this:

Code:

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

But every subsequent font-family rule in the CSS has been removed! The one in my <p>, <h1>, <h2> and other custom classes... gone. For example, my original class

Code:

.blok {
	font-family: "Anonymous_Pro_B", sans-serif;
	font-weight: bold;
	font-size: 2em;
	text-align: center;
}

now looks like this

Code:

.blok {

	font-weight: bold;
	font-size: 2em;
	text-align: center;
}

I've tried just about every remedy offered in this thread, but not one seems to work.

So I would like to ask Hitch or someone of the experts to please answer just what the hell is KDP doing? Just what makes KG, KP and KPC leave and display the fonts, and KDP strip them? I'm at my breaking point regarding this issue. Can I even embed the fonts, or is it a fruitless effort doomed from the start?

Hitch · 08-27-2015, 03:38 PM

Quote:

Originally Posted by V_Shaft

I've registered to the forum specifically to post a question regarding font embedding and the KDP conversion from the Pits of Hell.

I've done an epub e-book with 2 embedded fonts in Sigil. These are Anonymous Pro (Regular, Italic & Bold) & Open Sans (Regular, Italic & Bold). Both are well known and widely used ttf fonts.

Now, in the epub, they work perfectly. When uploading my book to KDP... not so much. Just to be clear, this isn't the first e-book I've done and I've made sure - just like every time - that both the epub and the stylesheet itself are validated and contain no errors.

I converted the epub via KindleGen (KG), the latest version. The resulting mobi contains no errors, also. And right enough, after testing with Kindle Previewer (KP) and Kindle for PC (KPC) I was assured the custom fonts work in the converted mobi file.

I then set out to upload that same mobi file to the KDP service. The file uploads, then KDP starts "converting it to Kindle format". When that was over, I downloaded the preview file (the "Download Book Preview File" option) and I get a mobi file that has stripped fonts.

I should clarify what I mean by "stripped":

After I browse the inside contents of the KDP-served mobi file/archive, I found that the font files themselves are left intact, inside the Fonts folder.

Upon examining the stylesheet I found it has been butchered.

The @font-face declarations at the top of the stylesheet (before body and everything else) have also been left intact. They look like this:

Code:

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

But every subsequent font-family rule in the CSS has been removed! The one in my <p>, <h1>, <h2> and other custom classes... gone. For example, my original class

Code:

.blok {
	font-family: "Anonymous_Pro_B", sans-serif;
	font-weight: bold;
	font-size: 2em;
	text-align: center;
}

now looks like this

Code:

.blok {

	font-weight: bold;
	font-size: 2em;
	text-align: center;
}

I've tried just about every remedy offered in this thread, but not one seems to work.

So I would like to ask Hitch or someone of the experts to please answer just what the hell is KDP doing? Just what makes KG, KP and KPC leave and display the fonts, and KDP strip them? I'm at my breaking point regarding this issue. Can I even embed the fonts, or is it a fruitless effort doomed from the start?

Hi, Teo:

I saw your post on the KDP forums--good luck with that. I'll be seriously surprised if anyone there can tell you the answer, or even knows the real question.

The long and short of it is that starting in April, above and beyond all the other issues you've seen described in this thread, Amazon did an update to the KDP that has resulted in all fonts being stripped from uploaded ePUBS, uploaded MOBIs, uploaded you-name-it.

What you are seeing isn't unusual. The fonts are being stripped, and in some cases, as you've described, the actual stylesheet is being altered. It's...boggling.

I know this because we had a bunch of books in, that were due out, for an international best-selling author, the week of April 5th, and suddenly, all the fonts started to disappear. My inference from correspondence with Amazon is that they are not sure what they did that caused it, because someone from ECR emailed me, asking about our workaround. I simply told them that we'd arrived at one, which resulted in another email asking for a phone conference about it, which hasn't yet occurred.

I hate to be the bearer, but that's the bottom line.

Hitch

Notjohn · 08-28-2015, 06:08 AM

Thanks for that!

V_Shaft · 08-28-2015, 04:26 PM

I seem to have found the solution. It was a process, though....

After failing with the typical embedding via the font-family: "font name"; rule, I tried using font shorthands. They're not so well known, but seem to work. For example, a font shorthand would look like this:

Code:

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;

However, a peculiar thing happened when KDP uploader got the file... the resulting e-book was likewise stripped of fonts, but whereas before the whole font-family rule would be deleted, font was deleted only partially. KDP would mangle the CSS in such a way:

Code:

font: italic small-caps normal 13px/150% "", "", "";

Only quotation marks remained of the font names. Obviously, KDP would kill any straightforward font definition.

So, it got me thinking, was there a way to smuggle the fonts by a backdoor of sorts?

The answer was yes, by using the @import method.

You need 2 stylesheets for this. One is your main stylesheet that is linked to the XHTML files directly. From this main stylesheet, I removed all font family rules. I left the @font-face declarations, though.

Then, I made another stylesheet. I did not link it to any content file. In it I only put the font-family rules, for my p, h1, h2, and so forth.

The final step was importing the second, unlinked stylesheet into the main (linked) one by @import function. Like this:

Code:

@import url(../Styles/style2.css);

Of course, alter the url location as you need. And, the rule must be put at the very top of the stylesheet, before anything else. From all this, I can only deduce that KDP strips fonts from the linked stylesheet, and any unlinked CSS file shall remain untouched.

And now the Offline Previewer shows the fonts, the Online Previewer also. The font definitions are also not stripped from the CSS of the KDP-generated file. So I can only assume the method works... well, that is until Amazon decides to screw up things again, which I'm sure they're working very diligently on.

Hitch · 08-28-2015, 04:52 PM

Quote:

Originally Posted by V_Shaft

I seem to have found the solution. It was a process, though....

After failing with the typical embedding via the font-family: "font name"; rule, I tried using font shorthands. They're not so well known, but seem to work. For example, a font shorthand would look like this:

Code:

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;

However, a peculiar thing happened when KDP uploader got the file... the resulting e-book was likewise stripped of fonts, but whereas before the whole font-family rule would be deleted, font was deleted only partially. KDP would mangle the CSS in such a way:

Code:

font: italic small-caps normal 13px/150% "", "", "";

Only quotation marks remained of the font names. Obviously, KDP would kill any straightforward font definition.

So, it got me thinking, was there a way to smuggle the fonts by a backdoor of sorts?

The answer was yes, by using the @import method.

You need 2 stylesheets for this. One is your main stylesheet that is linked to the XHTML files directly. From this main stylesheet, I removed all font family rules. I left the @font-face declarations, though.

Then, I made another stylesheet. I did not link it to any content file. In it I only put the font-family rules, for my p, h1, h2, and so forth.

The final step was importing the second, unlinked stylesheet into the main (linked) one by @import function. Like this:

Code:

@import url(../Styles/style2.css);

Of course, alter the url location as you need. And, the rule must be put at the very top of the stylesheet, before anything else. From all this, I can only deduce that KDP strips fonts from the linked stylesheet, and any unlinked CSS file shall remain untouched.

And now the Offline Previewer shows the fonts, the Online Previewer also. The font definitions are also not stripped from the CSS of the KDP-generated file. So I can only assume the method works... well, that is until Amazon decides to screw up things again, which I'm sure they're working very diligently on.

I freely admit, that's a completely different workaround than what we're doing. I'm glad you found something that works for you, however.

Hitch

V_Shaft · 08-28-2015, 05:04 PM

Hm, I did some further testing, and mixed things up I bit... to boggling results.

I left some of my font-family definitions in my main (linked) stylesheet, and transferred the others to my second (unlinked) stylesheet to use via the @import.

And in this case the KDP-generated e-book had all the font-family rules intact, even in the main CSS.

Could it be that, somehow, only a second dummy unlinked stylesheet has to exist in order for KDP to leave the main one alone? I'll do some more testing and report back...

Hitch · 08-28-2015, 05:18 PM

Quote:

Originally Posted by V_Shaft

Hm, I did some further testing, and mixed things up I bit... to boggling results.

I left some of my font-family definitions in my main (linked) stylesheet, and transferred the others to my second (unlinked) stylesheet to use via the @import.

And in this case the KDP-generated e-book had all the font-family rules intact, even in the main CSS.

Could it be that, somehow, only a second dummy unlinked stylesheet has to exist in order for KDP to leave the main one alone? I'll do some more testing and report back...

FWIW, we're not using any second CSS sheet at all. Don't know if that helps.

BTW, during the April "crisis," we found that on occasion, a book worked, for no apparent reason. The same book wouldn't work the next day. So, you're going to want to check, double-check, and triple-check those results over multiple days, I'm sorry to tell you.

Hitch

V_Shaft · 08-29-2015, 06:45 AM

@Hitch

Quote:

FWIW, we're not using any second CSS sheet at all. Don't know if that helps.

Well, it's helpful to a degree, but in effect not really... it narrows the solution down to, what, 10, 1000, 1000, an undetermined amount of possibilities? I assume your solution is an company secret, so it's alright.

In any case, I did some further experiments with my @import method. Here's what I got:

EXPERIMENT #0 - to re-check if the problem persists
Setup: 1 main linked stylesheet containing the actual CSS rules; No @import rules used anywhere; normal font-family definitions used to trigger fonts.
Result: Fail.

What happened: KDP stripped the font-family rules (the whole line no matter of its content, not just the font name that's being referred to) from the main linked stylesheet. As before, the font files themselves, as well as @font-face declarations, remained intact, but useless without the font-family rules.

EXPERIMENT #1

Setup: 1 main linked stylesheet containing the actual CSS rules + 1 dummy & unlinked stylesheet (blank, acting as a decoy); No @import rules used anywhere.
Result: Fail.

What happened: KDP stripped the font-family rules from the main linked stylesheet. Obviously, simply having a dummy style doesn't prevent KDP from making away with the fonts from the main style.

EXPERIMENT #2

Setup: 1 main linked stylesheet + 1 mirror copy unlinked stylesheet containing all the styles from the main; No @import rules used anywhere.
Result: Fail.

What happened: KDP stripped the font-family rules from both stylesheets.

EXPERIMENT #3

Setup: 1 main linked stylesheet containing only the @import rule + 1 unlinked stylesheet containing all the actual CSS; unlinked CSS imported into the linked one via @import.
Result: Success.

What happened: No fonts stripped from the unlinked CSS. Tested on several books. Fonts show up on both the Offline and Online Previewer, on Kindle for PC, as well as in the actual file when inspected. I confirmed the CSS remains intact.

Now, why this works I've no idea. But it does, and it's easy to implement. Kindle devices support the @import rule, so I'm gonna stick with that.

Hitch · 08-29-2015, 01:09 PM

Quote:

Originally Posted by V_Shaft

@Hitch

Well, it's helpful to a degree, but in effect not really... it narrows the solution down to, what, 10, 1000, 1000, an undetermined amount of possibilities? I assume your solution is an company secret, so it's alright.

I'm really not trying to be a jerk. It's just that we spent essentially 4 24-hour days (everyone worked, around the clock, literally) to come up with a solution, because we were against a deadline for our most-famous client. It cost me a small fortune to solve the issue. And given that the space is now sort of beyond dog-eat-dog, with the 3rd-world nations in it, offering incredibly cheap books--a girl's gotta hold on to any advantage, no matter how tiny. BUT, of course, that's gone now anyway.

Hitch

08-24-2015, 05:38 AM	#157
V_Shaft Junior Member Posts: 7 Karma: 10 Join Date: Aug 2015 Device: Nook Simple Touch	I've registered to the forum specifically to post a question regarding font embedding and the KDP conversion from the Pits of Hell. I've done an epub e-book with 2 embedded fonts in Sigil. These are Anonymous Pro (Regular, Italic & Bold) & Open Sans (Regular, Italic & Bold). Both are well known and widely used ttf fonts. Now, in the epub, they work perfectly. When uploading my book to KDP... not so much. Just to be clear, this isn't the first e-book I've done and I've made sure - just like every time - that both the epub and the stylesheet itself are validated and contain no errors. I converted the epub via KindleGen (KG), the latest version. The resulting mobi contains no errors, also. And right enough, after testing with Kindle Previewer (KP) and Kindle for PC (KPC) I was assured the custom fonts work in the converted mobi file. I then set out to upload that same mobi file to the KDP service. The file uploads, then KDP starts "converting it to Kindle format". When that was over, I downloaded the preview file (the "Download Book Preview File" option) and I get a mobi file that has stripped fonts. I should clarify what I mean by "stripped": After I browse the inside contents of the KDP-served mobi file/archive, I found that the font files themselves are left intact, inside the Fonts folder. Upon examining the stylesheet I found it has been butchered. The @font-face declarations at the top of the stylesheet (before body and everything else) have also been left intact. They look like this: Code: @font-face { font-family: "OpenSans-Regular"; font-weight: normal; font-style: normal; src: url(../Fonts/OpenSans-Regular.ttf) format("truetype"); } But every subsequent font-family rule in the CSS has been removed! The one in my <p>, <h1>, <h2> and other custom classes... gone. For example, my original class Code: .blok { font-family: "Anonymous_Pro_B", sans-serif; font-weight: bold; font-size: 2em; text-align: center; } now looks like this Code: .blok { font-weight: bold; font-size: 2em; text-align: center; } I've tried just about every remedy offered in this thread, but not one seems to work. So I would like to ask Hitch or someone of the experts to please answer just what the hell is KDP doing? Just what makes KG, KP and KPC leave and display the fonts, and KDP strip them? I'm at my breaking point regarding this issue. Can I even embed the fonts, or is it a fruitless effort doomed from the start?

08-28-2015, 04:26 PM	#160
V_Shaft Junior Member Posts: 7 Karma: 10 Join Date: Aug 2015 Device: Nook Simple Touch	I seem to have found the solution. It was a process, though.... After failing with the typical embedding via the font-family: "font name"; rule, I tried using font shorthands. They're not so well known, but seem to work. For example, a font shorthand would look like this: Code: font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif; However, a peculiar thing happened when KDP uploader got the file... the resulting e-book was likewise stripped of fonts, but whereas before the whole font-family rule would be deleted, font was deleted only partially. KDP would mangle the CSS in such a way: Code: font: italic small-caps normal 13px/150% "", "", ""; Only quotation marks remained of the font names. Obviously, KDP would kill any straightforward font definition. So, it got me thinking, was there a way to smuggle the fonts by a backdoor of sorts? The answer was yes, by using the @import method. You need 2 stylesheets for this. One is your main stylesheet that is linked to the XHTML files directly. From this main stylesheet, I removed all font family rules. I left the @font-face declarations, though. Then, I made another stylesheet. I did not link it to any content file. In it I only put the font-family rules, for my p, h1, h2, and so forth. The final step was importing the second, unlinked stylesheet into the main (linked) one by @import function. Like this: Code: @import url(../Styles/style2.css); Of course, alter the url location as you need. And, the rule must be put at the very top of the stylesheet, before anything else. From all this, I can only deduce that KDP strips fonts from the linked stylesheet, and any unlinked CSS file shall remain untouched. And now the Offline Previewer shows the fonts, the Online Previewer also. The font definitions are also not stripped from the CSS of the KDP-generated file. So I can only assume the method works... well, that is until Amazon decides to screw up things again, which I'm sure they're working very diligently on. Last edited by V_Shaft; 08-28-2015 at 04:39 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Font Embedding?	teh603	Writer2ePub	75	01-08-2013 07:57 PM
Font embedding	sachin	Sigil	36	03-30-2012 03:26 AM
Font embedding	sachin	Sigil	3	03-21-2012 09:19 AM
Do I need a font license if all I'm doing is referring to the font (not embedding)?	Stodder	Workshop	21	04-21-2011 04:19 AM
Special chararcters on the iPad or why does Apple not support Font-embedding?	georg3200	ePub	13	10-06-2010 10:32 AM

02-06-2015, 09:55 AM	#153
Peter Ahlstrom Connoisseur Posts: 75 Karma: 500000 Join Date: Oct 2011 Location: Utah Device: iPad	Matthew, I just popped in because I noticed that in your long list of fallback fonts it says capital-S Serif rather than lowercase-s serif. Does that make a difference?

08-28-2015, 06:08 AM	#159
Notjohn mostly an observer Posts: 1,515 Karma: 987654 Join Date: Dec 2012 Device: Kindle	Thanks for that!

08-28-2015, 05:04 PM	#162
V_Shaft Junior Member Posts: 7 Karma: 10 Join Date: Aug 2015 Device: Nook Simple Touch	Hm, I did some further testing, and mixed things up I bit... to boggling results. I left some of my font-family definitions in my main (linked) stylesheet, and transferred the others to my second (unlinked) stylesheet to use via the @import. And in this case the KDP-generated e-book had all the font-family rules intact, even in the main CSS. Could it be that, somehow, only a second dummy unlinked stylesheet has to exist in order for KDP to leave the main one alone? I'll do some more testing and report back...