Asciidoctor 適合用來製作電子書嗎?

過去幾個星期陸續花了一些時間學習 AsciiDoc 語法與相關工具,打算把學習筆記整理一下,為荒蕪已久的部落格添一點生氣。這是第一篇。

雖然我有一些使用 Markdown 來寫作的經驗,但仍想試試 AsciiDoc,主要是因為 AsciiDoc 在排版方面的語法似乎比 Markdown 更豐富,也提供了更大的自由度,讓作者能夠更細緻地控制版面與風格。

然而,功能越多、客製化的選項越多,往往意味著要處理的問題也越多。我漸漸發現,儘管 AsciiDoc 相關工具並不少,但是想找到令自己滿意的,卻沒有原先想像的容易。

我試過 AsciiDocFxAsciidoctor 工具組,兩者對中文的支援都有點問題,需要一點額外手段來解決。這裡我打算先寫一點我對 Asciidoctor 工具組的初學心得。

Asciidoctor 工具組

Asciidoctor 工具組或工具鏈(toolchain),指的是一組用來處理 AsciiDoc 文件的工具。官方網站是這樣介紹它的:
A fast text processor & publishing toolchain for converting AsciiDoc to HTML5, DocBook & more. 
(一個快速的文字處理器與出版工具鏈,可用來將 AsciiDoc 文件轉換成 HTML5、DocBook 與其它格式。)

在整個 Asciidoctor 工具鏈的生態裡面,大部分的工具是以 Ruby、JavaScript、和 Java 寫成。我比較關心這套工具在產生 pdf、epub、和 html 這三種文件格式方面是否足以拿來製作電子書,以及有沒有什麼隱藏的坑,所以目前試過底下三個工具(皆以 Ruby 撰寫):

其中 asciidoctor-pdf 在處理中文字元方面有點問題,例如斷行位置不對:


還好這個問題不大,安裝 asciidoctor-pdf-cjk 套件便可解決。

接著說說我碰到的其他問題......


首先,生成的 pdf 和 html 檔案,排版和風格差異不小。 其中有些地方很可能是我尚未了解 html 要怎麼調整樣式,有些地方則比較像是工具本身的缺陷。例如重點提示(admonition)的小圖示只能垂直置中,我試過各種我能想到的方式,總是無法達到令我滿意的程度。若要細說過程,得另外拉一篇出來寫了。此外,圖片與其標題(caption)在生成 pdf 的時候都有置中,可是相同的設定,在生成 html 的時候卻只有圖片置中,標題則靠左。諸如此類格式不一致的情形,花了我不少時間尋找解法。
註:也許有些人不覺得這是個問題。比如說,歐萊禮的書,圖片雖然都置中,但圖片的標題文字卻是靠左對齊的。

另外,剛才提過的 asciidoctor-pdf-cjk 套件似乎沒有照顧到表格(table)裡面的文字。從我的測試結果來看,表格裡面的文字總是會有斷行斷錯地方的問題。這問題也有別人碰到: https://github.com/chloerei/asciidoctor-pdf-cjk/issues/4。 如果有興趣挖掘此問題的歷史,可以看這篇:https://github.com/asciidoctor/asciidoctor-pdf/issues/82

另一個小問題是,表格內文字若有折行,會因為行距太擠而顯得難看:


此問題似乎只在生成 PDF 文件時出現,生成 HTML 時則無此現象。

看到這裡,原本對 AsciiDoc 好奇、躍躍欲試的朋友,可能會想打退堂鼓了吧? Me too 啊 Orz

關於輸出格式

Rob Conery 有一篇文章:Writing a Book Is Frustratingly Addictive。不確定該怎麼翻譯才對,也許是:「寫書這檔事,真讓人挫折到上癮。」當然,他指的是寫電子書。

在那篇文章裡,Rob Conery 說出了他編寫上一本電子書的感想,主要是關於三種電子書格式(epub, pdf, mobi)的風格統一。 他說:「想要讓三種輸出格式都長得一樣,是沒意義的。」他的比喻是,就像給五隻貓洗澡一樣,最終只會把自己搞得很累、又濕又冷。他還說,花了好幾個月,試過各種工具之後,總結出一個最好的做法,就是:
  1. 先輸出 epub 格式。
  2. 用 Calibre 把 epub 轉成 pdf 和 mobi。此步驟需要花一些時間來反覆嘗試,以找出最佳的設定。
  3. 在 Calibre 中,把 mobi 的輸出裝置設定為 Kindle Paperwhite。這樣已經能夠滿足絕大多數的 Kindle 使用者。至於 Kindle Fire 的使用者,他們可以看 pdf。
  4. 使用圖片來呈現範例程式碼。

關於第 4 點,我覺得如果用圖片來呈現程式碼,可能會有一些麻煩,例如:程式碼稍有改動就要重新抓圖、程式碼的字體可能因為圖片比例縮放而產生大小不一致的情形、讀者無法直接複製程式碼。不過,Conery 在意的是,就算你在撰寫書稿時費盡心思把程式碼的字體弄得很美觀,最終在電子閱讀器上面呈現出來的格式可能也不是你原先安排的那樣。也許,沒有像他一樣經歷過許多工具的折磨,就比較難體會他這番經驗之談(話說回來,我其實也花了不少時間在 asciidoctor 上面)。

另外,先產生 epub,再從 epub 轉成 pdf 和其他格式(如 mobi)的作法,聽起來有些道理。只是,從 Conery 的文章裡看不出來他有沒有用 Asciidoctor,不然我還真想知道他對於「利用不同工具把 AsciiDoc 原稿轉成 pdf、epub、html」的方式有何看法。

結語

剛開始學著用 Asciidoctor 工具鏈的時候,我把以前的書籍原稿拿一小部份來修改,把 Markdown 語法改成 AsciiDoc,以便實際感受一下 asciidoc 語法有什麼優點,以及產生出來的 pdf/epub/html 的品質如何。初步的一些小測試,令我滿懷希望,因為輸出的 pdf 品質很不錯,而且版型也有許多客製化的選項。

然而,在花了幾個星期改書稿、檢查生成的 pdf、epub、html 的反覆過程中,我漸漸覺得,目前這個版本的 Asciidoctor 工具鏈還不夠成熟,若要動真格來寫書,很折騰,因為實際上會碰到的問題實在太多了。且看 GitHub 上面尚待解決的諸多問題,有些我覺得蠻要緊的 bug 甚至長達兩年都沒有解決(例如 asciidoctof-pdf 的 issue #85)。為此我甚至興起一個念頭:「我是不是該學一下 Ruby 了?」

總之,目前用 Asciidoctor 來寫技術文件應該可以,但是要用來寫電子書,我會等到目前已知的問題都解決了以後再來考慮。

沒有留言:

技術提供:Blogger.
回頂端⬆️