epub中的NCX

完成了一個小小reader程式可以讀epub格式的電子書籍，現在要開始處理Table Of Content。
ODPF用既存的DTB(Digital Talking Book)的規範來處理TOC(spec第八章)，該SPEC中特地要求依SPINE順序來展現電子書內容，但在NCX中，卻又有playorder，「It provides a means to collate all PageTargets, navTargets, and navPoints into a single ordered sequence that reflects their order in the normal playback sequence of the book as presented in the spine and SMIL files.」，playorder的定義似乎與spine的功能相衝突。若相同則重覆定義，若不同則會是大災難。為何要這樣處理，背後一定有理由，只是這理由還沒看到。
或許是因為DTB的spec與epub沒有直接關連，所以各自找了方式處理章節順序的問題，但若重覆且error prone，實在應該廢除playorder。

第一版的epub reader之後

已經完成一個小小的epub reader，用的是：
1.libxml for the front end to read all epub related XML files for parsing, to get to the content the reader wants to show
2.webkit/GTK+ for the back end, after get the xhtml files to be layout, use webkit/GTK+ to layout the content
未來需要做很多很多的工作：
1.front end
a.error checking (required by epub spec)
b.metadata
c.DRM (under epub spec)
d.signature and others
2.back end
a.show pages in one xhtml(based on the size of the device? or physical size defined by doc?)
b.中文
c.直行書
最後當然是user interface(experience)的部份
最先要解決的問題是，如何將壓縮的.epub(用zip壓縮)建構其電子書籍的架構，我想用file roller的招數，利用tmp dir來隱瞞細節。

webkit/gtk+ thread system not initiated bug

討厭的是，Webkit/Gtk+用Glib這裡的bug沒有fix。
唯一的workaround是在每一個Webkit/Gtk+程式都加上這一行：
g_thread_init (NULL);
強迫將thread啟動，如此可以避免前述的bug.
找到這個workaround也花了很多時間...

webkit & gnome

討厭的是，webkit 1.15.4版本竟然需要 gnome 2.28以上的版本，該版本是2009年12月才release，我用的debian stable版當然還沒用這一版本的gnome，要花一些時間弄清楚如何安裝gnome 2.28。
這一部份一定要記住，因為未來為了mobile device去port webkit時，也會被這樣的問題困住...

layout engine

評估可以用什麼layout engine.因為想在未來使用clutter，來處理animation，可以有很fancy的使用者界面。加上clutter是唯一系統化的處理在Linux上的'touch & signature'的工具，應該是未來mobile device使用者介面有機會成為king的工具。所以一開始就鎖定clutter+openGL+GTK+。
最初考慮用 gtkhtml來layout xhtml的內容，但survey了一陣子才發現gtkhtml已經phase out了，被webkit所取代，原本不想用webkit，主要是因為webkit最早是由apple提供，是用object-c所撰寫，但在評估了其他的layout engine後，看來沒什麼選擇。
開始讀object-c的manual，開始嘗試build webkit from scratch。再慢慢了解layout engine的細節...
webkit是android採用的mobile browser，也是iPhone採用的mobile browser，應該要花一點時間弄清楚，也會是在為自己的技術能量做累積。

libxml中的relaxNG validation

正嘗試了解libxml中處理relaxNG的validaion部份。若這個部份可以好好利用，應該可以達成之前所想像的，基於relaxNG的文法，generate出一個parser供程式用來parse相對應的xml檔。在電子書的例子中，就是給幾個epub的relaxNG檔，然後能產生幾個相對應的parser，被reader用來讀取/validate電子書籍的正確性。
libxml中的relaxNG validation是透過API: xmlTextReaderRelaxNGValidate(reader, rng)來呼叫。reader則是透過 API:xmlReaderForFile(xmlfilename, encoding ,parse options)來建立，reader是一個xmlTextReader的data structure，defined in xmlreader.c中。
看來是先將rng轉成一個內部的struct，再以這個struct來parse xml檔。還要再看看。

relaxNG

總算想清楚了。
relaxNG就像是yacc中的文法(grammar)，我應該寫個小程式，將讀入的relaxNG產生一個.c檔,這個.c檔將像是一個state-machine,順著relaxNG所定義的文法來parse新讀入的檔案，確定該檔案有無follow relaxNG所定義的文法。至於若符合時應該做什麼動作，屬於meta層級的事，再透過在relaxNG文法中的特別格式，可能可以參考relaxNGCC的作法,用的方法加在.c檔中。
希望這種模式會成功。
有趣的是，將文法轉成.c檔，及.c檔中處理讀入的xml檔，都將使用libxml，meta-language及language層次都預設了libxml，寫來應該會好玩。
這個讀relaxNG產生.c檔的程式，寫完應該可以opensource出去，讓更多對xml grammar（如relaxNG)的無力可以被改變。否則每次都是先對讀入的XML檔，先走過一次tree後check整株tree是否合於文法，再開始重頭走一次tree，在對的地方做一些對的事，這種重覆walk-tree的作法真令人生厭。希望前述的作法可以讓整個xml parsing有效率...