Hello, I am running into an issue not previously present.
I have my h composed from _h.stem and _shoulder. In _h.shoulder, I have a center anchor set. However, my hbar looks like this:
Why? Previously, this used to work fine.
Edit:
This is resolved, there was a center anchor hidden below the top anchor in my h. Should this anchor not usually be at the vertical center?
Semi-related UI-note: The hidden anchor advocates to visually highlight z-stacked anchors. As this is not really a mistake, it shouldnât be too âloudâ (like the overlapping nodes are with their red dot). Maybe something like a second (third, âŠ) ring for every second (third, âŠ) anchor around the first anchor visible?!
Yes please!
It already exists as a plugin, itâs called âShow Anchors with Duplicate Coordinatesâ
And does this
Thanks for letting me know. I still think that should be a default and built-in feature.
I concur.
This time I really am running into this issue:
My nineinferior is made from sixinferior, which has a _center anchor. Why is this anchor not taken into account?
When I decompose the components, no anchor is shown for nineinferior.
The problem with the six/nineinferior is that it would traverse underscore anchors only from when the containing glyphs are marks. e.g. you donât like to see a _top when you ask the Adieresis for its anchors. I added that check for the mark glyphs in April, but I donât remember why 
.
It would make my life a lot easier if I could connect any anchor to any other anchor. I canât flip or turn components without making new anchors placed on top of other anchors. You said you donât like that and neither do I, but as I understand it there is currently no other way around it.
Perhaps create a new class of anchors that can be arbitrarily connected to other anchors of this class? There is however still the issue of connecting components with or without adding to advance width of the composite glyph. Could I suggest that this was a property that could be toggled on/off for the components where they are placed in the composite? So a switch I could set âAdvance width [ON] [OFF]â
I second all of Clausâ points. Iâll throw in my often-proposed idea of combined anchor names (such as bottomright ogonek instead of having the anchors separate and on top of each other).
Entry and exist anchors affect the advance width, others do not.
This is somewhat tricky when you just want to select one of those anchors (for example, to edit its anchor context).
Still, that should be solvable. The anchors would then still be separate in all ways (anchors property, etc.) except for the way that they are presented in the Edit View, where they would be presented as merged/space-separated.
Thanks, know all about it. What I am proposing is a system beyond the current capabilities.
There was a problem where an underscore anchor was showing up in an unintended place. I reverted that to the behavior of version 3.1
Also interesting. But how could a user then split them again manually in the UI, if they want to? Grabbing and moving would move both anchors together, I assume? Which would be okay if they are intentionally a combined anchor. But if they are two anchors and just visually represented as one, that could be confusing? Or maybe I am mistaken.
Yes, things like this make it a bit tricky to implement. A user could just add a new anchor with the same name somewhere else on the layer, thus removing it from the group, but I donât think that is very intuitive and it would need special handling to also transfer things like anchor contexts.
I thought a bit about this yesterday. I donât have a very satisfactory solution but it might be a start.
If I click on an anchor which shares its position with another anchor, the names could be shown as a list. Meaning: The anchors could still be separate, just if multiple anchors share the same position, if I click on one anchor, their names could be shown as a list next to the anchor(s). In order to select an anchor to drag it, I could click on the name label in order to select it from the anchor group.
I realise this goes against the current behaviour (where I canât click on the name label), but this might be a special case where multiple anchors share the same position. The labels could have a different, more solid (clickable) texture. If I donât select an anchor explicitly after selecting the initial anchor, both anchors move together.
In short:
Make anchor groups automatically when anchors share the same position.
Select explicit anchors by clicking on the name label from the list.
Anchor groups are automatically formed when anchors are moved on top of each other.
Does this make sense?
What anchors would you put on top of each other and how does the flipping interact?
As an example I have an in-stroke serifs as one (smart)component. I need two sets of anchors to link it up to other components in composite glyphs. The first set are stem and _stem for cases when the component should not advance the width. On top of those anchors are #entry and #exit anchor for cases when the component should advance the width. Additionally I have a _reversedExit anchor for when I use the component rotated 180 degree, and thus need the anchor point on the other side of the stem.
All these anchors are placed on the vertical midpoint of the xheight in order to link up to the bowl component (used in d,p,q,ĂŸ,&c). In order to flip the bowl I have to have the anchor in the middle of the xheight, and then all anchors land on to of each other.
I can send you the file if you need it, but I think this explanation alone is probably better.
NB: For ligatures I need a second set of #entry and #exit anchors if I want to avoid intermediate composite glyphs with the #exit anchor placed again to overrule the placement in the components.
