cat jjgod >> log

在印刷排版中，“point”是一个绝对的单位，它等于 1/72 英寸，可以用尺子丈量的，物理的英寸。但在 CSS 中 pt 的含义却非如此，例如我们指定一个字体是 9pt，我们会以为按照 CSS 规范，它等于：

9 * 1/72 = 1/8 inch

这是一个误解，因为我们的显示器被分割为了一个个的像素，单个像素只能有一种颜色 (为了简化，这里暂不讨论次像素反锯齿技术)，要在屏幕上显示，必须先把以 pt 为单位的长度转换为以像素为单位的长度，这个转换的媒介，就是 DPI (事实上，这里的所谓的 DPI，是操作系统和浏览器中使用的术语，即为 PPI, pixels per inch，和扫描仪、打印机、数码相机中的 DPI 是不同的概念)。

例如，无论在哪个操作系统中，Firefox 浏览器默认的 DPI 都是 96，那么实际上 9pt = 9 * 1/72 * 96 = 12px。

所以，虽然“DPI”中的“I”和“1pt 等于 1/72 inch”中的“inch”，都不代表物理上的英寸，但这两个单位互相之间是相等的，也就在相乘中约掉了。

那么，真实的物理长度怎么计算呢？请拿出一把尺子，丈量你的显示器的可见宽度 (我这里是 11.2992 英寸)，除以横向分辨率 (我这里是 1024 像素)，得到的就是每个像素的物理长度。

现在我们可以回答这样一个问题，网页上 9pt 的字体究竟占用了多宽的空间？答案是：

9 * 1/72 * 96 * 11.2992 / 1024 = 0.1324 英寸 = 0.3363 厘米。

有兴趣的朋友可以自己查证一下。

My Favorite，一些怪异或者不太怪异的喜好。

已编码的汉字一共有多少个？

先看看 Unicode 中对汉字的编码 [1]：

首先是基本位面 (BMP) 中的：

• CJK Unified Ideographs: U+4E00 .. U+9FA5 = 20902 个字符
• CJK Unified Ideographs Extension A: U+3400 .. U+4D85 = 6582 个字符
• CJK Unified Ideographs (4.1): U+9FA6 .. U+9FBB = 22 个字符
• CJK Compatibility Ideographs: U+F900 .. U+FA2D = 302 个字符
• CJK Compatibility Ideographs: U+FA30 .. U+FA6A = 59 个字符
• CJK Compatibility Ideographs: U+FA70 .. U+FAD9 = 106 个字符

以上总计 27973 个字符

下面是位面 2 的：

• CJK Unified Ideographs Extension B: U+20000 .. U+2A6D6 = 42711 个字符
• CJK Compatibility Supplement: U+2F800 .. U+2FA1D = 542 个字符

以上总计 71226 个字符，这些是所有已经包括在 Unicode 中的汉字。

• Punct & Radicals: 2E80..U+33FF = 1407 个字符，这些是部首与标点。

以上总计 72633 个字符

也就是说，我们总共能够访问的字符以 7 万左右为上限。

选择字体的原则

正文字体，顾名思义，是给文章主要的内容使用的字体，反过来说，它不是标题字体或者美术字体。所以，正文字体的选择自有其原则，我在下面选取的原则是：

1. 美观，包括屏幕显示的美观与打印效果的美观。
2. 包含足够的字符，这个好理解。
3. 符合授权。先不考虑字体是否通过正常的途径得到，至少使用这个字体的过程必须符合字体的授权。

再详细说说怎么叫美观，相对另外两点，这是一个比较主观的概念，可毕竟也有些共识，或者换句话说，字体至少要清晰、可读性强，能够长时间阅读而不疲劳，这也是我判断的标准。

字体的选择

我选择的字体主要包括这几类：全文使用的字体，强调用的字体、代替斜体 (或意大利体) 在拉丁字体中的类似地位的字体，和表示一段特殊文本 (比如原文引用、代码) 的字体。这基本上涵盖了正文需要使用的全部字体种类。在 TeX 中，以 CCT 文档类 [2] 为例，常见的设定是，全文使用宋体，强调使用黑体，代替斜体的是楷体，表示代码的是仿宋体，所以我也主要测试这四种字体。

选择的字体是我的机器上已经安装的字体，分别来自 Windows XP、Office 2003、Adobe Reader 和方正 GBK 字库。

技术细节

在操作系统、浏览器下的字体显示过于依赖点阵字体，所以这里是不考虑的，那什么算作屏幕显示呢？我测试的是 TeX 文档，使用 dvipdfmx 生成的 pdf，使用 Adobe Reader 7 观看，并打开 CoolType 的效果，所有的测试都是基于同一个 TeX 文档的，你可以在这里下载 (需要 Unicode TFM 文件配合，可以使用 cyperbit 字体的 TFM 或者用 ttf2tfm 工具生成)。打印效果… 应该都不错，但测试起来不大方便，待我有空装上激光打印机先…

怎么判断一个字体包含字符的数量？下面处理的字体有两种，TrueType 和 OpenType (CID)，都可以使用 Microsoft 提供的一个工具 查看其包含字形的数量，当然这里包含的字形不仅仅是汉字，也包括拉丁字符等。至于具体某个代码点有没有字，就不是我一个人能够测试得过来的了。

授权信息主要根据上面这个工具得到的 Embedding 数据和 License 数据。事实上下面遇到的 Embedding 就只有两种：Installable 和 Editable，也是最宽松的两种，Editable 的意思是你可以使用这些字体做 pdf，分发生成的 pdf，并允许别人对这些 pdf 作再加工，但你不能直接分发这些字体，也就是最常见的情况；Installable 的意思是允许收到嵌入该字体的电子文档者也能从电子文档中获取并安装该字体 (.. 这种情况很少见)。

结果

最后

最后… 当然是截图时间了，不过并非上边每个字体都有截图哦。

结论呢？

哦，好像真的是漏了结论，那便写点我自己的看法吧。

宋体中，博雅宋似乎过扁，中宋、标宋过黑，报宋和宋体 (simsun)、AdobeSongStd 都太淡，方正超大字符集收字最全，但在目前我还没搞定怎么让它访问到 CJK ExtB 那些代码点……，在不加粗的情况下，书宋与兰亭宋为最佳。

明体我没有发言权

黑体测试得也不多，主要考虑的还是字形的覆盖，所以不少人喜欢的 KozGoPro 字体没有测试，Mac 下用的丽黑也没有测试，华康等繁体的黑体也没有测试。目前的情况看，黑体的效果都不错。(不过用 FrameMaker 生成的 pdf 中，这几种黑体效果都不好，均有杂色，比较奇怪)

楷体中，标楷体的写法不大符合大陆的习惯，还是以方正楷体比较舒服，收录的字也完善。

隶书和仿宋可以任择。

参考文献

1. Unicode Consortium. UNICODE HAN DATABASE.
2. 张林波. CCT 的 LaTeX2ε 中文文档类.
3. FounderType. 方正字库.

用 FontForge 加粗手头的字体，果然是好慢阿… 我的机器 Pentium 1.4GHz / 512M，掐了一下表，一分钟 256 个字，算起来，方正书宋_GBK 一共 22000 多个字，跑一遍得一个半小时。

Firefox 的内存泄漏问题搞得人心惶惶，Jesse Ruderman 的说法似乎平息了一点怨气，但从我这几天用 nightly build 的结果来看，情况并没有什么好转，看来我们只能把问题归咎于扩展上了。

我现在用的 trunk 版本只启用了这么几个扩展：FlashGot, SwitchProxy Tool, IETab, NoScript, TabMix Plus, AdBlock Plus，几乎是 Firefox 的 addons 网站 上最受好评，也使使用者最多的几个，去年这个时候我写 Reflections on Firefox，过了一年时间，Firefox 方便浏览的功能没有一点改进，我们还是得依靠扩展。可是“They found that Session saver, NoScript, IE Tab, and the combination of FlashGot and Filterset.G Updater cause leaks.”——它们又是导致内存泄漏的元凶，真让人有点进退不得的感觉。

有人总喜欢拿“内存就是拿来用的”这句话来搪塞，我的看法是，这话没错，可是写程序却不是为了制造 bug 的，相信没人愿意明知这个 bug 在那里却不去修改：同样的，明知道可以早一点释放内存，却因为疏忽而没有释放，现在这个 bug 给别人发现了，却用这句话来做挡箭牌，未免无耻了一点，没错，内存是拿来用的，可难道你 Firefox 就天经地义的该占了 300M 的内存，留给其他所有程序用 200M？

再者，我在 about:config 里设置的上限可是 64M…倒真的很奇怪一个连自己最多用多少内存都不能控制的软件居然可以发布。

诚然，David Baron 在 The danger of extensions 中的忧虑是有道理的，Mozilla 本身的源代码管理已经足够混乱，给扩展开发者提供的环境也有够恶劣——连 minor version 的变化都经常使许多 extension 失效，对扩展的代码缺乏监控……如果说去年还是一片大好光景下大家有少许怀疑的话，到现在，扩展，或者说整个 Mozilla 开源社区管理混乱带来的种种问题，已经越来越趋进酿成灾难性的后果了。

是否我们接受开源的优越性的同时，必然接受这样的责罚呢？

这里是目前已经完成的 W3C 词汇表翻译的初版：GBK / UTF-8。

欢迎对其内容提出意见，可以发送到我的邮箱，也可以在这个 post 中回复。其中带“*”号的词汇是我最需要帮助的部分。:)

前些日子写的东东确实少了点，这两天尽量补救一下啦，看来我和大家的时间表是相反的，估计现在大家都应为过年在外边玩吧

布丁长辈完成了 W3C 词汇表的翻译，这份词汇表是根据 W3C Hong Kong 的版本，考虑台湾的用语习惯而调整后得到的。虽然 W3C Hong Kong 提供了简体版本的词汇表，我再考虑我们是不是应该在布丁长辈翻译的基础上，也将这个简体的词汇表进一步完善呢？我会尽快开始这个工作。

更新：目前完成的版本 (仅仅是挑出我不同意的翻译)，GBK / UTF-8。

Jedi 前辈 (呃……在去年 12 月) 写了一篇介绍 Firefox 中配合网页设计的相关扩展的介绍，相信其中有些，虽然你可能已经安装了，也未必了解其功能吧。不妨读读。

再来一条来自台湾的消息，李果正前辈的这篇《樂譜排版軟體簡介》需要排版乐谱的朋友不可错过，其中介绍的大部分工具和 TeX/LaTeX, GNU/Linux 有关。

Mark Boulton 的这篇《更佳排版的五个步骤 (Five Simple Steps to Better Typography)》提出了一些很有新意的观点，对 Web 排版有兴趣的朋友可以读读。虽然部分观点我不大同意，不过这个系列文章还是值得翻译的。