電子書直橫轉換有什麼困難?

Bobby Tung
Jun 2 · 8 min read

號稱能做到的,都還沒能做到最好

Amazon開始販賣繁體中文Kindle電子書了[1],在業界總是會聽到一些耳語,其中包括:Amazon現在不支援繁體中文直排,得要未來才能支援。

這當然讓我不能接受。2012年Amazon.co.jp開始販賣日文電子書時,早就完成以EPUB 3轉換Kindle Format的機制,在各種閱讀程式及電書機上顯示也毫無障礙,怎麼到了2019年還走回頭路呢?詳細的推測我寫在後面[2]。

知道這件事以後,我在聯合報專欄上寫了〈別讓正體中文再次邊緣〉來抗議。希望來呼籲出版社多注意一些自己的文化。

然而還有一些技術外的考量,Facebook上有位前輩留言說:

有位作者跟我說,他的著作之所以會有些橫排、有些直排,是因為出版社告訴他,純粹是成本銷售考量。(這作者的著作繁多,經由不同出版社發行)橫排,是因為一頁可以放的字數比較多,紙張費用可以少一點。假如是比較學術的,反正價錢高也會有人買,但頁數少可以省紙張印刷費。

直排,一頁可以排的字比較少,適用內容比較輕鬆的,因為頁數會是銷售考量,書比較厚,售價可以跟著提高。

也聽過出版社反應,現在年輕人愈來愈不適應讀直排(手機閱讀模式),所以會逐漸將新書改成橫排。也有出版社認為橫排才有「國際競爭力」!日後授權外文版才方便!直排是老一輩世代才看的,而這些讀者正消亡中⋯⋯。

也有業者很悲觀說紙本直排會在下個世代消失,要專注投資在橫排載具。(他應該不曉得 iWork 已支援直書)

因此,不知亞馬遜的決定是出自哪些寶貴的意見?

看來內容要直還橫排,這是個作者、出版社與業者都很苦惱的問題。然而,把印刷放到一邊,對於數位內容來說,這真的不是個問題。

EPUB 3格式的電子書,直橫轉換理論上是完全可以做到的⋯⋯只是還有一項CSS的關鍵技術等待普及,讓我花點時間說明直橫轉換所需的技術:

一:翻頁方向(OPF)與文字直排(CSS)

這一項以目前技術來說,可以完全對應。

文字想要直排,只需要CSS裡頭為html元素加上

一行,就可以將內容改成直排[3],假設你刪掉這行,就是預設橫排如:

而一般直排書為向右翻頁

JLREQ上的插圖,說明直橫排翻頁方向不同。

則是要在EPUB中OPF檔案的<spine>元素裡加入:

一行,就可以將內容改成直排,假設你刪掉這行,就是預設橫排如:

所以,改變翻頁與行文方向這兩項基本設定,就只是改動EPUB中兩行而已,毫無技術難度。但是想要保留排版設計,就需要配合以下技術的調整。

二:CSS Logical Properties and Values

CSS邏輯屬性與值直到最近才正式發布草稿,這意味著各瀏覽器要支援還得花上點時間,而各電子書閱讀程式要支援,得要更久了。[4]

這是什麼玩意兒呢?借用規格裡的圖來解釋:

在中/日文直排內容中,「行文方向(inline direction)是由上而下」,而「段走方向(block direction)是由右而左」,所以會有以下的對應:

  • 行首:inline-start(top)
  • 行尾:inline-end(bottom)
  • 段首:block-start(right)
  • 段尾:block-end(left)

假設我們不是使用邏輯方向,而是用現在指定上下左右的方式,硬把直排改成橫排,就會遇到排版上的悲劇了,例如行頭縮排:

CSS是:

轉過來會變成:

該段落的上方依然空下四個字的高度,然後「白兔說:」突出到可視範圍之外去了。則需要改成:

如果可以使用CSS邏輯屬性與值的話,則寫成這樣就可通用直橫排:

這樣不管轉直轉橫就都沒問題了。

同樣,像引言、標題周圍的空間等,都會受到影響。所以在CSS邏輯屬性與值普及前,自動轉換都很難做好。不過去年台灣數位出版聯盟發布的「台灣 EPUB 3 製作指引」裡頭,有著很有趣的處理方式,現在就可以實用:[5]。

三:英數問題

剩下還有兩個小問題要解決:一是「縱中橫排」,也就如右圖的「25」。一般來說二到三位數字在直排中需要結合為一字橫排。

另一是「英數全形」,也就如右圖中的「OK」。一般來說英文縮寫,如ISO、WHO等組織名,就會採用全形直立顯示。

這兩個小問題在橫轉直時會造成很大的問題,讓讀者感覺奇怪,好像內容沒有經過編輯一般。

反過來直轉橫問題不大,頂多有些英文數字以全形顯示而已。

也可以透過CSS來處理:

  • 縱中橫排:
    CSS套用 (-webkit-)text-combine: horizontal;
  • 英數全形:
    CSS套用 font-variant-east-asian: full-width;

這樣內文的英文數字可以都使用半形,透過CSS Class與<span>標註,在直排的Class下頭啟用的話,就可以讓兩者正確顯示。


這三件事還需要一點時間:

是不少電子書平台可以立即加在自己閱讀程式裡的功能。

需要各瀏覽器開發者加強力道實裝,並且未來還需要書檔把原有上下左右的指定方式改成邏輯方向(不過這可以程式化取代處理)。
又或者台灣更多出版社使用數位出版聯盟提供的EPUB範本來製作電子書,我們可以利用該範本的預設值,做到更好的直橫轉換處理。

則是需要出版社、轉制者多花點力氣標註內容。由於主要問題是「橫轉直」,要不要多做這工,也是個抉擇(縱中橫排與要不要全形,不完全是規則問題,也包含編輯的判斷在內,所以不能全以自動化的方式完成)。

大致如此[6]。


[1]: 嚴格來說,過去就可以先將電子書送到中國圖書進出口單位進行審查,以外版進口電字書的方式送到Amazon.cn上架,然後再藉此送到世界各國的Amazon站點銷售。現在只是不需「到中國走一趟、接受審查」,由Amazon.com直接上架。

[2]: Amazon一向不使用EPUB這種開放格式,而用自己的格式,包括:mobi, azw(Amazon whispernet), KF8(Kindle Format 8), KFX(Kindle Format X)。日本開站時使用的格式是將EPUB 3複製出一份供舊版橫排使用的EPUB 2並存於同個檔案中,所以檔案會是兩倍大。然後後來又有新版格式,可以支援快速預覽各頁面,但又把直排這種國際化需求放到一邊去了。現在繁體中文的狀況是:Kindle Previewer 這樣的工具僅支援新版格式,捨棄舊版支援,而看來出版社對口也只能用這一版本的工具,所以就只能要求上橫排書了。

談到未來支援,就不知道出版社願不願意更新書檔了。

[3]: 這個草案在W3C的CSS WG討論很久了,直到去年才正式發布,請瀏覽器開發者實作。可能要到2020年才能在瀏覽器上使用。屆時iOS因為背後都使用Webkit引擎,可以快速支援;但多數的Android閱讀程式,網頁引擎多半取自某一版的Blink(Chromium從Webkit專案拉出來的分支),所以要跟上最新版,還要花上一段時間。

[4]: 然而,過去有很多瀏覽器prefix,像是 -ms-writing-mode -epub-writing-mode -webkit-writing-mode(微軟的語法還不一樣勒),但新版本瀏覽器都已經拿掉prefix了。

[5]: 他們將直排橫排各給予一個class(.vtrl與.hltb),然後段落縮排與凸排等都使用預設的CSS,這麼一來,只要以更換class的方式切換直橫排,就能夠透過預設CSS切換方向,而得到正確的排版結果。

[6]: 其實在進行「一」轉向的同時,可以使用程式把CSS裡頭的上下左右直接改掉;並且在橫轉直的同時,使用正則表現式挑出數字和英文來加上縱中橫與全形,也是可以做到的。不過這些對程式人來說理所當然的事,到了電子書產業都很難推動⋯⋯

另外還有圖片尺寸指定height與width的問題,這裡就不處理了。

Bobby Tung

Written by

W3C i18n invited expert, editor of "Requirements for Chinese Text Layout" (CLREQ), Evangelist. I provide consultancy of digital publishing in Taiwan.