不鬼啊。
最早的TeX叫做knuthcian TeX,就是knuth老爷爷的那个TeX. knuth老爷爷说，我的TeX很好
，没有bug,大家就不要再修改了，要改，你就不能再叫TeX.从此，TeX就freeze了，不再开
发了，仅仅做bug fix.由于TeX不能满足所有人的需要，就有了一大堆的扩展。
虽然这样，Knuth提供了一个叫做xettex的咚咚，这个东西可以支持从右往左的书写，当然
这个不在标准的TeX当中。
NTS是一帮人改进TeX的一个尝试。该计划的第一个公布的产品叫作e-tex,即extention
tex,该东东提供了一系列的新原语，后来被广泛地使用。LaTeX中的很多效果就是使用它们
写出来的。ConTeXt 几年前就放弃了Knuth TeX,因为缺少这些实用的原语。NTS开发好
e-TeX以后，开始着手beta版的开发。和以前不同，这次使用的是Java语言。不过后来不知
道为什么，NTS的开发就停止了。直到2002年左右，一堆TeX专家，想用Java开发TeX,于是把
半路死掉的NTS捡了起来，搞出了一个叫做ExTeX的东西。不过终归是小打小闹.
然后的一个重要的方向，是多国语言支持和Unicode.这个方向的标志项目，叫做Omega.不过
留了一堆bug以后，Omega也死掉了。Omega的一个重要的后继者叫做Aleph,事实上就是
Omega和e-TeX的结合。
再接下来，一堆人搞出了pdftex,pdftex有两段，保留了原先Knuth的所有代码，可以按照
Knuth TeX那样直接输出dvi,这一部分还是原先的Web语言。另一端，可以直接生成pdf文档
，这时就加入了大量的C代码，通过和C库的连接，就可以处理一些简单的问题，比如插入各
种格式的图片。pdftex在算法上面比较的杰出方面，是HZ特性，可以取得较好的排版效果。
目前pdftex是ConTeXt主力推荐的TeX引擎。
pdftex和etex的结合，产生了pdfetex,而pdftex开发人员后来把etex统统加入了标准的
pdftex,所以现在提供的pdftex 1.40中，etex的扩展是完整的。
在etex的基础上添加Unicode支持，并且连接Mac OS X的各种技术，比如ATT,Quartz,
QuickTime，产生了一个重要的TeX分支，叫做XeTeX.XeTeX在2005/6年陆续发布了它的
Windows和Linux版本，最终集成在TeXLive 2007当中，标志着它被广泛地认可。在XeTeX中
，使用多国语言，变得非常轻松，并且可以方便地使用系统的TrueType和OpenType字体，因
此得到许多TeXGuru的喜爱。
在pdftex的基础上，把tex输出dvi的部分变成了aleph，并且使得输出pdf的部分可以象
aleph那样支持Unicode,并上Lua这个动态语言，产生了LuaTeX.然后，使得Lua可以控制TeX
的一些特性比如载入字体，处理node等，使得TeX具有了原本宏语言所不具有的语言特性，
更加方便编程。另一方面，由于Lua的无限扩展，可以使用系统的库程序，所以也方便TeX和
系统其他程序的连接。目前，LuaTeX已经可以比较好地处理多国语言，并且也可以使用
TrueType和OpenType字体。LuaTeX的下一个目标，是在TeX中嵌入MetaPost，并且把所有的
Web代码清理成C语言，把所有的内容变成独立的模块，使用Lua来连接各个模块。这些工作
预计在2010年完成。
----------我是分割线---------
http://blog.csdn.net/ramacess/archive/2007/08/02/1723279.aspx
Knuth 教授在设计 TeX 系统时，是以支持英文为出发点考虑的，系统规定的文本输入一律采用 ASCII 字符，但是世界上被广泛使用的语言文字不止英文一种，很多语言的基本字符数量远远超出 ASCII 字符集所能表示的范围，比如常用汉字约有 6000 多，而 ASCII 最多能表示 256 个字符。但这并非表示 TeX 不能处理中文字符，事实上，TeX 可以排版这个世界上任何一种语言文字写的文稿。关于 TeX 所处理语言多元化的问题中，真正困扰人们的是选择哪一种方式来实现。
第一种解决方案是对中文 TeX 文稿进行预处理，生成双字节的 ASCII 编码，然 后再实现字符编码与字体图形的映射，之后的过程（排版处理与输出）交给 TeX 系统来处理。在 8 位的ASCII 编码中，如果最高位为 0 ，那么就表示当前字节为一个 ASCII 字符；如果最高位为 1，就表示当前字节与下一字节表示一个汉字。这一预处理过程可以采用 TeX 提供的排版原语来实现，具体体现就是 TeX 宏包。这种方案的优点就是可以不改变 TeX 核心就可实现英文与中文的统一处理。目前，这一方案已经成功实现，几个可以处理中文的 TeX 宏包都是按照这一思路实现的，譬如德国人 Werner Lemberg 写的 CJK 宏包、中科院张林波教授开发的 CCT、华东师大陈志杰教授开发的 TyTeX（天元软件包）。现在的情况是，CCT 和 天元基本上是俱往矣了；而 CJK 由于与 LaTeX 的结合较为紧密，已被大多数中文 TeX 用户所接受。CJK 现在可以支持中文 GBK 、 UTF-8 编码。
第一种方案虽然比较轻省地实现 TeX 中文化、韩文化、日文化等，但是依然难以实现对世界所有语言文字的支持，也就是说难以实现 TeX 的国际化。按照这种解决方案，很有可能一个语种，就要开发一个相应的处理宏包，如果在一份文档中出现多种语言文字时，这些解决方案就不那么灵光了。鉴于目前计算机软件开发中，有一种清晰的潮流，那就是抛弃所有历史上与多字符集相关的编码方案，让应用程序原生的使用 Unicode 编码，这是目前为止以统一编码的方式处理世界所有语言的计算机表示的最佳方案，很多人都希望 TeX 系统也能顺应这种潮流，那就是想法子让 TeX 引擎支持 Unicode 编码。这样一来，就需要对 TeX 引擎进行改造，Omega（Ω） 、LuaTeX、XeTeX 等项目就是做这件事的。
Omega 项目是 John Plaice 与 Yannis Haralambous 开发的 TeX 扩展包，致力于实现 TeX 多语言化。在 Omega 中，每个字符都以一个 16 位编码的数据结构表示，这样就可以摆脱 TeX 的 ASCII 编码限制。Omega 提供了一些编码转换工具及扩展接口，可以将非 Unicode 转换为 16 位 ISO-10646 标准 Unicode 编码。关于 Omerga TeX 系统如何使用，目前资料很少，本文作者未曾使用过，因此无法给出相关优、缺点评说。但是就目前状况，Omega 距离实用，依然遥遥无期。
LuaTeX 可以说是 Omega 的延续,因为它是基于 Aleph 的，Aleph 又是Omega 和 eTeX 的合成品，所以 LuaTeX也具有内部支持 Unicode的能力。但是 LuaTeX 与 Omega 相比还是有很大区别的。譬如 Omega 主要还是基于 TeX 引擎上层的逻辑原语层 (WEB) 开发的，而 LuaTeX 很多模块基于 C/C++ 实现并嵌入到 TeX 引擎中，另外在 TeX 引擎中嵌入了 Lua 脚本编程机制。用户可以使用 Lua脚本对 LuaTeX 进行二次开发，这样用�就可以自由操作以前 TeX 无法做到的事情，比如以前 LaTeX 的上千行的 dirty 代码，基于 LuaTeX 可以更为精简的语句去实现.。 另外，LuaTeX 也被设计为支持本地 TTF、OpenType 字体调用，大大减轻了用户制作 TeX 字体的繁琐任务。不过，据说目前 LuaTeX 的 Bug 很多，经常挂掉。虽然我没有使用过 LuaTeX，但是觉得 LuaTeX 是很有希望的，但是也有很多人认为 LuaTeX 将 TeX 搞的更为复杂。
Lua 是一个扩展式程序设计语言，它被设计成支持通用的过程式编程，并有相关数据描述的设施。 Lua 也能对面向对象编程，函数式编程，数据驱动式编程提供很好的支持。 它可以作为一个强大、轻量的脚本语言，供任何需要的程序使用。 Lua 以一个用 Clean C 写成的库形式提供（所谓 Clean C ，指的 ANSI C 和 C++ 中共通的一个子集）。
XeTeX 原本是 Mac OS 平台上的项目，现在 linux、 Windows 平台都有其移植版本。 XeTeX 所要解决的问题与 LuaTeX 差不多，但前者没有像后者那样提供一种内嵌的脚本语言，而且目前的 XeTeX 已经可以较为稳定地运行了，而LuaTeX 距离实用还比较遥远。不过 XeTeX 的开发者 Jonathan Kew 曾说过，假如 LuaTeX 完善了，他会停止 XeTeX 的开发的。现在，XeTeX 的最新版是 0.996，已经可以支持 UTF-8 编码以及本地 TTF、OpenType 字体调用，用于中文文档处理基本上没有什么问题了。
已经讲了这么多关于 TeX 语言多元化众多的解决方案，总是要比较一下的。我个人的观点是，开发 TeX 外围宏包的解决方案，比如解决中文处理的 CJK 宏包，这种方案只能作为一种临时解决方案。TeX 系统并非传说中的那样完美，那样难以找出 bug，总之是要改进的。在第二种解决方案中，最现实的是 XeTeX 项目，最理想的是 LuaTeX，我们完全可以基于现实并期待理想实现。至于 Omega 项目，貌似已经半死不活，谁也不知道它究竟能否坚持下去。
No comments:
Post a Comment