Unchangeable font

[AlanHK]

I have epubs that I edit in Sigil, then create an AZW using the kindlegen plugin, then sideload to my PW3.

I've noticed that some books the Kindle would not allow me to change the font: if I pulled up the font menu, I could select whatever I wanted, but the display did not change.

I stripped down the epub to try to work out the reason.
Eventually I got a to a stylesheet with one style:

p {
     font-family: sans-serif;
}

The above showed Ember. If I made it "serif" it showed Bookerly, regardless of my selection. I can change the size as normal.

Same behaviour if I had

body {
     font-family: sans-serif;
}

I attach the test epub.

But many other epubs I have use "font-family:", and the display font can be changed regardless.

Anyone can cast a light on what is going on and what triggers this behaviour?

I normally do put "font-family: serif;" in the body CSS as I found that otherwise if I had some text in an embedded font (e.g a Fraktur for a few words), and set "Publisher Font" on to see it, all other text became sans otherwise (ugh).

I really would prefer it if you could choose the "font unspecified" display font while leaving the explicitly set ones to show. But I don't see any prospect of that.

[jhowell]

My understanding is that if you want to embed a font to be used for the main body of the book, a "Publisher font", you should set that as the font family of the body element and no where else. That allows it to be overridden by the user's selection.

You should not set a font family any place else, except where you want to use a font that you have included in the book for certain specific text, such as fancy headings. Regular paragraphs in the book should not have a font family set.

[JSWolf]

Originally Posted by jhowell

My understanding is that if you want to embed a font to be used for the main body of the book, a "Publisher font", you should set that as the font family of the body element and no where else. That allows it to be overridden by the user's selection.

You should not set a font family any place else, except where you want to use a font that you have included in the book for certain specific text. Regular paragraphs in the book should not have a font family set.

Why can't you use an embedded font for the main text in the book? If the Kindle is not jailbroken and you want to use a different font, you have to embedded such. The thing I've seen in a number of books when when font-family is put in hat should not be there like "font-family: Georgia, "Times New Roman", serif;" Neither of those two fonts are actually embedded.

[Hitch]

Originally Posted by jhowell

My understanding is that if you want to embed a font to be used for the main body of the book, a "Publisher font", you should set that as the font family of the body element and no where else. That allows it to be overridden by the user's selection.

That's correct. If you use it elsewhere--for example, you create a class named "body," and put that on a div that, say, encompasses the entire content section--then they can't change the font. It can only be changed easily/simply (by the typical Kindle user, I mean) if the font is placed on the body tag. (ironic n.b.: ask anyone at US-based Tech Support, and they'll tell you to NEVER put the font on the body tag, by the way, even though it says to do that in the PG. Go ahead, you figure it out. I'm too exhausted by it, TBH, after now nearly 5 years of this bulls**t.)

You should not set a font family any place else, except where you want to use a font that you have included in the book for certain specific text, such as fancy headings. Regular paragraphs in the book should not have a font family set.

Yup, that too.

@Alan: it's not the CSS, and what it says--it's WHERE it's called. The same CSS you've listed, for the serif body font, will be perfectly meaningless in one place, and perfectly iron-clad in the unchangeable category, if placed on the p tag. Thus, it's the where, not the CSS itself.

Does that make sense?

Hitch

[AlanHK]

Originally Posted by Hitch

That's correct. If you use it elsewhere--for example, you create a class named "body," and put that on a div that, say, encompasses the entire content section--then they can't change the font. It can only be changed easily/simply (by the typical Kindle user, I mean) if the font is placed on the body tag.

In the test epub I uploaded the html has has no divs, or classes.


But I tried again:

if CSS;
p { font-family: sans-serif; }
-- font is locked.

If
body { font-family: sans-serif; }
-- font is not locked.

Does that make sense?

But I've learnt not to expect everything Kindle to make sense.
I would expect that if anything would lock the font it would be "body", since that contains everything else. But not so, apparently

How about the related issue:
If I have an embedded font for some display text, and to make the embedded font show you have to choose "Publisher Font" on Kindle. That made the body text sans for some stupid reason (surely the default is serif?), so I put "font-family:serif" in the body css. But that forced it to Bookerly. No way for the user to choose one of the other system fonts like Baskerville. I assume I could choose Palatino, Baskerville, etc. in my css, but again that leaves the reader stuck with my choice of body text. Which is better than sans but still not ideal.

Kindle is convenient but I miss the variety of layout of actual books and after a couple of months of just Bookerly it was palling, so I'm currently alternating between Bookerly and Baskerville for my own reading. So I don't like to take the choice away.

I'm beginning to see why some publishers just use images for special text rather than wrestle with this.

[Hitch]

Originally Posted by AlanHK

In the test epub I uploaded the html has has no divs, or classes.


But I tried again:

if CSS;
p { font-family: sans-serif; }
-- font is locked.

If
body { font-family: sans-serif; }
-- font is not locked.


But I've learnt not to expect everything Kindle to make sense.

Well, this is how they've set it up-and how it's documented in their Publishing Guidelines.

I would expect that if anything would lock the font it would be "body", since that contains everything else. But not so, apparently

Right.

How about the related issue:
If I have an embedded font for some display text, and to make the embedded font show you have to choose "Publisher Font" on Kindle. That made the body text sans for some stupid reason (surely the default is serif?), so I put "font-family:serif" in the body css. But that forced it to Bookerly. No way for the user to choose one of the other system fonts like Baskerville. I assume I could choose Palatino, Baskerville, etc. in my css, but again that leaves the reader stuck with my choice of body text. Which is better than sans but still not ideal.

This is a known thing. I don't know if Amazon considers it a bug; we first reported it to them several years ago, on the entire family of PPW/Voyage/Oasis devices. If you embed ANY font, any at all, for anything--even just a fleuron--the body font will immediately show as sans serif. To work around this, embed the font you want, for whatever you want, and use the body tag for the font you want them to be able to change. Right?

Kindle is convenient but I miss the variety of layout of actual books and after a couple of months of just Bookerly it was palling, so I'm currently alternating between Bookerly and Baskerville for my own reading. So I don't like to take the choice away.

I'm beginning to see why some publishers just use images for special text rather than wrestle with this.

Well, I don't know how many books you've made, so it's hard for me to comment. We do scads--it's thousands now, which surprises me daily when I think about it--and I hardly think about it any more. YES, it can be frustrating, but...just think how boring it would be if it was always the same.

Hitch

[AlanHK]

Originally Posted by Hitch

This is a known thing. I don't know if Amazon considers it a bug; we first reported it to them several years ago, on the entire family of PPW/Voyage/Oasis devices. If you embed ANY font, any at all, for anything--even just a fleuron--the body font will immediately show as sans serif. To work around this, embed the font you want, for whatever you want, and use the body tag for the font you want them to be able to change. Right?

-- Sorry, not sure if I'm getting this.

I have a book with CSS like:

body {font-family: serif; }
@font-face { font-family: 'Fraktur'; font-weight: normal; font-style: normal; src: url('../Fonts/OldEng.ttf'); }
.Fraktur { font-family: 'Fraktur', serif; font-style: normal; }

And apply it with a span:
<span class="Fraktur">Christmas Greetings!</span>

I can choose a font on Kindle, but then the Fraktur style doesn't show. If I choose "publisher font" then everything else becomes Bookerly. So the reader can choose the body font, at the cost of screwing up the display text.
Is that what you meant?

[jhowell]

I suspect that the "body {font-family: serif; }" is causing the problem. You should not need this.

[JSWolf]

Originally Posted by AlanHK

I have a book with CSS like:

body {font-family: serif; }
@font-face { font-family: 'Fraktur'; font-weight: normal; font-style: normal; src: url('../Fonts/OldEng.ttf'); }
.Fraktur { font-family: 'Fraktur', serif; font-style: normal; }

And apply it with a span:
<span class="Fraktur">Christmas Greetings!</span>

I can choose a font on Kindle, but then the Fraktur style doesn't show. If I choose "publisher font" then everything else becomes Bookerly. So the reader can choose the body font, at the cost of screwing up the display text.
Is that what you meant?

You have two problems. One is the font-family in body. That has to go. The other is the use of Fraktur. The way the Kindle works is you either use a font from the list or you use Publisher font and get whatever the default is.if you don't need Fraktur, remove it too. If you do need it, then you may be screwed. Embedded fonts is one thing Amazon botched big time.

[Hitch]

Originally Posted by AlanHK

-- Sorry, not sure if I'm getting this.

I have a book with CSS like:

body {font-family: serif; }
@font-face { font-family: 'Fraktur'; font-weight: normal; font-style: normal; src: url('../Fonts/OldEng.ttf'); }
.Fraktur { font-family: 'Fraktur', serif; font-style: normal; }

And apply it with a span:
<span class="Fraktur">Christmas Greetings!</span>

First, I admit, I misunderstood you. I thought I understood you to say that when you embedded a font, the body font turned to sans-serif. That's what I thought I was addressing.

If you don't care what the reader does, with the body, you should remove the body font tag. No reason for it, unless you want to force the body font to be serif (and NOT sans serif on the KF8 eInks). If you do want the body font to be other than sans, then keep the body font declaration.

Secondly, don't use spans to create the font for the Fraktur. Apply it to the correct classes, e.g, p.Fraktur, h1.fraktur, or whatever you're going to call them. There's a definite, not-yet-fully-understood issue with fonts on Spans, in MOBI format. For one thing, there's a limit to the number of spans. I'm not sure that it's what's affecting your book, but it absolutely, positively exists.

I can choose a font on Kindle, but then the Fraktur style doesn't show. If I choose "publisher font" then everything else becomes Bookerly. So the reader can choose the body font, at the cost of screwing up the display text.
Is that what you meant?

That should not be happening. Regardless of whether you choose Publisher font or not, the Fraktur should display. Try going back and applying the font on the correct elements, rather than spans, and see if the issue persists. FWIW, unless it's a one-off, at my shop, bookmakers are not allowed to use spans for fonts. Too many issues surrounding that sort of undifferentiated usage.

Originally Posted by jhowell

I suspect that the "body {font-family: serif; }" is causing the problem. You should not need this.

Unless he wants to force the reader to see/read the book in sans-serif, he DOES need that. As I mentioned a post or two back, on the KF8 eInks, there's a bug/thing/issue--once you embed a font, no matter for what, or how many times you need it, etc., all--ALL--the KF8 eInks will display the body in sans-serif only.

It's the devil's choice--the devil and the deep blue sea, but my feeling is that given as all the studies have clearly shown that serif is the better choice for reading comprehension, at least choose on the side of serif as the forced choice. Someone else is, of course, free to make their own choices.

One last n.b.: you should consider using an otf for that use, rather than ttf. That's likely not related to the issues you're having, but IME, otf works better overall.

Hitch

[Hitch]

Originally Posted by JSWolf

You have two problems. One is the font-family in body. That has to go. The other is the use of Fraktur. The way the Kindle works is you either use a font from the list or you use Publisher font and get whatever the default is.if you don't need Fraktur, remove it too. If you do need it, then you may be screwed. Embedded fonts is one thing Amazon botched big time.

Wolfie, my curmudgeonly pal:

You're not reading the thread closely, sweetie. He wants the Fraktur, and it was I who told him to use the body font declaration, for the reasons I've listed. You're right in that he doesn't have to use it, but if he doesn't, the KF8 eInks will all force the reader to view the body in sans-serif.

And the main font on the body tag is, amazingly enough, the Tao of Amazon. Right there in the last few PG's.

Hitch

[JSWolf]

Originally Posted by Hitch

Wolfie, my curmudgeonly pal:

You're not reading the thread closely, sweetie. He wants the Fraktur, and it was I who told him to use the body font declaration, for the reasons I've listed. You're right in that he doesn't have to use it, but if he doesn't, the KF8 eInks will all force the reader to view the body in sans-serif.

And the main font on the body tag is, amazingly enough, the Tao of Amazon. Right there in the last few PG's.

Hitch

When you say KF8 will force sans-serif, do you mean it will force sans-serif if publisher font is used? Unless the book specifically states that there are embedded font(s), most people will just be using the default of Bookerly.

[Hitch]

Originally Posted by JSWolf

When you say KF8 will force sans-serif, do you mean it will force sans-serif if publisher font is used? Unless the book specifically states that there are embedded font(s), most people will just be using the default of Bookerly.

I'm saying that the book will display in sans-serif, if any font is embedded therein, and as far as I know, you can't then override the sans-serif by switching the fonts, whether Publisher, or any of the firmware fonts. It's a weird thing, but there it is.

Hitch

[AlanHK]

Originally Posted by jhowell

I suspect that the "body {font-family: serif; }" is causing the problem. You should not need this.

Yes I do.
Without that, with "Publisher font" selected, the body font becomes sans.

[jhowell]

Originally Posted by AlanHK

Yes I do.
Without that, with "Publisher font" selected, the body font becomes sans.

But you should not need to select “publisher font” at all.

Your book should display any of the built-in fonts selected by the user for the main text. It should also show your embedded font in the limited places it is used, regardless of which main font the user has chosen.