https://bugs.winehq.org/show_bug.cgi?id=55753
Bug ID: 55753 Summary: Fonts on dialog/modal windows are not aliased Product: Wine Version: 8.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts Assignee: wine-bugs@winehq.org Reporter: jimmyg521@gmail.com Distribution: ---
Created attachment 75248 --> https://bugs.winehq.org/attachment.cgi?id=75248 Screenshot of application mp3tag with open dialog box showing unalised fonts
I'm on a brand new install of MXLinux v23/Debian Bookworm with the latest stable/dev wine using the Debian Bookworm PPA from WineHQ (now after significant trouble-shooting). **Previous install of MXLinux v21 with it's version of wine-staging did not exhibit this behavior.**
Current system/wine information:
√ ~ > uname -a Linux HOLLIN 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27) x86_64 GNU/Linux HOLLIN [uname -a] ~ 23-10-08 4:17PM √ ~ > wine --version wine-8.17
MX-Linux System Report: KDE Plasma 5.27.5; Debian 12.2
CPU: 8-Core Intel Core i7-10700 (-MT MCP-) speed/min/max: 990/800/4800 MHz Kernel: 6.1.0-10-amd64 x86_64 Up: 8d 9h 1m Mem: 6843.1/15775.5 MiB (43.4%) Storage: 19.11 TiB (41.5% used) Procs: 476 Client: Unknown Client: mx-welcome inxi: 3.3.06
====
Problem is not about an application installing or running, it's about the dialog windows that both Wine itself and applications display. For example, I can run the notepad app from a terminal in any wine prefix (default 64-bit or a new 32-bit)and its fonts on menubar and menus look fine. But if, for example, I select from the menubar File > Open, the fonts on the Open dialog window are not aliased. The dialog itself is fully functional, its only the fonts that are unaliased. WineCfg it turns out is a dialog (modal?) window and it opens with unaliased fonts. No change to any of the fonts listed on the WineCfg Desktop Integration Appearance Theme modify this font behavior.
I have:
1. Completely uninstalled the MXLinux v23 default wine (using mc to track down every folder and file to delete them); reinstalled from the MXLinux repos - no change 2. Completely uninstalled again and reinstalled using flatpak version from org.winehq.Wine - no change 3. Completely uninstalled again, added the Debian Bookwork PPAs to install from WineHq - no change 4. Installed from the WineHQ PPA Wine-Dev - no change 5. Googled ad nauseam various combinations of words trying to limit search results to this specific issue, but it's a bit hopeless; most everyone is looking for ways to install fonts or make fonts larger, but that all works fine for me; in fact, on the Winecfg tab for Appearance, the slider is at 144 dpi and the font displayed below the slider is, of course, correctly aliased; just not any of the rest of the fonts used on the Winecfg dialog window or any other dialog window 6. I have made sure that any tahoma, etc. font in my Linux system that might cause some kind of font conflict was deleted and reinstalled using winetricks and rebooted my system - no change 7. I have removed nearly every font from my user /.fonts/ folder and restarted - no change 8. I have used winetricks to set the fontsmooting registry keys - no change 9. I have used winetricks to install most of the avialable fonts - no change 10. I have created test 32-bit and 64-bit prefixes using winetricks and Q4wine - no change; dialog/modal dialog fonts remain unaliases 10. I have added specific values to my local linux install's user .fonts.conf file to force Linux system aliasing and hinting hoping, based on a blog post, this might spill over into wine, and restarted - no change
Again - this is not about funcationality - it all works, it's only about the font display of dialog windows; primary windows of apps and Wine system apps (regedit, notepad, control, taskmgr) all load and display fonts as expected until I use File | Open, File | Print, etc. (see attached screen of application mp3tag running in a 32-bit prefix).
Why is this a problem? On an HDPI monitor, pencil thin unaliased fonts are very difficult to read. It is a real usability issue.
Here is an image of what I'm talking about - the application mp3tag (which I've been using for several years in wine on both Kubutu and MXLinx v21) with the File | Options dialog enabled. If you increase view to 200%, you can clearly see that the font of the dialog is not aliased while the menu font and other fonts in the app UI are.
https://bugs.winehq.org/show_bug.cgi?id=55753
--- Comment #1 from Guy Stalnaker jimmyg521@gmail.com --- Follow up - I remembered that the Windows Registry has some keys related to fonts and font substitutions. A quick Google lead me to edit some of these keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
There are several that seem related to this issue:
MS Shell Dlg MS SHell Dlg 2
The default value of these two keys was Tahoma. A bit of experimentation reveals that modifying the keys value produces changes to the font used for the dialog/model dialog boxes (that is, modifying the key, closing RegEdit, then option winecfg, produces the following results):
- Tahoma (default) - font unaliased - Arial - no change, font unaliased - Ubuntu - no change, font unaliased - SegoeUI - no change, font unaliased - Verdana - no change, font unaliased - hack - used, font aliased! - Inter - used, font aliased! - Lato - used, font aliased! - monofur - used, font aliased!
I have many fonts installed on my system, some from the distribution repository, some via winetricks, and some manually (these installed both system-wide, and locally).
Some of these fonts are "found" by wine, used on the dialog/modal dialogs and correctly aliased. But some are not, including the defaults as set in the default registry installed when wine is installed, or modified by winetricks when it modifies some of the keys. Arial and Verdana are installed as part of the mstcorefonts package. Ubuntu is installed from the MXLinux repositories. Tahoma and SegoeUI are installed via winetricks, without changes (still unaliased) and, for testing, in my local font folder (still, unaliased).
The four fonts which wine does use and which are antialiased are installed by from the MXLinux repository and in my local .fonts/ folder. So, wine is successfully finding and using fonts through out the system, but it's not using them all in the same way.
So it seems that in some way, wine is not correctly finding fonts, or is using the wrong fonts, or something else. I have not done an exhaustive run through all the fonts I have (multiple 100s), but at least these four work as expected. So, I am not as down the river as I was because I can set the MS Shell Dlg key to a font that is antialiased such that I can read them without picking up a magnifying glass (that's what I've had to do). But I'm not closing the bug, because the registry defaults for four different wine installations did not antialias the font on the dialogs, which did not happen in the previous version of MXLinux and wine.
-
WineHQ Bugzilla