Bracket layer composition issue

[yanone]

I managed to generate the font after yesterday's issue about the 63 character limit for glyph names in OT code. I'm going to clean up with all the issues after I managed to generate a comletely functioning font. So far, issues are piling up.

Here are two more:

• When glyphs get substituted by bracket layers, the bracket layer of their unshaped encoded base glyph gets inserted and breaks the composition. I really have no idea where to even start looking because I lack the knowledge.
• The dot of the left-most glyph (noon) shifts despite no such evidence in the source. This glyph isn't even getting substituted, so it's most likely a separate issue.

The purpose of the substitution: The font contains substitutions for all the Arabic dots. When the weight becomes too heavy, a redrawn dot component is used that has inktraps for the otherwise overlapping dots. This may seem an expensive design decision given how many glyphs it affects, but it's a legitimate use case nonetheless.

In the two screenshots below you see two versions of the font each, on the top an older version before the expansion of bracket layers into composite glyphs that is causing so much trouble lately. And below the new font that I generated yesterday with all the bracket layers.

The first image shows a normal weight without the bracket layers coming into effect, so both versions render identically. The lower shows a heavy weight where it does change. The lowest line shows the two described anomalies.

I've confirmed that the designspace file contains the correct substitution:

      <sub name="yeh-ar.medi.conn-m-1" with="yeh-ar.medi.conn-m-1.BRACKET.130"/>

The font is proprietary and available on request. I should mention that we have internally discussed that Simon is preparing a Noto release using G3 sources and is therefore interested in having seamless VF generation work. I will notify him of it to have a look.

[simoncozens]

I think the main problem (with yeh) is about where the variation substitutions happen in the shaping process.

Quick refresher: In Arabic shaping, there are a bunch of early features processed (like rtla/rtlm/frac), then the topographical shaping features (init/medi/fina), then the presentation features (rlig etc.), then positioning. When OpenType Variations were specified, "feature variations" could be applied to any feature at different places in the design space. However, Microsoft being Microsoft, they expected that these feature variations would happen in the rvrn feature, which they specified

should be processed early in GSUB processing, before application of the localized forms feature or features related to shaping of complex scripts or discretionary typographic effects.

Stare at that sentence a bit and you'll see Problem 1, and why your font doesn't work.

Most people now agree this was a mistake.

Problem 2 is that until recently there was no way to express feature variations in AFDKO syntax. And we needed to make variable fonts. So instead of coming up with a nice user-addressable way to make these things which could apply to any feature as originally designed, the UFO/Designspace people quickly added a <rule> element which creates a feature variation in the rvrn feature.

Now a mitigating feature here is that if you add processing="last" to your rule, the substitution gets put into the rclt feature instead which is processed last in the shaping path.

Problem 3 is that there is no way to tell Glyphs whether your bracket layer should be processed last or first, and so there's no way for us to write the designspace with the right value. Just has said:

Had designspace + varlib been new at that time I would have suggested to default to the "last" behavior, or even to have that be the only behavior.

So maybe we should set rulesProcessingLast=True when creating Designspace rules from Glyphs. (@anthrotype, thoughts?) That would fix your problem, but I don't know how much it would mess up other fonts.

Problem 4 is that Adobe applications doesn't support feature variations in the rclt feature, because of course.

[yanone]

Most people now agree this was a mistake.

Can it be done, per font, to move the rvrn feature backwards despite the specs?

[anthrotype]

maybe we should set rulesProcessingLast=True when creating Designspace rules from Glyphs

What does Glyphs.app use for bracket glyphs when generating a VF, "rvrn" or "rctl"?

Maybe we could coordinate with @schriftgestalt to define a new custom parameter that controls that (or maybe there is one and we don't know?) and have glyphsLib read and apply it accordingly.

I'd be wary of changing the default setting for all glyphs-based projects, there may be projects out there that use this feature and may result in unforeseen breakages.

[simoncozens]

Maybe we could coordinate with @schriftgestalt to define a new custom parameter that controls that (or maybe there is one and we don't know?) and have glyphsLib read and apply it accordingly.

Yeah, this is the right approach.

[khaledhosny]

custom parameter that controls that (or maybe there is one and we don't know?)

There is Feature for Feature Variations already.

[simoncozens]

Aha! Right, I'll fix this.

[anthrotype]

Thanks @khaledhosny for reminding us, I did remember seeing it once

[simoncozens]

Since Adobe apps don't process rclt, maybe Yan can set Feature for Feature Variations to medi. 🤪

(Don't actually do this.)

[yanone]

There is Feature for Feature Variations already.

Aha! Right, I'll fix this.

So this isn't currently supported in the toolchain, or shall I give it a try? And if so, which would be the targeted feature then?

[simoncozens]

This isn't supported in the toolchain, and even though fontTools allows us to put it into any feature, we have to go through Designspace, and Designspace only gives us the choice of rvrn or rclt. (Thanks, Designspace! We could have had the option to put feature="..." onto each rule, but instead we just have a first/last setting on the overall rules element.)

[anthrotype]

what you can do right now (and it's worth confirming that it actually fixes your problem) is to dump the font to ttx, rename "rvrn" -> "rclt" or whichever feature tag you like and recompile

[yanone]

That worked (a little bit)!

(Earlier I tried to generate the font from the UFOs where I've added the processing="last", which didn't work and still produced a rvrn feature and no rclt.

It works in FontGoggles and browsers, but not in Adobe apps, as mentioned (except Photoshop, which apparently does use HB already, as Simon pointed out). So I could keep the feature and wait till Adobe apps support variations in rclt/use HB, or I could choose to remove my dot feature so that the font appears consistently in all environments.

Some glyphs still get substituted wrong. In the below screenshot you see that the yeh should be a swash (lower line). But I'm growing tired of the many problems this approach introduces. There are metrics issues that I don't understand (lower line, the swashy jeem looks too far into the zain and creates what looks like a rendering mistake (to the uneducated eye). The dot components are off (see zain’s dot). asoasf.

I might just go with letting go of the dot variations.

[schriftgestalt]

Glyphs defaults to rlig, and puts the lookups at the end. I tried rclt but rlig worked a bit better in some Adobe apps.