cat jjgod >> log

MEncoder 是常用的离线编码器，属于 mplayer 项目的一部分，这里介绍了怎样用 MEncoder 编码常见的视频流。

首先，要安装 x264 编码库，mplayer 需要这个库才能加上 H. 264 编码支持:

$ git clone git://git.videolan.org/x264.git
$ cd x264
$ ./configure
$ make && sudo make install

注意 x264 库需要 yasm 汇编器，MacPorts 下可以用 sudo port install yasm 安装。

然后编译 mplayer (包括 mencoder)。

$ svn co svn://svn.mplayerhq.hu/mplayer/trunk mplayer
$ cd mplayer
$ ./configure # 注意输出中是否有 "Checking for x264 ... yes" 字样
$ make && sudo make install

然后就可以调用 MEncoder 了:

$ mencoder input.fmt -o output.fmt -ovc x264 -oac copy -x264encopts \
    bframes=4:b_pyramid:weight_b:pass=1:psnr:bitrate=1500:turbo=1

其中 input.fmt, output.fmt 分别是输入和输出文件，其调用格式见 MEncoder 的文档，而后面 -x264encopts 的参数制定的是 x264 编码参数，这是影响编码质量和速度的地方，文档中也有专门一节详细说明，这里选取的是一个中等偏上的效果。

• 原文: Bringing Debian APT to the iPhone
• 作者: Jay Freeman (saurik)
• 译者: Jjgod Jiang

iPhone (或 iPod Touch) 是一台配备着 128MB RAM、4 到 32 GB 闪存的 667MHz 计算机 (尽管只跑在 412 MHz 上)。软件方面，它运行的是一套裁剪过的 Mac OS X，包括 Darwin 内核上基于 FreeBSD 的用户空间程序，作为其标准组件。虽然部分人可能会奇怪怎么有人会把它作为 Unix 工作站来使，但就我和其他许多人的看法，不拿它来做 Unix 工作站才是值得奇怪的。

BSD 子系统

所以给这台设备头一个安装的包是“BSD Subsystem (子系统)”也就没什么奇怪的了：这是一套标准的 Unix 实用工具，让习惯了 Unix 的开发者感到宾至如归。从 grep, sed 到 vim, pico，这套软件包提供了深夜编程活动的基础。

不幸的是，要真以这样的方式用过一会儿，你肯定会因为这些关键工具配置和编译时的缺漏而感到恼火。尽管完成到现在这样也是件好事，但对 Unix 实用工具的编译打包不应该仅仅停留在“它能安装成功”，而更应该延续到“它能正常工作”。下面是我不得不处理的一些问题:

• bash - 命令在输入完之前就会被截短并执行
• chmod/chown - 总以“memory exhausted (内存耗尽)”作为退出消息
• nc/ping - 无法解析某些域名，并声称 “Unknown server error (未知的服务器错误)”
• netstat - 无法提供任何本地 socket 的有用信息
• passwd - 损坏 BSD 的 /etc/passwd 文件，使 1.1.3 的 SpringBoard 崩溃
• screen - 无法通过 terminfo 找到 “linux” 这样常见的终端类型
• vim - 没有语法高亮，退格键会导致编辑器崩溃

所有这些问题中，仅有 chmod 和 chown 的问题在公开的“BSD Subsystem”包中被修复了，这还是因为 Apple 的 1.1.3 更新带来的巨大压力 (要求所有的软件以 mobile 用户而不是 root 运行，所以必须修改文件的权限，有些程序必须 setuid 为 root)。

然而这些问题只要有人愿意花时间都是很容易解决的，却始终停留在目前这样的状况下，导致工作效率低到了可怜的程度。比如我到现在在 vim 里按下退格键之前还要犹豫一下下，就是因为用了那个损坏的版本开发了几个月所带来的后遗症。所以总得有人来改进吧。

CoreOS - iPhone Unix

剩下这些问题的一部分已经由一名叫 core 的 iPhone hacker 解决了。在他网站的 Unix Tools 部分一直提供了这些改进版本的程序，比如 chmod 和 chown (不过他提供的 passwd 还是坏的)。而在 Network Tools 部分他一直致力于改进 wget 和 ping 等有问题的工具。

可是要安装 core 这些改进过的版本必须分别手工找到、下载并安装修改过的文件：这些工作做一回还好，但三四次 jackbreak 之后再做就肯定觉得非常麻烦了。而人们不一定总是从 core 那儿获得更新，导致实际分发的二进制程序会有区别，因而跟踪起它们的行为来也就分外困难。

最后的一个原因是，core 总是没有时间把他如何神奇地修改这些软件代码的过程写下来，也没有把它用来编译的命令贴在网站上，所以别人没法知道这些问题是怎么被修正的，要修正其他类似的情况是也无法借助他的工作。

一套开放的替代品

为了缓解这些问题的困扰，我决定开始一个名叫 Telesphoreo 的项目，目的是以合作的、开放源代码的方式，给 iPhone 创建一套基于 GNU 和 BSD 的用户空间程序集。这个项目的名字来自于一个古希腊词汇，意思是“使果实成熟”，这正是我对 Apple 这个现有产品的想法：作为电话它是合格了，但要作为个人工作站它还远远不够。当然，要创建这样一个发行，还得使用正确的工具。

为了发行软件，我选择了 Debian 的 APT 系统，这是我在少量修改以配合 Apple 的网络设置后移植到这个平台的。为了方便大量用户的迁移，我还花时间用 UIKit 写了一个 APT 的图形界面，名叫 Cydia (Cydia pomonella 是苹果蠹蛾的学名，而苹果蠹蛾……就是我们常认为的苹果蛀虫，我觉得这个名字挺合适的)。

为令这个项目能够自举 (bootstrap)，我先是移植好了百余软件，从 bash 到 xeyes 的所有东西，包括一系列的支持库和脚本语言 (包括比 Installer 提供版本功能更强的 Ruby 和 Python)。所有为编译所作的代码修改，以及编译整个项目的脚本，都通过 subversion 库 提供。

虽然不是所有的东西都能正常工作，但我已经完成的部分肯定比原来 BSD Subsystem 提供的有了很大进步，也只在很少情况下会比 core 所提供的版本要糟 (不过这个情况很快会解决，因为 core 已经准备将他的更改贡献进来)。如果确实遇到了问题，我建议人们在项目的 Trac 上提交缺陷报告。

如果谁希望出来担任某个现有软件包的维护者，或者提供其他新程序的移植，请加入邮件列表 (译注: 邮件列表还未建立，请通过 IRC 联系作者)。尽管现在是这个新发行版唯一的维护者，我当然不希望一直这样 (既因为缺少对很多领域软件的经验，也因为本就不可能一个人把所有事情做完)。

安装过程

从用户的角度讲，只要将 http://apptapp.saurik.com/ 加入 Installer 的源 (source) 中，然后从它的“System”分类中安装“Cydia Packager”就可以了。你应该在安装前暂时禁用设备的自动锁定 (auto-lock) 功能，因为这个安装过程可能会花上好几分钟。

在安装过程中，下面这些操作会依次进行:

移除 BSD 子系统的旧文件

要替代 BSD 子系统，就得先把它删了，不幸的是在 Installer 里它是不能删除的，所以 Cydia 包管理器只好直接删除所有它安装的文件。不必大惊小怪，就算你非得要回 BSD 子系统，也完全可以用 Installer 来“Reinstall (重装)”它一遍。

重组文件系统以提供足够的空间

为了使升级 iPhone 固件时不会丢失个人数据，Apple 将 iPhone 的存储空间划为两个分区，分别挂载在 / 和 /private/var (它被符号链接到 /var)。前一个分区只有 300MB，所有 Apple 的软件都放在这里。可惜的是第三方软件也必须安装在这里。

为了缓解空间不足的问题，如果安装 Cydia 时发现你在另一个分区 (也就是 4-32GB 里那剩下的部分) 有足够的空间，并确信这些文件并未被 BossTool 这样的工具移动过，就会将你所有的 Applications (应用程序), Wallpapers (墙纸), Fonts (字体), Ringtones (铃声) 和 Shared data (共享数据) 通通移动到那个较大的分区中，原来那个就多出了 150MB 的空间。

安装 Cydia 和 Telesphoreo 基本包

这一步完成后会占用大约 35MB 的空间，并提供了一套常规的 Telesphoreo 子集，以供安装更多的软件包，或者升级已经安装好的部分，又或是执行一些核心的管理操作如运行终端，另外这套子集还能支持现有应用程序对旧有 BSD 子系统的依赖 (我自己、还有许多测试者们一道，给这些依赖库开了一张清单)。

上述的这三个步骤都完成了之后，以后 Cydia 自身和所有的 Telesphoreo 更新都将通过 Cydia/APT 进行，因此你不妨时常打开 Cydia 刷新来源信息看看有没有什么最新的软件。关于更新的更多信息会在下面的使用说明一节介绍。

如果过程中出现了什么错误，你可以提交一个 bug 报告 (要先注册并登录这个站点) 或者来 irc.saurik.com 的 #iphone 频道报告，我平日都在这个频道上边，就算我哪天要出门也至少会查看一次上面信息，又或者是直接给我发邮件请求帮助。(请只在前两个办法不合适的情况下才发邮件，因为前两个都能让其他看到的人帮上你的忙，以节省大家的时间。)

“伪” BSD 子系统

要注意：Telesphoreo 本身不依赖 BSD 子系统，所以如果你目前没装，也没有任何理由在装 Telesphoreo 之前装上 BSD 子系统，而更重要的是，安装过了 Telesphoreo 之后，如果你再尝试安装 BSD 子系统，则会损坏装好的 Telesphoreo (它会用就软件替换你的新系统)。而且，你还应该避免 BSD 子系统的升级 (upgrade)，因为其实这和重装没什么区别，同样会把 Telesphoreo 中关键的组件替换成旧的。

如果你刚刚 jailbreak 完自己的 iPhone/iPod Touch，不必安装 BSD Subsystem，装 Cydia Packager 就够了。如果某个包要用到 Cydia Packager 缺省没有提供的功能，你完全可以以后用 Cydia 装上。

这样和 BSD 子系统包的基本冲突进一步导致了两个需要用户了解的问题：第一个是 BSD 子系统日后的更新都会列在 Installer 的 Updates 中，所以用户有可能会误装这些有问题的旧软件；第二个则是有些软件会在安装前要求 BSD 子系统已被安装，否则它们自己的安装就不能继续。

希望 BSD 子系统会逐渐退休，而那些对它有需求的包则会在未来数月内更新为更聪明一点的检查 (比如判断自己需要的具体是哪些文件)。与此同时，Telesphoreo 也提供了了一个叫做“伪” BSD 子系统的变通方法，它和真正的 BSD Subsystem 的 bundle identifier (Mac OS X 用来甄别软件包的标识符) 一致，但本身不包含任何文件。只要装上了这个包，那些要求 BSD Subsystem 存在才肯安装的应用程序就能顺利装上，还能抑制 Installer 偶尔出现的那些——让你更新 BSD Subsystem 的请求。

虽然我会尽量保持伪 BSD 子系统的版本号和原始那个包的版本号对应，但可能还是会慢上几天，所以 Installer 可能会提示你有 BSD 子系统的更新。你必须避免更新，稍等几天，新的伪造版本就会出现，Installer 的更新提示也就自然会消除了。

Cydia 的使用

一般说来，Cydia 用起来和 Installer 差不多，都是为了让人们快速装上新软件的。主界面由底部的一排按钮组成，让你在下列几个页面间切换。

特色 (Featured)

这个页面是在 Cydia 一启动就显示的，其实是一个包含 Cydia 和 Telesphoreo 使用的相关新闻的站点，还列出了近来一些有趣软件包。虽然目前它只有唯一的页面，不过会迅速成为程序中的一个浏览窗口，让你访问到软件包相关的站点和更详细的信息。

安装 (Install)

在这里你可以按目录的形式浏览未装的软件包，或依分类序、或依字典序。(目前软件包的分类名称还比较混乱，所以如果见到某些怪异的分类，请稍作适应。)

更新 (Changes)

一般你会关心的两件事是：“我已经安装的软件包有没有更新”和“最近更新过的软件里有没有我想装的”。这个页面里就把这两种情况组织到一起了：已装软件的更新显示在上部，其他所有未装软件则按更新时间逆序列在下方。

这第二种使用方式类似 Installer 的“Recent Packages”分类，不过有两点重要的改变。第一，你可以回滚到任意时间点，而不仅仅是查看最近几天的更新。之所以支持这个功能，是因为只有 Installer 的死硬 fans 才会频繁地保持几天一次地查看最近更新，否则就有可能漏掉一些重要的新特性。

第二，一个包只在你第一次看到它之后才被算作被“加入”了，而不是按照它本身加入软件仓库的时间算。这一点也很重要，只要你添加了一个新的软件源，那它的库里所有的包都该被认为是“新”的。这样的定义还能避免每次软件库管理者修改包定义时又把它们推回列表的前头：只有没见过的包才能算是“新”的。

卸载 (Uninstall) 或管理 (Manage)

更为普通一点的 Cydia 使用是找出你已经装过的软件，然后或者重新配置或者重新安装。“Uninstall”界面就是为了这些情况设计的，之所以这么命名是因为 Telesphoreo 目前没用到 APT 的配置 (configuration) 系统，而 Cydia 当然也就不支持。如果这个界面以后有了更多的功能，可能会被改名为“Manage”以更好的表达其特点。

搜索 (Search)

最后一点，你经常会听说某个软件包但不确定它具体叫什么名字，又或者是你希望通过包描述中的信息找到特定功能的软件。这时就要用到“Search”了。只要输入一个字符串它就能依软件包的标识、名称或者描述将匹配的结果列出。

最后还有个放在顶部的界面元素：一个让 Cydia 与所有来源进行本地 APT 数据库同步的刷新按钮。另外顶部还显示了上次同步的时间。我希望以后这个更新的过程能被精简掉：当用户不用 Cydia 的时候同步可以自动在后台进行。如果实现，顶部这栏就完全可以去掉了。

管理来源 (Manage Sources)

Installer 中存在而 Cydia 里没有 (因为 Search 占用了空间) 的一个界面是“Sources”。虽然还没实现出来，但我们的计划是让你在 iPhone 的 Settings 程序里选择这些来源，而不必塞在 Cydia 的界面里。这种交互方式和 Apple 的 MobileMail 比较类似，其中你的帐号也是偶尔在 Settings 里设置了但通常都在 Mail 里访问的。

目前 APT 在 /etc/apt/sources.list 里维护了一个软件来源列表，你可以通过修改它来添加新的来源 (在管理来源的功能实现之前)。还有一个叫做 /etc/apt/sources.list.d 目录用来存放单独的 .list 文件，这样每个都可以简单地通过诸如 Installer 包的形式来安装卸载。

作为过渡，所有屏幕的左上角都有一个带圈的小 i，表示目前缺少的这个功能，并允许通过它你临时把来源添加到 APT 的配置文件中。(如果这带来了什么不便，我很抱歉。)

为何不用 Installer？

我完全能理解的一个质疑是，为何选用 Debian APT 并开发 Cydia，而不是直接用 Installer 来管理所有 Telesphoreo 中的软件包。考虑到 Installer 已经是 iPhone 上经典的软件分发方式：它是几乎所有自动 jailbreak 方式安装的第一个，也是唯一一个软件，并有大量的软件仓库支持，这些仓库一起提供了大量的软件包。

不幸的是，Installer 并非开源软件，就算有这么个许诺，也完全看不到任何相关的发布计划或者其他兑现的方式。Cydia 的源代码则已经提供了出来而其他项目 (比如 MxTube) 也正因此受益。我们也希望 Cydia 能借助开放源代码的优点，迅速得到第三方的补丁或者贡献。

所以一旦考虑到 Telesphoreo 开放的特质，我们实在找不到还用 Installer 作为其安装程序的理由。不过即便如此，这一点还一直是本项目争议最大之处：很多人都来问我，为什么非得创建一个“新”的应用程序分发系统 (APT 的移植) 而不是直接用现成的广泛存在的 Installer。而且，他们对于以后开源的许诺也被用作不要分散 iPhone 开发者精力的理由之一。

我觉得最好的回答是提供看问题的另一个角度：Cydia/APT 和 Installer 并不冲突。我在自己的 iPhone 上这两个程序都会用，也有大量用 Installer 装上的软件。目前为止也没有听说任何要求安装 BSD 子系统的程序因此出现什么兼容性问题，也没有任何理由这么怀疑。最后一点是：完全没有人——包括软件打包的人员和用户——被强制去用 Cydia 来替代 Installer。

我觉得一个关键的问题是人们觉得觉得 Installer 实现了他们以前未曾见过的功能：从许多来源、以单一界面提供了简便地程序安装管理。虽然在 Mac OS X 和 Windows 这两个 iPhone 用户集中的平台上都没有什么这方面的经验，但包管理的概念可一点也不新：几乎所有的 Linux 和 BSD 发行版都依赖着它。再说 Mac OS X 和 Windows 上还有 Fink 这样的第三方软件提供类似的功能 (顺便说一句，Fink 正好也是基于 APT 的)。

因此我专门写了一篇对包管理方式的快速剖析 (译注: 中文版见 AppTapp 的打包问题)，并解释了一些这类系统的复杂情形。这篇文章还包括我个人作为软件打包者在使用 Installer 时遇到的挫折，希望它能阐明高级软件包管理中会遇到的那些问题，以及尝试开发 Telesphoreo 这样一个雄心勃勃的计划意义何在。

总结性评论

尽管有这些问题，我还是相信 Telesphoreo 和 Cydia 对 iPhone 社群会有很大的帮助。就算有人不同意其中某个具体实现上的选择，将关于移植应用程序和库的信息收集到一起也能方便我们把更多高质量的软件带到这个平台上。希望能如我所愿吧。

Chmox 是 Mac OS X 上常用的 chm 阅读软件，它最后一个版本是 2006-10-28 发布的 0.4β，这也是它唯一的一个 Universal Binary 的版本，此后作者就再也没有过更新，因为我和许多 Mac 用户一样，为缺少好用的 chm 所困扰，所以便尝试来对此做一些修正。

主要的更新是参照 ChmSee 的做法修正了一些编码判断的问题，包括目录的编码和显示内容的编码。欢迎对此有兴趣的朋友将 Chmox 无法打开或者打开错误的 chm 发给我 (当然，文件大小尽可能小)，我会尽力修正的。

下面是最近的更新记录 (版本号延续作者原来的定义进行递增):

Chmox 0.4.2

更新:

- 修正某些 chm 文件无法正确载入页面的问题 (faithprice 报告)
- 没有目录时不打开 Drawer
- 提供简单的页内搜索功能

Chmox 0.4.1*

注: 版本号为我按照 http://chmox.sourceforge.net/ 原有版本更新
的，所以这不是官方版本号 (似乎作者本人已经停止维护了)。

更新:

- 更新到 chmlib 0.39
- 修正一些编译警告
- 使用 chm 文件自带的 LCID 信息来判断 CHM 目录的编码，修正在
  解析目录时的一些常见的编码判断错误

下载链接为: Chmox-0.4.2.dmg

更新: 刚刚设立了一个 git 代码仓库，请用 git clone git://gitorious.org/chmox/mainline.git 获取最新代码，访问这里了解项目最新开发进度。

mplayer 是常用的播放软件，其文档对于涉及字幕播放的一些参数不甚详尽，或者留意的人不多，这里对常用选项略作一介绍。

以一个包含了字幕的 mkv 文件为例:

$ mkvinfo ~/Vexille_2077_Nippon_Sakoku.mkv
...
|+ Segment tracks
| + A track
|  + Track number: 1
|  + Track UID: 141444798
|  + Track type: video
|  + Enabled: 1
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 0
|  + MinCache: 1
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: V_MPEG4/ISO/AVC
|  + Codec decode all: 1
|  + CodecPrivate, length 131
|  + Default duration: 41.708ms (23.976 fps for a video track)
|  + Language: jpn
|  + Name: 
|  + Video track
|   + Pixel width: 864
|   + Pixel height: 480
|   + Interlaced: 0
|   + Display width: 864
|   + Display height: 480
| + A track
|  + Track number: 2
|  + Track UID: 3113156519
|  + Track type: audio
|  + Enabled: 1
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 1
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: A_AC3
|  + Codec decode all: 1
|  + Default duration: 32.000ms (31.250 fps for a video track)
|  + Language: jpn
|  + Name: 
|  + Audio track
|   + Sampling frequency: 48000.000000
|   + Channels: 6
| + A track
|  + Track number: 3
|  + Track UID: 3841949375
|  + Track type: subtitles
|  + Enabled: 1
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 0
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: S_TEXT/ASS
|  + Codec decode all: 1
|  + CodecPrivate, length 903
|  + Language: chi
|  + Name: GB
| + A track
|  + Track number: 4
|  + Track UID: 1264721059
|  + Track type: subtitles
|  + Enabled: 1
|  + Default flag: 0
|  + Forced flag: 0
|  + Lacing flag: 0
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 0
|  + Codec ID: S_TEXT/ASS
|  + Codec decode all: 1
|  + CodecPrivate, length 891
|  + Language: chi
|  + Name: Big5
|+ EbmlVoid (size: 1024)
|+ Attachments
| + Attached
|  + File name: Font.TTF
|  + Mime type: application/x-truetype-font
|  + File data, size: 2484512
|  + File UID: 577931698
|  + File description: CN-GB
...

这是一个比较典型的情况: 有两个 subtitles track，分别对应简体和繁体的字幕 (从 Name 分别叫 GB 和 Big5 可以看出)，字幕的格式都是 ASS，并自带了一个附件 (Attachment)，这个附件是一个名为 Font.TTF 的字体文件。*

• 注: 顺带说一句，附带有版权的字体文件是非法的。

mplayer 默认的选项并不能让我们很好地播放这个 mkv 文件，所以需要一些配置。在这里，我首先建议编辑你的 ~/.mplayer/config 文件，而不是通过 MPlayer OSX 这样的图形化前端，因为 mplayer 同时支持用配置文件和用命令行选项来选择参数，前者调整起来要方便一些。

对于中文用户，最常见的一个选项是

subcp=gbk

这表示我们显示地指定将所有字幕文件以 GBK 编码处理，对于大部分中文字幕都是适用的。*

• 注: 近来，在 shooter (射手网) 上提供的字幕有些也会以 UTF-16 格式出现，如果你用 GBK 编码无法成功看得到字幕，可以尝试换用 subcp=utf-16 看看。

• 注 2: mplayer 可以用 enca 库来进行自动编码探测，可惜的是这个库并没有对 CJK 相关语系编码的支持，如果有可能，将 Universal Charset Detector 用在此处或许更好。

对于 ASS 格式的字幕，mplayer 有两种渲染方式，一种是忽略所有的格式信息，将它作为纯文本显示，另一种则是启用格式，一般我们希望使用后者，所以可以加上选项:

ass=1

对于自带字体的情况，默认 mplayer 并不解析它们，只有在:

embeddedfonts=1

时才会解析，所以也建议加上这个选项。

在播放 mkv 文件时，mplayer 默认并不会选择字幕文件的 track，所以我们需要手动用 -sid 0 或者 -slang chi 参数来选择。(你也可以将这类参数写入配置文件，不过在 mkv 不自带字幕时这样的参数不会有效。)

经过上述的调整，mplayer 已经可以很好地播放 ASS 格式字幕和 mkv 媒体文件了，不过还有一种更常见的字幕格式需要调节，那就是 srt。

srt 字幕常以外置文件的形式提供，放在媒体文件同一个目录下，以同样的前缀为名，后缀一般为 .chs.srt, .gb.srt 这样的形式，所以为了让 mplayer 的外部字幕文件查找能够找到这些文件，我们首先就应该加上下面的选项:

sub-fuzziness=1

这个选项的可选值对应:

0 = 不模糊匹配
1 = 匹配任何包含原媒体文件名的字幕文件，但包含原媒体文件名和 slang 所指定语言的优先级更高
2 = 匹配任何字幕文件

所以当同一个目录下有多个语言的字幕时，你可以用

sub-fuzziness=1
slang=chs

这样的配置来优先选择后缀为 .chs.srt 的那个。

对于 srt 字幕文件，一个有用的功能是字体大小的缩放 (因为 srt 本身没有指定字体大小)，经过试验，对于一般 DVDRip (resolution 在 600×300 左右)，用以下参数较恰当:

subfont-autoscale=2
subfont-text-scale=3.5

对于 720p / 1080p 的 HDRe/Remux，则应该将 subfont-text-scale 进一步缩小到 2.5 左右较好。

欢迎补充更多 mplayer 的使用经验。

“All mail clients suck. This one just sucks less.” - The mutt slogan

邮件客户端 (又称为 MUA, Mail User Agent) 似乎是一切用户永远的怨念，因为实在太难找到一个合意的了，这里“一切用户”当然也包括我，事实上，我寻找合适邮件客户端的路程也极为曲折。

自从 1997 年接触网络的时候申请了第一个 (163.net 的) 电子邮箱，当时因为网络太慢，大家都拨号，访问 163.net 花哨的 web 邮局界面登录一次就得等半天，实在太也奢侈。于是研究了半天，参照当时杂志上推荐的 Foxmail 配置了一下，记不得是哪个版本了，当时倒还是挺满意的，于是 Foxmail 伴随我的邮箱由 163.net 到 21cn.com 这么用下来，现在在 Windows 平台下也不失为一个可以考虑的选择。

不过作为一个喜欢排版的人，眼睛总是挑剔的，Foxmail 令我感到恼火的就是你很难选择合适大小的中文字体，众所周知 SimSun 的 9pt, 10.5pt 和 12pt 最佳，可 Foxmail 的选择偏偏跳过了这几个，缺省是一些非常恶心的大小，仅因为这一点，令我非常不爽，于是乘着 Thunderbird 1.0 顺利发布的东风，换成了 Thunderbird。

Thunderbird 也用了挺长一段时间，直到 2.0 版本我都没完全放弃，可用着用着还是发现不对劲，就是我的邮件经常会莫名奇妙的消失，比如收邮件时时，我把一封邮件从 Junk Mail 区拖回到 Inbox，结果收完了邮件 Inbox 里和 Junk Mail 里都找不到这封邮件了！自从 Thunderbird 搞丢我一封重要邮件后，我永久地放弃了 Thunderbird。

放弃了 TB 用什么呢？幸运的是，GMail 横空出世了，一开始也不觉得 GMail 有多好用，无非是大一点，不用删除，但后来用着用着就把所有的邮件都放到了 GMail 的 web 界面中去处理了，为什么呢？

• 有自动的 Spam 过滤，基本不用担心 Spam 的问题
• 邮件全文检索非常方便
• 最后，也是最重要的，thread 组织和浏览实在是太方便了

于是 GMail Web 界面成为了我主要的邮件处理工具，一直用到现在，虽然也积累了一些小的怨念，但还没有大到让我换客户端的程度，包括:

• Web 界面有时会被 ban 掉
• Web 界面还是有点慢，而且不喜欢总要开个浏览器
• GMail compose 出来的 Email 总是怪怪的，发出去的邮件会在奇怪的地方换行
• 没法配置发送纯文本 (8bit) 的邮件和附件
• 最后，也是最严重的，居然不允许用等宽字体查看和编辑邮件

其实最大的原因还是始终找不到合适的客户端，以前 GMail 不支持 IMAP，本地收下来的信和别的地方无法同步，这是完全不能忍的，而自从 GMail 开始支持 IMAP 一来，我试用了:

• Apple Mail, 因为过度的依赖超文本而放弃了，以前不用 Outlook Express 也是基于同样的理由
• mutt: 几个严重的问题: 配置繁琐，自身支持的收发功能都很弱，IMAP 支持也极差，查看邮件的 thread 组织远不如 GMail
• sup: 看起来像个理想的解决方案，把 GMail 界面的思想加入到了字符界面终端下，简直和我想要的界面一模一样，问题是太脆弱和太慢了，要把所有的邮件都下载下来进行全文索引这一步就完全不可接受，我的 GMail INBOX 里近 30000 封邮件用 sup 处理一次要 24 小时。而且只要此后你从 Web 界面动过任意一封邮件，所有的同步工作又白费了，要从头开始。sup 的作者抱怨这是 IMAP 协议的问题
• OfflineIMAP: 因为 sup 的作者说下载下来用 mbox 或者 Maildir 格式它就能很好索引了，结果尝试用 OfflineIMAP 把邮件下载下来，结果发现 OfflineIMAP 也十分脆弱，根本支持不了 GMail 这么多邮件的情况

直到昨天，alpine 的 1.00 版本发布，我终于看到了一个比较可以接受的替代品，alpine 是纯字符界面，满足我对编辑和查看邮件的要求，配置比 mutt 简单得多，也不需要额外安装什么专门用来发信收信的工具，IMAP 支持很不错，甚至连邮件 header 都不需要全部下载就能浏览 INBOX，这一点其它客户端似乎都办不到。唯一的缺点是 thread 组织比 sup 的做法还是差了许多。

我还在试验，学习中，如果遇到什么问题，也许会尝试自己去改进 (当然，只要有时间)，真正“完美”的邮件客户端也许能找到，也许找不到，但寻找的过程本身就很耐人寻味，或许邮件客户端从发明的那一天起，就是要我们学会适应与妥协吧？

把寻找的过程写下来，希望能对别人有用。

开发了将近两周的一个项目终于可以称作正式发布了: Mac Dictionary Kit 的目标是成为一套在 Mac OS X 系统下常用的词典处理与转换工具。虽然在目前它只支持 stardict 格式的转换，但相信随着以后代码的抽象和新格式需求的增加，我们会支持更多的格式，以及更强大、更复杂的转换功能。也尽可能提供更方便的图形用户界面。

目前 MDK 以两个子项目的形式发布: sdconv 是独立的命令行方式转换工具，专门用于 stardict 词典格式到 Dictionary 2.0 词典格式的转换；DictUnifier 是一个图形界面转换工具，它的设计是为了自动探测并支持多种来源格式，虽然目前它也只支持 stardict 格式。

发布在 Google Code 上，主要是为了提供更好的下载服务、更详细的文档和 bug 跟踪。因为这个项目原来参考了 stardict 的代码，所以沿用 GNU GPLv2 发布。

目前，这两套工具提供的都是 Universal Binary，支持 Intel 和 PowerPC 的 Mac 机器。也都是绿色软件，只需要解压/挂载就可以使用。

在这两套工具正式发布之前，得到了水木社区 Apple 版许多版友的测试与 bug 报告，在此表示诚挚的谢意。

这两天做了一些 Nally (MacBlueTelnet) 的修改，主要是让它支持 GBK 编码的 BBS。如果你经常在 Mac 下上 BBS，又对现有的客户端 (Terminal, iTerm, AlienBBS) 的显示正确性/速度/文本渲染效果不满意，可以试一试 yllan 开发的这个 Nally。最大的优点就是用 Core Text 渲染文本，速度特别快，而且字体选择方面专为中文 BBS 优化。我自己已经用它替代使用了很长时间的 iTerm 了。

另外，这是一个开放源码的项目，你也可以用 subversion checkout 下代码做出贡献哦。

Mac OS X 10.5 中，由于 Scripting Bridge 的引入，用 Ruby 或 Python 程序完成原来 AppleScript 才能完成的任务变得非常简单，而因为这两门语言自身的强大，无形中，可以完成的工作也多了不少。比如我们原来可能要用 ID3Mod 这样的软件进行 iTunes Music Library 的歌曲乱码转换，现在写一段不到十行的 Python 脚本就能完成 (当然，界面没有那么方便)。

一个小例子

这里先用 Python 简单的展示一点可以完成的操作:

# 导入必要的模块
from Foundation import *
from ScriptingBridge import *

# 找到 iTunes 这个应用程序
iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")

# 打印出当前正在播放的音乐名称
print iTunes.currentTrack().name()

这段代码在 Leopard 下，既可以保存为 .py 文件，用系统自带的 python 解释器 (/usr/bin/python) 执行，也可以直接在命令行下调用 Python 解释器，查看它的输出，比如我这里是:

$ python
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from Foundation import *
>>> from ScriptingBridge import *
>>> iTunes = SBApplication.applicationWithBundleIdentifier_(”com.apple.iTunes”)
>>> print iTunes.currentTrack().name()
Le Festin
>>> 

注意，执行之前最好先在 iTunes 里开始播放一首曲目。

了解更多

见识了 Scripting Bridge 的威力之后，你很自然的想知道这段代码为何可以工作，应该按什么方式来调用它，除了查询当前播放的歌曲名称以外，还有什么其他的接口可以使用。这时候，我们就需要对我们希望用脚本操纵的程序所提供的 Scripting 接口有个清晰的了解。所以可以用 sdef 这个命令获得一个程序的脚本接口定义:

$ sdef /Applications/iTunes.app
xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dictionary SYSTEM "file://localhost/System/Library/DTDs/sdef.dtd">
<dictionary><suite name="Standard Suite" code="****" description="Common terms for most applications">
...

出现了一长串的怪异信息，太混乱了，看不懂，怎么办呢？这时应该用 sdp 命令过滤一下，生成一个比较可读的格式，Objective-C 头文件:

$ sdef /Applications/iTunes.app | sdp -fh --basename iTunes
$ ls
iTunes.h
$ more iTunes.h
/*
 * iTunes.h
 */

#import <AppKit/AppKit.h>
#import <ScriptingBridge/ScriptingBridge.h>
...

这里就是一个对 iTunes 提供的脚本编程接口的详尽描述了。从这里我们其实很容易看出，原来 iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes") 获得的，是一个 iTunesApplication 对象，以这个对象为出发点，我们可以做到任何 API 允许的事情。下面就是一个例子。

#!/usr/bin/python

from Foundation import *
from ScriptingBridge import *

iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")

for track in iTunes.sources()[0].playlists()[0].tracks():
    print track.name(), track.artist()

简单的观察一下，iTunes 的脚本编程 API 组织是这样的：在 iTunesApplication 下，可以找到多个来源 (iTunesSource)，来源有许多种，比如 music library，比如 CD，比如 iPod 等等，而每个来源里，又按照播放列表 (iTunesPlaylist) 来组织，而每个播放列表中，显而易见地有多个曲目 (iTunesTrack)，在上面这个例子里，我们要找的第一个来源 (sources()[0]) 的第一个播放列表 (playlists()[0])，正是你的 iTunes Music Library。

值得注意的一点是，在 iTunes.h 中用 SBElementArray * 表示的数据类型，一眼可以看出它是数组，在 Python 中处理起来也很简单，直接当成 list 类型遍历即可。

修改数据

那么，查询我们知道了，该怎么把信息写回去，也就是说，修改原来 Music Library 的内容呢？

先来看看 iTunes.h 中的出现的一段:

@interface iTunesTrack : iTunesItem

- (SBElementArray *) artworks;

@property (copy) NSString *album;
@property (copy) NSString *albumArtist;
@property NSInteger albumRating;
@property (readonly) iTunesERtK albumRatingKind;

这里描述的是一个曲目 (它继承了 iTunesItem 类型，所以也继承了它的 name 等属性)，@property 这种写法，是 Objective-C 2.0 中新出现的，也很好理解，(copy) 的意思是你的赋值会被复制一份保存，(readonly) 当然是只读的，而 NSInteger 这种简单的变量也是可以写的。

那么，查询我们知道了，比如这里有个 album 属性，我们就去调用 track 的 album() 方法，但究竟如何赋值呢？还是按照 Cocoa 的 Key-value coding 的老规矩，改成 setAlbum(<参数>)，比如:

>>> iTunes.sources()[0].playlists()[0].tracks()[0].name()
u’Le Festin - Performed by Camille’
>>> iTunes.sources()[0].playlists()[0].tracks()[0].setName_(u’Le Festin’)

这里把一首原来叫做 Le Festin - Performed by Camille 的歌曲名称修正为 Le Festin，回到 iTunes 里一看，果然改了。

系统自带与 macports

在 Mac OS X 10.4 中，由于系统自带的 Python 是老旧的 2.3 版本，所以对 Python 爱好者来说，都往往不得不自己编译一份或者使用 fink/macports 中提供的 Python 2.4/2.5 版本。而在 Mac OS X 10.5 中，终于把自带的 Python 升级到了最新的 2.5.1 版本，对爱好者来说无疑是省事了，可惜这个自带的版本一个令中文用户郁闷的 bug 是：在提示符模式下无法用输入法输入任何中文字符 (相信其他 CJK 字符也是如此)，比如我用输入法打一段：你好 hello 世界 world，等我一确认，Python 解释器只收到了 hello world，中文字符被自动滤掉了！然而，通过 macports 安装的 Python 此功能却是正常的。

这使得我们这里如果要修改中文的歌曲、作家、专辑名等等都变得很不方便，怎么办呢？

系统自带的 Python 的特别之处，其实在于它自带了许多 Apple 添加的模块，比如我们在代码最开始导入的 Foundation 和 ScriptingBridge 模块，这些模块有些不是开源的，有些则还没来得及把代码公开，所以我们机器上只安装有编译好的 Python 模块，然而幸好这些模块是 2.5 版本的，只要我们用 macports 也安装一个 2.5 版本，把系统自带模块的路径给加进去，就能找到并使用它们了。让我们还是用开头那个例子做个简单的示范:

#!/opt/local/bin/python2.5

import sys

sys.path.append('/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python')
sys.path.append('/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjC')

from Foundation import *
from ScriptingBridge import *

iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")

print iTunes.currentTrack().name()

有了上面这些介绍，相信要把这几个工具组合在一起成为一套 iTunes Music Library 的管理利器也不是难事，各位不妨发挥想象力，我就不多说了。

众所周知的是，vim 的代码是 Bram 用 patch 的方式维护的，一种典型的集约式管理，虽然 edyfox 在 https://vim.svn.sourceforge.net/svnroot/vim 维护了 svn 版本，但这也只是导入 CVS 的内容而已，别人无法往里面加入代码，问题是，当你想开发一系列试验性功能时，没法直接在 vim 的 svn 仓库上工作 (比如创建分支)，而只能用自己的版本管理仓库。

这便造成了一个显然的维护问题，以我自己为例，vim-cocoa 的代码原本使用 code.google.com 提供的 svn 服务进行维护，但 Subversion 是以目录为单位跟踪修改的，所以，同一个代码目录，要么来自 vim 的代码仓库，要么来自 google code 的代码仓库，二者不可兼得。

所以我原来使用了一套非常麻烦的维护方式:

$ svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7
$ cp -r vim7/ vim-cocoa/
$ cd vim-cocoa; find . -name ".svn/*" -exec rm -rf {};
$ svn import src/gui_mac.m https://vim-cocoa.googlecode.com/gui_mac.m
...

也就是说，抓下一份 vim 的代码来，复制一份，去掉其 svn 的数据，然后将我修改过的部分导入 google code 的版本仓库。在我完成一部分修改，代码达到稳定之后，再返回 vim7 目录，更新原来用 svn 下载的代码，然后将我在 vim-cocoa/ 下做出的修改 back port 回最新的 vim7 代码里，生成针对最新版本的 patch，并编译，发布。

显然这里要花大量的时间在没有必要的手工操作上，而且很容易出错。这便是 git 该出现的时候了。再简单复述一下我的需求:

1. 能够通过 svn 经常更新到最新的 vim 代码
2. 自己正在工作的 vim-cocoa 分支代码不受影响
3. 能把主干代码和分枝代码按需合并
4. vim 的 svn 库里有些自动生成的文件，应该删除，因为 Bram 不愿意，所以我应该可以在自己的分支里删除，这样可以避免每次 commit 之前需要恢复这些自动生成的文件

下面是用 git 完成的步骤，主要就是利用了 git-svn 这套方便的工具:

$ mkdir vim; cd vim
$ git-svn init https://vim.svn.sourceforge.net/svnroot/vim/vim7
$ git-svn fetch -r 625 # 这里为了减少消耗，不复制整个 svn 版本仓库，只抓最新的 revision

这时 git-svn 会产生一个叫做 git-svn 的 remote branch，并让本地的 master 指向这个 branch。所以，我们可以从 master 分支出一个自己的版本来:

$ git checkout -b cocoa
# 下面是把所有原来 vim-cocoa 做的修改在这个最新版的 vim 代码中打上
$ git commit -m "import vim-cocoa changes into git repo"

此后，如果上游的 vim svn 库更新了，我们可以用 git fetch git-svn 把更新下载下来，然后，用 git merge git-svn 将这些更新 merge 到当前的 branch 里，当然，也可以用 git pull git-svn 把两步合在一起完成，只要你确定 merge 不会出现冲突。

那么，现在就有很好的一个的平台来做本地修改了，但 vim 的一个问题是，src/auto/ 中自动生成的文件也被放在 svn repo 里，这是一个很麻烦的问题，因为 vim 也不支持 off-directory build，所以在我们测试、调试过后，如果要生成 patch，就不得不先把这些 (configure/make 过程中) 必然会生成的文件先恢复到初始状态，无谓的增加了操作，如果在 git 里 commit，也会提示你这些文件更新了，但你显然不愿意把这些改动都算进你的 commit 里，那怎么让这些文件不烦人呢？

简单，我们不管上游的 vim svn 库怎么维护，可以在本地 git 仓库中把这些文件删除，也就是不跟踪的改动了:

# --cached 表示只删除 git 缓存，不删除实际文件
$ git rm --cached src/auto/config.h
$ git rm --cached src/auto/config.mk
$ git rm --cached src/auto/configure
...
$ git commit -m "stop tracking auto generated files"

因为就算这些文件不在跟踪中，一旦它们修改过了，git status 还是会提示你它们更新了，而且这样用 git commit -a 把所有修改过的文件加入下一次 commit 也不方便，怎么办呢？用 .gitignore 文件:

$ vi .gitignore

加入以下内容:

.*.swp
.DS_Store
src/TAGS
src/tags
src/Vim
src/auto/*
src/auto/configure
src/auto/config.h
src/auto/config.mk
src/auto/if_perl.c
src/auto/link.log
src/auto/link.sed
src/auto/osdef.h
src/auto/pathdef.c
src/config.log
src/config.status
src/objects
src/xxd/*
src/Vim.app/*

这样不管这些文件怎么变，git 都不会提示了。

现在我们需要一个用来作为参考的分支，以定期生成 patch，这个分支必须随着上游 svn 的更新而更新，但我们这里删除这些自动生成文件的记录又不应该包含在内，怎么办呢？可以用 git-svn 自动生成的 master branch 来做这件事情:

$ git checkout master
$ git rm --cached src/auto/config.h
...
$ git commit -m "blahblahblah"

这样，以后每次要生成一个独立的 vim-cocoa 分支相对 vim 主干的 patch 时，我都可以先在 master 分支上:

$ git-svn rebase
$ git pull git-svn

然后切换回 cocoa 分支:

$ git checkout cocoa
$ git diff master > vim-cocoa.patch

这样便完整了 patch 的生成。

最后，如果我们需要把现在这个 vim-cocoa 像原来 google code 的代码仓库一样，随时公布到网上该怎么办呢？http://repo.or.cz 提供了公开的代码仓库，申请以后可以获得一个 push 地址:

git+ssh://repo.or.cz/srv/git/vim-cocoa.git

push 需要添加一个用户，然后上传它的 ssh 公钥 (在本地用 ssh-keygen 生成)。然后，如果我要把本地的 cocoa 分支发布到网上，就可以执行:

$ git push git+ssh://repo.or.cz/srv/git/vim-cocoa.git cocoa:master

其中 cocoa 指的是来源 (本地) 分支，master 指的是目的 (远程) 分支，为什么要 push 到另一个名字的分支去呢？因为 master 是 git 默认 clone 下来的分支，为了方便其他用户的抓取，以及 gitweb 的信息显示，还是保持公开仓库里的 master 分支是你最常更新的那个分支为好。

这里介绍在 Mac OS X 中如何用 mac, shntool 和 lame 来完成 ape - mp3 的工作，只需要一个命令就可以完成。

mac 用我以前贴的那个。

shntool 可以 sudo port install shntool，但它的来源网站似乎被 GFW 了，你可以自行下载编译：

$ wget http://www.vi.kernel.org/pub/mirrors/gentoo/source/distfiles/shntool-3.0.2.tar.gz
$ tar zxf shntool-3.0.2.tar.gz
$ cd shntool-3.0.2; ./configure; make; sudo make install

lame 可以用 macports 上的：

$ sudo port install lame

然后这样处理 APE：

$ shntool split -f CDImage.cue -t '%p - %t' -o 'cust ext=mp3 lame --quiet - %f' CDImage.ape

其中 -t ‘%p - %t’ 是指定生成文件的标题，%p 表示 Performer，%t 表示 Title，都是从 cue 中读出的。’cust ext=mp3 lame –quiet - %f’ 表示输出文件用 lame 处理，默认参数，你当然可以在这里调整 lame 的参数。

举例如下：

~/Music/OST - Joe Hisaishi - Kikujiro no natsu [APE] jjgod$ shntool split -f CDImage.cue -t “%p - %t” -o ‘cust ext=mp3 lame –quiet -  %f’ CDImage.ape
shntool [split]: warning: discarding initial zero-valued split point
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Summer.mp3] (6:25.32) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Going Out.mp3] (1:17.35) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Mad Summer.mp3] (2:55.13) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Night Mare.mp3] (1:50.52) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Kindness.mp3] (1:58.23) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - The Rain.mp3] (5:38.70) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Real Eyes.mp3] (3:16.52) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Angel Bell.mp3] (3:13.20) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Two Hearts.mp3] (2:01.33) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Mother.mp3] (2:13.57) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - River Side.mp3] (6:14.40) : 100% OK
Splitting [CDImage.ape] (40:14.15) –> [Joe Hisaishi - Summer Road.mp3] (3:08.38) : 100% OK

-f 参数指定读取切割点的文件，如果不指定则从标准输入读取，所以，如果 cue 文件是 GBK 编码的，我们可以：

$ iconv -f gbk -t utf-8 CDImage.cue | shntool split -t "%p - %t" -o 'cust ext=mp3 lame --quiet - %f' CDImage.ape

就完成了 GBK 到 UTF-8 的转码。速度还是挺快的，估计它用 pipe 来把 mac 的输出送给 lame，因此这两个进程可以并行跑，CPU 能跑到 120% 的样子。

这个办法的好处是非常简单，不需要另外写程序，唯一的缺点是只能依靠 cue 的信息，也没有自动加上 MP3 的 ID3 Tag，不太方便直接导入 iTunes 中，不过我们可以写个后期处理的程序 (比如利用 cue 给出的一些信息，或者用 shntool 输出的 WAVE 信息，调用 freedb/cddb 的服务，或者根据 mp3 来调用 MusicBrainz 的服务) 给它加上 tag。