bugThe FreeType Project - Bugs: bug #56601, Odd behavior with variable hinted...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #56601: Odd behavior with variable hinted font.

Submitter:  bungeman <bungeman>
Submitted:  Tue 09 Jul 2019 04:17:55 PM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.2

Jump to the original submission

Fri 12 Jul 2019 08:55:27 AM UTC, comment #6: 

Yeah, thanks a lot!  Patch applied (with slight modifications).

Werner LEMBERG <wl>
Group administrator
Thu 11 Jul 2019 06:41:02 PM UTC, comment #5: 

Thank you for the analysis and the fix.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 10 Jul 2019 04:02:05 PM UTC, comment #4: 

This issue affects FreeType versions 2.9 to current 2.10.1, and started with the two related FreeType commits e7935f2910 and d062c54ce7. These commits fixed other issues, but appear to have introduced this one.

bungeman <bungeman>
Wed 10 Jul 2019 02:25:43 PM UTC, comment #3: 

Attaching hvar_vvar_hinted_scale.diff with a possible patch for this issue. This patch ensures that the phantom points are always assigned scaled values in all cases.

Note that this issue appears to occur in any font where there is an HVAR/VVAR table to provide adjusted metrics and the glyph is hinted and the minimal v40 engine is used. In other situations the loader's phantom points will end up being updated from the phantom points in the outline->points.

(file #47189)

bungeman <bungeman>
Wed 10 Jul 2019 04:27:50 AM UTC, comment #2: 

It appears that in TT_Process_Simple_Glyph the phantom points on the loader are not scaled (when using HVAR/VVAR values. The phantom points in the outline->points are scaled, but when these are not assigned back to the loader the loader continues to have unscaled (funit) values for the phantom points. Scaling these values directly when they will not be assigned from the outline->points phantom points seems like the right way to fix this.

bungeman <bungeman>
Tue 09 Jul 2019 10:36:01 PM UTC, comment #1: 

I ran ftgrid with FT2_DEBUG="ttgload:2 ttinterp:7" on glyph 1 ('A') and skimming through here I don't see that the horizontal  phantom points (11 or 12 for this glyph) are ever touched directly by the bytecode hinting (it appears the bytecode hinting in this font is trying to act only in the y direction). As a result, I suppose they should remain unchanged. Indeed, if I run ftgrid with ttgload:7 and hit 'H' to toggle the hinting engine between v35 and v40 I get the same output for the advances each time, however, these advances appear to be output before any processing.

So I added the diff in trace_pp2.diff (attached) to trace these values. Interestingly, in v40 it appears that the values are unchanged (and seem correct in funits) but in v35 the values are changed (and don't seem make sense in funits, seems to be in .6 pixels).

(file #47182)

bungeman <bungeman>
Tue 09 Jul 2019 04:17:55 PM UTC, original submission:  

If I take the font 'Oswald' [0] (which is a hinted variable font, available from Google Fonts) convert it to ttf (attached), open it in ftview (with current tip of tree FreeType) like

ftview 40 TK3iWkUHHAIjg752GT8G.ttf

and make sure ftview is in v40 mode it looks normal. If one then hits 'f' to force autohinting (or uses 'light AA' which also forces autohinting), then hit 'f' again to turn force autohinting off (or move away from 'light AA'), the advance widths of all the glyphs go bonkers. When in this odd state increasing or decreasing the size appears not to affect the advances until getting to size 200, which is a cutoff in the 'prep' table (at which point the advances seem fine). If I hit 'H' twice to first select the v35 autohinter and then go back to the v40 autohinter the advances go back to normal. Changing other settings (like the cache or hinting style) do not appear to affect this.

These same odd metrics can also be seen by loading this font into ftmulti or ftgrid which always seems to use the odd metrics even though these demos don't appear to ever force autohinting. Note that the component glyphs (like onehalf) seem to be unaffected even though they have instructions to position the components.

At first I thought this might be an issue with the font due to ftmulti and ftgrid always displaying this behavior (odd metrics), but the behavior in ftview makes it seem like this might be a state issue in the v40 interpreter when switching from forced autohinting back to the interpreter in relation to the phantom points (since the glyph outlines themselves seem fine in this odd state).

Related downstream issues with related information at [1], [2], [3]. This font was hinted with a modified version of the FreeType autohinter, but hinting with the unmodified autohinter seems to have the same behavior.

[0] https://fonts.gstatic.com/s/oswald/v23/TK3iWkUHHAIjg752GT8G.woff2
[1] https://github.com/google/fonts/issues/2051
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=981443
[3] https://github.com/googlefonts/OswaldFont/issues/16

bungeman <bungeman>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #47182:  trace_pp2.diff added by bungeman (761B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by bungeman (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-07-12 wl StatusNone Fixed
        Assigned toNone wl
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.2
    2019-07-10 bungeman Attached File- Added hvar_vvar_hinted_scale.diff, #47189
    2019-07-09 bungeman Attached File- Added trace_pp2.diff, #47182
    2019-07-09 bungeman Attached File- Added TK3iWkUHHAIjg752GT8G.ttf, #47176

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code