cat jjgod >> log

Linux System Programming 封面上的图是在一个正在飞行机器上的人。早在莱特兄弟于 1903 年实现他们第一台“重于空气”的可控飞行器以前，世界上的许多人就已经在用简单而精致的机器探寻飞行的奥秘了。在二世纪或三世纪时，就有中国的诸葛亮在孔明灯中飞行的记录，这是第一个热气球。而在六至七世纪，许多中国人尝试将自己绑在大型的风筝上以在空气中飞行。

此外，据说中国还创造了会转动的玩具，它是直升机的早期版本，这个设计可能在莱昂纳多达芬奇对人类飞行进行早期尝试时给予了他灵感，而在 1845 年，他设计了一台扑翼机，一台试图通过展动翅膀载人于空中飞行的机器。尽管他从未将这台机器建造出来，扑翼机的鸟状结构影响了后续几个世纪对飞行器的设计。

绘于本书封面的这台飞行机器要比 James Means 在 1893 的模型飞行器更为精细，多出了螺旋桨。Means 后来给他的飞行器印制了一份使用手册，其中提到“于 Willard 山巅，Crawford 屋畔，觅一良所”来试验这台机器。

不过这类试验通常是很危险的，在十九世纪后期，Otto Lilienthal 建造了一些单翼机、双翼机和滑翔机，他是第一个展示出飞行是在人类可控的范围内的人，也因此获得了“飞行测试之父”的称号：他曾参与超过 2000 次滑翔机飞行，有时单次飞行距离就超过了一千英尺。他在 1896 年死于一次降落事故，在那次事故中他折断了脊椎。

飞行器还被称作机器鸟或飞行船，也偶尔会叫成人造信天翁 (Artificial Albatross) 这样华美的名字。人们对飞行器的热情现在依然高涨，直到今天还有航空爱好者在建造早期的飞行器。

封面图和章节题图来自 Dover Pictorial Archive。封面的字体是 Adobe ITC Garamond。正文字体是 Linotype Birka，标题字体是 Adobe Myriad Condensed，代码字体则是 LucasFont 的 TheSans Mono Condensed。

注：孔明灯的传说里并没有提到诸葛亮借此飞行，当为老外附会。

近来在水木上讨论文档标记语言的优劣，想起前些天查资料时正好又碰到了一个熟悉的名字: Scribe，于是多花了一点时间查找，没想到找到的资料仍然非常稀少。

Scribe，是 Brian Reid 在 Carnegie Mellon 的 Ph.D Thesis，也是对文档格式研究中所绕不开的一个重要的名字 (另一个，当然是 Don Knuth 的 TeX)，这个项目大概在 1976 年开始，1980 年 Reid 发表这篇 Scribe: A Document Specification Language and its Compiler 以后，就甚少有什么改进了，尽管 Reid 的论文中也研究了 Knuth 的工作，但可以认为 Scribe 和 TeX 是同时代的作品。从对后续文档格式的影响说，Scribe 还更大一点，我们熟悉的 SGML (XML 的前身)，BibTeX 都受了 Scribe 的影响。在 1982 年，Reid 还因为这一贡献 (Ground-breaking text-formatting language.) 获得了 Grace Hopper Medal。

可是 Scribe 在应用上的成就却远远地被 TeX 所抛离，TeX 的生命力，被证明持久至今，而 Scribe 现在却在网上连一个正式的文档格式规范都找不到，一篇超过两页的详细描述都找不到！这是为什么呢？从 wikipedia 的文章中我们或许可以猜到一些隐情。

与 Knuth 慷慨地将 TeX 放入 public domain 不一样，1979 年 Reid 就把 Scribe 卖给了一个叫做 Unilogic 的公司，后来这个公司还持续和 Carnegie Mellon 大学就 Scribe 的知识产权问题扯皮，直到 CMU 放弃。最愚蠢的还不在这里，Scribe 居然在免费提供的 Scribe 程序中安插了后来被称为“time bomb”的东西，也就是说，90 天后如果用户不购买，这个软件就会执行自毁程序。

从 Scribe 如此猥琐的历史看，这个软件、这套格式最终为大众所抛弃，实在一点也不奇怪。

这个 blog 的长期读者也许读过我翻译的 The Scourge of Arial 一文，其中介绍了 Helvetica 的由来。而今年年初，看到 Helvetica: The Film 的公开，忍不住将它称做“年度最期待纪录片”。

目前它已经在欧美各处公映，却没有看到在中国的任何一处上映的计划，如果你能提供帮助：

If you work with a film festival, museum, cinema, or arts group and would like to organize a screening, please contact us via email: helvetica (at) swissdots.com

因为，我们想看 Helvetica，我们不能错过它。

这个东东首发在水木社区的 TeX 版，反响还不错，就贴来大家一同讨论吧

谈谈 TeX 系统的构建过程，不过这个其实挺没意思的，如果只是用 TeX，而不打算修改 TeX 的代码的人完全不需要了解这个，我也不会涉及什么 TeXBook 里的内容，不知道有人有兴趣不？先贴一小段，要是大家有兴趣我就继续贴。呵呵，也算是一个开发了几十年的软件如何演化的一点掌故。

偶尔，你可能会突发奇想：平时自己用的这些 tex, latex, pdftex 是怎么来的？——是怎么写出来的，又是怎么编译出来的？

愿意究根问底的话，可以先自己动手试一试，目前可以工作的最小的 TeX 系统是 web2c，我们常用的发行版中的二进制程序，都是根据 web2c 中提供的代码，基本不作修改，或者只作很小修改编译而来的，所以，你可以先从 http://www.tug.org/ftp/tex/web2c.tar.gz 下载一份 web2c 的代码，解压开来，听我一步步的讲。

众所周知，Knuth 最早是在一台 DEC PDP-11 上用一种叫做 SAIL 的语言编写的 TeX，尔后他和一些合作者，开始在 Stanford 大学实验一种叫做 literate programming (文学编程) 的新式编程方法，他们设计了一套叫做 WEB 的系统，用 Pascal 语言来编写程序，用 TeX 来编写文档，将两者交织为一张“网”。

经过几年的不断修改，WEB 系统和 TeX 系统相互的影响下逐渐成熟，到 1982 年的时候，两者都基本上稳定下来，此时的 TeX 系统，核心就是一个 tex.web 文件。OK, 看看你刚刚解压出来的 web2c 目录下是不是有这么一个文件？那就是 Knuth 亲手写的，原封不动。

WEB 系统中有两个独立运行的程序，一个叫做 tangle (扰乱？) 一个叫 weave (编织？)，运行 tangle tex.web 将生成一个叫做 tex.p 的 Pascal 程序，这个程序可以用任何现代的 Pascal 编译器编译；而运行 weave tex.web 将生成 tex.tex，你可以用自己系统里已经安装的 tex 来 tex tex.tex 得到这个程序的文档：tex.dvi。

我相信很多人看到这里就会觉得相当无聊，那不妨认为你现在用的 TeX 系统就是这么来的句号。如果你坚持到现在还在继续看，那就可以接下去看更完整一点的故事。

Knuth 当时写着写着，居然写了一个三万多行代码的文件出来 (灌水王啊~) 这已经很恐怖了，可是后来大家要接着在他后边修改就很累了，他自己也得做 bug fix 不是？所以就给 WEB 系统添加了一个功能：合并主程序和 change file 的功能。

其实这个 change file，和我们现在常用的 diff 出来的 patch 结构也差不多，无非是原来代码的上下文，和要修改成的代码。比如在 tex.ch 里，你可以看到:

@x
原代码
@y
新代码
@z

这就是一个完整的修改单元。tangle 和 weave 都同时接受主程序和 change file 两个参数，将两者归并起来再行生成 Pascal 程序和 tex 文档，也就是说，实际的编译过程是这样的:

tangle tex.web tex.ch 得到 tex.p
weave tex.web tex.ch 得到 tex.tex

可是后来，Knuth 又说，TeX 这个程序应该 freeze 下来，大家不要再改了啊，想改，就换个名字，不要再叫做 tex 了。所以后来陆陆续续就出现 etex, omega, pdftex 等等增强版本，可是大家做这些增强版本的时候，也不好意思直接在 Knuth 的代码上改啊 (恩，大牛写的代码只能拜)，就纷纷创建自己的 change file。渐渐的 change file 就多了起来，比如 XeTeX, 要归并的 change file 有四五个之多，可是 tangle 和 weave 都只支持一个 change file 啊，于是就有人写了一个叫做 tie 的程序，专门做这种归并工作 (和 Larry Wall 写的 patch 一样)，你可以指定一个主文件和 9 个以内的 change file，按顺序一个一个归并起来。

所以我们看 etex 的编译过程 (在 etexdir/etex.mk 这个 Makefile 里可以看到)，就是先:

tie -m etex.web tex.web etex.ch etex.fix

得到 etex.web，然后 tangle etex.web 得到 etex.p 的。

可是 Knuth 开发 TeX 的那个时代 C 还没有获得大众 (OK，如果计算机科学家也算作大众的话) 的欢迎，也许因为 Knuth 本人和 Nicklaus Wirth 关系也比较铁，WEB 就优先选用了 Pascal 语言来编写 TeX，然而到了 90 年代，Pascal 渐渐退出了大家的视野，尤其在 Unix 系统下，C 更是金科玉律一般没有任何其他语言能替代，考虑到普及的原因，也考虑到方便与其他 C 语言编写的模块一同链接的原因，一班人开始考虑把 TeX 的代码转换为 C 的可能性，这就产生了 web2c。(web2c 一位长期的维护者 Karl Berry 就是现任 TUG 主席，也是 TeXLive 的主要维护者之一。)

最直接的办法就是把 tangle 后的 Pascal 代码转换为 C 代码，web2c 也正是如此设计的，毕竟 Knuth 当时为了保证尽可能的方便移植，几乎没有用到只有 Pascal 语言才有的特性，所涵盖的功能现代的 C 编译器 都已具备。所以他们采取的方法就是用 lex 和 yacc 写出了一个把 tangle 输出转换为 C 代码的程序。

那么，究竟应该如何调用 web2c 来生成 C 代码呢？生成出来的代码又该如何编译呢？且听下回分解。

Microsoft 在 (或者将在) Windows Media Center Edition, Windows Vista 和 Office 2007 中替代 Tahoma 作为界面和菜单的默认字体的就是现在看到的这个 Segoe UI。毫无疑问，它可以和 Tahoma 区分得很清楚，取代 Tahoma 的尖刻的圆角和 Trebuche MS 有几分相似——wikipedia 上是这么说的。

然而 Linotype 公司声称它与 Linotype 的 FrutigerNext 是一模一样的。看下面的对比，真的是几乎一模一样啊 (黑色的是 60pt 的 FruitigerNext，灰色的是 56pt 的 Segoe UI)：

Wikipedia 上还提到，Microsoft 在 2004 年尝试在欧盟将 Segoe 和 Segoe Italic 注册为原创性字体设计，Linotype 提出了抗议，在 2006 年二月，欧盟拒绝了 Microsoft 的注册请求。Microsoft 承认 Segoe 和 Frutiger 是一样的，但却声称 Linotype 在 2004 年以前没卖过 Frutiger 和 FrutigerNext (这个理由真 faint)，这个说法还是被欧盟拒绝了。

那么现在究竟 Microsoft 会不会撤掉他们预先说好要在 Vista 和 Office 2007 中出现的这个字体呢？或者 Microsoft 与 Linotype 达成和解，同意给每份 Vista 的 copy 支付一个美分的授权费用？(先前 Microsoft 是在 Reader 软件中为 Frutiger Linotype 这个字体支付的授权费用。)

在网页上的比较可能会比较符合 Microsoft 的心思，不过我的测试是发现 Frutiger Linotype 和 Segoe UI 的效果差不多 (难道 Vista 上 ClearType 的改进又会带来变数？)，但 Frutiger Linotype 的 descenders 明显一点，Segoe UI 的 ascenders 明显一点，相比起来 Segoe UI 不那么“扁”，看起来会更顺眼。

引用一份 FrutigerNext 的小册子上说的：

1970 年初，当巴黎计划建设 Roissy Charles de Gaulle 机场时，他们发现机场的信号标识需要一个清晰可辨的字体。导航系统的设计落到了 Adrian Frutiger 的头上，结果是……太成功了，不仅导航系统需要这个新的字体，许多常规的书籍印刷同样需要。1977 年，这个字体以 Frutiger 的名字命名，进入了 Linotype Library。它不仅为机场信号，更为所有希望在字号较小时达到清晰可辨的字体设立了一个标准。 ……创造出一个既有吸引力又富动感的字体。经过加强的 ascenders 和 descenders 更显可读性，小写字母和数字在一行上排布得很整齐。Linotype Frutiger NEXT 在 Frutiger 的基础上，使笔画与宽度更为协调，各种粗细的版本放在一起显得更为融洽而不突兀。

从传统的字体设计角度上来说，Segoe UI 当然和 Frutiger/Next 脱不了干系，可是如果从纯技术角度上来说，我们不妨反思这样一个问题：字体的版权应当如何保护，类似 Microsoft 这样，为 ClearType 所优化的 hinting 算不算版权中的一部分呢？

已编码的汉字一共有多少个？

先看看 Unicode 中对汉字的编码 [1]：

首先是基本位面 (BMP) 中的：

• CJK Unified Ideographs: U+4E00 .. U+9FA5 = 20902 个字符
• CJK Unified Ideographs Extension A: U+3400 .. U+4D85 = 6582 个字符
• CJK Unified Ideographs (4.1): U+9FA6 .. U+9FBB = 22 个字符
• CJK Compatibility Ideographs: U+F900 .. U+FA2D = 302 个字符
• CJK Compatibility Ideographs: U+FA30 .. U+FA6A = 59 个字符
• CJK Compatibility Ideographs: U+FA70 .. U+FAD9 = 106 个字符

以上总计 27973 个字符

下面是位面 2 的：

• CJK Unified Ideographs Extension B: U+20000 .. U+2A6D6 = 42711 个字符
• CJK Compatibility Supplement: U+2F800 .. U+2FA1D = 542 个字符

以上总计 71226 个字符，这些是所有已经包括在 Unicode 中的汉字。

• Punct & Radicals: 2E80..U+33FF = 1407 个字符，这些是部首与标点。

以上总计 72633 个字符

也就是说，我们总共能够访问的字符以 7 万左右为上限。

选择字体的原则

正文字体，顾名思义，是给文章主要的内容使用的字体，反过来说，它不是标题字体或者美术字体。所以，正文字体的选择自有其原则，我在下面选取的原则是：

1. 美观，包括屏幕显示的美观与打印效果的美观。
2. 包含足够的字符，这个好理解。
3. 符合授权。先不考虑字体是否通过正常的途径得到，至少使用这个字体的过程必须符合字体的授权。

再详细说说怎么叫美观，相对另外两点，这是一个比较主观的概念，可毕竟也有些共识，或者换句话说，字体至少要清晰、可读性强，能够长时间阅读而不疲劳，这也是我判断的标准。

字体的选择

我选择的字体主要包括这几类：全文使用的字体，强调用的字体、代替斜体 (或意大利体) 在拉丁字体中的类似地位的字体，和表示一段特殊文本 (比如原文引用、代码) 的字体。这基本上涵盖了正文需要使用的全部字体种类。在 TeX 中，以 CCT 文档类 [2] 为例，常见的设定是，全文使用宋体，强调使用黑体，代替斜体的是楷体，表示代码的是仿宋体，所以我也主要测试这四种字体。

选择的字体是我的机器上已经安装的字体，分别来自 Windows XP、Office 2003、Adobe Reader 和方正 GBK 字库。

技术细节

在操作系统、浏览器下的字体显示过于依赖点阵字体，所以这里是不考虑的，那什么算作屏幕显示呢？我测试的是 TeX 文档，使用 dvipdfmx 生成的 pdf，使用 Adobe Reader 7 观看，并打开 CoolType 的效果，所有的测试都是基于同一个 TeX 文档的，你可以在这里下载 (需要 Unicode TFM 文件配合，可以使用 cyperbit 字体的 TFM 或者用 ttf2tfm 工具生成)。打印效果… 应该都不错，但测试起来不大方便，待我有空装上激光打印机先…

怎么判断一个字体包含字符的数量？下面处理的字体有两种，TrueType 和 OpenType (CID)，都可以使用 Microsoft 提供的一个工具 查看其包含字形的数量，当然这里包含的字形不仅仅是汉字，也包括拉丁字符等。至于具体某个代码点有没有字，就不是我一个人能够测试得过来的了。

授权信息主要根据上面这个工具得到的 Embedding 数据和 License 数据。事实上下面遇到的 Embedding 就只有两种：Installable 和 Editable，也是最宽松的两种，Editable 的意思是你可以使用这些字体做 pdf，分发生成的 pdf，并允许别人对这些 pdf 作再加工，但你不能直接分发这些字体，也就是最常见的情况；Installable 的意思是允许收到嵌入该字体的电子文档者也能从电子文档中获取并安装该字体 (.. 这种情况很少见)。

结果

最后

最后… 当然是截图时间了，不过并非上边每个字体都有截图哦。

结论呢？

哦，好像真的是漏了结论，那便写点我自己的看法吧。

宋体中，博雅宋似乎过扁，中宋、标宋过黑，报宋和宋体 (simsun)、AdobeSongStd 都太淡，方正超大字符集收字最全，但在目前我还没搞定怎么让它访问到 CJK ExtB 那些代码点……，在不加粗的情况下，书宋与兰亭宋为最佳。

明体我没有发言权

黑体测试得也不多，主要考虑的还是字形的覆盖，所以不少人喜欢的 KozGoPro 字体没有测试，Mac 下用的丽黑也没有测试，华康等繁体的黑体也没有测试。目前的情况看，黑体的效果都不错。(不过用 FrameMaker 生成的 pdf 中，这几种黑体效果都不好，均有杂色，比较奇怪)

楷体中，标楷体的写法不大符合大陆的习惯，还是以方正楷体比较舒服，收录的字也完善。

隶书和仿宋可以任择。

参考文献

1. Unicode Consortium. UNICODE HAN DATABASE.
2. 张林波. CCT 的 LaTeX2ε 中文文档类.
3. FounderType. 方正字库.

Firefox 的内存泄漏问题搞得人心惶惶，Jesse Ruderman 的说法似乎平息了一点怨气，但从我这几天用 nightly build 的结果来看，情况并没有什么好转，看来我们只能把问题归咎于扩展上了。

我现在用的 trunk 版本只启用了这么几个扩展：FlashGot, SwitchProxy Tool, IETab, NoScript, TabMix Plus, AdBlock Plus，几乎是 Firefox 的 addons 网站 上最受好评，也使使用者最多的几个，去年这个时候我写 Reflections on Firefox，过了一年时间，Firefox 方便浏览的功能没有一点改进，我们还是得依靠扩展。可是“They found that Session saver, NoScript, IE Tab, and the combination of FlashGot and Filterset.G Updater cause leaks.”——它们又是导致内存泄漏的元凶，真让人有点进退不得的感觉。

有人总喜欢拿“内存就是拿来用的”这句话来搪塞，我的看法是，这话没错，可是写程序却不是为了制造 bug 的，相信没人愿意明知这个 bug 在那里却不去修改：同样的，明知道可以早一点释放内存，却因为疏忽而没有释放，现在这个 bug 给别人发现了，却用这句话来做挡箭牌，未免无耻了一点，没错，内存是拿来用的，可难道你 Firefox 就天经地义的该占了 300M 的内存，留给其他所有程序用 200M？

再者，我在 about:config 里设置的上限可是 64M…倒真的很奇怪一个连自己最多用多少内存都不能控制的软件居然可以发布。

诚然，David Baron 在 The danger of extensions 中的忧虑是有道理的，Mozilla 本身的源代码管理已经足够混乱，给扩展开发者提供的环境也有够恶劣——连 minor version 的变化都经常使许多 extension 失效，对扩展的代码缺乏监控……如果说去年还是一片大好光景下大家有少许怀疑的话，到现在，扩展，或者说整个 Mozilla 开源社区管理混乱带来的种种问题，已经越来越趋进酿成灾难性的后果了。

是否我们接受开源的优越性的同时，必然接受这样的责罚呢？

这里是目前已经完成的 W3C 词汇表翻译的初版：GBK / UTF-8。

欢迎对其内容提出意见，可以发送到我的邮箱，也可以在这个 post 中回复。其中带“*”号的词汇是我最需要帮助的部分。:)

前些日子写的东东确实少了点，这两天尽量补救一下啦，看来我和大家的时间表是相反的，估计现在大家都应为过年在外边玩吧

布丁长辈完成了 W3C 词汇表的翻译，这份词汇表是根据 W3C Hong Kong 的版本，考虑台湾的用语习惯而调整后得到的。虽然 W3C Hong Kong 提供了简体版本的词汇表，我再考虑我们是不是应该在布丁长辈翻译的基础上，也将这个简体的词汇表进一步完善呢？我会尽快开始这个工作。

更新：目前完成的版本 (仅仅是挑出我不同意的翻译)，GBK / UTF-8。

Jedi 前辈 (呃……在去年 12 月) 写了一篇介绍 Firefox 中配合网页设计的相关扩展的介绍，相信其中有些，虽然你可能已经安装了，也未必了解其功能吧。不妨读读。

再来一条来自台湾的消息，李果正前辈的这篇《樂譜排版軟體簡介》需要排版乐谱的朋友不可错过，其中介绍的大部分工具和 TeX/LaTeX, GNU/Linux 有关。

Mark Boulton 的这篇《更佳排版的五个步骤 (Five Simple Steps to Better Typography)》提出了一些很有新意的观点，对 Web 排版有兴趣的朋友可以读读。虽然部分观点我不大同意，不过这个系列文章还是值得翻译的。

wordpress.com 的邀请一度被炒得很热，因为当时只有几个开发者拥有帐号和邀请权，物以稀为贵，这东西居然也能在 ebay 上拍卖了。自从 9 月 11 号以后，wp.com 开始自动发送邀请信，尽管仍然限制了邀请的人数，但使用者也渐渐多了起来，用的人多了，就会有意见，所以现在有捧的，也有骂的。

我也试着用了一会儿，觉得现在还没到值得向朋友推荐的地步，主要是因为以下的原因：

1. 现在用的是 WordPress 1.6 的 preview 版本，bug 还很多，其实现在有限的邀请，主要就是请你帮忙找 bug 的。我只用了大概 15 分钟，就发现了四五个 bug，都是不能忍级别的。(这从侧面说明 1.6 的发布恐怕还要等很长时间)
2. 已经有国人在上面发表一些危险的言论 (这些言论是否合理合法不是我要讨论的话题) 了，难保不会被 Great Firewall 封掉。
3. 相比纯中文的环境，wp.com 没有一个群体 blog 的合适氛围，对中国人来说，反正我觉得很不习惯。
4. WP 本身不采用模版系统，theme 都是直接用 PHP 写的，这么做造成的直接原因是这种多用户的版本绝对不会允许你自己编辑 theme，只能用官方指定的几个。
5. plugin 当然也不见了，没有了 Markdown，要忍受 bug 多多的 WYSIWYG 编辑器真是痛苦啊。

总结起来就是，wp.com 尚未成形，真的希望在上面写 blog 的朋友不妨再等等，想拿个 invitation 炫耀的家伙最好也给人家报告报告 bug，说实话，blog 要恁多作甚？有一个踏踏实实写的就好了。