Kindle Font Quirks

charleski · 11-04-2015, 06:18 AM

This post is fairly technical and will only be of interest to those designing books for the Kindle that use embedded fonts.

Vertical font metrics is a troublesome area that has never been properly standardised. For an overview of the various strategies font designers can adopt this page gives a summary of the common options.

Unfortunately, while RMSDK-based ePub readers are robust enough to handle these strategies properly, the Kindle is far stricter, and fonts that use the wrong strategy will end up being clipped at the top of the screen and have the wrong leading. The Kindle relies on the hhea values (and only on those values) to set the font's vertical spacing. hhea.LineGap is ignored and the system inserts its own leading value [This was my initial thought, but it's wrong, the hhea.LineGap value is added in to the vertical advance, but I'm still working out a quantitative measure that will distinguish it from the system-applied leading]. The picture below shows an exaggerated example using incorrect hhea values:

Many fonts are aimed at Mac users and layout apps and use the 'Adobe Strategy' described in the page linked above. These will produce undesireable results on the Kindle. The fix is fairly simple, but involves using FLS or a free editing program like FontForge to modify the vertical metrics and ensure that hhea.Ascender and hhea.Descender match the vertical bounds of the typeface's characters. For a full write-up of the best strategy to use, see Karsten Luecke's advice here, which works for the Kindle as well as more generally.

Dr. Drib · 11-04-2015, 07:57 AM

Moved out of the Kindle forum and into the Kindle Formats Forum - where it belongs.

Don
(Moderator)

charleski · 11-04-2015, 07:18 PM

Dan, this is not a format issue! It specifically relates to the rendering engine used in the hardware eInk Kindles. K4PC uses a different engine based on QT and will not show the behaviour described here (K4PC will clip based on the WinAscent/WinDescent values, as seen in other QT-based html rendering engines).

HarryT · 11-05-2015, 04:04 AM

Your post is aimed at ebook creators, not Kindle users, so this is the appropriate place for it.

JSWolf · 11-05-2015, 05:35 AM

The Kindle font engine uses different metric values than the font engine used with RMDSK for the default line height.

Doitsu · 11-05-2015, 06:06 AM

@Charleski: Can you give examples of fonts that have incorrect hhea.Ascender and hhea.Descender values and post before and after pictures?

dgatwood · 11-07-2015, 03:59 PM

IIRC, most of those Kindle readers, by default, set the line height to 1.2, and that's the minimum allowed line height, so the minimum distance between lines is 1.2 times the em square. I don't think it cares about the line gap, though IIRC some readers (those using the non-QT version of WebKit, like iOS) do take it into account if the em square plus that value exceed 1.2x the em square. I think.

In the photo above, the em square is probably smaller than the sum of the ascender and descender, resulting in the line height being too small.

I've seen this frequently, mostly with older fonts. I haven't seen it in any fonts created in the past decade or so, because most of the font tools these days provide access to parts of Adobe's font SDK, which IIRC provides (among other things) tools for computing all of those values automatically.

JSWolf · 11-07-2015, 06:51 PM

I have modified the metrics in a version of Charis SIL whereby the line height is reduced to something normal on a Kindle.

https://www.mobileread.com/forums/sho...d.php?t=184056

11-04-2015, 06:18 AM	#1
charleski Wizard Posts: 1,196 Karma: 1281258 Join Date: Sep 2009 Device: PRS-505	Kindle Font Quirks This post is fairly technical and will only be of interest to those designing books for the Kindle that use embedded fonts. Vertical font metrics is a troublesome area that has never been properly standardised. For an overview of the various strategies font designers can adopt this page gives a summary of the common options. Unfortunately, while RMSDK-based ePub readers are robust enough to handle these strategies properly, the Kindle is far stricter, and fonts that use the wrong strategy will end up being clipped at the top of the screen and have the wrong leading. The Kindle relies on the hhea values (and only on those values) to set the font's vertical spacing. hhea.LineGap is ignored and the system inserts its own leading value [This was my initial thought, but it's wrong, the hhea.LineGap value is added in to the vertical advance, but I'm still working out a quantitative measure that will distinguish it from the system-applied leading]. The picture below shows an exaggerated example using incorrect hhea values: Many fonts are aimed at Mac users and layout apps and use the 'Adobe Strategy' described in the page linked above. These will produce undesireable results on the Kindle. The fix is fairly simple, but involves using FLS or a free editing program like FontForge to modify the vertical metrics and ensure that hhea.Ascender and hhea.Descender match the vertical bounds of the typeface's characters. For a full write-up of the best strategy to use, see Karsten Luecke's advice here, which works for the Kindle as well as more generally. Attached Thumbnails Last edited by charleski; 11-05-2015 at 04:09 AM.

11-04-2015, 07:18 PM	#3
charleski Wizard Posts: 1,196 Karma: 1281258 Join Date: Sep 2009 Device: PRS-505	Dan, this is not a format issue! It specifically relates to the rendering engine used in the hardware eInk Kindles. K4PC uses a different engine based on QT and will not show the behaviour described here (K4PC will clip based on the WinAscent/WinDescent values, as seen in other QT-based html rendering engines). Last edited by charleski; 11-04-2015 at 07:37 PM.

11-07-2015, 03:59 PM	#7
dgatwood Curmudgeon Posts: 629 Karma: 1623086 Join Date: Jan 2012 Device: iPad, iPhone, Nook Simple Touch	IIRC, most of those Kindle readers, by default, set the line height to 1.2, and that's the minimum allowed line height, so the minimum distance between lines is 1.2 times the em square. I don't think it cares about the line gap, though IIRC some readers (those using the non-QT version of WebKit, like iOS) do take it into account if the em square plus that value exceed 1.2x the em square. I think. In the photo above, the em square is probably smaller than the sum of the ascender and descender, resulting in the line height being too small. I've seen this frequently, mostly with older fonts. I haven't seen it in any fonts created in the past decade or so, because most of the font tools these days provide access to parts of Adobe's font SDK, which IIRC provides (among other things) tools for computing all of those values automatically. Last edited by dgatwood; 11-07-2015 at 04:03 PM.

11-07-2015, 06:51 PM	#8
JSWolf Resident Curmudgeon Posts: 79,484 Karma: 145863170 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I have modified the metrics in a version of Charis SIL whereby the line height is reduced to something normal on a Kindle. https://www.mobileread.com/forums/sho...d.php?t=184056 Last edited by JSWolf; 07-11-2016 at 01:25 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
ePub to (old) Mobi has some strange quirks	freney	Conversion	9	06-10-2014 11:22 PM
Sideloading ebooks and cover image quirks?	Cameronpaterson	Kobo Tablets	10	01-19-2012 08:38 AM
Cool-er Quirks and Issues	sassanik	Interead COOL-ER	3	01-04-2010 03:24 PM
Book Designer 4.0 Quirks?	drmathprog	Workshop	1	03-19-2009 10:11 AM
Strange Quirks?	PinkTissue	HanLin eBook	1	12-01-2008 12:57 PM

11-04-2015, 07:57 AM	#2
Dr. Drib Grand Sorcerer Posts: 45,394 Karma: 59504381 Join Date: Jan 2007 Location: Peru Device: KINDLE: Oasis 3, Scribe (1st), Matcha; KOBO: Libra 2, Libra Colour	Moved out of the Kindle forum and into the Kindle Formats Forum - where it belongs. Don (Moderator)

11-05-2015, 04:04 AM	#4
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383099 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Your post is aimed at ebook creators, not Kindle users, so this is the appropriate place for it.

11-05-2015, 05:35 AM	#5
JSWolf Resident Curmudgeon Posts: 79,484 Karma: 145863170 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	The Kindle font engine uses different metric values than the font engine used with RMDSK for the default line height.

11-05-2015, 06:06 AM	#6
Doitsu Grand Sorcerer Posts: 5,709 Karma: 24031401 Join Date: Dec 2010 Device: Kindle PW2	@Charleski: Can you give examples of fonts that have incorrect hhea.Ascender and hhea.Descender values and post before and after pictures?

Advert

Advert