Hi! I’m probably not the first to raise this, but couldn’t find the answer. Is this filled overlap bug still supposed to be happening?
Overlapping 4.glyphs (848 Bytes)
I don’t see how it could be considered a bug; the counter is nothing but a single overlapping path and if I do a “Remove Overlap” it will disappear, as I would expect.
Using open corners should fix it
1 Like
Because Glyphs does recognize it as a counter if you move the nodes just a bit, even the crossbar on the outside:
I guess there’s some threshold on how it measures it, but I’d expect it to “break” in more extreme situations than in a fairly regular 4.
Interesting. You are correct about a threshold.
From the 12-23 Handbook:
“Opened corners are considered invisible if the triangular overlaps are small enough in relation to the neighboring visible outline segments. That way, opened corners can also be placed on the outside of paths. If the overlap size goes beyond the threshold size, they will be visible.”
I’m not sure the developers expected this feature to be used in this way though.
That’s a good fix, and it exports correctly.
Either use another open corner on the counter shape or add a node on the paths that are overlapped by the stem.
1 Like
Ohhh I see, it’s the same open corners function! Perhaps, there could be an option to override the auto guessing in a specific path (even if with a script)? I guess there might be cases when it’s useful for the actual open corners too.
There are very few cases where that is a problem. And adding a nodes in those, is a quite good workaround.
2 Likes