When to set panose numbers, TypoAscender, WinAscent, etc.?

When I convert fonts from .vfb to .glyphs, I see custom parameters set for things like panose, glyphOrder, and TypoAscender. With the exception of some OpenType features, I have been deleting the custom parameters carried over from FontLab Studio. My limited testing in Windows hasn’t shown any obvious problems, but I want to make sure I have my bases covered. How necessary is it to set these custom parameters? My goal is to make fonts that work predictably on PC and Mac.

There are explanations for every parameter in the appendix of the handbook. For Vertical Metrics, see the vertical metrics tutorial. Forget panose, it is pretty much irrelevant.

1 Like

If you don’t know what the values are, chances are that you don’t need them ;).

Like the cavalier reasoning :grinning:

2 Likes

Thanks. I have read most of the explanations in the handbook, as well as many pages elsewhere. What I was looking for was expert opinions like, “Forget panose, it is pretty much irrelevant.”

1 Like

Well, “Forget panose, it is pretty much irrelevant.” is a very bold claim.

If you are creating a font for terminal emulator use you should definitively set appropriate Panose values. There are clients (terminal emulators) out there in 2023 that look at Panose and only allow the font if it is marked monospace there!

You can set these values here:

I know this thread is rather old, but I believe that information needs some clarification as it still comes up in new fonts. And at least me, personally, use this forum also as knowledge base :slight_smile:

Which terminal emulators would that be?

I think looking at post.isFixedPitch would be a much better way to find out if a font is monospaced.

According to my old commit message when I researched it, it is for example Windows CMD and Powershell (if not used with the more modern Windows Terminal).

Let me check if Fontforge (that is used over there) sets isFixedPitch based on Panose; Fontforge does a lot of strange things :wink:


Fontforge does not touch isFixedPitch via Panose. Continuing …

It seems it not exposed in Fontforge, i.e. can not be seen.
On generation it is (automatically) set if all non-empty glyphs (in the foreground) have the same widths.

Because the mentioned project above does force all glyph width to be identical (for some settings) and even THOSE fonts needed the Panose set, we can conclude that isFixedPitch is maybe necessary but not sufficient for CMD et al.

1 Like

Thanks for your research!

I just tried to remove the PANOSE setting from my Sudo font, and reexport it. It is still recognized by PowerShell. The only thing that says “monospaced” is now the isFixedPitch setting. In fact, even the proportional (“UI”) fonts are offered in PowerShell, because apparently the isFixedPitch setting cannot be turned off on a per-instance basis.

Bildschirmfoto 2023-11-16 um 18.46.58

(PowerShell 7.3.9 with Windows-Terminal 1.18.2822.0)

Feel free to try these fonts:

As I said, affected is only the old Windows Terminal less versions of CMD and Powershell, how was that called conshost or something?

I could not find it in Windows 11 anymore (that seems to always use Windows Terminal, rightly so), but with Windows 10 it was possible to start CMD/Powershell without Windows Terminal:

image

And Sudo is not recognized…:

The font chooser starts with outline fonts (alphabetical) and than raster fonts.

Thanks for checking. I think I found a way to start the old cmd.exe, or at least it looks like it (I’m not that familiar with Windows), on Windows 11, but Sudo is also in the font menu there. Maybe it all runs on a new foundation that can’t be turned off anymore.