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); 

edit: kerning info "tymes" font in fontforge: enter image description here

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

Popular posts from this blog

python - Healpy: From Data to Healpix map -

c - Bitwise operation with (signed) enum value -

xslt - Unnest parent nodes by child node -