電子書直橫轉換有什麼困難？
號稱能做到的，都還沒能做到最好
Amazon開始販賣繁體中文Kindle電子書了[1]，在業界總是會聽到一些耳語，其中包括：Amazon現在不支援繁體中文直排，得要未來才能支援。
這當然讓我不能接受。2012年Amazon.co.jp開始販賣日文電子書時，早就完成以EPUB 3轉換Kindle Format的機制，在各種閱讀程式及電書機上顯示也毫無障礙，怎麼到了2019年還走回頭路呢？詳細的推測我寫在後面[2]。
知道這件事以後，我在聯合報專欄上寫了〈別讓正體中文再次邊緣〉來抗議。希望來呼籲出版社多注意一些自己的文化。
然而還有一些技術外的考量，Facebook上有位前輩留言說：
有位作者跟我說，他的著作之所以會有些橫排、有些直排，是因為出版社告訴他，純粹是成本銷售考量。（這作者的著作繁多，經由不同出版社發行）橫排，是因為一頁可以放的字數比較多，紙張費用可以少一點。假如是比較學術的，反正價錢高也會有人買，但頁數少可以省紙張印刷費。
直排，一頁可以排的字比較少，適用內容比較輕鬆的，因為頁數會是銷售考量，書比較厚，售價可以跟著提高。
也聽過出版社反應，現在年輕人愈來愈不適應讀直排（手機閱讀模式），所以會逐漸將新書改成橫排。也有出版社認為橫排才有「國際競爭力」！日後授權外文版才方便！直排是老一輩世代才看的，而這些讀者正消亡中⋯⋯。
也有業者很悲觀說紙本直排會在下個世代消失，要專注投資在橫排載具。（他應該不曉得 iWork 已支援直書）
因此，不知亞馬遜的決定是出自哪些寶貴的意見？
看來內容要直還橫排，這是個作者、出版社與業者都很苦惱的問題。然而，把印刷放到一邊，對於數位內容來說，這真的不是個問題。
EPUB 3格式的電子書，直橫轉換理論上是完全可以做到的⋯⋯只是還有一項CSS的關鍵技術等待普及，讓我花點時間說明直橫轉換所需的技術：
一：翻頁方向（OPF）與文字直排（CSS）
這一項以目前技術來說，可以完全對應。
文字想要直排，只需要CSS裡頭為html元素加上：
writing-mode: vertical-rl;一行，就可以將內容改成直排[3]，假設你刪掉這行，就是預設橫排如：
writing-mode: horizontal-tb;而一般直排書為向右翻頁
則是要在EPUB中OPF檔案的<spine>元素裡加入：
<spine page-progression-direction="rtl" >一行，就可以將內容改成直排，假設你刪掉這行，就是預設橫排如：
<spine page-progression-direction=”ltr” >所以，改變翻頁與行文方向這兩項基本設定，就只是改動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是：
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」。一般來說二到三位數字在直排中需要結合為一字橫排。
另一是「英數全形」，也就如右圖中的「ＯＫ」。一般來說英文縮寫，如ＩＳＯ、ＷＨＯ等組織名，就會採用全形直立顯示。
這兩個小問題在橫轉直時會造成很大的問題，讓讀者感覺奇怪，好像內容沒有經過編輯一般。
反過來直轉橫問題不大，頂多有些英文數字以全形顯示而已。
也可以透過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的問題，這裡就不處理了。
