David Berlow:

How important dynamically rendered type is to design and use on the web must now be clear. In addition, the only other option—that the type industry cede its intellectual property to the public without permission—is not going to happen.

Tal Leming:

There should be a new file extension for this. I propose “.wtf” – “WebType Font”.

Mark Pilgrim:

… What he fails to mention is that every font-consuming application on every platform on every computer on Earth will need to be “upgraded” to “respect” this permissions table. Because otherwise they’re not really permissions, are they? They’re just useless bits taking valuable chunks out of my metered bandwidth plan. Like the bozo bit without the bozo.

Jonathan Hoefler:

All of the type designers I know desperately want to find a way to enable people to use fonts online, and not just because we’re capitalist stooges, but because we live our lives online.

Bruce Schneier:

Truth be told, I don’t know. I feel rather like the physicist who just explained relativity to a group of would-be interstellar travelers, only to be asked: ‘How do you expect us to get to the stars, then?’ I’m sorry, but I don’t know that, either.

总结起来，未来还是很黑暗。

使用步骤如下：

1. 如果没装过，先安装 SIMBL；

2. 下载 SafariURLFix.zip，解压后，放到 ~/Library/Application Support/SIMBL/Plugins 目录 (如果没这个目录就自己创建)；

3. 在 Terminal 中输入:

   defaults write com.apple.Safari JJURLsToFix -dict newsmth.net GBK

   其中 newsmth.net 为你希望应用修正的网站域名。也可以打开 ~/Library/Preferences/com.apple.Safari.plist 文件自己编辑 JJURLsToFix 这个 Dictionary，自行添加新的，见附图。

4. 重新启动 Safari，尝试下载这样的文件，看看文件名是否被正确纠正了。

如果还有什么问题，欢迎在下面提出。

Recently I just found the script stop working for no good reason, because the proxy server I’m using is working, and I tried manually choose a proxy server (by entering its address and port into my browser directly) it also worked, so apparently there is something wrong with the script.

However, it has been a while since I last commit my changes to this script back to git. So there are some changes I wish to keep and I don’t want to do a binary search to find out the problem (Yep, I’m a lazy guy).

A few googling got me a tool called pactester, which turned out to be very useful. Basically it’s a Perl wrap of SpiderMonkey JavaScript engine. Since the proxy autoconfiguration script is just a subset of plain JavaScript, it can safely executes that with SpiderMonkey and find out where is the problem.

So I installed it and did one test:

$ pactester -p ~/Documents/Miscs/proxy.pac -u 'http://blog.iphone-dev.org'
Use of uninitialized value in numeric ne (!=) at pactester line 137.
Error: SyntaxError: missing ) after condition at line 98:
     if (dnsDomainIs(host, "cubes.fr") return "SOCKS 127.0.0.1:7777";

So that’s the problem. Fixed it, everything is back to normal again!

That’s a small tip on debugging a complex pac script, hope it helps.

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

现在“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.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 以上才可以称为比较可读。

曾被誉为“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。

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

预优化是万恶之源。

最近看的几个 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 算不算版权中的一部分呢？

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 厘米。

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