https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #7 from Nikolay Sivov bunglehead@gmail.com --- (In reply to 399989567 from comment #6)
(In reply to Nikolay Sivov from comment #5)
No, I don't think you should be making such code changes to fix this. What I don't understand is why values are dumped as hex() in your reg file. And what does it have to do with Noto Sans fonts.
Removing fonts from wine/fonts is not really supported, so please don't do that. DirectWrite will try to use Tahoma by default, if everything else failed, so you'll need Tahoma from wine installation.
I think you're right, it's true that we shouldn't actually fix theproblem by modifying the code in this way.
Q1: why values are dumped as hex() in your reg file
I don't know why the value was converted to hex(). I just used the"export registry" function provided by regedit and my registry was automatically converted to that.
Ok, it's probably because it's MULTI_SZ, and not just SZ.
Incidentally, I found that I can edit the registry contents in"wine.inf.in", but what should I do when the key value is Chinese?
When I type Chinese directly in the "wine.inf.in" file according to therules, the corresponding key value in the registry generates garbled code.
Q2: what does it have to do with Noto Sans fonts.
Since the registry value was changed to hex(), I am using a screenshotto show what my registry actually looks like for your convenience. Image URL: https://imgse.com/i/x1ZM8g
I don't know what could be a problem with this list. If you don't remove anything from wine/fonts (and you shouldn't), Tahoma replacement won't take any effect, at least in dwrite. Because replacements are used after collection is built, and only if name wasn't already added.
———————————— By the way, I would like to ask if there is any information that can help me understand the dwrite code better.
I can only suggest to read through parts you're interested in.
I look forward to hearing from you. Yours: SvenL