Locl and subs/sups/sinf features doesn't recognise glyphs with both .sups/.subs and .locl suffixes

Glyphs with suffixes such as .sups.loclXXX or .subs.loclXXX are not recognised by Glyphs and put in the appropriate features that have automatic generation turned on.

Glyphs with a .sups.loclXXX.hist suffixes are recognised by the hist feature however.

The “.sups.loclXXX” glyphs should show up in the “locl” feature. But that is applied very early, probably before the sups/subs features and thus will never be appleid. What are you trying to do?

The problem is that they don’t show up in locl for some reason. No .subs or .subs glyphs with an additional .locl suffix show up there.

Trying to get .loc variants of .subs and .sups glyphs recognised by the automatic feature code generation.

But why do you need those? Just trying to understand the context.

The problem is that when the locl feature is applied, the .subs alternates would not be there, yet. So it would not work anyway.

Could you explain what you mean here in more detail?

I use .subs and .sups glyphs mostly for components for the various superscript and subscript modifier letters. The cyrillic modifiers need acommpanying .locl variants just like the regular set of letters.

A set of .sups glyphs for superscript letters and .sups glyphs for subscript letters have also been implemented for the few use cases where where an additional level of modifier letters is needed, such as for depicting tertiary articulation in IPA.

As double superscripts or double subscripts have not been encoded, the best solution at present appears to be to implement .sups and .subs variants for these letters as a replacement.

mod-cy.sups and subscript.subs glyphs should also have .locl variants for the languages that need them. This is most important for cyrillic as most of the current and upcoming modifier repertoire needs localised variants.

That is one of the reasons that I posted this in the first place due to noticing that it didn’t work and figured out why.

After some more testing it seems that simply having them be added automatically to the local feature should let it work correctly.

.hist.locl glyphs does also not appear to show up in the locl feature.

Can you send me the .glyphs file. That would make testing this much easier.

I’ll see what I can do.

Would it be possible to add support for “dual” .locl glyphs?

As in glyphs with a name like glyph-cy.loclSRB_MKD that would be put in both the SRB and MKD segments of the locl feature, acting as a replacement for both of glyph-cy.loclMKD and glyph-cy.loclSRB.

It would let one cut down the number of extra glyphs in the file while still using automatic feature generation and be easily modifiable. It would mostly be used for glyphs that are identical for two or three languages.

That is already implemented. Just remove the underscoring from the suffix.

Thanks, that worked perfectly.

The order would either have to be .loclXXX.sups in the suffix, which would require a base .loclXXX glyph that the superscript feature can substitute. Or, you drag the locl feature after sups, but I do not know how current app or engine implementations handle locl at unusual positions. Will require testing in the targeted apps, YMMV.

If I drag features such as locl that have automatic feature generation turned on, the feature gets sent back to its default position. The only way to keep it there would seem to be to turn automatic feature generation off for that, and as you say, issues might occur in programs.

The only problem with that is that it would mess up the glyph order of the ones with that naming scheme.


If I would have to rename:




the default sorting of this set of glyphs would change into something not entirely ordered.

Would it at least be possible to change the automatic sort name feature, so that they’ll still appear in the order that is shown above even under the new names?

.hist.locl glyphs still needs to be automatically added to the hist feature, as they are currently not.

But that new naming scheme would be a better fit for how OpenType works.

That I agree with, and I will likely change them all later to using that naming model. What I still want to know is if it would be possible to make them by default sort as if he .subs/.sups suffix wasn’t part of their names.

If this was done, plain letters would be sorted first, then .hist, then .locl and lastly .locl.hist. (If .locl.hist is preferred over .hist.locl)

Edit: It might be best to simply leave it as it is.