Why Cairo?

因为想写一个 lightweight & fast 的文本布局引擎,这两天在留意一些新的图形 API。其实有些都不算很新了,像 [Anti-Grain Geometry](http://www.antigrain.com/)、[Amanith](http://www.amanith.org) 和 [Xara](http://www.xaraxtreme.org/)。

曾被誉为“Linux 图形未来希望”的 [cairo](http://www.cairographics.org) 广受诟病的是它的效率,尽管从一开始 cairo 便宣称将会利用 glitz 这样的 backend 实现硬件加速的矢量图形绘制,从而达到软件绘制无法达到的效果。结果现在戏剧性的是,cairo 比所有这些用软件绘制的引擎都慢得多

所以才有人写了这么一篇 [Why Cairo?](http://weblogs.mozillazine.org/tor/archives/2006/04/why_cairo.html),意思大概说得很清楚了,Mozilla 选用 cairo 的借口现在看来是非常苍白无力的,比如说 cairo 引以为傲的“bring vector graphics to print”有多少人需要把网页输出到 PDF/PS?如果最基本的页面渲染都做不到高效,谈何页面印刷的高效?

所以我觉得啊,rendering model 好当然不错,cross-platform 性能好也很好,但 cairo 是不是中 gnome 社群的毒太深了?什么东西都来搞个 backend,结果最后每个 backend 都半死不活的,没错,也许某天 David Reveman 搞定了 xgl 腾出手来整 glitz 了,可 David Reveman 就算搞定了 glitz,也未必能在 win32 下用啊。

… 今天测试的结果是,pango 用 cairo 作 backend,cairo 用 win32 backend,结果渲染一行字 (4 个字母),要半秒钟。嗯,没看错,就是 0.5s。

效率还是很重要的呀,虽然某位大人物说过:

预优化是万恶之源。

Layout Engine 的文档

真的是.. a mess,估计就像 pango maillist 上有的人说的,有能力使用 layout engine 的人都能够直接看 reference 写程序,没能力的都去用 GUI Toolkit 提供的 high-level API 了。

最近看的几个 layout engine 包括:[Uniscribe](http://www.microsoft.com/typography/developers/uniscribe/), [Graphite](http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite), [Pango](http://www.pango.org) 和 [ICU](http://icu.sourceforge.net/userguide/layoutEngine.html)。最惨的是它们的定位和功能还不一样,有些相互之间还有牵扯。

就是这样居然还有人能把 Graphite, ICU 和 ATSUI 集成起来[给 TeX 用](http://scripts.sil.org/xetex),考虑到 TeX 还是用 WEB (Pascal 的 literate programming 版本) 语言写成的,这真是让人崇拜得五体投地的[强者](http://www.unicode.org/iuc/iuc22/b051.html)啊。

(看了一下强者的 biography,原来自从我出生开始就在 SIL 工作了.. 那么这样我比较不自卑一点。)

更新:看完这篇 [mail](http://mail.gnome.org/archives/gtk-i18n-list/2004-December/msg00010.html),我又很高兴了 🙂

Segoe UI 之争

Segoe UI

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

然而 [Linotype](http://www.linotype.com) 公司声称它与 Linotype 的 FrutigerNext 是一模一样的。看下面的对比,真的是几乎一模一样啊 (黑色的是 60pt 的 FruitigerNext,灰色的是 56pt 的 Segoe UI):

FrutigerNext and Segoe UI comparison

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

那么现在究竟 Microsoft 会不会撤掉他们[预先说好](http://blogs.msdn.com/jensenh/archive/2005/11/16/493388.aspx)要在 Vista 和 Office 2007 中出现的这个字体呢?或者 Microsoft 与 Linotype 达成和解,同意给每份 Vista 的 copy 支付一个美分的授权费用?(先前 Microsoft 是在 Reader 软件中为 Frutiger Linotype 这个字体支付的授权费用。)

Frutiger Linotype and FrutigerNext

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

Frutiger Linotype in Firefox

Segoe UI in Firefox

引用一份 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 算不算版权中的一部分呢?

pt, px, DPI: 关于长度单位的误解

在印刷排版中,“point”是一个绝对的单位,它等于 1/72 英寸,可以用尺子丈量的,物理的英寸。但在 CSS 中 pt 的含义却非如此,例如我们指定一个字体是 9pt,我们会以为按照 CSS 规范,它等于:

9 * 1/72 = 1/8 inch

这是一个误解,因为我们的显示器被分割为了一个个的像素,单个像素只能有一种颜色 (为了简化,这里暂不讨论次像素反锯齿技术),要在屏幕上显示,必须先把以 pt 为单位的长度转换为以像素为单位的长度,这个转换的媒介,就是 DPI (事实上,这里的所谓的 DPI,是操作系统和浏览器中使用的术语,即为 PPI, pixels per inch,和扫描仪、打印机、数码相机中的 DPI 是不同的概念)。

例如,无论在哪个操作系统中,Firefox 浏览器默认的 DPI 都是 96,那么实际上 9pt = 9 * 1/72 * 96 = 12px。

所以,虽然“DPI”中的“I”和“1pt 等于 1/72 inch”中的“inch”,都不代表物理上的英寸,但这两个单位互相之间是相等的,也就在相乘中约掉了。

那么,真实的物理长度怎么计算呢?请拿出一把尺子,丈量你的显示器的可见宽度 (我这里是 11.2992 英寸),除以横向分辨率 (我这里是 1024 像素),得到的就是每个像素的物理长度。

现在我们可以回答这样一个问题,网页上 9pt 的字体究竟占用了多宽的空间?答案是:

9 * 1/72 * 96 * 11.2992 / 1024 = 0.1324 英寸 = 0.3363 厘米。

有兴趣的朋友可以自己查证一下。

再谈 Memory Leak

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

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