When Glyphs considers a glyph to be a “ligature”, it expects the anchors to be called something_1, something_2, etc. so that it can use mark-to-lig positioning to put the marks on the “relevant” ligature component.
However, U+05F0-05F2 are not strictly ligatures but digraphs. (They have no canonical decomposition in Unicode.) Marks on these letters should appear centered between the two stems, and I would expect to place a bottom anchor instead of a component-specific anchor.
Thanks. fixed it.
Hi there, checking in: has this been released yet? If not, any ETA?
This is fixed in the cutting edge version. You can try get it by checking “Show cutting edge version” in Preferences > Updates.
Hi, using Glyphs3.1.2-3151, or very close. A few issues with a Hebrew font, maybe related:
Can you try the latest cutting edge versions (3.2)? That should be fixed.
I’m trying Version 3.2 (3227). This is the version I get with “show cutting edge versions” checked. Is that the right version? All the same issues I gave above with version Glyphs3.1.2-3151 still happen with this version. Note: I emailed the .glyphs source file and one derived .ttf to support that I’d created with Glyphs3.1.2-3151.
That works for me.
vavvav-hb doesn’t have anchors defined. I can add that in the GlyphData.
That has to be defined in GlyphData, too.
You can manually add those anchors (as you did in the file you send). They should be used to generate the mark feature. How did you check for the anchors/marl positioning to work?
I thought the “cutting edge” version was going to eliminate the need to manually set category/subcategory for double-vov u+05F0 and double-yud u+05F2 digraph base chars to be Letter / Other. That was a workaround. It was successfully applied in Google Fonts Frank Ruhl Libre and David Libre.
Anyhow, I guess we can still keep using it.
Yes, vavvav-hb and yodyod-hb need to have anchors defined for sure, well, at least, “bottom”. The can take on diacritics below in many historic orthographies, and informal usage, and the combination of yodyod-hb + patah-hb is required in modern standard Yiddish orthography. It doesn’t make much sense for vavyod-hb to have anchors, but I guess it doesn’t hurt.
Yes, if the GlyphData needs to have changes for these digraphs to enable the mark cloud, please add that. If there’s a workaround to enable that, I can try that as well. (I just found this: Roll your own glyph data | Glyphs - maybe that will tell me?)
When I did not set the category/subcategory to Letter/Other, and experimented putting the “bottom” anchor for vavvav-hb and yodyod-hb way over to the right (close to the right subcomponent), the marks showed up centered with the resulting truetype fonts nonetheless (not off to the right), so I knew those anchors were being ignored. And if I loaded the truetype font into Glyphs App and looked at vavvav-hb or yodyod-hb in Glyphs App in the resulting truetype font, there was no anchor near the bottom at all. After I set the category/subcategory, the anchors were not ignored, and the marks showed up way off to the right with the resulting truetype fonts I experimented with. When I would load resulting truetype font into Glyphs App and look at anchors for vavvav-hb or yodyod-hb, they were there where I put the “bottom” anchor in the source .glyphs file, but the name of the anchor had been changed inexplicably to “ogonek”. I’m pretty sure the other font designers I’m collaborating with recently added “ogonek” support and presumably anchors for some Latin characters, so I figure this is somehow related. But it seems like a bug. Hope this makes some sense.
Do you happen do have some GlyphData.xml file next to your .glyphs file or in the ~/Library/Application Support/Glyphs 3/Info?
It shouldn’t ad a “ogonek” anchor and it doesn’t do it for me.
I don’t mean it adds an “ogonek” anchor. I meant when you look at the bottom anchor, which was named “bottom” in the source .glyphs file, in the generated .ttf font, the name appears to be changed to “ogonek”. It’s in the right place for the “bottom” anchor. Also, the diacritics that had been defined with a “_bottom” anchor now appear in the .ttf file to have an “_ogonek” anchor. Do you not see that?
So you opened a .otf in Glyphs? There are no names for anchors in the binary data. So glyphs needs to guess and that is very tricky. It hopefully will do better if the anchors are defined in glyohData.
I opened a .ttf in Glyphs. The anchors are defined for this character, alef, in GlyphData.
Interesting. As I said, it is not easy to discern the anchor names. Some guessing is involved. But that doesn’t mean the .otf is bad or wrong.
bottom anchor and position it appropriatelyYou don’t need to set the category/subcategory (at least not in the latest cutting edge version.)
I thought I had tested that case and found the category/subcategory setting is needed, even with the cutting edge version. It is true if you’re building with a script like gftools builder config.yaml, as Google Fonts builds tend to be done, to generate the .ttf files. But if I generate them from Glyphs 3 itself, i.e., with File > Export…, then the anchors are present and correctly positioned in the resulting .ttf files. Does anyone know what part of the Google Fonts stack has to change to get this updated behavior?
You never said anything about generating fonts outside of Glyphs. That explains it. GlyphsLib doesn’t have the latest version of the glyphData.xml that includes the latest corrections.
Oh that makes sense. Sorry I didn’t realize that had to be mentioned. It makes sense now. I just am learning my way around. How can that library Glyphslib get fixed? What has to happen? Anything I can do?
I’ll check that tomorrow.