KDP stripping custom fonts

[GJ Coop]

Originally Posted by AnemicOak

I don't know if the Cloud Viewer supports KF8 & embedded fonts or not.

Brian, Cloud Viewer seems to show other people's embedded fonts.

I ended up testing the system by, err, reluctantly, buying my own book, frankly a bargain at $3.75. But not such a bargain when the font has indeed been stripped, and, I already have a more attractive version on my computer.

I have a few ideas that I might run through in order to rule them out as being an issue.

First.

This is the head of my content.opf file. Should I be using version="2.0" or should this be version="3.0"

<?xml version="1.0" encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" xmlns:ibooks="http://www.idpf.org/2007/opf" unique-identifier="BookId" version="2.0">
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlnspf="http://www.idpf.org/2007/opf">

[GJ Coop]

The second issue is the naming of the font itself.

The font "Oswald" actually comes in four versions in separate packages:

Oswald-Regular.otf
Oswald-Bold.otf
Oswald-Light.otf
Oswald-stencil.otf

I have installed only Oswald-Regular.otf because I do not use bold or the other versions.

I use the name of the font "Oswald" in all the CSS because that is how it is referred to inside the font package. It validates with that name and has embedded.

If I try to call the font "Oswald-Regular" it says that the font can't be found and can't be embedded.

Are there any little tricks I may have missed here?

[GJ Coop]

I'm wondering if I have a similar problem as the one had by Mathew Reuther in the following forum thread:
Months of Runaround From KDP Support: Font Embedding Fails...HELP!

He says:

So, I'm not 100% positive that this works as I have not fully reassembled the book yet, but KDP apparently errors when you give it a heading declaration with a class that affects the font. Never mind that this is wholly legitimate HTML/CSS...

So, it is absolutely a case of there being a bug in the KDP conversion process. The workaround is moving from this:

<h2 class="fontchange"><a href="link details">Chapter One</a></h2>

to this:

<h2><span class="fontchange"><a href="link details">Chapter One</a></span></h2>

That looks altogether similar to what my issue is, guess KDP is choking on valid HTML and CSS once again.

I removed all those useless spans although to be honest the Pages .epub conversion managed to create about 60 separate classes of which I only need about 8.

Guess I'll have to whack a few back in, and test it again.

This thread was from just on a year ago, I thought maybe KDP might have fixed it.

[Hitch]

Originally Posted by GJ Coop

I'm wondering if I have a similar problem as the one had by Mathew Reuther in the following forum thread:
Months of Runaround From KDP Support: Font Embedding Fails...HELP!

He says:




That looks altogether similar to what my issue is, guess KDP is choking on valid HTML and CSS once again.

I removed all those useless spans although to be honest the Pages .epub conversion managed to create about 60 separate classes of which I only need about 8.

Guess I'll have to whack a few back in, and test it again.

This thread was from just on a year ago, I thought maybe KDP might have fixed it.

You want my short version, or the long version?

Short: OTF bad.
TTF Good.

Long:

18 months ago, we had a similar font-stripping situation. Some fonts simply will NOT work at the KDP; either the font, in its entirety, along with all font formatting, styling, etc., is stripped in the KDP "PW" (Publishing Workflow, which is what occurs to the book after you hit "save and publish" but before it goes on sale), or the font itself is corrupted (want fun? Try the dreaded Papyrus!!!). We have screenshots of some books that look like the lettering actually came "unstuck" from the page (think a Harry Potter spell), and the letters just moved hither and yon.

Now, you can sit there and bang your head against the wall from now until hell freezes over, or you can find another font. I'd highly recommend you find another font, and as Amazon tells you to stay away from otf's, I would. Even when we've tried converting some otf's to TTF, for pathologically-determined clients, we've had issues, so we tend to stick to TTF. We have had an ongoing discussion with Seattle--not the dreaded customer service--about this issue, and I'm not sure that they know what it is; it's simply a glitch. But they've already said, in the Formatting Guidelines, IIRC, to stay away from otf fonts.

Once you've made the book, upload it at the KDP, and ensure that you download the preview mobi. If the preview mobi is solid, you're likely in good shape. That's not 100% certain that the font won't be stripped out in the PW, but you can be absolutely positive that if the preview mobi doesn't have it, it won't be magically reinstalled in the PW. You'll obviously have to re-download the book (contact customer service and have the new version delivered to your devices, as they'll keep sending you the original otherwise) to ensure that the font is really, really there.

In all likelihood, it's not your coding--Reuter's issue was unique. We spent a weekend troubleshooting that book with him, as a favor, and NO font worked in his book. That WAS a coding error. Most font issues, though, are the font, not anything else.

Simply try substituting a different font, that's a ttf, and see if your problem resolves.

Hitch

[GJ Coop]

Originally Posted by Hitch

You want my short version, or the long version?

Short: OTF bad.
TTF Good.

Hitch

Thanks Hitch, that's an enormous help.

Actually, for some reason, something I read somewhere, I originally had the Oswald as a .ttf and changed it because I thought KDP recommended .otf.

I'll search out the original .ttf font.

As an aside it's just plain kooky that the KDP Previewer doesn't preview the ultimately converted file. Why on earth would you preview an intermediate stage?

At least that's confirmation that it might, in fact, not be totally due to my own ineptitude.

Who would guess that KDP would choke on valid XML?

Man, once I get this sorted it will be such a relief. It's been going on for 5 weeks.

Thanks again.

[Hitch]

Originally Posted by GJ Coop

Thanks Hitch, that's an enormous help.

Actually, for some reason, something I read somewhere, I originally had the Oswald as a .ttf and changed it because I thought KDP recommended .otf.

I'll search out the original .ttf font.

As an aside it's just plain kooky that the KDP Previewer doesn't preview the ultimately converted file. Why on earth would you preview an intermediate stage?

Because other magical shtuff is done in the PW. For example, the books that DO get that "leave a review" geegaw at the end, get them in the PW. Not all books do, despite what "Sell Your Book on Amazon!" self-proclaimed "experts" may tell you. Other things happen, too.

At least that's confirmation that it might, in fact, not be totally due to my own ineptitude.

Who would guess that KDP would choke on valid XML?

Man, once I get this sorted it will be such a relief. It's been going on for 5 weeks.

Thanks again.

I feel ya. I am, right this second, sitting here late because we have a book that mysteriously, has an SRL that is starting AFTER the first chapter's first page, not in some other mystery location, and it ONLY happens AFTER the client uploads--her cover. Why would the cover affect SRL? It shouldn't. But can I replicate it? Yes. Is this a brand-new SRL glitch and bug, unrelated to the previous SRL bugs? Yes.

Does it make me Oh, yeah. Along with

Hitch

[GJ Coop]

Well, I've re-uploaded a new .mobi file, created as an .epub in Calibre and converted in Kindle Desktop Previewer, for probably the 20th time, I'm getting to know the mechanics of The System. It looks OK in the KDP Online previewer. Actually it looks exactly what I want, so fingers crossed for tomorrow morning.

Spent some of today fiddling around with spans and classes. In between unblocking, err, the toilet.

This time the upload has the third font. I initially had a go with Impact, since it's on every computer, but maybe it was copy protected in some way.

The second font was the clearly public domain Oswald, a straightforward compact font. If any font should work, this one was specifically designed and optimised for the web, you would think that one would. It's available as both .ttf and .otf and of course I tried them both.

This third font is also a free web font from Google Web Fonts, the strangely nomenclatured "Yanone Kaffeesatz Regular". It seems to be looking OK, at least in the KDP online preview and on the Kindle Desktop Reader.

Somehow I'm feeling like I'm transported back to my early days of doing desktop publishing, early 1990s Pagemaker, except back then they could actually get the fonts to work. Not much progress in the last 21 years by the look of things. I guess we see the result in a difference in vision between Jobs and Bezos.

I don't think I'm doing anything too special, just a single additional compact sans serif font for a title page and for the chapter headings. I had validating code 4 weeks ago and I'm now at the point where I think I might just have to publish where they use .epub. I want my book to look the simple way I've designed it.

[Hitch]

Originally Posted by GJ Coop

Well, I've re-uploaded a new .mobi file, created as an .epub in Calibre and converted in Kindle Desktop Previewer, for probably the 20th time, I'm getting to know the mechanics of The System. It looks OK in the KDP Online previewer. Actually it looks exactly what I want, so fingers crossed for tomorrow morning.

So: the problem appears solved, then? Is that the takeaway?

Spent some of today fiddling around with spans and classes. In between unblocking, err, the toilet.

Ok. Good to know. Try fibre.

This time the upload has the third font. I initially had a go with Impact, since it's on every computer, but maybe it was copy protected in some way.

Impact...you mean the OPEN TYPE Impact?

The second font was the clearly public domain Oswald, a straightforward compact font. If any font should work, this one was specifically designed and optimised for the web, you would think that one would. It's available as both .ttf and .otf and of course I tried them both.

This third font is also a free web font from Google Web Fonts, the strangely nomenclatured "Yanone Kaffeesatz Regular". It seems to be looking OK, at least in the KDP online preview and on the Kindle Desktop Reader.

As I mentioned, you can't predict which fonts will function correctly, and which won't. I know, factually, of hundreds that will work just fine (we've developed a sizeable stable of them). You'd need a geekier font-maven than I, to explain why some don't work, but honestly: there's a world of fonts out there, and zillions of the blockier ones like Impact, between DaFont, FontSquirrel, GoogleFonts, and the like.

Somehow I'm feeling like I'm transported back to my early days of doing desktop publishing, early 1990s Pagemaker, except back then they could actually get the fonts to work. Not much progress in the last 21 years by the look of things. I guess we see the result in a difference in vision between Jobs and Bezos.

Yes, you do. Bezos created an actual, viable, financially-possible environment for self-publishers, and Jobs manufactured and sells devices. Amazon sells books. Apple sells devices. Don't confuse the two.

I don't think I'm doing anything too special, just a single additional compact sans serif font for a title page and for the chapter headings. I had validating code 4 weeks ago and I'm now at the point where I think I might just have to publish where they use .epub. I want my book to look the simple way I've designed it.

Just having "validating code" doesn't mean anything. Moreover, you could have just called the fonts with a sans serif fallback, so that when it didn't work, it would have fallen back to the already-installed sans serif fonts that are on the device(s).

If you want to talk about competing "visions," try to put an ePUB you've created on a first-gen iBooks, and pray that it doesn't use centering. Or, for that matter, some fonts, unless you include a "special file" that you can't use at most distributors/aggregators. To make an ePUB work on most first-gen iPads, you have to include a crapload of unnecessary code, to work around all the bad in the app. Oh, and if you make an ePUB3-compliant book for iBooks right now, it won't work on those first-gen iPads, either. At least, at Amazon, you can fallback gracefully for the millions of KF7-compliant devices with media queries. Over at Nook, if you have two spans in the first line of a paragraph, the line will break, hyphenating at bizarre locations.

Print layout has been around since Gutenberg. eBook layout has been around for, really, a whopping 5 years. Let's say 8, to be highly charitable and give credit where credit is due, to the early mobi/palm/lit, etc., pioneers. That it's not "done and dusted" and all burned-in is hardly surprising. Moreover, unless you're doing this ALL the time, it changes, literally weekly.

The goalposts move, and they move constantly.

Hitch

[GJ Coop]

Originally Posted by Hitch

So: the problem appears solved, then? Is that the takeaway?
Hitch

Well, no.

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.

I decided to cut my losses and create the title page as an image.

That was easy enough for me to do, and simplifies the number of embedded font classes in the code from six to two. One for the Table of Contents, the other for the chapter headings.

I added the not particularly elegantly named font, YanoneKaffeesatz-Regular, to the Manifest:

<item href="Fonts/YanoneKaffeesatz-Regular.ttf" id="Yanone Kaffesatz" media-type="application/x-font-truetype"/>

Added the @font-face to the CSS

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

h1 {
text-align: center;
margin: 0;
padding: 0;
color: #e65c00;
font-size: 100%;
}
.title {
font-family: "Yanone Kaffeesatz", sans-serif;
page-break-before: always;
}

Added the tags to the text:

<h1><span class="title">Day 7 | Brinkley Bluff: on top of the world</span></h1>

The .mobi created by the desktop app looks good in all the previewers, so once again my fingers are crossed that it will be acceptable when it pops out on the other side in the Amazon Kindle Store Previewer.

I guess I could get someone else to do this for me but I really want to nut this process out myself. I am writing short travel style ebooks and there is scope for writing plenty more of them, actually a whole new career and I'm 99% of the way there with the first four ebooks.

I'll report back on how KPD has machinated the .mobi. It might just work this time.

[RbnJrg]

Originally Posted by GJ Coop

...
I decided to cut my losses and create the title page as an image.
...

Hmmm, in that case you could consider to use .svg images. By using .svg images you also could employ the fonts you like without issues. Just be sure that the WHOLE .svg image is converted to PATHS before saving it as "plain .svg". Of course, .svg images are only supported by modern kindle devices (K3, K4, KT, KPW; no K1 nor K2) so you would to write some code (by using media queries) to manage that aspect.

[Hitch]

Originally Posted by GJ Coop

Well, no.

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.

I decided to cut my losses and create the title page as an image.

That was easy enough for me to do, and simplifies the number of embedded font classes in the code from six to two. One for the Table of Contents, the other for the chapter headings.

Six, quite frankly, is a LOT. We've done them, but I always recommend against that many fonts. First, size is a real issue. Secondly, it's just...a lot. {shrug}. Something is wrong in your coding. I don't know what, but you can't be quite THAT unlucky with font selections. I think you said you used Calibre, right? I/we don't, so there may be something happening there that affects it. Pure speculation on my part, but...

I added the not particularly elegantly named font, YanoneKaffeesatz-Regular, to the Manifest:



Added the @font-face to the CSS



Added the tags to the text:



The .mobi created by the desktop app looks good in all the previewers, so once again my fingers are crossed that it will be acceptable when it pops out on the other side in the Amazon Kindle Store Previewer.

Good luck. Seriously.

I guess I could get someone else to do this for me but I really want to nut this process out myself. I am writing short travel style ebooks and there is scope for writing plenty more of them, actually a whole new career and I'm 99% of the way there with the first four ebooks.

I'll report back on how KPD has machinated the .mobi. It might just work this time.

You might want to consider getting a pro to do it once, so you have a template of a book that works. Just an idea. Most of the better pros use the same CSS in their ePUB that they do in their MOBI, because they're building the mobi from the ePUB. It would give you a starting point.

FWIW, in the CSS:

src: url(../Fonts/YanoneKaffeesatz-Regular.ttf);

try:

src: url("../Fonts/YanoneKaffeesatz-Regular.ttf") format("truetype");

Quotes around the source url, and add the format text.

And for this, in the manifest:

media-type="application/x-font-truetype"/>

(Does that validate? Really?)

Try this:

media-type="application/x-font-ttf" />

I know that this seems like nitpicky little stuff, and I know you're trying to build a mobi, but that type declaration shouldn't be validating in ePUBcheck, firstly, and you never know...it might be messing with your mobi, too. You never know--never--what's going to set off the KDP. I spent hours yesterday working out a process diagram of all the myriad ways we've worked with the SRL (Start Reading Location) and Fonts, and all the fail paths versus the success paths. Trust me when I say, the fail paths are far more numerous than the succeed paths. And it's always something teeny. OR ridiculous.


Hitch

[GJ Coop]

Hitch

Thank you so much for taking the time with this.

Originally Posted by Hitch

Six, quite frankly, is a LOT.

I agree embedding six fonts would be entirely ridiculous. I am using one font and six classes.

Originally Posted by Hitch

You might want to consider getting a pro to do it once

Embedding fonts is one of the most difficult issues to get my head around that I've encountered in coding. It would be helped by KPD having a more explicit Official Guide. But also it seems that there mustn't be any official standard for the construction of the fonts, ie, why some work and others don't.

If I hadn't been in the finishing straight I would have been way better to pay someone else to sort this. The amount of wasted time has been quite staggering.

I would certainly recommend anyone else having issues with font embedment to get someone who knows what they are doing to sort this out. Like paying for it. It would be money well spent, at least if you value your time.

On the other hand, having made 100 mistakes I've come to understand how the font embedment process works. If you are the type to learn from mistakes it hasn't been entirely wasted.

Originally Posted by Hitch

try:

src: url("../Fonts/YanoneKaffeesatz-Regular.ttf") format("truetype");

I copied my code originally from someone else, somewhere, long ago. Clearly it works while on my computer but chokes up in the cloud.

I think it's probably those missing "" that have been causing my problems all along. Thanks for pointing out the obvious.

Originally Posted by Hitch

media-type="application/x-font-ttf" />

Calibre changes the application to what I had automatically. I'm not sure this is critical, but I'll change it anyway.

Originally Posted by Hitch

I know that this seems like nitpicky little stuff ...

Hitch

It's this nitpicky stuff that chokes code up. You must have an extreme eye for detail in this business, playing spot the difference. Get one character wrong, even a " instead of ' and it can come to grief.

Well, the day is youngish, there's four ebooks to fiddle with.

Hitch, thanks again, your advice has been extremely helpful.

[Hitch]

Originally Posted by GJ Coop

Hitch

Thank you so much for taking the time with this.

You are most welcome.

I agree embedding six fonts would be entirely ridiculous. I am using one font and six classes.

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

Embedding fonts is one of the most difficult issues to get my head around that I've encountered in coding. It would be helped by KPD having a more explicit Official Guide. But also it seems that there mustn't be any official standard for the construction of the fonts, ie, why some work and others don't.

If I hadn't been in the finishing straight I would have been way better to pay someone else to sort this. The amount of wasted time has been quite staggering.

I would certainly recommend anyone else having issues with font embedment to get someone who knows what they are doing to sort this out. Like paying for it. It would be money well spent, at least if you value your time.

If it's any comfort, we struggle still. Not on every book, of course, but stuff happens, and then we're dumpster-diving for answers just like you.

On the other hand, having made 100 mistakes I've come to understand how the font embedment process works. If you are the type to learn from mistakes it hasn't been entirely wasted.

It's the ONLY way to learn. Truthfully. Liz Castro aside, there really isn't any "book" on this, and it changes SOOOOOOOOOO fast, in so many formats/retailers, that it's a constant chase for knowledge. The guys here, though? Totally rock.

I copied my code originally from someone else, somewhere, long ago. Clearly it works while on my computer but chokes up in the cloud.

Hmmmph. What worketh in HTML, frequently crasheth in ebooks. Here endeth the lesson. ;-)

I think it's probably those missing "" that have been causing my problems all along. Thanks for pointing out the obvious.

When you've looked at font names hundreds of times, it's hard NOT to see it.

Calibre changes the application to what I had automatically. I'm not sure this is critical, but I'll change it anyway.

I honestly don't know if it's critical, but I pulled up a book that I know works, and figure...if it ain't broke...

It's this nitpicky stuff that chokes code up. You must have an extreme eye for detail in this business, playing spot the difference. Get one character wrong, even a " instead of ' and it can come to grief.

As I said above, we do this ALL day long. It's almost hard NOT to see it.

Well, the day is youngish, there's four ebooks to fiddle with.

Hitch, thanks again, your advice has been extremely helpful.

Well, as I said yesterday, I spent the better part of an evening staring at a MOBI with a fubarred SRL. I know the Fiddling feeling well.

Good luck.

Hitch

[JSWolf]

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

Here is a book with many embedded fonts. It's 11/22/63 by Stephen King. Only 6 of those fonts are not actually used in any way.

AldusLTStd-Italic.otf
AldusLTStd-Roman.otf
AlternateGothicNo2BTStd-Regular.otf
AmericanTypewriterStd-Med.otf
CalibanStd.otf
CheltenhamStd-BoldCond.otf
CheltenhamStd-BoldCondIt.otf
CooperBlackStd-Italic.otf
CooperBlackStd.otf
EngraversLTStd-BoldFace.otf
FrutigerLTStd-Black.otf
FrutigerLTStd-Bold.otf
Garamond3LTStd-Bold.otf
Garamond3LTStd-BoldItalic.otf
Garamond3LTStd-Italic.otf
Garamond3LTStd.otf
HelveticaInseratLTStd-Roman.otf
HelveticaLTStd-Blk.otf
HelveticaLTStd-BlkObl.otf
HelveticaLTStd-Obl.otf
HelveticaLTStd-Roman.otf
MemphisLTStd-Bold.otf
NewsGothicBTStd-Bold.otf
NewsGothicBTStd-BoldCondensedItalic.otf
NewsGothicBTStd-Italic.otf
NewsGothicBTStd-Roman.otf
StencilStd.otf
TimesNewRomanMTStd-Bold.otf
TimesNewRomanMTStd-BoldIt.otf
TimesNewRomanMTStd-Italic.otf
TimesNewRomanMTStd.otf
TradeGothicLTStd-BdCn20.otf
TradeGothicLTStd-BdCn20Obl.otf
TradeGothicLTStd.otf

[susan_cassidy]

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