In Mac, Programming, Tools, Typography on
16 January 2012 with no comments
一直想写篇 blog 介绍一下常用的、跟字体技术相关的开发调试工具，我一般用 Mac OS X 或者 Linux 开发，所以工具也集中在这两个平台下，也有的是跨平台的。这里只说我自己常用的，欢迎补充。
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 在线游戏，适合在开发之余放松一下大脑 
In Asides on
4 September 2011 with 21 comments
改好 DictUnifier 的 Lion 支持已经将近九点，在奥斯陆的公寓窗外望去，天色已经深沉，地上依旧湿漉漉的，想是小雨还间或下着。这个时节的奥斯陆，气温已经在十度上下徘徊，虽然周围的树叶草坪还绿，冷风已经带上些寒意了。一看上次更新 blog 还是七月下旬，转眼一个多月过去，夏天已经结束了。
去年夏天我结束了三年的研究生学业，一个人跑到远隔万里的奥斯陆来工作，对于生活确实是个极大的变化，但诸般变化总还在计划里，慢慢也就适应了。然而今年夏天对于我生活的影响也许比去年还要大，既然如此，不妨暂且放下这个 blog 向来只更新技术内容的习惯，多记上一笔。
在这个夏天里，我邀请父母来奥斯陆，在我自己布置的公寓住了一个多月，一起游览了挪威的海边小镇 Ålesund、乘船到 Geiranger 峡湾、爬上 Preikestolen；还逛过了巴黎和布拉格，自己则两次到柏林出差，虽然匆忙，也算走过了许多地方，最适合旅游的暑假没有浪费，当然更重要的是在自己安排下带父母出门，这还是平生头一次，其中也有遗憾，但总算走下来了。
这个夏天里我还遇上了自己喜欢的人，认真地开始一段感情，长时间一个人的生活，到现在这种时常牵挂另一个人的心境，其实还颇有一点不大适应，但总归要慢慢学习和成长。
如果要说最大的遗憾，应该是没有花更多时间陪父母，尤其是花在旅程上的时间上多了，计划得略显匆忙，交流其实反而少了。二是因为工作繁杂，生活变化也大，很多原来坚持做的开源项目都没有更新，随着 Lion 的推出都应该陆续完成的，目前已经完成了 TextEdit 和 DictUnifier 的更新，希望接下来继续。
套用《甲方乙方》里那句话，这个夏天过去了，我很怀念它。
In Miscs on
23 July 2011 with 14 comments
昨天下午，奥斯陆市中心发生了大型爆炸事件，我经常经过的一条路两侧一片狼藉；随后在 Utøya 的青年夏令营发生了持枪屠杀事件。已有 87 人遇难。
我与家人目前都还安好，也在积极关注事态的发展，谢谢各位的关心。
可以想见的是，无论这两件史无前例的事件最终调查结果如何，都必然会对挪威造成非常深远的影响。作为旅居的华人，我也会在 blog 和 twitter 上继续介绍我了解到的情况。
In Mac, Programming on
1 July 2011 tagged cocoa, github, uikit with 4 comments
Kyle Neath wrote an excellent piece about the design process of GitHub for Mac. What’s more interesting is his concern about the Mac OS X/Cocoa framework as a whole, it’s the best criticize of Cocoa that I’ve seen for a while, I sincerely recommend any developer interested in Cocoa to read.
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?1
Kyle’s main reasons for not liking Cocoa are as follows:
- Drawing in code is slow and painful. Images are easier to work with and result in more performant code.
- 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.
- There is no styling engine in Cocoa. (To change the background color of a button for instance will require significant changes)
- 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 
