I understand that it’s tricky because some Cyrillic characters may doesn’t need a local forms in small caps, but some Latin characters (like Polish with acutes) should retain their local forms in small caps. As I understand it, I have to additionally review these localized characters, and manually generate only those small caps that should retain the local forms. Is it correct?
2. Generate automatic features question
For example (for test), I generate only small caps glyphs that proposed in sidebar menu, that is, without local forms. Based on the fact that the locl feature is applied earlier than smcp/c2sc, so smcp/c2sc should redirect the local forms to base small caps.
script latn;
language PLK;
lookup locl_latn_2 {
sub Cacute by Cacute.loclPLK;
sub cacute by cacute.loclPLK;
...
} locl_latn_2;
The smcp feature (generate automatically) redirects the lowercase local forms to base small caps, as expected.
sub cacute by cacute.sc;
sub cacute.loclPLK by cacute.sc;
But the c2sc feature (generate automatically) does not redirect the uppercase local forms to base small caps, for some reason.
sub Cacute by cacute.sc;
So when applying Capitals to Small Caps, the uppercase characters like Ć remain uppercase in Polish (and respectively for all the other languages that have characters with localized forms).
It’s similar, yes, but maybe the order of features is different. I am considering the locl feature is executed earlier, and the c2sc is executed later. Here’s what I expect:
If a.locl.sc is presented, then A.locl and a.locl should be substituted with a.locl.sc.
If a.locl.sc is not presented, then A.locl and a.locl should be substituted with a.sc.
Sometimes one or both of these cases don’t work as expected in automatic features, especially in c2sc. Please also check my next comment below.
Then I updated the smcp and c2sc automatic features and notice that almost all the localized forms are successfully substituted by their localized small caps versions, as expected, except of the first two (fhook.sc and dcedilla.alt.sc).
Both versions of these glyphs are presented in the font, and even the florin (which is supposed to be lowercase version of fhook) is presented too.
The convention that glyphs follows for .sc is that it uses the lowercase name, which in this case is florin.sc. This is a special case for historical reasons. You can override the name of florin in GlyphData. In a future version, we are considering updating the naming by default.
Works as expected for me. c2sc has sub Dcedilla.alt by dcedilla.alt.sc; autogenerated.
The problem was in GlyphData.xml file. Previously I used only required attributes: name and category. So I added case and script attributes, and now autogenerated features works as expected. So these optional attributes actually needed. Didn’t know that.
I understand the root of that naming issue. However, practically, the small caps version of Fhook (based on uppercase F) may be visually/stylistically differ from small caps version of florin (based on lowercase f). Perhaps, even the shape’s width may be different in different designs (like the letter is wider and currency is narrower). So I have some doubts that uppercase Fhook should be substituted with florin.sc. It would be nice if someone of the experienced developers could confirm this suggestion. I’m talking about the case when the font contains both fhook.sc (for uppercase sub) and florin.sc (for currency sub).
Rainer, what if I made two versions of c2sc feature – one is automatically generated and doesn’t include fhook.sc, and another one is manual and included only this sub:
sub Fhook by fhook.sc;
Will the exported font contain the unified c2sc feature? I read about it somewhere here, and I would be happy if you could confirm that it will works.
florinis an f with a hook. If you have true Fhook in UC and LC, ignore a specific currency shape for the lowercase, and just use the LC shape in a glyph called florin (unless you adjusted your GlyphData of course). Do not add florin as a stylistic alternate of fhook or something like that. Not worth it.
Unfortunately, there’s no such thing, since Unicode has decided there is no difference between a lowercase f-with-hook and a florin sign. A gross miscalculation, if you ask me, but there it is: they are officially the same symbol and cannot be told apart.
If you’re writing a text about historical European currencies in Ewe, the regular ƒ (representing /φ/) should not be slanted as though italic, and in small caps it should look like a downsized Ƒ; whereas the currency symbol ƒ should be slanted as though italic, and as a currency symbol is unicase and should not change its shape when using small caps. But this is not currently possible to achieve, except through stylistic alternates applied to the currency symbol.
After that, autogenerated c2sc feature correctly substitute uppercase Fhook with fhook.sc.
Yes, and it’s strange, because visually they have to distinguish. It turns out that Unicode put the responsibility on a type designers.
I haven’t come to a specific conclusion yet (because different people say different things) but I’ll probably use three different glyphs – Fhook, fhook (or florin.loclEWE), and florin. Maybe not for every design, but for the text fonts. This also requires the substitution of florin by fhook (or florin.loclEWE) in locl feature for EWE language.
About 80 custom entries. I added those that Glyphs don’t have recipes (?) to generate composites for them. So the main reason is decompose attribute. Like:
I think it’s the case attribute (lower, upper). After I added it, the automatic features like c2sc started to see and substitute the glyphs like Fhook and some others.
I don’t know the reason, but I just moved my custom GlyphData away from Info folder, restarted Glyphs, regenerated the automatic c2sc feature, and after that the line sub Fhook by fhook.sc disappeared.
Edit. The font have fhook.sc but doesn’t have florin.sc yet. Maybe this is the reason.
Perhaps the reason is that the default decomposition used brevecomb-cy instead of brevecomb. So if the font doesn’t have the brevecomb-cy, then the generation from components will not work for such glyphs.
I understand the reason of Cyrillic breve version, but it’s not always the case (up to design). So maybe Latin brevecomb could be the fallback if Cyrillic breve isn’t presented?
Maybe I added them in the meantime.