Hi. I have noticed, that typing in El-cy.loclBGR field the value =A-cy, Glyphs 3.2 (3227) interprets the sufix -cy as -10.
Another error.
En-cy in another master had a shift of +10 pt to one side, the width remained the same. En-cy is a component from H. After using Disable Automatic Alignment and Enable Automatic Alignment, the error disappeared.
Why a metrics key when you align the components? They are mutually exclusive.
(Except for incremental keys like =+20 for adjusting automatic component alignment.)
The second problem is not with metrics kesys, only the first one. I didn’t want to create a separate thread for odd error that was there, disappeared and I couldn’t replicate it.
El-cy.locl isn’t a component. It has a similar shape to A and A-cy that’s why I used the value of A-cy. I know that A and A-cy have the same shapes and A-cy is formed from A and it’s probably overkill for most people but I prefer to type the values from Cyrillic and have them separate from Latin.
Why are you typing =A-cy? Just type A-cy.
Why?
Ok. But I want to subtract some value as well. And it’s a bit silly if someone doesn’t have Latin and only has Cyrillic. So it’s probably worth solving it.
Because I prefer to treat Latin and Cyrillic separately when it is possible.
Yes, you made that clear. But why? Do you not have A-cy as a component from A?
I noticed a bug, I described it because it may appear elsewhere and in other scripts — that’s the main reason, it seemed worth noting. And if it doesn’t work then - eee, ok.
It is also a part of my workflow which allows me to pick up the names and spacing of the other characters. I try to do this as consequently as it is possible. On the same principle, I try to use siedberings values, which is why I raised the other issue in a previous post. And it doesn’t have to be efficient for you, it has to be efficient for me and how I associate and learn things.
Of course. Everybody is entitled to their own workflow. However, that doesn’t necessarily mean they make sense and couldn’t be open to improvement in some parts. That’s why I was curious to know your reasoning.
The bug still exists, naturally, nobody’s doubting that 
The metrics key calculation works for me. Can you send me your file that I can have a look?
I send the file, but the bug is gone — I don’t know if it’s from restarting Glyphs or other things. I don’t know if it can be replicated now.
I hear about such a practice but haven’t tested it yet.
Is it just a logic separation, or a different metrics as well? The different metrics also mean different Kerning Groups for Latin and Cyrillic. And in this case, I wonder how it affects an amount of kerning pairs.
Sorry for the offtopic.
It doesn’t work for me, 3227.
For example, I set the RSB to =de-cy. The result is always 0. Same if I write =de-cy-10, the result is 0.
Indeed, works fine now (including combination with maths operators). Sorry for the confusion.
In theory, to get the same spacing visually Cyrillic might need a bit looser spacing due to its “small caps” structure. In practice however, as far as I know even experienced native type designers just reuse Latin metrics and it’s pretty common to add tracking among good type users. Seems like a bad habit/compromise in the industry.
1 Like
I use Latin metric for the same characters in Cyrillic. I don’t seperate them. I simply write metric keys from the Cyrillic to the other Cyrillic characters if they have similar shapes. En-cy has an H value. However, since as a non-native speaker I want to remember the characters,their relationships and not forget them I continue to type for ex. in Sha-cy =En-cy instead =H.
@langosz_d I got it.
En-cy = H metrics.
Sha-cy = En-cy metrics.
For the application however it may looks like a double reference.
Sha-cy = En-cy = H.
I don’t know if it may be a problem.
1 Like