Wed, 07 Mar 2007 16:20:24 GMT汇聚中国Web标准主题的经验、技巧、智慧与理想！http://www.sharkui.com/wsba/rss/zh-cnzh-cnThu, 08 Mar 2007 00:20:24 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596299/1235569/1/item.html严格来说，JavaScript 其实指的是 Netscape/Mozilla 对 ECMAScript 标准的实现，但考虑到习惯因素，这里就不咬文嚼字了。 目前仍然在开发中的 JavaScript (ECMAScript) 开放源代码的实现包括： JavaScriptCore Apple 开发的 JavaScript 引擎，以 Mac OS X Framework 的形式提供，与 WebCore 一同结合而成 WebKit Framework。JavaScript 是基于 KDE 计划的 KJS 库和 PCRE 正则表达式库开发的。 特点： 强大的垃圾回收器 使用 C++ 开发 基于标准 C/C++ 库和 ICU (IBM 的 Unicode 库) Mac OS X 程序调用它比较方便 采用创建语法树并执行的形式，而不是生成 bytecode 再执行 提供 C, Java (JNI), Objective-C, Qt 的 binding 跨平台，可在 win32 下使用 网站： The WebKit Open Source Project Trac 提供代码 (Subversion), Bugzilla KDE 提供了 kjsembed 库，也是基于 KJS 的，但依赖 Qt (和 KDE)。 SEE 是 Simple ECMAScript Engine 的缩写，提供了 ECMAScript 的解析器和运行时环境。提供到 JavaScript 1.5 (ECMAScript 第 3 版) 的兼容性。 特点： 不直接提供 DOM，但 API 设计时是考虑到了支持 DOM 绑定的 关注正确性与可移植性 网站： SEE 提供代码的 snapshot, Subversion, 邮件列表和 Bugzilla 文档： Using SEE DMDScript Digital Mars 的 ECMAScript 实现，作者是 D 语言的发明者。 特点： 声称要比其他实现都快 有 D 语言实现也有 C++ 语言实现 混合 License (开源软件可以使用 GPL) 加上了 Microsoft Jscript 扩展 网站： DScript 只提供单独的源代码压缩包下载。 有邮件列表，没有版本管理库。 SpiderMonkey Mozilla 的 JavaScript 参考实现，支持到 JavaScript 1.7。 特点： 使用者数量众多，对 JavaScript 和语言扩展支持最快 专门为单独 (standalone) 编译考虑，不需要依赖任何其他的 mozilla 软件/库 要保证线程安全则需要 NSPR 库 向 Adobe 贡献的 tamarin 引擎转移的步骤进行很慢 网站： SpiderMonkey 代码提供压缩包 (从 FTP) 和 CVS。有 Bugzilla。有新闻组。Thu, 08 Mar 2007 00:20:24 +0800Web4Chttp://blog.jjgod.org/2007/03/02/js-implementations-overview/Web4C2007-03-07T16:20:24Zhttp://blog.jjgod.org/2007/03/02/js-implementations-overview/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596299/1235569Thu, 08 Mar 2007 00:20:24 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596300/1235569/1/item.html算来买到 MBP 距今也有 4 个月了，这四个月里我主要做了哪些 hack 工作呢？这里罗列出来，或许你会有兴趣： 因为 OS X 上没有一个文本编辑程序 (ok, let2s forget vim and emacs) 支持自动的编码探测，所以我在 jserv port 的 Mozilla 的编码探测技术 的 charset-detector 基础上稍作修改使之能在 OS X 下工作，并打算修改 open source 的 Text Editor 的代码，使之能够自动探测选择常见的编码。这个工作前一部分已经完成，后一部分打算在这个周末做一做，包括 pack charset-detector 为 Framework 等等。link, binary, source. 因为突然要听 APE (Monkey2s Audio)，但 OS X 下把 APE 转换为 MP3/Apple Loss less/AAC 必须先用 MAC (Monkey2s Audio Console) 将 APE decode 为 WAV 格式。但却没有人提供 Universal Binary 的 MAC。所以就自己修改、移植、编译了一份 MAC for Intel。link, binary. 将 Apple 提供的输入法例子 BasicInputMethod 修改为 Intel Macs 下可编译。link, source. 因为想玩《金庸群侠传》，但 OS X 下先前别人编译的 DOSBox UB 版本却一跑2《金庸》2 就崩溃，于是自己编译了一份新的 CVS 版本。link1, link2, binary. 修改 gVim for Mac OS X，提供完整的中文支持和 ATSUI 渲染功能。并改进对部分中文输入法 (QIM) 的支持。这是最近几天做的，也是最复杂的一个。link, patch, binary. 还有几个未完成或者未 announce 的 project 上面这些项目我都是在一完成后就在 newsmth.org 的 Apple 版发布，我也时常在那儿停留，参与讨论，如果你有兴趣也不妨来逛逛。 Hacking 真是人生最大的乐趣Thu, 08 Mar 2007 00:20:24 +0800Web4Chttp://blog.jjgod.org/2007/03/07/what-ive-done-with-my-mbp/Web4C2007-03-07T16:20:24Zhttp://blog.jjgod.org/2007/03/07/what-ive-done-with-my-mbp/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596300/1235569Sun, 18 Feb 2007 04:20:27 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596301/1235569/1/item.htmlRands In Repose 上有一篇 TextMate 主创者 Allan Odgaard 的 Interview，提及了一个敏感的话题：TextMate 会开放源代码吗？Allan 的答复是，他最终还是决定开公司，不开源，他的观点是： TextMate 已经是部分开放源代码的 (Bundle 部分)。 他本人喜欢设定一个确定的目标，得到一个确定的结果的方式，如果采用开源软件的开发方式，他无法要求参与的开发者都按照他的意愿工作，所以他宁可开个公司。 他还是担心开源了就赚不到钱。 虽然让人有点失望，但这也是正常的思路，你不可能指望所有的编辑器作者都像 Bram Moolenaar 那样去救助乌干达的可怜儿童，所以 InType 早在没有出 Alpha 之前就说他们是肯定要卖钱的，而虽然早有人说靠 TextMate 40 欧元每份的价格，Allan 早已赚得盆满钵满，但还是舍不得开源。 作为一个购买了 TextMate 的用户，我关心的是什么呢？ 我提的问题是不是有人回复 如果没有人回复，我能不能自己去改进它 我最热爱开源软件的地方正是第二点，我可以完完全全地按照自己的意愿去改进它，如果我的改进能被主干接受当然更好，如果不接受也没关系。就拿 TextMate 为例，我被它处理正则表达式的问题困扰，但因为 Allan 去旅行了两个半月，没有人能回答我的问题，结果我只能坐着等 (事实上，Allan 今天刚刚从旅行回来，我甚至根本不知道我两个月前提的问题他会不会看，一想到这一点我就抓狂)，如果困扰我的是 Smultron, Vim, 这样的问题早就解决了。 如果开公司，是可以保证比较稳定的客户服务，但无形中失去了很多程序员的业余贡献，比如我的主业是 Linux 内核驱动的开发，如果 TextMate 开源，我倒是乐于贡献，但要让我去做一辈子编辑器，恐怕就不会原意了。 当然，开源也有很多弊端，软件项目管理本来就是一件很难两全的事情。Sun, 18 Feb 2007 04:20:27 +0800Web4Chttp://blog.jjgod.org/2007/02/14/on-textmate-not-opensource/Web4C2007-02-17T20:20:27Zhttp://blog.jjgod.org/2007/02/14/on-textmate-not-opensource/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596301/1235569Sun, 18 Feb 2007 04:20:27 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596302/1235569/1/item.html我以前总说 autotools sucks，以为只用 make 就能解决一切问题。 最近终于开始做一套比较实用的 (或者说 Insdustrial-strength) 的程序，涉及好几个平台和库，于是 make 的局限性就显现出来了，为了在几个不同的平台下都编译使用，不得不在 Makefile 里写大量判断。 于是开始找跨平台的编译工具，其中最有名的两个是 cmake 和 scons，cmake 之所以出名估计是因为 KDE 4 从 autotools 转向用 cmake 来编译。而 scons 则是 lighttpd 原来用的编译工具，它现在也转向 Python 了。cmake 和 python 大概代表了新一代跨平台编译工具的两种方向。第一种 (cmake) 是延续并改良传统 automake, autoconf 工具链，将之合为一体，但最终仍然生成 Makefile, Visual Studio 的 .sln，Xcode 的 .xcodebuild 文件，依赖现有编译工具 (make, nmake, vcbuild, xcodebuild) 来编译；第二种则是完全消除现有编译工具的调用，直接调用编译器，scons 就属于这一类 (scons 还有一个特点是完全不用专门的语言，控制编译的脚本就是 Python)。 从人气上来说，反倒是走改良路线的 cmake 比 scons 好一些，有几个原因：scons 基于 Python，可能有些代码不是很照顾速度，于是类似 KDE 这样的大项目编译起来会很慢；scons 开发比较慢，最近一直只是 bugfix。不过相对 cmake，scons 的优点是文档非常细致可读，而 cmake 的文档则非常少，可以在网上找到的只有几篇介绍性的文章和参考手册，不像 scons 有一本 User Guide。 与之相关的工具还有 Jam (包括它的变体 FTJam, Boost.Build), Waf, Bakefile 等。其中比较新的 Waf 是一个 scons 的改进，在它的提供的 benchmark 中，显示通过缓存方式可以大大改进编译的速度。不过因为这个项目还很新，目前没有什么软件用它作为编译系统。 Bakefile 走的则是 cmake 的路子，从名称上也可以看出，它最终也是通过生成 Makefile 一类的文件来完成编译的。不过不同的地方在于 cmake 用的语法很像 autotools 用的 m4 的传统语法，而 bakefile 则完全用 XML 来定义编译规则了，这一点倒很像 ant。Bakefile 倒是有不少著名的项目使用，比如 wxWidgets, WebKit, VCF, libxml。 我自己挑来选去，最终决定用 cmake，不过选择的过程写下来，希望能对遇上同样问题的朋友有用。Sun, 18 Feb 2007 04:20:27 +0800Web4Chttp://blog.jjgod.org/2007/02/17/next-generation-build-system/Web4C2007-02-17T20:20:27Zhttp://blog.jjgod.org/2007/02/17/next-generation-build-system/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596302/1235569Sat, 20 Jan 2007 04:20:24 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596303/1235569/1/item.html将在 2 月份出版。(ebook)估计是影印版本，希望最迟 3 月份能拿到。 除此之外，今年期待的书还有： 海因莱因的《异乡异客 (Stranger in a Strange Land)》，不知道什么时候出版，不过按照科幻世界的效率，应该不会太久。 乔治 R.R. 马丁的《冰与火之歌》第三卷《冰雨的风暴 (A Storm of Swords)》，月底出版。 O2Reilly 在 4 月份出版的 Fonts & Encodings。 凤歌的《沧海》，已经在卓越上订了第一册。 今年已经看完和正在看的书有乔治 R.R. 马丁的《冰与火之歌》的一、二卷《权力的游戏》和《列王的纷争》，尼尔 盖曼的《美国众神 (American Gods)》。Sat, 20 Jan 2007 04:20:24 +0800Web4Chttp://blog.jjgod.org/2007/01/19/css-tdg-3e/Web4C2007-01-19T20:20:24Zhttp://blog.jjgod.org/2007/01/19/css-tdg-3e/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596303/1235569Fri, 19 Jan 2007 07:20:16 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596304/1235569/1/item.html有朋友问到 xcp.py 究竟怎么用，是我不对，说了半天连个例子都没举出来，光看两句介绍当然无法理解。我自己记性也不好，怕以后忘了，现在赶紧写下来： \documentclass{article} \usepackage{fontspec} % 定义英文字体，更换为你希望使用的 \setromanfont{Minion Pro} % 定义中文字体，可将 SimSun 更换为你希望使用的字体 \newfontinstance{\zhfont}{SimSun} \newcommand{\zh}[1]{{\zhfont #1}} % 设置中文断行，必备 \XeTeXlinebreaklocale "zh" \XeTeXlinebreakskip = 0pt plus 1pt \begin{document} TeX 提供了一套功能强大并且十分灵活的排版语言，它多达 900 多条指令，并且 TeX 有宏功能，用户可以不断地定义自己适用的 新命令来扩展 TeX 系统的功能。许多人利用 TeX 提供的宏定义 功能对 TeX 进行了二次开发，其中比较著名的有美国数学学会推 荐的非常适合于数学家使用的 AMS-TeX 以及适合于一般文章、报 告、书籍的 LaTeX 系统。 \end{document} 将此文件存为 foo.tex，对它 python xcp.py foo.tex > foo.out.tex xelatex foo.out.tex mv foo.out.pdf foo.pdf 就可以得到你需要的 PDF 啦。如果你有兴趣，还可以看看 foo.out.tex 是什么样子的： \documentclass{article} \usepackage{fontspec} % 定义英文字体，更换为你希望使用的 \setromanfont{Minion Pro} % 定义中文字体，可将 SimSun 更换为你希望使用的字体 \newfontinstance{\zhfont}{SimSun} \newcommand{\zh}[1]{{\zhfont #1}} % 设置中文断行，必备 \XeTeXlinebreaklocale "zh" \XeTeXlinebreakskip = 0pt plus 1pt \begin{document} TeX \zh{提供了一套功能强大并且十分灵活的排版语言，它多达} 900 \zh{多条指令，并且} TeX \zh{有宏功能，用户可以不断地定义自己适用的% 新命令来扩展} TeX \zh{系统的功能。许多人利用} TeX \zh{提供的宏定义% 功能对} TeX \zh{进行了二次开发，其中比较著名的有美国数学学会推% 荐的非常适合于数学家使用的} AMS-TeX \zh{以及适合于一般文章、报% 告、书籍的} LaTeX \zh{系统。} \end{document} 可见导言区都没有修改，只是对正文区进行了预处理。 我们可以打开 PDF 看看，效果如图： 可见中文使用了宋体，英文使用了 Minion Pro，正是我们需要的效果。Fri, 19 Jan 2007 07:20:16 +0800Web4Chttp://blog.jjgod.org/2006/11/25/xcp-example/Web4C2007-01-18T23:20:16Zhttp://blog.jjgod.org/2006/11/25/xcp-example/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596304/1235569Fri, 19 Jan 2007 07:20:16 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596305/1235569/1/item.htmlCocoa Text System，所有 Mac OS X 用户的必读，这篇文章对所有的 Cocoa 软件都有用，非常易读，简洁。 可以参考的还有：Mac OS X Keybindings, Usable Selectors for Cocoa Key Bindings 和 Default Mac OS X System Key Bindings. 可惜还是不能解决它下层的键映射问题，比如右 enter 的作用，fn 键，等等。Fri, 19 Jan 2007 07:20:16 +0800Web4Chttp://blog.jjgod.org/2006/12/03/cocoa-text-system/Web4C2007-01-18T23:20:16Zhttp://blog.jjgod.org/2006/12/03/cocoa-text-system/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596305/1235569Fri, 19 Jan 2007 07:20:16 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596306/1235569/1/item.htmlBrendan Eich 的这篇 Mozilla 2，过了一个多月我才来看。还是有些新内容的。 现在“Mozilla”这个词比较怪，它不再指以前那个“Mozilla Suite”浏览器 (自从 SeaMonkey 分出去之后)，也不专指“Firefox”，更不仅限于“Gecko”渲染引擎 (虽然现在给 Mozilla 起的版本号还是和 Gecko 同步的)，按我的理解，指的是 Mozilla 组织这面大旗下的整个平台的统称，Web 渲染，XUL, XBL, JavaScript, XML/XSL 等许多引擎的统称，而其招牌产品就是 Firefox。 其中，Mozilla 1.9 将对应着 Firefox 3.0，其路线大致已经确定了。Brendan 讨论的是在架构上将有巨大变化的 Mozilla 2，它预期在 2008 年出现。 最引人注目的是基于 JIT 的 JavaScript 虚拟机的出现，加上改进的垃圾回收，将给 JavaScript 的效率 (在 DOM 访问和内存占用方面) 带来巨大提升，据说。同时，它支持的语言会是 ECMAScript 4 (俗称 JavaScript 2)。 其他的改进对普通用户则不大可见，比如放弃 XPCOM，而更多的依赖标准 C++ 的特性来写程序，去掉一些为了兼容性遗留的旧 API，简化代码组织，放弃 CVS 换用新的版本管理工具，等等。Fri, 19 Jan 2007 07:20:16 +0800Web4Chttp://blog.jjgod.org/2006/12/04/mozilla-2/Web4C2007-01-18T23:20:16Zhttp://blog.jjgod.org/2006/12/04/mozilla-2/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596306/1235569Fri, 19 Jan 2007 07:20:16 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596307/1235569/1/item.html随 Adobe Acrobat/Reader 8 发布的中文字体中，出现了一款叫做 Adobe Heiti Std 的，初步使用之下，感觉非常满意。 hei.pdf 是用 XeTeX 生成的一个样例 PDF。下面的图片分别是 Linotype FontExplorer X 下查看到它的一些属性，和几个简繁差异较大的字的写法示例。另外这个字体一共包含 30591 个字形。Fri, 19 Jan 2007 07:20:16 +0800Web4Chttp://blog.jjgod.org/2006/12/06/adobe-heiti-std/Web4C2007-01-18T23:20:16Zhttp://blog.jjgod.org/2006/12/06/adobe-heiti-std/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596307/1235569Fri, 19 Jan 2007 07:20:16 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596308/1235569/1/item.html你有一个好想法，或者你对某件事情很不爽，该怎么吹或者怎么骂呢？我们这里有一个坏的例子和好的例子。Fri, 19 Jan 2007 07:20:16 +0800Web4Chttp://blog.jjgod.org/2006/12/14/how-to-argue-correctly/Web4C2007-01-18T23:20:16Zhttp://blog.jjgod.org/2006/12/14/how-to-argue-correctly/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596308/1235569Fri, 19 Jan 2007 07:20:16 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596309/1235569/1/item.htmlArno Pro 是在 Photoshop CS 3 Beta 1 中出现的一套字体，在我的系统中 (Mac OS X) 安装 PS CS3 后就能在 Font Book 里找到了。Thomas Phinney 是这么说的： Arno Pro 是 Robert Slimbach 设计的 Adobe Original 系列字体之一，它带有现代维也纳怀旧风格 (modernized Venetian oldstyle)，我认为这个字体和 Adobe Jenson 的关系就和 Minion 和 Garamond Premier 的关系一样。展开来说，Arno 对语言的支持是和未来发布的 Adobe 软件保持一致的。这个随 Photoshop CS3 beta 发布的 Arno Pro 也是一个正在测试中的字体，未来可能有改变，比如字体命名方式上的改变。 下面是 Arno Pro 的一个截图和用 XeTeX 排版的一篇短文 (来自 ctex 论坛上 haginile 提供的源文件)。 另外，以 Arno Pro Regular 08pt 为例，我们注意到 Arno 除包含 85 个基本拉丁字符外，还有 91 个 Latin-1 补充字符，127 个拉丁扩展 A 区字符，34 个拉丁扩展 B 区字符。85 个希腊文字符和 132 个西里尔语符。 从字体外形的丰富程度来看，这套字体包括从 Light, Regular, Semibold 到 Bold, Optical Sizes 从 08pt, 10pt, 12pt, 18pt 到 36pt，再加上 Italic 的版本，共 32 款字体。 从风格而言，我个人觉得还是和 Minion 有点像的，不过 Jenson 的味道也确实一眼就能看出来。 另外我这里 (XeTeX 0.995) 似乎没有正确选择 Optical sizes，这一点比较奇怪，因为 Garamond Premier Pro, Minion Pro 这些在这里都能自动选择的，还得查查是源文件错了还是 XeTeX 的原因&Fri, 19 Jan 2007 07:20:16 +0800Web4Chttp://blog.jjgod.org/2007/01/03/arno-pro/Web4C2007-01-18T23:20:16Zhttp://blog.jjgod.org/2007/01/03/arno-pro/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596309/1235569Fri, 19 Jan 2007 07:20:16 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596310/1235569/1/item.html升级到 Wordpress 2.0.6，更换了新 theme，改用 PHP Markdown Extra，并不小心把原来上传的文件都搞丢了&Fri, 19 Jan 2007 07:20:16 +0800Web4Chttp://blog.jjgod.org/2007/01/06/upgrade-completed/Web4C2007-01-18T23:20:16Zhttp://blog.jjgod.org/2007/01/06/upgrade-completed/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596310/1235569Sat, 18 Nov 2006 03:20:25 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596311/1235569/1/item.html虽然很贵，但在 2.0 出来以后买一个也不错。 要是 Vim for Mac 能够好用点该多好&Sat, 18 Nov 2006 03:20:25 +0800Web4Chttp://blog.jjgod.org/2006/11/17/textmate-oaeecoodheuaaae/Web4C2006-11-17T19:20:25Zhttp://blog.jjgod.org/2006/11/17/textmate-oaeecoodheuaaae/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596311/1235569Sat, 11 Nov 2006 10:20:31 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596312/1235569/1/item.html恩，还是得写点什么，在懒惰已经成为习惯，找借口找上瘾了的时候，看到勤奋的 midi 同学 blog 更新之快，我就不由得惭愧啊。 距离上次写 blog 又是两个月了，这两个月发生了什么事呢？ 推研的事情终于尘埃落定，如无意外，明年这个时候我就该在中科院研究生院上课了。未必是最好的结果，也未必是最坏的，还是非常感谢不少朋友和老师的无私帮助。感谢我的父母。 买了一台 MacBook Pro，我和 lukhnos 这么说：新机器到手的时候，真有点手足无措的感觉。有种打开了一个憧憬已久的世界时，突然不知道该干什么的感觉。但也只是一阵子，这一阵子之后，我又给自己的 Mac 学习计划开了一个长长的单子――用 lighttpd 的作者 Jan 的话来说：hey … that’s why we are hackers 申请了水木社区 的 TeX 版斑竹，欢迎大家多支持。 下周又是一堆考试，还有恐怖的 12 分钟长跑，所以，你可以预料到& 下次更新时间不定！Sat, 11 Nov 2006 10:20:31 +0800Web4Chttp://blog.jjgod.org/2006/11/10/something/Web4C2006-11-11T02:20:31Zhttp://blog.jjgod.org/2006/11/10/something/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596312/1235569Sat, 09 Sep 2006 00:20:35 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596313/1235569/1/item.html两个功能 使用 Python 来对 XeTeX 文档进行处理，进行自动的中文与英文字体的切换。 消除两行连续的中文之间多余的空格。 如何获取 从下面的地址下载： http://xcp.googlecode.com/svn/trunk/xcp.py 可以到 http://code.google.com/p/xcp/ 查看相关信息和提交 Issues。 使用方法 现在这个版本应该可以处理任何包含中文的 XeTeX 文档了。使用方法很简单，在文档的导言区加上: \usepackage{fontspec} \setromanfont{Garamond Premier Pro} % 此处指定英文字体 \newfontinstance\zhfont{SimSun} % 此处指定中文字体 \newcommand{\zh}[1]{{\zhfont #1}} 然后调用: python xcp.py foo.tex > bar.tex 编译得到的 bar.tex 即可。 几点说明 默认接受 UTF-8 格式的文档，如果你使用了其他编码，可以修改 xcp.py 第 5 行的 encoding=2utf-82 为你使用的编码，在 http://docs.python.org/lib/standard-encodings.html 可以找到 Python 支持的所有编码。 默认在 \begin{document} 之后才开始处理，到 \end{document} 结束处理，所以记住把 \title{} 之类放在这中间，其中的汉字才能被处理。如果你用的不是 LaTeX 而是 ConTeXt，可以相应的改成 \starttext 和 \stoptext。 需要 Python 2.4。并建议把文件格式转换为 Unix 的。 如果需要避免它处理部分代码，则可以使用 @{} 标记，这样 {} 中间的内容都不会被处理。比如 @{中文} 将被转换为 {中文}，而不是 {\zh{中文}}。Sat, 09 Sep 2006 00:20:35 +0800Web4Chttp://blog.jjgod.org/2006/09/07/xcp-0-2/Web4C2006-09-08T16:20:35Zhttp://blog.jjgod.org/2006/09/07/xcp-0-2/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596313/1235569Sat, 02 Sep 2006 23:20:26 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596314/1235569/1/item.html自从第一部分贴出以来，受到了很多朋友的鼓励，令我感到非常高兴： 看来尽管我拙于表达，对于 TeX 系统的构建感兴趣的朋友还是不少的。不过有一点需要说明：撰写此文的主要目的并非是“构建一个最小的 TeX 系统”，只不过正巧 web2c 系统符合我们讲解的需要而已，我所希望证明的是，TeX 的构建看似复杂，其实也不过是有许多细小的“砖石”一块块搭成，并无什么神秘的地方，尽管大家的兴趣多数是在 TeX 的基础上撰写宏包，但其实参与到 TeX 系统的开发中去也并非那么困难。 web2c 只是用 YACC 写的一套简单的分析程序，由于无法作复杂的分析，所以类似 autotools 的那套“由 A 生成 B，B 生成 C，C 再生成 D”这样化学反应链一般的恐怖过程便被设计出来。 一开始，因为没法直接从 Pascal 代码中分析出其中的变量与函数，所以不得不在一些称为 .defines 的文件中专门说明这些，比如我们如果要用 web2c 转换 etex.p，就得把 common.defines, texmf .defines 和 etexdir/etex.defines 再加上 etex.p 四个文件连接起来送给 web2c 这个程序的标准输入。 然后编写 web2c 的人发现，就算这样还是不好直接通过 web2c 生成的方式搞定所有 C 程序里需要的定义，还是另外把一些内容写在 .h 头文件里，让生成的 .c 程序 #include 它就好了。于是就有一个叫做 texmf.h 的头文件被 C 程序包含，后来这个包含继续复杂化，变成现在这样，C 程序包含 texd.h, texd.h 除了自己的一部分自动生成的内容之外包含 texmfmp.h 和 texcoerce.h，而 texcoerce.h 的内容则是把 web2c 生成的一部分内容再加上一个通用的 coerce.h 连接起来得到的……实在太麻烦也太恶心了，好在我们不需要细究这个，毕竟我们只希望知道，如果要给 TeX 增加代码，对 web 文件的改动，如果增加了变量、函数、过程，则应该在 .defines 文件里增加内容，如果有额外的 C 程序需要链接在一起，则应该找一个被 texd.h 包含的 .h 文件，往里面添加增加全局变量或者函数声明。 分析 web2c/convert 这个 shell 脚本我们可以发现，这个脚本完成了完整的从 Pascal 转换到 C 的过程，一个 tex.p 被分成了三个部分： texd.h (被其他 .c 文件包含的头文件)，事实上，这个文件主要是从对应 .defines 文件里得来，比如 web2c/texmf.defines 就定义了全局变量和函数原型 (prototypes)。对此的分析可以让我们得出结论：如果我们希望把部分模块单独用 C 语言写好，最后再和原来的 TeX 程序链接起来，是可以做到的，只需要在对应的 .h 文件中增加相应的函数声明，并在 Makefile.in 文件中提供正确的链接选项即可。事实上，虽然 eTeX, pdfTeX, Omega 这些 TeX 的扩展都还是用纯 web 语言编写的，但较新的一些扩展，如 XeTeX 和 LuaTeX，都体现了尽量把代码提取出来用 C/C++ 实现的思路。 texini.c: 这是原来的程序中标记了 INITEX 那一部分的代码， 读过 TeXBook 的朋友知道，TeX 可以采用一种特殊的方式把大量的宏定义转换成一种便于以后快速载入的文件 (很像现在的 C 编译器提供的预编译头文件 PCH 的功能)，这种文件就称为 format 文件，而用于生成――在这里叫做 dump――这种 format 文件的程序就是initex。以前 Knuth 的设计是，如果我们把标记了 INITEX 的那部分代码编译进去，生成的程序就叫做 initex，专门用于 dump format，如果不编译进去，就是我们日常运行的 tex，只能载入 format 而不能 \dump。熟悉 C 语言的朋友可以想象成，web2c 里把 #ifdef INITEX 和 #endif 之间的那部分代码提取出来，形成了 texini.c。 顺便说一下，现在的 tex 程序往往都把这个 texini.c 默认就编译进去，不过一定要指定命令行参数 -initialize (-ini) 才会启用这部分功能，事实上平时我们用于生成 format 文件的 fmtutil 这个脚本就是调用 tex -ini 来创建格式的。如果用 tetex/TeXLive，可以打开 kpsewhich fmtutil.cnf 文件查看不同的格式对应的源文件 (如果用 MikTeX，你可以使用 MikTeX Options->Formats 查看)，比如我这里 Plain TeX 格式对应的源文件的内容就是: \input plain \dump \endinput 你同样可以用 etex -ini 启动 TeX 系统，输入上面的内容，手动地生成格式。 tex0.c, tex1.c, tex2.c: 在前面我们提到过，原来的 Pascal 代码足足有 3 万多行，自然，转换出的 C 代码也有 3 万多行，设计 web2c 的时候生怕当时的 C 编译器无法一口啃下这么长的代码，就专门开发了一个叫做 splitup 的程序，把完整的程序切分为三个差不多长度的文件――嗯，叫人很汗的想法。 得到这些文件之后就简单了，只要用 C 编译器编译并链接起来就得到我们平时运行的 TeX 程序。 最后是一幅图，把前边叙述的内容作一小结。下次我们将讨论 TeX 系统中的文件搜索与支持它的核心：Kpathsea。Sat, 02 Sep 2006 23:20:26 +0800Web4Chttp://blog.jjgod.org/2006/09/02/tex-system-construction-2/Web4C2006-09-02T15:20:26Zhttp://blog.jjgod.org/2006/09/02/tex-system-construction-2/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596314/1235569Mon, 28 Aug 2006 00:20:19 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596315/1235569/1/item.htmlMon, 28 Aug 2006 00:20:19 +0800FantasySky Blog - 看我七十二变FantasySky Blog - 看我七十二变2006-08-27T16:20:19Zhttp://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596315/1235569Fri, 18 Aug 2006 00:20:42 +0800http://blog.jjgod.org/2006/08/17/constructing-tex-system/这个东东首发在水木社区的 TeX 版，反响还不错，就贴来大家一同讨论吧 谈谈 TeX 系统的构建过程，不过这个其实挺没意思的，如果只是用 TeX，而不打算修改 TeX 的代码的人完全不需要了解这个，我也不会涉及什么 TeXBook 里的内容，不知道有人有兴趣不？先贴一小段，要是大家有兴趣我就继续贴。呵呵，也算是一个开发了几十年的软件如何演化的一点掌故。 偶尔，你可能会突发奇想：平时自己用的这些 tex, latex, pdftex 是怎么来的？――是怎么写出来的，又是怎么编译出来的？ 愿意究根问底的话，可以先自己动手试一试，目前可以工作的最小的 TeX 系统是 web2c，我们常用的发行版中的二进制程序，都是根据 web2c 中提供的代码，基本不作修改，或者只作很小修改编译而来的，所以，你可以先从 http://www.tug.org/ftp/tex/web2c.tar.gz 下载一份 web2c 的代码，解压开来，听我一步步的讲。 众所周知，Knuth 最早是在一台 DEC PDP-11 上用一种叫做 SAIL 的语言编写的 TeX，尔后他和一些合作者，开始在 Stanford 大学实验一种叫做 literate programming (文学编程) 的新式编程方法，他们设计了一套叫做 WEB 的系统，用 Pascal 语言来编写程序，用 TeX 来编写文档，将两者交织为一张“网”。 经过几年的不断修改，WEB 系统和 TeX 系统相互的影响下逐渐成熟，到 1982 年的时候，两者都基本上稳定下来，此时的 TeX 系统，核心就是一个 tex.web 文件。OK, 看看你刚刚解压出来的 web2c 目录下是不是有这么一个文件？那就是 Knuth 亲手写的，原封不动。 WEB 系统中有两个独立运行的程序，一个叫做 tangle (扰乱？) 一个叫 weave (编织？)，运行 tangle tex.web 将生成一个叫做 tex.p 的 Pascal 程序，这个程序可以用任何现代的 Pascal 编译器编译；而运行 weave tex.web 将生成 tex.tex，你可以用自己系统里已经安装的 tex 来 tex tex.tex 得到这个程序的文档：tex.dvi。 我相信很多人看到这里就会觉得相当无聊，那不妨认为你现在用的 TeX 系统就是这么来的句号。如果你坚持到现在还在继续看，那就可以接下去看更完整一点的故事。 Knuth 当时写着写着，居然写了一个三万多行代码的文件出来 (灌水王啊~) 这已经很恐怖了，可是后来大家要接着在他后边修改就很累了，他自己也得做 bug fix 不是？所以就给 WEB 系统添加了一个功能：合并主程序和 change file 的功能。 其实这个 change file，和我们现在常用的 diff 出来的 patch 结构也差不多，无非是原来代码的上下文，和要修改成的代码。比如在 tex.ch 里，你可以看到: @x 原代码 @y 新代码 @z 这就是一个完整的修改单元。tangle 和 weave 都同时接受主程序和 change file 两个参数，将两者归并起来再行生成 Pascal 程序和 tex 文档，也就是说，实际的编译过程是这样的: tangle tex.web tex.ch 得到 tex.p weave tex.web tex.ch 得到 tex.tex 可是后来，Knuth 又说，TeX 这个程序应该 freeze 下来，大家不要再改了啊，想改，就换个名字，不要再叫做 tex 了。所以后来陆陆续续就出现 etex, omega, pdftex 等等增强版本，可是大家做这些增强版本的时候，也不好意思直接在 Knuth 的代码上改啊 (恩，大牛写的代码只能拜)，就纷纷创建自己的 change file。渐渐的 change file 就多了起来，比如 XeTeX, 要归并的 change file 有四五个之多，可是 tangle 和 weave 都只支持一个 change file 啊，于是就有人写了一个叫做 tie 的程序，专门做这种归并工作 (和 Larry Wall 写的 patch 一样)，你可以指定一个主文件和 9 个以内的 change file，按顺序一个一个归并起来。 所以我们看 etex 的编译过程 (在 etexdir/etex.mk 这个 Makefile 里可以看到)，就是先: tie -m etex.web tex.web etex.ch etex.fix 得到 etex.web，然后 tangle etex.web 得到 etex.p 的。 可是 Knuth 开发 TeX 的那个时代 C 还没有获得大众 (OK，如果计算机科学家也算作大众的话) 的欢迎，也许因为 Knuth 本人和 Nicklaus Wirth 关系也比较铁，WEB 就优先选用了 Pascal 语言来编写 TeX，然而到了 90 年代，Pascal 渐渐退出了大家的视野，尤其在 Unix 系统下，C 更是金科玉律一般没有任何其他语言能替代，考虑到普及的原因，也考虑到方便与其他 C 语言编写的模块一同链接的原因，一班人开始考虑把 TeX 的代码转换为 C 的可能性，这就产生了 web2c。(web2c 一位长期的维护者 Karl Berry 就是现任 TUG 主席，也是 TeXLive 的主要维护者之一。) 最直接的办法就是把 tangle 后的 Pascal 代码转换为 C 代码，web2c 也正是如此设计的，毕竟 Knuth 当时为了保证尽可能的方便移植，几乎没有用到只有 Pascal 语言才有的特性，所涵盖的功能现代的 C 编译器 都已具备。所以他们采取的方法就是用 lex 和 yacc 写出了一个把 tangle 输出转换为 C 代码的程序。 那么，究竟应该如何调用 web2c 来生成 C 代码呢？生成出来的代码又该如何编译呢？且听下回分解。Fri, 18 Aug 2006 00:20:42 +0800Web4Chttp://blog.jjgod.org/2006/08/17/constructing-tex-system/Web4C2006-08-17T16:20:42ZSat, 15 Jul 2006 13:51:28 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596317/1235569/1/item.htmlJavaScript是面向对象的么？是么？不是么？先来了解一些你可能不知道的特性吧。Sat, 15 Jul 2006 13:51:28 +0800Articles - SharkUI.comhttp://www.sharkui.com/articles/article.php?id=44Articles - SharkUI.com2006-07-15T05:51:28Zhttp://www.sharkui.com/articles/article.php?id=44http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596317/1235569Fri, 23 Jun 2006 00:51:24 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596318/1235569/1/item.html域名由 jjgod.3322.org 改变为 blog.jjgod.org (原来的仍然可用)。Thanks a lot to lukhnos & dfbb. 在 http://feeds.feedburner.com/jjgod/blog 这里提供一个固定的 RSS feed。 BTW: 还没想好 jjgod.org 这个根域名用来放什么，有建议吗？Fri, 23 Jun 2006 00:51:24 +0800Web4Chttp://blog.jjgod.org/2006/06/22/blog-jjgod-org/Web4C2006-06-22T16:51:24Zhttp://blog.jjgod.org/2006/06/22/blog-jjgod-org/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596318/1235569Thu, 22 Jun 2006 19:51:23 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596319/1235569/1/item.html在印刷排版中，“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 厘米。 有兴趣的朋友可以自己查证一下。Thu, 22 Jun 2006 19:51:23 +0800Web4Chttp://blog.jjgod.org/2006/02/24/misleading-length-unit/Web4C2006-06-22T11:51:23Zhttp://blog.jjgod.org/2006/02/24/misleading-length-unit/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596319/1235569Thu, 22 Jun 2006 19:51:23 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596320/1235569/1/item.htmlMarkdown 是 John Gruber 精心设计的一套文本标记系统，由 Michel Fortin 转换到 PHP 并提供了 WordPress 的插件。这两天抽空翻译了一下 Markdown 的基本功能以备学习。感谢 hlb 的指点，我想下面要做的大概是翻译完整的 syntax 文件和 PHP Markdown 的扩展功能。此外，MultiMarkdown 也是个有趣的东西。 噢对了，翻译后的文件在这儿。Thu, 22 Jun 2006 19:51:23 +0800Web4Chttp://blog.jjgod.org/2006/03/13/translate-markdown/Web4C2006-06-22T11:51:23Zhttp://blog.jjgod.org/2006/03/13/translate-markdown/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596320/1235569Thu, 22 Jun 2006 19:51:23 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596321/1235569/1/item.htmlMicrosoft 在 (或者将在) Windows Media Center Edition, Windows Vista 和 Office 2007 中替代 Tahoma 作为界面和菜单的默认字体的就是现在看到的这个 Segoe UI。毫无疑问，它可以和 Tahoma 区分得很清楚，取代 Tahoma 的尖刻的圆角和 Trebuche MS 有几分相似――wikipedia 上是这么说的。 然而 Linotype 公司声称它与 Linotype 的 FrutigerNext 是一模一样的。看下面的对比，真的是几乎一模一样啊 (黑色的是 60pt 的 FruitigerNext，灰色的是 56pt 的 Segoe UI)： Wikipedia 上还提到，Microsoft 在 2004 年尝试在欧盟将 Segoe 和 Segoe Italic 注册为原创性字体设计，Linotype 提出了抗议，在 2006 年二月，欧盟拒绝了 Microsoft 的注册请求。Microsoft 承认 Segoe 和 Frutiger 是一样的，但却声称 Linotype 在 2004 年以前没卖过 Frutiger 和 FrutigerNext (这个理由真 faint)，这个说法还是被欧盟拒绝了。 那么现在究竟 Microsoft 会不会撤掉他们预先说好要在 Vista 和 Office 2007 中出现的这个字体呢？或者 Microsoft 与 Linotype 达成和解，同意给每份 Vista 的 copy 支付一个美分的授权费用？(先前 Microsoft 是在 Reader 软件中为 Frutiger Linotype 这个字体支付的授权费用。) 在网页上的比较可能会比较符合 Microsoft 的心思，不过我的测试是发现 Frutiger Linotype 和 Segoe UI 的效果差不多 (难道 Vista 上 ClearType 的改进又会带来变数？)，但 Frutiger Linotype 的 descenders 明显一点，Segoe UI 的 ascenders 明显一点，相比起来 Segoe UI 不那么“扁”，看起来会更顺眼。 引用一份 FrutigerNext 的小册子上说的： 1970 年初，当巴黎计划建设 Roissy Charles de Gaulle 机场时，他们发现机场的信号标识需要一个清晰可辨的字体。导航系统的设计落到了 Adrian Frutiger 的头上，结果是……太成功了，不仅导航系统需要这个新的字体，许多常规的书籍印刷同样需要。1977 年，这个字体以 Frutiger 的名字命名，进入了 Linotype Library。它不仅为机场信号，更为所有希望在字号较小时达到清晰可辨的字体设立了一个标准。 ……创造出一个既有吸引力又富动感的字体。经过加强的 ascenders 和 descenders 更显可读性，小写字母和数字在一行上排布得很整齐。Linotype Frutiger NEXT 在 Frutiger 的基础上，使笔画与宽度更为协调，各种粗细的版本放在一起显得更为融洽而不突兀。 从传统的字体设计角度上来说，Segoe UI 当然和 Frutiger/Next 脱不了干系，可是如果从纯技术角度上来说，我们不妨反思这样一个问题：字体的版权应当如何保护，类似 Microsoft 这样，为 ClearType 所优化的 hinting 算不算版权中的一部分呢？Thu, 22 Jun 2006 19:51:23 +0800Web4Chttp://blog.jjgod.org/2006/04/17/on-segoe-ui/Web4C2006-06-22T11:51:23Zhttp://blog.jjgod.org/2006/04/17/on-segoe-ui/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596321/1235569Thu, 22 Jun 2006 19:51:23 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596322/1235569/1/item.html真的是.. a mess，估计就像 pango maillist 上有的人说的，有能力使用 layout engine 的人都能够直接看 reference 写程序，没能力的都去用 GUI Toolkit 提供的 high-level API 了。 最近看的几个 layout engine 包括：Uniscribe, Graphite, Pango 和 ICU。最惨的是它们的定位和功能还不一样，有些相互之间还有牵扯。 就是这样居然还有人能把 Graphite, ICU 和 ATSUI 集成起来给 TeX 用，考虑到 TeX 还是用 WEB (Pascal 的 literate programming 版本) 语言写成的，这真是让人崇拜得五体投地的强者啊。 (看了一下强者的 biography，原来自从我出生开始就在 SIL 工作了.. 那么这样我比较不自卑一点。) 更新：看完这篇 mail，我又很高兴了Thu, 22 Jun 2006 19:51:23 +0800Web4Chttp://blog.jjgod.org/2006/04/17/layout-engine-document/Web4C2006-06-22T11:51:23Zhttp://blog.jjgod.org/2006/04/17/layout-engine-document/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596322/1235569Thu, 22 Jun 2006 19:51:23 +0800http://item.feedsky.com/~feedsky/web/~1232609/12596323/1235569/1/item.html因为想写一个 lightweight & fast 的文本布局引擎，这两天在留意一些新的图形 API。其实有些都不算很新了，像 Anti-Grain Geometry、Amanith 和 Xara。 曾被誉为“Linux 图形未来希望”的 cairo 广受诟病的是它的效率，尽管从一开始 cairo 便宣称将会利用 glitz 这样的 backend 实现硬件加速的矢量图形绘制，从而达到软件绘制无法达到的效果。结果现在戏剧性的是，cairo 比所有这些用软件绘制的引擎都慢得多。 所以才有人写了这么一篇 Why Cairo?，意思大概说得很清楚了，Mozilla 选用 cairo 的借口现在看来是非常苍白无力的，比如说 cairo 引以为傲的“bring vector graphics to print”有多少人需要把网页输出到 PDF/PS？如果最基本的页面渲染都做不到高效，谈何页面印刷的高效？ 所以我觉得啊，rendering model 好当然不错，cross-platform 性能好也很好，但 cairo 是不是中 gnome 社群的毒太深了？什么东西都来搞个 backend，结果最后每个 backend 都半死不活的，没错，也许某天 David Reveman 搞定了 xgl 腾出手来整 glitz 了，可 David Reveman 就算搞定了 glitz，也未必能在 win32 下用啊。 & 今天测试的结果是，pango 用 cairo 作 backend，cairo 用 win32 backend，结果渲染一行字 (4 个字母)，要半秒钟。嗯，没看错，就是 0.5s。 效率还是很重要的呀，虽然某位大人物说过： 预优化是万恶之源。Thu, 22 Jun 2006 19:51:23 +0800Web4Chttp://blog.jjgod.org/2006/04/18/why-cairo/Web4C2006-06-22T11:51:23Zhttp://blog.jjgod.org/2006/04/18/why-cairo/http://www.sharkui.com/wsba/rss/feedsky/web/~1232609/12596323/1235569