I need some clarification on how anchors work, as I come, in Linux, from a different font editor.
If I open an .otf that uses anchors (eg EB Garamond 12, which I know was designed with Glyphs, as Wikipedia says), I can’t find the lookup ‘mark’, which - like ‘cpsp’ is’ kern '- should be contained in GPOS. Where are these lookups?
Still opening the same .otf, in the font editing window I don’t see the anchors: is this normal behavior?
I do a basic experiment. I automatically create anchors for a glyph, say | a |, and then those for brevecomb and macrocomb. Diacryrics have zero width (although I read in the Mark Attachment tutorial that this is not necessary). So I create the compound glyphs, but they are completely off-center.
Evidently there is something wrong with the procedure I follow …
Thank you
Ok for EB Garamond, although on opening I get a message that the Glyphs version is a lot older and is having problems with composite glyphs. However, I can’t find the GPOS lookups.
But until now, as I said above, until now I have worked on Linux with FontForge and I don’t think there is a way to open or otherwise import the .sfd files, so I can only take the .otf files. Does this mean that the original lookups are lost (now I find GSUB, but not GPOS) ?
In any case I still have the above problem even from an original .glyph file, with another font. The images are completely similar to those already posted. PS
I realized now that the problem arises from the fact that my “wrong” glyph was composed by |a| + |breve| (u02D8) and not by |a| + |brevecomb| (u0306). Now I fixed it manually.
But when I choose the item: “Transform into compound glyph from components”, the program does not use .comb glyphs: what mistake am I making?
Not all GPOS features are listed in the Features tab since that data is generated from the anchors and the kerning info as defined in Edit View. When opening a .glyphs file, no feature code is lost. When opening an exported file, some data, including some feature code, cannot be reconstructed. This is why it is not advisable to work from an OTF or TTF file and instead always use source formats.
Glyphs can also open UFO source files. Perhaps there are UFO source for the fonts you want to work on.
What was the current glyph that you were working on when running this command? And what component glyphs were used instead of the .comb glyphs?
Since it is now almost two in the morning, I postpone further experiments for the first things (import of .otf etc.) until tomorrow.
I proceeded like this: I deleted eg. | abreve | with “Clear”; in fact they were originally characters not constructed with anchors. Selecting the empty slot I gave: “Transform into compound glyph from components”. As I reported above, the program used the normal (spacing) glyph of | abreve | (u02D8) instead of brevecomb (u0306)
Because there are no anchors in compiled OTFs. Work with source files, as suggested. If you reverse engineer compiled binaries, it is to be expected that some things will be lost. If you must use the OTF route, be prepared to reinstate some of the info lost in the process. There is a tutorial about opening existing fonts.
This makes me doubt that the problem is not in the fact that this lookup is not present in the compiled .otf, but that Glyphs for some reason cannot read it
The same if I export the file as UFO
Yes, now I understand.
However this is a useful feature and could be implemented, also I realize that developers may have other priorities at the moment.
In any case it was pointed out to me by its author, @SimonCozens, a useful plugin capable of importing different features from an .otf.
However, since I can export the .fea configuration files from my old .sfd sources, including those related to the ‘mark’ lookup, I will try as soon as possible if with this system I will be able to recover the anchors.
