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.
I also tried mixing the Primary/SecondaryFont model with an embedded font, but no furtherance. I tried mixing the Monospace font method with an embedded font, also to no avail.
What I find particularly annoying about all this is that it appears that Amazon’s recommended font encoding is designed to work only in dedicated devices but not in apps. Why the hell will Amazon not just programme them all to work the same way? It’s as if they want us coders to design only for dedicated devices, as if poor user experience in its apps will encourage consumers to abandon their tablets and smartphones for a Kindle. I suggest it will not, and will only aggravate those users and lead them to believe a book was poorly built, not that the app is poorly designed.
What also makes this particularly annoying is that Amazon’s new image requirements for Kindle represent, to me anyway, that Amazon themselves recognize the use of high-resolution tablets among their users, and these new image requirements are not merely to accommodate the new Kindle HD, as the latest Kindle Publishing Guidelines would have us believe — the new Kindle HD’s screen is only 1280 pixels high: who needs a 5MB file to fill a 1280-pixel screen? No one. These 5MB images are for the iPad3, whose screen is 2048 pixels.
Source:
http://ift.tt/1gVFEOt