cat jjgod >> log

更新: Mozilla Labs 新出一篇 Next Generation Javascripting 也总结了近来出现的一些有趣的东西，包括 Tamarin, SqurirrelFish, Processing.js, ContextFree.js 和 Parchment。

其中 Tamarin 和 SqurirrelFish 代表了浏览器 JavaScript 引擎性能的提高 — Tamarin 虽然现在还不明显，因为它的 JIT 还在 tracing 优化阶段，SqurirrelFish 甚至还完全没用 JIT。不过这两者正式进入市场至少要到 2009 年 Mozilla 3 平台的初步发布和 Safari 4 随 Snow Leopard 一起发布时。

Processing.js 和 ContextFree.js 则代表了 Web-based Processing 创作的新方向，Processing 和 NodeBox 的成功充分说明了在简单技术上提供更有效的表达方式会给图形生成带来多大的改进，现在能在 Web 上直接实时呈现这些优美的图形，毫无疑问 Flash, Silverlight 等将更不受欢迎了。

Parchment 则是一个非常漂亮的 Z-Machine 在 Web 上的呈现，适合 Text Adventure 爱好者们。

近来，两个新出现的 JavaScript 框架得到了许多关注: SproutCore 与 Objective-J。表面上，它们共同的特点就是大量使用了 HTML5 特性来改善用户体验，达到类似桌面应用的效果，然而从底层分析，它们其实代表了两种对富 JavaScript Web 应用的开发方式的革命。

为什么说是“两种”呢？虽然 SproutCore 是一套几乎完全由 Apple 工程师开发的框架 — 其设计目的就是给 MobileMe 提供类似桌面应用的效果 — 但其设计思维是 Web 化的，是和现下流行的服务器端开发框架一脉相承的。从我的观点看来，SproutCore 是受 Ruby on Rails 影响严重的一套框架，其提供的工具大多用 ruby 编写，创建的目录结构都带着 Rails 的痕迹 — 甚至开发人员也是典型的 TextMate 用户。

而 Objective-J 虽然也主要是由前 Apple 工程师领导开发，可是这些工程师却是不折不扣的 Objective-C/Cocoa 狂热爱好者，他们在 280slides 表现出来的是典型的 Keynote 风格，其代码组织则是典型的 NeXTSTEP 风格。

所以，可以想见的是，SproutCore 的设计思维更容易为大众接受，而 Objective-J 很可能始终保持小众 — 甚至我都很怀疑它到底会不会发布…

我们可能时常会关注 JavaScript 的效率，然而大部分都会忽略的一件有趣的事情是，CSS 也可能带来对页面载入效率的影响，正如 WebKit 的开发者，被称为“Semi-god”级别的 Dave Hyatt 所说：

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers. – Dave Hyatt

如何编写高效的 CSS？Mozilla Developer Center 有这么一篇文章值得一读：Writing Efficient CSS。

相信熟悉 Web 设计的朋友已经了解，这本书是一本关于 JavaScript 的较有深度的书籍，中文版是由贤安 (realazy) 和我一起翻译的，中文译名是《精通 JavaScript》。

原书的价值，对于熟悉的朋友应该毋庸置疑，我们两人在翻译时也颇费了一番功夫，大致分工是我主要负责和语言特性相关的，贤安主要负责和 Web 应用相关的 (包括与 CSS 的配合)，如果有任何意见建议，欢迎致信 projsch@gmail.com，我们会将所有的更正与改进放在勘误页面上。

Brendan Eich 的这篇 Mozilla 2，过了一个多月我才来看。还是有些新内容的。

现在“Mozilla”这个词比较怪，它不再指以前那个“Mozilla Suite”浏览器 (自从 SeaMonkey 分出去之后)，也不专指“Firefox”，更不仅限于“Gecko”渲染引擎 (虽然现在给 Mozilla 起的版本号还是和 Gecko 同步的)，按我的理解，指的是 Mozilla 组织这面大旗下的整个平台的统称，Web 渲染，XUL, XBL, JavaScript, XML/XSL 等许多引擎的统称，而其招牌产品就是 Firefox。

其中，Mozilla 1.9 将对应着 Firefox 3.0，其路线大致已经确定了。Brendan 讨论的是在架构上将有巨大变化的 Mozilla 2，它预期在 2008 年出现。

最引人注目的是基于 JIT 的 JavaScript 虚拟机的出现，加上改进的垃圾回收，将给 JavaScript 的效率 (在 DOM 访问和内存占用方面) 带来巨大提升，据说。同时，它支持的语言会是 ECMAScript 4 (俗称 JavaScript 2)。

其他的改进对普通用户则不大可见，比如放弃 XPCOM，而更多的依赖标准 C++ 的特性来写程序，去掉一些为了兼容性遗留的旧 API，简化代码组织，放弃 CVS 换用新的版本管理工具，等等。

最近 FreeType 2.2.1 刚刚发布，尽管由于 API 的变化 (许多内部函数被隐藏起来了)，多数的 distro 并未把系统使用的 FreeType 升级到这一版本——我相信要过很长一段时间才有可能这 么做。但使用源代码编译的版本，我做了一点小小的对比分析。

因为精力有限，只对 FreeType 2.1.10 (目前绝大多数发行版正在使用的版本) 进行了比较，试图给出基于 FreeType 的程序 (如 fontconfig) 应当如何配置字体 才能获得最好的效果的一点建议。而事实上，font rasterizer (字体光栅化工具) 必须和其他的 rasterizer 比较才能看出明显的区别来，例如 ATSUI, Win32 GDI 等等。

同时，我也只对随 Windows 附的 simsun.ttc 做了测试。如果你有兴趣，欢迎分享 更多的测试结果。

测试的截图在 flickr 上。

经过比较，我们可以给出这样一些建议：

1. 必须打开 anti-alias，gamma 才会起作用。
2. gamma = 0.0 时启用 sRGB (次像素反锯齿) 模式，这种模式要比默认的 gamma = 1.0 显示得更清晰锐利一些。
3. 绝大多数情况下，打开 hinting 能达到更好的效果。
4. 小于 12px 的情况下，关闭 anti-alias，打开 hinting 能使字体勉强可读， 但仍然建议绝对不要使用这么小的字体。
5. 12px 以上，即 12-16px, 18px 的汉字必须使用嵌入的 bitmap。事实上，AA + hinting 的汉字要到 28px 以上才可以称为比较可读。

因为想写一个 lightweight & fast 的文本布局引擎，这两天在留意一些新的图形 API。其实有些都不算很新了，像 Anti-Grain Geometry、Amanith 和 Xara。

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

所以才有人写了这么一篇 Why Cairo?，意思大概说得很清楚了，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。

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

预优化是万恶之源。

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

最近看的几个 layout engine 包括：Uniscribe, Graphite, Pango 和 ICU。最惨的是它们的定位和功能还不一样，有些相互之间还有牵扯。

就是这样居然还有人能把 Graphite, ICU 和 ATSUI 集成起来给 TeX 用，考虑到 TeX 还是用 WEB (Pascal 的 literate programming 版本) 语言写成的，这真是让人崇拜得五体投地的强者啊。

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

更新：看完这篇 mail，我又很高兴了

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 算不算版权中的一部分呢？

在印刷排版中，“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 厘米。

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

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

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