So, to summarize, the new behavior is sTypo (if UseTypoMetrics), then hhea (if not 0), then sTypo (if not 0), then usWin. This is now consistent across all fonts; variable fonts do not have a different fallback order. Variable fonts will apply the MVAR deltas to whichever metrics were picked.
This explains the behavior change seen when rolling this into Chromium ( https://chromium-review.googlesource.com/c/chromium/src/+/1452712 ) and the change to the cff2 font ( https://test-results.appspot.com/data/layout_results/linux-blink-rel/6261/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html ). This is AdobeVFPrototype.otf (checked into blink's test resources) and it does not set the UseTypoMetrics bit, so we're using the FreeType computed metrics. The MVAR for this font only has 'stro' and 'xhgt', so no variable adjustments. What has changed is that FreeType now provides the hhea metrics instead of the sTypo metrics since UseTypoMetrics isn't set. Overall I like this change, this behavior is easier to reason about. This particular font didn't ask nicely to use the sTypo metrics, and it's probably a good thing to keep it that way to keep testing this case. Le lun. 4 févr. 2019 à 01:46, Werner LEMBERG <w...@gnu.org> a écrit : > > Done, pushed and fingers crossed. > > Thanks! > > > Werner >
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
