I’m working on a typeface that has .case glyphs for diacritics and .case glyphs for a few case-sensitive capital letters, and I’m getting some strange behaviour from the Make Component Glyph command.
For example, let’s say my font contains:
/E /E.case /acutecomb /acutecomb.case
And I want to build the two corresponding component glyphs:
/Eacute and /Eacute.case
My expected result after adding those glyphs and using the Make Component Glyph command would be:
/Eacute = /E + /acutecomb.case
/Eacute.case = /E.case + /acutecomb.case
But instead, I get:
/Eacute = /E.case + /acutecomb.case
/Eacute.case = /E.case + /acutecomb.case
That doesn’t make sense to me. Is this a bug, or is there another more common scenario I’m not imagining where this would be the expected behaviour?
When building components for uppercase glyphs, the algorithm is locking for ‘.case’ alternates for for each part. And you are fine with this behavior for the marks but not for the base?
It is indeed possible to have alternates for all caps settings but I have never seen that.
I don’t think it makes sense for the algorithm to use .case alternates for the base of all uppercase glyphs. It should only do that for alternate uppercase glyphs that have a .case suffix, right? The marks should always be .case glyphs if available, though.
To explain my scenario, it’s an art-deco style typeface, with elevated crossbars on /E, /F, /G, /H, /K, but I’ve decided to make .case glyphs for these, and I’ve lowered the crossbars to match the x-height on the default glyphs. So the elevated crossbars are activated in all-caps settings only, like this:
The workaround of fixing them manually isn’t an issue of course since it’s only a few letters. I’d imagine it isn’t common to have case-sensitive alternates for uppercase letters, so maybe this is a bit of an edge case, but a fix for this would still be a better algorithm in general, I think.
That sounds like a potential workaround to get the Make Component Glyph command function correctly, but I’d be trading a small problem for a bigger one.
Using the .case suffix on the alternate capital glyphs is preferable because Glyphs generates the case feature codes automatically. With the .alt suffix, I’d have to manually write the feature codes.
I’m not sure case is the appropriate feature anyway. The use cases are not particularly well defined by OpenType end even if they are most font vendors interpret them loosely.
You could declare the raised crossbar to be a stylistic set, for example ss01. Then you glyphs end in .ss01 for the automatic feature code generation.
Idea for @GeorgSeifert: If a feature does not contain any lookups (as is the case with auto-generated ss## features) the lookup for the feature is generated implicitly. So
feature ss01 {
sub A by A.ss01;
} ss01;
expands to
feature ss01 {
lookup ss01_internal {
sub A by A.ss01;
}
} ss01;
This internal expansion could be exposed such that the Glyphs feature compiler performs the above expansion before compiling the code with a well defined lookup naming scheme. FEATURE_internal, like above, or FEATURE__lookup or something similar.
Then, @justinpenner could use Glyphs’s automatic ss01 feature code generation and also reference the ss01 feature from case by looking up the ss01 internal lookup in the case code:
That is too much automatic fixing even for me.
Adding explicit names lookups changes the behavior of the code. E.g It only can contain one lookup type.
If I change something than I would make the lookup explicit.
Ah, I did not know about this difference. Perhaps such a lookup would only be added to automatically generated features like ss##, cv## and not complex auto-features (like locl) or manual features since there I could refactor the code myself to be lookupable from other features. But than what features get this special treatment and is that future proof?
I see that is more complex than I initially thought it was.
The .case glyphs I’ve designed for the capital letters are meant to be a better glyph in an all-caps context, not an alternate glyph, so I believe case is the correct feature. It’s precisely the same use case as case-sensitive punctuation, and it conveniently ties it the all-caps button in the user’s application. I will most likely include a stylistic set as well, though.
The case feature is primarily meant for punctuation, or non-letters in general.
The better and more compatible solution is calt with an ignore statement:
ignore @caps' @Lowercase;
sub @caps' by @allCaps;
The Lowercase class can be automated. Put your .case Glyphs in the allCaps class, and their unsuffixed counterparts in the same order in the caps class.
