http://bugs.winehq.org/show_bug.cgi?id=11861
Summary: regedit does not correctly display unicode value data Product: Wine Version: 0.9.56. Platform: Macintosh OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: programs AssignedTo: wine-bugs@winehq.org ReportedBy: thestig@google.com
Created an attachment (id=11149) --> (http://bugs.winehq.org/attachment.cgi?id=11149) screenshot
With my locale set to zh_CN.UTF-8, I ran regedit and set a registry value to "图片" (picture)
It's correctly displayed in the listview, but not in the edit dialog box -- see screenshot. I tested this on Ubuntu Feisty.
http://bugs.winehq.org/show_bug.cgi?id=11861
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|Macintosh |PC
http://bugs.winehq.org/show_bug.cgi?id=11861
Mikolaj Zalewski mikolaj.zalewski@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mikolaj.zalewski@gmail.com
--- Comment #1 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2008-03-06 15:24:07 --- Could you attach the user.reg? Regedit is an ANSI application and can't handle full Unicode but if the string displays right in the listview then it should also display in the edit box. If you use the arrow keys to walk the string, how many characters are there after the last '/'?
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #2 from Lei Zhang thestig@google.com 2008-03-06 17:06:06 --- Created an attachment (id=11160) --> (http://bugs.winehq.org/attachment.cgi?id=11160) user.reg
there's 2 characters after the last '/'.
http://bugs.winehq.org/show_bug.cgi?id=11861
Mikolaj Zalewski mikolaj.zalewski@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|programs |fonts
--- Comment #3 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2008-03-09 16:36:42 --- That's a fonts problems - the edit control passes the correct string to TextOutW (and one can see that the listview uses a different font - that's probably why it works). I don't know if this failes because of a lack of Windows-compatible Chinese fonts in Wine or a bug e.g. in font linking or 'MS Shell Dlg' mapping.
What is definitely a bug is that GetTextExtentPoint32W computes 10 pixels for the ':' replacement character while in fact it's shorter. This is why there is a gap after :: and if one types some recognisable charaters (e.g. 'a') after it then the cursor position will be out-of-sync with the character being edited.
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #4 from Lei Zhang thestig@google.com 2008-03-09 22:50:40 --- In a +font trace, for the listview I see: trace:font:WineEngCreateFontInstance L"MS Shell Dlg", h=-11, it=0, weight=400, PandF=00, charset=0 orient 0 escapement 0
In HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes, MS Shell Dlg is set to Tahoma. The actual font it's using is uming.ttf, from the ttf-arphic-uming Ubuntu package. I'm not sure how Wine decided to use uming.ttf for Tahoma.
and for the edit box, I see: trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0
not sure what font it's using.
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #5 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-10 00:32:39 --- (In reply to comment #4)
In a +font trace, for the listview I see: trace:font:WineEngCreateFontInstance L"MS Shell Dlg", h=-11, it=0, weight=400, PandF=00, charset=0 orient 0 escapement 0 In HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes, MS Shell Dlg is set to Tahoma. The actual font it's using is uming.ttf, from the ttf-arphic-uming Ubuntu package. I'm not sure how Wine decided to use uming.ttf for Tahoma.
That's because of the font linking "magic".
and for the edit box, I see: trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 not sure what font it's using.
It uses built-in bitmap font System, that of course doesn't have any CJK glyphs (just like in Windows). Regedit (or whatever who creates an edit) should not use System font, but an appropriate UI font instead.
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #6 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2008-03-10 04:03:25 --- The string edit dialog declares the font as "MS Shell Dlg" - there should be a WM_SETFONT to the edit control that changes the font to Tahoma.
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #7 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2008-03-29 15:36:07 --- I've looked more into it and: - The difference between the listview and the edit box is that the listview asks for the font with lfCharSet set to GB2312_CHARSET while the editor box uses DEFAULT_CHARSET. For the listview the charset field have precedence over the font name and we get one of the Chinese fonts instead of Tahoma. It seems that for DEFAULT_CHARSET if the font name matches, we get it even if it doesn't support the default charset for the current locale.
- It would still work if we had font linking. On Windows as far as I understand the links to standard fonts like Microsoft Sans Seriff or Tahoma are created by the control panel applet when changing the system locale (the order of preference of fonts is locale dependent). As on Wine the user can change the system locale by changing an environment variable without using an applet or even run two problems at the same time with different system locales we should probably do it dynamically in gdi32.dll
- The invalid characters are displayed as ':' (or '>' on native Tahoma) instead of a square because in WineEngGetOutlineTextMetrics if the tmDefaultChar would be 0 we change it to a magic value of 0x1f. For Tahoma it seems the correct value is 0. It should be easy to test and fix however I don't know if it won't have some side effects for some old fonts? This bug is quite nasty as it makes the return of GetTextExtentPoint32 be different from the size used by TextOut and the cursor in the edit control gets out of sync.
- Also after I copied SimSun from a Windows partition and created a link with RegEdit I had the chinese characters in the edit box but CreateFont("Tahoma", GB2312_CHARSET) wasn't selecting Tahoma - the Latin characters in the listview were drawn using the Chinese font. It looks like a bug but I haven't tested it on Windows.
- Once the font link is set up, it works even for the System font - on Windows as well as on Wine. We have two pieces of code that makes it happen - we link Tahoma and its every link to System and in another place for codepage 932 (Japanese) we link every link of Microsoft Sans Seriff to every non-symbol and non-OEM font. It's possible both are partial implementations of the same mechanism.
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #8 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2008-03-30 09:34:36 --- Created an attachment (id=11742) --> (http://bugs.winehq.org/attachment.cgi?id=11742) patch for the invalid character
The GetTextMetrics are correct, the problem is in GetGlyphIndices - it was tested on a bitmap font (probably due to a bug - it took me a while to notice it) and didn't convert the default character to its glyph index. The attached patch should work for font where the glyph index of char 0x1f is 0. Maybe it would be better to access the OS/2 table directly and use glyph 0 when usDefaultChar is 0.
I see it is not clearly written in the previous comment that the main problem is that the font links are not created automatically (Windows creates them in all locales. There is also a problem to what fonts to link to on Linux).
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #9 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2008-04-02 09:47:57 --- A patch to fix the invalid char glyph got applied to the Wine Git (http://www.winehq.org/pipermail/wine-cvs/2008-April/041978.html) so now they should display correctly correctly as empty squares.
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #10 from Lei Zhang thestig@google.com 2008-04-02 09:59:04 --- Thanks for looking into this Mikolaj!
http://bugs.winehq.org/show_bug.cgi?id=11861
Alexander Nicolaysen Sørnes alex@thehandofagony.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alex@thehandofagony.com
--- Comment #11 from Alexander Nicolaysen Sørnes alex@thehandofagony.com 2008-08-25 16:12:25 --- Is this fixed, then?
http://bugs.winehq.org/show_bug.cgi?id=11861
--- Comment #12 from Austin English austinenglish@gmail.com 2009-02-26 11:16:33 --- Lei, ping.
http://bugs.winehq.org/show_bug.cgi?id=11861
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #13 from Lei Zhang thestig@google.com 2009-02-26 13:07:04 --- Marking this fixed.
http://bugs.winehq.org/show_bug.cgi?id=11861
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org 2009-02-27 16:30:50 --- Closing bugs fixed in 1.1.16.
-
wine-bugs＠winehq.org