I was reading the handbook and noticed (just now) that I could use glyphs that start with double underscore to add RSB to their component glyphs. I tried that with Greek tonos but it didn’t work. Could anybody explain why this trick is only supported in RSB and suggest a good latest strategy on how to do Greek capital diacritics?
I also notice that double-underscore components simply add their width to that of component glyphs, although I expected that the overlap would automatically be subtracted (e.g. in letters like Zhedescender-cy, RSB is added too much). Is this an intended behaviour?
Yes.
Okay, in that case I guess the user is supposed to handle position and sidebearing adjustments via kerning instead of anchors. Is that correct?
Not necessarily. I do it with anchors. But I hardly use it anymore, I have to admit.
Double-underscore glyphs do not align automatically, which means I have to position them with anchors. I now see in the handbook that it simply adds width (therefore the said behaviour is intentional), but I do not find it useful in any situation. Again, the space it adds to the compound glyph is way too much (because it adds the whole width), and it doesn’t support LSB adjustment.
Think about the case of dcaron and tcaron: because of its position to respective letter glyphs, you don’t want to add the whole width of half caron in both cases. Even in intended scenarios I don’t think it’s solving anything.
1 Like
Why would that be too much? The point is that you can determine the width that is being added precisely by changing the width of the double underscore glyph.
Because you don’t want to add the same amount of space to dcaron and tcaron, for example (or to Alphatonos and Upsilontonos, assuming it supports LSB too). Adjusting the additional space from the component’s width is a flawed idea in my opinion.
The idea is to maintain automatic alignment, not necessarily to reuse the same component. You would not use the same double underscore component in dcaron and tcaron, but likely dcaron and lcaron. But in these cases, the question is if disabling auto alignment is not the better idea anyway.
For the greek uppercase tonos glyphs you can use a normal tonos.case. Just kern it with the Alpha and Omega instead of positioning it with anchors.
True, I am still using tonos.case for that.
I think what double-underscore components should do is to allow for kern-positioning like in tonos.case. That works better for all cases including caron and Cyrillic tooth, and I don’t understand the benefit of double underscore components. Exactly in which case is it useful?
The problem with kernable caron and tooth is that, as for now, I have to make a special glyph in GlyphsData that behaves as if they’re letters (and that I will have to share the xml along with the font). Also tonos.case behaves differently from other diacritics, and I think you made a special case for it. My suggestion is that all double-underscore components should behave like what tonos.case does now (make a category of letter-like, kernable glyphs that users can improvise) and drop special behaviour of tonos.case in favour of using __tonos or __tonos.case. I think that’s the best way to handle Polytonic Greek capitals without making all of them special on your side.
You don’t need to define the custom glyphs any more. You can manually set it from the font view (Info for selection, cmd+opt+i). and you could use a name+suffix that would be a Letter. And I changed the auto align code to be more useful in this cases for unknown glyphs.
The difference between the tonos.case and a __hoock-cy is that the former is treated like a letter and kerning and spacing is applied. The latter is positioned by anchors and in this cases the width of the would be ignored if it hadn’t the underscores. You could position the hook with kerning but that makes it difficult to control the sidebearing.
In the case of hook-cy, it’s better to apply the same RSB than adding the same width (same goes for dcaron/lcaron and tcaron). The tonos.case works fine and so does the GlyphsData override, but the cases where I need to make exceptions are always the same (caron.alt, tonos, Polytonic diacritics, hook-cy, tooth-cy, etc), and the feature that is supposedly used for this problem isn’t helping anything in my opinion, which is why I suggest the change.
While I really like the idea of double-underscore components, I find their implementation very limiting. For instance, I often run into the case where I would want a component to influence the composed glyph’s left sidebearing (e.g. for Đ, Ғ) rather than the right — or in the case of ł, perhaps even both. Also, I find a component such as the cyrillic descender whose path might be 200 units wide but whose advance width is only 20 units rather uncomfortable to handle in the edit window.
Could the behavior of such components be changed so that the LSB of the component is added to the LSB of the composite, and vice versa for the RSB? Then the advance width of the component could remain natural, and you could finally address both sidebearings.
I figure you’d make a lot of people angry if you changed the behavior of __components so drastically now that people have started to use them… so perhaps it would make sense to introduce ___components? 
1 Like
Do not use the double underscore hack anymore. Use incremental metrics for automatically aligned compounds, e.g. =+20. See the latest blogpost for 2.3 or the handbook: https://www.glyphsapp.com/blog/new-features-in-glyphs-2-3
1 Like
Feature suggestions that would be really useful: with such adjusted auto sidebearings, it would be great to be able to adjust them with the same keyboard shortcuts as normal sidebearings (e.g. Ctrl-Shift-Left would change the LSB =+20 to =+30).
But potentially quite dangerous 
How do you mean?
I should clarify it could be set up so that keyboard shortcuts couldn’t move an auto sidebearing if it’s set just at “auto”–that is, they could only work if there’s already a plus or minus modifier.
It just seems to me that finding the correct sidebearing modifier, like finding the correct sidebearing, should be a process where minor adjustments can be conveniently made based on visual feedback.
Additionally (or alternately) if up and down, or shift up and down, arrows while the adjusted sidebearing field has focus could change the value appropriately. But that doesn’t feel as natural.
1 Like
That is a good idea. I’ll have a look.
2 Likes