Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Dec 2007 12:00:11 GMT
From:      Wei-Hao Syu <whsyu@ntu.edu.tw>
To:        gnome@FreeBSD.org
Subject:   Re: ports/118481: big5-2003 in converters/libiconv
Message-ID:  <200712191200.lBJC0BBY076882@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/118481; it has been noted by GNATS.

From: Wei-Hao Syu <whsyu@ntu.edu.tw>
To: Alexander Nedotsukov <bland@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: ports/118481: big5-2003 in converters/libiconv
Date: Wed, 19 Dec 2007 19:57:48 +0800

 Why we want to replace big5 instead of directly use big5-2003? Because =20=
 
 in some applications you can only choose big5, no options for =20
 big5-2003, you have to hack each of them if you want. Some =20
 applications read locale info to convert texts to original big5, and =20
 again it's not easy to modify each of these program to use big5-2003.
 
 Please note that this hack is an option, and I don't think it should =20
 be enable by default.
 If someone know what he need and don't care about the incompatibility =20=
 
 part of them, then just enable it. Otherwise everything works just as =20=
 
 before.
 
 For the compatibility issue, I think that you are talking about the =20
 0xA140-0xA2CE mapping.
 big5-2003, big5-1984, and cp950 have different mapping in some symbols =20=
 
 at this section.
 (but with almost same look, such as 0xA156 -> U+2013/U+2015)  This =20
 issue is already exist because some big5 data generated by windows =20
 system, we assume it's big5-1984 but actually it is cp950.
 
 I agree with you that we should also ask GNU libiconv team to replace =20=
 
 the original one which comes from obsolete unicode 1.1 table. (another =20=
 
 issue of this one: big5-1984 does not define katakana/hiragana, but =20
 this table has an incorrect one in it.)
 
 On 2007/12/17, at =A4U=A4=C8 1:37, Alexander Nedotsukov wrote:
 
 > I understand the difference. My question was more about why you can =20=
 
 > not use BIG5-2003 when it appropriate? The point is BIG5 in its =20
 > original form is not a subset of BIG5-2003. There are code points =20
 > defined differently. So what you asking for is technically illegal. =20=
 
 > However if this is an *official* way you do it in Taiwan (which will =20=
 
 > be really weird case) please convince GNU libiconv developers to =20
 > switchover.
 >
 > Wei-Hao Syu wrote:
 >> because of katakana and hiragana.
 >>
 >> The major difference between big5-2003/big5-1984 is big5-2003 has =20
 >> katakana and hiragana mapping ( from big5-eten). big5-2003 is part =20=
 
 >> of official standard in Taiwan and most Taiwanese have the =20
 >> requirement (katakana, hiragana support) when using ftp/bbs with =20
 >> big5 encoding, that is why we need this one.
 >>
 >> On Thu, 13 Dec 2007 11:25:35 +0900 , Alexander Nedotsukov =
 <bland@FreeBSD.org=20
 >> > wrote:
 >>> Could you explain why you need this hack and what is more =20
 >>> important how it will interact with other variants of BIG5 family, =20=
 
 >>> please? I can see that this silent switchover may lead to =20
 >>> incompatibility between hacked and clean systems which is not good =20=
 
 >>> thing IMHO. In any case I strictly recommend you to put pressure =20
 >>> on GNU libiconv developers to resolve issue at the right place.
 >>>
 >>
 >>
 >
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712191200.lBJC0BBY076882>