Do PANOSE monospace settings really matter anywhere?

[arrowtype]

Does anyone know if the PANOSE monospace setting is actually checked/relevant in any modern app? I’m hitting Font Bakery warnings around this, and I’m unsure whether it’s really worth fixing. (I have multiple mono projects at the moment, and would need to adjust the build approach somewhat significantly to make this fix. If it’s worth it, it’s worth it, but if it doesn’t actually matter, I don’t want to complicate the build for it.)

I tested this question in (Windows 11) PowerShell yesterday, and panose made no difference for whether a mono font was listed as a font option. It seems that Font Bakery included this check based on a TypeDrawers thread where it was claimed that it matters, but without any testable scenarios mentioned. The only testable context cited was that Word may enforce monospacing if panose monospacing is set – but this only seems like a potential reason to make sure it’s not set, in non-mono fonts.

It seems that Windows may provide a mechanism for app developers to check the panose of fonts, but it’s unclear if any apps really do this.

Any insights would be greatly appreciated! Thanks in advance. ❤️

[tphinney]

I have just been looking into this issue for a particular existing font I was looking at changing. Many years ago, I would have assumed that there were some programming environments, shells, etcetera that restricted one to monospaced fonts. BUT as far as I can tell based on web searches for various questions, there are very few (if any?) such environments today. Not sure if the apps got more flexible, or if that was never true.

That said, my current concern is more “is this a general problem?” and not “are there ANY apps that might choose not to display this font because it doesn’t claim to be monospaced?”

I was definitely responsible for the OPPOSITE claim you mention, which really could create a nasty bug, but that as you say was the reverse: proportionally spaced fonts should avoid claiming to be monospaced in their Panose.

[arrowtype]

Hey Thomas, thanks so much for taking time to reply!

As far as I could tell, PowerShell really does only show monospace fonts (at least by default), in Windows 11.

In this test, "Config Mono" has Panose set to all zero values, while "Config Mono PanoseTest" has the basic monospace parameters set. However, they both appear in an abbreviated list that only includes monospace fonts, and that list is presumably using other parameters, such as the post.IsFixedPitched value, or else (maybe) some check of character advance widths.

On MacOS, iTerm2 also boosts monospace fonts in its list of Font options for a profile. It then also allows non-mono fonts to be set, but when they are, they are displayed in a monospace layout, with very wide spacing by default. So, basically, it still matters in certain apps for monospace fonts to be truly monospaced. However, I don’t think Panose values would have any affect here.

I was definitely responsible for the OPPOSITE claim you mention, which really could create a nasty bug, but that as you say was the reverse: proportionally spaced fonts should avoid claiming to be monospaced in their Panose.

Okay, yes, that makes sense. It would be nasty bug if a proportional font were rendered with monospacing! I haven’t tested that personally, but if I do, I’ll try to add that result here.

[arrowtype]

I've heard that, as of 2017, JetBrains required the PANOSE monospace attributes to be set. Today, however (at least in JetBrains PyCharm, on Windows 11), this is no longer the case. It does boost monospace fonts, but it doesn't base this on PANOSE, based on my test case. It then also offers my choice of any proportional font on my system, if I scroll at bit further in the font menu:

[arrowtype]

I’ve variously heard that PANOSE monospace values might matter in either Putty or eMacs, though I haven’t tested this personally. I will update this if I do. Others are welcome to test & share their findings, as well!