Cannot get the kerning of some specific .ttf fonts with freetype -
i trying extract kerning information out of .ttf fonts freetype 2.6 library.
this how kerning informations (looping through characters):
if( ft_has_kerning(face->getface()) && previous ){ ft_vector delta; ft_uint glyph_index = ft_get_char_index( face->getface(), character ); ft_uint prev_index = ft_get_char_index( face->getface(), previous ); ft_get_kerning( face->getface(), prev_index, glyph_index, ft_kerning_default, &delta ); kerning = delta.x >> 6; }
i tried program different fonts: "times new roman.ttf", "tymes.ttf", "minion.otf". times new roman font only, kerning information correctly extracted, , checked logging info.
the problem don't understand why kerning 0 (i.e. ft_has_kerning returns false, , ft_getkerning returns 0 anyway) other 2 fonts.
i checked fontforge kerning info present pairs "va" , "to", , there! must stored in .ttf. nevertheless, code above kerning 0 "va" or "to", or ft_has_kerning returns false.
is there freetype option or setting missing here? kind of enlightenment appreciated..
edit: setting face size with
ft_set_pixel_sizes( face->getface(), 0, size);
freetype can retrieve kerning values font's kern
table, not more modern implementation opentype feature using gpos
. documentation:
note opentype fonts (otf) provide 2 distinct mechanisms kerning, using ‘kern’ , ‘gpos’ tables, respectively, part of otf files. older fonts contain former, while recent fonts contain both tables or ‘gpos’ data only. freetype supports kerning via (rather simple) ‘kern’ table. interpretation of kerning data in (highly sophisticated) ‘gpos’ table need higher-level library icu or harfbuzz since can context dependent (this is, kerning may vary depending on position within text string, example).
your freetype code works times new roman (mine "monotype:times new roman regular:version 5.11 (microsoft)") because contains both tables:
tag 'gpos' checksum 5dfeb897 offset 778576 length 43506 tag 'kern' checksum a677acd1 offset 734088 length 5220
but other fonts not contain kern
one.
gpos
kerning preferred on plain kern
because tables can linked particular script , language, , offers finer control.
there reasons contain 1 type of table – if both present, it's font renderer select one. microsoft's recommendations opentype fonts, example, states following:
the off specification allows cff ot fonts express kerning in kern table. many off text layout engines support this. windows gdi’s cff ot driver, however, ignores kern table in cff ot font when prepares kerning pairs report via pair kerning api.
when kern table , gpos table both present in font, , off layout engine requested apply kerning run of text of particular script , language system: (a) if number of kern feature lookups in resolved language system in gpos table zero, kern table should applied, followed remaining gpos features requested. (b) if number of kern feature lookups in resolved language system in gpos table non-zero, gpos lookups, including kern lookups, should applied in usual way , kern table data ignored.
Comments
Post a Comment