I have been making monospaced fonts for coding and I have noticed that ticking “IsFixedPitch” custom parameter is not enough for the font to be recognised as monospaced. One of the pitfalls were combining diacritics that are made zero width on export and thus failing the monospace test, and I had to manually mark them as spaced.
This gave me the idea; can the custom parameter automatically ensure the resulting fonts to be truly technically monospaced? i.e. disable automatic metrics adjustment in some glyphs (e.g. zero width glyphs), and auto-adjusting the glyphs that are not set to the same width. As for the latter case, I could see two ways of implementing: The custom parameter has additional field (or replacement new text box) where the user needs to specify the width. If the custom parameter does not exist or the value is set to zero, the font won’t be flagged as monospaced. The value will apply file-wide, and will take away the ability to adjust spacing from the grey info box (or give a warning dialog and cancel spacing changes). If that custom parameter is introduced later and finds inconsistency, it could give a warning or apply the most popular width value in the file.
I wonder what would be the best approach. I see two ways: A switch in font info and then all glyphs will have the same width as some key glyph like space. Or a setting that defines the width right in font info.
I was going to make a new suggestion about this same topic, and I seem to have already done that long time ago. Sorry for a super long delay.
I think the initial suggestion still holds, and my suggestion is to specify the number in font info; isFixedPitch to have a number field where zero is considered OFF and any non-zero value is considered True as well as the layer width (and there is no need for a checkbox in a boolean custom parameter since you can now dis/able them from the left checkbox). Linking the width to a particular glyph doesn’t sound user-friendly to me (feels like the lowercase d issue in Illustrator).
That’s tricky. I don’t remember the details right now, but there was some reason I needed to keep all encoded glyphs strictly the same monospace width in Sudo to avoid problems in some terminal apps. I think spacing combining marks would be less of a problem in this context.
Maybe when the IsFixedPitch parameter is present, the autogenerated ccmp could set all combining marks widths to 0? I don’t know if this supported in the common terminal emulators at all though …
I would agree with Jens, it’s more important to set all glyph width to zero, otherwise some environments do not consider the font as monospaced in the first place. That’s especially the case when the designer’s intent and acceptance of the possible drawback is clearly stated in the form of the custom parameter.
Some code editors only selected features. e.g. Sublime Text supports liga but not calt, so it’s likely that other features are also not paid attention to. I know it doesn’t support Arabic positional features or rlig either.
So to be recognized as a monospace font in some edge cases, we need to mess with the rendering in other (the ones that add the width of the mark). Can someone confirm with a sample font what is the best solution?
I’ve set my Comic Code to isFixedPitch=True and overridden all the combining diacritics’ category to be spaced, and given the same value. It’s now recognised as monospaced in macOS but diacritic combining still occurs.
Whether combining succeeds or not, I would guess this rigid monospace check predates OpenType (or at least modern expectation of it) and is needed where such behaviour is not expected. In my view, dynamic combining is not always necessary (some people might even argue against it as it messes up visual character count).
The combining non-spacing diacritic marks in my 1403 Vintage Mono Pro typeface have a 0 width as set by Glyphs 2 and isFixedPitch also set. As I recall, it was working as a monospace font. But, perhaps there’s a test I haven’t tried with it.
@composerjk I don’t know, actually. I had a customer complaining that it wouldn’t appear on his macOS (version unspecified). I had sent him 3 updates, 1: isFixedPitch present, 2: also all glyphs forcefully monospaced, and 3: also added new glyphs. I know 1 didn’t work and 3 did, but I don’t throw away the possibility that he didn’t test 1 properly (possible cache issue). It seems that adding isFixedPitch seems to be enough to convince Font Book though.
@GeorgSeifert I don’t know what you mean by eventual spacing problems, but on TextEdit the spaced combining marks behaved just like the non-spaced ones with no spacing oddities.