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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文字想要直排,只需要

writing-mode: vertical-rl;

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

writing-mode: horizontal-tb;

而一般直排書為向右翻頁

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

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

<spine page-progression-direction="rtl" >

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

<spine page-progression-direction=”ltr” >

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

二:CSS Logical Properties and Values

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

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

在中/日文直排內容中,「」,而「」,所以會有以下的對應:

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

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

CSS是:

margin-top: 4em;
text-indent: -4em;

轉過來會變成:

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

margin-left: 4em;
text-indent: -4em;

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

margin-inline-start: 4em;
text-indent: -4em;

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

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

三:英數問題

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

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

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

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

也可以透過CSS來處理:

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

這樣內文的英文數字可以都使用半形,透過CSS Class與<span>標註,

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

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

需要各瀏覽器開發者加強力道實裝,並且未來還需要書檔把原有上下左右的指定方式改成邏輯方向(不過這可以程式化取代處理)。
又或者台灣更多出版社使用數位出版聯盟提供的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的問題,這裡就不處理了。

--

--

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Bobby Tung

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