I don’t know about that parameter. I’m using renameGlyphs and replaceFeature.
Well, adding a (pointless) /q.medium and /q.long actually got rid of the error message…
So you meant that you created the glyphs in feature code?
Not sure what you mean. I created the glyphs, period. I didn’t change the feature codes.
I was wrong about that after all; the unlinking still doesn’t work. Here’s how my Cormorant Unicase turns out in Cyrillic. Unicase replaces the /t.sc by /t.sc.ss05. Since /te-cy.sc contains a link to /t.sc, it also gets turned into /t.sc.ss05, which is not appropriate. This really shouldn’t happen.
(Alright, this actually looks somewhat sexy, but probably confusing to Cyrillic readers… in general, though, replacing a character by another should not have undocumented and unpredictable ramifications for other glyphs.)
Replacing depending components is not unintended and unpredictable. Accented letters depend on it. I need to think about this.
I think we’ve discussed this before… if you have an /a.ss01, you’ll want to create an /aacute.ss01 as well that contains the /a.ss01 as a component. If you just replace the /a by /a.ss01 and propagate that to the existing /aacute upon export, the position of the acute, the metrics, and possibly the kerning classes will no longer be correct. That’s not a workflow Glyphs should encourage. Of course, you’ll also want to be able to access the feature via SS01 in the original font, which wouldn’t be possible that way.
Please implement unlinking before glyph replacements; its current omission is a dangerous bug, not a feature. Here’s an example of the bloody mess that it creates:
That problem can be solved by the “Decompose Glyphs” parameter that is new in 2.3.1 (905).
When will that be released?
I just uploaded it. It is not 905 but 904
BTW, what’s the proper value for Decompose Glyphs? True? Shouldn’t that be the default value when the feature is created?
EDIT: The value «True» doesn’t seem to do the trick. No error message, though.
A list of glyph names.
Oh, OK, that works.
What I still find strange, though, is that when I replace /a with /a.sc, the original shape of /a gets stored in /a.sc instead. Also, although I use a Remove Feature custom parameter for smcp when I export my SC fonts, the feature still persists in the exported fonts, which then proceeds to replace the smallcaps glyphs with lowercase glyphs! Very unexpected indeed!
EDIT: OK, so I made a mistake in the custom parameter… I removed the feature «sc» rather than «smcp». Still, it’s weird that Replace Glyphs apparently swaps rather than replaces glyphs.
That was a frequent feature request, and is now implemented in 2.3.1. You can disable the other glyph with the Remove Glyphs parameter.
I notice I’m still getting these glyph replacement glitches despite my use of the Decompose Glyphs custom parameter. For instance, I replace /y with /y.ss01 (infant /y) and then feed /y to the Decompose Glyphs parameter, but that doesn’t catch the fact that /u-cy is linked to /y. So in the exported font, /u-cy is going to look like /y.ss01 but retain the advance width, anchors, and kerning behavior of the original /u-cy. Bad idea!
I guess I should have my scripts generate a list of all glyphs and feed that to Decompose Glyphs, just to be sure I don’t miss anything. Is there a downside to unlinking all glyphs prior to export?
No downside, CFF fonts must be decomposed eventually anyway. TTFs can have components and save some file size this way, but if you decompose wisely, that should be fine too. You should be able to use LayerGeek as a Prefilter for that purpose.
You don’t decompose the ‘y’ but the ‘u-cy’.
The problem is figuring out what glyphs need replacing. When I make an alt for /y, I don’t necessarily think about its ramifications for /u-cy; that’s how these mistakes happen.
I’ve taken to feeding the Decompose Glyphs custom parameter the full glyph list, though, so that should be moot from now on.