LINUX中文环境

LINUX中文环境

一、预备知识---基本概念

  在 UNIX 的世界中，形成了「程序国际化」与「数据本土化」的标准，程序代码只要写过一遍，就可以适用于所有的语文与编码系统，只要系统有支持该语文与编码系统所需的「本土数据」即可。即采取的概念就是「程序」与「数据」分离并分开维护的方式。

「程序国际化」简称 I18N，其意为 InternationalizatioN 一字中头尾字母 "I" 与"N" 中间夹 18 个英文字母，故名。它是在系统底层的函式库 (即 libc 函式库) 中实作一组标准的函式接口，可以让程序存取该地区语系的种种信息。有了这些信息，程序本身不仅可以不需要修改，就足以处理各国的语文，同时程序本身甚至连各地区语文的各项细节 (如编码方式 .... 等) 都不需要知道，因为这些全部都是由系统函式库提供的。

「资料本土化」简称 L10N，其意为 LocalizatioN 一字中头尾字母 "L" 与 "N" 中间夹 10 个英文字母，故名。它是将地区语文的各项细节数据分门别类，安装在系统底层的数据库中，以便让系统函式库存取，以提供给上头的应用程序使用。这些用来描述各地区语文的数据，我们称之为「地区环境数据库 (locale)」，或简称「地区环境」它们包括以下的类别 (categories):

1. LC_COLLATE: 该地区文字排序规则，以及正规化表示式 (regular expression)的比对依据。
2. LC_CTYPE: 该地区所使用的编码系统、字集、与文字分类、转换等信息。
3. LC_MESSAGES: 各应用程序区域化的讯息显示。
4. LC_MONETARY: 该地区所通行的货币格式。
5. LC_NUMERIC: 该地区所通行的数字表示格式。
6. LC_TIME: 该地区所通行的时间、日期表示格式。
·对于同一个地区语文而言，除了 LC_MESSAGES 之外，其它所有的类别都是固定的，故这些类别的数据就只需准备一份即可，它们是由系统底层函式库直接提供，可以让所有的应用程序分享。至于 LC_MESSAGES 讯息显示的部分，由于各应用程序的讯息都不同，故这部分的数据是由应用程序自身提供，而不像其它类别一样由系统函式库提供。
·在这些类别中，决定一个程序是否在该地区已「本土」化的最重要因素，一是 LC_CTYPE，二是 LC_MESSAGES。前者赋与程序处理该地区文字的能力，后者赋与程序用该地区的语文来显示的能力。
·在实际中，将程序所有的讯息集中放在一个文件档中，而该文件文件的讯息开始时只会用程序原作者惯用的语言来表示。如果希望该程序也能显示其它语文的讯息时，我们只需要去做翻译的工作即可，而不必真的去修改程序代码本身。因此，讯息翻译与程序维护可以分头进行，翻译的工作不需要由程序原作者、或有经验的程式设计师来做，只需他熟悉该语文，并对该程序有一定的熟悉度即可。故基本上，任何人都可以参与翻译的工作。当程序编译安装完成后，已翻译成各国语文的讯息文件也会一并安装入系统的区域化数据库中。当程序启动，需要做讯息显示时，它会呼叫系统提供的函式介面，依目前的语系设定来正确抓取该语文的讯息并显示出来。万一目前的语系设定找不到相对应的讯息翻译文件时，则程序会自动以其原始的语系来显示。

地区环境数据库名称和语系设定
各地区所属的地区环境数据库名称格式如下:
_[.]
其中 [.] 有时候会省略。以我们台湾地区所使用的为例:
zh_CN.UTF-8其意即为「中文语系」(zh)「中国」(CN)「使用UTF-8编码系统」。如果将后头的 [.] 省略掉，就是这个样子
zh_CN

·如果我们不特别做语系的设定，则程序在启动时，会以系统预设的语系来运作，一般而言其地区环境数据库名就是 "C" 或 "POSIX"，也就是原始 C 语言所采用的编码系统 (ASCII) 与英文讯息等等。如果希望改变程序运作的语系，则我们必须在程序启动前先做好环境语系的设定，也就是设好各类别的环境变量。例如:
LC_CTYPE=zh_CN.UTF-8; export LC_CTYPE
LC_MESSAGES=zh_CN.UTF-8; export LC_MESSAGES
·假如希望程序可以处理 EUC-TW 的文字，但仍以 Big5 中文显示讯息时，就这样设定:
LC_CTYPE=zh_TW.euctw; export LC_CTYPE
LC_MESSAGES=zh_TW.Big5; export LC_MESSAGES

·在多数情况下，通常会希望一口气将所有的类别设定成相同的语系，也就是让我们的整体环境全部处于同一个语系下。当然我们可以用上述的方式一个个类别分别设定，但除此之外系统还提供了另外两个环境变量，以方便我们的作业。一是 LANG，另一个是 LC_ALL。例如我们这样设:
LC_ALL=zh_CN.UTF-8; export LC_ALL
其效果就完全等价于将所有的类别全部设定了。而 LANG 的用法也是一样，所达到的效果也类似，但意义稍有不同，这里要留意优先级的差别。一般系统对这些环境变数的优先级是:LC_ALL > LC_* > LANG
·也就是说，任何一个 LC_ 类的变量设定后，会使 LANG 的设定的相对应类别失效。如果我们完全不设任何的 LC_ 类的环境变量，只单单这么设
LANG=zh_CN.UTF-8; export LANG
则所有的类别都会以 LANG 的设定来运作，除非我们特别去设了某个 LC_ 的环境变数，如此这个类别就会以新的设定来运作 (但其它的类别不变)。相似的道理，如果我们设了 LC_ALL 的环境变量，则所有的类别设定，包括 LANG 的设定全部会失效，而改以 LC_ALL 的设定来运作。

二、linux环境下的解决方法

GNU/Linux 的 I18N 环境的发展，到了glibc-2.2 系列正式问世后，才算完全成熟。它不仅完全支持 Unicode 环境，同时在 I18N 与 L10N 方面还拥有许多先进的特色述如下:

1. glibc 内部的编码转换系统 (iconv) 拥有共同的「基底字集」，该基底字集采用 UCS4 编码，目前仍持续扩编当中，理论上将可以函盖世界上所有已知的编码系统的转换对应。透过基底字集，可以达到完善的转码机制。同时，由于在各语系下其多字节编码转成宽字符时，其实就是转成 UCS4，这在将来 Unicode通行时，将有利于数据的处理。
2. glibc 内部拥有数量庞大的编码转换表，大部分是各编码系统与 UCS4 的转换用，也有一些是用于不同编码间直接转换。所有的转换表皆采动态模块加载的方式供应用程序使用，故只有在需要时系统才会自动加载所需的转换表来执行，使用完毕后可以卸下，不会浪费内存空间。
3. glibc 拥有完整的 I18N 过程调用接口，以及完整的 Unicode 输出入与处理的呼叫接口。
4. 在地区环境方面，glibc 将「字集」与「编码」的概念分开。一个地区环境资料库有一个明确的字集，代表这个地区语文可能会使用到的所有文字符号，而这个字集可以自由选择一个编码系统来套用。例如我们台湾地区的字集包含所有的中文字 (简繁体都有)，如果我们选用 Big5 编码，则地区环境数据库名称就是 zh_TW.Big5；若我们选用 EUC-TW 编码，则名称就是 zh_TW.euctw；当然我们甚至可以选用 GB2312 或 Unicode 等编码来套用。
·然而，由于各编码所能包含的字数是固定的，同时它们也只能包含特定的字集，因此，仅管我们的中文字集包含了所有的中文字，但一旦选定编码系统后，其所能使用的中文字自然仅限于该编码系统所包含的范围。因此，假如我们选用Big5，就表示在此环境下无法使用简体字；反之若选用GB2312 亦然。
5. glibc 中各地区环境预设的编码系统与传统的 UNIX 系统稍有不同。所谓的「预设编码系统」指的是在 "_" 这样的地区环境数据库名称中，所采用的编码系统。传统的 UNIX 系统中所采用的预设编码系统多半是依照官方或业界的标准，例如在台湾地区就是 EUC-TW。而在 glibc 中，则是以当地最广泛流通的编码系统做为预设。
·更进一步地，glibc 会自动将未登录的编码系统名称，改以其地区环境的预设编码系统来取代。例如我们将语系环境设定为 zh_TW.euctw，由于 "euctw"在 glibc 内部已有登录，故它就会采用 EUC-TW 做为此环境下的编码系统。万一我们将语系环境设定为 zh_TW.unknown，由于 "unknown" 一字没有登录，故glibc 会自动以 zh_TW 预设的编码系统 Big5 来取代。
6. 在讯息显示方面，各应用程序的讯息翻译只需依各语文地区分别保留一份即可，不需要分别为不同的编码系统都保留一份。以台湾地区中文为例，我们只需要一份 zh_TW 的讯息即可，至于它是用 Big5 写成的，或 EUC-TW 写成的都没关系。假如它原来是以 Big5 写成的，但我们却希望以 EUC-TW 来显示时，glibc会自动为我们做好转码的工作。
·也许有人会问，那我们只需要保留一份 zh (即中文) 的讯息就好了嘛，这样岂不是两岸三地都可使用了？然而这么做并不恰当，原因是两岸三地因历史背景与文化的隔阂，各自发展成独特的语文，或称「地区性方言」，对同一个句子的翻译，可能两岸三地的翻法都各自不同。故我们不能单纯用转码的方式，直接将台湾地区的翻译转成简体字供对岸使用，而必须为他们分别保留一份他们自己的讯息翻译。
7. 在讯息翻译的维护工作，以及系统函式的呼叫接口上，各 UNIX 系统的实作方式都不尽相同。而在 glibc (或所有的 GNU 系统、程序) 中，则统一使用 GNUgettext，以方便程序撰写以及后续的翻译维护。
8. 在地区环境数据库中，除了上述那几个传统的类别之外，新一代的 glibc-2.2还扩增了以下的类别:
LC_PAPER,
LC_NAME,
LC_ADDRESS,
LC_TELEPHONE,
LC_MEASUREMENT,
LC_IDENTIFICATION
这些是根据 ISO/IEC JTC1/SC22/WG20 N690 (1999/06) 的新规范而来，用以描述更多的地区性惯例，如住址格式、电话号码格式、抬头称位 .... 等等。

三、Xwindow国际化环境 (Xi18n)

·X Window 系统所面临的课题也是在于文字处理与讯息显示这两大方面。就讯息显示方面而言，过去在 libc 的 I18N 与 L10N 标准尚未确立前，曾一度使用资源档 (X Resources) 来存放讯息的翻译，此方式普及率不高。现在有了 I18N 与 L10N，只要使用 LC_MESSAGES类别，就能达到所需的目标。
·但在文字处理方面就复杂许多，主要是文字的输出与输入两方面。在图形接口中，不同的文字需要不同的字形来显示，故为了要完整显示一个地区所有的文字符号，往往需要同时使用许多不同的字型才能达成。故在 X Window 的地区环境定义中就多了一个字型集 (FontSet) 的定义。以我们的 zh_TW.Big5 地区环境为例，在使用 XFree86的 X Window 系统中 (包括 GNU/Linux)，我们的字型集就包括了一个 ISO8859-1 的字型，以及一个 BIG5-0 的字型，分别用于显示英文与 Big5 中文。但在其它使用非XFree86 的 UNIX 系统中，其字型集的定义则各有不同。
·有了字型集的定义，X Window 系统就会依据 libc 的 LC_CTYPE 编码辨识与分析机制，自动从字型集中挑选适当的字型来显示各个文字。因此， X Window 的应用程序同样也不需要知道各语文的编码细节，使用字型集就能自动完整地显示出该语文中所有的文字符号。因而程序可以国际化。

四、中文输入法

1. 纯文字模式下的中文输入：
·一般而言，文字模式下的输入法并没有特殊的规范或协议，程序所要做的，只有取得使用者的字键输入，再将中文输出到「标准输出 (standard out)」管道，系统自然会将这些文字喂入应用程序中。只要应用程序能够接受并处理 8位字符码，则不会有任何问题。

2. X Window 下的中文输入:
2.1. XIM 协定:
·在 X Window 的图形接口底下，由于各程序间的交互作用是以「窗口」为单位，它们可以藉由标准的 X 协议达到彼此间的沟通，故我们自然而然地可以将中文终端机程序与输入法本身分开发展（输入与输出是两个独立的应用程序，可以通过X协议来传递数据），而不再需要像纯文字模式下将二者绑在一起 (在早期确有将二者绑在一起的解决方案，如 cxterm，它是直接自 XWindow 的标准终端机程序 xterm 修改而来)，如此在一个图形桌面上只需执行一个中文输入法，就可以对许多中文终端机程序提供中文输入的服务，不但节省系统资源，同时模块化的开发模式也让后续维护工作容易得多。
·然而，在 X Window 下的输入法所面临的问题却比纯文字下要复杂许多。由于考虑到程序国际化等方面的问题，故 X Window 定义了一组标准的输入法协议，称之为 XIM (X Input Method) 协定。此协议是架构在程序国际化 (I18N) 与系统的地区环境 (locale) 之上的，故只要遵守此协议，则应用程序就可以在不需修改程序代码的原则下，接受来自各种语系输入法程序的文字输入。
·与纯文字输入方式不同的是，在这里输入法程序不预先拦截使用者的字键输入。而应用程序与输入法程序之间的关系，就好像客户端与伺服端一样，应用程序提出输入请求，则输入法程序提供输入服务。因此，当我们对一个窗口做中文输入时，实际上敲入的字键是直接送往应用程序本身，而应用程序在处理它之前，会先经由 XIM 协议将这些字键序列送往输入法程序，然后由输入法程序那边取得中文字。故在此协议下，应用程序又称之为 ``XIM client''，而输入法程序又称之为 ``XIM server''。

·在一个 ``X Window 的显示设备 (display)'' 中 (这里意指一个屏幕、一个键盘，再加一个鼠标，也就是一个 X Window 终端桌上环境)，可以同时执行好几个 XIM server，它们可以输出不同语系的文字 (例如有的可以用来打中文，有的可以打日文)，或其中有几个可以输出相同语系的文字。而 XIM client 要选那一个 XIM server 来使用，必须透过以下两个环境变量的设定:
export LC_CTYPE=
export XMODIFIERS="@im={XIM server 名称}"
其中前者指定了语系环境，后者指定了要用那一个输入法程序。所有的 XIM client在启动之前必须先有上述的环境变量设定，启动后才能接受该 XIM server 的输入。

·一般 XIM server 所显示的信息可以分成以下三类:

A. 组字信息: 显示于 XIM server 组字的过程中。
B. 状态信息: 显示 XIM server 目前的状态。
C. 其它辅助信息: 例如菜单选单或在线文件说明等。
其中依组字与状态信息显示的位置不同，就形成了各种操作接口 (input style)，
·供使用者方便使用。其中包括:
A. Root: 此信息显示在 XIM server 的主窗口内。
B. OverTheSpot: XIM server 会在 XIM client 的输入光标附近开启一个小窗口，以显示组字信息。如此使用者在打字过程中眼睛就不需老看XIM server 主窗口组字信息。
C. OffTheSpot: XIM client 会在自己的窗口中开出一块区域，让 XIM server来显示其组字信息。此区域通常是在 XIM client 窗口的底下。
D. OnTheSpot: XIM server 提供必要的数据给 XIM client，让它用自己的方法来画 XIM server 的组字信息。这通常是给有特别需求的 XIMclient 选用。
·其中 Root 模式是最简单的方式，一般而言所有的 XIM server 与 XIM client都会支持，至于其它的模式则不一定。必须 XIM server 与 XIM client 都同时支持的模式才使用。如二者同时支持几种模式，当二者开始连系，准备让使用者输入时，它们就会先协调，以挑选最佳模式用。很多时候使用者可以在 XIM client 这指定要使用那一种模式。

2.2. XCIN (X Chinese INput method):

A. 支持 BIG5, BIG5HKSCS, 与 GB2312 等多种编码方式。使用时只要在不同的地区环境 (LC_CTYPE) 下启动它，即可自动采用该语系的编码来做输入。
B. 支持动态外挂式输入模块，让我们可以依需要开发不同的输入法模块，以支持不同的输入法。
C. 支持多种输入法。
D. 支持 Xi18n, XIM 协议与 Root 和 OverTheSpot 输入模式。
E. 拥有丰富多样使用者自定选项。
F. 可以跨平台编译执行，其中包括 GNU/Linux, FreeBSD 与 HP-UX。
2.3. Chinput
·这是一个针对 GB 编码与大陆地区使用者习惯而设计的中文输入法，它是以 cxterm 为基础发展出来的。它同样支持 XIM 协议，与 XCIN 相较，它具备较佳的拼音输入功能，有较好的图形操作接口，同时也支持 GB、Big5、JIS(一种日文的编码) 与 KS (一种韩文的编码) 等编码方式，以及许多常见的输入法表格和方便的输入功能，是一支相当优秀的中文输入法程序。

五、中文输出

·在 UNIX 世界中，长久以来已不乏排版与打印的工具，例如功能强大的幕后排版系统 TeX/LaTeX，用以预览、显示、以及打印的文件图形化语言 Postscript，以及在自由软件世界中常见的 Postscript解译器 Ghostscript 及其附带的打印机与其它外围装置的驱动程序 .... 等等。
·然而，要让这些排版与打印工具可以处理中文却是一项难题，主要是在于文字的编码方式以及字型方面。就以中文为例，由于在一般的计算机装置 (如打印机) 或计算机软件并不内建数量庞大而且笔画复杂的中文字型，故当我们要做中文输出时，必须要有特别的处理方式。例如我们希望在印一份纯文字的中文文件，我不能直接将它送交纯文字打印机去打印，因为这些打印机多半认不得中文编码，也没有字型可用，故它最多只能将送来 的中文编码拆成一个个连续的 ASCII 或 ISO8859-1的编码，再用其内建的 ASCII 或 ISO8859-1 字型印出来，结果就是印出一连串的乱码。
·为了解决此问题，通常当我们要做打印时，不论是印已编排好的文件或纯文字，我们多半要做如下的处理: 辨认出文件内的所有文字，中文字的部分就去找适当的字型，将代表该字的字型 (或说该字的「图案」) 画在该文件内，最后处理完后原本的文件(或文字文件) 就成为一个「图形文件」，最后才将该「图形文件」送印。因此，在很多情况下，印一篇中文的文本文件，其实是印一份内嵌了中文字型的图形档案。图形文件的格式有许多种，但在自由软件的世界中，其最终输出的格式通常是 Postscript。

图形输出格式: Postscript 与 PDF
·Postscript 是早年 Adobe 公司与apple公司所合作开发的一种描述式语言。之所以用 Postscript 做为最终的送印图档格式，主要是因为它有很好的可移植性 (因为它在一般人或程序看来只是纯文字文件，而不是二进制文件)，而且其语法有很高的弹性与延展性，使得我们可以轻易将图案缩放而不至于失真。同时，Postscript 也是业界文件输出格式的重要标准，早期有许多学术论文与排版印刷工作的最终输出都是 Postscript，甚至有许多打印机直接就可以读懂 Postscript, 故它们可以直接打印 Postscript 的文件，而不需要额外的驱动程序。
·Ghostscript 软件。它是一个可以读懂 Postscript 语言的解译器，更重要的是它内含许多驱动程序，可以将 Postscript 文件转换成各种形式输出，包括许多打印机的驱动程序，使得这些不懂 Postscript 语言的打印机得以顺利打印文件。除此之外，Ghostscript 还有 X Window 的绘图模块，可以让 ghostview、gv 等程序在 X Window的环境下显示 Postscript 的文件；它还有可以将 Postscript 转换成其它图档格式(jpeg, png, tiff, ....)、甚至可以送交传真的 faxg3 格式 .... 等等 (因此，当我们要用 modem 传真文件时，我们可以先将该文件的 Postscript 档案准备好，经由Ghostscript 程序转换后送出)。故 Ghostscript 可以说是一个功能相当强大的Postscript 转换引擎。
·由于 Postscript 只是一种图档格式而已，我们很难直接编写、修改 Postscript 的文件，也无法轻易在 Postscript 文件中搜寻文字，更难以用鼠标剪贴的方式将 Postscript 文件中的文字剪贴到别的窗口中。为了弥补这些缺点，故近年来 Adobe 公司又另外发展了一套称为 PDF 的文件。它同样包含了Postscript 所有的优点 (然而它是个二进制文件，而非纯文字文件，这一点与 Postscript格式不同)，也弥补了 Postscript 的不足，其中包括:
1. 由于 PDF 的文件有压缩过之故，使得它的大小比起相同的 Postscript文件要小得多。
2. 在 PDF 浏览器 (如 xpdf) 中显示 PDF 文件时，速度比起用 Postscript浏览器 (如 gv) 来显示 Postscript 要加快不少。
3. 用 PDF 编辑器可以很容易地直接修改 PDF 文件，也可以直接将 PDF文件中的文字直接剪贴到别的窗口中。
4. PDF 文件还支持索引、hyper-reference、及 bookmark (目录) 的功能。
·由于这些优点，故在这一两年来它的普级率迅速上升，许多原本采用 Postscript 的学术文件也逐渐改采 PDF 了，连近年来新版的 Ghostscript 软件也能读懂 PDF 的格式。 然而在自由软件世界中，现阶段 PDF 仍然不是最终输出的格式，特别是在印表方面， 很多时候仍然要先转换成 Postscript 之后才能送印，而许多绘图程序的打印输出也多还是 Postscript 而非 PDF，我想还需要一段时间才会有完整的支持。

中文字型的转换与内嵌

·不论是 Postscript 文件或 PDF 文件，都可以直接内嵌所需的字型，可以只提示所需的字型名称与每个字在字型文件中的编码索引等。后者的档案大小当然比前者来得小，但前提是文件内所使用的字型名与字型规格要有一个通用的标准，如此该份文件才能在各种环境下阅读与打印。故一般只包含 ASCII 或 ISO8859-1 文字的 Postscript文件是不内嵌字型的，但是一份中文文件在目前常见的情况下是必须内嵌字型的，其原因正是目前还没有通用的中文字型与规格。

·在早期 (也许 PDF 格式尚未问世的时候)，用做内嵌的中文字型来源是一种名为 HBF的点阵字型，当时有许多程序可以将 HBF 字型转换成 Postscript 可以使用的格式，然而这类的点阵字型分辨率有限，故内嵌在 Postscript 文件中往往不够美观，特别是当我们要做有限度的文字缩放时更是惨不忍睹。后来，由于 TrueType 字型逐渐普及，同时可以处理 TrueType 字型的引擎 -- freetype 函式库的问世，许多基于该函式库的 TrueType 字型转换程序一一开发出来，使得它成为 Postscript 与 PDF 内嵌字型的最重要来源。内嵌了 TrueType 转换字型的文件不但比起过去要美观许多，且由于 TrueType 本身就具有可缩放的特性，故我们可以轻易产生高分辨率的转换字型，使得文件在有限度的缩放下仍不失真。同时由于文鼎公司对自由软件世界的支持，捐赠了两套 TrueType 中文字型供大家自由使用，让我们在中文文件输出问题上得以彻底解决。

·最佳的解决方案仍然是希望以不需内嵌中文字型的方式，其优点除了可以让输出的文件档变小以外， 同时还可以保证在任何尺度上的缩放而不失真。由于内嵌在文件中的字型在很多情况下是将 TrueType 字型转成点阵字型之后，才进行内嵌 (例如在 CJK-LaTeX 所编译的文件中内嵌了由 TrueType 转成 PK 的点阵字)。仅管由转换过来的字型有相当高的分辨率，但再高的分辨率也是有限的，故在做大尺度的缩放时仍然会失真。要做到真正不内嵌中文字型于文件中，有许多工作要做，其中包括:
1. 要有一套统一的字型名称与规格: 这可能是最令人头疼的部分，因为这里卡到了授权问题。由于 Postscript 与 PDF 文件格式是 Adobe 公司开发的，故其所用的字型名称都会灌上 Adobe 之名，而这些名称是否能在自由软件世界中，以自由软件的游戏规则来运行，将会是个问题，其中尤以 PDF 最为严重。同时，在定这些名称与规格时，我们不能关起门来自己定，必须同时与许多团体谈，可能包括 Adobe 公司、TeX/LaTeX 开发团队、Ghostscript 开发团队、甚至其他与排版、字型相关的计划与 商业公司等。
2. 要有一个字型的来源: 这一点在现阶段已有初步成果，目前我们已有将 TrueType字型转换成 Postscript 所需的 Type1 字型的工具程序，例如 ttf2pt1 或 chpfb,ttf2pfb 等。除此之外，另外还有一套称为 t1lib 的函式库，可以用来进一步处理 Type1 字型，例如将字缩放、旋转，或将它转换成点阵的格式以用于其它的用途 .... 等等。
3. 如果我们有了 Type1 的字型，我们还可以进一步地将它合成 Type0 的 CID-Keyed字型，可用于 Postscript 与 PDF 的文件中。
4. 我们的文件转换引擎: Ghostscript 要能处理多字节编码、并利用这些字型:这一点目前也正积极开发中，例如下一代的 Ghostscript 就有处理多字节编码的能力，除了迎接未来的中文 Type1 字型以外，它还内含了一个可直接使用TrueType 字型的模块，可以做到不需要字型的内嵌，就可以使用 TrueType 字型来显示文件，其原 理是将 TrueType 字型仿真成 Type0 CID-Keyed 字型来用。但这可能会面临可移植性 的问题，万一将此文件拿到其它没有安装此 TrueType字型的系统下就无法读了。因 此，它目前也同时在开发直接内嵌 TrueType 字型的技术，做为因应此问题的配套措施。

中文 Postscript 与 PDF 文件的产生
·目前较通用的纯文字文件转 Postscript 格式的程序为由 python 语言所写成的 bg5ps程序，它所产生的 Postscript 文件采内嵌中文字型的方式，而中文字型的来源即为TrueType 字型。

CJK-LaTeX
· 是一套功能相当强大的幕后排版系统，它使用类似程序语言的方式，来格式化并编排文件，并配合 Postscript 的输出，可以轻易达到高品质文件的输出要求。特别是它容易处理数学符号的特性，使得它特别适于学术文件、书籍、出版的排版工作。要让 LaTeX 能处理中文，必须在 LaTeX 系统上额外加装一套 CJK-LaTeX 的宏。顾名思议，此宏可以付与 LaTeX 处理中文、日文、韩文等编码系统的能力，而它也渐渐成为 LaTeX 的标准之一。而它最后在产生 Postscript 文件时，是采用内嵌中文字型的方式，其字型来源也是 TrueType。它利用 freetype 函式库的衍生工具 ttf2tfm、ttf2pk 将 TrueType 字型转换成 TFM 与 PK 点阵字型，前者用于前段的排版工作，后者则用于最后的字型内嵌。
LaTeX 的外衣 -- LyX
LyX 是一个以 LaTeX 为基底的一个图形化排版系统，让我们不必须记一大堆 LaTeX的排版指令，可以直接可视化地在窗口内编排我们的文件，而最后的排版输出才交由LaTeX 处理。它的中文支持目前正慢慢发展中，包括支持 XIM 协议，使得我们可以用 XIM server 输入法程序直接在它的窗口内打中文。而它的 CJK-LaTeX 指令的部分在经过少许的修正后也能正确地搭配使用。

各应用程序与打印系统的整合

·如前所述，由于 Ghostscript 可以正确处理 Postscript 与 PDF 的文件，并且可以将它们转换成各种格式输出，包括许多打印机的打印格式。故使用 Ghostscript 正是最标准且一致的打印解决方案。除了上述可以产生 Postscript/PDF 文件的程序以外，事实上还有许多与文书工作相关的应用程序，如办公室软件 KOffice/AbiWord 等，或绘图软件 gimp、xfig、gnuplot .... 等，它们在做打印输出时都可以产生 Postscript的格式 (未来也许会有 PDF 格式)，故只要经过适当的整合，就能顺利 解决打印的问题。

小结：中文化环境包括中文console、Xwindow、打印、输入等相关主题，为了达到让代码适应多数的语言环境与编码系统，采用程序与数据分离的策略，用「程序国际化」 I18N与「资料本土化」L10N2种标准来实现。其中本地化包括区域、时间、货币、数字、编码系统及应用程序自身区域化显示信息。实际操作中会涉及到字体的安装，系统、用户以及应用程序的环境变量的特定设置，以此支持中文工作环境。