[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [cle-devel] Arphic PL fonts and BIG5<->Unicode



陈先生您好!谢谢您在百忙中抽空为我解答问题。 ^_^

On Wed, Dec 15, 1999 at 03:34:13PM +0800, Wan-Chih Chen wrote:
> 
> From: Anthony Fok <foka@ualberta.ca>
> 
> > 一、Big5 码 0xC6A1 至 0xC8FE 一段,为什么文鼎 PL Big5 字型档中对应的
> >      Unicode 码一律是 U+F6B1 - U+F848 <Private Use 字域> ,而不是∶
> 
> 因为 Windows 95 已在系统定义Big5造字区(含 0xC6A1至 0xC8E8FE)与Unicode造字区
> 间的对应, 所以无法将Big5造字区对应到上述的 Unicode 符号区. 在 Linux 上我想是
> 可以不要有这样的限制.

  这个我也想不清楚了,似乎两种方法都有其道理。毕竟,Big5 0xC6A1至0xC8FE
是厂商造字区,对应 U+F6B1 - U+F848 也有道理。我想不通了。  ^_^

> > 二、Euro 币符,全型编为 U+20AC 正确,但另加半型的 Euro 币符 放在
> >      0x80 (U+0080) 原为控制码的的位置,会不会有负面影响?抑或这是
> >      Microsoft Windows 平台上 16-bit 字型加 Euro 币符的业定作法?
> 
> Microsoft Windows 平台上 "8-bit" 字型加 Euro 币符的作法是加在 0x80.
> 但将 Euro 欧元符号放在 U+0080的位置是不太好, 我们已在后续的字型产品里将此码
> 移除.

  如果这在 MS Windows 平台上是 de facto 标准,那末可能保留 U+0080 为
Euro 也没有大碍。  ^_^  (为什么我好像是帮微软说话? ^_^)我的意思是,
如果您认为保留 U+0080 为 Euro 比较好,请把它保留,不要单单为了我的问题
而除掉。  ^_^

> 基本上只要是支援 ASCII charset 的 encoding 皆可以用, 在 ISO8859-x 的标准中,
> 其前 127 字元是相同的.
> 
> >        以上是我的个人见解,不知对否?如果 ETen 3.10 版以后的 Big5
> >      字型的确是华人采用的 de facto standard,我们好不好跟 BIG5.TXT
> >      的作者(及 CJK/Unicode/中国文学专家)John H. Jenkins 井作恒先生
> >      联络,修订 BIG5.TXT 档,并联络 Tcl, glibc2 等更新其转码档?
> >      (John Jenkin's Home Page 在 http://www.blueneptune.com/~tseng/,;
> >      相当有错,不妨一看 ^_^。)
               ^^
(对不起,打错字了。我本来想打「相当有趣」的。  ^_^

> 这是国际性的标准, 恐怕无法说改就改, 不过可以提出建议试试.

  谢谢您的意见。我迟些有空试试问问他们。
同时因为 Unicode 3.0 将增加一些以前 Big5 有但 Unicode 无的字型,
也许他们可以顺便更新 BIG5.TXT,甚或放几个版本的 Big5 转码表来。
(嘻嘻,我大概梦想天开了。 ^_^)

  感谢您详细的解答!  ^_^

					东东

-- 
Anthony Fok Tung-Ling                Civil and Environmental Engineering
foka@ualberta.ca, foka@debian.org    University of Alberta, Canada
anthony_fok@catholic.org             Keep smiling!  *^_^*
Come visit Our Lady of Victory Camp -- http://come.to/olvc


-- 
[ This mail was originally sent to debian-chinese@lists.debian.org and was ]
[ forwarded to this list automatically. Big5 characters are also converted ]
[ to GB at the same time,  Please note that there may be errors during the ]
[ conversion as this is not done by a human!                               ]


Reply to: