揭开Linux下GPL中文Postscript的面纱 （2）

上面的程式还有一个可议之处，它放弃了字型快取(fontcache)的使用。这可能使程式的速度大受影响，我还不太明白它放弃的原因，也许要试过才知，不过在Ghostscript中速度似乎还可以接受。我们接下来看一下子字型实际上的定义，由於每一个子字型除了Offsets以外都一样，我只列出第一位元是0xF9的字型为例。我把这部份程式放在CHPOST2.ps这个档案中。

它第一码是0xf9的字型定义，其它的也大致相同。它首先由CFT1JacksonFontdict中将各项字型资料拷贝过来，/DataFile就是字型资料档的名称，而/BuildChar就是指到前述的/bc中。值得注意的是最後一项/Offsets，它是一个长度为158*3的阵列，其中每一项就是相对字元在资料档中启始的位置。

至此我们已将所有Type3的字型准备好了，最後我们看一下KaiSu-Regular这个type0的字型如何把前面定义好的89个字型组合在一起，且了解一下Postscript解释器如何读入正确数目的字元。请参考CHPOST3.ps这个档案

在/KaiSu-Regular的定义中我们可以看到它的字元转译模式是6(注)，这表示它使用SubsVector中的讯息来解释输入字串。它的SubsVector的定义为/SubsVector<00802158>def 第1个00代表每次读入一个字元，後面叁个数字代表整个字型被分为四段，依次为第0-3号字型，然後由/Encoding中取出实际的字型编号，在这里就刚好是0-3，然後再由/FDepVector中取出实际的字型。上面的过程用意在分辨中文和英文的字型，如果把实际的字型范围列出。

0-0x7f第0号字型/_@ASCII 

0x80-0xa0第1号字型/NotDefFont 

0xa1-0xf9第2号字型/CFT1JacksonFontSupp 

0xfa-0xff第3号字型/NotDefFont

这就是BIG5码的定义，在这个过程中只有合法的第一码实际取用到了Jackson字型，其馀的就用原先的字型。

所以一个中文字元被取出的过程如下，以0xa10x40为例,KaiSu-Regular看到0xa10x40，取出encoding为2，在/FDepVector中取得/CFT1JacksonFontSupp，这也是一个typ20字型。

/CFT1JacksonFontSupp是一个8/8mapping的type0字型，用0xa1为索引在/Encoding中取出0，故由/FDepVector中取得第一项/CFT1JacksonFontA1。将CFT1JacksonFontA1堆入堆叠，并将0x40也推入堆叠，呼叫/BuildChar也就是前述的/bc。

/bc由CFT1JacksonFontA1中的/Encoding取得0x40的索引为0，故由Offsets中取得档案的位置0，长度为9。读入这个字元定义，这是一个type1的加密字元定义字串(encrypedcharstrings)。

做一个暂时的字型叫存在/CFT1JacksonFontTemp中，并造出一个字型，把前面读入的字元定义放在里面。用一般show指令将这个临时产生的Type1字型中的字元印出。看起来有些复杂，不过Ghostscript的速度还可以接受，且用的记忆体也还可接受。不过我有点怀疑它在DiplayPostscript时的速度。