Embedded custom fonts and fallback styling

[santosha]

I'd like to style some headings in a book with a custom font and with small-caps.

My research has led me to understand that pre-KF8 Kindles do not support either of those elements (custom fonts, smallcaps) and my question is if I need to do fallback-styling with media queries--which actually seems pretty straight forward--or if the pre-KF8 devices simply will ignore the embedded font/smallcaps styling and default back to whatever the user chooses/is default?

I'm fine with the font/styling being vanilla on pre-KF8 ereaders, rather than trying to simulate something that may look somewhat similar to smallcaps (as I read you could do with slightly smaller font-size and uppercase, etc., as advised in another thread by JSWofl).

I'd also like to ask the same question in a more general way: is it always better to define fallback-styling (even if the pre-KF8 ereader would ignore KF8 styling and default back to something else) or is it a good practice to just define KF8-only supported elements as long as the pre-KF8 ereader simply ignores that "advanced" element? Does it even know what to revert back to or is that kind of a gamble to be avoided?

I hope I made it at least somewhat clear--thanks in advance!

Santosha

[storax]

Hello Santosha,

Since no one else has replied and I've been struggling with similar issues, I thought I'd chip in even though I'm a rank beginner.

In short, I think some type of fallback styling is needed, and that an @media query forking between mobi and kf8 may not always be enough. I have a Paperwhite, which speaks kf8, but styling based on embedded fonts is ignored unless ‘Publisher Font’ is selected.

My thoughts are still incomplete, but here’s what I’ve learned so far.

I'm currently formatting a book (my very first) as a favor for an author-friend, and I’m trying to do two simple things:

• Add a decorative element to section breaks.
  
• Add a small image to the title page and to an 'About the Author' page. (It's a glyph taken from an old woodcut, which the author uses like a chop mark).

My workflow is HTML => Sigil => KindleGen. I know HTML and CSS fairly well, and enough RegEx for the simple tasks involved. Both the HTML and CSS passed the W3C validator.

So it should be a piece of cake, right?

The ePub looked great in ADE, and the mobi file looked good on my PW. Then I tried it on Kindle Previewer and found that the images looked horrible if I switched to sepia or night views when emulating one of the Kindle Fires. Searching the MR forums, I learned that Kindle support for transparent backgrounds in image files is broken. (I was using transparent .gifs)

My next idea was to use an @media query:

• The basic CSS would set ‘display: none;’ on the elements containing the images and instead use decorative characters from an embedded font. The font would have to be modified, of course, to include the author’s glyph. This, I was thinking, would work for both ePub and kf8.
  
• @media amzn-mobi would set ‘display: none;’ on all elements referencing the embedded font, and ‘display: block;’ on those containing the images. Since the target devices are b&w, my thinking is that the lack of transparent backgrounds would be acceptable.

I’ve been testing my idea with a font I found in a thread on Dividers and fleurons. My testing is not complete ― all I’ve done so far is embed the font and use it for the section breaks ― but I’ve already encountered the font selection problem I mentioned above: on my PW, unless I select ‘Publisher Font’, I get the letter the glyph maps to instead of the glyph from the embedded font. I surely can’t expect the person reading the book to switch fonts, so my idea will only work if the decorative character I want to use maps to an appropriate characters included in the basic Kindle fonts, such as ‘•’ or ‘*’. That way, if the reader has selected their own font ― which I have to assume will generally be the case ― they’ll get something like this

•

for a section break. I’m a survivor of the browser wars, so I’d really like to find ‘the one ring that rules them all’. I hope I can have one set of HTML and CSS that serves for both ePubs and Kindles.

Anyway Santosha, that’s my current thinking.

Best of luck !
Storax

[Doitsu]

Originally Posted by storax

I'm currently formatting a book (my very first) as a favor for an author-friend, and I’m trying to do two simple things:

• Add a decorative element to section breaks.
  
• Add a small image to the title page and to an 'About the Author' page. (It's a glyph taken from an old woodcut, which the author uses like a chop mark).

For more Kindle formatting ideas also check out my CSS3 thread in the Kindle forum. It shows, for example, how to add a fleuron using CSS3 and doesn't require fallback styling, because CSS3 elements will simply be ignored by KindleGen when it generates the Mobi7 part of the master mobi file.

IMHO, it's nice to think of fallback styles, but I wouldn't waste too much time on it since the majority of Kindles in use support KF8. Only 3 older Models (K1, K2 an DX) don't support KF8 and most of them were bought by "early adopters" with enough disposable income to afford the latest models.

[RbnJrg]

Originally Posted by storax

...
I’ve been testing my idea with a font I found in a thread on Dividers and fleurons. My testing is not complete ― all I’ve done so far is embed the font and use it for the section breaks ― but I’ve already encountered the font selection problem I mentioned above: on my PW, unless I select ‘Publisher Font’, I get the letter the glyph maps to instead of the glyph from the embedded font. I surely can’t expect the person reading the book to switch fonts, so my idea will only work if the decorative character I want to use maps to an appropriate characters included in the basic Kindle fonts, such as ‘•’ or ‘*’.

I have been there before Finally I found a solution so the fleuron is showed always (that is, even if the user doesn't select "Publisher Font"). Now I convert the font glyph with the fleuron in a svg image. In the conversion, I transform the glyph in a "path" (svg path) so it's no neccesary to embed the font in the ebook. Read this post:

https://www.mobileread.com/forums/sho...62&postcount=7

Rubén

[storax]

Thank you, Doitsu !

This is very useful information indeed. I’m going to re-do my first line styling today; it’s a mobi7 kludge at the moment.

For more Kindle formatting ideas also check out my CSS3 thread in the Kindle forum. It shows, for example, how to add a fleuron using CSS3 and doesn't require fallback styling, because CSS3 elements will simply be ignored by KindleGen when it generates the Mobi7 part of the master mobi file.

This part is especially interesting to me; I’m reminded of when I made websites and knowledge of the various browser ‘features’ was often more valuable than HTML and CSS skills, especially for positioning. You could know the specs backwards and forwards, but heaven help you if you thought that was enough.

IMHO, it's nice to think of fallback styles, but I wouldn't waste too much time on it since the majority of Kindles in use support KF8. Only 3 older Models (K1, K2 an DX) don't support KF8 and most of them were bought by "early adopters" with enough disposable income to afford the latest models.

I appreciate your thoughts on this. What you say makes a lot of sense.

Thanks again for your generosity. These forums are fantastic !

Storax

[storax]

Thank you, Rubén!

I'm just getting started for the day; reading your post (and the thread it's in) is first on my list. I'm unfamiliar with svg images, so I guess I have some reading to do.

Thanks again for the tip!
Storax

[Hitch]

Originally Posted by Doitsu

For more Kindle formatting ideas also check out my CSS3 thread in the Kindle forum. It shows, for example, how to add a fleuron using CSS3 and doesn't require fallback styling, because CSS3 elements will simply be ignored by KindleGen when it generates the Mobi7 part of the master mobi file.

IMHO, it's nice to think of fallback styles, but I wouldn't waste too much time on it since the majority of Kindles in use support KF8. Only 3 older Models (K1, K2 an DX) don't support KF8 and most of them were bought by "early adopters" with enough disposable income to afford the latest models.

Doitsu:

My only quibble with this is that there are millions of e-ink Kindles still in use, and most of those early adopters don't show any signs of intending to get rid of them. Almost every reading group I belong to--and there's quite a few--has an overwhelming number of readers still using K2's, K3's that didn't get the upgrade (or chose not to) and DX's, not to mention K-1's. I wouldn't dismiss the e-inks out of hand, not at all.

I'd also add that fallback styles are nearly always necessary for dealing with any images that are less-than-full-screen-sized, particularly due to the massive ppi difference across devices.

Hitch

[Doitsu]

Originally Posted by Hitch

My only quibble with this is that there are millions of e-ink Kindles still in use, and most of those early adopters don't show any signs of intending to get rid of them.

This may sound mean, but, IMHO, that's their problem since they're by now outnumbered by KF8 enabled devices and apps, and unlike several years ago, new entry level Kindles and used older models are relatively affordable.

Originally Posted by Hitch

I wouldn't dismiss the e-inks out of hand, not at all.

I didn't dismiss e-ink devices at all, after all I own one.

However, when it comes to Kindles, fallback styles for embedded fonts or CSS3 styles are usually not required for the simple reason that Kindlegen will simply ignore them when it generates the Mobi7 part of the master .mobi file. This means that owners of older devices might miss out on some fancy formatting, but their "reading experience" won't be negatively affected.

I.e., fallback styles are usually only required for large tables, some images and multiple hard-coded <span> styles applied to single words or paragraphs, e.g. drop caps.

[storax]

Originally Posted by Hitch

I'd also add that fallback styles are nearly always necessary for dealing with any images that are less-than-full-screen-sized, particularly due to the massive ppi difference across devices.

This comment has piqued my curiosity. I can see where fallback styles would be useful for the difference between FLOAT-able and non-FLOAT-able readers, but don't understand why the ppi differences would need fallbacks.

Wouldn't it be sufficient to set the width of the image in percent?

DISCLAIMER: I haven't tried this yet; just thinking off the top of my head. ALL of my experience is with websites. In other words, a handy collection of misconceptions with which to begin.

[Hitch]

Originally Posted by storax

This comment has piqued my curiosity. I can see where fallback styles would be useful for the difference between FLOAT-able and non-FLOAT-able readers, but don't understand why the ppi differences would need fallbacks.

Wouldn't it be sufficient to set the width of the image in percent?

DISCLAIMER: I haven't tried this yet; just thinking off the top of my head. ALL of my experience is with websites. In other words, a handy collection of misconceptions with which to begin.

You cannot set image sizes in percentages for K7. You have to set it in actual pixels. If you endeavor to set an image size in percentages in K7, it will simply try to blow the image up to full-screen size, with less-than-gratifying results.

Websites and ebooks are two completely different things; websites have a freedom that ebooks really, really, really don't. ;-)

Hitch

[storax]

Originally Posted by Hitch

You cannot set image sizes in percentages for K7. You have to set it in actual pixels. If you endeavor to set an image size in percentages in K7, it will simply try to blow the image up to full-screen size, with less-than-gratifying results.

Thank you, Hitch! This is exactly the type of information I'm trying to learn. I think I feel a TABLE coming on -- columns for: ePub, K7, and K8 -- to keep track of what works where.

Websites and ebooks are two completely different things; websites have a freedom that ebooks really, really, really don't. ;-)

Yes, I've noticed that.

I'm glad my friend doesn't yet have the cover art done.