Winforms: No more Microsoft Sans Serif, return actual system font from SystemFonts.DefaultFont?

[jnm2]

Is this a good time to fix a long-standing issue, the default use of Microsoft Sans Serif 8pt instead of Segoe UI 9pt? This is in violation of Microsoft's design guidelines:

UI technology | Target Windows version | Fonts to use and optimize for
-- | -- | --
Win32 or WinForms | Windows Vista or later | Use the appropriate Segoe UI font.

• Developers:

  • For elements that use fixed layout (such as Windows dialog templates and WinForms), hard code the appropriate font from the preceding table.

The only member of SystemFonts that reflects the actual system theme is the unintuitively-named SystemFonts.MessageBoxFont. Anything in SystemFonts that's not returning Segoe UI on a default installation of Windows should either change and start returning the real value or should be obsoleted. In other words, https://docs.microsoft.com/dotnet/api/system.drawing.systemfonts#properties should line up precisely with https://docs.microsoft.com/windows/desktop/uxguide/vis-fonts#fonts-and-colors on current Windows installations. Tahoma is not okay and Microsoft Sans Serif is not okay.

These guidelines are consistent with Microsoft's font guidelines for other UI technologies.

If Segoe UI was defaulted effortlessly, it would be a huge benefit! The fight against Microsoft Sans Serif has afflicted every Windows Forms project I've worked on, large and small. I also see apps being built that didn't undertake this uphill battle and which stand out visually as less professional as a result. Here's an example taken from the second link below:

History and hacks to get it working:

• https://weblogs.asp.net/kdente/394499
• https://benhollis.net/blog/2007/04/11/setting-the-correct-default-font-in-net-windows-forms-apps/

[wjk]

I applaud this. However, there are a few issues you should be aware of.

1. The reason why the MessageBoxFont property is named such is because the Windows Visual Style (uxtheme) system supports multiple fonts for a single theme, each with a different semantic use. It just so happens to be that on Windows Vista and later, most if not all of the uxtheme fonts always return Segoe UI. Renaming this property would actually increase confusion (at least if you know how to use uxtheme).
2. Windows does not let you create your own custom theme, which would seem to make all this uxtheme indirection pointless. In a sense, it is — if you are targeting actual Windows. The ReactOS and Wine projects both develop open-source, Windows-compatible APIs that include uxtheme. Both allow custom themes to be loaded and used. Furthermore, neither supports the Segoe UI font at all due to licensing restrictions. Hardcoding the Segoe UI font into Windows Forms would break compatibility with these two platforms, which I do target regularly.
3. I can use Segoe UI — or whatever font is specified by the theme, if applicable — at runtime by adding this.Font = SystemFonts.MessageBoxFont into my Form or UserControl constructor, after the InitializeComponent call. Not only will this use the correct font at runtime (Segoe UI or not), it will also rescale all the controls in the form to preserve the layout while not clipping any content. If we set the font before any controls are created, then the controls won't be automatically rescaled. Again, simply assuming that Segoe UI will always be used is not portable.

If we are going to change this behavior (and I hope we do!) I would want the above three points to be addressed. Thanks!

[wjk]

OTOH, I do support updating the DefaultFont property (only). After reading its documentation, I agree that its description is misleading. It should instead return the same value as MessageBoxFont, as the latter font is what is _really_ recommended for dialog boxes and controls.

[merriemcgaw]

I like this idea! We could change the default font yet still ensure that when the developer sets it we don't override that. We have a lot of UI ourselves in System.Design.Editors that would need to be validated if we change the default font. But this could go a ways towards modernizing WinForms to current standards in general.

[merriemcgaw]

The UI validation for System.Design.Editors would also need to include localized versions of these screens.

[wjk]

I was thinking on working on this issue (given it has the up-for-grabs label), but I ran into two issues:

1. The SystemFonts class is in the System.Drawing.Common project, which is part of corefx. Should I send a PR there and link this issue, or is it sufficient to change Control.DefaultFont to use the MessageBoxFont instead?
2. How should I test the UI in System.Design.Editors, given that most of it is stubbed to throw a NotImplementedException? Furthermore, as I understand it most of that API is still .NET Framework-only anyway.

Thanks!

[merriemcgaw]

@dreddy-work is going to take a look through our codebase and make sure that this approach is what we want to take. We do like the idea of moving over to a more modern font.

[wjk]

@merriemcgaw I'm not certain what you mean by "this approach." What other approach are you considering?

[dreddy-work]

Changing DefaultFont in corefx would be a ideal solution. We reached out to Windows on what would be the recommended way to request windows default Font. MSDN documentation discourages current 'DefaultFont' logic.