自從上次 iBook 螢幕顯示壞掉之後，螢幕就是花花綠綠一片。於是就拆掉螢幕，接上大的寬螢幕使用。這樣用起來還蠻有一番趣味，因為 iBook 放在外接螢幕前，就好像只是鍵盤一樣，不會有 LCD panel 擋住外接螢幕視線。但是缺點就是，本來 portable 就變成不 portable。前幾個禮拜看到有人在賣 iBook 零件，剛好有上蓋那部份整個 LCD panel，而且不貴加上運費才不到 2.5k。於是就敗了回來，但是拆 iBook 實在也是一件浩大工程，所以遲了幾天後才正式開工。經過一陣子 iBook 解剖之後，終於把螢幕給裝回去。順便把 Hitachi 的硬碟拆下來接到 PC，用 feature tool 把調整 acoustic level 為 quiet seek mode。因為說實在的，從以前新硬碟裝上去之後，都覺得三不五時常常會有「框搭」的聲音，尤其夜深人靜時候更是明顯。而 feature tool 又只能在 PC 上跑，所以趁這個機會挖出硬碟來改。又一陣兵荒馬亂之後，把整台 iBook 完全組裝完畢。於是 iBook 又有自己的「頭」了，不過，嗯，怎麼每拆一次 iBook 就莫名其妙生出一些小螺絲，記得明明都有鎖到 XD。
ps: 先前順便把壞掉的螢幕拆掉，原來裡面用的是 LG Philips 的面板。

基本上因為有些 code 是牽涉到 platform/machine dependency，所以在沒有 x86 機器情況下，我沒辦法去測試，所以就不包這部份的 binary。那功能上的部份就不探討這些方面。
那下一個 stage 是什麼，比較簡單的就是改掉簡繁轉換的某些字元衝突。像是簡體字"只"對應到正體可能也會有“隻“，"斗"或許是對應到"鬥"，但是只和斗也是正體常用的字，把他們任意轉換之後，正體文就怪了。另外一招就是學中文 wikipedia，建一堆辭彙轉換。不過當然就是增加一堆 trade off。試想，在內部都用 unicode 表示下，簡繁字體都可以並存，drawing 時候全部丟去辭彙 search/replace，應該不是一個好方法。目前只是單一個字元，並且用 GNU perfect hash 產生出來的表格，至少快很多。那為什麼不直接把儲存的 unicode 內容本質上就改成正體編碼。我想還是不要任意去更動使用者內部儲存的資料比較好，因為目的和用途不知道情況下，這樣可能會破壞使用者在網頁上的輸入和 submit 資料。
另外一個部份，是想實作類似 Firefox 上使用 google toolbar 的 translation 其中一個功能，在滑鼠游標下的英文字彙，可以有類似 Dr.eye 的翻譯效果。這對看英文網頁幫助不少(汗)，因為 firefox 的肥大和速度讓我不喜歡在 Mac OS X 下使用，所以有這樣的東西相對就拉近兩者所需功能的距離。如果你有打開 Universal Access 的話，在 Safari 裡面滑鼠移動到某個英文字，然後按下 Ctrl-Cmd-D，就可以直接在內建的 Dictionary 裡面查到英英解釋。這就是透過 Apple Accessibility API 所得到的效果，當然 WebKit 裡面也是有支援 Accessibility API 才有辦法。但是研究了很久 Apple Accessibility API，以及 WebKit 裡面的支援（這部份都還沒 document）。還是沒有辦法只取到單一個英文字，頂多只有整段片段。另外一個方法就是反組譯 Dictionary.app 去看他怎麼抓這部份單字，當然這也是一個苦差事，因為反組譯和他使用的 API 方式都很難懂。所以有對 Accessibility API 有經驗的朋友，希望能夠得到一些分享經驗或知識，就像隔行如隔山，搞不好點破就一切通了XD。