wineconsole: Remove the character-width check as we need newer FreeType library.

[Eric Pouech]

Le 15/12/2011 17:18, Akihiro Sagawa a écrit :
> On Wed, 14 Dec 2011 19:35:34 +0100, Eric Pouech wrote:
>> this doesn't solve the printing issue as the always infer that any char has
>> the same size
>> how is this printed on real windows with your character set ?
> See the attachment, please. It was taken in my Windows 7 PC with
> Japanese Terminal font. Most of Japanese characters take up the double
> width of the ASCII characters. For example, the first Japanese character
> (KATAKANA LETTER DO, U+30C9) is as same width as `:¥' (=two halfwidth
> characters).
>
> Unicode Standard Annex #11, East Asian Width (*), may help understanding
> East Asian character width.
> * ... http://www.unicode.org/reports/tr11/
>
> In the document, some characters are defined as ambiguous. And its
> recommendation is that ambiguous characters always map to fullwidth
> characters when mapping Unicode to East Asian legacy characters.
>
> But actually it depends on locales or encodings. For instance, as shown
> in the bottom echo line in the snapshot, U+E1 (LATIN SMALL LETTER A WITH
> ACUTE) is halfwidth and U+B1 (PLUS-MINUS SIGN) is fullwidth in Japanese
> environment.
>
> In my humble opinion, printing issue is not good especially for users.
> But, as far as I know, it doesn't occur in ASCII characters. And it is
> better than showing the error message, "Couldn't find a decent font,
> aborting," at starting up.
>
>
>
as pointed out in 
http://blogs.msdn.com/b/buckh/archive/2005/09/11/463427.aspx#2250089
those Japanese characters need to be stored in two adjacent "cells" in 
the console infrastructure code...

your patch will actually print them on top of two cells, while it's 
going to be stored only in one...
it would then lead to making all the output (and internal encoding) be wrong

A+

-- 
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20111218/09d7df89/attachment.html>