Bad XTRA calibration?

[Lorp]

I don’t understand the values for XTRA in the font. In practice it generates narrower instances than expected when compared with Amstelvar. I’m assuming we still use the gap between stems in H, in normalized 1000 upem font units.

Here are comparisons in ParaSync and Axis-Praxis, with XTRA set to 500. Note that the H gap is significantly wider in Amstelvar than in RobotoFlex.

I measured the H glyph in RobotoAvar2-wght400.ufo:

So from this, we get measurements of 734 for XTRA, 192 for XOPQ, normalized as per the table. The last two columns in the table should be equal for each row, but for XTRA they are significantly different. XTRA being larger than expected in the designspace accounts for the H and the rest of the font appearing too narrow when compared with other parametric fonts.

axis	measured	normalized 2048	normalized 2000	designspace
XTRA	734	358.40	367	463
XOPQ	192	93.75	96	96

(Note: If we look at axes other than XTRA in the designspace, they assume upem 2000 although the true upem is 2048, so there is an additional ~2% anomaly that is not the subject of this issue.)

[dberlow]

XTRA has been the addition of counter and stem of H since the beginning. It should be that value in Roboto and Amstelvar.

[Lorp]

That’s not supported by:

https://variationsguide.typenetwork.com/#xtra

https://fonts.google.com/knowledge/glossary/xtra_axis

[davelab6]

[dberlow]

I know what was done over my work. Six years later, Dave informed me of the name change to counters. I disagreed and quit dealing with this documentation and images then.

At this point, it's best to declare Amstelvar a custom implementation of XTRA that uses a more reliable value for width adjustments because, as was discussed from the very first parametric roundup, it was the measure of the STEM and COUNTER of H,m n and 0. If it's not it should be and so should Roboto.

It was an instinctive thing then and it still is that when this sample glyph gets projected to individual glyphs of its group, the range and disproportionate changes are better programmed as originaly defined.

[davelab6]

I chatted with @dberlow and he said, "XTRA for a full glyph set from 1 glyph is too singular and simple a sample, and its worst to select just one glyph, as opposed to add a feature that lots of glyphs also have; so that's how I recommend to define it, and how it is being used. That works in the typo wiki demo that way. XTRA has now been broken into parts, which raises a big question - after you renamed it as "Parametric Counter Width" axis, I told you that it was more than that. But we can make it whatever you want, as long as it is consistent. But parama-roundup always took measurements from left side of left stem, to left side of right stem; uppercase H, lowercase n, and figure zero." We get those values so that, if there's a huge different in like an oldstyle serif, they can be broken out. Figures are usually broken out into their own axis, for e.g. tabular figures. If not split, the H measurement is used. Many glyphs have 2 stems, some 1.5 (c), some 3 (m). It isn't about number of strokes though, and this is different to UC/lc. We have a term 'forming' for making a blend. YTRA has always been a thing that is an additive thing, you have a limitation on the height of the Em, the YTRA must add up to the Em in max. So the broken down YTRA axes like ascenders, descenders, are some fraction of that, and work independently (unless you bind them together). But they are all part of the Em space, and it is a finite space. But XTRA is infinite, and MANY axes blend with XTRA, or are blended. Can we blend an axis, and then use that axis to blend a 2nd? [I believe so, with avar2; if not, varc definitely does allow that.] So pure counter XTRA is too dominating and not useful for justification, it is XTRA + XOPQ together that is useful."

[Lorp]

Let’s call these the A-spec (as published) and the B-spec (as @dberlow explains). If A-spec fonts must be adapted to B-spec, let’s think through the implications:

• All masters need their XTRA values recalibrated — this is quick.
• All masters with non-default XOPQ need their multi-stem glyphs redesigned (in A-spec fonts, XOPQ shifts all stems but the first) — this is not so quick.

[dberlow]

[LP]
All masters need their XTRA values recalibrated — this is quick.[DB]
...we are doing this.

[LP]
All masters with non-default XOPQ need their multi-stem glyphs redesigned (in A-spec fonts, XOPQ shifts all stems but the first) — this is not so quick.

[DB]
Please? What is a "non-default" XOPQ? What do "multi-stem glyphs" have to do with anything? 'Is there an "A-spec" and B-spec? What's an "XOPQ shift" of a stem?