然而在实际实现中，进度计算是一件伤脑筋的事情，比如 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. 可以在界面中显示从现在开始，如果不间断，将在什么时刻读完这本书

这毫无疑问是一个比较有意思的想法，其实游戏和播放器都经常采用这样的方式 (时间记录和完成时间估计)，但用在书籍、文章阅读时会起到积极的作用吗？会不会有些副作用？不惯怎么说，应该是值得尝试的。

“Classics” is a great product, it shows us iPhone developers what an elegant ebook reader can be, so I bought it almost instantly after it’s released. I’ve been chatting with my friends about this app for a while, now I’d like to give a more closer examination to it from the perspective of a typographer and a programmer. Especially its weaknesses.

Illustrated by my favorite graphic designer, David Lanham, Classics tries its best to provide a traditional book reading experience (that’s why it’s called “Classics”). It contains the following books, even I’ve read most of them in Chinese long time ago, thanks to Classics, it’s still a fascinating experience to read them again in English:

• 20,000 Leagues Under the Sea by Jules Verne
• A Christmas Carol by Charles Dickens [Added in version 1.1]
• Alice in Wonderland by Lewis Carroll
• Flatland by Edwin Abbott Abbott
• Gulliver’s Travels by Jonathan Swift
• The Hound of the Baskervilles by Sir Arthur Conan Doyle
• Adventures of Huckleberry Finn by Mark Twain
• Paradise Lost by John Milton
• Robinson Crusoe by Daniel Defoe
• The Call of the Wild by Jack London
• The Jungle Book by Rudyard Kipling
• The Metamorphosis by Franz Kafka
• The Time Machine by H. G. Wells

However, there are still some details to be improved.

First of all, Classics shows the entire interface in a portrait way, it’s more like traditional books, but has an unavoidable drawback: the iPhone/iPod Touch screen is not wide enough, if you make the characters large enough (otherwise people won’t be able to read them clearly), breaking paragraphs into lines will be extraordinarily hard, you either have to introduce a lot of hyphens, or make the word spacing too loose or too tight. From the following screenshot, we can see Classics made both mistakes.

The spots I marked made the reading experience much worse, if you’re a picky reader like me. And it happens on almost every pages! So why, why couldn’t Classics support landscape mode to improve the situation a little bit?

To understand this, we must first find out how Classics is implemented. Let’s take a look (yeah I know I shouldn’t do such reverse-engineering, but I just can’t help). First, copy it from where it’s saved, expand it as a zip archive:

$ cp ~/Music/iTunes/Mobile\ Applications/Classics\ 1.1.ipa classics.zip
$ unzip classics.zip
    Archive:  classics.zip
   creating: Payload/
   creating: Payload/Classics.app/
   creating: Payload/Classics.app/20,000 Leagues.classic/
  inflating: Payload/Classics.app/20,000 Leagues.classic/0.pdf  
  inflating: Payload/Classics.app/20,000 Leagues.classic/1.pdf  
 ...
  inflating: iTunesMetadata.plist    
  inflating: Payload/Classics.app/SC_Info/Classics.sinf  
  inflating: iTunesArtwork           
finishing deferred symbolic links:
  Payload/Classics.app/CodeResources -> _CodeSignature/CodeResources

OK, now it’s clearer, let’s open up Finder so that you can see it in a more structured way:

See? It turns out every book Classics loads and displays:

1. Is a .classic ended directory with PDFs for each chapter,
2. Contains a Info.plist describes it,
3. Has a cover image called Art.png.

Let’s first look at one of these plists,

$ cd Payload/Classics.app/A\ Christmas\ Carol.classic
$ plutil -convert xml1 Info.plist -o -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>author</key>
    <string>Charles Dickens</string>
    <key>language</key>
    <string>English</string>
    <key>sections</key>
    <array>
        <string>Preface</string>
        <string>Marley’s Ghost</string>
        <string>The First of the Three Spirits</string>
        <string>The Second of the Three Spirits</string>
        <string>The Last of the Spirits</string>
        <string>The End of It</string>
    </array>
    <key>title</key>
    <string>A Christmas Carol</string>
    <key>year</key>
    <string>1843</string>
</dict>
</plist>

So the file contains sufficient metadata for Classics to load this book, but it seems quite “preliminary”, thus, not flexible enough IMHO. For instance, PDF files must be named from 0 to n, each corresponds to a chapter (0 → Preface, 1 → Marley’s Ghost, etc.)

And then, how are these PDFs look? Here is a screenshot taken from Quick Look. pdffonts and pdfinfo from xpdf can give us more information:

$ pdfinfo 0.pdf 
Title:          untitled4
Author:         Phillip Ryu
Creator:        Pages
Producer:       Mac OS X 10.5.4 Quartz PDFContext
CreationDate:   Fri Nov 14 00:12:37 2008
ModDate:        Fri Nov 14 00:12:37 2008
Tagged:         no
Pages:          2
Encrypted:      no
Page size:      216 x 316.8 pts
File size:      27175 bytes
Optimized:      no
PDF version:    1.3

So it’s typesetted manually by Phillip Ryu with Pages, doesn’t sound very high-tech, huh?

$ pdffonts 0.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
VLFBFB+Georgia                       TrueType          yes yes no      10  0
LMPSPR+Georgia-Bold                  TrueType          yes yes no       9  0
BXMTAW+Georgia-Italic                TrueType          yes yes no      19  0

Yeah, the only font family used is Georgia. To admit, I was actually hoping some fonts more suitable for book typesetting, say, Garamond or Sabon.

Enough said, now we have a better understanding of the internal architecture of Classics. As we can see, using PDF for all the books is the chief decision that affects the rest of the app. There are pros and cons for this decision.

Pros:

1. No need to calculate the layout when the user is reading, thus loading a new page will be generally faster than a book reader that loading text and doing layout dynamically.
2. With PDF, one can embeded arbitrary fonts as wish, bypassing iPhone’s limitation. (Classics does not make use of this advantage, sadly.)

Cons:

1. The layout is fixed, no way to adapt it to a screen in landscape mode.
2. Loading PDF through iPhone still has noticeable sluggish, thus, you can’t tap a chapter and have it shown instantly. The worse thing is, there is no way for the developer to optimize it, as long as they still use Apple’s frameworks for PDF rendering.

Except for this, is there anything else can be improved? Yes,

• After compressed, Classics is a 22M beast. Downloading it in bad bandwidth condition can be a problem, not to mention every once it’s updated, you have to download 22M (or even more) again, while most of them you downloaded are just duplicated resource files you already had!

  Even though we can see it greatly simplified application deployment, this part can certainly be improved. For instance, instead of bundle these books with the app, setup a site for it to retrieve books dynamically, books can be downloaded the first time user tries to read, and cached in his Documents directory.

• Pages is definitely not a serious typesetting tool. If I were Phillip¹, I’ll try to build an automatic conversion infrastructure with XeTeX, it will be much easier to maintain, and gives noticeably better text layout results, especially on line breaking, I suspect.