The Old Blog Archive (Traditional Chinese), 2004-2009

Archive for the 'tekhnologia 技術或者藝術' Category

上週六在 OSDC.tw 2008 的投影片

投影片在這裡

OSDC.tw 的邀請,上週六下午給了一個題目為「開放原始碼、開放資料與日常生活的語言應用」(Open Source, Open Data in Everyday Handling of Natural Languages)的分享。題目有點長,內容也有點雜。主要的企圖還是在區分日常生活語言問題的種類,以及圍繞在中文的核心問題──斷字──上面。

「問題意識」(problems)上,日常生活的語言問題,主要還是在怎麼將之編目索引檢索。除非你的應用程式本身就是語言應用(language-specific applications)。這個部分有一些地方跟 l10n/m17n/i18n 有重疊處,但這並不是同樣的兩件事。另外一個我試圖(但沒有很成功)想要講述的方向是,我們這些講中文的人應該試圖去處理中文以外的語言,切莫認為我們只需要處理中文就好(而且事實上中文也並非是如我們被教育成的,是一種均質的語言,「中文」本身諸元的差異或許就和中文與其他語言的差異一樣地多)。

在「方法論」(methods)的段落,我簡短介紹了兩種「正規」的方法,基於觀察中文構詞型態的MMSEG以及基於language model的方法。事實上相關的研究很多,implement說來比較偏工程問題。(中文自動選字)輸入法的問題其實只是其中的一種變體,把輸出改成音素,輸出改成可能的最佳句子就是了(用最化約的方法來說)。

在「工具」一段,所介紹的大多數工具仍是以 Perl 為主。Perl 在語言處理上仍然是最強大的語言之一,也是大多數相關工作的首選。我不熟 Python ,所以用 Python 寫的 NLTK 等工具,就無法多說什麼。Ruby 在這方面很弱。當我說「如果你用 C++ ,那沒有人救得了你」時,沒想到大家竟然反應熱烈地笑了。這句話,出自一個還是必須用 C++ 來解決問題的人嘴裡,其實是很辛酸的呀。

「資料」的問題,還是跟 Hans Rosling 在講公共衛生議題的相關 TED talks 的那句話一樣:資料就都在那邊,可是卻沒有辦法開放出來。

準備這次主題的一個額外的收獲是,我深深感受到日文相關軟體計畫,無論在規劃,募集資料、或者看問題的方法、甚或是 C library header file 的組織上,都有很多可以借鏡的地方。另一方面同樣看到的問題是,編碼的需要現代化(例如 anthy 仍是 Shift JIS-based)、程式語言的需要現代化(需要引進 C++ 來使得語言物件──音節、音素、unigram──等等可以被當做型別來操作)等等挑戰。

總之還有很多很多要努力的地方啊。

Flickr 的 Video Service

Flickr 也有 video 了。

雖然有很多評論者馬上拿來和 Google 的 YouTube 擺在一起比較,我倒是覺得,Flickr Video 跟 YouTube 完全是兩種概念的東西。Flickr 的 90 秒短片,一如 Flickr 員工自己說的,比較像 “moving pictures”。另外 Flickr 的 video 是圍繞在「個人」身上,也就是說那些影片跟作為上傳者的「你」是聯繫在一起的。YouTube,一定程度上,比較像一種脫個人化(de-individualized)的 video depot (影片倉儲)。同時你也很難從後者影片的留言串,跟他人建立關係。反之,Flickr 的 comment 很成功地把人跟人給拉在一起。

另外就是 Flickr 員工自己的社群經營囉。例如這個。很可愛不是嗎?

我主觀的欣賞這個新服務,當然有一些同樣主觀的因素啦。好比說,那一年去東京旅遊時,拿 Cybershot 拍的那些爛爛的 video,也終於找到了合適的地方上架。這種東西我不太可能搬到 YouTube 上。但是放在 Flickr 上卻合適極了。套用《空想科學讀本》的說法,適才適所,這樣不是很好嗎?(誤)

最近的一個機車的心得

QuickSilver 的 source code 有用到 Carbon private API ,竟然可以從 window-server level 把鍵盤事件給遮斷搶過來用!你不知道我在說什麼沒關係,我只是想說,這一陣子我再次體會到那句名言不假:

如果你寫程式沒用undocumented API,
那一定是因為你的程式沒什麼了不起的功能

(註:undocumented API 不見得要是沒見光的,即使是 open source 的 framework 也經常暗藏秘技、邪惡的 higher-order techniques,或者是曲折離奇的 message sending path。有寫過鐵軌快寶裡任何活躍的唱片的外掛的朋友,一定知道我在說什麼。XD)

重新學C++

最近在重新學C++。簡短的感覺是,C++哪裡是什麼物件導向/「面向對象」的語言嘛。C++設計哲學的精采之處,似乎都表現在「沒有使用pointer」的地方。另外就是,傳統C有的程式庫功能,C++幾乎都有一套「符合自身哲學」的作法。從這點來說,等於是跟C斷裂了。

Objective-C就這一點來說,還是跟C貼近些(Objective-C是C的超集合,但C++不是;合法的C不見得是合法的C++)。

不過,兩者哲學天差地遠就是了。倒是C++因為有行內展開(inlining)這種超邪惡的機制,在處理複雜資料結構上,有著可怕的速度優勢。

最近感受到把某些老程式用C++重寫後獲得2x甚至10x速度的爽感──在完全不改動資料結構或演算法的條件下,一切全拜C++的ADT哲學與STL container之賜。

雖然有一種遲來的快適,不過也幸好是現在才改用C++重寫,而不是在它們還用其他語言寫時,就做很多敲敲打打。因為,套用那句經典名言:

Premature optimization is the root of all evil
過早求最佳解乃萬惡根源

PMingLiU時代

修正一句話:Vignelli的地鐵標示是1966年設計的,不是70年代。

記錄片Helvetica的DVD已經公開發售一段時間了。很推薦大家去看這部片。實在覺得在台灣應該要有個放映會的。

我可能比較傾向片中「不認為Helvetica限制了什麼」的那一派。而且即使是Helvetica也還是有時代性的。確實Massimo Vignelli的紐約地鐵標示系統不太容易讓人覺得這是1960年代的東西(據一位朋友說,紐約地鐵以前不是這樣的,以前對路線的稱呼方式和現在色環加字母的系統很不相同,是那種只有紐約客搞得懂的命名法),但是也絕對不會讓人和,好比說,American Apparel聯想在一起。字體仍然是要和它的context一起發生作用的。

有時在想,如果過去五十年有所謂的Helvetica時代這種說法,不知道繁體中文的等義詞會是什麼。

不會是…… 「PMingLiU時代」吧。

PMingLiU,或者說是「細明體」、「新細明體」,大家從Windows 3.1一路看到現在,一共也看了15年以上了吧。總覺得一定程度上這跟Arial有異曲同工之妙。因為Windows的緣故,它背負了所有電腦字體的罪惡。不過,「阿賴羅」好歹還有個理型和範式:那就是被它rip off的Helvetica。細明體呢…… 我們好像沒有那個理型的存在(不會是 stdfont.24 吧 *大誤*)。說來也奇怪,平平是明體/宋體/明朝體,日文字體就有辦法表現出那種一眼即能看出的個性和年份。莫非,這一切都是「風土條件」(terroir)造成的?

(不過,即使在 stdfont.24 的年代,大家拿到倚天,第一件做的事,就是找一套轉換程式,把國喬的 16×15 字型換過去──奇怪,或許那時候反而大家比較在乎這種事?)

倒是幾個月前對我們的「PMingLiU」時代有新的體悟。那就是去WWDC ’07的時候,為了一個繪圖系統的問題,去了他們在會場上設置的lab。幾經輾轉,最後我面前的人是…… 「Quartz主要就是他寫的啦」。「Apple的PDF是跟Adobe買的library還是自己照規格刻的?」「自己照規格刻的,應該說,是我刻的」,的那種等級的人。

談話最末,也許出自沒話找話,我問了個問題,「對了,附帶一提…… 你們能不能解決有一套繁體中文字型在PDF裡會錯亂,但關掉anti-aliasing後會正常的問題?」

「我好像知道你講的是那一套字了,你講的該不就會是……」
「PMingLiU?」
「啊,果然」

那個當下,他的反應,我唯一能想到的,只有這句台語可以形容:khùaⁿ tio̍h kúi。漢字寫作「看著鬼」,也就是一般說的看到鬼啦。

真是有夠「硬名譽」(infamous)的。

不過,我好像也曾經很愛PMingLiU呢,特別是跟另一套電腦字型的罪惡相比,那就是本國偉大政府公文書統一使用的14pt BiauKai(請恕我實在無法直呼其名諱,這種事跟不能直呼佛地魔,只能說the-typeface-whose-name-thou-shalt-not-mention是一樣的道理)。不過,那又是另外的樓層/故事了。

幾年前英國電信出了個服務,是你只要在手機上撥個號碼,然後把手機湊近,好比說,discotheque大聲放送的舞曲,幾秒鐘後就會有簡訊告訴你這是哪首歌、哪裡買得到、要不要買鈴聲一類的。嗯,其實我也好希望有這種服務是,看到喜歡的字型,用手機拍下來,發送MMS,幾秒鐘後就會有簡訊告訴你,這是哪套字 …… 不過,相對於鈴聲一首不到百元台幣,應該是不會有字型立即購這種事的啦……

OpenVanilla 2007年11月18日止的捐款收支明細

我們今天整理完OpenVanilla至昨日(2007年11月18日)為止的捐款收支明細,發佈為一份Google Docs的試算表,並且說明了近期的開發及支用情形。請大家參閱OpenVanilla Group所公佈的文件,謝謝!

.cin的歷史,與Leopard對.cin的支援

Apple在OS X Leopard中加入了對.cin格式的支援。做為輸入法開發者,我想這大概是對open source社群最棒的tribute之一。這個經過歷史考驗(.cin最早是由Xcin創建的格式)、廣為各framework使用、有許多使用者自訂或創建內容的格式,如今也成為了商業作業系統的一環。

根據我所知道的,把.cin放進~/Input Methods/或/Library/Input Methods中,重新登入,就會變出相對應的輸入法。不過要怎麼調整各種選項,我就不是很清楚了。

Yale Chinese Mac的主人Eric Rasmussen在Chinese Mac Google Group起了個頭,想了解 .cin 格式的定義,以及Leopard對 .cin 的支援。我貼了一封回應,也等於整理了我對 .cin 的理解。我對 .cin 在其他 framework 的實作瞭解有限,如有疏漏還要請大家指正了。

滿城盡是封面流 (cover flow)

Xcode 3的Quartz範例中有一個叫CovertFlow的程式,示範如何以CoreAnimation來製作cover flow。程式相當複雜。有人在Cocoa mailing list上問:Apple有沒有Cover Flow的API?

答案是有的──雖然Apple沒有將之公開。Class就叫IKImageFlowView。

如果你會用IKImageBrowserView,那麼幾乎已經完成了把程式cover-flow化的準備。進Interface Builder弄一個class為IKImageFlowView的custom view,然後把data source (IKImageBrowserDataSource protocol)的兩個必備method換成:

  • - (NSUInteger)numberOfItemsInImageFlow:(id)aFlowLayer
  • - (id)imageFlow:(id)aFlowLayer itemAtIndex:(int)index

就可以了。事實上呢,Apple的API還會耍一下小把戲。當你什麼都不做時,console log會丟給你一個exception,說data source沒有實作 “-flowLayer:itemAtIndex:” 這個method,實際上的名字卻是上述的imageFlow:itemAtIndex: 。

於是就做完了,根據傳統,有圖有真相:

Cover Flow Study

範例程式碼可以從CocoaHeads Taipei Group此處取得

OpenVanilla新模組:聯想詞功能(alpha版)

好久沒用 OpenVanilla 開發新功能了。都說 OV 適合開發輸入法相關功能,如果不拿來善用會有點可惜。

所以就寫了這個:OpenVanilla聯想詞模組

這只是開發版,還有點生。抓下來之後,照著裡頭”How to Install”的說明來安裝,然後把兩個名稱奇異的模組都enable,就可以開始用了。任何單字式的輸入法都可以使用(倉頡、簡易、傳統注音、大易、行列… you name it)

Tiger跟Leopard用的OV,都可以安裝。

No picture(s), no truth. 首先是要 enable 兩個名稱怪異的模組:

OpenVanilla Associated Phrase Module

就大功告成了:

Example of Associated Phrase Module in Action

裡面的詞庫是從酷音詞庫(tsi.src)衍生來的。目前還沒有翻頁功能,不過基本邏輯已經正確囉。

Windows版本,等 key preprocessor 架構完整後,就能支援了。

徵求測試:針對LeopardVanilla不穩所做的修正

自上週五 OpenVanilla 0.8.0 發布以來,我們已經接到不少關於 Leopard 專用版 (“LeopardVanilla”) 不穩定問題的回報。我們今天發布了新的修正套件,在此徵求測試。請下載本連結所附的檔案,解開後,依據README文件說明,將/Library/Input Methods/中的OpenVanilla.app代換掉(可能要先disable LeopardVanilla並登出才能進行代換,或者在shell進行sudo cp),再重新登入。

目前「初次起動不穩」的問題應能獲得改善。「進入偏好程式修改設定後,輸入法無法使用」的問題也應獲得大幅改善。前者應可算完全解決,後者仍有機會在離開偏好設定後,造成輸入法失靈(解決方法,除了離開現有應用程式,也可試著在shell下打”killall OpenVanilla”)。我們會繼續努力解決後面這一問題。

要請各位朋友幫忙測試看看這一版是否有改進了。謝謝!

« Prev - Next »