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.
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.