---
tags: 演講, 原稿
---

# 回顧中文排版需求（CLREQ）

#### 楔子

今年 9 月 18、19 二日，W3C 在日本東京慶應義塾大學辦了場[數位出版工作坊](https://www.w3.org/publishing/events/tokyo18-workshop/)，之後，由日本數大出版社集資與慶應大學合作成立的[進階出版實驗室](https://www.aplab.jp/)（Advanced Publishing Lab, APL）趁這機會舉辦了一場座談會，我在會中講了一場「中文排版需求的沿革與標準化活動」的主題。會後應 [Eric Liu](https://thetype.com/author/ericliu/) 邀稿在此以中文發表，本文就是依當時講稿加筆說明寫成。

## CLREQ 的過去與進程

2009年，日文排版需求（日本語組版処理の要件, JLREQ）正式發表，如同日本標準化專家小林龍生先生在其著作《EPUB 戰記》中所述，在日本當地並未產生迴響與漣漪。但這是由 W3C 國際化小組（i18n WG）所發表的第一份語言排版文檔，實際上是一步重要的定石。一方面作為參考文件，推動了多數與東亞語文排版相關 CSS3 標準的制定；另一方面也引出了其他語言的跟進。中文就是其中之一。

回想 2010 年前後，當時 HTML 5是技術圈內的熱門話題（然而，成為推薦標準是2014年的事情）。當時 W3C 的工作人員Robin Berjon為了推動中日韓等東亞語言圈的討論以意見回饋，開設了HTML 5 Chinese/Korean/Japanese Interest Group三個興趣小組，分別以各自的語言進行討論，降低了參與的語言門檻。在台灣熱絡起來的主要原因是當年台灣最大的開放原始碼聚會COSCUP的主題正是HTML 5技術，邀來了不少相關的專家，頓時凝聚了不少人開始進行討論。我記得有前端專家賀師俊（John Hex）、Opera的謝子斌（Zibin）、台灣Google的葉平（pingoo）等人，還有一位台灣出版界的老前輩——人稱老貓的陳穎青。

當年在技術問題之外，[最熱烈討論](https://lists.w3.org/Archives/Public/public-html-ig-zh/)的就是中文的各種排版需求，包括直書（豎排）、避頭點、標點符號、以及直到現在未能有解的漢字與西文間的間隔等議題。

一年以後，葉平先生提出了個[提案](https://www.w3.org/html/ig/zh/wiki/中文排版要求)，希望匯集群眾的力量，比照JLREQ來寫一份〈中文排版要求〉的文檔。避免重造車輪，先從翻譯JLREQ開始著手，完成後列出與日文排版的不同之處。無論上述討論或者這份提案，在當年都未能完成，不過也留下了珍貴的紀錄供後續參考。

我在當年是台灣一份科技媒體的記者/編輯，主要感興趣的就是作業系統與Web技術，在這圈子裡頂多算是稍微了解狀況的旁觀者。2010年因為看到了iPad的發表，才投身到數位媒體圈子裡頭，但當時還是使用一些軟體套件來製作數位內容，依然有些距離。

直到2012年，在日本數位出版老舖Voyager Japan社長萩野正昭的邀請下，到了東京書展（當年和數位出版展一起合辦，現在兩方都已經不再舉辦了），當年日本在政府推動標準化的狀況下，決定採用EPUB 3作為共通的電子書格式，看到日本官方與民間緊密地推動EPUB 3格式從標準走向應用，覺得數位出版的潮流終於西風東漸，從美國來到了亞洲。這時我離開了媒體工作創辦了一家小公司，決定踏入這個業界。沒想到這決定影響我迄今，套句台灣的說法，就是入了大坑還想要把它填起來。

早幾年台灣政府推動數位內容時，過早地採用了僅適用於西文的EPUB 2格式，加上版權等因素，而造成了揠苗助長的現象。到了2012年時，整個業界甚至退回使用PDF格式，對於EPUB 3的採用顯得興趣缺缺。

但當年回顧EPUB 3這個格式裡和中文相關的部分時，我突然發現標準上並不完善，整體來說還是有著不少問題。例如竪排，當年雖然Apple Webkit小組裡有位David Hyatt如魔術師一般突然就做了個雛形，但其他瀏覽器的支援依然不完善，同時也需要許多字型技術的支持，在當年字型產業不如現在景氣，且資訊並不流通的狀況下，等候作業系統的支援也需要好長一段時間。同時日本的積極推動，也對中文產生了影響[1]，反而增加了問題。而這些問題不參與W3C等國際標準化組織的運作，大概也不會有解。

幸好2013年，W3C開始對數位出版領域進行意見徵求，分別在紐約、東京、巴黎舉辦了三場不同主題的工作坊；而在東京舉辦的就是電子書與國際化需求場次。我就直接參與，提出了在台灣問題最大的注音符號排版問題。但還有一堆未能解決的問題，若靠一人之力逐一提出，力有未逮。於是想起了當年未盡的CLREQ計畫，決定把它做完。

大致上花了一年的時間，從把JLREQ翻譯成中文開始，加上整理在郵件群組裡頭的討論，再到圖書館確定過去鉛字時代書籍排版的作法，加上詢問老貓等老編輯的意見，終於整理出針對繁體字排版的初稿。

要做事並不困難，但遇到和政府以及組織打交道就是政治問題了。要怎麼把這份初稿正式送進W3C裡頭進行後續作業呢？W3C當年的台灣會員不多（現在居然沒了），而對台灣政府來說，這件事在EPUB 3定稿時就已經做完了，相關的協會組織等也覺得沒有必要做下去。於是我也僅能把這份文檔放在電腦裡，等候機會。

那一年10月，W3C的年度大會TPAC正好由騰訊贊助，在深圳舉辦，透過這機會我再提了一次CLREQ的議題。當年透過和W3C Host北京航空航天大學的胡春明教授以及李安琪主任接洽，知道他們願意協助將這個案子一起推動下去。隔年在北京開了一場會議後，加上藏文、維文、蒙文，成立了Chinese Text and Layout Taskforce，我也能夠藉此以邀請專家的名義提出草稿，參與活動。老實說，這一連串的過程，說是奇蹟也不為過。

作為最初的貢獻者，我做的事情後續不比其他參與者多。後來參加的編輯包括陳奕君，他很早就使用Javascript做出了漢字排版Polyfill模組「[漢字標準格式](https://css.hanzi.co)」，當年還在北京大學醫學系求學。另一位是眾所皆知的字型技術者梁海。他們二位針對簡體字、拼音以及注音的部分加筆貢獻。以及來自中國移動的張安杰和W3C的李安琪主任協助翻譯，以及吳小倩和Richard Ishida等人協助處理內容結構標注等繁重的工作，讓整份文檔能在支援英文、簡體字、繁體字的狀況下，在2015年以編輯者初稿（First Editor's Draft）發表。加上TIB的劉慶，現在還在持續擴展內容。

## CLREQ 的特色

就外國人的角度來看，大致上都知道中文分為繁體字與簡體字，但中文使用的地區卻相當廣泛，而且各自有著不同的規則與習慣。口語上也許大致可通，但落實到印刷之上時，沒能符合地區習慣就顯得奇怪。而CLREQ最大的特色就是希望涵蓋這些地方規則。

但以目前的進行來看還有些問題，主要的撰稿者，繁體字來自台灣；簡體字部分則是大陸，未來還需要來自港澳新馬等地的意見與貢獻來延伸不足的部分。

## 推動 CLREQ 的方法

CLREQ還有一項特色，就是參與的編輯大多是志工，且多是對字型、排版有深厚興趣，視為志業的非專業者。相較於JLREQ有多數老編輯、KLREQ甚至蒙古文需求有著多數學者參與，狀況不大相同。（但並不因為成員的不同而損及專業性）

對我來說，志工意味著自掏腰包以及要花時間在上頭。我從2013年起就自費參與W3C的各種國際會議，僅一次透過群眾募資（眾籌）的方式募到了10萬台幣去參與灣區的W3C TPAC年會，以及同時舉辦的Books in Browsers研討會。而當時贊助的人除了早年參與、認同這件事的資訊人外，也包含老貓等編輯以及許多教師。[2] 雖然我覺得這件事情台灣政府需要提出支援，但如前述，他們覺得事情已經做完了[3]。加上在台灣電子書市保持停滯，我也只能靠著新公司且戰且走的微薄收入來支出所需，雖然壓力不小，但問題若不解決，這個產業（在台灣）也很難有再起的可能。所以我不知道自己能做到什麼時候，就在CLREQ之外，也用其他方法來推動需求的落實，包括：

1. 在會議上直接提出需求

CLREQ只是一分需求文件，要將需求真正落實到可用的階段，得透過CSS標準的制定、瀏覽器的實作，還要等候好幾年（你知道很多人不大願意更新作業系統）才能普及。所以若是慢慢等候，只會把時間拉得更久。

但W3C的會議上，像是CSS WG的會議，除了規範作者以外，也會有許多瀏覽器的開發者參與。不管是正式提出，或者私下討論，都有機會把需求快速納入規範的可能。或者和瀏覽器的開發者討論時，就可以直接透過Bug回報系統來反映，處理的速度也能快上不少。在這似乎可以透過Github以及各種線上工具處理一切的時代，遇見人、認識人、透過交談來處理問題，還是非常重要的一項管道。

2. 研究需求的實作方法

但和排版相關的問題並不都能透過W3C解決，有時會和Unicode相關，有時得用到字型技術來處理。以台灣的注音符號排版為例，主要使用的是來自日文的ruby標籤，雖然在2013年深圳會議後，Robin Berjon就寫了[HTML ruby markup extensions](https://www.w3.org/TR/html-ruby-extensions/)，CSS WG的fantasai寫了[CSS Ruby Layout Module](https://www.w3.org/TR/css-ruby-1/)，但依然不能完全支援，注音符號調號要放到一邊，得用OpenType字型技術來解決。後來我找到了台灣的字型專家But Ko來協助[4]，加上諸多瀏覽器開發者協助處理Bug回報，才接近完成。更進一步，這項字型技術的應用將會納入思源黑體/Noto Han Sans 2.000版本中。

3. 透過社群來取得共識

在JLREQ之前，日本針對排版已經有了JIS X 4051這項日本工業標準。但無論台灣繁體字也好，大陸簡體字也好，都沒有與排版相關的標準文件。雖然中國有著諸多與編輯作業相關的GB/T國家標準，但也不能說完善。編輯只能研究實際排版的樣貌，將要項一一列出，透過社群討論來取得共識。例如劉慶君在推動的「孔雀計畫」，就是針對簡體字排版規則的不足進行深入探討，未來都可能納入CLREQ之中。

這是重要的一步，因為繁體字的需求不算多。但簡體字與日文排版極為接近，若能尋找出規則，可以大幅強化日文的需求被實現的可能，這是極為重要的下一步。

## 談談 CLREQ 的內容

說實在的，作為 JLREQ 的中文譯者，以及看過了其他語言的需求文件，我可以說這些 xLRE Q就是「長、不好閱讀，沒有圖例真的不好看懂」。現在 CLREQ 的問題也是缺少圖例（歡迎 TIB 的讀者加入團隊協助提供），這裡就提幾項 CLREQ 的重點：

### 字體

西文可一刀劃分為 Seri f與 Sans-serif，日文也有明朝體與歌德體，但我覺得對於中文來說還不夠。對於中文印刷書而言，黑體出現的頻率其實不如楷體，而多數狀況，有些標題、文言文摘要、古詩等，要是不用楷體就少了一份韻味。

在公文應用上，台灣公文標準使用楷體為內文，中國紅頭文件則是使用仿宋體，我覺得這都是需要落實在資訊設備上的需求。

前面說到與開發者實際見面處理的問題就是字體。現在你可以透過Generic family中的cursive來指定楷體（同時對應簡繁雙方），而在[CSS Font Module Level 4](https://www.w3.org/TR/css-fonts-4/)裡，甚至直接追加了Fangsong來指定仿宋體。

這些都僅能應用在電腦作業系統，無論微軟Windows還是蘋果的macOS，都有這些字體。對於電子書閱讀程式而言，僅有Apple的iBooks透過抓取字體還有比較多的選擇。對於行動設備的作業系統，iOS也好、Android也好，中文的系統字體僅有黑體一擇，隨著現在行動設備的儲存空間與處理能力增加，我真的希望未來也能逐漸增加[5]。

### 標點

中文簡體字與繁體字在排版規則上最大的差異其實是因標點而造成。繁體字的標準依循民國時代的作法，無論橫直排都置中置放，這使得需求大幅簡化，也和日文的進階排版關係較遠。

相對之下簡體字橫排時使用的左下角標點就能和日文的進階排版產生直接的關係，會需要幾乎相同的機制來實現。簡體書豎排時則是要按照GB/T 15834-2011的規定，使用偏右的標點。

過去標點符號因為在 Unicode 裡共用相同的碼位，所以按照字型設計時的語言來區分。但 Adobe 的 Ken Lunde 目前正在Unicode Consortium 提案，希望在同一套字體中可以透過語言選擇機制自動切換。

### 禁則與擠壓處理

就我在研究台灣活字時代排版書籍的時候發現，其實台灣對於行頭行尾的標點禁則處理（避頭尾點）並沒有嚴格的要求。可能是因為置中標點就算不避也不會太過於突兀。但我也發現有著兩種不同的作法，和印刷排字師傅受的訓練應有所關係。

有些排字師傅會避頭尾點，而在鬆行的標點前後加入鉛片來處理，我認為這是來自日據時代排日文書籍的訓練與習慣。而有些則是縱橫對齊，鮮少對頭尾點作出處理，這和1949年前的印刷品排版有所相似。

之後隨著DTP的普及，繁體字多套用日文的設定，並且使用行頭尾對齊（Justify）來進行處理。[6]

簡體字則是按照GB/T 15834 5.1.11的規定「…可適當壓縮標點符號所佔用的空間。」這一點在孔雀計畫系列文章中已多有討論，不再贅述，只希望能找出共識，將實際的狀況寫入CLREQ之中。

但我想無論簡繁以及日文，共同的需求就是掌握版心的尺寸。

目前在網頁設計上，顯示內文的區塊往往是固定的像素值，而這個值不會是內文文字尺寸的整數倍。同時瀏覽器可以讓讀者自己縮放字型大小。所以會需要的機制是透過CSS來掌握版心，使行長等於文字尺寸的整數倍。這麼一來無論是使用行頭尾對齊（Jusfity），或者未來使用進階的標點擠壓機制來處理排版，都用得著。

### Ruby

中文的Ruby應用有以下三種方式[7]：

1. 注音Ruby
2. 拼音Ruby
3. 新運用法

注音Ruby是非常特殊的狀況，目前在技術上接近完成，可說是中文排版透過OpenType功能大幅做出排版調整的第一例。

拼音排版廣泛應用於全球的華語教學，GB/T標準中雖有漢語拼音分詞，但對於排版卻沒有特別的規定。「孔雀計畫」中提到拼音目前在字型上、對齊方法上仍有不少的問題，也待解決，甚至可說頗為迫切。

而因為日本翻譯輕小說的影響，Ruby在中文也用於註解。過去在古籍中有「行間注」的用法，可以彼此呼應。

其實日本提出Ruby需求後，隨著CSS等規範的增加，瀏覽器的實作狀況並不一致。許多仍使用早期實作的成果，CSS Ruby的各種排版調整都不支援。對於日本出版界而言，雖然不滿意，但現狀沒有大缺陷的狀況下，也不強求改進。或許拼音的需求提出以後，可以促進各瀏覽器的實作。

## 最後

我覺得我是個科技樂觀主義者。

這五年中，隨著參與CLREQ與標準化的工作，我覺得自己逐漸變得保守。我經常想：我是不是真的不能接受Web上一直以來以黑體排版，不使用段首縮排，而在段落間加入一行空白，且因為自動避頭尾點造成的行尾對不齊這些狀況呢？

我想我不能夠接受。一來是傳統排版功夫依照規則整然排列的印刷文字，依然會讓我感到舒適易於閱讀，另一來在科技圈子裡打滾，自然明白這些狀況是來自軟硬體的限制所造成。

在Retina螢幕出現以前，明體字要容易顯示，裡頭還包了小字用的點陣字體；爾後索性都使用黑體。而中文電腦字體不僅製作需要大量資金和人力，對於那個儲存空間與記憶體都小，沒有良好管理機制的時代，更是負擔。

而Web的世界，在HTML 5以前，一向都是以西文當作基礎，對於其他語言的支援甚為薄弱。當然在以美國為首的科技業裡，把國際化當作重點的文化，僅屬於那些早期的公司[8]。一套瀏覽器預設樣式表，就影響了整個文字排版文化迄今。

說這是「摩登」、「現代」，我倒認為是在缺陷下造成的結果。就像是成長於饑荒時代的父祖輩，永遠會在意孩子有沒有吃飽一般。

Web 上的中文排版，如今一步步反侵蝕到印刷排版。但如果我們能夠肯定印刷排版整然有序的規則是美學與易讀性的基礎，那麼做一些事情將其帶回數位時代的電子書、網頁排版上，讓類比時代的排版文化得以重生，的確有其必要，也是我所願。

#### 謝辭

感謝日本Voyager Japan 的萩野正昭先生，從和 Bob Stein 一起做Laser Disk 以至 Mac 上使用 HyperCard 技術的Expanded Boo k的經驗非常寶貴。而也因為他對數位出版的熱情，讓我走進這個領域。

也感謝W3C北航的胡春明教授，李安琪主任，以及W3C i18n小組的 Richard Ishida，沒有他們的支持與協助，不會有CLREQ的發表。

以及台灣角川集團 BookWalker 電子書公司的施性吉社長，以及台灣大塊文化的郝明義董事長。他們都具豐富的編輯經驗，在現在的位置上還極為重視排版文化，願意聘用我為顧問，才能持續標準化活動。

小林龍生先生的 Unicode 戰記與 EPUB 戰記是少有在第一線參與國際標準化的經驗談，不僅在精神上給予協助，也提供了不少戰術指導。

當然還有志願參與 CLREQ 工作的編輯們，沒有他們，CLREQ 不會有現在的品質與份量。[9]

[1]: 例如竪排中的冒號「：」與分號「；」，繁體字依然保持直立，但日文卻轉90度變成躺著，簡體字則需要直立偏右。曾經某一代的macOS裏，中文字型豎排時比照日文，這是因為當年[UTR#50](http://www.unicode.org/reports/tr50/tr50-19.html)未能完善所致。

[2]: 也許是責任感作祟，我進行這些活動並不能保證一定會有成果。拿認識的人的錢做這些事情，多少會感到無以回報，之後我就盡量想辦法自己出錢，就當作一年一次奢侈的旅行來說服自己。

[3]: 但就在本月，台灣文化部提出了一筆經費給「台灣數位出版聯盟」這個產業協會加入W3C，並且資助國際會議旅費。

[4]: Github Repo：https://github.com/bobbytung/Bopomofo_on_Web

[5]: Apple很早就在macOS和iOS中採用了Hiragino Mincho作為Serif的對應字體，這多虧了從90年代加入Apple，負責日文木田泰夫先生的品味與判斷。他後來還挑選了游明朝作為內文字體加入macOS，Windows 10後來也跟進。直到今日這還讓我感到羨慕不已。

[6]: 這件事情我和劉慶君有很大意見歧異。我沒有將這一部分寫進CLREQ中，因為當年的做法相當隨意，並不能找出一定的規律。而「不避頭尾這件事」當然不是現代做法，但曾經存在的排版事實，我覺得需要寫進需求之中。

[7]: 因為在日本談CLREQ，所以提及Ruby這項日本人相當在意的排版方式。

[8]: 其實認真來看可以發現，個人電腦世代的公司，如Apple,微軟，都對語言支援較為在意。而Google之後（包括Google）的美國資訊企業，就不見得做得那麼完善。

[9]: 這場演講中，我似乎有意無意地要把劉慶君拉到這個坑洞的深處。不過因為他對日文與中文排版皆熟悉，又能與日本排版專家直接溝通。若要將中日文排版透過Web技術更進一步推動下去，所需要的是簡體字的需求來抬升需求層級。對於簡體字我力有未逮，只能希望他透過TIB這平台來凝聚教育圈、出版圈以及第一線的排版設計師們來找出共識。