KDP stripping custom fonts

[GJ Coop]

Originally Posted by susan_cassidy

Also, keep in mind that the older Kindles, probably millions of which are still in use, cannot display embedded fonts.

Very good point Susan.

Fortunately my target audience, my books are Adventure Travel, are unlikely to possess a Kindle. They will probably read them on a phone.

And here am I, somewhat a Luddite, reading things on my laptop.

[JSWolf]

Originally Posted by GJ Coop

Very good point Susan.

Fortunately my target audience, my books are Adventure Travel, are unlikely to possess a Kindle. They will probably read them on a phone.

And here am I, somewhat a Luddite, reading things on my laptop.

The iPhone Kindle app will display embedded fonts in a KF8 (AZW3) eBook.

[NiLuJe]

I think Hitch is aware of that, since I dimly remember bringing it up here once before, but one reason KDP might be so finicky with custom fonts is the (heavily? weirdly? patched) font rendering engine used on the eInk Kindles. Since the K3, we (when playing with custom font hacks) have demonstrated that it sometimes horribly mangles some fonts, or just plain crashes when rendering some fonts. And it's specifically an issue with Amazon's patches, since replacing the library responsible for font rendering with a recent vanilla copy miraculously solves everything (well, except truetype fonts with broken bytecode, of course, but those are relatively few and far between, and easy to check for, since they're broken on anything using FreeType's BCI).

Don't ask me why they haven't bothered fixing it since the K3, though ;D. Although they did close a somewhat easily accessible undocumented entry point for system-wide user-configurable custom fonts at one point of FW 5.x's life, probably for that reason.

[JSWolf]

At least I know my modified Charis SIL works well with Amazon's font engine.

[Hitch]

Originally Posted by NiLuJe

I think Hitch is aware of that, since I dimly remember bringing it up here once before, but one reason KDP might be so finicky with custom fonts is the (heavily? weirdly? patched) font rendering engine used on the eInk Kindles. Since the K3, we (when playing with custom font hacks) have demonstrated that it sometimes horribly mangles some fonts, or just plain crashes when rendering some fonts. And it's specifically an issue with Amazon's patches, since replacing the library responsible for font rendering with a recent vanilla copy miraculously solves everything (well, except truetype fonts with broken bytecode, of course, but those are relatively few and far between, and easy to check for, since they're broken on anything using FreeType's BCI).

Don't ask me why they haven't bothered fixing it since the K3, though ;D. Although they did close a somewhat easily accessible undocumented entry point for system-wide user-configurable custom fonts at one point of FW 5.x's life, probably for that reason.

Yes, and another change has been made, recently, by Amazon, at the KDP (within the last 7-10 days). Books that worked fine, last week, will have fonts stripped, this week. I haven't sourced it yet, but seriously: a book that would upload and display the embedded fonts perfectly 7 days ago will not now--same file. It's enough to make your teeth grind. they also did more "fixing" to the SRL, so everbobdy: your workarounds for THAT aren't working any longer, either, if you were using workarounds. Amazon actually knows that they broke THAT, because they are telling publishers--wait for it--that yhey are fixing the SRL's MANUALLY.

We haven't quite figured out what's changed (back to fonts). Depending on the book-building method, some (zipped html files) are working, but KP- and KG-built mobi's aren't (from the SAME source files, mind you). It's enough to make ya take up serious drinking.

Oish.

Hitch

[GJ Coop]

Originally Posted by Hitch

Yes, and another change has been made, recently, by Amazon, at the KDP (within the last 7-10 days). Books that worked fine, last week, will have fonts stripped, this week.

Hitch

H, thanks for that news.

Humm. So maybe it hasn't been me after all.

I've followed the embedment method pretty closely and still am having no luck in getting the embedded fonts to stick despite using various different single fonts for my chapter headings in a number of different ebooks.

I've downloaded a few mobi files previously uploaded to KDP from the previewer and the font is there, just not when it gets to the public side.

In some ways this is good news, ie, it might not be my markup, but hopefully KDP will resolve things shortly.

[Hitch]

Originally Posted by GJ Coop

H, thanks for that news.

Humm. So maybe it hasn't been me after all.

I've followed the embedment method pretty closely and still am having no luck in getting the embedded fonts to stick despite using various different single fonts for my chapter headings in a number of different ebooks.

I've downloaded a few mobi files previously uploaded to KDP from the previewer and the font is there, just not when it gets to the public side.

In some ways this is good news, ie, it might not be my markup, but hopefully KDP will resolve things shortly.

Coop:

You're saying that you're seeing fonts in the online Previewer, but NOT seeing them in the downloadable samples or books, from the books on sale?

You're the second person that's said this, and I'm downloading samples from our books, and the fonts ARE there. hmmm.

Hitch

[GJ Coop]

Hitch

I'm uploading the ebooks as an epub. There is only one embedded font used in one class, for chapter titles.

I'm seeing the embedded fonts in the online Previewer after I've uploaded the book.

I'm even seeing them in the Download Book Preview File in the Downloadable Previewer.

But the embedded fonts are not present over on the public Amazon site although everything else in the CSS is, ie, color, size, indent.

It's just my fonts being stripped.

I've tested this with six different books uploaded in the last few weeks.

Different fonts, TTF and OTF, same problem. No quotes on fonts, single quotes, double quotes, any variation you could come up with.

Everything else in the ebook in the Kindle store looks good, the CSS is working otherwise.

This is my mystery but perhaps it's good that it is now also being noticed by others, might mean that it's not my markup at fault.

[Hitch]

Originally Posted by GJ Coop

Hitch

I'm uploading the ebooks as an epub. There is only one embedded font used in one class, for chapter titles.

I'm seeing the embedded fonts in the online Previewer after I've uploaded the book.

I'm even seeing them in the Download Book Preview File in the Downloadable Previewer.

But the embedded fonts are not present over on the public Amazon site although everything else in the CSS is, ie, color, size, indent.

It's just my fonts being stripped.

I've tested this with six different books uploaded in the last few weeks.

Different fonts, TTF and OTF, same problem. No quotes on fonts, single quotes, double quotes, any variation you could come up with.

Everything else in the ebook in the Kindle store looks good, the CSS is working otherwise.

This is my mystery but perhaps it's good that it is now also being noticed by others, might mean that it's not my markup at fault.

GJ:

That's interesting. I've heard one other guy mention this, but it's not clear to me whether he's using Jutoh or doing his books by hand. He heavily recommends Jutoh for DIY'ers, but has posted a big long thread about the wonders of it over at the KDP, but at about the same time, he posted that his fonts were being eaten, too.

At this moment in time, although something has patently changed at the KDP vis-a-vis fonts on INTAKE, we (as yet) are not seeing any fonts that are being eaten in the PW (Publishing Workflow). We are still seeing that the SRL (Start Reading Location) has been changed yet again--our former workaround is not working now, but we HAVE been able to persist with fonts thus far.

I can't say as to why you're having issues. From what I've seen, you shouldn' be, BUT, I will say that the KDP is extremely sensitive to WHERE and HOW the fonts are called, in the CSS. Were I you, I'd start bracket-navigating. I'd do one font, and see what happens. Then add another, class-by-class. If I were a guessing man, which I'm not, I'd guess you have a class conflict. Not something that will show up in any check; I mean, something that the KDP doesn't like, like...calling the font in "bodysection," or something like that.

I was going to ask you whether you were setting the fonts in the body tag, versus the paragraph tag, but you're saying that you ARE seeing fonts in the online Previewer and download preview MOBI, but NOT in the for-sale book. That's an oddity.

WAIT: you don't mean, when you say

But the embedded fonts are not present over on the public Amazon site although everything else in the CSS is, ie, color, size, indent.

The LOOK INSIDE, do you? You mean the SAMPLE, not the Look Inside, right? Because if you mean the LOOK INSIDE, no, you WON'T see the fonts, etc. Please confirm you're talking about the book for-sale and the sample, and not the LITB (Look Inside the Book)?

Hitch

[GJ Coop]

Originally Posted by Hitch

GJ:


WAIT: you don't mean, when you say

The LOOK INSIDE, do you? You mean the SAMPLE, not the Look Inside, right? Because if you mean the LOOK INSIDE, no, you WON'T see the fonts, etc. Please confirm you're talking about the book for-sale and the sample, and not the LITB (Look Inside the Book)?

Hitch

Yeah, no fonts in the book store side sample.

I did once buy one of my own books early on but there were no fonts there.

If others, such as yourself, are still getting their custom fonts embedded then it's obviously my dumb markup. If only one other ebook creator has a problem then it's probably coincidence, still my markup.

If everyone has a problem then it ain't me at all. But I guess we would hear about that quickly.

I'm only wanting to use one custom font, but I'm not getting the sans-serif fall back either. That hints at a CSS issue, I guess.

Humm, I'll have to examine this class conflict stuff. I'm using more or less the same style sheet for the six ebooks so if there's a simple conflict that would explain why they are all carking it.

Thanks for that.

GJ

[JSWolf]

If you pot the CSS, maybe Hitch will take a look at it.

[Hitch]

Originally Posted by GJ Coop

Yeah, no fonts in the book store side sample.

I did once buy one of my own books early on but there were no fonts there.

If others, such as yourself, are still getting their custom fonts embedded then it's obviously my dumb markup. If only one other ebook creator has a problem then it's probably coincidence, still my markup.

If everyone has a problem then it ain't me at all. But I guess we would hear about that quickly.

I'm only wanting to use one custom font, but I'm not getting the sans-serif fall back either. That hints at a CSS issue, I guess.

Humm, I'll have to examine this class conflict stuff. I'm using more or less the same style sheet for the six ebooks so if there's a simple conflict that would explain why they are all carking it.

Thanks for that.

GJ

When the other guy at KDP claimed that his fonts were getting eaten in the PW, (although, n.b., it's not clear to me that they WERE showing up in the Step-6 preview mobi), I downloaded samples of a random 5 of our recently-uploaded books, and all their fonts were there. So at this point in time, as far as I know, we're not having this issue.

Our testing is not definitive, but usually, what we find, is something that shouldn't negatively affect the fonts, but does. For example: we have a book that has two "bodysections," for all intents and purposes, big divs. Font A is used for one; font B is used for another. A third font, a handwriting font, is used intermittently throughout. Right now, we're struggling because when we call the handwriting font, the arial (Font A) stops working/displaying. At this moment, who knows what that is? The fonts, which it could be, or something else? What we usually find is that somewhere, somehow--in no discernible pattern--it's something in the CSS *and* the HTML. We had a book that had a body-tag font set, and a bodysection tag set, (same font, mind you), and that wiped out all the font B headings. When we removed the bodysection font call...everything worked.

It's not yet remotely predictable. There are some things that you can work out and avoid, but there isn't an easy way to come up with what will and won't work. The best practice is to start out with something incredibly simple--font strictly for, say, chapter headings--and work your way OUTWARD from there. Otherwise, it's nearly hopeless. You have to bracket-navigate your way around the troubleshooting.

That's my best advice. @Wolfie: normally, I'd be happy to look at his CSS, but in all likelihood, that alone isn't the problem. It might be--but as demonstrated in my examples, above, it's usually a combination of things, and how they're used. I spend a ludicrous amount of time GUESSING at things, using my gut, and I'm lucky a lot. But that's just shortcutting after several years of messing about with it.

Hitch

[GJ Coop]

Ha, still going here, don't know why I don't just put myself out of my misery.

I have done a revision of the stylesheet for each book and have found a few anomalies which have been corrected.

For the record I had my images with two conflicting classes which still managed to show up OK in the public books all the same.

I had for some reason: list-style: none; instead of list-style-type: none;

I've switched that around.

My recent background is web development so my ebooks are very simple with the CSS, my file is just over 1k, there are not many classes, I have a basic seven. I see some of the automatically generated CSS files clock in at 30k. Having a look at how all over the place other people's markup is, a new class for each paragraph almost, I wonder how they troubleshoot that barrel of odds and ends.

The CSS looks like this with a few working classes left out.

@font-face {
font-family: "Abel";
font-style: normal;
font-weight: normal;
src: url("../Fonts/Abel-Regular.ttf") format("truetype");
}
body {
margin: 0;
padding: 0;
}
p {
color: #333;
font-size: 0.75em;
line-height: 1.4;
margin: 0;
padding: 0;
text-align: left;
text-indent: 1.5em;
}
p.title {
color: #e65c00;
font-family: "Abel", sans-serif;
font-size: 1em;
margin-top: 0.25em;
margin-bottom: 0.125em;
page-break-before: always;
text-align: center;
text-indent: 0;
.toc {
font-family: "Abel", sans-serif;
font-size: 1em;
line-height: 1.4;
margin-left: 1em;
text-indent: 0;
}
.books {
font-family: "Abel", sans-serif;
font-size: 0.9125em;
line-height: 1.4;
margin-left: 1em;
margin-bottom: 0.1em;
margin-top: 0.1em;
text-indent: 0;
}
ul {
margin-left: 1em;
margin-top: .25em;
margin-bottom: .25em;
list-style-type: none;
}
a {
text-decoration: none;
}

The only things not working are the font-family, neither the "Abel" nor the sans-serif are seen, and the a{text-decoration: none;}.

Sorry to go on about this but I'd love to work it out.

Remember this all looks just fine when previewed using Book Preview and in the file downloaded on the Edit Book Details page of KDP.

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

[GJ Coop]

JS

Thanks for that.

But I'm pretty sure that isn't my issue, I've tried that and every other combination conceivable.

The file I download from Book Preview on the upload page looks correct in the Kindle Paperwhite Previewer app, in

The online previewer also looks good.

It's the Amazon Previewer screen, one on the public side, that looks not so good, the fonts stripped.

Here's a few screen shots. There's three that show what I want and one that shows what I get.