wanderertw

[wanderertw]

將PDF轉成圖片的Automator工作流程

雖然大��數的PDF程式都內建轉檔功能，但在處理大檔案時時常會出現當機等等問題，這裡提供一個macOS的Automator Workflow檔案，可以一鍵將PDF檔案轉成適合製作EPUB 3 Fixed Layout的連續編號圖片檔。

PDF2JPG

開啟後會要你選擇要轉換的PDF檔案，然後將轉出的圖片放到桌面上的「bookimg」資料夾中，修改檔名為從001起的jpg檔案，最後會將圖片長邊修整為1600像素，可以配合mkepub轉換成EPUB 3 Fixed Layout格式。

＊注意，如果原來PDF內各頁大小或/及長寬比不一，轉出後的圖檔也會不一致，需要調整為一致後轉換成EPUB較佳。

[wanderertw]

將圖片轉換成EPUB 3的簡單工具

固定版面的EPUB 3檔案製作上並不困難，只要先把漫畫、雜誌輸出��固定長寬的圖片檔案，配合範本置換檔案調整就可以製作完成。但這樣的工夫未免瑣碎。一位日本朋友Waku Oe以PHP寫了一個Script mkepub，可以直接把連續圖片檔案轉換成EPUB 3，還可以順便輸出Kindle用的mobi檔案。十分方便。

如果你不曉得怎麼使用指令列執行，這個工具也有提供Mac OS X用的Automator版本，可以依照指示轉換。這個Script採BSD授權，如果你有雜誌或者漫畫想要轉換成EPUB或者Kindle用的mobi檔案歡迎使用。

這個指令列腳本可以將掃瞄或轉換出的連續編號jpeg/png檔案轉換成固定版面格式的EPUB3或者mobi檔案。

運作環境需要能夠執行php 5.3腳本，在OS X以及Linux，特別是OS X 10.7, 10.8環境，不需要特別的安裝與設定。

產生出的EPUB 3檔案，以能夠跨頁顯示的日本電書協EPUB 3製作範本為基礎，能夠在以下的閱讀程式正確顯示：

iOS 6：iBooks 3、Kinoppy、Kobo

Mac/PC：Kinoppy、Readium、Adobe Digital Edition 2（不支援跨頁）

Android 4.2：Kobo、Kinoppy、Himawari Reader

Kobo：touch, glo（不支援跨頁）

轉換出的EPUB檔案也適合轉換為Kindle使用，能夠同時轉換為mobi檔案。

並且能夠指定翻頁方向，目錄資訊，以及圖片跨大顯示等。

基本使用方法

下載以下ZIP檔案後解壓縮

mkepub_1_4.zip (2013/05/09)

解壓縮後，將mkepub資料夾移到「應用程式」（/Applications）資料夾下（OS X的話）。

請將想要轉換成EPUB的PNG或JPEG圖檔，放到資料夾中，檔案名依序編碼（如001.jpg, 002.jpg…）。

開啟終端機，移動到資料夾所在的位置，這裡將準備好的圖檔放在/Pictures資料夾下面，命名為"hoge"。

以"cd ~/Pictures/“指令移動到/Pictures下頭。

將資料夾名以參數輸入，執行放在/Applications內mkepub裡的jpg2epub.sh。

$ /Applications/mkepub/jpg2epub.sh hoge

就會在相同資料夾中生成"hoge_epub"資料夾，以及"hoge.epub"的EPUB檔案。

當在終端機輸入檔案名時，只要輸入一部分的檔名，按下Tab後就會自動補完。

圖片不會重新壓縮調整，直接打包成EPUB檔案。原則上各圖片檔案需要長寬比��致，如果掃瞄時尺寸有些微差異影響不大。

當jpeg/png檔案依照字母順序排列時，第一個檔案視為封面，第二個檔案之後為內容，預設為右翻（直排書、日本漫畫）。預設會在封面頁後面插入一張排序用的空白頁。

功能說明

書名與作者名

置放圖片的資料夾名就會直接用於書名，資料夾命名為”[作者名]書名"時，就會將作者名一併輸入到Metadata中。

當使用日文或中文命名時，在終端機指定時請將資料夾名稱以’‘包覆。

$ /Applications/mkepub/jpg2epub.sh '[作者名]書名'

翻頁方向

預設為右翻（直排、日本漫畫）。輸入"-l"參數則會變成左翻（橫書，美國漫畫）。請將參數輸入在來源資料夾名之後。

$ /Applications/mkepub/jpg2epub.sh hoge -l

空白頁

預設為了讓跨頁對齊，會在封面頁後加入��頁的空白頁面。在右翻時，等於內容從左頁開始。如果不要空白頁，請輸入參數"-p"。

$ /Applications/mkepub/jpg2epub.sh '[作者名]書名' -p

目錄資訊

請在置放圖片的資料夾中新增名稱為"navi.txt"的檔案，就能輸入目錄資訊。請以Tab區分目錄項目名稱以及對應的圖片檔名，編碼請使用UTF-8。

輸出檔案名稱與Kobo選項

輸出的EPUB檔案名可以使用"-o"參數更改。不更改時就會以圖片資料夾名加上".epub"。若加上"-k"參數時，就會輸出使用".kepub.epub"的Kobo用EPUB檔案。

放大與邊界

打包成EPUB時不會重新處理圖片檔案，但可以調整顯示時的放大倍率。可以消除邊界空白讓內容擴大。參數"-z"可指定放大內容的%，參數"-t"則是指定對頂端邊界的%，參數"-s"則是指定橫向外側邊界的%。不輸入-t, -s時，放大後置於中心。

例如整體放大105%，對上方邊界為1.5%時：

$ /Applications/mkepub/jpg2epub.sh hoge -z 105 -t 1.5

放大參數不適用於封面。

Kindle支援

本工具也可以用來輸出轉換成Kindle用mobi格式的EPUB檔案。如果安裝了Amazon提供的KindleGen工具，就能自動轉出mobi檔案。

KindleGen請由這邊下載，若使用OS X，請放在Applications資料夾中。請使用2.8以上版本。OS X以外的作業系統請放在適合的位置，修改php/conf.php檔案中的KindleGen路徑。

下載KindleGen之後，第一次使用時會跳出警告，請至少透過Finder執行一次並且同意。

要轉出Kindle用的話，請加入參數"-a"，轉換時會在生成EPUB後，繼續進行mobi的轉換。

Kindle用EPUB檔案與電書協規格有著以下差異：

為了能移到目錄，會在最後一頁後面插入目錄頁（nav.xhtml）。

封面由閱讀器插入，所以不會設定在第一頁。

OPF中加入了Kindle固定格式用的標籤。

每一XHTML頁面中的圖片，不使用SVG縮放，直接以img標籤置入。

同時不能使用上述的放大與邊界功能。

使用Automator的圖形工具（for OS X）

如果不會使用指令列工具，可以使用Automator製作成的圖形工具。

jpeg2epub.app.zip Automator程式

下載後解壓縮即可直接執行，但也記得先下載上面的mkepub，並且放進應用程式資料夾中，不然會不能轉換。

執行後會要求選擇檔案，請選擇置放圖片的資料夾。然後會跳出輸入參數的對話框。

輸入參數後按下OK鍵就會進行轉換。

這裡也提供Workflow檔案，執行這個檔案就會開啟Automator，也可以透過「檔案」→「轉換成」輸出為系統服務，透過選單就能夠執行。

jpeg2epub.workflow.zip Automator workflow

[wanderertw]

IDPF併入W3C

今天在芝加哥舉行IDPF論壇上，W3C主席Tim Berners-Lee演講之後，兩組織正式宣告合併意向，預計於2017年一月完成各種程序。意思就是：未來EPUB規格的修訂以及數位出版新規格的提出，都由W3C數位出版興趣小組來進行。

從技術的角度來看

IDPF活動最為積極的時間點應該是2007年制定EPUB 2，緊接著到2011年EPUB 3制定和EPUB 3.01修訂，送進ISO組織成為技術規格為止。2013年底W3C成立數位出版興趣小組後，大多數的技術成員重疊，變成W3C決定方向（如EPUBWEB），IDPF實際進行規格的制定。

但實際上遇到很多問題，EPUB 3.0規範其實相對穩定，在2013年後支援EPUB 3.0的閱讀系統少有修正，而主要的問題都在於CSS是否有規範，並且是否實作。而這一點IDPF無法處理，必須回到W3C的會議上來討論，並且提出規格。

而EPUBWEB的願景與其由出版商與相關技術者研議，不如回到W3C由對線上出版有興趣的公司及技術者參與。這樣雙頭馬車下去，不如合併，在技術推動上會相對快得許多。（規格制定是IDPF較有效率，但是實際推動透過W3C的內部溝通，速度會快上更多）

從組織經營的角度來看

IDPF雖然是國際級的組織，但實際還是一個美國的NGO，得靠會員的會費與各種活動的收入來維持營運。IDPF曾經有高達400名法人會員，但是在EPUB 3.0制定完成後，陸陸續續有所退出，加上非營利組織與新創公司的會費相當少（每年775美金）若要維持營運，必須提出能讓會員加入的誘因。IDPF提出了EDUPUB，以及W3C EPUBWEB的概念與工作小組，但是似乎難以如EPUB 3.0時一般吸引會員加入。制定技術規範的組織不僅需要行政人員，也需要技術人員協助，所以從現狀來看，應該相當辛苦。

W3C其實也是，在HTML 5正式進入推薦以後，開始提出Web Platform的概念，希望擴展到應用層面，制定更多業界需要的規格。當然數位出版也是很重要的應用，W3C有直接與排版相關的CSS工作組，以及負責國際化的i18n以及無障礙的A11y小組，彼此支援，會產生更大的綜效。

對台灣的影響

其實沒什麼影響。早期經濟部工業局推動數位出版時，要求受補助單位加入IDPF，但是實際在運作上鮮少有參與。儘管經濟部工業局一直希望讓這一百多家的公司作為後盾，選出一名IDPF理事，但是在以貢獻為主的技術場域上，不參與就沒有話語權。所以IDPF併入W3C後，工業局可以忘掉這個達不到的目標吧。

但是未來如果有技術公司想要參與數位出版相關的標準制定，W3C的會員費用相對高上許多。台灣過去還有中研院與工研院是會員，今年也消失在名單上。未來要參與的門檻會提高許多，不僅是會費，也包含理解會議進行脈絡的知識層。

但就產業來看，現在僅有少數平台商願意支持EPUB 3.0格式，停滯（甚至說堅守）在2.0格式的不在少數。或許我們與這方面的創新，沒有什麼關係。

未來的W3C活動

W3C除了日常的maillist活動外，一年有一次年會，各工作組還會有一到兩次的面對面會議，在世界各地舉辦。光是要參加這些會議就得要付出相當的費用。我想之後應該也會慢慢淡出，畢竟動輒六位數的支出，��於小公司來說是相當的成本。長期靠募款也不是正確的做法。

是否持續做下去，目前我還沒有明確的答案。而持續參與是否有實質的影響，我想確實有在推動一些規格的建立與實作的速度。但畢竟不是能靠一人一家公司進行的事情。

[wanderertw]

EPUB 3.1版初稿

前言：去年中開始的EPUB 3.1改版作業，本來預期會大幅改版，納入EPUBWEB相關的技術支援，如使用JSON作為OPF等。但由於研議時間短暫，所以將這些大幅變更的部分延後到下一版，這版本僅作些微修改。

原文請見： EPUB 3.1 Changes from EPUB 3.0.1 EPUB 3.1

EPUB 3.1的變更點

1, 新的核心媒體格式（Core Media Type）：

加入WOFF 2作為核心媒體格式。

2, 外部資源的回退機制：

當外部資源不在SPINE物件、也不嵌入內容文件，單純供Script使用時，不需要提供回退宣告。

3, 不強制RS支援EPUBCFI：

3.1版不強制閱讀系統支援基於EPUBCFI定址的超連結機制。

Package部分的變更點

1, 調整最小限度的metadata需求：

至少需要一個dc:identifier（識別碼）

至少需要一個dc:title（書名）

一個以上的dc:language（語言）

零個或多個dc:author（作者）

一個選用的dc:publisher（出版社）

零個或多個dc:type（類別）

其他都柏林核心集都不採用，若製作者希望加入更多的書目資料，可使用連結的方式處理。

refines屬性過去用於擴增說明使用，現在不能再用於meta元素。

file-as屬性可用於dc:title, dc:creator及dc:publisher元素，以提供閱讀系統排序時作為參考。

2, 移除NCX

EPUB 3.1不再支援EPUB 2的NCX目錄格式。

3, 移除guide元素

EPUB 3.1不再支援OPF中的guide元素。

4, 移除bindings元素

EPUB 3.1不再支援用來處理非核心媒體格式回退使用的bindings元素。

內容文件的變更點

1, 支援額外的HTML 5語法

EPUB 3.1將HTML 5作為核心媒體格式，閱讀系統須完整支援HTML與XHTML版本的HTML 5語法。

主要的變更為：用於XHTML語法中的epub:type屬性將被ARIA role屬性所取代。導覽目錄文件中需要同時使用epub:type與role來與3.01版前的EPUB相容。

2, 以CSS參考文件取代EPUB規範

EPUB 3.1移除舊的EPUB規範，並且提供CSS參考文件作為基準。

閱讀系統現在需要支援基礎CSS。

EPUB 3.1使用CSS工作小組提供的支援現況作為「官方定義」，取代舊有的CSS規範。

移除不能使用position: fixed的限制。

移除不能使用position: absolute的限制。

所有加上-epub-的CSS Speech語法因為缺乏實作，全部移除。

移除-epub-ruby-position語法

移除-epub-text-combine-horizontal語法

移除-epub-fullsize-kana語法

移除-epub-text-emphasis的短值語法

移除-epub-text-orientation的use-glyph-orientation與sideways-left值

3, 釐清scripts支援

EPUB 3.1對scripts支援做了以下調整：

container-constrained script僅限用於HTML5 iframe元素（移除embed與object）。

閱讀系統應支援container-constrained script執行（因安全與隱私考量，不再為必須）。

閱讀系統應支援固定版面，以及定義為rendition: flow的「文件捲動」、「持續捲動」內容的spine層級script執行。

如果閱讀系統支援文字重排內容spint層級的script執行。就必須支援「文件捲動」介面，也應支援「持續捲動」介面。

4, 額外的WCAG支援

過去僅推薦使用script的內容文件需要符合WCAG規範。EPUB 3.1現在推薦所有的HTML內容文件符合WCAG 2.1 AA等級規範，並且推薦SVG內容文件符合SVG無障礙指南。

5, 移除switch元素

EPUB 3.1不再支援用來表示內容狀態的switch元素。

若有數學算式需求，建議使用MathML取代文字與取代圖片屬性。

6, 移除trigger元素

EPUB 3.1不再支援用來控制影音內容的trigger元素。

請使用HTML5的video、audio元素的原生控制界面。

[wanderertw]

W3C TPAC 2015報告（完）

注音符號是我參與W3C活動的契機，也是到現在為止尚未完成的主要工作。

2012年時，注音符號在Web與電子書中的呈現幾乎沒有實作。若要勉強辦到，只能透過注音字型來處理。但注音字型一般會按照教育部一字多音審定表造六套字型，若你要顯示破音，就需要透過複雜的字型指定與一堆<span>在內文中標注切換。除了技術上有所難度外，提供出來的資料也缺乏語意。而注音若能被廣泛應用，不僅能應用在初等教育上，也能變成大數據，來協助TTS（Text to Specch）引擎，為視障提供更準確的機讀機制。

這三年間，工作大致上可以分為兩個部分：

注音符號的資料結構

注音符號的顯示排版

注音符號的資料結構

2012年資策會囫圇吞棗、蜻蜓點水似地參與了EPUB 3的規格制定，也硬把注音排版需求錯置提交到了IDPF，然後貿然地發佈了一套電子書實作文件，當年注音的標註方式是這樣：

<ruby>我<rt><ruby>ㄨㄛ<rt>ˇ</rt></ruby><rt></ruby>

也就是：「ㄨㄛ」是「我」的Ruby文字，而「ˇ」是「ㄨㄛ」的Ruby文字，這稱為巢狀（Nested）結構。這種標註方式一方面過於複雜，另一方面語意不對。後來在HTML 5 Ruby Markup Extensions中修改標註方式為：

<ruby>我<rt>ㄨㄛˇ</rt></ruby>

後來還處理了調號問題，例如輕聲時，應該放在注音的後面還是前面，決議是符合語意，放在前面，如：

<ruby>呢<rt>˙ㄋㄜ</rt></ruby>

雖然許多輸入法直接輸出時，會把輕聲放在最末，但在教育使用上，還是會放在前頭，所以依照常用的方式處理。

後來唐鳳試著使用萌典API試做了一個產生器，Ethan也做了一個標注器。在產生內容上，降低了相當的障礙。

當資料結構確認下來後，就要處理顯示排版的問題。

注音符號的顯示排版

在這段時間裡，正好回頭處理了Ruby排版與內容的分離，提出了CSS Ruby Layout Module Level 1這份文件，很快地，最關鍵的語法 ruby-position: inter-character，也就是在橫排文字中要將注音放在右側的語法，被Apple實作在Safari中了。

但是又遇到了另外一個問題：調號既然不能使用巢狀Ruby處理，那該怎麼辦？是要讓瀏覽器自動將它移到右邊，還是要一組機制來辦到？

注音符號與OpenType字型

後來決定採用OpenType字型裡的技術來試做。OpenType中有一項GPOS的功能，全名為Glyph Position，使用這項功能，就可以試著在一定的組合下（例如注音接調號時），移動字元的位置。

我在g0v開了一個案件，在But Ko的協助之下，做出了初步的實驗。目前能在Safari上呈現，但還有些小缺陷。但終究可以說：找到了一條出路。

現在在中研院莊庭瑞老師提到教育部後，希望能在技術上做出完整的規範。再試著提交到W3C希望各瀏覽器都能夠支援這項OpenType功能。也許還需要一兩年，但至少注音在瀏覽器、電子書上的顯示問題，將要見到解決。

[wanderertw]

W3C TPAC 2015報告(2)

W3C裡頭的i18n（internationalization）工作小組，目的是為了讓Web的世界能夠符合各地區的語言文字需求。讓Web不只是西方Latin語系世界的Web，而能讓世界上所有人都能在Web上可讀、寫自己的語言。但是前面敘述到W3C的會員結構與組成，就算國際化是使命，但要如何推動使其變成真正可用的標準並且實踐，不是無償就能達成。

例如參與者付出的時間、撰寫文檔研究的支出。以及每個工作組定期電話會議的參與，一年一到兩次的面對面（Face to Face）會議等等。光是差旅費就會需要數十萬元。對於大企業而言��參與標準化工作不僅可以推出與自己目的相符的提案，也可以帶回其他會員的意見來建立共識。但對中小企業或個人而言，常態性的支出就會是很大的負擔。

中、日文相關的需求大約在2000年前後首次提出。我想可能是因為數位典藏計畫下因為XML規格而參與W3C時一併提出了。但在實作上卻受到擱置。

日本政府從2008年起，就對出資資助專家在W3C運作，不僅止於JLREQ的撰寫，也包括實作層面的規範，如CSS Writing Modes Level 3、CSS Ruby Layout Module Level 1等等。最後在產官學一致的推行下，透過EPUB 3格式電子書作為產業標準，而實現出這些表現性。

日文排版要做到怎麼樣的程度？

過去幾年，日本政府總務省＋慶應大學＋電子書產業相關會員（樂天、Sony、Antenna House等）非常努力地推動以上需求的實作。但隨著日本電子書產業的穩定，似乎不再那麼積極。但有兩家公司加入後，開始了新一波的推動。

一家是Vivliostyle.inc，這家公司的創辦人村上真雄過去在Antenna House負責XML排版系統，使用XSLT、XSL-FO等語法，讓文件能夠幕後排版成印刷格式。但因為XML相關標準過於成熟而停止發展，他希望能採用HTML、CSS技術取而代之，於是成立這家公司，積極參與標準化工作。

另外一家是BPS，這家公司除了以Ruby on Rails提供網站製作服務外，也提供客製的Webkit作為電子書閱讀程式「超縱書」。該公司的董事榊原寛曾在慶應大學修讀博士，也因此加入了W3C。

在今年TPAC會議前，榊原寛事先安排了一場聚會，讓日本對於排版與Web技術感興趣，但非W3C會員的公司代表與CSS WG的成員先見面，談談該如何推動更進一步的日文排版。日本於本領域著名的IT記者小形克宏先提出了一個重要的問題：「要將JLREQ實現到怎麼樣的程度才算完成？」

JLREQ中提出了相當多來自活字排版的規則，包含標點符號的擠壓、壓縮等。但現狀無法透過CSS來實作。實際上幾乎所有的電子書，都是使用Writing-mode來使其直排，並且透過Text-align: justify來強制對齊行頭行尾，將多餘的空間平均分配到字距之中。

這種作法，就不符合JLREQ裡頭「基本版面」，也就是中文所提的「版心」的定義。該定義要求先決定文字尺寸，再決定每行幾字，最終算出的行長需要為文字尺寸的整數倍。也就是回到活字排版的做法，採格狀排列，這時對於標點做出調整才能讓版面呈現更好看。

對於電子書產業而言，也許不覺得做到這麼細膩相當重要。但是出版社希望保留其體裁、印刷與POD公司希望技術上能夠達成，讓出版從數位檔案（HTML、XML）轉換到印刷用檔案時也能自動排版，來降低成本、快速完成。

所以在CSS WG會議上，由Vivliostyle的Florian Rivoal重新提出了文字格點（Character Grid）的要求。

文字格點（Character Grid）

文字格點的概念，其實早先曾經出現在2003年版本CSS3 Text Module中，並且受到微軟在IE上實作出來。只是在改版調整中，退出了CSS，這次的提案等於把這概念給拯救回來。

不過所謂文字格點，還是希望一行的長度能正好為文字尺寸的整數倍。而簡單的處理如下，假設：

一字尺寸為20px

文字顯示空間為410px

最大字數為20 x 20 = 400px

10px空間變成padding或者margin

當文字尺寸改變時，重新計算

這樣確保「基本版面」與「版心」的概念能被實踐，後續就可以利用CSS Text Module Level 4的Text-spacing調整，來做到更多JLREQ上的需求。同時要是加入更多中英混排的案例，也可以做到老貓「縱橫對齊」需求的實現。

例如，要求英文字出現在行內時，使用整數倍漢字空間，英文與漢字的間隔動態調整（大於0，小於0.5em）。但還要面對更多的狀況，例如：

如上圖，當The Sun兩個字剛好能夠斷行時，The是否需要對齊行尾？Sun是否要對齊行頭？或者只要放在格點的正中央即可？

另外如果遇到英文字位於行尾太長時，是要：

整個字移到下一行，前一行尾留白？

若可以斷行（hyphenation）時，該如何處理？

是否可以強制切斷英文字，從任何一處斷行？

這些都要提供額外的資料，以上是TPAC上的第二項提案。

[wanderertw]

W3C TPAC 2015報告(1)

這是我第三年參加W3C TPAC年會。

第一年在深圳舉辦，正好遇到北航的W3C工作人員，讓中文排版工作小組成案；

第二年在Santa Clara舉辦，這時工作小組已經成立，主要安排進度與目標；

第三年在札幌舉辦，CLREQ已經發佈草稿，我希望能夠開始推到時記得規範上。

W3C的變化

就在這三年間，W3C的目標有著大幅度的變化。

2013年，HTML WG在如火如荼地做HTML 5規範的最終修訂。

2014年，W3C公佈HTML 5進入推薦（Recommendation）階段，也就是任務的一時完結；同時推出Open Web Platform的構想，目的是希望將Web打造成更完整的平台。

2015年，工作組已經有了大幅度的變化，HTML WG在最後一次會議後，併入WebPlatform WG中；而各種汽車、數位看板、Web of Things、Web Payments等與實際產業相關的IG/WG一一成立。W3C的目標不僅是底層技術的制定，也希望能延伸到各種實際的產業，並且集合需求來制定共通標準，像是安全性等等。

不變的工作

而國際化（i18n）與CSS WG的變化不大。還是逐步尋找需求、提出草案、尋求共識、予以實作。這幾年裡，多了許多Level 1的規格，如：

CSS Scroll Snap Points Module Level 1

CSS Round Display Level 1

CSS Grid Layout Module Level 1

CSS Logical Properties Level 1

這些指的是過去未曾出現在CSS中，新提出的需求與語法，同時也有許多繼續往下走的Level 4的規格，如：

CSS Text Module Level 4

CSS Font Module Level 4

原來存在於CSS 2中的內容，在CSS 3中被拆成許多Module，並且稱為Level 3，然後透過規格與實作，當走到CR（Candidate Recommendation，如Writing-mode）時，代表多數的瀏覽器已經實作該規則，若有額外的需求，請提到Level 4作為下一階段。

而我希望來自CLREQ的需求，能夠趕上這些Level 4的進度。雖然CLREQ還在寫，但應該已經可以提出一些提案，送進CSS WG。

中文的常用字體

第一個提案是中文常用字體，在CLREQ中列舉了中文常用四種字體。

但是在Web上，最常用的是黑體，這個問題是因為：

若要跨系統指定相同字體，透過CSS Font中的Generic Family最為方便，但現狀僅對應宋/明體與黑體。

雖然Windows與OS X都有以上四種字體（仿宋僅有簡體字型），但iOS與Android僅有黑體可用。

後者我們只能提出需求，但前者是標準化的範疇。

Web內容可能不需要這麼多種字體，但在將印刷書轉換成電子書的過程中，當然希望能夠將原有的樣式變化重現。缺乏Generic Family的對應下，若要使用楷體，必須窮舉，如：

font-family: "Kindle的楷體","其他楷體","標楷體","楷體-繁"…;

只要少了任何一家預載楷體，就不會正常顯示。為了降低作業的複雜度，若能變成：

font-family: cursive;

相對簡單得多。

目前在提案上，我所推動的是將cursive對應到楷體。畢竟在中文印刷字體中，楷體是最符合cursive定義的一種。現在OS X El Capitan已經支援，Firefox也將於近幾版支援。我也希望各閱讀程式能夠做到cursive對應楷體的mapping，變成一種約定俗成的使用方式。

也有人覺得楷體與仿宋的使用需求不大，但是台灣的公文規定使用楷體，大陸則是在GB/T 9704-2012
《党政机关公文格式》中規定使用仿宋作為公文用字體；這也是各桌上作業系統內都會有簡體仿宋字體的原因。

但從CSS 1起的Generic Family只剩下monospace與fantasy可用。畢竟所有的中文字體都是等寬字，且仿宋也沒那麼夢幻。若要指定仿宋，就應該提出新的Generic Family，目前我的構想如下：

一、serif的italic：

日本前幾年曾討論過這件事，仿宋體在日本稱為宋朝體，他們認為漢字沒有斜體，若按照italic手寫的定義來看，宋朝體比較像是serif的italic形式。雖然這種想法語意上是對的，但實際上沒有任何一家字型公司做出字型家族，把仿宋放到宋體作為italic使用。所以在實務上有困難。

二、新Generic family：

又分為幾個提案：

1, Fangsong：也就是直接使用「仿宋」命名。但就僅限於中文的一種字體，不那麼Generic，所以不是很好的提案。

2, Formal：若以功能來定義，將公文書用的字體訂為「Formal」，但我們也不確定是否其他國家與區域也規定公文書需使用字體，所以屆時也會顯得侷限。

3, Antique：若以外型來定義，仿宋是活字設計上，介於明體與楷體間的字體，也就是復古字，所以命名為「Antique」。我想這就廣泛得多了。各種語言、拉丁、日文等應該都有復古的電腦字體。而Antique在西文書的排版上也是共通的術語。

以上是今年TPAC上的第一個提案。

[wanderertw]

以iBooks Author製作EPUB

Apple前日更新了iBooks Author，新增了製作EPUB Reflow（文字重排、流式）的功能。這項工具應用在電子書製作上，可以輸出Apple稱為Multitouch book（.ibooks）的互動影音圖像書，也可以輸出文字為主的EPUB格式。其中Widget也有部分互通，如圖庫、影片與HTML Widget。

但是輸出的EPUB 3雖然採標準格式，但裏頭有著相當多iBooks專用的樣式與語法。以致在iBooks（Mac、iPad、iPhone）上頭版面近乎一致，但是換到其他閱讀程式上，就會有相容性問題。

除此之外，也不支援直排、註解等功能，但具備如Pages、Word一般的樣式管理，字體也不會隨著書而輸出，你只能用宋、黑、楷等iBooks內建的中文字體。

從最底限來看，這樣WYSIWYG的製作工具，至少可以讓製作者脫離Sigil，轉向這工具。但不幸的是，製作出來的EPUB，也僅能送上iBooks store販賣、提供；或在Apple裝置上以iBooks閱讀。無法送到其他支援EPUB 3的書店（如未來的樂天Kobo、BookWalker、博客來等）。

如果你是個人作者，想要在iBooks store上賣書，或者你是出版商，只想對應iBooks store需要EPUB 3的問題，你可以使用iBooks Author。但如果你想要做到進一步的排版，或者達到單一書檔、多店共用的狀況，這款工具不是好的選項。

[wanderertw]

談談DRM

任何數位���容的商業模式裡，都會提到DRM這個詞彙，DRM的全名是Digital Rights Management，直譯是「數位權利管理」，白話點說，就是「內容保護機制」，也有人稱DRM是「防拷貝機制」，甚至「反盜版機制」，但嚴格來說，這些俗稱不大正確。

DRM由誰提供，限制了些什麼？

DRM通常是由接觸到消費者的終端提供，以電子書為例：

出版商→電子書店→消費者

這時就是由電子書店提供經由DRM保護的內容給消費者；出版商給電子書店的檔案不需要DRM，但若出版商要直接賣給消費者時，一般也會加上DRM保護。而DRM保護了：

使用者：誰可以開啟內容，通常僅限購買的消費者。

裝置：使用者有幾台裝置可以開啟內容，一般有所限量。

期間：通常用於租借，過期後就無法開啟。

列印與分享：使用者可以合理使用部分內容的比例。

一般來說，就是在Amazon購買的內容，只能透過Amazon提供的App開啟，而每個帳號只能給固定數量的機器，如平板、手機使用，超過數量，就必須調整授權。

DRM有什麼不好？又為什麼不得不為？

DRM在電子書圈子裡也有另一種解釋，就是「Don’t Read Me」。就是諷刺受到機制保護的電子書，只能在符合以上範圍之內閱讀。但一本印刷書可以自由傳閱、拍照、掃瞄……沒有這麼多限制。

但數位檔案天性就是可以複製、透過網路傳遞，在沒有DRM的狀況下，對於作者與出版者沒有保障，於是DRM就限制了使用者複製散佈的可能，以保障作者與出版者。

可接受的DRM：服務讓你注意不到保護

幾乎沒有任何一位消費者不對DRM的限制感到反感，但是DRM在一些狀況下，會讓消費者察覺不到，或者願意接受：

一、亞馬遜的案例：亞馬遜的Kindle電子書商店，在歐美近乎獨佔。當消費者想要購買電子書時，幾乎都會到亞馬遜上購買。消費者僅從單一商店購買內容時，就不會太在意是否有DRM。同時，亞馬遜提供了自有的專屬閱讀器，以及在平板手機電腦上各作業系統都有推出閱讀程式，解決跨平台問題時，也能輕減消費者的反感。

二、Netflix的案例：Netflix是月費制的電影與影集線上收看服務，使用串流機制提供內容。當消費者選取一部影片時，從伺服器串流影片到裝置上頭。看完以後，檔案不會留在裝置上頭。像這樣以技術機制滿足消費者的做法，也不會讓消費者覺得受到限制。

反之，如果在該地市場，消費者購買數位內容不僅於單一商店購買，又沒有能完整支援各系統時，DRM的限制就會變得相當明顯。

DRM可不便宜

DRM在技術上是以加密為核心，但加密法如同影片壓縮技術一般，是由舊的技術延伸出新的技術，而舊的技術通常會受專利保障，以至於建構一套獨有的加密法時，會需要取得相關技術的授權。在加密法之外，安裝在使用者裝置上的程式也需要嚴格注重安全，不然都可能會受到破解。

如果要想出一套機制，如Netflix一樣，更需要審慎規劃，不然內容依然會以快取等方式存在使用者裝置上。

那麼，可不可以不要DRM？

這就是DRM-Free的由來。指銷售端賣給消費者的數位內容檔案，不使用任何機制保護。一方面還給消費者自由使用內容的權利，另一方面銷售端不需負擔昂貴的DRM機制。

但從反面來說，銷售端得面對消費者複製、散佈的風險；消費者也可能獲得不了額外的服務，例如：在不同裝置閱讀同一本書，彼此能同步進度、書籤等等⋯⋯且DRM-Free的內容也不一定能於所有裝置、程式上開啟、表現一致。彼此之間會產溝通上的成本。

也有另外一種做法，是在內容檔案中加入消費者的個人資訊，如姓名、電子郵件等等，若消費者不能除去這些資訊自行散佈，也可由此追查出來源。

DRM v.s DRM-Free：是個商業問題

一般在內容授權出版、授權發行的狀況下，授權方為保障自己的權益，都會要求禁止複製、禁止讓終端自由散佈。於是像翻譯書、海外電影、音樂等，在地的出版社、發行與唱片公司沒有逕自以DRM-Free散佈的權利。同時在海外成熟的機制下，DRM不會讓消費者感到過於反感，所以DRM是數位內容在一般商業體制下的常態。

而以DRM-Free的方式提供內容，可能的狀況包括了：

創作者想直接販賣給消費者，沒辦法建構DRM機制。

販賣方希望數位內容在被消費者購買後能夠自由散佈，作為行銷的方式，獲得更多愛好者以及品牌效益。

對開放理念的堅持。

兩者之間沒有優劣之分，最糟糕的狀況會是：DRM機制保障不完全，消費者可自行破解，以致於未能達到保障授權方與創作方的利益，也變相懲罰付費的消費者。

[wanderertw]

如果你真想面對數位出版⋯⋯

這裏所說的數位出版意義很狹隘，不提報紙雜誌如何走向Web，也不說網路原生的新媒體，就專注在「書籍出版」，尤其是面對消費者的書（把學術與教育放在一邊，雖然面對的問題一樣）。只講一件事：出版社想要把出的印刷書，轉換成電子書，放到通路上販賣，然後獲利。

這件事有點困難，尤其在2010年起那一波如狼來了的風潮後，許多出版社的總編、老闆都不相信這件事會成真。但2015年卻是我看到第二波即將開始的一年，無論是更成熟的通路（人流、金流、產品、系統、還有電子書最重要的「信任」），或者基礎建設（像是格式、工具、字體等等）。都在這一年陸續到位。

這些條件慢慢聚集，狀況不再像2010年那樣土法煉鋼，如果這一波依然無效，那麼，就技術的可能性來說，我暫時看不到未來。

如果你真想面對數位出版，我希望您能聽得進去以下這些建議：

一、PDF真的不能幫到你

PDF不能幫你什麼，真的。分為兩部分來談，一部分是販賣、另一部分是電子書製作。

先談談販賣。Google Play Books自2013年9月開張以來，已經成為台灣最大、銷售量最高的消費者向通路，但是，還不夠好。Google Play Books上賣的書，大多數是PDF檔案，簡單來說，Google Play Books與台灣各家電子書店沒有什麼差異，但Google Play Books之所以銷售量好，原因我覺得是——人們信任Google，而且透過Google Wallet的金流方便"一點"。

行動裝置市場已經很成熟，手機的量大於平板的量，但就算手機大到7吋，依然不適合讀PDF檔案。如果出版社還繼續把PDF當作電子書，那麼只能說是具有缺陷的產品。銷售再好，終究會到頂。EPUB並非完美的格式，但是對於行動載具來說，卻是基礎。PDF沒有被明文排除在「電子書」之外，但在電子書銷售真正成熟的市場，卻自然地忽視了PDF，不將它當作正式的產品看待。

再談談製作。希望你先閱讀IDPF執行董事Bill McCoy的文章，他在加入IDPF之前，曾經多年負責Adobe Acrobat產品，PDF的技術缺陷，他說明得相當清楚。在製作上你不能使用PDF，因為它的可再利用性非常差。

如果你手上是好的PDF，可以透過工具把文字摘出，並且多少能辨識出一些樣式；但如果你手上的PDF裏頭是一頁頁的圖檔，就只能取出圖檔，���非透過OCR光學辨識試著分析出文字，但你會需要極高的校對成本去處理這本書。

就算PDF能摘出文字，你還是需要調整結構，手工處理，結果還是需要額外的人力工時——你也可以不處理，但出版社應該對電子書品質負責，就如對印刷書品質負責一樣。

二、沒有簡單的工具

台灣EPUB格式的專家不多，甚至可以說PDF的專家都很少（高手多半在印刷界）。以至於迄今無法打造出好的工具。EPUB的基礎技術就是HTML與CSS，也就是網頁技術，這麼多年來，各種「所見即所得（WYSIWYG）」的編輯工具，像是FrontPage（已死）、DreamWeaver（已不堪使用），都失敗了。也代表以同樣技術製作電子書時，更不可能拉拉點點就做出一本全平台上看起來都相同的書，Sigil不可行、套用廉價如部落格後台那樣的編輯器也不可行。

如果真的有一項所見即所得的好工具，就會需要充分了解EPUB格式，以及業界技術實作，同時，使用者也需要學習如何使用，才能做出完善的EPUB檔案。但如果最終還是要人力拉拉點點調整，那不如學習結構化的簡單語法，理解「所見即所指（WYSIWYM）」的工具，如Markdown。也許Markdown功能太簡單，但在學習更難的語法之前，還是應該從Markdown開始學習。

三、外包、內製還是丟給別人做？

台灣電子書發展的先天包袱就是：「我們使用中文」。英、法、德文等Latin語系在文字處理技術上相當成熟，成熟到電子書的製作技術幾乎可以完全自動化，但也少不了製作後校對、修正的繁瑣流程。過往美國的出版商也採外包製作，但這幾年為了因應電子書的快速出版，也逐漸整合回編輯流程裡，改為內製。

而在日本，完整的產業鏈讓印刷、排版業接下了電子書製作的業務，但需要額外的成本，同時也少不了繁瑣的品質確認流程。

台灣沒有以上優勢，在人力、產值、成本的考量下，也很難養出外包製作的公司（別用廠商，電子書沒有工廠）。中文先天在製作上就相對複雜，若希望降低成本，大概只能外包到大陸。大陸有專門接電子書製作的外包商，但我在訪問時，也遇到出版商問：「台灣能不能協助轉檔處理、大陸人力太貴了！」更何況，台灣的出版商對大陸的轉製公司，多少會有信任問題。

大陸也有許多出版社在政策扶持（或者說壓力）下，開始導入內製的訓練流程，甚至打出「不能適應就下崗、不能轉型就死亡」這樣的宣言。既然終究如此，那麼我覺得早一點內製，會是比較好的選擇。

你也可以交給販賣方、電子書店來製作。但是多少會需要讓利，例如Amazon能夠幫出版社代為製作專用的格式（其實還是先做出EPUB檔），但拆帳比會少5%（一般Amazon與出版社五五分帳），不賺錢時，5%不多；賺錢時，5%不少。

四、考慮下一步

數位化對出版帶來的變革有哪些方面，簡單可以分為「工作流程（workflow）、通路（Channel）、行銷（Marketing）、營運（Operation）」，以上所提全部都在處理工作流程，但行銷與營運可以同步進行。尤其是行銷。缺乏實體的電子書透過網路來進行行銷會得到最大的效果，而網路上行銷的效果得益的並不是電子書而已。如果能趕緊處理前面兩項的轉型，才能處理後面真正重要、開啟市場的關鍵。

[wanderertw]

Accessibility in Mind

從事數位出版相關國際標準化活動以來，有兩個領域我一直力有未逮。一個是EDUPUB，由IDPF與W3C、IMS Global三個組織一齊推動，關於電子教科書與數位學習標準化的活動。隨著美國教科書實質數位化，以及各國（例如韓國）由政府帶頭參與，而在這兩年積極活動。因為涉及的領域過於廣泛，我個人無法參與。

另一個領域是Accessibility，台灣網路人Jedi將其命名為「親和力」。白話點講，就是給視障、聽障、身障與學習障礙者，也能如常人一般接觸內容的輔助功能。

一切都沒有數位化的時代，以上幾種障礙者想要接觸內容，都需要花上不小的力氣與成本。例如電影「春風化雨1996（Mr. Holland's Opus）」中，為了讓有聽力障礙的孩子聽到交響樂，特別在舞台兩側加裝了顯示器，至少讓他「看」到音樂的變化。

盲人若要讀書，就得另外請人錄製有聲書，或者製作成點字書。這些額外的作為，都被視為「給予」或者「愛心」。障礙者能夠存取內容，等同作為福利的收受者。

但透過數位化的內容以及程式的輔助，就能夠提供障礙者與常人一般的能力來接觸內容，像是：

視覺障礙者可以透過TTS（文字轉語音）或者數位點字顯示器閱讀、

視覺障礙者可以透過嵌入字幕來看電視電影，知道有哪些聲音、

聽覺障礙者可以透過等化器將音樂視覺化「聽見」音樂、

肢體障礙者可以透過數位輔具操作內容⋯⋯

如此一來，他們不再是被動的「接受者」，而與一般人一樣，是內容的「消費者」。

但以上這些數位「親和力」，還是需要做些額外的事情才能達成。不過不像做一本點字書、錄一本有聲書一般高成本。內容製作者的態度應該從「給予關懷」，改為「理所當然」。「親和力」是基礎，而不是額外的工作。

舉個說明Web及電子書親和力的常用案例，當我們置入一張圖片時，HTML會這麼寫：

<img src="image.png" />

但對視覺障礙者而言，這張圖他無法看到、讀到，你必須提供額外資訊，如：

<img src="image.png" alt="這是一本點字書"/>

這麼一來，當TTS等輔助工具遇到這張圖片時，就會朗讀「這是一本點字書」，這只是一件小事，但卻能提供視障者「看」見這圖片的可能。

做出一本結構良好的電子書，不是過度的要求，考量到各種讀者的需求，只是基礎而已。（再說一次，不是施予愛心）。

我最近與國立台灣圖書館有些接觸，發現在電子書與親和力上，台灣的認識還並不是相當普及。也許，可以從一些文件資料翻譯開始著手：

W3C Web Accessibility Tutorials

IDPF EPUB 3 Accessibility Guideline

Accessible EPUB 3

[wanderertw]

i18n & EPUBWEB

經過頗令人挫折的CSS會議後，TPAC會議第四日同時有i18n WG與數位出版IG的會���。在i18n WG花了些時間解決中文楷體的問題。

i18n是什麼？

i18n是internationalization的簡稱，因為i與n之間有18個字母，就縮減成i18n。順帶一提：近用性accessibility也被縮寫成a10y。i18n工作小組主要處理各種Web規範國際化的問題，像是比較實用的CSS Counter Style Level 3，裡頭有著各種語言的編號方式，當然也負責各種排版規範，像是JLREQ、KLREQ等等。所以中文所遇到的問題，也會在這裡討論。

兩個議題：楷體與斜體

楷體的需求大致上和CSS中所提及的狀況一樣。很可惜地，i18n在沒有參考資料的狀況下，也無法馬上與CSS小組取得共識。但是卻有一點可以協助。

目前大多數的瀏覽器都提供了自定字體的功能：

但是如你所見，在Serif、Sans-serif、Cursive、Monospace、Fantasy五個Generic Family中，只能調整西方文字常用的Serif、Sans-serif、Monospace三種，而Cursive與Fantasy則無處可調。

在CSS Font Module Level 3裏有這麼一段話：

User agents are encouraged to allow users to select alternative choices for the generic fonts.

就是建議瀏覽器開發商能讓使用者自行調整這些基本字體。i18n能做的就是在國際化的最佳實踐參考文件上加上這一點，希望瀏覽器能夠實作。

至於iOS/OS X中Cursive會強制轉斜的問題，則是直接請教在場的Apple Webkit工程師，他建議在前兩天提出的Bug Report上加入對於電子書的影響，然後盡可能地追蹤進度。這個問題看來不只是Webkit的問題，而是出自Core Text。

※2015/7/2補充：Apple已經在OS X 10.11 El Capitan中修正cursive會強制轉斜的問題，如下圖。

另一點是中文在某些標籤中預設轉斜的問題，例如：「<em> = emphasis = 強調」這個標籤。這一點需求只是提出而已，不會做任何的更正與調整。畢竟對於英文來說，原本採用<em>斜體強調的文字如果一下子都變「直」了，反而分不出來。所以還是以網站國際化的最佳實踐文件處理，希望各網站在處理中文時，不要使用斜體，<em>以底線、強調點、粗體、黑體等方式加上CSS來達到強調效果。

EPUBWEB是什麼？

前幾天的Books in Browsers上，W3C 數位出版興趣小組聯絡人Ivan Herman以及IDPF CTO/小組主席Markus Gylling一併發表了EPUBWEB這個格式（投影片）。這個格式是數位出版興趣小組未來的目標，主要希望將原來供離線使用的EPUB格式，能夠更友善地與Web接軌，可以應用在學術出版、企業文件、文書典藏單位供全文檢索、教育使用上頭。

當然這是現在才開始的工作，到完成為止還要花上幾年，技術上需要突破的點包括：

不以現在的ZIP方式壓縮；

需要簡化各種資料；

需要找出在Web裏讓書擁有唯一識別碼（ISBN等⋯⋯）的方法；

瀏覽器該怎麼實作分頁；

要讓讀者控制到什麼程度。

若這理想能夠實現的話，電子書與網頁之間的區隔將會更為模糊；也更能夠讓電子書得以普及，應用在機構之中（而不是單純地「賣書」）。

如果你是出版商的話，應該會想問：「EPUB 3都還沒成為主流，又來個EPUBWEB？該怎麼追？」不過不要害怕，W3C標準化就算定下來了，還有各種子規格要制定，最後還要瀏覽器實作，完成需要好幾年的時間。在W3C memes上有一則嘲諷：

Today in the Digital Publishing IG, members of the IDPF invited the W3C into their glass house.

另外一點，EPUB 3的內容與樣式完全使用HTML 5與CSS 3技術，所以未來如果需要轉換的話，可以輕鬆相容。由於在場也有Wiley、Hachette Livre、BISG等出版業界的會員，大家經歷過EPUB 2到EPUB 3的轉換，相當重視這項問題。

好，EPUBWEB才剛開始制定，所以別怕。

其他⋯⋯

TPAC會議的第三天通常是休息日，會有自訂主題的小組會議、Lightning Talk、Demo等等活動。今年是W3C 20週年、Web 25週年，特別舉辦了一場聚會，有一系列的演講。

MIT的Alex 'Sandy' Pentland談數據與隱私

FCC主席Jessica Rosenworcel不���5G，而是以FCC的角度談A10y，強調技術一定要考量到障礙者的使用權利

INTEL則談Web技術的硬體加速（雖然被場下罵死了）

Panel則主談「誰統治網際網路」（不是Web 25年嗎？）

最有趣的是在晚餐開場前，有這麼一段：

Vint Cerf是TCP/IP的共同發明人，號稱Internet之父；Tim-Berners Lee是Web之父，W3C幫他們做了兩件T-shirt，一面寫著：

I invented the web.

I invented the internet.

另一面寫著

I did not invented the internet.

I did not invented the web.

這T-shirt大概也沒人敢穿⋯⋯

令人意外的是Opera的Håkon Wium Lie悄悄地現身在Lightning Talk會場，這下子Internet之父、Web之父、CSS之父都到齊了⋯⋯這圈子裏沒有xxx之母嗎？

[wanderertw]

楷體在數位時代，何去何從？

W3C TPAC 2014 CSS會議上，談到的中文議題是「將CSS Font中的楷體移到Generic Family的cursive」。

這議題在去年TPAC後，我就透過Mail-list提出，但當時CSS 3 Font Module Level 3的編輯John Daggett不在位置上，所以討論完，也就被一直擱置。今年因為北航協助處理電子書字型的問題，又被納入議題之中。

至於為什麼要處理楷體呢？讓我先從日本電子書製作的案例開始說起。

日本電子書界指定字型的方法

原本在不同作業系統中指定相同的字型就不是件容易的事。像是日文的明朝體，在Windows裡頭是MS明朝體，在OS X與iOS中是Hiragino Mincho，在各電子書閱讀程式/器中預設的字型又不同，例如Kobo使用森澤的Ryumin⋯⋯因為各種系統所使用的字型不同，讓CSS指定變得更加麻煩。

不過，一套標準的日文字型內含兩萬多個漢字，差不多要8-10MB，和中文一樣，不會有太多種選擇；作業系統/瀏覽器/閱讀程式都會指定好預設的字型。讓EPUB的製作者只要指定Generic Family，就能直接套用預設字型。

像是明朝體（明體）是：

font-family: serif;

指定哥德體（黑體）則是：

font-family: sans-serif;

這麼一來，電子書的字型呈現就幾乎沒有什麼問題。

中文楷體的狀況

但是中文——無論簡體或者繁體的印刷書，從過往以來，明/宋體一向是標準內文字，而在節錄、引用、對話、署名上最常用的字型是楷體，或者仿宋體。之後隨著數位技術的進步，黑體的應用才逐漸廣泛。

但從印刷書過渡到電子書時，理應保持相同的排版傳統，不大可能把楷體、仿宋全部以黑體取代。不過，要怎麼指定楷體呢？你會需要一連串的CSS來做到這件事，像是：

font-family: "Kindle用的楷體", "linux用的楷體", "其他閱讀程式有的楷體", ... "STKaiti-TC", "DFKai-DB";

簡單來說就是：窮舉、排序。以確保楷體能被正確顯示。

那麼，有沒有方法可以簡化呢？我一開始所想到的是：CSS Font Module Level 3裡頭Generic Family的說明將楷體放到了Serif之中，但在定義上，Cursive更合適，規範裡寫著：

...the result looks more like handwritten pen or brush writing than printed letterwork.

當然，楷體與其說是印刷字，不如說是書法字，符合這項定義。

如果楷體能移到Cursive，那麼製作電子書時只要指定：

font-family: cursive;

問題就解決了。（當然，行書、草書也屬於Cursive，不過一般作業系統中只有楷體。）

會議上的處理

去年會議時寫的信，經過了整整一年，兩天前終於反映到規格上。不過只是從Serif家族中刪除了Kai，並未加到Serif中。今天會議上John身在日本，透過電話會議參加討論時表示：他覺得各種語言的Generic Family要如何選擇，不應該在CSS Font Module中處理，應該以其他的方式選擇。所以僅刪除不適當的陳述而已。

我當然希望能將楷體作為Cursive的範例之一，供瀏覽器開發商作為參考。但要是編輯不願意，也無可奈何。

不過我並不覺得公平。最新編輯草稿上有著「日文傳統字型」、「

字型細節的設定

」等Properties，這些能利用OpenType字體特性做到細微調整的部分都相當好，不過從範例來看，我倒覺得在Mozilla Japan工作的John Daggett，過於偏向日文需求，甚至到了Over-spec的程度；而完全不想添加Generic Family範例，明顯是偏心。

也有與會CSS WG的成員問：「不在這裡處理，那要去哪兒？」

下一步怎麼做？

沒有捷徑，那麼就要從作業系統、瀏覽器、電子書閱讀系統三方面著手：

・電子書閱讀系統：

應該是最簡單的部分，各家閱讀程式如果都能實作出「cursive = 楷體」的話，那麼至少在EPUB製作上就能夠以簡單的語法達到互通。

・瀏覽器：

目前應該會由國際化小組（i18n）整理更多語文的排版需求，列出推薦的字體列表給瀏覽器開發商作為標準字型；這會與中文排版需求並行。詳細會在週四的會議上討論。

另外，目前能自行定義字體的瀏覽器，幾乎都只能設定Serif、Sans-serif、Monospce這三種Generic Family，若能增加Cursive（甚至Fantasy），也能透過使用者自行設定，做到最佳化的呈現。

・作業系統

或者透過作業系統層級來設定，目前我的測試如下：

Windows 8.1：不為Cursive設定中文字型（英文為Comic Sans）。

OS X 10.10：使用內建的楷體，但強制轉斜。

iOS：沒有系統楷體字型，App內可另外從Apple下載，但也會被強制轉斜。

Android：只有Droid Sans Fallback一套黑體可用。

目前比較有希望的是Apple能夠接受Bug回報，不強制把Cursive轉斜，或者可利用font-style: normal;或者font-synthesis: none;來調整。

總之，要做的事情還有很多。

最後：為什麼數位時代還要楷體？

如同前面所述，最簡單的就是希望使用Web技術的EPUB電子書，也能如印刷書一般使用楷體。瀏覽器能夠支援，則是在電子書逐漸往Web前進時，也能夠無縫接軌。像是剛發表的EPUBWEB計畫。

也許大家會覺得：現在網站從標題到內文到廣告等所有文字都使用黑體，連明體都很少用了，怎麼還會需要楷體呢？

我覺得有許多原因：過去因為文字複雜性與螢幕解析度、文字數量造成字體成本高、檔案大、字型與Render技術不好、行動裝置缺乏系統字型（例如iOS與Android）等等問題，一直不能做到很好的呈現。經過了這麼多年，大家也都習慣了。但現在這些技術全都到位，我們真的要把自己的語言習慣通通拋開嗎？或者可以來做些排版的實驗，看看楷體、明/宋體的表現如何。

總之，還有好幾年的路要走，孤掌難鳴，一人路難行，也希望各位能多多協助。

補充：仿宋的指定方式

仿宋又是另外一個問題。仿宋體在日本稱為宋朝體，之前日本排版界曾經爭論過：「明朝體的"italic"該如何呈現？」

漢字天生沒有斜體，而italic在字義上是「如同手寫」。那麼保持更多書寫特徵、但依然是印刷字的仿宋體/宋朝體，就該作為明/宋體/明朝體的italic。CSS語法像這樣：

@font-face { font-family: Chinese; src: url(song.woff); } @font-face { font-family: Chinese; src: url(fang-song.woff); font-style: italic; }

就能組合出「明/宋體的italic是仿宋體」的呈現了。不過，你必須想辦法以WOFF、下載、預載等方式提供仿宋體給使用者才行。

2022年11月追記：

後來CSS技術推進，在CSS Fonts Module Level 4中開放新增Generic Family，包括中文仿宋＝Fangsong。那麼楷體就不需要放在Cursive下頭，也能提出新的值“Kai”來對應楷體。

之前Apple Safari, Google Chrome, Mozilla Firefox等瀏覽器都支援把Cursive對應到系統的楷體上（測試用網頁）。但由於Fonts Level 4的編輯也是Safari字型技術的負責人，就先移除了Safari的對應。

針對這項Generic Family的擴增，W3C國際化小組也發表了Font styles & font fallback來搜集各種所需的字體種類。

[wanderertw]

寫在募款成功之後

感謝41位朋友與台灣數位出版聯盟的協助，募款於今日達到目標，實際收入與支出可透過Google文件確認。有四位朋友以匯款方式贊助，文件上我以匯款時間紀錄，希望能告訴我貴姓大名，以便日後答謝。

募款時陸陸續續接到一些詢問，我在這裡以問答的方式回答，希望能夠解決大家的疑惑。

一、這件事不應該由政府出面來做嗎？

的確，政府應該出面。但台灣在國際標準化上也有其困境，例如最重要的ISO/IEC，台灣由於不是會員國，僅能參加ISO/IEC JTC1 SC2 WG2 IRG的會議，也就是Unicode中漢字的研議小組，網路上可以找到歷年參與者的與會報告。

所以，台灣在國際標準化上，僅能參與開放性組織的活動。像是制定EPUB的IDPF、還有之前WiMax聯盟等。但在實際執行上，並非由政府組織長期實際參加，而是依目的與需求，由半官方組織，如中研院、工研院、資策會代表參與。往往計畫結束後，缺乏經費之下，就停止活動。

二、其他國家政府的參與狀況如何？

一般而言，國際標準化對於開發中國家來說，會以政府參與居多；但絕大部份是相關領域利益團體為主，像是企業體或者學術單位。例如W3C的數位出版興趣小組，就有幾位印度政府的成員。

而我也每次在參與的會議上遇到日本總務省的官員，因為日本總務省除如台灣內政部的職責外，也掌管通訊與資訊技術。他們雖然參與，但不直接指導運作，而是將各企業的實際參與狀況匯報給政府。

三、過往台灣委託半官方組織的參與如何？

結論上來說：有參與，但沒有延續。

例如資策會曾經在EPUB 3.0格式制定時，相當積極地參與了電話會議與F2F的會議，在IDPF的討論區也能找到一些過去的簡報。但這些參與都是在專案經費下執行，一旦結束，就停止活動。往往無法確保需求能夠被實際執行。甚至人員也在結束後離開。

在經驗無法累積之下，也造成一些問題沒有被解決，例如：

注音符號「ㄧ」的問題；

注音在Web與EPUB上實作的問題。

2的部分再做些解釋，資策會曾相當用心地向IDPF提出中文注音的需求。不過IDPF主要權責在於EPUB包裝與導覽等規格上的制定，實際CSS的實作，應該著力於W3C，但這需要長期的追蹤與跟進。例如要把注音放在橫排文字右邊的ruby-position: inter-character就花了12年才真正被實作出來。

甚至不需要非常積極，而是這些組織的專家遇到中文問題時，至少讓他們能夠找得到人提供必要的資訊。但沒有延續，就連人都找不到。

四、我們的企業都不參與嗎？

也不見得，例如IDPF就有許多來自台灣的會員，他們都��投票權以及參與技術討論的權利。（也傳言，當年要接受政府數位出版的補助，就必須加入會員）

但重要的是實質參與，而實質參與建構在實作上。當EPUB 3被制定出來時，會員無論出版社或者技術商或者販賣端，要是沒有跟進技術演進，就沒辦法繼續參與後面的發展。以至於名存實亡，難以看到實際的作為。

又或許，我們的企業沒有大到需要從標準化上獲取利益的需求。例如我在TPAC 2013深圳會議上，看到Panasonic、三星、Sony等電視製造商，很積極地在Web and TV興趣小組上討論。畢竟誰先掌握標準化，誰就能先做出符合標準的產品。

我不清楚在其他領域台灣企業的表現如何，但在數位出版部分，至少我沒遇到來自台灣的其他參與者。若大膽一點揣測，台灣或許在代工環境下對於標準化的敏感度不足，認為規格定出來後跟隨就好。這樣的心態或許也是原因之一。

許多業界成員也在這次募款中表示支持，像是PUBU的蔡競賢博士、前貓頭鷹出版社社長老貓等人。深表感謝。

五、那麼相關的公協會呢？

跨領域的技術門檻也是個問題，要出版商直接進入技術的討論，或許有點困難。我所知道日本電子出版協會JEPA，就做了中間的角色。由協會內部的成員先互相討論，找出需要提交到IDPF、W3C的需求，再由JEPA聘請專業顧問代表，目前IDPF進階與混合版面規範的主席村田真，就是JEPA的技術顧問。

台灣電子書相關的公協會有台灣數位出版聯盟、台灣數位出版聯盟協會、台灣電子書協會、電子閱讀產業推動聯盟等，但是卻無法做到如JEPA一般的功能。在這兩年的活動中，我僅受到台灣數位出版聯盟的資助，但就實際所需要的經費來說，相對少到可憐。而若要說長期延續，又回到了第三點的問題上：就算和政府取得經費，也僅到專案結束為主。甚至可以說大部份的經費並未用到真正的活動上頭。

為了達到真正的專款專用與長期延續，我覺得還是不要依賴台灣的公協會比較好一點。（但還是感謝台灣數位出版聯盟這次贊助二萬元）

六、那麼，你憑什麼參與？又憑什麼募款？

這應該絕大部份看到募款資訊後會產生的疑問。

就對中文排版而言，我不是老資格的編輯；就技術上來說，我也沒有PhD、MS的學位背景；以參與國際標準化組織來說，我更是個新手。

回到實際狀況，光是找到既懂技術、又懂編輯的人就不簡單了，而參與國際標準化，了解作業流程與討論的脈絡，更是需要長時間的累積。我不認為我很行，但是在台灣也只有我在做這件事情。

我也很希望目前是W3C會員的中研院與工研院能夠請專家長期地參與，這件事情落在我一個創業剛兩年、甚至付不起W3C會員費用的小公司上，實在過於繁重。但在他們願意出面之前，我也只能盡量參加、協助處理這件事。

這一兩年間，IDPF與W3C兩個組織的距離越來越近，出版與Web技術的交雜越來越快速且頻繁。如果在這迅速的變革��沒有人參與，我覺得對於語言與產業來說，失去的機會將會相當大。

如果有任何人希望做這件事，我會盡可能地把參與的方法、相關的人脈關係等一併提供出來。當然我也不會因而退出，參與者越多越好。

七、為什麼不透過FlyingV等線上募資服務募款？

「是否要對大眾募資？」這件事讓我掙扎了很久。

前面說了這麼多，政府、半官方組織、企業、公協會的確有要做這件事情的義務，但在這一年下來，我認識到期盼這些組織是不行的，但這成本也不應該轉嫁給大眾。

後來萌典的唐鳳做出了注音符號Ruby標注器，加上老貓推了一把，我才決定公開向大家募款。

這時透過線上募資服務已經遲了些，且我認為8%的手續費過高，另這件事無法在短時間內做出確實的回饋，我才決定僅透過部落格的文章募款。能在時間內達到這成果，非常感謝各位的支持。另，Paypal手續費佔全體募款的2.27%。

八、募款將如何使用？

其實已經花完了，包括機票、住宿費用與註冊費用，實際支出如下：

餘款7,237元將用在其他W3C的Workshop，或者明年於札幌舉辦的W3C TPAC會議上。

九、後續能做些什麼？

在EPUB與Web等數位出版的領域，會需要這些方面的意見：

出版社：提出目前EPUB 3電子書排版上遇到的問題。

電子書商：提出目前基於瀏覽器組版引擎閱讀系統表現的限制。

排版工作者：提供中文書排版所使用的規則。

Web設計者：實踐更好的排版，提出技術上的限制與需求。

若沒有實踐，就沒有問題與需求。而第一線的實踐者，提供的意見最有力。

感謝各位的支持，明年我還會繼續在這領域堅持下去。

[wanderertw]

如果你在乎中文

這是一封募款信，我希望能在下個月前往美國加州Santa Clara參加W3C的年度技術與專家大會TPAC 2014，以及前一週由Internet Archive所舉辦的「Books in Browsers」研討會。這兩個會議對於中文排版實踐在EPUB與Web（網頁）上，以及未來電子書的發展走向來說，相當重要。

讓我先做一段簡單的說明。

EPUB與Web發展的說明

各位都知道EPUB 3格式由IDPF在2010年制定完成。不過，EPUB 3是一個由上到下（Top-down）的技術標準，並非由下到上（Bottom-up）的格式。這也以至於有許多規範無法馬上實現。其中，內容就是一個很大的問題。

EPUB 3的內容採用HTML 5與CSS 3呈現，就是所謂的Web技術。但Web技術主要是由W3C（WorldwideWeb Consortium）所制定、推動。就不在IDPF的權責範圍內。

因為這樣子的分層關係，所以兩方也開始了緊密的合作關係。一開始，2013年在紐約、東京、巴黎三地舉行電子書工作坊，蒐集電子書與數位出版所需的Web技術需求。同時成立了數位出版興趣小組（Digital Publishing Interest Group）積極制定各種數位出版的相關規範。

可以這麼說：

IDPF負責EPUB格式電子書的結構、導覽等； W3C負責EPUB/Web上的文字與各種呈現所需的技術。

接著談一下去年一年，做出了些什麼成績。

2013年的參與與推動

目前，中文在Web與EPUB電子書上的呈現，看似問題不大。但在細節上，還有著：

字體選擇：如何更有效的選擇文中楷體的呈現；

對齊：文字與段落對齊的Justification處理；

注音符號：如何更有效地標注、呈現注音符號。

等等，其中注音符號長久以來從未被實踐。無論在教育應用與童書上，都有相當的需求。我在去年做了一些事情。

首先，在六月前往東京參加了電子書工作坊，提出注音符號的排版需求。

其次，在十一月前往深圳參加W3C TPAC，參加數位出版興趣小組以及CSS工作小組的討論，提出一些建議，並且認識了一些實作上的關鍵人物。

但如果以追著議題的方式進行，並不是個好方法。所以在去年起草了「中文繁體字排版需求（Requirement for Tradition Chinese Layout）」。不過畢竟不是W3C會員，所以也無法進一步送進去成為正式文件。所以由W3C的Host學校北京航空航太大學接手，希望加入簡體字的內容，成為正式的參考文件「中文排版需求」，今年��月北航也開了工作坊討論進一步該如何處理。

去TPAC與BiB的原因

第一點，是希望能夠後續跟進這份文書的進度。

去年雖然TPAC少見地離開歐美，在深圳舉辦，但是台灣的參與人數並不多，一共六人。其中有一個團體還是為了瞭解W3C在做些什麼才去。今年辦在Santa Clara，應該參與人數會更少。而我希望在數位出版與CSS小組會議時，當遇到中文議題時表達意見。也可以說，確保在中文上的話語權。

第二點，是推進實作。

在TPAC上，除了規範制定的參與者外，也會有實作的瀏覽器開發者參與。如果能夠立即處理實作上遇到的問題，將有可能加速規範的實作。例如注音符號有一個重要的值ruby-position: inter-character，能夠讓注音在文字橫排時標注在漢字的右側，並且不會因為斷行而分離。從規範制定到現在十幾年的時間裡，從未被實作出來。不過前幾天，最新的Webkit Nightly Build裡首次實作。呈現約如這樣：

rubyposition from Bobby Tung on Vimeo.

我不敢將功能攬到自己身上，但是透過參與，的確能夠有效推動實作。

第三點，是了解前沿趨勢。

無論是數位出版興趣小組的討論，或者Books in Browsers會議，都會指出具體數位出版在未來發展的技術趨勢。而這次Books in Bowsers也會有W3C與IDPF代表的聯名出席，我希望能夠追蹤技術層面上的發展。

預算需求

Books in Browsers研討會將於十月23至24日在舊金山市區舉行，而W3C TPAC將於隔週十月27-31日於聖塔克拉拉Marriott飯店舉行，合計於十月22日起，至十月31日，共十天行程，預算需求如下表：

10/3：已收到40位個人與台灣數位出版聯盟之贊助，達到募款目標。之後將會透過Paypal與郵件寄出收款收據與感謝函，謝謝各位的支持。

[wanderertw]

一件小事：注音「ㄧ」到底要直要橫？

去年我在W3C、IDPF活動時，認識了一位叫做石井宏治的日本朋友。他不僅是W3C CSS WG中多份標準的編輯，也參與Unicode Consortium的活動。可以說是「出版界—電子書技術界—國際標準組織」中，最後一段實際工作的關鍵人員。

他正在編寫Unicode Consortium一份技術文件「UTR#50 Unicode Vertical Text Layout」，這份文件對於文字直排的語言（日文、繁體中文）來說非常重要。Unicode中每個字碼都只能有一個編碼（Codepoint），以接下來會提到的注音符號「ㄧ」來說，編碼就是U+3127，Unicode不會讓相同一個字擁有兩個字碼。

但是當文字直排時，許多符號都需要隨之旋轉，簡單一點的，如引號、括號，直接旋轉90度。

也會遇到一些複雜的狀況，例如日文裡的單位、年號，直排時根本是不同的字形（Glyph），

在Unicode規則之下，就需要這樣一份文件來整理資訊，提供給字型公司、排版相關的瀏覽器、軟體開發者參考，如何才能達到理想的文字排版。

七月中我收到了石井來信，他詢問注音符號「ㄧ」的使用方式。到底在怎麼樣的狀況下是直線、怎麼樣的狀況下是橫線。依照教育部在民國八十九年出版的《國語注音符號手冊》中，記載如下：

也就是說，橫排時應該是「｜」，直排應該是「ㄧ」。而Unicode字碼表收錄的是橫排時的字形，所以也是「｜」。（也請注意，在Unicode中收錄的注音符號來自GB2312標準。）

但是，教育部在這本手冊的線上版補充說明中，有這麼一段描述：

本手冊據民國24年所公布之「國字旁注之注音符號印刷體式表」重新設計製作，所訂韻符「ㄧ」直式注音寫成「ㄧ」，橫式注音寫成「｜」。惟時空環境變遷，考量目前多數電腦環境，要輸入直的「｜」較為困難，且為便於資訊交換、流通、辨認及使用習慣等因素，於民國97年相關諮詢會議結論，橫式注音時以寫成「ㄧ」為原則，亦可寫成「｜」。

這麼一來，改變就大了。也就是說無論直排或者橫排，U+3127都應該是「ㄧ」，而不是「｜」，「｜」僅作為橫排時的另一種寫法。那麼在Unicode字碼表中，這個字元也需要修改。

和石井先生說明後，正好八月初Unicode Technical Committee要開會，這個狀況就成了正式提案。（由Ken Lunde提出，他有個日文名字叫小林劍。）我和教育部提出公文咨詢後，得到了正式回應，後來獲得UTC的正式接納。有蠻大的機會，在下一版本的Unicode中，U+3127會修改為符合使用習慣的「ㄧ」，而不是「｜」。

感謝教育部終身教育司楊小姐的協助，處理了這一項「小事」。

再來多提一下Unicode以及台灣的參與。

最早，Unicode Consortium是由業界所組織，希望提出容納所有語言文字的Unicode編碼。Unicode Consortium你可以當作一個國際級的公協會，任何企業體、個人、政府組織都能夠加入。但當Unicode製定後，Unicode Consortium將其提交到ISO/IEC成為ISO標準（ISO 10646）後，就由ISO/IEC JTC1/SC2負責管理，由於中華民國很早就退出ISO/IEC，所以既沒有會員權，也無法參與。唯一與Unicode相關的接觸，是在ISO/IEC JTC1/SC2/WG2下的IRG（Ideographic characters Rapporteur Group）以臺北電腦工會的身份參與。IRG直到現在還在運作中，每年都會處理新增的漢字提案與研議，所以漢字到現在還有著Ext-E、Ext-F的擴增。

和楊小姐電話聯絡時得知，教育部不會參與國際標準的討論，而是由經濟部標準檢驗局為主，在文字標準上頭，又是以現在已經並入國發會的研考會負責。過往在IRG中也曾提出注音「ㄧ」的問題，不過當時要求「｜」另外給予編碼，不符合Unicode規則而未能成案。

這是一件小事，但在處理時我會這麼想：如果我不認識石井宏治，如果他不來問我注音的問題，這件事會不會遙遙無期？然後許多的作業系統為了符合Unicode標準，紛紛把「ㄧ」造成「｜」（例如在Windows 8.1下，輸入時的注音就是直的。）而有種我們離國際真的蠻遠的實感。

題外話，教育部公文裡這份民國24年的注音文獻相當珍貴，和大家分享：

[wanderertw]

為什麼Sigil不再適合用來製作EPUB？

月初，在EPUB編輯器Sigil的部落格上，出現了一篇名為「Sigil's Spiritual Successor（Sigil的精神後繼者）」的文章。其中提到幾個重點：

Sigil在去年將開發平台從Google Code移到Github後，開發依然遲緩。

Calibre的開發者Kovid，希望從Sigil出發，將編輯功能納入其中。

現在的使用者還是可以繼續用，要是未來不堪使用，可以考慮轉換到Calibre。

於EPUB開始推廣的那幾年，Sigil的確是獨一不二的便利編輯工具。甚至資策會也推出了中文版，作為推薦的工具。

然而，Sigil不是商用軟體，而是一個開放原始碼計劃。雖然人人都可以為其增添功能，讓它發展下去，但要是貢獻者少，或者架構不合時宜，開放原始碼計劃也會停滯，甚至停止開發。

Sigil最初是由Strahinja Marković所開發，但是當大家發現這個工具極為方便之後，各種功能建議與要求語言支援的信件紛紛寄到他信箱裡，但畢竟這是個開放原始碼計劃，並非商用軟體，所以Strahinja無法完全對應這些需求，後來他放下開發，去了Google工作。後來由John Schember接手，但他並沒有想要自己下去主導開發，而是擔任專案管理的角色。隨著其他各種工具的成熟，Sigil的進展也停滯了下來。

更重要的是，在這段時間裡，EPUB 3規格逐漸取代EPUB 2，停滯的Sigil顯得不合時宜。另外對於西文以外語言的使用者來說，Sigil、Calibre這些工具，也難以符合自己文字排版的呈現需求。

所以，對於台灣繁體中文電子書來說，Sigil不再是一款適宜的工具。儘管容易使用，但做出來的書卻需要額外的人力調整，不然無法通過各種主流電子書店的品質檢查。提供的「方便」，反而會造成「欲速而不達」的結果。

・放大的粗體，你認得出是標題，但是機器只認得「放大的粗體」

數位內容必須要兼顧「人讀」與「機讀」，直到現在，許多人使用Word等WYSIWYG工具時，會把標題字級放大、加粗、更換字型，覺得這樣就是「標題」。但對於電腦而言，只會認得字級、字型與粗體的變化，而認不出那是標題。

但在WYSIWYM工具的思維中，你想指定標題，就利用記述方法，例如Markdown就是「#、##、###⋯⋯」，HTML就是「<h1>、<h2>、<h3>⋯⋯」，你知道那是標題，機器也知道那是標題；至於想要如何呈現，就留到樣式（CSS）去指定。

・你看到的完美版面，在別人機器上變了個樣

WYSIWYG工具還有個問題，就像是你在WORD中指定各種字體，但把DOC/X檔案寄給別人時，卻完全換了個樣。這種狀況，電子書與網頁編輯時更容易出現。一本電子書，人們可能在Windows上閱讀、可能在iOS與OS X的iBooks上閱讀，可能在電子紙閱讀器上讀⋯⋯這些不同的環境，幾乎無法讓你的設計忠實呈現。WYSIWYG工具容易給你一切都搞定了的假象。

WYSIWYM工具則能去除這些假象，回歸到基礎，讓你專注在內容製作上頭。當然，保持設計一致還是相當重要，但就像是網頁設計需要交給專業的來一樣，電子書設計也有其專業（例如我們）。或者你可以自學累積專業。

・連打空白鍵做縮排、兩下Enter分段落

WYSIWIG工具是在十幾二十年前，提供人們從類比轉數位時易於學習的工具。但同時也造成了不少正確的觀念因為工具的方便而被放在一邊。例如到了今天，還是很多人把Word當作打字機在用。例如段首縮排二字，不少人還是連按空白鍵（甚至不是兩個全形空白），而非使用段首縮排設定。另外，當希望段落間空一行時，應該要使用段落間距來處理，不過常見的是兩下Enter解決。

這些WYSIWIG裏頭可以容許的不良習慣，在WYSIWIM工具裡會被凸顯出來，你必須改��才行。當然，要是大家都不願意改變，那我們也不用談什麼創新或者進步了。

所以，我會建議大家不要再以Sigil作為EPUB的製作工具。雖然一時之間沒有完整的取代方案，但Markdown與電電轉換器是讓你學會正確概念的方便幫手。

不過就像Sigil雖然緩慢，但卻沒有正式放棄開發一樣。如果你覺得我們依然需要那樣的工具，你可以找到開發者，對Sigil、Calibre等專案作出貢獻，讓它們支援EPUB 3、中文書的製作。

在那之前，這些工具是利弊相伴，請多加考量。

＊若你需要把電子書轉成Kindle用的Mobi檔案，請愛用Amazon官方的Kindle Previewer，得到的成果會比Calibre好上許多。