[varLib.featureVars] lookups for 'rvrn' should probably be inserted at the beginning

It turns out Apple messed up the implementation of rvrn: despite the spec saying it should be processed early, it follows the lookup order.

https://twitter.com/justvanrossum/status/1345364798423363584

So fonts built with designspace rules saying <rules processing="first"> (which use the rvrn feature), behave like <rules processing="last"> on macOS (at least on 10.15).

We should probably work around that by inserting the rvrn lookups before all other lookups.

[arrowtype]

there’s nothing I can do about the previous behavior for users that don’t update

@nedley Thanks for your input! I’m not sure if this was directed at me, but I am still primarily using Catalina. Just to clarify, though, I’ve tested this on the latest version of macOS (v 11.2, released Feb 1, 2021) and Safari on iOS 14.4.2 (v14.4.2, released March 26, 2021), and I have confirmed that if the rvrn lookups are ordered later than the stylistic set lookups, the rvrn substitutions don’t occur before stylistic set substitutions. Unless, are you saying that the behavior has been fixed in more-recent versions of Mac or iOS? (Also, am I mistaken in thinking that iOS Safari uses CoreText? I’m genuinely unsure about whether that is the case, or whether WebKit uses its own text layout engine.)

Here’s a screenshot of TextEdit, showing the problem. ss20 should mean that the I g l glyphs get subbed for .text versions at smaller opsz values, as they do in HarfBuzz (e.g. in FontGoggles, screenshot below).

(Also checked at actual sizes < 24)

The same font works as expected in FontGoggles:

If the lookups are reordered (e.g. by the process shown in my video, above), things do start to work as intended. For comparison, you can see these two deployments of a non-working vs working version of these rvrn-dependent stylistic sets. How to use: open the “Options” sidebar, then add ss20, and then move the opsz slider up and down. In the latter test, you will see glyphs I g l swapping at opsz 24.

• Not working in Safari (rvrn lookups last): https://606230b58eb4c800085056f1--namesans.netlify.app
• Working in Safari: (rvrn lookups first): https://606a6ca7824a0300099bc459--namesans.netlify.app

If it’s helpful to have these for local testing, you can find them in browser Dev Tools > Network file view of the respective web pages.

---

Update: I’ve tested this in the latest macOS general release, 11.2.3, and the issue persists.

[nedley]

CoreText has always applied rvrn early (along with other mandatory features) but not super-early; this has been fixed but there’s nothing I can do about the previous behavior for users that don’t update.