[Bug 11861] regedit does not correctly display unicode value data

wine-bugs at winehq.org wine-bugs at winehq.org
Sat Mar 29 15:36:10 CDT 2008


http://bugs.winehq.org/show_bug.cgi?id=11861





--- Comment #7 from Mikolaj Zalewski <mikolaj.zalewski at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.



More information about the wine-bugs mailing list