Font tests: results and query

[eggheadbooks1]

Last year I designed a book for 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. I relied on Kindle Previewer for results on Paperwhite and Kindle, though Previewer is often not a reliable tool. The results were:

• Kindle Fire: the ebook displays as designed. User cannot change the primary font (which may irritate some) and the SourceSansPro displays correctly.
• Kindle for Mac/PC app: both apps use their default (and only) font for the main text, but the SourceSansPro displays correctly.
X Paperwhite: the ebook does not display correctly. User can select the font but all text displays the same. The embedded font is ignored.
X Kindle: the ebook does not display correctly. All text displays in Caecilia. The embedded font is ignored.

With some recent updates to Kindle’s programming, and hoping to find a way to achieve uniformity across devices, I recently performed various tests, unfortunately with the same mixed results. The first test was:

No font definitions included for primary text; SourceSansPro embedded and coded for secondary text. The results were:

• Kindle Fire: the ebook displays as designed. User can change their primary font but the SourceSansPro displays correctly.
• Kindle for Mac/PC app: both apps use their default (and only) font for the main text, but SourceSansPro displays correctly.
X Paperwhite: the ebook does not display correctly. User can select the font but all text displays the same. The embedded font is ignored.
X Kindle: the ebook does not display correctly. All text displays in Caecilia. The embedded font is ignored.

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. The user can change their primary font and the ugly Monospace font displays correctly.
X Kindle for Mac/PC app: the ebook does not display correctly. Everything is displayed in the app’s default font.
• 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.

Next test used the Primary and Secondary font codes as recommended by the Kindle Publishing Guide. The results were:

• Kindle Fire: the font differentiation is there. The user can change their primary font and the default secondary font is Verdana.
X Kindle for Mac/PC app: the ebook does not display correctly. Everything is displayed in the app’s default font.
• Paperwhite: same as on the Kindle Fire except that the default secondary font is Helvetica.
X Kindle: the ebook does not display correctly. All text displays in Caecilia. The secondary font code is ignored.

Lastly, I tried mixing the Primary/Secondary method with the embedded secondary font ({font-family:"SecondaryFont", "SourceSansPro-Regular";} and vice versa), as well as combining Monospace and SourceSansPro, hoping one would work for Paperwhite and Kindle while the other would work for the Fire and the Kindle apps. Alas, this has no effect.

Has anyone else done similar tests and who has an actual Kindle or Paperwhite to test on instead of relying on Previewer? I would be interested to hear your results.


Michelle