2011年12月2日

開放源碼電子書與 EPUB 幕後排版

在 2011 年「數位出版金鼎獎分享會暨媒合會」,我分享的 Talk 主題是「開放源碼電子書與EPUB幕後排版」。

我們沒有電子書產品可以分享,談論這個議題,目的是希望數位出版業界的朋友們,可以看到 Markdown 這種的標記語法,適合用於「排版相對簡單」、「以文字為主」的電子書製作。因為有許多書籍重點在內容,而不必要求像雜誌一樣漂亮的圖文編排,也不必要求媒體聲光效果。


有許多概念和技術細節,沒機會在 Talk 中講述,所以只好用網誌慢慢寫 : -)

故事從程式設計教學這門「慈善事業」開始說起。

我們想要尋找一種方式,讓個人(素人作家)也可以很容易出版。動機是我們已經發展多年的程式設計練習系統,已經有累積一些數位教材,可以變成教科書販售。

程式設計的數位教材

但是在跟幾家出版社洽談後,我們發現傳統的出版流程並不合適,一來出版社意願不高,我們想做的頁數很少(我們不想用大量程式碼和畫面擷圖灌水充頁數),我們想用很便宜價格賣給學生;二來我們的書籍內容會經常需要更新、添加新的章節,紙書可不能想改版就改版、重印。

我們想做的書,內容必須配合題庫,因為題庫的 Learning by doing 學習方式,才是真正對學生有用的部份。但是題庫在每一次課程中使用之後,會持續有新增或修改。

不管是做紙書或電子書,一般的書籍排版方式太耗費人力,題庫修改完之後,要找到對應的書籍內容做修改同步,這樣一來書就不可能便宜賣。

於是我們開始想找一種方式,讓題庫(XML格式)可以自動轉換輸出成 PDF,這樣就能拿來少量印刷(Print-on-demand)或製作成電子書發行。過去的努力方向是把 XML 轉 LaTeX,但一直沒有太多進展。

直到 9 月 17 日的「HTML5與Node.js在台灣聯合技術小聚」,有幸遇到 XDite 大大,聽他介紹 Rails 101 的製作,才發現 Markdown(及 reStructuredText) 是個不錯的解決方案。對個人出版(或精實出版)有興趣的朋友,可以持續追蹤 XDite 發表的文章。

加入 Markdown 當成「書的原始碼」,對程式設計的數位教材有了很大的轉變,作者在設計題庫的時候,可以用 Markdown 撰寫題目說明、解答、教學內容等等。接下來就可以使用一套自動化的工具,將教材原始碼匯出成「電子題庫 XML」+「友善列印的電子書 PDF」+「適用各類閱讀器的 EPUB」。

這麼一來,對於程式設計教材的作者,只需要把必要的「題庫」做好,其他「講義」、「投影片」、「電子書」,就可以在不需要額外 effort 的情況下,由軟體代勞、自動化。電子書(及題庫)的發行成本低,「售價」高低受到作者(及其他人力)的成本影響。

因此如果將 Markdown(或 reStructuredText)作為電子書的原始碼,讓電子書可以自動化生產,很多電子書就可以讓「程式」自己做,而不需要太多額外人力介入。

也許這種概念同樣適合其他應用。

例如 Blog 平台提供電子書販售,幫部落客定期把精選文章挑出來,變成可以上架販售、容易閱讀的電子書,只需要在平台加上 HTML 轉 Markdown 的功能(或者平台本身就支援以 Markdown 寫文章),再把 Markdown (電子書的原始碼),自動產生成 EPUB、PDF 等格式,就可以輕鬆上架。

以下兩種情況,相信會造成不同的售價:
  1. 部落客要自己花時間把內容挑選出來,用 EPUB 編輯軟體排版成電子書,上傳到電子書平台上架銷售。若文章內容有更新修改,必須再人工做一次。
  2. 部落客只要在後台設定打個勾,每隔一段時間,平台就自動幫忙打包成書上架販售。

當然以部落格當例子,有人會覺得既然文章都已經公開,網站就能看,為何還要買書呢?我不清楚有多少人願意花錢買,但如果是我喜歡的部落客,能夠用很合理的價格、很容易付費的方式,就能取得集合半年、一年文章的電子書,很方便地下載到我喜歡用的閱讀器,我願意成為掏腰包的那一群。

願意付錢,絕對不是因為錢太多沒地方可花,而是電子書看起來就是爽度比較高,內容通常比較連貫,也不會有斷線、圖片變叉燒包等等問題;作者既然已經賣書、收費,就有責任修正勘誤,或是補充及更新,因此品質可能也會比較好。

這是一種付費支持好作者的實際行動,讓好的作者有動機和意願繼續用產出好的「內容」來服務讀者。

但問題是有多少錢真正落入作者的口袋呢?

傳統的出版方式,即使很慷慨地付給作者 20% 版稅,你可能覺得自己付了 299 買這位作者的書,但實際上作者只拿到 60 元;現實是多數作者拿到的比例更少。

另一種極端是你只付了 99 元,但作者卻能得到 80 元。同樣賣 1000 本,作者的收入相差 2 萬元。可以很合理推斷,如果賣 299 元可以有 1000 本銷量,那麼 99 元似乎不該賣得更差。

要達到這種極端的況,就是書籍從作者到讀者中間的過程,必須去除所有非必要的浪費(精實)。

有些書並不需要印出來,有些書不用太精美的排版,有些書不用一大堆插圖,有些書只需要簡單的封面,有些書不需要在初版就完全沒錯字、沒勘誤。換句話說,有些書,讀者期待的也許是作者寫好之後,也許不超過十分鐘的時間,讀者就可以線上付費、下載到自己的閱讀器,而不是多花幾倍的價格,卻要等個一年半載,才能開始預購、買書、等待到貨通知。

如果讀者想要的是「內容」,願意付費給作者提供這項「服務」;何不讓讀者只要付出少少的錢,就能買到作者最直接、最即時的服務呢?

過去作者想要出書,必須先把內容交給專業的編輯、專業的排版,做出來的書才會像「書」;否則就只能叫做原稿(通常是 WORD 文件之類),沒有讀者想花錢買原稿。

有不少的書,重點在內容,以文為主,加上部份說明圖片、照片,不需要太多編排,就已經足夠。

這一類的書,作者只要知道如何「定義結構」,就可以自己做個人出版。也就是標記哪些文字是標題,哪些文字是內容段落或引言等等。只需要「標記」一本書的內容結構。

最常見也使用最廣泛的「標記」是 XML,例如 EPUB 使用的 XHTML 也是一種 XML 格式。

但這種東西相當技術,我沒辦法想像如余秋雨等文學作者,如果想要個人出版,還要學會 EPUB 的語法之後才能做電子書。如果要假他人之手,請為專家(或工程師)來幫忙,那書的成本就不只來自作者了。

有一種發展方向,是發展所視即所得的「電子書編輯工具」,對於使用者來說,這類軟體介面通常很友善,也很管用,多數情況不用知道語法,只要學會軟體的操作,就可以製作電子書。但這種工具,還是免不了使用者要自己「排版」這件事。

回到「定義結構」這件事,作者一定相當清楚,自己寫得內容,哪些部份是標題,哪些部份是段落,哪些部份要加上項目編號。但是作者不一定知道如何用編輯軟體,將這些標題、段落、項目編號「排版」,除非作者先學習軟體怎麼用。

但是更好的情況是,作者只需要用簡單的標記,將書籍內容的結構定義清楚,把「電子書的原始碼」完成(幕後排版)。

排版的事情,就交給看得懂這種結構定義的「軟體」來做。軟體很吃苦耐勞而且一天可以工作二十四小時,沒有超時、過勞或爆肝的問題,出版社只需要請來一位軟體,就可以應付成千上百位作者的排版工作,只要作者交來的文稿有清楚的結構定義。例如:

我是大標題
=========

我是小標題
---------

這是第一段,blah..blah..blah..

這是第二段:

* 蘋果
* 香蕉
* 蓮霧

* 上述是一種 Markdown 的文字標記語法,可以利用 Notepag.es 網站玩玩看

那出版社可以做什麼呢?數位出版時代的出版社,可以提供平台,協助作者賣書,也能藉由加值服務幫助作者行銷、編輯或企劃(也就是幫助素人作家成為暢銷作家,有錢大家一起賺)。

出版社可以協助作者,讓自己做的書看起來更像書,透過提供專業設計的電子書範本。

內容原始碼(作者) + 專業設計範本(出版平台)+ 通路(出版平台) = 版稅70%以上的電子書

也就是說,要使用 EPUB、MOBI 或 PDF 格式,要相容什麼閱讀器, 都應該和作者一點關係也沒有。作者只需要知道少少的幾種簡易標記怎麼用,把電子書的原始碼完成,上傳到平台,接下來就只需要等錢匯入銀行帳戶。(就像部落客只要寫好文章、發佈,廣告商定期就會將錢匯到帳戶)。

如果「電子書原始碼」被接受,也成為出版平台支援的一種個人出版寫作模式,事情發展應該可以變得更有趣。由出版平台提供應用程式介面,也就是「網路服務(Web Services)」,概念上類似把「出版平台」變成「虛擬印表機」,作者寫好的書,只要輸出到出版平台「印成電子書」。

近期已經有一些國內的平台廠商,提供個人作者在網站上寫書,由網站自動轉成電子書的服務,也能將部落格(RSS)轉換成電子書。但我認為出版平台並不需要做這麼多功能,只要提供一組 API 就夠了。

舉例來說,出版平台只需要提供一組「電子書出版 API」:

http://api.some-publish-service.com/upload?uid=...&format=...

應用程式只要將「內容」輸出成適合的文字標記格式,也就是「電子書原始碼」,再利用這組 API 上傳給出版平台,就可以自動出版成電子書、上架販售。

這麼一來,各種文字出版的應用就有機會以 10x 速度發展。

部落格平台商,只需要將部落客的文章輸出成「電子書原始碼」,發佈到出版平台,就能為部落客出書。

行動應用程式開發商,只要在文字編輯軟體(App)加上一個「發佈按鈕」,就能將「電子書原始碼」發佈到出版平台,轉換成電子書格式。也就是 iPhone、iPad、Android,也可以利用這類應用程式「製作電子書」。

職業作家想到 Cafe shop 寫書,只需要帶一台 iPad($15,500)加上一組無線鍵盤($2,190),就可以悠閒自在寫書,不用為了寫書這件小事,搬來一台又厚又重又容易當機的筆電。

背包客帶著智慧型手機,只要利用 App 拍照、做文字記錄,再利用 Wi-Fi 將電子書原始碼發佈,就可以即時更新自己正在販售的旅遊書。

其它諸如新聞、研討會、學報、...等等,只要能夠將內容簡單地集結成「電子書原始碼」,就可以自動化地出版成電子書。

輸出這樣的電子書原始碼困難嗎?要利用程式輸出簡易的標記語法,應該會比產生 EPUB 簡單一百倍。

printf("title\n=====\n\nHello World!\n")

只要懂得簡單的程式設計,都會有機會利用這種出版平台的 API 服務,為各種創意的應用加上「出版」功能。

如果很多人都能夠用出版平台的 API 服務,開發加值的應用程式,一般只想要寫作的使用者,就會有更多的選擇可以發行自己的內容,而不受限於某個出版平台才提供的特定編輯功能。

接下來想要分享一些技術上的想法。

使用「原始碼」來製作電子書,會程式設計的朋友,就不難看見一些「好處」。

例如,Unix 我們常用 Makefile 自動建置執行檔(executable program),可以依照不同系統需求建置、打包個別的套件。在 Java 開發環境則有 Ant、Maven、Gradle,而 .NET 也有 NAnt 等。

當電子書是透過原始碼來製作,過程就會有許多彈性,且可以被自動化。例如「圖片」可以只維護、編輯一張原始大小的向量圖檔,在建置「EPUB」格式時,先用 ImageMagic 將圖片壓縮成適合閱讀器的解析度,減小體積;而輸出印刷用的「PDF」時,則保留原有的高解析度,以維持輸出的品質。

自動化建置的過程,除了將電子書由原始碼轉換成特定格式,並且在過程中處理掉例行的瑣事,最後也可以自動發佈到某個出版平台。

如此一來,每一次修改了部份的內容,後續所有流程就可以自動化處理完畢。

程式碼的版本控制已經發展出許多優秀的工具,例如 Subversion、Git、Mecurial 等等。電子書的原始碼也可以直接利用現有的工具和方法,就可以輕易達成「多人協作」的目的;一般的電子書軟體很難真正讓多位作者同時編輯,以及處理編輯衝突的問題。

舉例來說,內容願意開放、分享的電子書,可以直接在 GitHubGoogle Project Hosting 之類的服務,註冊開放源碼專案,將電子書開放原始碼,就可以藉由社群的多位作者協同編輯這本電子書;因為有了電子書的原始碼,加上版本控制,可以比對不同版本之間的差異,並解決編輯衝突的問題,也很容易回復到某個歷史版本,就可以同步進行內容編修。

包括編輯、繪圖的人員,也可以利用版本控制系統,和多位作者同步進行電子書的製作。就如同軟體現行的作法。

有了版本控制系統,軟體開發的 Continuous Integration (持續整合)概念,也可以用來協助電子書開發團隊。

也就是說,有一位「電子書管家機器人」,它會定期(也許是一小時一次),從版本控制系統將內容團隊 commit 的最新版本取出,並且自動檢查內容(如拼字錯誤、標記語法錯誤等)、並嘗試將它打包成各種格式,進行相容性測試等,如果測試結果沒有問題,也可以自動上架到出版平台。

再將軟體專案的 Issue Tracking System (ITS)納入,一個有組織的電子書製作團隊,也許可以更「敏捷」出版。

例如校稿人員發現錯字,就上 ITS 增加新的 Issue(新問題),編輯覺得哪邊需要修改,也加入新的 Issue。當內容已經修改好,並且提交到版本控制系統,就可以將 Issue 更新(已修改)。最後自動打包成新版的電子書,經過檢視沒問題之後,再將 Issue 關閉(已解決)。

當電子書有了原始碼,就可以變得跟軟體一樣好玩。

例如開發 EPUB 電子書範本的設計師,可以利用 Sass 撰寫更清晰明瞭的描述樣式,在自動化建置電子書的過程中,利用工具指令將 Sass 轉換成 CSS,最後再一起打包成 EPUB 格式。

如果覺得電子書原始碼,撰寫的時候沒有所視即所得,少了爽度,其實也可以自己做一個。利用類似 Watchr 這類的指令程式,自動偵測原始碼、產生的電子書檔案是否有更新,如果有就在背景自動建置打包電子書、重新以預覽程式開啟檢視,就可達到編輯同時預覽的效果。

為了讓開放源碼電子書、協作出版可以更進一步實現,我們也邀請 NodeJS Taiwan 社群的朋友一起寫書,透過這個 GitHub 的開源專案「NodeJS From Scratch」進行。

雖然要寫電子書原始碼很簡單,只要記事本之類的純文字編輯器,加上打字的基本技能,就可以輕鬆寫。但是將電子書原始碼轉換成特定格式,例如 EPUB 及 PDF,就需要在電腦上安裝不少工具。

我目前偏好的格式是「reStructuredText」,也是 XDite 由推薦後發現它很管用。因為它有個強大的工具「Sphinx」可以輸出成 PDF、HTML、LaTeX、EPUB、...等等。

但是以 EPUB 及 PDF 這兩種電子書格式,除 Sphinx 本身需要 Python,還要另外搭配 TeX Live(提供 XeTeX可支援Unicode中文)、合適的字型檔,才能正確輸出中文 PDF;EPUB 的部份則需要調整 Sphinx 的 Themes(佈景),以及少許中文修正,看起來才會比較適合一般的電子書。程式碼色彩(Syntax Highlight)的顯示,也需要將 Pygments 版本更新,才會支援更多種程式語言。

為讓不想花時間搞這些軟體環境安裝設定的朋友,也能加入以電子書原始碼寫作的行列,我們正在實現一個概念展示平台「Continuous Publishing(ContPub)」,在這個網站註冊一組個人帳號,就可以立即使用線上編輯器,以 reStructuredText 格式撰寫內容,並由網站負責打包成電子書(提供 EPUB 及 PDF)。這個網站也支援 iPad (但目前編輯效果並不流暢),可以用行動裝置出版電子書。

除利用 ContPub 內建的文字編輯器寫書,它也支援從 GitHub 專案取出最新版的電子書原始碼,同樣自動打包成 EPUB 及 PDF 兩種格式。最後產生的電子書會上傳 Amazon S3 服務,方便各類的裝置下載閱讀。

http://contpub.org/

我們嘗試利用「電子書原始碼」的方式,同時開發程式設計的電子題庫及教科書。


也協助作者(或譯者),以原始碼方式製作電子書。


以原始碼方式製作電子書,作者不必學習編輯軟體,也不用學習過多特殊語法,只要習慣「打字」、「標記」,就能輕鬆完成一本書;日後也能隨時輕鬆修改、增加內容。

我們暫且將一種概念稱為「持續出版(Continuous Publishing)」,意思就是作者只要寫到一個段落,就可以先將電子書出版,得到來自讀者的購買付費及意見回饋,成為被讀者支持(擁有粉絲)的作者,再持續付出時間和努力改善、擴充書的內容。

並非每一種書都適合這種模式,但是我們相信某些書籍,在數位化之後,應該成為一種服務(訂閱)而不比較不像是商品。例如 Android 應用程式開發的電子書,當第一版是以 SDK 2.2 為基礎撰寫,作者持續獲得讀者付費的支持,就可以持續為 SDK 2.3 增加的功能改寫或新增部份書籍內容,讓已經付費的讀者,在內容更新的第一時間,就取得最新版的電子書,同時也有機會讓更多還沒購買的潛在讀者付費。

如果您對本篇說明的出版概念有興趣,歡迎加入 ContPub 專頁 

如果您想取得相關的程式碼及技術方面的資源,請參考我們的 GitHub 開源專案。目前有 sphinx-cook(Sphinx工具化繁為簡專案)、sphinx-themes(EPUB佈景改善專案)正在進行。

延伸閱讀:精實出版(Lean Publishing


13 則留言:

  1. 怎麼沒通知我阿~讓我捧場一下ㄇㄟ,錯過一場阿宏講習很可惜ㄋㄟ

    回覆刪除
  2. 很有趣的 topic, 我過去沒有用過, 我當場差點要站起來為您鼓掌喔 !! 個人覺得當天最出色的內容 !!

    回覆刪除
  3. 下次有機會分享技術再約你~

    回覆刪除
  4. 您真是好人~多謝你的鼓勵~

    回覆刪除
  5. 我 90% 你的看法,但懷疑這樣做出的電子書是否太陽春?很難處理複雜的排版,圖片甚至影片。
    以部落格匯入的例子來看,部落格中的:圖片、影片、投影片、程式碼、特別說明等,如果只用很難想像如何用 Markdown 編輯?

    回覆刪除
  6. 其實我認為目前 EPUB 才合適做為電子書的原始碼,廣濶而全面性,但確實也造成了複雜性,就如同所有功能強大,應用範圍廣的程式語言一樣,如 Java, C#, VB, C++...等,都不好學。
    這是我的Blog: http://chigo-studio.blogspot.com/ 歡迎參觀。
    可惜沒有您部落格中如此熱情豐富的內容,也有一陣子沒更新了,數月前為了研究 EPUB,翻譯了部份 5月份IDPF公佈的 EPUB 3.0 內容,不過經過了幾個月,我發現原文規格又改了不少。
    再過1,2週,我會公佈自已研發的*線上電子書編輯器*部分測試版,到時再歡迎您指教。

    回覆刪除
  7. 看到程式設計數位教材的那張圖,非常眼熟,您應該是雲科資管的學長吧。

    回覆刪除
  8. 原來 Pubu 也有雲科人啊!!!

    回覆刪除
  9. 請問一下. 在那些網站上編電子書 會不會有被盜用的問題 ?

    回覆刪除
  10. 這個問題一定會存在,不管是用什麼方式編輯囉

    回覆刪除
  11. 請問如果有表格,應該使用何種語法,我試過 markdown 的用法,就是直接放 HTML table ,但是卻不行,會直接顯示出 html table 語法,而非表格。

    回覆刪除
  12. ContPub 使用 reStructuredText 的語法,有部份和 Markdown 類似,不過還是屬於兩種不同的標記格式;表格的部份請您參考一下這個範例:

    http://contpub.org/sandbox/show/78

    回覆刪除
  13. 了解,謝謝你的回答。

    回覆刪除

lyhcode by lyhcode
歡迎轉載,請務必註明出處!