Closed Mark2Mark closed 2 months ago
I would need to see the drawing code.
You have access to the private repo. main-G3 branch is the one live.
Another note: I see it only happen in some glyphs of my test font. /a /o /s /oacute for example, but not in /b /c /f /g /h /n /e, etc
I cannot find out what is different in those glyphs. Anchors or background seems not to cause interferences, as those are present or not in those mentioned glyphs crosswise. (the /s and /S now work fine though)
Causing glyphs don’t have any special layers either.
No other reporters are active when this happens.
🫠 When duplicating a faulty glyph, that duplicate also behaves fine‼️
@schriftgestalt here you can see the oddity, where a glyph that shows this bug that gets duplicated has this duplicated glyph (/oacute.001) behave totally fine.
I cannot see how the drawing code can cause that, as it just implements the standard dash line on the NSBezierPath.
And then at other times this issue is gone again, even with the glyphs I noted above, where – when it happens – it happens each time I come back to that glyph. But after re-opening the file, all is fine.
In the setLineDash
call, you use a dashArray[4]
and a count of 4. But only the first fields are set. Use a count of 2 and it should work.
This has likely been it. Thank you so so much! 🙏
(fixed in 3.7.6)
@schriftgestalt: This is new with Glyphs 3.2 and I did not touch the drawing code in the plugin. Do you know what might suddenly cause that?
In the clip you see how initially the outlines are dashed as supposed to. Then when panning the view, they suddenly lose the dash and get solid. That is the bug.
Zooming triggers them to get their dash back.
This happens in all kind of scenarios now, the video shows just one case.
https://github.com/Mark2Mark/variable-font-preview/assets/5824595/6181a618-3d82-4010-9d60-f6012f600e91