UPDATED 11 June 2014
(NOTE: where I include code, the quotation marks should be straight quotes, not curly quotes. When I updated my WordPress site it began automatically using curly quotes, and I cannot find a way to stop it.)
If you are designing a book for Kindle where the book uses only a single font, you do NOT include font definitions anymore. Amazon, in fact, now strip out such font definitions. This is because font definitions can prevent the user from selecting their preferred font. This article is for those who need to use more than one font to create font differentiation in their ebook.
Last year I designed a book for a client that involved a dialogue between two people, differentiated by a font change. In order to achieve our goal, I included the font definition {font-family: “Palatino”, “serif”;} in my CSS paragraph definitions for the main text; for my secondary text I embedded the open-source font SourceSansPro-Regular and its italic counterpart, SourceSansPro-Italic, and coded accordingly: {font-family: “SourceSansPro-Regular”;}. The results were tested in my Kindle Fire and on both Kindle for Mac and Kindle for PC. At the time the files worked perfectly.
But since then Amazon have released the Paperwhite and recently they updated the apps, so first I rechecked the original file and then I ran new tests. The results were:
√ Kindle Fire: the ebook displays as designed. Users cannot change the primary font (which may irritate some) and the SourceSansPro displays correctly.
√ Kindle for Mac/PC app: both apps use their default font for the main text, and the SourceSansPro displays correctly.
√ X Paperwhite: the ebook displays correctly if the user selects Publisher Font. Users can select their own font, but then the embedded fonts are ignored and all text displays the same. Unfortunately, users have to go into their device preferences to accept publisher fonts, and I am told few users are even aware this option exists.
X Kindle: the ebook does not display correctly. All text displays in Caecilia. The embedded font is ignored because older Kindle devices cannot read embedded fonts.
Hoping to find a way to achieve some semblance of uniformity across devices, I tried another option, unfortunately with the same mixed results.
The first test was: no font definitions included for primary text; SourceSansPro was embedded and coded for secondary text. The results were:
√ Kindle Fire: the ebook displays as designed. Users can change their primary font and the SourceSansPro displays correctly.
√ Kindle for Mac/PC app: both apps use their default font for the main text, and SourceSansPro displays correctly.
√ X Paperwhite: the ebook displays correctly if the user selects Publisher Font. Users can select their own font, but then the embedded fonts are ignored and all text displays the same.
X Kindle: the ebook does not display correctly. All text displays in Caecilia. The embedded font is ignored because older Kindle devices cannot read embedded fonts.
Next test was: no font definitions included at all for primary text, and Amazon’s recommended Monospace font (an unattractive Courier-like font) was used for the secondary text. The results were:
√ Kindle Fire: the font differentiation is there but it’s ugly. Users can change their primary font and the ugly Monospace font displays correctly.
√ Kindle for Mac/PC app: the font differentiation is there but it’s ugly. Main text is in the app’s default font and Monospace displays correctly.
√ Paperwhite: same as the Kindle Fire.
√ Kindle: Default font is Caecilia, but the Monospace font displays correctly and is different enough from Caecilia to create visual separation.
However, a bug was revealed: if you code in ‘font-family=”monospace”;’ the code is not read by the Kindle for PC app. But if you code in ‘font-family=monospace’ the problem is solved. Normally whether or not you put the font family in quotation marks is irrelevant in Kindle devices.
Finally, I did a test based on the way the Kindle Fire was programmed when it was first released: I coded in Arial as my primary font and Georgia as my secondary font. I included font definitions in my CSS, but, because the Kindle Fire already has both fonts installed, there is no need to embed them. The results were as expected:
√ Kindle Fire: the Fire displays both fonts and the user cannot change them.
√ Kindle for Mac/PC app: identical to the Kindle Fire, suggesting the app has the same licensed fonts as the Fire.
X Paperwhite: The Paperwhite, not having Arial and Georgia installed, cannot display them and defaults to Helvetica. Moreover, users cannot change their font.
X Kindle: All text displays in Caecilia.
So far the only way to have two fonts display across all Kindle devices is to use the hideous Monospace. Slim pickings, Amazon.
Yes, that is my understanding as well, which only adds to the confusion. The other problem is that, as has happened in the past, someone informs Amazon of oddities such as this, Amazon fix the problem, but then never announce the change. So what works this month may not in the next. You have to test and test and test and test … it is beyond tedious.
Amazon also tweak their programming with each new device. While improving your product as it evolves makes sense, not updating the firmware on previous devices still in use leaves ebook publishers with a situation where, if you had a complex ebook designed, say, a year ago, you ideally should have it redone to take advantage of new coding possibilities and the fixes Amazon have since made. How often can a publisher afford to update the code in their ebook?
Michelle,
As I understand it, CSS syntax only calls for double quotes around font names comprised of more than one word. Maybe Kindle is being a little pedantic on that point.
Best wishes
Gordon
Michelle,
Do you of any place to obtain a previewer for the Paperwhite?
Have a great day.
Take care,
Darwin
P.S. I forgot to reply in my previous question…
Michelle,
Do you of any place to obtain a previewer for the Paperwhite?
Have a great day.
Take care,
Darwin
Michelle,
Thanks for your articles about Kindle fonts. They are very helpful.
Do you know if it is possible to get Unicode text (e.g., Hebrew characters) to display on the Kindle DX?
Can you please tell me where to obtain all of the previewers that you mentioned in your articles, especially the different versions of the Paperwhite previewer(s)?
Finally, have you been able to get drop caps to display correctly on the various devices? (In the previewers that I have access to, it looks great on some devices but not so good on others.)
Have a great day.
Take care,
Darwin
No. Unless you can find an earlier release of Kindle Previewer and then do not update. Why is previewing on the Paperwhite so important?
Hebrew is not supported by Kindle at all. Supported languages are here: https://kdp.amazon.com/help?topicId=A9FDO0A3V0119.
The Previewer is at https://kdp.amazon.com/help?topicId=A3IWA2TQYMZ5J6, but it no longer shows the Paperwhite; it now uses Voyager. Amazon always update the Previewer to display only their latest device in each category: mobi7 (Kindle DX), mobi8 (Fire), and mobi8 grayscale (used to be Paperwhite, now is Voyager).
Drop caps are Kindle Format 8 and will only display properly on mobi8 devices. The code I illustrate in my book The Global Indie Author, 3rd edition, will create a drop cap that works in mobi8 devices and will display as a large cap on mobi7 devices.