[Bug 16325] incorrect font rendering for CJK programs

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Jan 31 06:22:51 CST 2012


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

Ma Xiaojun <damage3025 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |damage3025 at gmail.com

--- Comment #112 from Ma Xiaojun <damage3025 at gmail.com> 2012-01-31 06:22:51 CST ---
Dmitry Timoshkov:

I guess your opinions are flawed from the very beginning.

Firstly, requiring the user to setup font links is indeed a bug.

As far as I know, many windows users DO NOT KNOW what (the ****) is font links.
English Windows can run Chinese programs flawlessly if Chinese locale is
selected in Control Panel.

Secondly, locale overriding is an desire feature.

As far as know, some Chinese users enjoy Japanese games. When the Japanese game
displays garbage, Microsoft's AppLocale or Third-party NTLEA. (These may be no
maintenance for NTLEA currently, but to my experience, this one works much
better)

Some terminals, e.g., the Tectia's SSH client (may not be latest version) used
in my university, have poor support for CJK. When Chinese locale is set, you
get messy output in the CLI. And I personally prefer English UI since most
Linux documentation I meet is in English.

So I use en_US.UTF-8 locales for all my machines and accounts. Native Linux
programs can display and input CJK flawlessly, do I have to change locale just
because of wine?

Above all, wine can do better than Windows. I hope wine can support locale
overriding for individual programs one day.

Thirdly, your testing principle is wrong. 

I guess a dirty patch, would fix CJK but break other languages. And what you
are constantly asking is a test case showing the CJK handling difference
between Windows and wine. We cannot do anything, if such test is not yet
discovered, right?

In fact, many Chinese people gave up wine or Linux entirely because of wine's
CJK rendering problem. We are NOT talking about mathematics, mass experience is
indeed a proof.

However, do you have test cases showing wine's current, supposed i18n capacity?
Why don't you use such cases to justify whether a patch is dirty or not? Or you
can just use some more practical non-English non-CJK program to test it. 

If you don't such do tests. I guess you are rejecting others' patch just
because you think you know Windows and wine better than others. May be it is
the case, though.

-- 
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