linux汉化大全.doc_第1页
linux汉化大全.doc_第2页
linux汉化大全.doc_第3页
linux汉化大全.doc_第4页
linux汉化大全.doc_第5页
已阅读5页,还剩27页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

linux汉化大全(一)Linux的中文输入概述:汉字输入上, GB 与 Big5 的输入由于历史与习惯的原因, 已截然分化成两种, 这就是在大陆最流行的Chinput 和 在台湾最流行的 XCIN, 它们都经历了自定义协议阶段, 目的是配合外挂式中文平台, 最终向国际化标准协议靠拢, 即支持XIM协议(日语输入软件kinput2也经历了漫长的过程). 在中文平台TL-ZWinPro下使用Chinput, 它的XIM协议和原来的协议能够无缝接合使用.目前Chinput已成为大陆最流行的Linux中文输入软件. 它被众多的Linux中文平台所采用:TurboLinux 中文版6.0,Xteam Linux 3.2,BluePoint Linux 2.0ZhXWin: 由宫敏博士开发的Linux下的中文平台Chinput 以CXterm的输入引擎为基础, 支持中文GB/GBK/Big5, 日文和韩文输入. 后又增添了李振春先生的智能拼音输入, 使输入法日臻完备. 它具有独特的无边界窗口, 浏览输入模式, 单双行输入模式, 颜色字体可配置性. 如果配合中文平台 TL-ZWinPro, 它可以根据窗口当前的编码自动输入GB/GBK/Big5.极大地方便了中文用户的网上冲浪, 如浏览网页时的输入,上BBS时输入, 都有可能需要同时输入GB和Big5编码, 这时您不必要重新启动Chinput, 便可以输入这两种不同的编码.XIM 协议Chinput 对X11R6的国际化输入提供了标准接口, 即XIM接口. Chinput 所使用的Locale是zh_CN, 定义的输入服务器名称是Chinput, 所以 在客户程序找不到 Chinput 时, 应设置XMODIFIERS为im=Chinput.XIM 的输入风格(preedittype)共有四种: on the spot, over the spot, off the spot, root window, on the spot 是在Client软件的当前 输入处输入, over the spot 是在当前输入处之上有一预编辑窗口提供 输入, off the spot 是在输入窗口的下方提供预编辑取和输入状态显示 区, root window 是在独立于输入软件的窗口中(该窗口为根窗口的子 窗口)输入. 可以看出, root window 是比较适合汉字输入的. Chinput 目前只支持根窗口输入风格(root-window style). 如果有必要, 其它的输入风格也将被陆续加入.XIM 支持与原协议无缝结合, 对用户来说是不透明的. 当用户在中文平台上使用XIM支持的软件时,原协议对该应用软件自动失效. 这要求中文平台需要作特殊处理, 才能避免两种协议的冲突.支持软件(运行前设置LC_ALL=zh_CN.EUC, LANG=zh_CN.EUC)nxterm, 修改源码. 中文显示需中文平台支持xemacs, 编译:configure -with-xim=xlibrxvt2.60, 编译:configure -enable-xim -enable-gb, 运行: rxvt -im Chinput -pt Rootnetscape: 需改动Netscape.ad, 部份输入区有问题:Netscape*fontList: -*-helvetica-bold-r-*-*-*-140-*-*-*-*-iso8859-*;-*-gb13000.1993-1:vim 资源文件 .gvimrc(.vimrc):set fileencoding=prc:set guifontset=-sony-fixed-medium-r-normal-16-120-100-100-c-80-iso8859-1,-tlc-song-medium-r-normal-*-16-*-*-*-*-*-gb13000.1993-1qt-1.44(i18n patched)/KDE: setenv XMODIFIERS im=Chinputgtk/gnome: 设置 fontsetgimp: 须修改资源文件Motif: 设置 fontset一,Linux下的中文终端Linux 下现在用户可以有许多中文终端可用, 比如 CXterm, rxvt, kvt, 即使是普通的 xterm, 在中文平台下也可以成为中文终端. 在这些中文终端之中, 最好用的当属 CXterm.CXterm 自带中文输入方法, 当然在中文平台下也可以使用中文平台所带的输入方法. 比如在TurboLinux下使用Chinput中的智能拼音是最好的选择. 此外, 除了支持GB外, CXterm还可以支持中文Big5 编码, 日语EUC编码和韩语EUC编码(尽管实际上使用它作日韩语终端 的人比较少).CXterm 是上BBS的最佳选择之一, 它也可以用来和 jvim一起编辑汉字文件.rxvt 也是支持中/日/韩双字节编码的终端, 它与CXterm不同的是, rxvt本身不带输入部分, 但它支持XIM输入或在中文平台上使用.cce也非常好用,不象union还需要重新编译内核.大家可从网上下载cxterm或cce的rpm包安装即可.unicon 3.0.2当然有它的好处,如支持中文目录,文件名显示.二,安装中文字库方案一:安装中文TrueType字体XFree86 4.x可以比较好的支持TrueType字体。TrueType字体可以无级缩放,显示效果非点阵字体可比。为了达到Microsoft Windows那样的漂亮字体效果,我们可以安装中文TrueType字体。最简单的方法就是直接使用Windows下的中文字体。注意:Windows的TTF字体是Microsoft公司的商业软件,这里使用它主要是用于学习和教育目的,不可非法使用。mkdir /usr/share/fonts/default/TrueTypecp /mnt/c/windows/fonts/simsun.ttf /usr/share/fonts/default/TrueTypecd /usr/share/fonts/default/TrueTypettmkfdir fonts.dir因为ttmkfdir对Windows字体的编码识别有问题,因此需要手动修改一下。编辑fonts.dir文件,将simsun.ttf -misc-SimSun-medium-r-normal-0-0-0-0-p-0-ascii-0修改为simsun.ttf -misc-SimSun-medium-r-normal-0-0-0-0-p-0-gb2312.1980-0然后设置可缩放字体cp fonts.dir fonts.scale设置编码文件cp /usr/X11R6/lib/X11/fonts/encodings/encodings.dir .因为我们修改了字体名称,所以不能再用xfs了,必须指定字体路径。编辑/etc/X11/XF86Config-4文件,将默认的xfs部分注释起来,再加上所需要的字体路径,如下所示:(#表示注释行,以下同)Section Files# FontPath unix/:7100FontPath /usr/X11R6/lib/X11/fonts/misc:unscaledFontPath /usr/X11R6/lib/X11/fonts/75dpi:unscaledFontPath /usr/X11R6/lib/X11/fonts/miscFontPath /usr/X11R6/lib/X11/fonts/Type1FontPath /usr/X11R6/lib/X11/fonts/SpeedoFontPath /usr/X11R6/lib/X11/fonts/75dpiFontPath /usr/share/fonts/default/Type1FontPath /usr/share/fonts/default/TrueType (关键)EndSection还有在该文件的Modules部分,请加上xtt模块,同时必须取消freetype模块,两模块不可同时使用。例如:Section ModuleLoad GLcoreLoad dbe# Load driLoad extmodLoad glxLoad pex5Load recordLoad xieLoad v4l# Load freetypeLoad xtt (关键)Load type1Load speedoEndSection运行/etc/rc.d/init.d/xfs stop再运行/usr/sbin/setup,取消xfs在启动时的加载。方案二:我喜欢简单,所以直接用bluepoint linux 2.0的一些rpm包rpm -Uhv bluepoint-release-2.0-1BP.noarch.rpmrpm -Uhv XFree86-zhfont-3.3.5-1.i386.rpm需要这些软件的人可到/engineer/hubertzou/下载。关闭xfs,修改/etc/X11/XF86Config-4:Section Files# FontPath unix/:7100FontPath /usr/X11R6/lib/X11/fonts/misc:unscaledFontPath /usr/X11R6/lib/X11/fonts/75dpi:unscaledFontPath /usr/share/zhfont/X11/FontPath /usr/X11R6/lib/X11/fonts/chinese/FontPath /usr/X11R6/lib/X11/fonts/misc/FontPath /usr/X11R6/lib/X11/fonts/75dpi/EndSection相关问题:有网友说在XFree864.0.2下可以不关闭XFS因为某此程序如 realplayer只认默认的 fixed 字体.关掉XFS会出错说找不到字体.我也试过了,其实在XFree 86 4.0.1里面也可以不用关。只要在/etc/X11/XF86Config-4里面加上TrueType字体的路径就可以了。这样写:Section FilesFontPath unix/:7100FontPath /usr/share/fonts/default/TrueTypeEndSection这是就不要动xfs相关的部分了。在XFree86窗口系统中实现对GB18030的支持(二)本文是在 XFree86 窗口系统中实现对 GB18030 的支持的第二篇,将具体介绍如何在XFree86中实现对 GB18030的支持。1 在 libX11 中实现 GB18030 编码转换模块前面已经介绍了在 XFree86 中支持一种文字编码的关键是在 libX11 中实现支持这种编码的一系列转换模块。 但是由于 GB18030 是单双四字节混和编码, 所以和其它常用的单双字节编码相比, 处理起来比较麻烦。 下面就简要介绍一下在 libX11 中实现 GB18030 编码转换函数的原理。 大家可以参考 XFree86 的源码和相关文档, 以便更好的理解以下内容。1.1 如何将 GB18030 编码成 Compound Text看过 Compound Text 文档, 大家就会知道它的最初用途是用来承载单字节或双字节编码的, 并不适合承载编码 GB18030 这样的多字节可变长度编码。其实 Compound Text 所能够承载的编码并不是通常意义的文本编码(encoding),而是字符集编码(CharSet encoding)。而 XFree86 系统最多仅支持双字节宽度的字符集编码。要想用 Compound Text 承载 GB18030 编码的文本, 就必须先把 GB18030 转换成 Compound Text 所支持的编码。 目前可行的有以下两种方案:1. 方案一、将 GB18030 拆分成两个双字节编码首先需要注意的是 GB18030 编码中 0x00x7F 范围的单字节部分用 Compound Text 编码后就变成了 ISO8859-1:GL (GL 表示左半部分编码, 即 ISO8859-1 的七位码部分), 所以在拆分 GB18030 编码的时候, 这部分是不计入内的。拆分 GB18030 的最直接的办法就是把其双字节部分作为一个独立的编码, 然后把四字节部分再编码成双字节, 成为另一个独立的编码。这样我们就可以将 GB18030 文本分解成一个单字节部分, 和两个双字节部分编码成 Compound Text 了。 GB18030 的双字节部分其实基本就是原来的 GBK 双字节编码部分, 它们之间仅有几十个码位的区别。 也就是说我们可以象处理 GBK 编码那样处理 GB18030 的双字节部分。 下面的任务就是处理四字节部分了。将 GB18030 四字节部分编码成双字节最简单的办法就是把这部分编码从第一个码开始按顺序重新编码, 重新编码后 GB18030 的第一个四字节码 0x81308130 就变成了 0。 依次类推, 我们可以将 GB18030 四字节编码中与 Unicode 3.0 (即 ISO10646 第一平面) 相对应的部分编码成双字节。 但由于这种编码方式最多只能有 65536 个码位, 所以我们不可能将 GB18030 中与 Unicode 3.1 对应的所有码位都编成双字节码。 这也是这种编码方案最大的不足。 另外还有一种办法就是直接将 GB18030 四字节编码转换成对应的 UCS2 编码, 同样可以实现以上目的。在实际实现时, 我们并没有使用将 GB18030 拆分成两个双字节编码的方案。 因为这种方案实现起来过于复杂, 而且还具有无法向 Unicode 3.1 标准过渡等问题。 实际使用的是下面一种方案。2. 方案二、将 GB18030 编码成 UTF-8前面已经介绍过,为了使 XFree86 平稳的从 Compound Text 过渡到 UTF-8,已经在标准的 Compound Text 中加入了一个特殊的模式用来编码 UTF-8文本。在 XFree86 中 Compound Text 编码转换函数会对这种编码模式做特别处理,以便能够正确转换编码在 Compound Text 中的 UTF-8 文本。详细细节请参见 XFree86 的源码(xc/lib/X11/lcCT.c)。另外前面也介绍过,GB18030 在字汇上和 Unicode 3.0 标准是一一对应的,在码位上也给 Unicode 3.1 标准预留了足够的空间。也就是说,GB18030 编码和 Unicode 3.1 编码是一一对应关系,它们之间可以做双向转换而不损失任何信息。所以我们完全可以将 GB18030 编码的文本先转换成 UTF-8 编码,然后再转换成 Compound Text,而不丢失任何信息,反之亦然。由于 libX11 中已经提供了通用的函数完成 CharSet encoding 与 Compound Text 之间的转换,并且支持 UTF-8 编码。所以我?侵恍枰峁? GB18030 UTF-8 的转换函数,就可以利用 libX11 的间接编码转换功能实现 GB18030 Compound Text 的相互转换。这一过程对于应用程序来说是完全透明的,只要应用程序使用 libX11 所提供的标准的 Compound Text 处理函数,就可以正确无误的处理 GB18030 编码。目前常用的应用?绦蚩猓? gtk+、QT 等都是这样做的。但不幸的是有少数应用软件是自己处理 Compound Text 的,如 emacs 和 xemacs。所以这种方案不能应用于这类软件。另外,gtk+ 从 1.2.9 开始便引入了一个错误,它在处理 Compound Text 文本时画蛇添足的做了一下过滤,把 0x800xFF 之间的一些控制字符过滤掉了,就破坏了编码成 UTF-8 的 Compound Text 文本。在最新发布的 TurboLinux 7.0 中已经修正了这个错误。至此,将 GB18030 编码成 Compound Text 的问题已经解决了。接下来就要解决 GB18030 与其它编码之间的转换问题,以及显示的问题了。1.2 GB18030 与其它编码之间的相互转换以上介绍了如何将 GB18030 编码成 Compound Text 的问题,解决了这个问题后我们就可以在 GB18030 Locale 下运行的两个应用程序之间利用 Compound Text 交换数据了。但这还远远不够。目前最常用的中文编码是 GB2312 和 GBK,台湾和香港地区常用的则是 BIG5 和 BIG5-HKSCS。GB18030 作为最新的汉字编码标准其实已经涵盖了前面这几种编码标准的绝大部分字汇,是名副其实的超集。因此,在使用传统中文编码的应用程序和使用 GB18030 的应用程序之间交换数据,是一个非常有用的功能。至少需要实现从传统编码程序到 GB18030 程序的单向数据传输。因此我们必须在 libX11 中实现把 GB2312、GBK、BIG5 等编码转换成 GB18030 编码的功能。更广泛的讲,GB18030 标准已经具备表示所有 Unicode 3.0 甚至 Unicode 3.1 字汇的能力,也就是说 GB18030 可以编码各国文字。所以将非中文编码转换成 GB18030 编码也是有意义的,尤其是日文和韩文。要想实现从各种传统编码向 GB18030 编码转换可以借助于 glibc 的 iconv 模块,但这种方法的最大缺陷就是效率太低。幸运的是,在 libX11 中已经包含了许多常用字符集编码和 UCS4 之间的转换函数(参见 xc/lib/X11/lcUTF8.c 和 xc/lib/X11/lcUniConv/*)。所以我们可以利用这些函数通过 UCS4 编码做中介,实现 GB18030 和这些传统编码之间的转换。1.3 GB18030 编码字符串的显示前面已经提到,XFree86 仅支持双字节的字符集编码,所以直接用 GB18030 编码做字符集编码进行字符串显示是不行的。因此我们需要将 GB18030 编码的字符串先转换成多段单字节或双字节编码的字符串,然后才能送去显示。这个问题的解决办法其实已经在 1.1 节中提到了。对于第一个方案,我们已经把 GB18030 编码的字符串分解为一个单字节编码部分和两个双字节编码部分,因此可以直接送去显示。单字节部分就是 ISO8859-1 编码,可以使用 ISO8859-1 编码的英文字库进行显示;双字节部分则需要中文字库的支持。在现有的应用软件中,mozilla 其实就是使用这种方法来显示 GB18030 文本的。mozilla 使用了 1.1 中所述的第一种方法编码 GB18030 文本,并将 GBK 兼容的双字节编码部分称做 gb18030.2000-0,将原四字节编码部分称做 gb18030.2000-1。因为 mozilla 不使用字符集来显示字符串,它使用自己的一套处理机制来完成类似于字符集的功能,因此只要 XFree86 支持这两种编码的字库,mozilla 就可以正确显示 GB18030 文本了。关于在 XFree86 中支持这两种字库的问题,我们将在后面介绍。对于第二个方案,就更简单了。我们只需要用一个 iso10646-1 (UCS2-BE) 编码的 GB18030 中文字库就可以完成字符串的显示工作。而且现在所有符合 GB18030 标准的 TrueType 字库都使用了 Unicode (UCS2-BE) 编码作为字库索引,XFree86 的 xtt/freetype 字库模块可以直接访问这种字库而不用做任何编码转换。但是由于中文 TrueType 字库包含的字模数目太大,在 XFree86 中用变宽模式使用这种字库,速度太慢。所以我们只能用固定宽度的字符元(Char Cell)模式来使用中文字库,由此导致的直接后果就是所有英文字符变成全宽的了,效果非常难看。解决这个问题的方法其实很简单,即使用字符集。将 GB18030 编码文本中 0x00x7F 的部分分离出来,使用半宽的英文字库进行显示。其余部分仍然使用中文字库进行显示。在实践中发现,由于 GB18030 还覆盖了 Unicode 中 0x800xFF 之间的编码,即 ISO8859-1 的右半部分。而这部分也是半宽的,所以同样不能使用中文字库进行显示。因此这部分也需要被分离出来使用英文字库进行显示。TrueType 字库在显示低点阵字符的时候效果比较差,目前又没有可用的 GB18030 点阵字库,所以在实际应用中我们还把 GB18030 中常用的 GB2312 部分编码分离了出来单独用 GB2312 字库来显示,这样在低点阵的时候我们就可以用 GB2312 编码的点阵字库来显示这部分汉字,以获得比较好的显示效果。1.4 实现 GB18030 编码转换模块上面说了两种显示办法都需要将 GB18030 编码的字符串切割成多段单字节或双字节字符集编码的字符串才能调用相应的字库进行显示。好在 libX11 库中已经提供了一套现成的函数来完成类似的工作,这就是 libX11 中的 lcUTF8.c 模块。这个模块不仅实现了一整套传统字符集编码与UTF-8编码和UCS4编码之间的转换函数,还提供了将 Unicode 编码的字符串切分并转换成多段单、双字节字符集编码的函数。这个模块使用静态的转换码表来实现 Unicode 编码和传统字符集编码之间的转换。与使用 glibc 的 iconv 模块相比它的速?雀欤艺加玫哪诖娓。蛭? XFree86 软件仅在内存中共享一套转换码表。前面已经介绍过,GB18030 编码和 Unicode 编码在字汇上有一一对应的关系,因此它和 UTF-8 编码也同样存在一一对应关系。而 lcUTF8.c 模块所提供的功能正是我们的 GB18030 编码转换模块所需要的。所以很自然的就可以想到我们可以在 lcUTF8.c 的基础上实现 GB18030 编码转换模块。实际上我们并没有编写独立的 GB18030 模块,而是在 lcUTF8.c 中直接实现了对 GB18030 的支持。这样做的好处是不言而喻的。我们仅在 lcUTF8.c 中增加了几百行代码就解决了上面讲到的所有问题。参照 lcUTF8.c 对 UTF-8 编码的处理方法,我们只需完成 GB18030UCS4 的相互转换工作就行了。GB18030Compound Text,GB18030CharSet encoding 等转换函数其实就是先将 GB18030 转换为 UCS4 然后在转换成 Compound Text 或 CharSet encoding。而 UCS4Compound Text,UCS4CharSet encoding 等转换函数和 lcUTF8.c 中原有的函数没有任何区别,可以共享同样的代码。因此关键问题就是如何实现 GB18030UCS4 的转换。解决这个问题的最直接的方法其实就是使用 glibc 的编码转换模块。由于使用 GB18030 编码的 X 应用软件都会将 Locale 设置为 GB18030,所以我们可以在 libX11 中直接使用 mbtowc 和 wctomb 两个函数在 libX11 中实现 GB18030 多字节字符和宽字节字符之间的转换。而且 glibc 中 wchar_t 使用的正是 UCS4 编码。由于 GB18030 是无状态编码,所以在 libX11 中使用 mbtowc 和 wctomb 是线程安全的。在此仅列出 CharSet encoding 到 GB18030 编码(也就是 MultiByte 编码)的转换函数以供参考:/* from XlcNCharSet to XlcNMultiByte */static inticonv_cstombs(conv, from, from_left, to, to_left, args, num_args)XlcConv conv;XPointer *from;int *from_left;XPointer *to;int *to_left;XPointer *args;int num_args;XlcCharSet charset;char *name;Utf8Conv convptr;int i;unsigned char const *src;unsigned char const *srcend;unsigned char *dst;unsigned char *dstend;int unconv_num;if (from = NULL | *from = NULL)return 0;if (num_args encoding_name;/* not charset-name because the latter has a :GL/:GR suffix */for (convptr = all_charsets, i = all_charsets_count-1; i 0; convptr+, i-)if (!strcmp(convptr-name, name)break;if (i = 0)return -1;src = (unsigned char const *) *from;srcend = src + *from_left;dst = (unsigned char *) *to;dstend = dst + *to_left;unconv_num = 0;?hile (src UCS4 编码转换函数将 CharSet 编码字符转换成 UCS4 编码 */consumed = convptr-cstowc(conv, &wc, src, srcend-src);if (consumed = RET_ILSEQ)return -1;if (consumed = RET_TOOFEW(0)break;/* 调用 glibc 中的 wctomb 函数将 UCS4 字符转换成 GB18030 多字节字符 */count = wctomb(dst, wc);if (count = 0)break;if (count = -1) count = wctomb(dst, BAD_WCHAR);if (count = 0)break;unconv_num+;src += consumed;dst += count;*from = (XPointer) src;*from_left = srcend - src;*to = (XPointer) dst;*to_left = dstend - dst;return unconv_num;另外,lcUTF8.c 中原先是没有 GBKUCS4 和 BIG5-HKSCSUCS4 转换模块的,我们参照 xc/lib/X11/lcUniConv 目录中其它转换模块的格式为 lcUTF8.c 增加了这两个模块。至此,我们就在 libX11 中实现了 GB18030 的编码转换模块,XFree86 的 GB18030 内功已经修炼完成,下面就要开始修炼 Locale 描述文件、字库接口等外功了。2 GB18030 Locale 的 XLC_LOCALE 文件*nix 系统中编写国际化程序的关键就是底层 libc 库对 locale 的支持。每一种语言编码和国家地域都对应一个 locale,其中提供了编码转换信息、日期货币格式、字符排序规则等信息。同样,要想让 XFree86 支持一个 locale,就必须有一个相应的 XLC_LOCALE 文件,其中描述了这种 locale 使用的文字编码、所有字符集编码以及字体集等信息。GB18030 locale 对应的 XLC_LOCALE 文件内容如下:# XFree86 NLS for Chinese encoding GB18030# Modified from xc/nls/XLC_LOCALE/en_US.UTF-8# by James Su# XLC_FONTSET category#XLC_FONTSETon_demand_loading Trueobject_name generic# We leave the legacy encodings in for the moment, because we dont# have that many ISO10646 fonts yet.# 以下定义了 GB18030 locale 使用的所有字库和对应的字符集编码# 字体集 fs0, fs1 对应单字节部分的 0x00x7F 和 0x800xFF# fs0 class (7 bit ASCII)fs0 charset name ISO8859-1:GLfont primary ISO8859-1:GLvertical_rotate all# fs1 class (ISO8859 families)fs1 charset name ISO8859-1:GRfont primary ISO8859-1:GR# 字符集 fs2, fs3 对应其它部分# fs2 class (Chinese Han Character)fs2 charset name GB2312.1980-0:GLfont primary GB2312.1980-0:GL# fs3 classfs3 charset name ISO10646-1font primary GB18030-0substitute GBK2K-0END XLC_FONTSET# XLC_XLOCALE category#XLC_XLOCALEencoding_name GB18030mb_cur_max 4state_depend_encoding False# 下面定义的是 GB18030 locale 使用的所有字符集的信息# cs0 classcs0 side GL:Defaultlength 1ct_encoding ISO8859-1:GL# cs1 classcs1 side GR:Defaultlength 1ct_encoding ISO8859-1:GR# cs2 classcs2 side GRlength 2ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR# cs3 classcs3 side nonect_encoding ISO10646-1END XLC_XLOCALE注意字符集 fs2 的定义,字符集编码使用的是 ISO10646-1,也就是 UCS2-BE,而字体是 GB18030-0。其实 GB18030-0 只是我们在 xtt 字库模块中增加的一个 ISO10646-1 的别名而已,目的是将 GB18030 字库与其它 ISO10646-1 字库区别开来。字符集定义 cs0 cs3 与字体集 fs0 fs3 并没有直接的联系,它们的定义是独立的。定义 cs0 cs3 的用途是告诉 libX11,在将 GB18030 字符串编码成 Compound Text 前先拆分成使用 ISO8859-1:GL,ISO8859-1:GR,GB2312.1980-0 以及 UTF-8 等不同字符集编码的四段字符串,然后在编码成一个 Compound Text 数据流。这样做的好处是,我们可以从 GB18030 locale 的应用程序向 GB2312 locale 的应用程序传输英文字符和 GB2312 中文字符;或向英文 locale 的应用程序传输纯 ASCII 码数据。现在 XFree86 支持 GB18030 的工作已经基本完成,最后就差在 xtt 字体模块中添加对 gb18030-0 以及 gb18030.2000-0 和 gb18030.2000-1 的支持了。3 改造 xtt 模块XFree86 中包含了两个常用的 TrueType 字体模块,xtt 和 freetype。相对而言,freetype 模块使用标准码表来实现对各种字符集编码的支持,改造起来相对简单些。但由于性能以及功能较 xtt 弱,所以人们常用 xtt 模块。xtt 模块采用编码转换模块来支持各种编码的字体。所有编码转换模块都被编译成动态库文件,可以在使用的时候动态加载和释放。下面就介绍一下怎样让 xtt 支持上述三种字体。支持 gb18030-0 非常简单,因为它就是 ISO10646-1 (UCS2-BE编码)的一个别名而已。支持 gb18030.2000-0 也比较简单,只需把 xtt 原有的 GBK 模块拿来稍加改造就行了。gb18030.2000-1 就比较复杂了,因为它是 mozilla 专用模块,采用采用顺序编码的方式把 GB18030 的四字节部分重新编码,我们必须建立这种新编码和 UCS2-BE 编码之间的映射表才能编写 gb18030.2000-1 模块。好在 mozilla 的源码中有这张表,只需要转换一下格式就行了。按照 xtt 中其它编码转换模块的格式,我们可以将三种字体的代码写到一个模块中,主程序(main.c)的代码如下:/* =EmacsMode: -*- Mode: C; tab-width:4; c-basic-offset: 4; -*- = */* =FileName: =Copyright (c) 1998 Takuya SHIOZAKI, All Rights reserved.Copyright (c) 1998 X-TrueType Server Project, All rights reserved.(省略注释)Notice=*/#include xttversion.hstatic char const * const releaseID =_XTT_RELEASE_NAME;#include xttcommon.h#include xttcap.h#include xttcconv.h#include xttcconvP.htypedef enumGB18030_0,GB18030_2000_0,GB18030_2000_1 CharSetMagic;static CharSetRelation const charSetRelations = gb18030, 2000, 0, GB18030_2000_0, 0x40, 0xff, 0x81, 0xfe, 0x8140 , gb18030, 2000, 1, GB18030_2000_1, 0x00, 0xff, 0x00, 0x99, 0x0000 , gb18030, NULL, 0, GB18030_0, 0x00, 0xff, 0x00, 0xff, 0x3000 , gbk2k, NULL, 0, GB18030_0, 0x00, 0xff, 0x00, 0xff, 0x3000 , NULL, NULL, NULL, 0, 0, 0, 0, 0, 0 ;CODECONV_TEMPLATE(cc_gb18030_2000_0_to_ucs2);CODECONV_TEMPLATE(cc_gb18030_2000_1_to_ucs2);CODECONV_TEMPLATE(cc_font_gbk2k_to_ucs2);static MapIDRelation const mapIDRelations = GB18030_2000_0, EPlfmISO, EEncISO10646,cc_gb18030_2000_0_to_ucs2, NULL , GB18030_2000_0, EPlfmUnicode, EEncAny,cc_gb18030_2000_0_to_ucs2, NULL , GB18030_2000_0, EPlfmMS, EEncMSUnicode,cc_gb18030_2000_0_to_ucs2, NULL , GB18030_2000_1, EPlfmISO, EEncISO10646,cc_gb18030_2000_1_to_ucs2, NULL , GB18030_2000_1, EPlfmUnicode, EEncAny,cc_gb18030_2000_1_to_ucs2, NULL , GB18030_2000_1, EPlfmMS, EEncMSUnicode,cc_gb18030_2000_1_to_ucs2, NULL , GB18030_0, EPlfmISO, EEncISO1064

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论