October 2022 - Wine-Bugs - list.winehq.org

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 --- Comment #10 from 399989567(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 6, 2022

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 --- Comment #9 from Nikolay Sivov <bunglehead(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 6, 2022

[Bug 53762] RtlpWaitForCriticalSection wait timed out in thread

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53762 Ashwinkumar Metpalli <AM185352(a)ncr.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |AM185352(a)ncr.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022

[Bug 53762] New: RtlpWaitForCriticalSection wait timed out in thread

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53762 Bug ID: 53762 Summary: RtlpWaitForCriticalSection wait timed out in thread Product: Wine Version: 2.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: AM185352(a)ncr.com Distribution: --- Created attachment 73238 --> https://bugs.winehq.org/attachment.cgi?id=73238 Crossover boot exec log and version information One of our proprietary applications (hence cannot share the code) is reporting the below in Crossover bootexe logs: 63533.367:00be:00e4:err:ntdll:RtlpWaitForCriticalSection section 0x1b7e668 "?" wait timed out in thread 00e4, blocked by 00e5, retrying (60 sec) The above error continues to repeat in intervals until the system is restarted. The occurrence is sporadic in nature - sometime these errors start right after the reboot and sometimes during a session. If you look at the attached crossover-bootexec.log-20220928-0000.bak file and search for "wait timed out in thread" and find all occurrences in this document (like using Notepad++), you can see all such occurrences and all do correspond to the same process SigmaGenericManager.exe (the one with 35 threads), there are other processes with the same name but they load different binaries and has nothing to do with this process. 000000be 35 \_ 'SigmaGenericManager.exe' It's always this process that runs into this issue once in a while but cannot be reproduced on demand. We recently updated Wine on the customer's platform but not 100% sure that these did not occur before the update. The versions of the software can be found in the attached panther2-versioninfo.log where we can see the below: Wine Version: wine-2.8-8453-g900a9b9c476 Crossover Version: VERSION="2.7.4 (warrior)" BUILD_ID="20220519101904" BUILD_VERSION="2.1.6" Linux Version: Linux panther1 4.19.237-intel-pk-standard #1 SMP PREEMPT Thu May 19 10:49:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux So we would like to know what is causing this and how to troubleshoot this further. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 --- Comment #8 from 399989567(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 --- Comment #7 from Nikolay Sivov <bunglehead(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 --- Comment #6 from 399989567(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal --- Comment #5 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 --- Comment #4 from 399989567(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022

[Bug 53739] Text does not show in QQ UI, possible issue with Fonts/Replacements

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53739 --- Comment #3 from 399989567(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Oct. 5, 2022