因为前面提到的原因，视频部分可以不转换，所以选择直接 Pass Thru，但音频部分一般是 AC3 或者 DTS 各式的，需要转换为 AAC 才可以给 iDevice 们播放，这里可以任选码率，大部分情况下 192 kbps 绰绰有余。

更新： @RioJot 提醒我有个开源的 Subler 工具也可以完成这个操作，它的界面比 MP4tools 更好一些，支持选择音频 downmix 的类型 (Dolby Pro Logic 2, Dolby Pro Logic, Stereo, Mono)，还可以自动抓取元数据和 Artwork。另外它的队列管理也比 MP4tools 好一些。唯一需要注意的是必须安装了 Perian 之后才可以进行音频的 downmix。

转换完之后的 mp4 已经可以直接加入 iTunes 中播放，但比较理想的还是添加一下文件的元数据，比如电影的标题、年份、电视剧的系列名和海报等等。这个工作可以用 iSubtitle 自动完成。只要用 iSubtitle 打开 mp4 文件，它就会根据该文件的名称在网上的对应数据库中匹配获得相关元数据 (比如电影从 themoviedb.org 中搜索)。iSubtitle 还支持的一个重要功能是给 mp4 文件添加软字幕，只需要把 srt/ssa 格式的字幕文件下载下来，取相同前缀，放在 mp4 文件所在的目录下即可。比如 Spartacus.S02E02.720p.HDTV.X264-DIMENSION.mkv 文件转换得到 Spartacus.S02E02.720p.HDTV.X264-DIMENSION.mp4，字幕文件可能是 Spartacus.S02E02.720p.HDTV.X264-DIMENSION.chs.srt。它的界面如图所示：

iSubtitle 执行的只是元数据操作，所以可以在 mp4 上直接保存。然后就可以加入 iTunes 中。iTunes 会根据元数据信息分类存放，比如下面这样：

更新：Subler 也可以完成添加字幕的操作，这样你可以把两步操作合并到一步完成，可是 Subler 必须手工选择字幕文件，而且字幕文件也必须已经转换为 UTF-8 编码才可以添加。

然后，在 iTunes 和 iDevice 中启用家庭共享 就可以在设备的 Video app 上看到这些视频了。根据我的经验，至少 720p 的视频在 wifi 下播放是非常流畅的，也几乎不需要任何缓存时间，如果出现播放缓慢、经常停滞的情况，就应该检查网络或者设备配置问题了。如图：

于此同时，因为 iTunes 已经将文件组织好了，我们还可以将 iTunes 的媒体文件所在目录直接添加到 XBMC 中，这样就可以自由选择是在电视的大屏幕观看还是在 iPad 上观看了 (当然也可以直接用 iTunes 观看，选用 XBMC 主要是习惯和方便用遥控器操作)。对于电视剧文件，因为文件名仅仅是标题，XBMC 无法直接搜索，所以可以在安装了 mp4v2 之后 (brew install --using-llvm mp4v2)，使用如下 Python 脚本生成符合 XBMC 需要的符号链接：

#!/usr/bin/python

import sys, os, commands

def linkfile(src):
    output = commands.getoutput("mp4info '%s'" % src)
    season = 0
    episode = 0
    for line in output.splitlines():
        sl = line.strip()
        if sl.startswith("TV Season"):
            season = int(sl.split(":")[1].strip())
        elif sl.startswith("TV Episode"):
            episode = int(sl.split(":")[1].strip())

    if season and episode:
        ext = os.path.splitext(src)[1]
        dst = "%s/%dx%02x%s" % (os.path.dirname(src), season, episode, ext)
        print src, "->", dst
        if not os.path.islink(dst):
            os.symlink(src, dst)

for root, dirs, files in os.walk(sys.argv[1]):
    for name in files:
        linkfile(os.path.join(root, name))

这样在 XBMC 上看到的效果如图：

顺带一说，在即将发布的 XBMC 11 “Eden” 中，还支持将 XBMC 作为 AirPlay 接收端，这样 iDevice 上保存的图片、音乐和视频也可以直接用 wifi 发送到 Mac 上观看了。

这周把买房和贷款的合同签完，买房这件事情算是告一段落，也可以来写点总结了。从真正决定买房到拍下房子，总共花了将近两个月的时间，对于我这样消费不怎么犹豫的人来说已经是出奇的长了。其实去年找租房的时候就有同事推荐买房，这几年搬家至少每年一次，每次租房实在有诸多不便，而且奥斯陆房价也在世界前列，增长的速度丝毫不见放缓，最近的数据是奥斯陆的房价自 2005 年来增长了 62%，年增长率大概是 10%。房价变化虽然不能和国内相比，但基数已经太高，奥斯陆的平均房价在 4.5 万/平米左右，所以增长一点都让工薪阶层更吃不消。何况买房还可以退税，所以在向同事打听清楚之后，今年年初就开始策划买房的事宜。

在挪威买房的第一步是选择一个贷款的银行，不同的银行允许贷款的额度和利率都不同，但大体策略是类似的：面向 35 岁以下的头一次购房者优惠最多，如果拥有别的房产或者年纪更大的人就享受不了那么多优惠了。以往头一次购房者可以 100% 贷款，虽然去年底开始挪威也收紧了房贷限制，要求至少首付必须占房价的 15%，但大部分人靠存款、父母支持或者卖房的收入还是可以付得起这部分的。此外国家的银行可以提供更优的房贷，但对于有稳定工作的人来说申请到的可能性不大。

选择银行一般是通过电话或者网站向银行约谈，我的办公室楼下就是 Sparebank1 的办公室，也是我平时使用的银行，所以就先找他们谈。基本上谈话内容就是了解我的年收入、债务等经济情况，打算买的房子的大致价格范围，用来计算我还款的压力，然后给出一个包含贷款额度和利率的具体 offer。如果我觉得可以考虑，就可以把我打算用作首付的钱放在这个银行的一个存款账户内，他们就可以做正式的贷款担保，有了这个担保就可以进入下个环节。一开始 Sparebank1 答应给我贷款 210 万，但利息不算最优，只能给 3.9%，而大多数银行可以给 3.6% ~ 3.7%。所以后来又联系了 DnBNor 和 Nordea 这两家。不过最后选择的还是 Sparebank1，一来是考虑操作的便利，二来是它在我的要求下最后答应给我 3.65% 的利率。

第二步，也是耗时最长的一步，是网上选房和实地看房，在挪威卖房不需要自己去找中介，因为所有的房源都在 finn.no 这个网站上列出了，有详细的房屋介绍和照片，包括房屋的建造年份、每月的公摊费用、维护情况、以前维护欠下的贷款等等。这些广告会附上一般两次的实地看房时间，叫做 visning。visning 一般安排在平时晚上下班后或者周末，每次一小时。大体也就是看看房屋的使用状况，和中介谈谈周边环境和房子的细节问题。如果看完以后感兴趣，就可以留下名字和联系方式，准备进入竞标买房的环节。在挪威选房子和国内区别，主要是这里更看中房子的西向，因为这样可以在下午到晚上获得尽可能长时间的阳光，这在阳光稀缺的国度尤其重要。如果房子朝西，有个大阳台，又是不受遮挡的顶楼，那肯定能卖出好价格。

两次看房结束后的一天内，中介就会组织竞标，竞标一般是早上开始，尽可能在中午 12 点之前结束，开始的出价一般会比房主的要价稍低，然后随着是否热门层层上升，最多时我见过比要价高出 50 余万成交的。竞标的过程都是由中介组织远程完成，第一次出价必须填写一个书面的表格并签字写明过期时间，后续出价就可以直接通过电话口头作出。我参加了三次这样的竞标过程，头一次没有其他人竞争，不过我觉得房主要价 260 万稍贵，就想压到 250 万内成交，可是房主坚持不肯，后来就放弃了这套房子，房主也只能重新组织下一轮的看房和竞标了。第二次的房子竞争者把价格炒到了 280 万以上，超过了我可以接受的最高限度，只好放弃，估计这套房子的成交价在 285 万左右。最后一套房子大家出价都很谨慎，要价 239 万，出价从 220 万开始，两万三万地增加，最后我出到 250 万没有人再加价，可是房主还试图要我出到 255 万，并许诺如果是这个价格就立即卖出，在我拒绝了以后他只好接受了我 250 万的出价。

之后的过程就很简单了，中介发来合同，签字，和银行签好贷款合同，最后这个月底正式过户，完成整个买房的全过程。在一开始同事跟我说买房注定是个非常痛苦的过程，其实觉得倒也还好，中间是会有选择与放弃的痛苦，尤其在喜欢的房子没买到的时候，所以我觉得最有用的一句话是“don’t get too emotionally attached to the one you didn’t get.”就算是喜欢的，放弃了也不应该再想，因为好的房子总是会出现的。

• UnicodeChecker

  

  Mac OS X 下完美的 Unicode 字符查看工具，可以根据 UTF-16 编码 (10 进制、10 进制)、UTF-8 编码来查找，或者直接复制粘贴字符进去，可以选择不同的字体查看该字符对应的字形，包含完整的 Unicode 字符属性数据库，可以自动下载安装 Unihan 数据库。几乎是每次开发和调试问题的必备。Linux 下有 gucharmap 实现类似的功能，但要弱很多。

• ttx

  将 TrueType/OpenType 文件按照指定的表 dump 成 XML 格式，或者反过来，所以既可以查看也可以修改。非常方便分析 OpenType 的 GPOS/GSUB 特性查找表。这是一个命令行工具。更简单一点的 TTF/OTF 分析命令行工具还有 lcdftypetools 里的 otfinfo，可以直接列出字体的特性，但没有细节显示。

• FontForge

  

  大部分 TTX 的功能也都可以用 FontForge 实现，虽然界面是基于 Xlib 的相对老旧，但它的功能实在是强大，不过我一般也就用来编辑字体的 name table 和 OpenType feature。

• hb-view

  harfbuzz-ng 提供的工具，可以用指定的字体、指定的 OpenType 特性，将 HarfBuzz 排版好的内容以 FreeType 渲染出来，方便对比测试特性字符串的布局正确性。当然，通常我还会用常见的浏览器、文本编辑器等来比较，尤其现在 Firefox 和 IE10 TestDrive 支持 OpenType 特性指定了，测试起来就更方便。

• fc-list, fc-match

  fontconfig 提供的工具，主要用来分析 Linux 下的字体匹配，在阅读它的用户文档之后，善用 -v 和 -a 参数，可以直接获得不少字体的信息。

• Pixie

  

  Xcode 自带的屏幕放大镜，用来分析 subpixel antialiasing 非常给力。别的平台下当然也有类似的工具，比如我在 Linux 下用 KDE 的 kmag。

• The Font Game, Kerning Game 和 letter shaping game

  三个制作非常精良的字体相关小游戏，第一个是 iOS 上的字体辨识，后两个则是体验对间距形状把握的 HTML5 在线游戏，适合在开发之余放松一下大脑

去年 12 月中在北京的 Qt 开发者大会上，我做了一个关于 Qt 的文本渲染技术的讲座，兼谈及了一些文本渲染的基本概念和过程，和四年前在清华 thossclub 讲的《文本渲染技术的一次短途旅行》相似但又有些新的内容，有兴趣的朋友可以看 slides，等有录像视频时我也会加上链接。

去年夏天我结束了三年的研究生学业，一个人跑到远隔万里的奥斯陆来工作，对于生活确实是个极大的变化，但诸般变化总还在计划里，慢慢也就适应了。然而今年夏天对于我生活的影响也许比去年还要大，既然如此，不妨暂且放下这个 blog 向来只更新技术内容的习惯，多记上一笔。

在这个夏天里，我邀请父母来奥斯陆，在我自己布置的公寓住了一个多月，一起游览了挪威的海边小镇 Ålesund、乘船到 Geiranger 峡湾、爬上 Preikestolen；还逛过了巴黎和布拉格，自己则两次到柏林出差，虽然匆忙，也算走过了许多地方，最适合旅游的暑假没有浪费，当然更重要的是在自己安排下带父母出门，这还是平生头一次，其中也有遗憾，但总算走下来了。

这个夏天里我还遇上了自己喜欢的人，认真地开始一段感情，长时间一个人的生活，到现在这种时常牵挂另一个人的心境，其实还颇有一点不大适应，但总归要慢慢学习和成长。

如果要说最大的遗憾，应该是没有花更多时间陪父母，尤其是花在旅程上的时间上多了，计划得略显匆忙，交流其实反而少了。二是因为工作繁杂，生活变化也大，很多原来坚持做的开源项目都没有更新，随着 Lion 的推出都应该陆续完成的，目前已经完成了 TextEdit 和 DictUnifier 的更新，希望接下来继续。

套用《甲方乙方》里那句话，这个夏天过去了，我很怀念它。

我与家人目前都还安好，也在积极关注事态的发展，谢谢各位的关心。

可以想见的是，无论这两件史无前例的事件最终调查结果如何，都必然会对挪威造成非常深远的影响。作为旅居的华人，我也会在 blog 和 twitter 上继续介绍我了解到的情况。

According to Kyle, a first-time Mac OS X designer/developer, Cocoa is dying for a framework. This argument feels a bit ironic since I came from the age when a bunch of Cocoa fanboys were labeled as the “Delicious Generation” who only wrote fancy good looking apps with no actual functionalities, while the good ‘ol Carbon guys looked so damn unattractive. Has it now come to the downfall of us Cocoa developers?¹

Kyle’s main reasons for not liking Cocoa are as follows:

1. Drawing in code is slow and painful. Images are easier to work with and result in more performant code.
2. There is no layout engine for Cocoa. If you want two elements to rest side to side, you’ll need to calculate the pixel size of the text, padding, borders, margins — then manually position the next element.
3. There is no styling engine in Cocoa. (To change the background color of a button for instance will require significant changes)
4. Learning the differences between layer-backed views, layer-hosted views — understanding that you have to subclass everything — balancing delegates, weak connections, strong connections, KVC, view controllers, and notifications — understanding little intricacies like how AppKit flips .xibs when it load them up or how hard it is to make one word in a sentence bold.

I will try to share some of my opinions about them, one by one.

Is draw in code slow and painful?

Being a low level graphics developer for so long, I know my opinion must be biased. But still, I’ve never felt drawing in Cocoa (or Cocoa Touch) to be slow, working with Core Graphics, Cocoa Drawing API and APIs like Core Text is quite pleasant actually. Drawing operations are always blazingly fast. I honestly couldn’t see a better way to solve these problems without resorting to low level. Yes, they are imperative APIs rather than declarative, yes, you have to do your -drawRect: code cautiously. But low level drawing itself has never been a bottleneck for my programs. The real problems are scheduling what to draw and finding out when stuff is drawn.

So in my opinion, it’s not the drawing itself that’s slow and painful, but you need to have a thorough understanding of the graphics stack to be able to write efficient low level imperative drawing code. That’s a damn steep learning curve. That’s why very few people can write efficient yet complex drawing code even veterans like Loren Brichter recommend to “do your own drawing”.

However, there is no silver bullet. Cocoa Touch makes life a little bit easier by simplifying the view hierarchy and build with Core Animation from ground up. But to have butter smooth scrolling, you still need to do your own drawing cautiously. Apple did provide layer-based and layer-hosted views in Cocoa, but they are too conservative to re-architect the entire Cocoa view stack with Core Animation, that’s a pity but luckily you can always roll your own (as we always did).

Anyway, the best framework I can imagine is the one using a declarative API to construct most of the UI and leverage the full power of GPU, with flexibility to do custom drawing with an imperative API.

No layout engine for Cocoa?

Apparently, Apple is solving this with Cocoa Autolayout. Can’t say much about this (it’s in NDA) but it does look promising.

No styling engine in Cocoa?

Well well, this is controversial. On one hand people are complaining that UI in Mac OS X apps are not consistent anymore, on the other hand people detest Aqua and dream for change from the bottom of their heart. I can understand Kyle since he is more of a designer than a developer. With no doubt I think that’s a fair judgement, but it’s hard to justify whether the styling difficulty contributes to HIG consistency or drives people to the opposite side of it. As a user of Mac OS X I felt that UIs should be “semi-consistent”, or as John Gruber puts it eloquently: uniformity has been replaced by conformity.

Apple is acting slow and they can definitely improve on this. The solution doesn’t have to be very innovative, adding styling flexibilities here and there is no groundbreaking change. Cocoa Touch is not far superior either, there is still a lot of work to do if you don’t like the standard controls from UIKit. In contrast, my biased opinion would say that QML/Qt Quick appears to be a much more flexible solution, it’s XUL/Air/JavaFX/WPF done right. Though I am biased, who knows me well should know that I’m hard to convince as a low level graphics engineer.

Cocoa has complicated intricacies?

Yes, any framework survived more than 20 years will have some intricacies, that’s inevitable. Actually I’m surprised by the fact that so many of the NeXTSTEP APIs are still in good use. Come on, it’s a fast changing industry and you really need to be a genius to predict the trend in more than 10 years.

However, most of Kyle’s concerns came from his expectations: he expects to fit UIKit model as is into Cocoa but it didn’t work. It probably never will, as I said previously, Apple is conservative in that sense, for stable platform like Mac OS X, they tend to provide new options other than forcing everyone to adapt to the new model. That inherently complicates the framework, of course. Changes that us Cocoa developers applauded for can be seen as too cautious by iOS developers.

Anyway, I think it’s fair to say that Cocoa isn’t the best API for modern, dynamic UI, alternatives like Chameleon may eventually surpass it. Nevertheless, there is no easy path between both worlds, you either port the code to the new model (UIKit like) or adapt to the hybrid model (Cocoa like). For iOS developers, the former is definitely easier, but for us the latter seems to be a better option.

That’s it. I’m surprised that you can read my ramblings to this far

Fujifilm FinePix X100

自从上个相机 (Nikon D90) 丢在马德里之后，就一直在寻找比较轻巧的替代，D90 的画质虽然不错，但平时几乎不愿意带出门去，其间关注了 Olympus E-P 系列、Panasonic Lumix GF 系列和 Fujifilm 的 FinePix X100，今年复活节假期之前还没等到 X100 就先买了台 GF2 (14mm f/2.8) 尝试，上周刚刚拿到 X100，可以说说对这两台相机的印象了。

之所以先选择 Panasonic GF2，主要是因为另外两个选择：Olympus E-PL2 和 Sony NEX-5 带的镜头都不令人满意，E-PL2 在我这里只有变焦套机卖而 NEX-5 的 16mm f/2.8 定焦画质收到很多批评，而 GF2 的 14mm f/2.8 正好非常适合旅游的风景照和到此一游照，后来事实证明效果确实也不错。

我对于 GF2 的印象是：

• 体积非常小，搭配 14mm/2.8 镜头，一只手就可以很方便的握持和操控，适合拍一些角度比较低的照片。
• 对焦奇快，习惯了单反的对焦速度，改用 GF2 基本不会有任何效率的损失，当然据说这也和镜头搭配有关，Panasonic 14mm f/2.8 镜头应该是目前最快的。
• GF2 的高感光度画质是软肋，但因为我主要是拍旅游风景照，基本上没拍什么夜景，所以把 ISO 控制在 800 以下时，画质还是很出色的，至少看不出比 APS 幅面的相机逊色。
• 操控比较简单，但因为去掉了大部分的拨盘，基本改用触摸加按钮操控，所以偶尔还是不够方便，尤其像切换对焦点、更改快门、增加曝光补偿之类的常用操作，我还不太习惯。
• 一个教训是如果让别人帮忙拍到此一游照，一定要把对焦模式改成面部识别。

这个相机总的说来还是很满意的，喜欢轻巧搭配的可以加上 Panasonic 20mm f/1.7 镜头，不管是风景还是人像都很方便。不过我因为还想等等看 X100，就先把 GF2 给退了。

X100 的评测其实目前已经很多了，论详尽可以看 DPreview 的，尤其是想解毒的可以专门看 Conclusion 里的 Cons 部分，还是非常中肯的；如果想看看实际拍摄的照片，Steve Huff 的评测还不错，当然像 flickr 上搜索 “x100″ 也能找到很多照片。

从去年 9 月公布的时候我就开始关注 X100，到今年 4 月发售却一直没有货，直到上周才刚刚拿到，总的印象还是没有令我失望 (目前拍的照片放在这里)，虽然前面使用 Panasonic GF2 的经验多少提高了期待程度。虽然优缺点网上也都说得很多了，我主要想重复一下我体会最多的几点：

• 体积比 GF2 稍大一点，毕竟加上了取景器，顶部拨盘也比较多，但还是一只手可以抓稳的。
• 画质一流，镜头在全开光圈时锐度也很高。最强大的是高 ISO 效果，1600 以下基本上不用担心任何明显的噪点，对比起来完全不逊色于 Nikon 这一代的单反。
• “微距 (Macro) 模式”其实应该称作“近摄 (Close up) 模式”，因为基本上一米以内的对象不用这个模式就很难合焦了，而到 10cm 以内则所谓的微距模式也不管用了，所以实际上是不可以和单反的微距镜头相比的。
• 手动对焦 (MF) 模式的对焦环不大好拧，但可以用 AF/AE Lock 按钮来预先自动合焦，然后再用对焦环细调，所以还算方便。
• 其他情况下对焦速度还是不错的，比 GF2 肯定是慢了半拍，抓拍运动的对象不那么方便，但还不算太困难，尤其是 OVF 提高了取景的效率。
• 背后的拨盘和按钮设置不太科学，像更改对焦点之类的操作不如 D90 方便。
• OVF 的视差要在两米以外才基本可以忽略，而且用 OVF 对近处的对象相比 EVF 也更难合焦，当然因为混合取景器的设计，切换起来并不困难。
• 内置的中灰滤镜 (ND Filter) 很管用，适合在阳光下拍摄。

总结起来 Fujifilm FinePix X100 不失为扫街 (street photography) 利器，至于是否值现在这个价格就见仁见智了，比如花 4000 就能买到的 GF1 套机在焦段上接近 (40mm vs. 35mm 等效)、画质也不差太多，但选择 X100 的多半是因为它复古的造型和操控方式，如果在以后的固件升级里能提高一下对焦效率，尤其是微距模式的对焦，就堪称完美了。

下面的介绍主要根据我对 WebKit 和 Gecko (Firefox) 的印象来谈，其他的浏览器也大致相同，如有阙漏之处欢迎指出。

解码

当浏览器收到来自 Web 服务器的网页数据之后，第一步是要把它解码成可以阅读的文本，因为历史原因，不同区域和语言的网页可能会使用不同的编码方式，而浏览器判断编码主要是依据以下方法：

1. Web 服务器返回的 HTTP 头中的 Content-Type: text/html; charset= 信息，这一般有最高的优先级；
2. 网页本身 meta header 中的 Content-Type 信息的 charset 部分，对于 HTTP 头未指定编码或者本地文件，一般是这么判断；
3. 假如前两条都没有找到，浏览器菜单里一般允许用户强制指定编码；
4. 部分浏览器 (比如 Firefox) 可以选择编码自动检测功能，使用基于统计的方法判断未定编码。

分段

编码确定后，网页就被解码成了 Unicode 字符流，可以进行进一步的处理，比如 HTML 解析了，不过我们这里跳过 HTML/XML 解析的细节，单讲得到了解析后的文本元素之后该怎么处理。

因为我们得到的文本可能是很多种语言混杂的，里面可能有中文、有英文，它们可能要用不同的字体显示；也可能有阿拉伯文、希伯来文这种从右到左书写的文字；也有可能涉及印度系文字这样涉及复杂布局规则的文字；另外，还可能有网页内自己指定的文本语言，比如 <span lang="jp">日本语</span> 这样的标记，使得日文汉字可以使用日文字体显示 (因为 Han Unification 导致这些汉字和中文里的汉字使用同样的代码点，尽管很多写法不同)，"lang" 属性也可以在 HTTP 头、<meta> 或者 <html> 出现，用于标记整个文档的全局语言，通常这是一种好的习惯，方便浏览器进行字体匹配。

为了统一处理所有这些复杂的情况，我们要将文本分为由不同语言组成的小段，在有的文本布局引擎里，这个步骤称为“itemize”，分解后的文本段常被称作“text run”，但是具体划分的规则可能根据不同的引擎有所区别，比如 HarfBuzz 和 ICU 一般是根据要使用的不同排版类来划分 (常称作“shaper”)，比如英语和法语可能使用同一个 shaper 排版，那么相邻的英语和法语文本就会划分到同一个 run 里，而希伯来文需要另一个 shaper，就划分到它自己的 run 里，以 HarfBuzz 为例，它有这样一些 shaper：

• 通用的 (适用于中文、英文等等大多数布局规则简单的语言)
• 阿拉伯文
• 希伯来文
• 印度系文字
• 高棉文
• 缅文
• 谚文

不少浏览器还会在这个划分下面，在确定具体使用的字体之后，根据使用字体的不同划分更细的 run，这种 run 可能称作“SimpleTextRun”，每个都会使用和相邻不同的字体，最后把它们逐一交给 shaper 进行排版得到要绘制的字形，这样一来，shaper 的工作就被简化为在确定的语言、确定的字体下排版确定的文本，生成对应的字形和它们应该放置的位置、占用的空间。下面先详细说说确定字体的步骤。

字体

说到字体，首先必须提到的就是 CSS 里的 font 和 font-family 等规则。比如这样的规则：

p { font-family: Helvetica, Arial, sans-serif; }
strong { font-weight: bold; }

如果对于这样一段文本：

<p>A quick brown fox <strong>jumps</strong> over the lazy dog.</p>

表示这个段落里优先使用 Helvetica 这个 family 的字体，如果找不到，就找 Arial，如果还是找不到，就用浏览器设置的默认非衬线字体 (有的浏览器，比如 Safari 只给你一个设置，有的像 Firefox 则允许根据不同语言设置，这时可以根据前面分析得到的文本 run 语言信息来判断该用哪个)，这个过程非常简单，大家都很好理解。稍微复杂一点的是“jumps”，它应该继承父元素的 font-family，也用 Helvetica，但不用默认的 Regular，而用 Bold 版本，假如找不到 Helvetica Bold，就找 Arial Bold，否则就找浏览器设置的那个字体的 Bold 版本，假如都没有呢？就要考虑用人工伪造的方式来显示粗体了，这个且按下不谈，先看对于中文常见的情况：CSS 指定的字体没有覆盖我们需要的文本时，该怎么做。比如还是上面的 CSS 规则，但对这样的文本：

<p>一只敏捷的狐狸...</p>

这里的“一只敏捷的狐狸”该用什么字体呢？假设 CSS 里具体指定了中文字体，比如 Helvetica, STHeiti, sans-serif，那很简单，按照英文字体一样的规则来判断：逐个字符尝试当前的字体是否提供了针对该字符的字形，如果没有则尝试下一个，要是到了最后都没找到匹配的字体呢？CSS 规范里只简单的说执行“system font fallback”，但这个过程在不同的浏览器下可能很不一样，比如 WebKit 会使用 font-family 列表里的第一个字体和这段文本所属的语言来寻找 fallback 字体，像 Times 这样的 serif 字体对应的中文 fallback 字体，在 Mac OS X 下是华文宋体 (STSong)；而 Firefox 则会根据 sans-serif 这样的通用 font family 和对应的语言匹配到设置中针对对应语言的默认字体，比如在 Mac OS X 默认的中文非衬线字体是华文黑体 (STHeiti)。Linux 下一般通过 fontconfig 去根据语言、风格等参数来选择 fallback，但不同浏览器的实现还可能有区别；Windows 下则一般会使用系统的 Font Linking 机制，根据注册表内的 FontSubstitutes 信息来寻找。因为在这里不同的浏览器可能有不同的行为，所以建议在 CSS 中写明对应平台该用的字体。

具体的字体选择还有一些不太容易注意的细节，也是各个浏览器差异比较大的一点，可能会出现这样一些问题：

• 是否支持用字体的 PostScript name 选择：如 STHeiti 的 Light 版本又称作 STXihei，或者是否能用 full name 选择：有的浏览器不能正确地将 CSS 里对字体的 font-weight 或者 font-style 等要求映射到特定的字体上，尤其是在字体使用了非标准的 style 命名的情况下，考虑到很多厂商有自己的字体命名规则，这其实很容易出现，像 Helvetica Neue 的 UltraLight, Light, Regular, Medium, Bold 这些不同的 weight，是怎么对应到 CSS font-weight 的 100 到 900 数值上的？这就是特别容易出现 bug 的地方。
• 是否支持按 localized name 选择：比如能不能用 "宋体" 来代表 "SimSun"。以 Mac OS X 下的浏览器为例，Firefox 支持这样的写法，但基于 WebKit 的浏览器一般不支持，这样的问题 CSS 规范没有限定，所以无论哪种情况都是允许的。

总的说来，如果要保证最大限度的兼容性，在 CSS 书写的时候应该尽可能选择明确、不容易出错的写法，尽量少隐式地让浏览器自己确定 (be explict instead of implict)，虽然隐式写法通常比较简洁，但除非你 100% 确定想支持的浏览器在你想支持的平台下都能支持这个写法，否则还是不应该轻易用。

CSS3 新增的 @font-face 规则则是对于现有规则的扩展，提供了 web fonts 功能，但字体匹配算法的逻辑并没有改变，详细的算法可以看 CSS 规范里的说明。

渲染

当确定了字体以后，就可以将文本、字体等等参数一起交给具体的排版引擎，生成字形和位置，然后根据不同的平台调用不同的字体 rasterizer 将字形转换成最后显示在屏幕上的图案，一般浏览器都会选择平台原生的 rasterizer，比如 Mac OS X 下用 Core Graphics，Linux/X11 下用 FreeType，Windows 下用 GDI/DirectWrite 等等。关于这个步骤，typekit 的这篇 blog 可以作为参考。各个浏览器的差异主要来自使用的排版引擎可能对不同的语言支持有差异，调用 rasterizer 使用的参数可能有差异 (比如是否启用 subpixel rendering、使用的 hinting 级别等等)，但在同一个操作系统下的效果差别不会很大。

建议

基于以上的介绍，可以尝试提出一个在现有浏览器下，针对中文用户的，书写 CSS 字体选择规则的建议，如下：

1. 首先确定要选择字体的元素应该使用的字体风格，比如是衬线字体、非衬线字体还是 cursive、fantasy 之类的；
2. 确定了风格之后，先选择西文字体，优先把平台独特的、在该平台下效果更好的字体写上，比如 Mac OS X 下有 Helvetica 也有 Arial，但 Helvetica (可能) 效果更好，Windows 下则一般只有 Arial，那么写 Helvetica, Arial 就比 Arial, Helvetica 或者只有 Arial 更好；
3. 然后列出中文字体，原则相同，多个平台共有的字体应该尽量放在后边，独有的字体放在前面，还需要照顾到 Mac OS X/Linux 下一般用户习惯用(细)黑体作为默认字体，Windows 下习惯以宋体作为默认字体的情况，比如 STXihei, SimSun 这样的写法比较常见，如果写作 SimSun, STXihei，但 Mac OS X 上装了 SimSun 效果就不会太好看。
4. 最后还是应该放上对应的 generic family，比如 sans-serif 或者 serif。
5. 尽量用字体的基本名称 (比如 English locale 下显示的)，而不要用本地化过的名称。除非特殊情况 (Windows 下“某些”浏览器在特定编码下只能支持本地化的字体名称)。Mac OS X 下字体名称可以用 Font Book 查到 (菜单 Preview -> Show Font Info)，Windows 下字体信息在微软的网站可以得到，Linux/X11 下可以使用 fc-list 命令查到。
6. 字体名称中包含空格时记住用引号扩起，比如 "American Typewritter" 和 "Myriad Pro"。
7. 文档开头最好指明语言，比如 <html lang="zh-CN">，可以使用的语言标记参见 W3C 的说明。

• 最喜欢的电影：Inception
• 最喜欢的读物：Out of Mao’s Shadow
• 用得最多的电子产品：Apple iPhone 4
• 参与最多的软件项目：Qt
• 花时间最多的翻译作品：Cocoa 编程开发者手册 (未完成)

总的说来，今年写 blog 少了，写 twitter 多了；花在游戏上的时间少了，出门运动的时间多了；浏览网页泡论坛 BBS 的时间少了，看书的时间多了；做自己个人项目的时间少了，花在工作上的时间多了；这些趋势并不所有都是好的，但至少多读书、多运动，有时间多走走看，正是我对明年的期望。