法蘭克福書展後，公司似乎不那麼忙亂，但我的心態卻有了變化。

先別急著吐槽：「你也放棄得太快了吧？」或是「就知道會這樣。」

並不覺得對不起這份工作，雖然沒有忙到像天天 hackathon ，但在台北的日子，能不被打擾想著公事。這也是來之前的初衷，要像桐山零（或按訪談的說法，就是作者羽海野チカ本人）看齊，不讓自己有藉口抱怨：「要是當時再拼一點就好了。」

喜歡 GitHub 這種看得到 source ，東西壞掉時找得到 issue 或是 pull request ，對這個問題什麼時候會修，或有沒有人在意有個底。加上在 #g0v.tw 頻道看到的合作模式，讓我對無法存取的檔案庫，或是會影響到自己，但是無法得知的訊息感冒（還不如一開始就不知道），不方便嘗試新想法。

說到新想法，之前太拘泥於簡報檔了。看看未來的需求，如果書裡的每個資源，都有獨立的 URI ，就能方便地紀錄讀者可以使用那些資源。網頁版的閱讀器與其試著去解析 EPUB 或其他私有格式，不如從 API 取得資源，把書組出來。

那時才有空實驗這個想法？該撥空用 Apiary 先做？反正工具都在，沒道理不用。行不行得通，做過才知道。

十一月底又有另外一條死線（The American Council on the Teaching of Foreign Languages, ACTFL），當然希望可以快點完成更多書，這幾天一直在整理做到一半的工具。

才知道許多細節妳在兩個月前幾乎都做過了！要不是有這些 code 可以參考，真不知自己得走多少彎路？

目前的方向是打算在 zip 前，把資料都複製到個別資料夾，再產生頁面跟打包用的 metadata 。沒用 make 是因為不熟悉除了生出額外的檔案外，有沒有更好的溝通方式。沒用 gulp 則是因為 vinyl-fs 有個遇到 symbolic link 會出 EISDIR 的 issue 。修好前，沒法像原來那樣，做 symbolic link 再打包。正在用的 xmlbuilder 很友善，但也許以 jade 提供頁面與 ocf 的 template ，管理起來會更方便。

就算這樣，只是兜出能動的東西而已。我還是不了解該注意什麼，還有它們代表什麼意義。

從 Open Container Format 輾轉找到汪達數位講的故事，發現 Extended Books （又看到 HyperCard ），想起 Accuracy takes power: one man’s 3GHz quest to build a perfect SNES emulator ，為了完美模擬超任，得花那麼多工夫，還好 EPUB 是個開放的標準。

但我有好好利用這個標準嗎？ HTML5 可以做的事情太多，我忽略了早已存在的 SMIL 技術。到今天才知道閱讀器正嘗試支援它，還內建了個可愛的按鈕，又能自動翻頁。知道得少，想像力也被侷限，除了靠 React 呈現 VTT ，我還可以有不同選擇 XD