Skip to content

Conversation

@jenskutilek
Copy link

In monospaced fonts, all glyphs must have the same width, including mark glyphs. In proportionally spaced fonts, those usually have a width of 0.

luaotfload currently reads the actual width for mark glyphs from the font. This results in an extra space after the mark glyph, as you can reproduce with the Sudo Coding Font:

%!TEX TS-program = lualatex
%!TEX encoding = UTF-8 Unicode

\documentclass{article}
\usepackage{fontspec}
\setromanfont{Sudo}
\begin{document}
The dashes shoud be directly next to the p:
\begin{itemize}
\item Without mark: —p—
\item With mark: —p̄—
\end{itemize}
\end{document}

Bildschirmfoto 2025-01-30 um 09 08 51

This has been discovered and discussed in the Glyphs forum.

This PR sets the width of mark glyphs to 0, regardless of their width in the font. The result:

Bildschirmfoto 2025-01-30 um 09 09 56

@zauguin
Copy link
Member

zauguin commented Feb 23, 2025

In monospaced fonts, all glyphs must have the same width, including mark glyphs.

What is this requirement based on? Having a non-zero advance width for mark glyphs sounds like a font bug to me.

@jenskutilek
Copy link
Author

This requirement is not spelled out explicitly anywhere, but can be deduced from the TrueType and OpenType spec, and testing in different environments that use monospaced fonts.

Per Apple’s original TrueType spec, the first glyphs in a font must be

  • Glyph index 0, the "missing character" glyph .notdef, with a non-zero advance width
  • Glyph index 1, the NULL glyph with no contours and zero advance width

Per the current OpenType spec recommendations for the hhea and hmtx tables, "It is suggested that monospaced fonts set numberOfHMetrics to three".

This also follows the Apple spec. The first HMetrics entry will be the width of the .notdef glyph, which is the common monospaced width, e.g. 600 font units, then the NULL glyph, 0 font units wide, then one more entry of 600 font units which will be used for all remaining glyphs.

It's not possible to build a font with 3 HMetrics entries if the combining diacritics have an advance width of 0, as in that case there must be HMetrics entries for all glyphs (up to the last glyph in the font after which the advance width stays the same).

Bugs for various environments have been reported that state if all encoded Glyphs are not monospaced:

@jenskutilek
Copy link
Author

Here are two versions of my Sudo coding font. The only difference in the one called SudoNM is that the glyph acutecomb has an advance width of 0.

Sudo-Font.zip

@tphinney
Copy link

This issue desperately needs clarification in the OpenType specification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants