Help: missing embedded fonts after ePub3 transfer to Kindle

[Hitch]

Originally Posted by Turtle91

Well… hold on a second.

Implying that Hitch is a troll is … just wrong. It’s undeserved and inaccurate. She is on here all the time helping people. It’s normal for people to misunderstand a point, or just miss it for that matter - especially as threads get longer and longer. She has tons of great points and lots of actual experience navigating these issues people bring up.

It serves everyone well to respectfully listen to others - even if they occasionally misunderstand a point.

Cheers!

Well, I'm quite sure that it's also driven, heavily by the very varied circumstances in which each person is thinking about using 3 or 8 or 20 fonts. I know when I'm asked for them. I know what I see, in the manuscripts, when I'm asked, and what I'm told about how it will or shan't work, when the scenario is explicated. I mean...as you know, Dion and so does everyone else here, we've done many thousands of eBooks. It's hardly shocking that I have an opinion about it. Trolling? Why? Because of what I think of the practice? Oh, right...today, you're trolling if you have an opinion about something and it diverges from that which the other person has utmost in their mind.


LostOnTheLine wrote:

"Supports", in this context, means simply that it has the ability to use. With the rest of my comment I made it clear that I consider it a developing thing, so as it works better now than it used to, I expect it'll work better in the future than it does now.

Okay--well, then, since "fonts" generically and loosely are supported for most--not all--KDP readers, devices, software, etc.--then there's really not much else to discuss. They're supported and you can use what you wish. (Is there some technical point of competency here yet being debated? Is there? I mean, those of us who've done this for a bit know that there are mystery limits, undocumented and worse, not understood at KDP/Amazon, around font calls in CSS. We've seen it happen. We know that other things, even more murkily perceived, can result in all the fonts being ripped from a book. Naught that we can all do about that, really.

Right? You can proceed apace, congrats.

Thus: what's the technical question if one still exists? What, the "what can go wrong, go wrong, go wrong" line? Almost anything. We've all seen it. I've wrangled with it as far back as 2012, around font counts and ...any number of times since then.

As far as the should he/shouldn't he...[shrug]. I've seen any number of requests for it, over the years and the books. My fave was probably the woman author whose cast and characters were 18 different dogs--all of whom needed a different font to identify them. Bless her heart.

Hey, why not? Dogs, characters...all the same thing, eh?

@slm: I downloaded the AZW3 version of that book from her website. Thank you for the roadmap and guideposts!

Now...this comment is unrelated to the "should we use 90-bajillion fonts identify characters" discussion (as that apparently seems to be the discussion underway here....), but whoever chose those fonts in that AZW3 should be shot. Good God.... :-) Oh, well...

Hitch

[Quoth]

Originally Posted by slm

I don't know what book the OP was referring to, but a book that absolutely needed multiple fonts is "The Interior Life" by Dorothy Heydt (writing as Katherine Blake). The switch back-and-forth between "exterior" worlds and "interior" one needs a very strong visual indicator to work.

As it switches within a paragraph I can see why she did it. Switching on chapter or even a section break basis wouldn't need extra fonts at all.
That, plus I think the thoughts are in italic (which is not always done), makes it very very tiring to read.
Personally I think it could have been done differently and using one or at most two fonts for the body, maybe even serif and then sans for the skips. I find the chosen alternate font hard to read. Then it would translate to non-Roman-Latin better and audio book better.

The download seems to be the entire ebook, but I put it in my "bought books" folder rather than the folder for pd books. I treat free copyright works as if they were bought.
However 3 or 4 body fonts will pass KDP, using 8 or 9 probably won't.

EDIT:
IMO Hitch is one of the more helpful people here and one of the most knowledgeable and experienced on eBook production/formatting I've seen in my 6 year membership here.

[Turtle91]

Originally Posted by Hitch

(Is there some technical point of competency here yet being debated? Is there? I mean, those of us who've done this for a bit know that there are mystery limits, undocumented and worse, not understood at KDP/Amazon, around font calls in CSS.

The original question was how to get a different font in different chapters based on a change in narrator. Basic CSS knowledge would make that an easy question to answer. The only technical question that caught my eye in this discussion was whether Kindle supports multiple fonts....

Someone mentioned Kindle only allows so many css font calls... I'll be the first to admit I don't have any idea of the internal programming required on a reader to display an html page with the proper styling as defined on an attached CSS sheet. So I don't know how (or why) the reader/device would 'count' the number of times a reference to the CSS was made???

I know that Kindle doesn't want people defining the font for the entire book and would rather leave that to the customer to choose.

"Body text should not have a forced font face. Make sure that you have followed the guidelines for embedded fonts. Not following these guidelines could lead to customers not having the ability to change their preferred reading font."
- Kindle publishers guide

In general, I agree with the sentiment. However, if the author really, really, needs to have a different font to denote some story point, How do they go about making it happen?

I suppose you could do like Harry Potter and make a "Kindle in Motion" type book where the reader needs to 'opt-in' to see all the special magical features of the book.

While that probably works, and it is readable, without the magic, on devices that don't support it, it seems like a LOT of work for the eBook coder; and some users may not want to be bothered with the 2 button pushes it takes to enable it...

Having said ALL that, I think the problem may just be in the WAY people have been coding the book. If "the number of CSS calls" is the problem, then why not reduce the number of calls? Based on the coding I've seen in most of the books I've read, I can easily believe that people are putting font calls in each paragraph. Instead, they should just put a single call in each body tag.

OBTW, that is also how Kindle recommends you do it:

The primary or main font in a book should be set at the <body> level. If you prefer to use additional text styling such as bold or italics, ensure that the styles are set on the text rather than the font so that any font that the customer selects correctly displays these styling elements. Below are examples of both correct and incorrect implementation of customizing fonts in a Kindle book.

Although my 'put all styling in the CSS sheet' philosophy cringes at putting styles in the html, I would think that following kindle's own recommendations would work, no?

Anyone experiment with that??

[Quoth]

No matter how you do it, if it's submitted to KDP (epub is best according to Amazon speaking to me) and the there are too many "body fonts" (we don't know how Amazon measures this?) then Amazon might strip all the embedded fonts.

Actual azw3 files by USB to a Kindle on your desk don't have the same limitations as azw3 from Amazon publishing or "Send to Kindle". Also big publishers have a different way of interfacing to Amazon.
The KFX is different:
1) Actual downloads from Amazon for transfer by USB to eink are never KFX. Only old mobi or azw3 depending on model. Maybe the PW1 has something weirld with images? I'm not sure.
2) All Whispernet downloads for apps or Kindles that can support KFX are KFX.
3) Calibre can make azw3, but not KFX, the KFX output plugin invokes command line version of an Amazon program (I forget which one), which doesn't work on Linux.
4) KFX has different rules to AZW/KF7 and seems mainly to exist to reduce Whispernet traffic on Mobile, allow reading before download is complete and always have DRM even if publisher said no DRM.

The italic and bold variation of existing body font (as per css of the p) should be inline HTML. So an occasion where "direct formatting" in the wordprocessor works. Using a character style (which will map to additional CSS) may not work. The only other direct formatting would be superscript and subscript. It sort of makes sense that bold, italic, superscript and subscript that are using the existing body CSS are inline HTML. The actual opening <p should reference a CSS class if needed, or there can be a default p CSS.

[Hitch]

Originally Posted by Turtle91

The original question was how to get a different font in different chapters based on a change in narrator. Basic CSS knowledge would make that an easy question to answer. The only technical question that caught my eye in this discussion was whether Kindle supports multiple fonts....

Someone mentioned Kindle only allows so many css font calls... I'll be the first to admit I don't have any idea of the internal programming required on a reader to display an html page with the proper styling as defined on an attached CSS sheet. So I don't know how (or why) the reader/device would 'count' the number of times a reference to the CSS was made???

Well, I'm pretty sure (I CONFESS!) that I may well be the source of this bit of murk. I know for a fact, that we (my co) dealt with this sometime between 2012 and 2015. We had to then deal with it, again, in the same bl**dy book, a few years later and we have not seen anything that makes us think that the Kraken of the Deep is not lurking around to do it again.

I'll try to remember what I can, but...dudes. It's been a while. Tex might remember, b/c I think I regaled him with the story at the time and he's still got that steel-trap brain. He hasn't yet reached the tender years where stuff falls out the bottom.

Anyway, we had this guy who had to make this...memoir. That's about all I can call it, a recitation fo his life. He desperately wanted...I think it was 4-5 fonts. I know that Arial was one of them, as it became the big bone o'contention. It also used...something odd, like Apple Chancery. Something quasi-foofy. If any of my Minions or Myrmidons can recall the name of this thing, I will buy and share it with you all, so that you can see what's what.

ANYWAY.. so, we make the book. Nothing really exciting. The usual, in-stylesheet CSS, yadda. And yes, if you are remotely organized, you can easily do the whole thing with CSS, so that p class=Sandy is where Sandy speaks and all that. Is it magical? No, it requires some effort and planning or some sheet luck. We had neither. But for yuor typical author, if they were typically motivated, they could use p styles (from Word, LO/OO, etc.) n their ms and then recode that with proper CSS post-HTML-export, IMHO and it wouldn't be awful.

We could NOT make that freaking thing render. COULD NOT DO IT. It would get to point X in the book and then just...all fonts would stop.

We tried--let's see, all the CSS in the ss. We tried half the CSS in the ss and half in the head. We tried 1/3rd, 1/3rd, 1/3rd. We tried putting everything in the CSS and then the fnt calls/changes, ONLY, (p = yadda) into inline. NOTHING. Inline font calls, even, old school hardcoding. Nada.

We literally experimented with and watched, as we could remove, say, two paragraphs worth of Arial "font calls" (for lack of a better description--call them p styles, or font calls...we tried 'em all). We'd see two paragraphs worth of Arial appear AFTER the original stopping place (as long as the two we'd removed remained removed), and the moment we put those two back in, the added two would disappear. What seemed to be a hard, mathematical limitation, no matter what.

I know that Kindle doesn't want people defining the font for the entire book and would rather leave that to the customer to choose.

Oh, yes. That's been in there forever, although they've tamped it down since then.

In general, I agree with the sentiment. However, if the author really, really, needs to have a different font to denote some story point, How do they go about making it happen?

A little ePUB, a little HTML and a little CSS and they can make it go. They don't even need that much, if they have, say, AWP and aren't obsessively picky about the markdown. [shrug].

I suppose you could do like Harry Potter and make a "Kindle in Motion" type book where the reader needs to 'opt-in' to see all the special magical features of the book.

I have that KIM. Nice, but...nothing to write home about. One of those, "Look, Ma, I did it!" rather than "look, Ma, you can't live without it" things.

While that probably works, and it is readable, without the magic, on devices that don't support it, it seems like a LOT of work for the eBook coder; and some users may not want to be bothered with the 2 button pushes it takes to enable it...

And many don't even know that they can do that. I have lost count of the number of PPW users or other devices in that family that don't even know that they can/do/should switch to Publisher Font, versus not knowing it exists. I did mean to mention this part, too, as I see it soooo often.

(And then what? With the 8 fonts, all of which will REQUIRE that Publisher Font be turned on to see them? When that's turned off...then what?) You can't very well run around to all their homes and flip the switch, right? But the entire PPW family has the superpower of overriding any/all font embedding, so the only way to make the fonts display is as Publisher Fonts. You either educate your buyer and hope for the best or...well, 99%, they aren't seeing the 8 fonts.

Having said ALL that, I think the problem may just be in the WAY people have been coding the book. If "the number of CSS calls" is the problem, then why not reduce the number of calls? Based on the coding I've seen in most of the books I've read, I can easily believe that people are putting font calls in each paragraph. Instead, they should just put a single call in each body tag.

See above, sweet pea. I still don't know why it broke, what broke it...nada. I just know that each and every vivification effort, Bones would look at me and say "it's dead, Jim."

OBTW, that is also how Kindle recommends you do it:


Although my 'put all styling in the CSS sheet' philosophy cringes at putting styles in the html, I would think that following kindle's own recommendations would work, no?

Anyone experiment with that??

Seriously...if we missed trying something...I don't know what it was. Literally, we tried for some months to make it GO.

We are all prohibited from using a font on the BODY tag and tried that anyway (making the Airal the body and yadda) and NOPE. Didn't work. At that point, we were simply chasing some sort of sign from the heavens, something that would say "hey, you're on a path here!" and we never got one. NEVER. We have no access to all the troubleshooting tools so...it is what it is.

These last 3 pots, you and Quoth...there's a lot to parse/discuss here but this is my best recollection, from...IDK, 8-10 years ago and then some as to the first indicator that we had, that something like this could occur.

AND yes, before you ask, it seemed to be limited to Arial. Not say, Calibri. (Didja ever notice that some people are simply addicted to Arial? You cannot move them off it? Helvetica, Arial...there are simpoly some fonts that folks get their knickers in a twist about...)

Hitch

[DNSB]

It's been a few months now and for some strange reason, I'm still tempted to ask: Do the multiple fonts work in the epub? If so, why is this discussion still in the epub workshop rather than being moved to the Kindle workshop forum?

[Hitch]

Originally Posted by DNSB

It's been a few months now and for some strange reason, I'm still tempted to ask: Do the multiple fonts work in the epub? If so, why is this discussion still in the epub workshop rather than being moved to the Kindle workshop forum?

I daresay that it's the ubiquity of it. I mean...you can't, really, use 'ePUB" to mean "one file to rule them all." Someone could be talking about MoonReader, someone about Nooks, one about Kobo...it's endless, right?

But then when you get to "Kindle," you have a prescribed universe of devices and we all, already know that there are challenges. And those that are proscribed...well, not "in" the KindleZone, right?

Whereas with ePUB-reading devices, heck, if you hacked your KFire, you could put a droid-based Nook Reader on it as a Droid device. Lots of crossover and muddied waters there.

AFAIK, multiple embedded fonts have worked, pretty much across the board, other than the occasional Apple-weirdness, in most real devices. Can't say much for and would not use, most software readers like Moon, but...Kobo, Nook, etc.--those all seem to work with multiple and even myriad font faces.

Hitch

[DNSB]

Originally Posted by Hitch

AFAIK, multiple embedded fonts have worked, pretty much across the board, other than the occasional Apple-weirdness, in most real devices. Can't say much for and would not use, most software readers like Moon, but...Kobo, Nook, etc.--those all seem to work with multiple and even myriad font faces.

Hitch

I know that a Kobo Touch could display over 18 fonts. One person whom I helped with an ebook cleanup had multiple alien species and wanted a different font for each so we ended up with a mix of serif, sans serif, etc. fonts. It didn't look too bad on the Touch but when she attempted to publish it on Amazon, the fonts disappeared no matter we tried. We finally ended up using a mix of "quote" characters, italic, bold and smallcaps to indicate the different species. All I can remember at this point was the use of guillemets and italic for a species that was telepathic.

Personally, I felt it was a bit of a mess but they were more or less happy until they looked at the sales numbers. Money wise, they likely would have done better collecting refundable containers off the street.

[Hitch]

Originally Posted by DNSB

I know that a Kobo Touch could display over 18 fonts. One person whom I helped with an ebook cleanup had multiple alien species and wanted a different font for each so we ended up with a mix of serif, sans serif, etc. fonts. It didn't look too bad on the Touch but when she attempted to publish it on Amazon, the fonts disappeared no matter we tried. We finally ended up using a mix of "quote" characters, italic, bold and smallcaps to indicate the different species. All I can remember at this point was the use of guillemets and italic for a species that was telepathic.

Personally, I felt it was a bit of a mess but they were more or less happy until they looked at the sales numbers. Money wise, they likely would have done better collecting refundable containers off the street.

Yeah, but...that's hardly uncommon.

I agree, afaik, the ePUB devices work generally.

The far bigger issue is, IMHO, if the fonts are that important--how can you adjust everything for that, given that you have no way to "force" the reader to use them/see them? Tsk.

Hitch

[JSWolf]

Originally Posted by Hitch

Yeah, but...that's hardly uncommon.

I agree, afaik, the ePUB devices work generally.

The far bigger issue is, IMHO, if the fonts are that important--how can you adjust everything for that, given that you have no way to "force" the reader to use them/see them? Tsk.

Hitch

You can put in a note in the eBook to say to turn on publisher fonts. But you are correct, there is no way to force it.

My question is...Have these fonts been tested on an eInk display with no added weight to make sure they look good enough?

[Hitch]

Originally Posted by JSWolf

You can put in a note in the eBook to say to turn on publisher fonts. But you are correct, there is no way to force it.

My question is...Have these fonts been tested on an eInk display with no added weight to make sure they look good enough?

Jon:

That's not the topic here--the testing, or lack thereof, of eInk, no-weight-added fonts.

And some 8,000 eBooks into this, let me just say, you can put notes, billet-doux, forget-me-nots, etc. in there from now until hell freezes over and 99% of the readers who buy them will a) never see the note and b) never read it. Anything in front-matter is almost ubiquitously ignored and never seen. That's just what has happened in a day and age when eBooks "typically" open to a given location.

People are, apparently, blithely disinterested in front matter.

Any concerns someone has about font weights, etc.--they can just test it themselves. That's their job as the publisher, any-damned-way.

Hitch

[JSWolf]

Originally Posted by Hitch

Jon:

That's not the topic here--the testing, or lack thereof, of eInk, no-weight-added fonts.

And some 8,000 eBooks into this, let me just say, you can put notes, billet-doux, forget-me-nots, etc. in there from now until hell freezes over and 99% of the readers who buy them will a) never see the note and b) never read it. Anything in front-matter is almost ubiquitously ignored and never seen. That's just what has happened in a day and age when eBooks "typically" open to a given location.

People are, apparently, blithely disinterested in front matter.

Any concerns someone has about font weights, etc.--they can just test it themselves. That's their job as the publisher, any-damned-way.

Hitch

Putting in a note about the embedded fonts is the only thing I can think of to do. Most are not going to try publisher font to see if there are any embedded fonts.

I think that if the eBook needs these embedded fonts, publish as ePub and forget the Kindle exists.

Amazon's way of doing things is really really stupid. The eBooks should always open at the cover and from there, the first page. Also, if there are any embedded fonts, publisher font should be on by default. That would solve a lot of problems.

[Hitch]

Originally Posted by JSWolf

Putting in a note about the embedded fonts is the only thing I can think of to do. Most are not going to try publisher font to see if there are any embedded fonts.

I think that if the eBook needs these embedded fonts, publish as ePub and forget the Kindle exists.

Amazon's way of doing things is really really stupid. The eBooks should always open at the cover and from there, the first page. Also, if there are any embedded fonts, publisher font should be on by default. That would solve a lot of problems.

Well, Amazon is nothing if not hide-bound by statistcs and data, seriously. If the Zon tells you, for example, that 90% of their users flip right past the front matter and go directly to Chapter 1, I think you can take that to the bank. I really do. They are addicted to that user data.

I suspect that they simply discovered something--who knows, something that SW knew or could have known, if they'd looked back in the day--that told them something that would just confirm what Amazon has built an entire empire learning and to which it caters--immediate self-gratification. People B Lazy. People want what they want, when they want it, and not before or after.

So, they have no interest in reading front matter. They don't. It slays my writers, trust me. The agonies of the defeat of front matter, trust me. ("What do you mean, they don't REAAAAAD it?"), but I think if Amazon saw any signs of life, around the front- or back-matter, they'd be delighted to allow people to read. I do.

[shrug]

Although it frustrates me, from a tech perspective (as that's my wheelhouse here), I can't blame Amazon for making it customizable for their readers. It's like the damned Burger King song, "have it your way, have it your way...".

I also think the whole "can't forcibly override the fonts on a PPW family device thing?_-is a bug. I don't think that they intended that, not one iota, but...I seriously doubt that they'll ever admit that. I KNOW that they never intended that 50% thing (the "if an image is 50-51% of the width of the screen, the PPW, et al, will blow it up to 100%") bug) to be real. That was a bl**dy BUG.

Hitch

[JSWolf]

Originally Posted by Hitch

Well, Amazon is nothing if not hide-bound by statistcs and data, seriously. If the Zon tells you, for example, that 90% of their users flip right past the front matter and go directly to Chapter 1, I think you can take that to the bank. I really do. They are addicted to that user data.

I suspect that they simply discovered something--who knows, something that SW knew or could have known, if they'd looked back in the day--that told them something that would just confirm what Amazon has built an entire empire learning and to which it caters--immediate self-gratification. People B Lazy. People want what they want, when they want it, and not before or after.

So, they have no interest in reading front matter. They don't. It slays my writers, trust me. The agonies of the defeat of front matter, trust me. ("What do you mean, they don't REAAAAAD it?"), but I think if Amazon saw any signs of life, around the front- or back-matter, they'd be delighted to allow people to read. I do.

[shrug]

People don't read the stuff before chapter 1 because the book starts with chapter 1. They might actually read the stuff before chapter 1 if it was actually presented on screen. I do read some if the stuff in front of chapter 1 if it's something to be read.

Although it frustrates me, from a tech perspective (as that's my wheelhouse here), I can't blame Amazon for making it customizable for their readers. It's like the damned Burger King song, "have it your way, have it your way...".

What I think would be a good idea is that when there are embedded fonts that the users choice of the body font be used and the embedded fonts be displayed. But the embedded fonts can be overridden but not by default. That way people would read the book as they want and when the embedded fonts show up, if they are a bother, they can be overridden.

I also think the whole "can't forcibly override the fonts on a PPW family device thing?_-is a bug. I don't think that they intended that, not one iota, but...I seriously doubt that they'll ever admit that. I KNOW that they never intended that 50% thing (the "if an image is 50-51% of the width of the screen, the PPW, et al, will blow it up to 100%") bug) to be real. That was a bl**dy BUG.

Hitch

This image bug should be fixed. It's a stupid bug.

[Hitch]

I must have bent up someone's feelings about the whole eight fonts thing.

That's the only explanation for this bit. Oh, well.

Hitch