20. PDF的幻想
 20.2. 中文PDF的現實面-過去、現在與未來

本來 PDF 也不是我們所自創,照著外國人的方法就得了,好在 Adobe 也知道世界有各種語言,也早就考量中文(包含繁體與簡體)的問題,理論上當西文都可以成功使用PDF當做印刷的傳輸交換標準標準時(DDAP),中文有何不可?

Windows 系統十分標準結構化,所以從 Acrobat 3.0 之後,中文的應用在 PDF 上與英文幾乎一模一樣,除了中文字大多數是 TrueType 而已,沒有 Type 1 的中文字,但不影響到印前印刷所需的 PDF 之應用,總括來說,自從 Acrobat 3.0 問世之後在 Windows (95, 98, NT, 2000, XP, 2003) 下,中文 PDF 十分成熟與簡易完備。

Macintosh 作業系統 Finder 相對的比較以產地美國為中心,中文屬於擴充外加的模組功能,不是標準系統的一部份,因此在已完全適合印前印刷的 Acrobat 4.0 (PDF 1.3) 出現時,中文字的支援僅止於 CID 字型 (character identification),否則只有將字體全部轉成點陣圖一途,但是當時 Macintosh 電腦上的字體使用環境是大部分人使用 TrueType 字型,部分使用點陣字型以對應後端的 RIP 內之 PostScript 字型,根本幾乎沒有人使用 CID 字型,而可使用的字型只有文鼎 71 套 ATM 字體與華康金碟 38 套 ATM 字體,加上大部分的後端輸出設備廠商初期都還不完全支援 PDF,只好喊出包 CID 字計算比較慢,檔案大的說法,在這種先天與後天不足的環境之下幾乎無一公司能使用中文 PDF。

更大的問題是有沒有人可以處理、組版與輸出?

在當時我理解到不容易變化前端的作稿客戶由 TrueType 轉成 CID 字型,好在文鼎與華康的 CID 字型與原先的 TrueType 之字型外觀之參數幾乎一致,所以倒是可以繞一點路解決這個問題,方法是將應用程式產生給 Distiller 的 PostScript 檔案攔截,然後依據 TrueType 與 CID 字型名稱對應表,將 PostScript 內用到 TrueType 字型的指令修改成為使用相對應的 CID 字型後再送入 Distiller 計算 PDF,這樣就可以在不變前端作稿習慣下轉換出內嵌中文字型的 PDF 了。有一點迂迴與慢,但也能解決部分問題,而且不涉及傷害字型的版權,也有ㄧ些問題是無法處理的,例如注音體因為 CID 沒有可對應的,所以無解;不過受限於當時任職的環境,並沒有太多的推廣與教育。但是後續的把玩與研究中卻讓我的心中逐漸勾勒出更好的可行想法。

直到 Acrobat 5.0 (PDF 1.4) 發行之後,在 Macintosh 上的中文問題總算是完全解決,因為 Macintosh 上的 Adobe Distiller 5.0 能夠事先掃描安裝的中文 TrueType 字型,並且在接受 PostScript 時能直接解譯 TrueType 字型的要求並可將 TrueType 字體內嵌到 PDF 檔案內,此外其他的印前印刷所需各總要求也在 5.0 中一併改的更完善了。

所以就客觀的環境來說再西元 2000 年時 Acrobat 5.0 發表之後應該中文的 PDF 紀元就應該來臨,可惜的是到今天我們依然少見完全使用 PDF 運作的公司。我的看法是因為若干因素之糾結問題,包含:

Acrobat 5.0 (PDF 1.4) 雖然出來了,輸出機的RIP之能處理的版本卻還留在 PDF 1.3,所以...

系統廠商的 Normalizer (與 Distiller 相似,是Adobe提供系統廠商的另一種版本,但售價就貴多了)不知為何原因一直留在舊的版本,而且是 PC 版,根本無法處理 Macintosh 的問題,所以...

有在台灣銷售的組版軟體都無法處理 PDF 1.4,所以...

單純銷售 Acrobat 5.0 與可處理 PDF 1.4 的組版軟體,最大的成本會是教育問題,標準定價的利潤之下根本無利可圖,所以...

所以設備廠商與系統廠商用 PDF 釣上客戶後又將之推回傳統作業,所以嶄新的 RIP 後組版系統大賣,所以流傳著『PDF的圖檔品質因為壓縮所以比較差』、『PDF 檔案包了 CID 字後檔案太大』、『PDF 還不穩定』、『PDF 還不成熟』、『某某外國機構說用 PDF 有 XX...問題』等等的說法,所以至今還有人不知 Macintosh 的 TrueType 字體都可以用。

 進入留言討論區

counter
Table of contents