Diacrtitics change ΔX between Glyphs 2 and Glyphs 3

I typed p macron into FontGoggles, with a version of a font created in Glyphs 2 and a version created in Glyphs 3.

The top is Glyphs 3, the bottom is Glyphs 2.

Can someone explain why the ΔX are different, and/or how I might have switched from the bottom setting to the top?

(My memory isn’t good enough to help me and I can’t find the original source from 2022…)

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).

Thanks Georg. Someone has reported an issue to me that spaces are inserted after this combination, when using LaTeX and fonts created by Glyphs 3:

I suppose LaTeX is so old that it prefers marks set using the Glyphs 2 way… :grinning: 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…)

You can try my Sudo Coding Font, it is monospaced and has mark positioning.

I can confirm that in some cases you get an extra space after the letter. It seems to depend on the LaTeX engine used.

The extra space is there with luahbtex 1.18.

The spacing is correct with xetex 3.14.

Weird, because the HB in luahbtex stands for harfbuzz, and harfbuzz handles the combining marks correctly.

It is possible to add some GPOS to reduce the width of the non spacing marks. I never had the need to try it.

I tried that too, but it has no effect on the result.

@jkutilek Thanks so much - this is very helpful information to have.

@GeorgSeifert GPOS shifts would have to LaTeX-only though :thinking:

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:

return {
 ["cache_version"]=3.134,
 ["compacted"]=true,
 ["creator"]="context mkiv",
 ["descriptions"]={
  -- ...
    [772]={
   ["boundingbox"]=50,
   ["class"]="mark",
   ["index"]=722,
   ["name"]="uni0304",
   ["unicode"]=772,
   ["width"]=448,
  },
  -- ...
}

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.

Not sure where to report such an error, though.

2 Likes

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).

1 Like
1 Like

With Sudo font, I can confirm it is a LaTeX (or rather luaotfload) bug when not using HarfBuzz:

\documentclass{article}
\usepackage{fontspec}
\newfontfamily\sudo{Sudo-Regular.ttf}
\newfontfamily\sudohb{Sudo-Regular.ttf}[Renderer=HarfBuzz]
\begin{document}
{\sudo p^^^^0304,}\par
{\sudohb p^^^^0304,}
\end{document}

2 Likes

I’ve made a PR for luaotfload.

2 Likes

@jkutilek Thanks for your investigation!