從數(shù)據(jù)結(jié)構(gòu)談起

作為一個(gè)非計(jì)算機(jī)專業(yè)畢業(yè)的學(xué)生，讀計(jì)算機(jī)相關(guān)的書，曾經(jīng)是吃了不少苦的。數(shù)據(jù)結(jié)構(gòu)就是一個(gè)比較典型的例子。數(shù)據(jù)結(jié)構(gòu)就是一定程度上對(duì)于元素關(guān)系的考察。自我接觸TeX以來，從一個(gè)用戶變成開發(fā)者，所接觸的數(shù)據(jù)結(jié)構(gòu)，其實(shí)也就是：數(shù)組，散列表（關(guān)聯(lián)數(shù)組），樹。圖就基本沒碰過，至今我也沒接觸過典型的需要我使用樹的情況。

數(shù)據(jù)結(jié)構(gòu)的書，讀起來雖然還是有一點(diǎn)難度，但是總比數(shù)學(xué)書好讀。一些數(shù)學(xué)書的作用，完全就是一把鑰匙，它很少告訴你為什么這把鑰匙要打開的門是什么樣的。數(shù)據(jù)結(jié)構(gòu)的書，由于描述語言的不同，雖然也會(huì)帶來一些細(xì)節(jié)上的差異，但是大的圖景上，還是一樣的。

TeX中的數(shù)據(jù)結(jié)構(gòu)

TeX中的數(shù)據(jù)結(jié)構(gòu)，構(gòu)造頁面的，就是list。這個(gè)list確實(shí)和Lisp中的cons是一樣的（cons之后會(huì)講）。

TeX中的這個(gè)list的控制和處理，只有在引入新的排版元素的時(shí)候才需要做一些改動(dòng)。把OpenType引入到TeX中，加入了細(xì)粒度更細(xì)的glyph node或者native word node（相當(dāng)于一組glyph），基本上只需要寫幾十行代碼控制內(nèi)存分配和釋放，大部分內(nèi)容會(huì)被測(cè)量后直接丟給DVI。

TeX中保存宏命令的是散列表，做斷詞算法的是trie樹。由于本文圍繞list展開，所以不多作介紹了。

TeX和Lisp

讀過TeX源碼的，應(yīng)該會(huì)注意到TeX中的list處理和Lisp有一定相似之處。但其實(shí)，這更多的應(yīng)該是巧合。巧合在于：list是一種常見的結(jié)構(gòu)。Lisp本身就是以List處理為核心特點(diǎn)的語言。

不過，由于TeX和Lisp在一些人看起來，都有一些別扭之處。這種古怪的東西，放在一起，似乎有點(diǎn)分類學(xué)上的趣味。

Lisp的宏和TeX的有一點(diǎn)像，不過麻煩程度上，還是TeX的宏比較麻煩：有先展開后展開的問題。

Lisp on TeX

在TUG 2013的時(shí)候，HAKUTA Shizuya發(fā)表了Lisp on TeX。這東西就更古怪了。但是，古怪歸古怪，這東西是能用的。

雖然，真沒有多少人會(huì)用這個(gè)東西來搞運(yùn)算。說它是炫技？倒也不必，這種東西就是個(gè)showcase。就好比一個(gè)人能吃五碗飯，但是平時(shí)只吃兩碗一樣，它更證明了TeX的完備性。

未完成的m17n-flt接入

我自己的TeX，曾經(jīng)有一個(gè)想法，就是把m17n的flt子組件接進(jìn)來。但是這個(gè)嘗試，當(dāng)時(shí)是失敗了。這個(gè)東西的作用，和今天的harfbuzz一樣。

m17n-flt的核心系統(tǒng)，是一個(gè)用S表達(dá)式寫成的一組控制代碼。這些S表達(dá)式基本上是要處理unicode中一些特定書寫系統(tǒng)的模型，比如bidi，indic。那些代碼，熟悉基本的Lisp控制結(jié)構(gòu)就能看了。

之所以失敗，兩個(gè)原因：m17n-flt不是單獨(dú)的庫，在分發(fā)和部署上會(huì)有很大問題；m17n-flt中特定語言的s表達(dá)式文件有錯(cuò)誤，似乎是沒經(jīng)過測(cè)試的。

平心而論，m17n-flt的代碼雖然難讀一點(diǎn)，但是還是比harfbuzz要好讀一點(diǎn)。harfbuzz的代碼為什么變成了今天的那個(gè)鬼樣子，我不太好說。坊間傳聞，是用了邪術(shù)保證開發(fā)者對(duì)項(xiàng)目的掌控權(quán)。

所以我那個(gè)TeX，至今就是沒接入太多的OpenType處理的功能。現(xiàn)有的功能是由m17n的子項(xiàng)目libotf實(shí)現(xiàn)的。今年還是沖一沖業(yè)績，把這個(gè)libotf換成我自己寫的mlayout吧。這里還需要說一下為什么沒接入harfbuzz。我是發(fā)現(xiàn)harfbuzz跨版本，有一些不一致。這會(huì)影響到輸出的文檔，用不同版本跑出來的東西不一致。還有就是harfbuzz的控制細(xì)粒度的問題，它們內(nèi)部優(yōu)化，導(dǎo)致不能使用16個(gè)以上的feature調(diào)用（記憶上如此）。

題外。m17n的作者之一Kenichi Handa（半田剣一），應(yīng)該日本的排版國標(biāo)JIS X 4051（《日本語文書の行組版方法》）的審定者或定制者之一。家里書都收起來了，要不然還能查證一番。

Wadalab，和田研的嘗試

如果誰還在使用CJK包處理漢字，那大概還可能會(huì)碰到wadalab的包。不過，從我的直覺出發(fā)，似乎日本人也不用這個(gè)了。

TeX Live或者CTAN收入這個(gè)包，一定意義上只是為了保存人類一定時(shí)期的智力遺產(chǎn)。

wadalab這個(gè)字體，只是一個(gè)計(jì)算出來的結(jié)果。它是一套使用Lisp構(gòu)建出來的造字系統(tǒng)（使用的是UtiLisp）。和glyphwiki的kage系統(tǒng)的JavaScript版本的設(shè)計(jì)方式不太相同。不過，兩者輸出的東西都有獨(dú)特的古怪之處。

wadalab在一定意義上是失敗的。錯(cuò)不在lisp。錯(cuò)在兩點(diǎn)：一是缺乏描述漢字stroke的參數(shù)化工具（現(xiàn)在也缺，只不過字體廠商用一定的人力解決了），二十缺乏有力的GUI調(diào)試工具（這個(gè)工具不只是作為查看工具，還有修改工具）。