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

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

在 iTextus，也就是 iPad 版本的文本阅读器中，我打算换一种方法，主要的原因是：

• 大家在手持设备中都不喜欢用进度条，因为频繁滑动比较烦人
• 分页方式实现起来比较简单高效，而 iPad 的性能有限

其实从文件载入到显示出来，90% 的时间花费在排版上 (对于 Core Text 程序，就是 CTFramesetterCreateWithAttributedString 这一步)，剩下 5% 用来读取文件，5% 用来绘制排版结果。所以在 iPad 上我们尽可能的减少排版时间，最简单的方法就是把这个时间均摊到每页上，这样每页的排版时间就几乎可以忽略不计了。另一方面，这样也能减少程序的内存占用，在内存紧张的时候可以简单地回收几个页面的排版数据，而不必清空所有的。

既然采用分页方式，进度显示就很灵活了，我们先看看常见的 iPhone 上电子书阅读器是怎么做的。

Stanza 在全屏阅读状态时，除了页面底部用不同颜色显示已读和未读进度比例之外，没有任何其他的提示，这样看起来非常简洁。

触碰页面中部之后 Stanza 会出现一个更详细的界面，包括上方的导航栏提供了书名和作者，中间提示了章节、页数和进度的百分比，下方工具栏还提供了直接通过拖拉跳转页面的功能。

GoodReader 在全屏阅读时干脆什么都不显示，触碰页面中部之后的界面和 Stanza 差不多，不同之处是把页面和跳转进度条放到了左边。

Eucalyptus 采用的是模仿真实书籍的方式，全屏时在页面上方显示书名和页码。

在触碰页面中部之后，Eucalyptus 显示的界面和 Stanza 差不多，更简单一点，中间没有放置任何 HUD 控件，页码放在了下方，而且干脆也不提供任何设置功能了。

Classics 的方式更有趣一些：它没有单独的信息界面，导航栏是一直保持在页面上部的，书名在导航栏上，然而它改写了导航栏，在上面通过颜色区分显示阅读过和尚未阅读的进度比。下方则用浅色显示章节名称和页码。

其他几个阅读器主要是考虑 iPhone 界面空间非常宝贵，导航栏和状态栏没必要随时保持在页面上，把它们在用户要求时单独显示出来反而不容易干扰阅读，而 Classics 这种做法也是可以理解的，因为它复用了导航栏，算是节省了一些空间，这样实现也简单一点。

此外，Stanza 和 GoodReader 都支持横屏显示，而 Eucalyptus 和 Classics 都不支持。

目前我在 iTextus 中实现的是类似 Stanza 的进度提示方式，如下图所示，因为这是最容易实现的，至于最后是否应该选择这样的方式，我还没有决定，也欢迎你的意见。

与进度显示紧密相关的是进度的估计，因为我们既然不能一次排版完所有内容，就必须有个合适的方法估计当前阅读内容的总页数，目前我采用的一个简单的方法如下：

1. 因为我们一次读取整个文件的内容，所以一开始我们就知道当前文件的总长度 (字符数量)
2. 但是每页可能有不同数量的字符 (比如有的页面段落、换行较多，有的则较密集)，可是我们假设平均数量是一个稳定值
3. 总的估计页数 = 文件总的字符数量 / 当前页面平均字符数得到
4. 一开始只排版了一个页面，那当前的页面平均字符数就是第一页的字符数，此后每排版一个新的页面，我们可以让这个平均值更精确一点

经过实际使用的尝试，对于较长的文件 (比如文本长度 100KB 以上的)，这个页数估计是非常精确的，就算偶尔出现震荡也不会超过一两页，不会影响用户对进度的体验。

前不久 Instapaper 的开发者 Marco 提出了一个新的想法：根据时间跟踪和估计进度，大致构思如下：

1. 从用户打开一个新的文件开始，记录用户阅读该文件的总时间
2. 用户的平均阅读速度 = 该文件总阅读时间 / 当前已阅读的页数 (或者字数？)
3. 根据总的页数或者字数和用户的平均阅读速度推算要读完这本书要花费的总时间
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 用，这在目前还没看到类似的工作。

I may write a more detailed article on Core Text typesetting later, stay tuned.

What’s New?

• Updated vim to 7.2.49
• Use Core Text to replace ATSUI for text rendering
• Optimize program startup
• Support transparency option to control background transparency
• Fix cursor redraw on right clicking
• Fix CTRL + SHIFT + ? key handling ( Issue 35 )
• Mac OS X 10.5 only (Since Core Text is a 10.5 only framework)

Download

• googlecode

View Source

• github