I inserted some debug printfs into the locations Alexei pointed out
and indeed the only difference after a-/descender calculations are
done was that ascender values differ, 983 fU for the static, 739 fU
for the instances. Height stays 1200 fU like in my calculation, bbox
yMin/yMax stay the same.
Looking at the code, this is an unfortunate corner case it seems.
`sfnt_load_face` by default assigns the hhea metrics to ascender,
descender and height and only if they are zero does it look at typo
and then win. When applying MVAR, it blindly assigns whatever ends up
in the typo metrics, and if zero, in the win metrics. The default
outline and the instances therefore have different decisions made
about their metrics.
> I would say if that bit is off then the respective MVAR tags should be
> applied to hhea values.
Cantarell doesn't have a typo/win delta in the MVAR :/
The attached diff solves the issue for me by simply not varying ascent
and descent unless USE_TYPO_METRICS is set, but I'm not sure this has
unintended consequences like never looking at modified win metrics?
diff --git a/src/truetype/ttgxvar.c b/src/truetype/ttgxvar.c
index 8fda112b0..e51dd4a4a 100644
--- a/src/truetype/ttgxvar.c
+++ b/src/truetype/ttgxvar.c
@@ -1366,8 +1366,12 @@
{
FT_Face root = &face->root;
-
- if ( face->os2.version != 0xFFFFU )
+ /* Special case for varying ascender, descender and height: Only modify if
+ * OS/2 fsSelection's USE_TYPO_METRICS is set. sfnt_load_face uses the hhea
+ * metics by default, this code would otherwise blindly overwrite those
+ * metrics with typo or win metrics, leading to a difference in metrics for
+ * default outlines and all instances. */
+ if ( face->os2.version != 0xFFFFU && face->os2.fsSelection & 128 )
{
if ( face->os2.sTypoAscender || face->os2.sTypoDescender )
{
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
