Hi Huw,
Thank you very much for the detailed explanations! Basically, this validates the cleanup work that Austin and myself did in Winetricks and it's great to know that we made the right assumptions, especially the wineserver wait trick.
Enjoy the Holidays!
Best regards, Mihai
On Wed, Dec 20, 2017 at 8:53 AM, Huw Davies Huw.Davies@physics.ox.ac.uk wrote:
On 19 Dec 2017, at 20:30, Mihai Todor todormihai@gmail.com wrote:
First of all, there is some logic somewhere in Wine which automagically populates `HKCU\Software\Wine\Fonts\Cache` when font files are copied into `.wine/drive_c/windows/Fonts/`. The magic seems to be based on inotify, but I don't understand well enough how it works.
When a Wine session (instance of wineserver) starts the first process that needs access to fonts creates a font list and saves this information under the above key. Further processes read the data from the key and so save time not having the create the font list from scratch.
The code that creates the font list is in dlls/gdi32/freetype.c:init_font_list() You’ll see that fonts within c:\windows\fonts are added to that list.
However, there seems to be a race issue between apps like regedit and notepad and the above mechanism. For example, if I have the corefonts installers cached under `.cache/winetricks/` and I run `winetricks corefonts` and I start notepad immediately after, I notice that the new fonts are not available. Worse, most times (not sure yet how to reproduce it all the time) if I run regedit just after, the new fonts never get added to `HKCU\Software\Wine\Fonts\Cache`, which seems to be the place from where Wine lists fonts through EnumFontFamiliesEx (try running this code https://github.com/kamwoods/FontAnalysis/blob/d894c082221912e72653ae76804a72... just after installing corefonts). This happens on wine-3.0-rc2 and older.
Is this the expected behaviour?
Yes, see above. You’ll need to let the wineserver shut down after adding the fonts. After that, subsequent invocations will recreate the font list and things should work as expected.
I'm also wondering why Wine doesn't also write the required entries under `HKLM\Software\Microsoft\Windows[\ NT]?\CurrentVersion\Fonts` when it populates `HKCU\Software\Wine\Fonts\Cache`. Is this a bug? Is there a different way of registering fonts that Winetricks should use? I'd be more than happy to remove this manual registry insertion code from Winetricks…
It doesn’t do that, because Windows doesn’t do it that way. You need to add the registry key to have Windows see the font. This is normally done by the font installer, which winetricks in by-passing...
And, I also noticed that a fresh wine install on Ubuntu 16 will auto-populate both `HKLM\Software\Microsoft\Windows[\ NT]?\CurrentVersion\Fonts` keys with the following fonts: Courier -> coure.fon MS Sans Serif -> sserife.fon MS Serif -> serife.fon Small Fonts -> smalle.fon
If I look in `HKCU\Software\Wine\Fonts\Cache`, I see that they are located in `/opt/wine-devel/bin/../share/wine/fonts/`, so shouldn't the above entries also point to the same location? And maybe not all apps will like the `..` in the font path…
Fonts without a path correspond to c:\windows\fonts. These files should be installed into that directory.
And, since we're here, I noticed that Winetricks registers font replacements under `HKCU\Software\Wine\Fonts\Replacements`, but doesn't add any entries to `HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes`. Does Wine completely ignore this key?
No, font replacements are a Wine extension:
From dlls/gdi32/freetype.c:
The replacement list is a way to map an entire font family onto another family. For example adding
[HKCU\Software\Wine\Fonts\Replacements] "Wingdings"="Winedings"
would enumerate the Winedings font both as Winedings and Wingdings. However if a real Wingdings font is present the replacement does not take place.
This is different from how FontSubstitutes work, which are essentially just aliases for facenames and optionally charsets.
Huw.