A little story I felt like sharing, because I found it both frustrating and hilarious and thought maybe some people here would appreciate it.
A few weeks ago I made some minor UI changes to FCEUX (not yet available in official release), and yesterday feos reported to me that it looked broken on his system. (Demonstrating images attached at the bottom.)
The problem was that some of the interface (e.g. nametable view, CHR viewer, etc.) depended on being an exact pixel size, but the dialogs were made with the age old method of CreateDialog and RC templates, which which uses "dialog box units" instead of pixels.
The way "dialog box units" work is that they're based on the size of the font the dialog is being rendered with. That way if the user has different DPI settings, or a different font configuration, the layout is automatically adjusted to fit the font as rendered.
So I fixed the problem by checking the actual pixel size of the generated dialog at runtime, and manually expanding it if there weren't enough pixels to contain the relevant pixel-sized interface. A bit annoying to have to do, but it seems like a good idea to ensure, in case people have different DPI settings.
The problem was fixed, but I wanted to know why things looked different on my computer, and how I could adjust it. I checked my Windows display settings, but the font size was set to 100%, so this shouldn't make a difference. I tried other programs with Windows forms, but they all looked identical across the systems I was comparing. Only FCEUX was getting a large font!
What I discovered was that FCEUX was using MS Sans Serif. To see if this changed anything I reinstalled MS Sans Serif on my computer, and all of a sudden it was rendering at the correct size! Quite mysterious! How did MS Sans Serif get messed up on my computer, though?
As it turns out, Windows 7's installer was the culprit. If you install it on a high-DPI monitor (e.g. my 13.3" laptop with a 1080p screen), the installer sets your font size to 125% by default, but in addition to this it modifies three special fonts to increase their size independently of the font size system:
This is really bizarre! I can only imagine that this was some hack done at Microsoft to make the installer or some other anointed legacy program look better. (MS Sans Serif used to be the default system font, but it got replaced by Tahoma as of Windows XP. Courier was replaced by Courier New. Dunno about MS Serif?) Since Vista, there has been a DPI-Aware API where programs can tell the OS whether or not the programmer had variable-DPI in mind. On Vista and later, this means that increasing the font size setting on Windows causes legacy programs to render at their original DPI and then get rescaled by the renderer (image attached at bottom). It looks ugly, but its more compatible than letting the higher DPI fonts mess up the layout. The three special fonts might have been trying to avoid this?
I laughed loudly when I found this article complaining that apparently MS Office checks if your system font settings for menus/etc. are using MS Sans Serif and override that one font specifically to use Tahoma instead, presumably to work around the installer hack that modifies these fonts and make sure their dialogs look consistent. In the article, the user describes their own hack to get that font to display anyway despite the override. A work-around for a work-around for a work-around.
Anyhow, just something stupid I learned today. If you're making Windows UI, it's probably best not to use MS Sans Serif, MS Serif, or Courier, and always test your layouts at 100% font size at least. (Changing to other sizes for testing is a big pain, because Windows requires a logout for this.)
It's also probably best to use a GUI system with a proper layout manager, rather than the ancient RC template API, but that's its own battle.
A few weeks ago I made some minor UI changes to FCEUX (not yet available in official release), and yesterday feos reported to me that it looked broken on his system. (Demonstrating images attached at the bottom.)
The problem was that some of the interface (e.g. nametable view, CHR viewer, etc.) depended on being an exact pixel size, but the dialogs were made with the age old method of CreateDialog and RC templates, which which uses "dialog box units" instead of pixels.
The way "dialog box units" work is that they're based on the size of the font the dialog is being rendered with. That way if the user has different DPI settings, or a different font configuration, the layout is automatically adjusted to fit the font as rendered.
So I fixed the problem by checking the actual pixel size of the generated dialog at runtime, and manually expanding it if there weren't enough pixels to contain the relevant pixel-sized interface. A bit annoying to have to do, but it seems like a good idea to ensure, in case people have different DPI settings.
The problem was fixed, but I wanted to know why things looked different on my computer, and how I could adjust it. I checked my Windows display settings, but the font size was set to 100%, so this shouldn't make a difference. I tried other programs with Windows forms, but they all looked identical across the systems I was comparing. Only FCEUX was getting a large font!
What I discovered was that FCEUX was using MS Sans Serif. To see if this changed anything I reinstalled MS Sans Serif on my computer, and all of a sudden it was rendering at the correct size! Quite mysterious! How did MS Sans Serif get messed up on my computer, though?
As it turns out, Windows 7's installer was the culprit. If you install it on a high-DPI monitor (e.g. my 13.3" laptop with a 1080p screen), the installer sets your font size to 125% by default, but in addition to this it modifies three special fonts to increase their size independently of the font size system:
- MS Sans Serif
- MS Serif
- Courier
This is really bizarre! I can only imagine that this was some hack done at Microsoft to make the installer or some other anointed legacy program look better. (MS Sans Serif used to be the default system font, but it got replaced by Tahoma as of Windows XP. Courier was replaced by Courier New. Dunno about MS Serif?) Since Vista, there has been a DPI-Aware API where programs can tell the OS whether or not the programmer had variable-DPI in mind. On Vista and later, this means that increasing the font size setting on Windows causes legacy programs to render at their original DPI and then get rescaled by the renderer (image attached at bottom). It looks ugly, but its more compatible than letting the higher DPI fonts mess up the layout. The three special fonts might have been trying to avoid this?
I laughed loudly when I found this article complaining that apparently MS Office checks if your system font settings for menus/etc. are using MS Sans Serif and override that one font specifically to use Tahoma instead, presumably to work around the installer hack that modifies these fonts and make sure their dialogs look consistent. In the article, the user describes their own hack to get that font to display anyway despite the override. A work-around for a work-around for a work-around.
Anyhow, just something stupid I learned today. If you're making Windows UI, it's probably best not to use MS Sans Serif, MS Serif, or Courier, and always test your layouts at 100% font size at least. (Changing to other sizes for testing is a big pain, because Windows requires a logout for this.)
It's also probably best to use a GUI system with a proper layout manager, rather than the ancient RC template API, but that's its own battle.