Re: [ft-devel] Problem with FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH

[Bram Tassyns]

> 
> Folks,
> 
> 
> I got a bug report about a subsetted TrueType font with a buggy `post'
> table:
> 
>   <post>
>     <formatType value="3.0"/>
>     <italicAngle value="0.0"/>
>     <underlinePosition value="-217"/>
>     <underlineThickness value="150"/>
>     <isFixedPitch value="1091"/>
>     <minMemType42 value="70648888"/>
>     <maxMemType42 value="71304253"/>
>     <minMemType1 value="72025145"/>
>     <maxMemType1 value="603979776"/>
>   </post>
> 
> In particular, the `isFixedPitch' value is incorrect (it should be
> zero).  If you use the default load flags, FreeType trusts the value
> in the `post' table and consequently uses `advanceWidthMax' as the
> advance width for all glyphs.  This particular font, however, distorts
> the shape of some glyphs in dependence on the horizontal phantom
> points, causing really bad rendering results.
> 
> A quick fix is to add FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH to the load
> flags.  However, this is a hack, not a solution.  In function
> `compile_glyph_metrics' (in file ttgload.c) we have this:
> 
>   if ( face->postscript.isFixedPitch                                     &&
>        ( loader->load_flags & FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH ) == 0 )
>     advance = face->horizontal.advance_Width_Max;
> 
> I think we need some heuristics to improve that, given that the
> `isFixedPitch' field is obviously not reliable.
> 
> Any suggestions?  Some ideas come to my mind:
> 
>   . Complete `advance_Width_Max' completely and always use the values
>     from the `hdmx' table.
> 
>   . Recompute `advance_Width_Max' and use the original value only if
>     it is greater than the actual widths.  [I don't think this is a
>     good idea.]
> 
> 
>     Werner
> 
> 
> PS: I've now implemented key `A' in ftview which allows, similar to
>     `ftdiff', to toggle this flag.
> 

Are the values correct for the glyphs that are part of the subset?

Assuming the creator of this font didn't just write random values,
it's likely that when creating the subset the post table was recreated
taking only the actually used glyphs into account (and not all glyphs in the
font).

If that is the case I think that the old behavior is good enough (you'll
render existing documents correctly). You might get issues when editing a
document with such a font, but that's almost always the case for subsetted
fonts (for that case the editing application is at fault for using a
subsetted font as if it was a complete one).

Regards,
Bram