Logitech Z906

Mac 的数字音频输出有两种方式，通过集成的数字/模拟音频输出 3.5mm 口用 TOSLINK 线，或者通过 HDMI。因为我用来放电影的 Mac mini 还是 2009 年的型号，所以用 TOSLINK 是唯一的解法。注意 TOSLINK 相比 HDMI 的限制是由于带宽所限无法直接输出 DTS HDMA 或者 Dolby TrueHD 的音频，但考虑到 OS X 的限制即使是用 HDMI 也无法直接输出这两种格式的，所以也就没啥好说的了。

硬件选择上，一开始考虑选择低端的数字音频解码器，比如 Yamaha RX-V473 或者 Pioneer VSX-527-S，价位相近，2000 ~ 3000 kr。优点是这两款低端的解码器对于我的需求来说都绰绰有余了，而且都支持 7.1 的 HD 音频，日后升级也有余地。缺点也很明显，单有解码器只解决一半问题，至少还得买一套 5.1 的音箱系统来替换我原来用的 Logitech Z523 2.1 系统。

所以再仔细一看 Logitech 现在的产品，替换原来的 Z5500 的这套 Z906 倒是个很好的选择：自带 DTS 和 Dolby 5.1 解码，有数字和模拟音频输入，省掉了解码器的费用，而且本身也正好是一套不错的 5.1 音箱。看看到处评价都不错，就买来试试了，一同买的还有一根 TOSLINK – 3.5mm 线，其中 3.5mm 头接 Mac mini，当然也可以买 TOSLINK – TOSLINK 线然后加一个 TOSLINK – 3.5mm 转接头。

今天收到货，接上之后 OS X 直接就识别出了数字输出 (副作用是这样就锁定了音量，必须通过解码终端来控制音量)，在 XBMC 中也切换为数字输出 5.1 DTS/AC3 音频很顺利的就在 Z906 中正确解码了，唯一需要注意的是 Z906 的“Input”选择必须切换为数字输入对应的端口 (有 3 或者 4 两个 TOSLINK 输入，我用的是 3)。相比原来的音箱，感觉音效果然提升不少。

除了 XBMC 以外，MPlayer X 和 VLC 都应该支持 5.1 DTS/AC3 输出，但其他的应用比如 Mac 下的游戏我还没尝试。另外可以考虑再找条 TOSLINK 线试试用 PS3 玩游戏的效果。

不过 Logitech Z906 的缺点也很明显，不支持 DTS HDMA/Dolby TrueHD 解码，也没有 HDMI 输入输出，相信下一代产品会有改进吧。

上周末有空，就用 Python 写了 opf-cc 这个项目，是 Open Packaging Format Chinese Conversion 的缩写，因为 epub 和 Amazon 采用的 mobi 都只是封装方式，具体的文件布局都是按照 OPF 规范的。这里说说实现的思路。

简繁转换这个问题相对好解决，有现成的 OpenCC 在处理多繁一简或者多简一繁的问题上已经很完善了，所以就稍微修改了一下 OpenCC 的代码直接拿来用了，修改都作为 pull request 已经提交到上游了。

解包 epub 比较简单，因为 epub 实际上就是 zip 压缩包，所以用 Python 的 zipfile 模块直接就可以解压。mobi 的解包稍微麻烦一些，如果不用 calibre 那一套庞大的库，mobiunpack 就是最好的选择。

解包后需要找到应该转换的文件，比较麻烦的地方是有的目录中 href 到的文件名本身就是繁体，如果直接整个目录文件一起转换，就得把文件也对应改名，比较麻烦，这里我尝试用 lxml 来解析目录文件，挑出文本来调用 OpenCC 的 Python 模块进行转换，对于 href 属性的内容则不转换。

重新打包 epub 也简单，用 OS X 的 zip 工具一压就可以了 (更新: fishy 提供了不依赖单独 zip 工具而是直接用 Python 的 zipfile 的实现)，但 mobi 的打包比较麻烦，要么用 calibre 要么用 Amazon 提供的 KindleGen，好处是下载安装一个二进制程序就可以了，坏处是生成的文件大小要比原来的文件大一倍有余，calibre 就没这个问题 (更新: 经 byelims 推荐使用 kindlestrip 来处理 KindleGen 生成的文件，可以去掉冗余的数据)。

总的说来这个项目还有不少可以改进的地方，除了上述两点以外，还有可以加入简体转繁体的功能，也就是给 OpenCC 传一个不同的参数的事而已。不过我设想该有的功能都已经有了，具体应用的时候遇到什么问题再拿来改进。

另外有兴趣的朋友可以提供更方便的封装，比如用 Automator 或者 ThisService 做成 OS X 的 Service，就可以直接在 Finder 里选中文件右键点击转换了。

In my previous post I talked about leaving Nokia and the Qt community. So what am I joining? Turned out I’m staying in Oslo for Opera Software. Why? There are a few reasons.

• When I applied for a job at Nokia, Qt Development Frameworks, I also sent my resume to Opera. But their response came too late (I got a “Your background looks very interesting…” letter after 4 months), by the time I received it, I have finished my interviews at Nokia and almost decided to join them. So I joined the trolls for 2 years. But I have always been thinking what would be like to work on Opera instead. Now I got the chance.
• I joined the trolls expecting to be a Mac developer, but as it turned out I actually focused on the other interest: typography. It’s wonderful to be one of the few typography engineers in the world, but I still want to sharpen my Cocoa skills from time to time. So now I’m actually working full time as a Mac developer for Opera.
• Working on typography is my dream job since I was a child. But I had the fear that I was too familiar with internals of Qt thus afraid of change and learning new things. Now I got the exposure of a whole new area and have to quickly learn a lot of new things — exactly I wanted.
• Doing framework job is a great learning experience, the code has to be so solid and stable and I get to work with many great engineers. But from time to time I wanted to work on some products that are closer to the end user, like a browser. Something that you can go to the party and tell rest of the people what you are working on. (Explaining Qt to non-tech people is not exactly my strength.)

I have worked in the new Opera office for more than a month and so far it has been a really great experience. The work is fast pace, challenging and my colleagues are friendly. The best thing so far is we have free beers on every Friday I will probably write again about my job after a few months and tell you more.

• Passionate co-workers with the amount of dedication I have never seen before. I really enjoyed working with the fellows in graphics team. Many of them have spent more than ten or even twenty years on graphics programming. It is truly a team I’m honored to work with and I learnt a lot from them.
• Really high quality code base with decent workflow (git and gerrit are the best tools and JIRA for bug tracking worked well for me).
• Nice office layout with separated rooms.
• Social activities such as climbing, skiing and movie nights, we also helped each other on moving and hang out together in house warming parties – time spent with friendly and helpful trolls is one of my best memories.
• Free drinks and snacks (I enjoyed the apple juice, chocolate milk and cookies).
• Ice creams for the whole summer, and donuts on the first Friday of every month.
• Lønningspils – a Norwegian tradition: monthly beer drinking on paycheck weekends.
• Table tennis – I guess I let a lot of people down as a Chinese yet played just so so in this sport.
• The 8-core Mac Pro I used as the main development machine.

Things that didn’t work that well includes:

• Pressure from Nokia to do some of the stuff I didn’t enjoy that much and ended up not shipping anything, I surely learnt a lot from it, but still felt that is a waste of time.
• Canteen – It was quite good when I joined, but got much worse from the end of last year when the previous chef left. Terrible soup choices and warm food usually tasted awful.

Anyway, after these wonderful two years, I think it’s time to move on. I want to work on something else now. So I didn’t join most of my colleagues transferring to Digia, but I sincerely think that they have a very good chance of succeed and making “Qt Everywhere” more true than it is. It has been a great ride and if anyone is looking for a job and Digia is hiring, I can recommend it without any hesitation.

I will try to cover what’s next for me in the next post, stay tuned

While his famous lecture Inventing on Principle tackled the idea of making new principles, people are mostly interested in applying that visualization method on IDEs and such. Although most of these efforts are largely experimental, I still find it harsh to dismiss them and consider them as a failure. Live coding is not the point of Victor’s lecture or essay, but it is still immensely better than a dumb editor and cold console that I used to use to learn programming.

(My girlfriend, who majored in landscape design, learned most JavaScript concepts with the rudimentary web editor from Codecademy. She found it engaging and helpful. I doubt she will find it that way if she was given a Unix console and gcc, checking a.out output every time a change was made.)

In the area of learning a new way of thinking, things as simple as live coding can be useful.

What’s more important is how do we progress after grasping basic concepts like iteration and function? While most people think learning programming as a one time effort, I have programmed for more than 10 years and I’m still constantly learning.

Malcolm Gladwell’s Outliers brought us the concept of 10,000 hours of practice. He told us that Bill Joy became a master after practicing programming for 10,000 hours. But what exactly has Bill Joy done in his practice is unknown to us. We all knew that Bill has coded the vi editor and some of the BSD network stack. Did he start practicing from writing a smaller subset of vi or BSD?

The essential question here is how do we learn higher levels of abstraction and design systems more complicated.

First, I personally believe that we need to understand the details to do higher level designs. You won’t be able to design an efficient system without knowing the implementation costs and performance impact of critical code paths. That’s why I usually choose to dive to the bottom and solve/evaluate a few critical issues before looking at the big picture.

However, human mind is not a precise machine that can assemble low level details into high level constructs. After mastering the details sometimes we need to take it away, clear our minds to see a bigger picture, otherwise our heads will be occupied by low level details and have no time to abstract. Contradicted as it is, visualization becomes a really useful tool to hide the details for us.

With visualization as simple as a pie chart, we will suddenly able to free our minds, stand on our previous results and reach higher fruits. That, I think, is the real value of Bret Victor’s idea. What I disagree with him is that his idea doesn’t have to be a groundbreaking rule to revolutionize our ways of programming, the existing tools and IDEs can still equip that as a weapon, to help us tackle even more complex problems.

Imagine code visualization as an amplifier. Without that it is possible to work on certain issues, but with that you are suddenly able to work on harder issues in a more efficient manner.

How to make that really work? Let’s start from small. Take your favorite IDE for example, Xcode can have built-in visualizer for native Cocoa classes such as NSString, NSArray, NSColor and NSFont. The code to show them is already there, just need to find a way to present. Qt Creator can have visualizer for QString, QTransform, QColor and QFont, etc.

For visualizing the states of a program, it works just like our existing debugger with variable watching feature. Except that is presented in a structural way, specific presentation can be given by the programmer himself, just like writing a test case. We can have a drag-and-drop layout interface to do that.

Some of Bret Victor’s ideas (like parameter tagging) can already be achieved with a static analyzer such as clang. Others can only be done in execution. How to speed up execution to avoid setting up a lot of states is the most interesting problem. I think we can try to reduce the amount of input and take an independent block of code (functions without side effects) for examination in an isolated sandbox environment, supplying the required parameters in a simpler way just like preparing for test data sets.

In summary, I still expect that this visualization tool as a programming assistant. An assistant that can take a piece of code, walk through its execution and explain it to me how it works. Even if can only tell how does one variable transits in a loop, it will still be much better than me evaluating it by hand with paper and pencil. In short, hand the repeating tasks over to your machine and focus on something more creative, that’s what we humans are good at.

• 常说挪威是个“社会主义国家”，从我们中学学到的定义“国家控制经济命脉”来说，确实如此，挪威的核心产业基本上都是国家控制或者大力扶持，个人独资的企业极少，比如石油是国家石油公司 (Statoil) 占了绝大多数的份额、铁路是 NSB、航空业老牌的北欧航空 (SAS) 虽然受到很多挑战，但仍占最大份额。
• 相比其他北欧国家，挪威对于农产品有非常大的贸易保护，传统的渔业不说，乳业是由国内的巨头 Tine 控制的，去年因为 Tine 对雨季后产奶量的错误判断造成了整个国家的“黄油危机”，整个圣诞季全国的商店都没有足够的黄油，只能用人造黄油替代，而进口黄油很难进入挪威市场，Tine 不仅是最大的乳业销售商，同时它还占有行业规范制定者的地位，类似“裁判下场打球”，所以国内对此有很多批评。禽业则来自 Prior 占据了超市绝大部分的鸡蛋货架。
• 与工农业的贸易保护同时的，是零售业的封闭，整个挪威的贫富差距虽然较小，但是最富有的人往往是国内的零售业巨头，如 Rimi 等。有观点认为，高物价其实很大部分来自零售业的贪婪，同样的产品，如果在中东超市销售，价格就比常见的联锁超市链的售价要低很多。
• 从中国到挪威，最不习惯的也许是巨大的人力成本差异，从网上购物的邮费或者快递费动辄数百不说，技术工人的收费更是令人咂舌，电工和水管工一小时的收费可以轻易上千，房屋、汽车的维修费用也极高，例如安装汽车尾部的拖车装置就要花费上万。在国内这是很难想象的。
• 虽然整个挪威地广人稀，但首都奥斯陆的人口密度却比北京更高，高人口密度很大程度上来自移民滥用了福利制度。如最近的报导认为短期来挪威工作的人对社会的贡献要比长期的移民多得多，因为短期的工程师等往往有较高工资，纳税但基本上享受不到福利就回去了，而长期移民却有许多长期享受失业和生育福利但从来不工作的。
• 同时这也带来了很多不稳定的因素，来挪威两年，遇到过三次在公交车上偷窃的行为，据办公室的同事说，这在十来年前的挪威是很难想象的，当时的城市用“路不拾遗”形容也毫不夸张。再比如奥斯陆警察以巡逻不必佩枪自豪，但最近大部分的警察也开始佩枪了，当然治安的不稳定因素也不只是移民造成的。
• 挪威的 IT 产业相比美国和许多其他欧洲国家都更陈旧和封闭，相比邻国瑞典对创业的扶持都远远不及，整个产业最多的是 Java、.NET 的企业咨询，应用新技术的创业公司极少，招聘国外的员工也很少。最近见到的负面新闻有整个国家的银行登录系统 BankID 坚持使用 Java applet、投入巨资开发，处理整个国家人口与税务数据的 Altinn 系统闹了大笑话 等等。
• 北欧的医疗保障体系广受赞誉，但身在挪威的人反映这个体制的主要问题是医疗处理的缓慢，造成许多人不夸张病情就无法就医，情况要比在中国糟糕得多。同时也有人利用体系的漏洞，比如威胁转到私立医院来加快就医的速度，或者不得不支付高昂的私人保险来减少排队时间。从某种程度上说，这个体制对于大病是很好的防护网，但对于小病和急诊的待遇其实不如中国的情况。

以上看起来写的都是负面的情况，但都是我自己亲身了解到的，中国国内的报导甚少触及，可以给对北欧有兴趣的人作为参考。

因为前面提到的原因，视频部分可以不转换，所以选择直接 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，等有录像视频时我也会加上链接。