Quote:
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.
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.