Explaining the render differences

[vv-monsalve]

Could the tool provide information about differences in rendering? When using it and observing differences between renderers, it's not always clear whether there's a font bug, a rendering issue, or an issue with the tool itself.

E.g. Something like "Alpha values are not supported in x renderer"

Example 1. COLRv1 font

Using a still WIP new font colored using PaintCompiler. In this case the expected result is the first one (which uses alpha values)—wondering if samsa-svg does not support it (isn't it using samsa-core?).

---

Example 2. Standard VF

When checking a VF with a YEXT axis that shifts the vertical metrics, system looks like shifting the baseline position.

Playpen-YEXT-axis.mov

[Lorp]

More information about each renderer is definitely needed. On the examples:

1. Alpha values should be working ok, so this needs investigtating (probably in samsa-core)
2. I believe the system renderer is behaving correctly. The font seems to be adjusting its own sTypoAscender and sTypoDescender values (using MVAR). In a user agent (e.g. a modern browser) this necessitates lowering the baseline so that the top of the text box remains aligned with sTypoAscender. Getting vertical metrics right is fiddly — it’s not always clear what the best solution is. My current focus is visual comparisons of the rendering itself, rather than its vertical position, so a fix (or controls to determine behaviour) will not be imminent. BTW I’d be interested to see how InDesign handles adjustments to YEXT.

[vv-monsalve]

2. BTW I’d be interested to see how InDesign handles adjustments to YEXT.

I've just found it doesn't >.<.

[Lorp]

Did you try a multiline sample in InDesign? Deciding how to handle the first line of a text box is a kinda separate from handling subsequent lines.

[vv-monsalve]

I've now tried both: single line + multiline. The YEXT axis does change the ascenders, descenders, and cap height but does not modify the line's leading or position. Not even when changing the first line offset in the baseline options (from Ascent, Leading, Fixed, etc).

[Lorp]

I believe it’s correct for InDesign to behave this way (thus differently from a browser default settings). Pro users are happy to handle vertical metrics manually, via point size and leading controls. For example, the browser would modify its first-line baseline position and maybe also the line-height if a single glyph is from a font with a larger sTypoAscender, than the rest of the text; but that would be unwanted in InDesign.

[vv-monsalve]

Pro users are happy to handle vertical metrics manually, via point size and leading controls.

Makes sense. On Friday, I was frustrated when I saw it was not working there, but this is probably the main reason. However, I wonder if there should be an option to enable the font's metrics. Similar to what they allow regarding kerning

[Lorp]

I think you’re right.