這里來講我一個昨天測試的例子。先上代碼：

這代碼是網(wǎng)上抄的。作用是繪制shading，或者稱作gradient。那么效果如此：

然后，我看了一眼Texpad的效果（起碼的對標(biāo)對象嘛）：

這是圖形驅(qū)動沒寫好啊。熟悉圖形學(xué)和PDF的人應(yīng)該知道，這里面的繪制，是先畫文字，然后取文字輪廓作為clip的來源，然后再繪制shading。除去細(xì)節(jié)不談，Texpad的渲染的問題在宏定義里面的special處就出現(xiàn)了：

這個special是告訴PDF解釋器，繪制文字的時候要將文字輪廓放到clip path中去。

Swift包的Core Graphics的API，雖然有時候比OC版的難用，但也不是不能用。大的原則，其實(shí)就是按PDF的邏輯（字節(jié)碼）順序來寫。我用swift playgrounds寫了一下，大概如此：

代碼很亂，但是有效果如此，是能做出來的。

在iOS或者macOS上寫圖形圖像的東西，如果知道PDF的細(xì)節(jié)，那么理解Core Graphics就很容易了。因?yàn)樗麄儓D形圖像模型是一致的。當(dāng)然，不讀PDF的Reference也可以，讀一本老書也可以：

TikZ以及諸多圖像包的支持，是我這App的開發(fā)重點(diǎn)。還好以前用Cairo寫過一版驅(qū)動啊，用Core Graphics，還是有熟悉感的。

有網(wǎng)友問我的App支不支持EPS。這事嘛，macOS上面有一個PSNormalizer.framework，可以將PS轉(zhuǎn)換為PDF。但是在iOS上，應(yīng)該是不存在這個庫的，所以，原生支持（省事的）是不存在的?？赡艿淖龇ㄓ袀z，一個是買GhostScript的商業(yè)版授權(quán)，或者重寫出一個PostScript來。前者價格不明，后者需要App帶來足夠的收入。

我去年寫過一個簡易版的PostScript解釋器，但是用途比較簡單，一是為了解析Type 1字體以及諸多的cmap文件，二是給PDF解析庫做hook?；A(chǔ)是有的，但是想要更多的PostScript支持，還是需要一定的工作量的。