片子大概是 07 年初拍的，有 Ratatouille 的镜头，但是很少，也没介绍。不过估计其中大多数采访还要更早一些，比如里面胖胖的 Steve Jobs，看起来像 05、06 年的样子。

这是一部纵向的历史，点选得很好，John Lasseter 作为整个 Pixar 精神领袖，奠定基业；Steve Jobs 慧眼识珠；Andrew Stanton, Brad Bird 锐意进取；以及 George Lucas, Tom Hanks 这些从另一个角度给出的看法，都弥足珍贵。

这样的一部纪录片，有着一种激动人心的力量，不疾不徐，但是潜移默化，当你看到 John Lasseter 说：“别人问我为什么总能得到最好的车位，我告诉他，因为我三天前就把车停在这里了，这几天我一直睡在公司”，看到 Pixar 草创之际每年亏损好几百万 Steve Jobs 仍然坚持投资……回过头来看，你会觉得这都是值得的，能够亲自推动 3D 动画电影的革命，能够创造这样一个历史，这都是值得的。

唯一的遗憾是，横向的比较只是突出了 3D 动画与传统的 2D 动画在时代更迭之际的矛盾，作为引出 Disney 收购 Pixar 的铺垫，所以略有不足，Pixar 在这场 3D 动画的革命中并非独行，DreamWorks、Bluesky 等同样也有贡献，这方面的介绍未能在本片中出现。

此外作为一个技术人员，没能看到 Pixar 内部的工作流程，包括 RenderMan 这样重要的软件是如何开发出来的，也略有遗憾。

在我还年轻时 — 也就是写下《哥德尔、艾舍尔、巴赫》那时 — 曾问过自己这么个问题：“计算机程序会有写出优美音乐的那一天吗？”然后做出了如下推断：“计算机作曲程序在很长一段时间内不会产生什么有新意的成果……‘我们就快能用一台批量生产的二十块钱邮购获得的预置程序桌上型音乐盒子中那贫乏的电路写出肖邦或巴赫假如活到今日将写出的曲子’ — 这种念头，哪怕只是想一想 (事实上我的确听人如此提过)，也已是对人类心智深度的一种荒诞可耻的误估。”那时我的调子就是如此这般。

四分之一个世纪之后，我是如何看待这种推断的呢？说不准。这些问题已困扰我多年，直到现在还是没找到一个确定的解答。 1995 年春，我偶然发现了 David Cope 的《计算机与音乐风格 (Computers and Musical Style)》一书，他是加州大学圣克鲁斯分校的一位教授。在书中我注意到了一首模仿肖邦风格的马祖卡舞曲，它是由 Cope 的 EMI (“Experiments in Musical Intelligence (音乐智能实验)”一词的缩写) 程序所谱的。之所以能引起注意，是因为作为毕生的肖邦爱好者，我觉得没什么伪托肖邦的曲子能骗过我的眼睛。所以我直接在钢琴上即兴把这首 EMI 马祖卡反复弹了好些次，每弹一次，我的困惑与惊讶便增加一层。

尽管能间或能听出些小瑕疵，这首曲子还是给我留下了深刻的印象，因为它似乎在“倾诉”着什么。如果谁告诉我它是出自人手，我绝不会怀疑它的表现力。这首曲子听来有些怀旧，带点波兰味道，而全无抄袭嫌疑。它是崭新的，而又毫无疑问地刻上了“肖邦风格”的烙印，却不令人觉得情感空乏。我的的确确受到了震撼：抒情的乐曲怎么能从一个从未听过一个音、从未活过一秒钟、从无一丝一毫情感的程序中写出来？

越是纠缠于此，我就越是困扰 — 但也越是为之着迷。这里确实有个不符情理的矛盾，狠狠将了我一军。但我不会就此拒绝承认，认为 EMI 无关紧要或缺乏乐感，不然这只能说明我的怯懦心虚而已。我要直面矛盾，与这个怪异的程序奋战到底，因为它动摇了早在我内心深处的信念：关于音乐的神圣地位的信念、关于音乐是人类灵魂的终极圣地的信念。这也是人工智能在奔向思维力、洞察力与创造力之前的最后障碍。

如果我只是看过 EMI 的架构而未听过任何它的产出，我肯定不会把它放在心上。尽管 Cope 在 EMI 上花的功夫比大多数人工智能研究者在任何项目上花的功夫都要多得多，EMI 的基本原理在我看来并不新鲜，甚至显得没什么前途。颠覆我看法的是 EMI 所谱的曲子。

后续的几个月里，我在美国和加拿大的许多地方做了关于 EMI 的讲座，令我大为惊讶的是，几乎没有几个听众对 Cope 模拟艺术创造力上的这一妙着感到沮丧，几乎没有谁感到威胁或担忧。反之，我却觉得某种能显示人类深邃思维的崇高性不复存在了。对我来说，不仅丢脸，还很可怕。

EMI 中最深层次的原理是被 Cope 称作“重组音乐 (recombinant music)”的原理 — 从一名作曲家的作品中识别出不同类型的重现结构，然后以新的排列来复用这些结构，依此产生一份“同样风格下的”新作品。你可以想象 EMI 在学习了贝多芬的九首交响曲后，自行谱出《贝多芬第十交响曲》的情景。

给定几个输入作品的情况下，EMI 的核心手法是这样的：

(1) 分解；(2) 重组。

当然，有许多重要的原理会限制什么段落可以跟在什么后面，这些原理都被公式化确定下来以保证乐曲的连贯。我可以总结出如下两条规则：

(1) 局部的音调转合模式应类似原作； (2) 全局的片段排布应类似原作。

这两条规则也可以转化为在解决拼图游戏时经常利用的两类限制：

(1) 每块拼图的形状必须与邻接块紧密啮合； (2) 每块拼图上的图案必须在整个图片的大环境下有意义。

前一条限制可以被刻画为“语法啮合”，或者仅根据“形式”构造的啮合，而后一条则可以刻画为“语义啮合”，或者仅根据“内容”构造的啮合。单看其中任何一个都平平无奇，可一旦组合起来，它们就能成为一套非常强大的限制。

篇幅所限，这里我无法详述 EMI 中各种错综复杂的构造，它们被用来吸收风格元素、执行 Cope 编制的多层“重组”。

在我关于 EMI 的讲座中，几乎每次都会让听众先听上一组双音小节，事先告知它们其中至少有一个是巴赫所作，也至少有一个是由 EMI 仿巴赫所作，然后由他们尝试找出其归属。听完之后我会让听众投票，通常大部分的听众能认出真正的巴赫作品，但通常也只是 2/3 的听众选对，还有将近 1/3 的人错了。而且选错的并非总是那些缺乏经验的听众。

EMI 在进化着 — 它不是一个固定的目标。Cope 是从 1981 年开始开发这个程序的，多年以来他并未停止。EMI 的早期作品就像任何作曲新手的一般稚嫩，可后来的作品就越来越令人难忘，Cope 也随之对它有越来越高的期望。一开始他只是满足于 EMI 创制的短篇二部创意曲和短篇马祖卡，但现在他已经开始让 EMI 谱写整部整部的奏鸣曲、协奏曲和交响曲了。EMI 甚至还在编写一部叫“马勒”的歌剧 — 这可是对人类作曲家来说都极富挑战性的工作。

毫无疑问，风格是一种多层次的现象。对风格的认知有深有浅，仅抓住一个作曲家的浅层习惯而忽略掉某些内在神髓是完全可能的。所以，在听到一段音乐，认出其中某些手法和以前听过的甲作曲家的手法相似，从而自行声称“这听起来像甲的作品”的时候，我们又受到了多大的欺骗呢？我们到底能不能清楚地区分浅层感应与深层体会？说实话，音乐的“浅层风格”与“深层风格”、“语法”与“语义”、“形式”与“内容”之间到底有什么区别？甚至到底有没有区别？

在讲座中，我通常还会加上一段插曲，这次涉及马祖卡舞曲了 — 一首肖邦加一首 EMI。有一次我在纽约州罗切斯特市，世界著名的 Eastman 音乐学院做这个讲座，几乎所有的作曲与音乐理论教员都上了 EMI 马祖卡的当，把它当成了货真价实的肖邦 (相形之下，真正的肖邦作品却被当成了计算机仿冒的小调)。一位 Eastman 的音乐学生，Kala Pierson 就此给我发了一封电子邮件，她说：“和大多数朋友一样，我把第二首作品当成真正的肖邦。在你宣布第一首是肖邦的而第二首是 EMI 的那时，我们都倒抽了一口凉气，它带来的后果是一种快乐的恐慌，我从来没见过这么多理论家和作曲家的矜矜自得转眼间被扫得一干二净 (当然也包括我自己的)，它真是美轮美奂。”

我在罗切斯特的讲座中 (事实上也是从所有关于 EMI 的讲座中) 得到的震撼是，有着深刻音乐天分、经过长年训练的人也有可能偶尔把 EMI 的作品当作真品。要记得 — 我们这才刚刚起步，我们人类才刚刚开始把“批量生产的二十块钱邮购获得的预置程序桌上型音乐盒子”这样的梦想付诸现实，这种盒子就是在我写《集异璧》时曾嗤之以鼻的“贫乏电路”上构建而成的。

再经过二十年的努力工作后我们能到达什么境界？五十年呢？2084 年那时的顶尖水平又会是怎样的？到那时还会有人能区分真伪吗？谁会知道、谁会关心、又有谁会大声呼吁风格最核心的那微小的一点还没有被达到 (也永远达不到)？一旦巴赫、肖邦们广受赞誉的崭新杰作，如尼亚加拉大瀑布的流水一般从硅晶电路上涌出时，又有谁还会关心这样琐屑的细节？这样奇妙的一个新的音乐黄金时代，难道不该是“美轮美奂”的吗？

以 Cope 所谓的《普罗科菲耶夫第十奏鸣曲》为例。在 EMI 第一张 CD《Bach by Design》的封套说明中，Cope 写到：“这首由计算机谱写的普罗科菲耶夫奏鸣曲完成于 1989 年，它的谱写灵感来自于普罗科菲耶夫自己完成第十钢琴奏鸣曲的尝试，因其逝世而终止的尝试。所以，这说明了类似 EMI 这样的程序的一个潜在的用途。(即补完未竟作品)”可是对我来说，这样的话不啻渎神。

计算机模拟所令我担忧的，并非在于它暗示了我们自己可能也不过是机器，因为我早已相信了这一事实。困扰我的其实是这样的想法：触及我心灵最深处的东西 — 大部分情况下这指的是音乐作品，我总把它们当作灵魂间直接传递的信息 — 可能可以被简单的机制有效生产出来，这样的机制要比产生人类灵魂的复杂生物机制简单数千倍，甚至简单百万倍。这样的景象由 EMI 鲜明而几乎触手可及地展现在了我的面前，令我产生了巨大的担忧，在这样忧闷的情绪下，我悲观地罗列出了下面三个原因：

(1) (比如说) 肖邦要比我想象的浅薄得多。 (2) 音乐要比我想象的浅薄得多。 (3) 人类灵魂/心智要比我想象的浅薄得多。

让我再略作解释。关于第一点，既然我毕生都为肖邦的作品感动至深，假如 EMI 能一首接着一首地产出“肖邦风格”的乐曲，我将不得不从头回顾我从肖邦音乐中得来的全部意义，因为我将不再相信这样的意义只能来自于人类内心深处，而不得不接受这样的事实：弗雷德里克・肖邦可能只是一个非常流利的艺匠，而不是一位拥有深刻情感的艺术家，一位我从孩提时就确信自己知之甚详的艺术家。

这样的损失会给我带来难以想象的悲痛，但从某种意义上说，上述损失不会比第二点带来的损失更糟，既然肖邦总被我当作音乐力量的代名词。尽管如此，把所有的作曲家统统扫地出门肯定还是比只扫一位要来得困难。

当然，第三点带来的损失将是对整个人类尊严的终极冒犯。当意识到人脑千亿个神经元、将近亿亿个突触连接中所蕴含的全部“计算能力”能被几块尖端水平的芯片超过，而产生有史以来最强大的“艺术大爆发”只需要一块纳米级别的电路板 — 全部这一切一切，不劳费神，全来自于一件没有知觉、视觉、听觉、味觉，不曾活过、死过、奋斗过、痛苦过、成长过、思念过，不曾歌唱过、舞蹈过、搏斗过、亲吻过、期望过、害怕过、胜利过、失败过、哭泣过、欢笑过、爱过、渴望过、关怀过的个体。

尽管 Kala Pierson 和许多其他的人可能会用“美轮美奂”这样的词来欢迎这种个体的来临，可是一旦音乐最终不可避免地被归约为了语法模式和模式本身，按我古板的看法，那会是非常黑暗的一天。

另外 Adium 其实是个非常好的开发群体，非常 active & helpful，只是项目庞大到了这样，bug tracker 里的 ticket 一多，开发者自己也很难保证代码结构足够好了。

因为最近开始使用 MSN 群 (1, 2)，但我使用的 MSN 客户端 Adium 并不能将群内发言人的身份显示出来，只能全部统一显示为群本身的名称。

其实这是 Adium 所使用的 IM 协议支持库 libpurple 在支持 MSN 协议上固有的缺陷 — 不过也不算特别严重的缺陷，因为 Windows 版本的 MSN 也只在 Windows Live Messenger 8 以上才支持，而 Mac OS X 下的 Microsoft Messenger 干脆到现在也不支持。

所以，要修复这个问题，必须从 libpurple 上打主意，然而，因为 libpurple 编译不便 (后面我会解释为什么这么说)，Adium 本身的代码仓库中只提供了编译好的 libpurple framework，编译这个 framework 的步骤则是分离出来的，要单独用 Utilities/dep-build-scripts 下面的脚本来完成。

可是问题变得越来越 tricky 了：为了编译 libpurple 的代码，必须下载整个 pidgin 的代码，但 pidgin 的代码又是用臭名卓著的 Monotone 来管理的，这直接导致下载当前代码的步骤就变得复杂无比，更不用说后面的编译了。

这还没有完，崩溃的是，Adium 虽然其他协议的支持都是直接从 libpurple 来的，但偏偏 MSN 协议最近改用了从 libpurple 中 fork 出来的 msn-pecan 项目，而 msn-pecan 又是用 git 来管理代码的……

这么一来，为了修改 MSN 协议支持并编译出 Adium，我们必须至少涉及三套版本管理系统 (Subversion, Monotone 和 git)，把 Adium 提供的一堆错综复杂的脚本找出来，让它先给 libpurple 打上 Adium 自己的 patch，然后分 ARCH 来生成 configure 并分别配置编译，最后合并成 Universal Binary 再 copy 回 Adium 的 Frameworks 目录去… 到这里我还没开始改一行代码呢！

虽然这个问题最终得到了解决，我提交的 patch 也将合并到 msn-pecan 官方的代码中去，可是这个经历仍然让我觉得颇有体会：

从 F/OSS 项目的贡献者来讲，要成功的参与项目，就必须掌握好常用的版本管理工具并了解基本的编译手段，才有机会参与到真正的代码修改中去。

而从 F/OSS 项目的发起和维护者来讲，要创造一个成功的项目，应该：

1. 避免使用怪异的版本管理工具
2. 编译步骤简单再简单，尽可能分解为可以单独执行调试的步骤，尽可能减少会在编译时出现的问题

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，是 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 的代码的人完全不需要了解这个，我也不会涉及什么 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. 方正字库.

我现在用的 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 开源社区管理混乱带来的种种问题，已经越来越趋进酿成灾难性的后果了。

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