网页 CJK 竖排的最新进展

上个月关于 CSS 的一个重要的新闻是 WebKit 开始支持 CJK 竖排 (通过 -webkit-writing-mode),而且时隔七年之后 (上一个版本还是 2003 年制定的),W3C 的 CSS 工作组也发布了新的 CSS Writing Mode Level 3 工作草案,和以前的版本有较大的区别,WebKit 现在就是按照这个草案实现的竖排支持,虽然它的实现还不完整。下面简单介绍一下新草案的变化。

在原有草案中,writing-mode 属性是 directionblock-flow 属性的合成,你可以交叉地组合这两个属性,构成 writing-mode:比如 lr-tb 表示文字从左到右,块排列从上到下。而在新草案里,block-flow 不再是一个独立的概念,被并入了 writing-mode 中,新的 writing-mode 有以下几种选择:

  • horizontal-tb: 默认情况,从上到下,从左到右的横排书写形式。

    horizontal-tb
    horizontal-tb

  • vertical-rl: 块按从右到左排列,文字则从上到下,这是典型的直排情况。

    vertical-rl
    vertical-rl

  • vertical-lr: 虽然是竖排,但块则从左到右排列。这主要用于内蒙古使用的蒙古语满语

    vertical-lr
    vertical-lr

还可以注意到经过讨论,非常少用的从下往上横排书写形式 (horizontal-bt) 被去除了。

保留了 direction 属性,但它和 CSS2.1 中的效果一样,仍然用于控制文本在行内是从左到右还是从右到左书写,以及 Unicode BIDI 双向混合文字的情况。

同时,新增了一个 text-orientation 属性用于控制行内字符的旋转,例如在典型的中文竖排文稿中,拉丁字符应该顺时针旋转 90 度。目前的草案规定了以下这些模式:

  • vertical-right: 默认的情况,将非文本语言的字符 (比如汉字中间嵌入的拉丁字符) 顺时针旋转 90 度,其他字符不变。
  • upright: 不旋转上述字符,保持和其他字符一样的方向。(这是目前 WebKit 实现的做法,等于什么都没处理)
  • rotate-right: 把所有字符都顺时针旋转 90 度。
  • rotate-left: 把所有字符都逆时针旋转 90 度。
  • rotate-normal: 在 vertical-rl 书写模式中等于 rotate-right,在 vertical-lr 中等于 rotate-left
  • auto: 除了对 SVG1 的 glyph orientation mode 支持以外,其他情况下等于 vertical-right

下图中左侧是 vertical-right/auto 的效果,右侧是 upright 的效果:

最后,新增了 text-combine 属性用于控制在竖排时同一行内要塞进多个非 CJK 字符的情况,在日文排版中称为“縦中横”。它有两个选择:

  • none: 不做特殊处理。
  • horizontal: 在竖排情况下,首先浏览器应该尝试用对应字体中提供的专门的合并后的字形替代,如果没有,则浏览器可以尝试缩小这些字符以适应宽度,或者放弃合并。效果如图:
    縦中横
    縦中横

不过这个属性目前还很不成熟,仅仅初步把概念规范化了,短期内估计不会有浏览器尝试实现。此外这份草案还没考虑行内割注 (日文中称为 warichu) 的情况:

割注
割注

目前在 Mac OS X 下 WebKit 已经完整实现了这一版草案的 writing-mode,大部分的 bug 也都已经扫除 (其他平台的实现情况参见 Koan-Sin Tan 的说明),但是还没开始实现 text-orientation,然而要保证可用的竖排效果,text-orientation 的支持是不可或缺的。

Becoming a Troll

As many of you may have known, since 19th last month, I started working for Nokia, Qt Development Frameworks (formerly Trolltech) as a software engineer. It is my first job. My focus will be the graphics and text rendering area of Qt. Since the work is based at the Oslo office of Nokia, I’ve moved to Oslo, Norway. It is an entirely new environment for me to get used to, also a lot of challenges and fun. As Trolltech people usually call themselves, I can now officially declare myself as a “troll”.

As a side note, I will continue working on my open source projects (vim-cocoa, DictUnifier, TextEdit+, etc.) as usual, though this relocation stuff took most of my energy for a month, updates (including blog updates) will be back to normal soon.

阅读器的进度显示与估计

对电子书阅读器来说,提示当前阅读进度是一项很自然的功能,习惯用电脑的人都常看到进度条 (progress bar) 和滚动条 (scroll bar),如右图是 Textus 中使用的右侧滚动条。

然而在实际实现中,进度计算是一件伤脑筋的事情,比如 Textus 的实现其实很简单:在打开文件时读入整个文件,然后整个交给 Core Text 去排版,将排版后的结果分解为行 (CTLineRef) 记录下来,并将所有行总的高度设置为整个文本视图的高度,这样,每当滚动视图 (NSScrollView) 移动到某个位置时,重绘函数 (-drawRect:) 被调用到,我们根据该位置来判断应该绘制从第几行到第几行的内容,再调用 Core Text 把这些行画出来。

这么做看似很简单直接,结果也很容易保证正确,带来的问题是,每次用户修改设置 (比如调整字体大小、窗口尺寸) 时,就得把整个文件重新排版一遍,即使此时我们只需要看到当前一页的内容。为什么这种方法这么低效,我还一直使用它呢?因为这个实现严格依赖滚动视图给出的位置来判断当前阅读进度,所以总的高度估计必须非常精确,不然随便滚动一下就可能出现错位,而一次算给出整个高度的方法最准确,不容易出错。

Continue reading “阅读器的进度显示与估计”

是否该用 Core Data?

Core Data 是 Cocoa 里面一套非常受欢迎的框架,从 Mac OS X 10.4 提供以来,在 10.5 中引入了完善的 schema 迁移机制,再到 iPhone OS 3.0 时被引入 Cocoa Touch,这套完善的框架都被认为是管理大量结构化数据所首选的 Cocoa 框架,尤其是因为使用 Core Data 能大大减少需要手工编写的代码量,就使它更受开发者欢迎了。

不过最近却出现了一些不同的声音,先是传出消息说 Aperture 3.0 抛弃了 Core Data,改为直接操作 SQLite 数据库 (大家联想到 Apple Mail 3.0 也是直接用 SQLite,没有用 Core Data),但因为都是 Apple 内部的决定,大家只能凭空猜测理由;接下来,NetNewsWire 的开发者 Brent Simmons 也说在 NetNewsWire for iPhone从 Core Data 转向用 FMDB 来操作 SQLite 数据库 (FMDBGus Mueller 编写的一层很薄的 SQLite 在 Objective-C 下的封装),Brent 给的理由就很充分了:他要做的很多操作都是对数据批量进行的,其实不需要把所有数据都保存在内存里遍历执行,那样更慢,直接交给数据库,往往一条语句就搞定了,简洁而且快速。

然后 Jonathan ‘Wolf’ Rentzsch对此深表赞同,并推荐 Aaron Hillegass 的 <a href="http://weblog.bignerdranch doctissimo viagra en ligne.com/?p=232″>BNRPersistence 框架,这个框架用 Tokyo Cabinet 提供了一个类似 Core Data 接口的数据持久化方案,最大的优点是比 Core Data 快得多,根据 Aaron 自己的测试,常见的操作都要快 10 ~ 20 倍。其实快这么多也可以理解,毕竟 BNRPersistence 要比 Core Data 轻量得多,支持的功能也少很多,加上 Tokyo Cabinet 这样的 Key-value 数据库在处理适合它的操作时,多数要比 SQLite 这样的关系型数据库要快。

所以突然 Core Data 就有点被墙倒众人推的意思,好像以前大家都知道它不好用,但都不好意思说,直到突然有经验足够丰富的开发者开头,就一涌而上开始骂了。我个人的观感是 Core Data 作为官方方案,给开发提供的许多便利还是不可小视的,但考虑学起来确实也不容易 (所以才有人专门写本书讲 Core Data),所以新上手的 Cocoa 程序员不妨先考虑一下 BNRPersistence, FMDB 这样的方案。

那是否 Core Data 就该被抛弃呢?目前的争议其实有点像 Web 开发里到底该不该用 ORM,区别是大多数 Web 开发者因为历史原因,对直接进行数据库操作有偏好 (或者说,本能地反感 ORM),而多数 Cocoa 开发者则坚定支持用对象操作数据,所以长远来看,数据持久化方案在 Cocoa (Touch) 开发里少不了,唯一的疑问是 Apple 会不会继续改进 Core Data 的性能和接口,以拉近与第三方方案的差距,只要 Apple 还在不断改进,Core Data 就有学习的必要。

我个人对 Core Data 的怨念主要是在要写的“胶水代码”上:有的时候为了方便与界面的 bindings 操作,不得不给 Model 写大量重复的胶水代码,所以如果第三方的方案如果在这方面有简化,我很乐意改用。

闲聊文本渲染技术的近期发展

在今年 7 月的 GUADEC 上 Behdad Esfahbod 做了一个题为 State of Text Rendering 的讲座,系统地综述了当前文本渲染技术的现状,顺带强调主要由他开发的 harfbuzz-ng 是未来发展的方向,4 个月过去了,最近文本渲染技术有了什么发展呢?这里谈谈我的一些印象和见解。

首先,harfbuzz-ng 到底想做成什么样子?我们知道底层的字体格式支持,开放的有 FreeType 一枝独秀,各平台私有的有 Win32 的 GDI font, Mac OS X 有 ATS 和 CGFont,上层的文本布局排版引擎,现在各家自有一套到两套:Windows 的 DirectWrite 和 Uniscribe;Mac OS X 有 Core Text 和 ATSUI,有 NSLayoutManager;GTK+ 有 pango,都是比较成熟的接口了,那 harfbuzz-ng 是要取代他们吗?

不是,也完全说不通,毕竟 pango 就是 Behdad Esfahbod 自己维护的,没理由拆自己的台。但是开放的 pango 等平台一直缺失的部分是 OpenType 复杂排版特性的支持,这一点 FreeType 没来得及解决,也因为和排版引擎关系太紧密,所以没法完全靠 FreeType 这种“字体格式解析库”来解决。harfbuzz-ng 要做的,正是在原来的 FreeType OpenType 排版代码的基础上,构建一个类似 ICU LayoutEngine 的、有简洁的 C API 的、支持 OpenType 特性的,而且还要比 pango 底层一些的库。

那不是和 ICU 重合了吗?ICU 一来是 C++ 的 API 用着比较累,而来确实也比较笨重,移植的时候够受的。ICU 虽然在近期版本里也开始提供 C 的排版引擎 API,但也只是试验性的。

所以总的看起来,Linux 下的文本渲染层次还真是够多的:GTK+ → pango/cairo → harfbuzz-ng → FreeType,同时 harfbuzz-ng 还可能用到 ICU, Graphite,在 Mac OS X 上还要用到 Core Text 和 Core Graphics。

细分层带来的好处就是不同的需求可以选择合适的 API 来实现:比如你要在图形界面上显示一段文字,就用 GTK+ 的 label;要绘制小段的文本,就用 cairo 和 pango;要高效率的、轻量地绘制大量的文本,就用 harfbuzz-ng 来自己攒一个排版引擎 — 大部分浏览器都是这样,只不过在没有 harfbuzz-ng 的情况下,或者要直接用 FreeType,不得不多写很多代码,或者就用 pango 这种重量级的,性能又得不到保证。

在 8 月份,harfbuzz-ng 的 API 提议已经出现,并在不断讨论中完善 (要我说,本来这个星球上有经验参与讨论的也最多不超过 20 个人,不如大家到一个屋子里开个会搞定得了)。

XeTeX 的作者 Jonathan Kew 虽然仍然在开发 TeXworks,但工作的重心已经放到了 Mozilla Firefox 3.6 的 WOFF 格式和 OpenType 复杂排版支持上,最近的一个视频里 Jonathan 提供了一个很棒的概览,有这样的一些特性之后,在浏览器里做一些认真的文本排版才可能成为现实 — 可惜浏览器仍然缺乏好的断行算法实现。这部分工作其实就是基于 harfbuzz-ng 的。而 WebKit-GTK 版本也开始了基于 harfbuzz-ng 的实现。

当然了,畅想了一番美好未来之后还是要回到现实,目前我想做的一个项目,是开发一套能跨 iPhone OS 和 Mac OS X 的、轻量级的排版引擎,专门给文本阅读器用。这个工作的出发点是:

  1. iPhone 上缺少 (按我的标准) 足够好的文本阅读器,而既然我已经开始写 Textus 了,不如把它移植到 iPhone 上;
  2. iPhone 上没有 Core Text 这个层次的框架,要渲染文本要么用 NSAttributedString,要么用 WebView,他们的额外开销都太多,太重量级了;
  3. 轻量的方法有神秘的 private API CGFontGetGlyphsForUnichars,如果不愿意用 private API 呢,就只好像 cocos2d-iphone 那样自己去实现 cmap 载入的代码,非常痛苦;
  4. 即使这样,也不支持复杂的 OpenType 排版特性,甚至简单一点的连字 (ligature) 都不支持,对于一个文本阅读器这是不能忍受的。

所以觉得写个这样的引擎会比较有用:

  • 做到后端独立,比如可以选用 ICU (iPhone OS 上), Core Text (Mac OS X 上), harfbuzz-ng
  • 能够支持 OpenType 复杂排版特性
  • 至少支持好大部分西方字符和 CJK 字符
  • API 尽可能的简单

最近刚刚开始做一些试验,比如用 Core Graphics 完成了一个简单的 CGFontInstance 给 ICU 用,这在目前还没看到类似的工作。