https://bugs.winehq.org/show_bug.cgi?id=53739
Bug ID: 53739 Summary: [font cannot show in QQ ]When using the font replacement function in the registry, some fonts cannot be displayed, which affects normal use, and even makes the response speed of some functions of the application slow. Product: Wine Version: 7.16 Hardware: x86 OS: other Status: UNCONFIRMED Severity: major Priority: P2 Component: dwrite Assignee: wine-bugs@winehq.org Reporter: 399989567@qq.com
Created attachment 73181 --> https://bugs.winehq.org/attachment.cgi?id=73181 replacement.reg -> the registry file I modified fontwrong.log -> log of errors that occurred
My English is not good, so I hope to be forgiven if there are any poor wordings.
First of all, I appreciate your help and I will describe my problem in three aspects.
[ Background of the problem ] By using wine,I know that most of the font problems can be solved by installing “allfonts” ect through winetricks,but I noticed that most of the fonts are not open source. So I want to use all open source fonts to display text in wine by my own effort, such as NotoSans. My ability does not support me to modify the source code directly, so I mainly used the “Fonts\Replacements” function in the registry provided by wine to do the replacement of missing\not open source fonts. Most of the fonts displayed well after I made the replacements, but some fonts had rendering problems, and these problems even affected the use of the application. Through my own research I found that all the changes I made to the registry did not cause problems in wine 7.12, but in wine 7.18 they did. By dichotomy, I found that the cause of the problem is the modification of the file "dwrite", but I don't know where the problem occurs, so I'm asking for advice.
[My actions] The changes I made to the registry are in the file "replacement.reg", which you can import directly from "./wine regedit." I also deleted the fonts in . /wine/fonts file, because I want to display all text in open source fonts. In addition to changing the Fonts\Replacements in the registry and . /wine/fonts file, I did not do any other things. And I found that in my above operation, QQ can display all the text normally in 7.12, but not in 7.18. [File description] replacement.reg -> the registry file I modified fontwrong.log -> log of errors that occurred My model: ThinkPad-X1-Debian-11.4.0-amd64-KDE
I sincerely hope to get a reply, if you don't have time, you can simply point me in the right direction, I'm also working on it now, hopefully we can make wine better together
Yours: SvenL
QQ downloardURL:https://im.qq.com/download QQ Version:9.6.7
https://bugs.winehq.org/show_bug.cgi?id=53739
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- Ideally, it will be great to see bisect result - specific commit that causes problems for you. The process is described here https://wiki.winehq.org/Regression_Testing.
One of the recent changes to dwrite was an addition of fallback font list. That list does use various Noto Sans fonts.
Are you sure QQ is using dwrite in a first place? WINEDEBUG=+dwrite will show it.
https://bugs.winehq.org/show_bug.cgi?id=53739
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[font cannot show in QQ |Text does not show in QQ |]When using the font |UI, possible issue with |replacement function in the |Fonts/Replacements |registry, some fonts cannot | |be displayed, which affects | |normal use, and even makes | |the response speed of some | |functions of the | |application slow. |
https://bugs.winehq.org/show_bug.cgi?id=53739
399989567@qq.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Version|7.16 |7.14
--- Comment #2 from 399989567@qq.com --- First of all, I am honored to receive your reply !!! This is really inspiring to me. At the same time,I apologize for not responding to your message in time. Through regression testing I found that the problem was caused by this commit,
dwrite: Remove old system fallback logic. ID: 26e717c5653d2c6fcb29846e7d22aa97e37048e1
This commit seems to 'Remove old system fallback logic' and I am now looking at why this commit is causing the problem and trying to fix it by myself.
In the meantime,by using WINEDEBUG=-all,+dwrite, I'm sure QQ is using dwrite.
I look forward to hearing from you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #3 from 399989567@qq.com --- Dear Nikolay Sivov: Through my attempts I found that the cause of the problem may be the following: (everything below is based on the commit "26e717c5653d2c6fcb29846e7d22aa97e37048e1")
'''bash $ git reset 26e717c5653d2c6fcb29846e7d22aa97e37048e1 '''
In "dwrite/analyzer.c", there is a problem with the "fallback_map_characters" function, where the problem occurs as follows:
'''C 2246: data = fallback->data.count == ~0u ? &system_fallback : &fallback->data; '''
When I force "data = fallback->data;" the problem is solved.
So I guess there might be a problem with the assignment of "system_fallback" or with data.count, and I'm still looking into the cause of the problem.
For now, it seems that the brute force solution is to force "data = &fallback->data;", but a more elegant solution is yet to be thought of.
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #4 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #1)
Ideally, it will be great to see bisect result - specific commit that causes problems for you. The process is described here https://wiki.winehq.org/Regression_Testing.
One of the recent changes to dwrite was an addition of fallback font list. That list does use various Noto Sans fonts.
Are you sure QQ is using dwrite in a first place? WINEDEBUG=+dwrite will show it.
Dear Nikolay Sivov: Through my attempts I found that the cause of the problem may be the following: (everything below is based on the commit "26e717c5653d2c6fcb29846e7d22aa97e37048e1")
'''bash $ git reset 26e717c5653d2c6fcb29846e7d22aa97e37048e1 '''
In "dwrite/analyzer.c", there is a problem with the "fallback_map_characters" function, where the problem occurs as follows:
'''C 2246: data = fallback->data.count == ~0u ? &system_fallback : &fallback->data; '''
When I force "data = fallback->data;" the problem is solved.
So I guess there might be a problem with the assignment of "system_fallback" or with data.count, and I'm still looking into the cause of the problem.
For now, it seems that the brute force solution is to force "data = &fallback->data;", but a more elegant solution is yet to be thought of.
I look forward to hearing from you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- 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.
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #6 from 399989567@qq.com --- (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 the problem 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.
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 the rules, 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 screenshot to show what my registry actually looks like for your convenience. Image URL: https://imgse.com/i/x1ZM8g ———————————— By the way, I would like to ask if there is any information that can help me understand the dwrite code better.
I look forward to hearing from you.
Yours: SvenL
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 the
problem 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 the
rules, 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 screenshot
to 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
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #8 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #7)
Ok, it's probably because it's MULTI_SZ, and not just SZ.
I think you are right,MULTI_SZ and SZ will produce different results.
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.
I did delete all the fonts in the "./wine/fonts" folder because I don't want to use copyrighted fonts.
You said before " DirectWrite will try to use Tahoma by default, if everything else failed", I would like to ask if you can tell me how this is implemented, is it through the file "dlls/dwrite/layout.c" line 733 ?
I'm thinking if I can modify the default specified font to Noto Sans fonts.
> line 744 in layout.c > if (FAILED(hr = create_matching_font(sys_collection, L "Tahoma", range->weight, range->style,range-> stretch, &IID_IDWriteFont3, (void **)&font))
————————— Incidentally, I found that I can edit the registry contents in "loader/wine.inf.in", but what should I do when the key value is Chinese?
such as: HKCU,Software\Wine\Fonts\Replacements,"Tahoma",0x00010000,"Noto Sans CJK SC"
But when I type Chinese directly in the "wine.inf.in" file according to the rules, the corresponding key value in the registry generates garbled code,instead of the corresponding Chinese.
I really appreciate your help and I wish I knew if there was a way to express my gratitude to you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #9 from Nikolay Sivov bunglehead@gmail.com --- (In reply to 399989567 from comment #8)
(In reply to Nikolay Sivov from comment #7)
Ok, it's probably because it's MULTI_SZ, and not just SZ.
I think you are right,MULTI_SZ and SZ will produce different results.
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.
I did delete all the fonts in the "./wine/fonts" folder because I don't
want to use copyrighted fonts.
Those are free fonts, provided by Wine project.
You said before " DirectWrite will try to use Tahoma by default, if everything else failed", I would like to ask if you can tell me how this is implemented, is it through the file "dlls/dwrite/layout.c" line 733 ?
In current tree it's a function called layout_run_get_last_resort_font().
I'm thinking if I can modify the default specified font to Noto Sans fonts.
> line 744 in layout.c > if (FAILED(hr = create_matching_font(sys_collection, L "Tahoma",
range->weight, range->style,range-> stretch, &IID_IDWriteFont3, (void **)&font))
————————— Incidentally, I found that I can edit the registry contents in "loader/wine.inf.in", but what should I do when the key value is Chinese?
such as: HKCU,Software\Wine\Fonts\Replacements,"Tahoma",0x00010000,"Noto Sans CJK SC"
You can set it up in any way you want, what I'm saying is that Tahoma is our current default font for UI, and for dwrite layout as well, so it's better to leave it be.
But when I type Chinese directly in the "wine.inf.in" file according to
the rules, the corresponding key value in the registry generates garbled code,instead of the corresponding Chinese.
I have no experience with that, sorry.
I really appreciate your help and I wish I knew if there was a way to express my gratitude to you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #10 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #9)
(In reply to 399989567 from comment #8)
(In reply to Nikolay Sivov from comment #7)
Those are free fonts, provided by Wine project.
Thank you very much for your reply, this news helps me a lot.I have a few questions and look forward to receiving your helps.
Q1: You said this is a free font, so I would like to ask if these fonts are commercially available.
Q2: I would like to ask if all the fonts under the "./wine/fonts" file are free fonts, and my judgment that the fonts are copyrighted is only because the font's familyname seems to be Microsoft's copyrighted fonts.Like tahoma, I found out by searching that this is a Microsoft non-commercial font.
In wine, is it only the family name of fonts is the same as the Microsoft non-commercial font,in fact, the internal font is made by our own wine.
Q3:You said "provided by Wine project.", I would like to ask where can I see how these fonts are provided by wine? I am interested in fonts and I would like to know if I can have a chance to be involved in the production of wine fonts, so I would like to know how these "provided by Wine project" fonts are made.You don't need to tell me exactly how it is done, it would be too much work for you. Just tell me which part of the project I should look at.
I'm a beginner in using wine, so I hope you don't mind if my question is stupid.
I look forward to hearing from you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #11 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #9)
Dear Nikolay Sivov:
I followed your advice and didn't delete anything in ./wine/font, but the problem doesn't seem to be fixed.
And I found that "Text does not show in QQ UI" doesn't seem to be caused by my modification. I use wine7.18 (just git pull, config, and make) without any modification, and the problem still exists.
I look forward to hearing from you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com --- I have no idea what's happening. If it doesn't work correctly with clean unmodifed installation - use official wine packages for that, and a new wineprefix - then we could treat this as a new bug. Any local modifications are hard to verify.
Is there a direct download link to the application? Is missing text problem reproducible without a QQ account?
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #13 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #12)
I have no idea what's happening. If it doesn't work correctly with clean unmodifed installation - use official wine packages for that, and a new wineprefix - then we could treat this as a new bug. Any local modifications are hard to verify.
I use the clean unmodifed installation - use official wine packages for that, and a new wineprefix, and I'm sure this problem is still exists.
Is there a direct download link to the application?
download URL:https://dldir1.qq.com/qqfile/qq/PCQQ9.6.7/QQ9.6.7.28815.exe
Is missing text problem reproducible without a QQ account?
Yes, of course. Without account you can reproduce this problem.
Figure 1 below tells you where to click to reproduce the problem.
Figure 1:https://imgse.com/i/xGER56
Figure 2 tells you what the situation with the problem looks like and the situation without the problem.
Figure 2:https://imgse.com/i/xGVVRU
ps:LANG = zh_CN.UTF-8, Language is Chinese
I look forward to hearing from you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #14 from Nikolay Sivov bunglehead@gmail.com --- I don't see the plus sign button, and QR code button hangs the application for me. We'll need someone else, familiar with this application to try to reproduce.
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #15 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #14)
I don't see the plus sign button, and QR code button hangs the application for me. We'll need someone else, familiar with this application to try to reproduce.
The QR code hangs the program (I have encountered this and I am sure the hang problem is caused by dwrite(because When I use my way to let text show in QQ,the hang problem is disappear)),I think you just need to wait a while because the font does not display properly and the program is hang(I don't know why cause caton),so you just need click the QR code and wait for a while,QQ will automatically load a QR code and there is no font display below the QR code,where should have some text.
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #16 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #14)
I don't see the plus sign button, and QR code button hangs the application for me. We'll need someone else, familiar with this application to try to reproduce.
(use plus sign button to find this problem is the quickest way,it will not cause app hangs)
It is precisely because the font does not appear that the program responds slowly (hangs), so I came to ask for your help.
If you don't see the plus sign button, try moving your mouse over the circular penguin icon, which might show the plus sign.
Or I think you can enter the account password at will, and click to log in (note that this will also cause a long period of hangs), and then QQ will prompt you that the account password is wrong, but the text in this prompt also cannot be show in wine.
Hint picture:https://imgse.com/i/xGmQds
moving your mouse over the circular penguin icon:https://imgse.com/i/xGm3iq
I look forward to hearing from you.
Yours: SvenL
https://bugs.winehq.org/show_bug.cgi?id=53739
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #17 from Zeb Figura z.figura12@gmail.com --- (In reply to 399989567 from comment #10)
Q1: You said this is a free font, so I would like to ask if these fonts
are commercially available.
Q2: I would like to ask if all the fonts under the "./wine/fonts" file are free fonts, and my judgment that the fonts are copyrighted is only because the font's familyname seems to be Microsoft's copyrighted fonts.Like tahoma, I found out by searching that this is a Microsoft non-commercial font.
In wine, is it only the family name of fonts is the same as the Microsoft non-commercial font,in fact, the internal font is made by our own wine.
Like the rest of Wine, our fonts are provided under the terms of the GNU Lesser General Public License version 2.1. That fact is actually provided in the font source and binary file, but may be nontrivial to discover. The basic provision of the license is that you can use, modify, and redistribute the fonts, as long as you make those modifications public to anyone you redistribute the fonts to. You can read the license in its entirety here: https://source.winehq.org/git/wine.git/blob/HEAD:/COPYING.LIB
Our fonts have the same name as Microsoft fonts by necessity, because programs expect to open the Microsoft font by name.
Q3:You said "provided by Wine project.", I would like to ask where can I see how these fonts are provided by wine? I am interested in fonts and I would like to know if I can have a chance to be involved in the production of wine fonts, so I would like to know how these "provided by Wine project" fonts are made.You don't need to tell me exactly how it is done, it would be too much work for you. Just tell me which part of the project I should look at.
Our fonts are built using FontForge. The source files are the .sfd files located in the fonts/ directory of the Wine source:
https://source.winehq.org/git/wine.git/tree/HEAD:/fonts
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #18 from 399989567@qq.com --- (In reply to Zeb Figura from comment #17)
Thank you for your reply, if there is any recurrence of this problem, feel free to contact me.
https://bugs.winehq.org/show_bug.cgi?id=53739
--- Comment #19 from 399989567@qq.com --- (In reply to Nikolay Sivov from comment #14)
I don't see the plus sign button, and QR code button hangs the application for me. We'll need someone else, familiar with this application to try to reproduce.
I would like to ask if this issue is still being researched, thanks for the reply
https://bugs.winehq.org/show_bug.cgi?id=53739
399989567@qq.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Text does not show in QQ |Text does not show in QQ UI |UI, possible issue with |and Enterprise WeChat UI, |Fonts/Replacements |with native wine7.18