In Glyphs 2, the LSB of mark glyphs was moved to the right (to make the shape overhang to the left. This made it necessary to correct the position of component and such. To make it simpler and align with the behavior of glyphsLib/ fontmake, we change it in Glyphs 3. Now simply the width is set to zero (making the shape hang over to the right).
I suppose LaTeX is so old that it prefers marks set using the Glyphs 2 way… I don’t use LaTeX myself, but if there are any solutions using Glyphs 3 I could try them…
I suspect something else causing this. Is this a monospace font? In those, all glyphs need to be monospace. Even the nonspacing marks (don’t ask why). Layout engines are supposed to ignore the width but it seems LaTeX didn’t get the memo.
This is all monospaced - no problems except with LaTeX …
I’m trying to reproduce the issue with other fonts - do you know of any monospaced fonts made with Glyphs 3 that I can use for testing? (FiraCode is still Glyphs2 I believe…)
Y’all know I can’t let a font mystery go unsolved.
Looks like the glyph metrics get cached by luatex, in my case there are .lua files in ~/Library/texlive/2024basic/texmf-var/luatex-cache/generic/fonts/otl/, e.g. sudo-regular.lua which contain entries for all glyphs like these:
Next to each file is a compiled .luc version. If I edit the .lua file so it contains ["width"]=0 for the mark glyphs, and delete the .luc file, the mark spacing is correct! (And the .luc file is regenerated)
It seems that the cached widths are used, and not the positioning information processed by harfbuzz.
Note that HarfBuzz is not used by default, and one still needs to manually ask for it, otherwise the non-HarfBuzz code will be used (some packages like polyglossia or babel might enable HarfBuzz by default under certain conditions, though).