2007年1月28日星期日

大於與小於50000的差異

在zhcon的basefont.cpp中看到這一段程式碼時, 心中突然有了些感觸。

下面所記載的程式碼,主要的目的是判斷在字型檔大於50000Bytes時,就改採用memory mapped的方式來配置,因為CJK所用的字型大部分大於這個容量,所以得另外作一些處理。而這些細心的念頭, 是在FreeType的PCF部分,還有libXFont的PCF中找不到的。想當然爾,國外地區的Hackers只需要用到ASCII的字型,誰會去關心這樣的細節呢?

因此,對於這些CJK的基礎建設,我們更應該主動去作才是。

若我們不作,還有誰會來作?

if (mBufSize > 50000) {
//hzfont use mmap
mpBuf = (char *) mmap((caddr_t) 0, mBufSize, PROT_READ,
MAP_FILE | MAP_SHARED, mFd, (off_t) 0);
if (mpBuf == MAP_FAILED)
throw (runtime_error("error in mmap gbfont!"));
} else {
//ascii font read to buffer
mpBuf = (char *) new char[mBufSize];
unsigned nread = read(mFd, mpBuf, mBufSize);
if (nread != mBufSize)
throw (runtime_error("error in reading asciifont!"));
}

2007年1月24日星期三

你要慢跑還是漫跑?

剛退伍的我,常有一種很深的學習焦慮感,尤其在希望早點獨立自主的自我期望下,凡事都急求速成,什麼東西都沾一點,卻又不夠深入。弄到最後,一件都沒有好好的學成,心情也跟著低落。

逛Blog時碰巧讀到
"Teach Yourself Programming in Ten Years" 這篇文章,作者提出了對人人學程式設計急求速成的反問,並用他的經驗告訴我們,那些求速成所花的時間, 根本就不夠養成一個真正的程式設計師。網路上形形色色的成果展示,或是創意作品,也許只有短短幾分鐘,但可知作者在背後花了多少的時間和心血,才能達到這樣的能力?

正所謂,「台上十分鐘, 台下十年功」。

之前讀到李四端對於新聞工作的感想「你要新聞慢跑還是漫跑?」,也是心有所感.,或許在汲汲騖騖的生活中,也要找機會停下腳步來想一想,自己是否真的熱愛所投身的工作、事業?還是只是漫不經意的走馬看花。

最近洽巧讀到一篇值得一看的程式設計學習的導引,"How To Become A Hacker",除了呼應了"Teach YOurself Programming in Ten years" 所表達的觀念,也鼓勵讀者多學習性質不同的程式語言,並嘗試以不同語言的性質來思考問題。

小小繞了一圈操場,才發現真正要走的路,還很長很長...

2007年1月23日星期二

RT executive

作為RT nanokernel的應用呈現,最近花了一些時間發展相容於RTLinux-GPL的小型RTOS,目標是銜接眾多RTLinux的modules與RT applications,但不需要種種Linux沈重的包袱,僅實做最小的虛擬記憶體管理、RTLinux-GPL相容APIs、更精簡的TLB與記憶體快取機制,同時能充分控制硬體,至於原本Linux applications (non-RT tasks),則由RT nanokernel建立特定的domain以運行。

2007年1月9日星期二

OSDC.tw 2007 is coming

OSDC.tw (Open Source Developer's Conference in Taiwan) 2007 即將在四月份舉辦,Mat與我都準備提案,希望屆時可分享我們最近的成果。

Mat 的提案名稱為:"Unicode Console InputMethod Framework",以下是提案內容:

在console輸入中文真的非常麻煩,常常需要透過其他媒介才行。在觀察當時的console上輸入法相關的程式和實作方式後,發現兩個必須要徹底解決的問題:
  • 輸入法的支援幾乎都是寫死在程式裡
  • 大部分沒有接軌國際架構
這些問題使得重複的基礎建設一再消耗Programmer的力氣。於是UCIMF提出以Shared Lib的方式,並用Dynamic Loading的方法來克服這兩個難題。未來幾個期待努力的方向,包括:
  • 與SCIM接軌
  • 用VT100的Control Sequence顯示組字

也就是將這兩年來開發UCIMF的歷程予以公開,不同以昔日閉門造車的途徑,UCIMF成功銜接IIIMFOpenVanilla等輸入法架構,並且這個Unicode Console也支援PCF與TrueType字型描繪,提供Linux輕量卻完整的多國語文終端機解決方案。

而我的提案名稱為:"RT Nanokernel for Embedded Linux",以下為提案內容:
在台灣,開發一個新的作業系統並非不切實際的工作,相反地,在銜接Free / Open Source software運動巨變的同時,其中很重要的理念就是最佳化、通用性,與客製化。Nanokernel/Hybrid-kernel 的提出,就是針對應用需求,如行動裝置的進階能源管理機制等需大量軟硬體協同開發的技術項目,提供一種新途徑。

眾多Realtime Linux系統的提出,證明可在符合特定需求的Hard Realtime OS上面運作修改過的Linux Kernel,以兼具即時任務需求與既有 Linux 應用程式相容性。在資訊產業有句金言:「沒有完美的技術,只有合用的技術」,本議題以日漸成熟的nanokernel /para-virtualization等技術為基礎,提出輕量級且易於擴充的新設計,讓Embedded Linux發揮更大的威力。
Realtime技術已限不於自動控制,事實上,在移動裝置也能透過RT nanokernel技術,不必大幅改寫系統,卻可提昇特定需求的可靠性與穩定性,如進階能源管理或高效能I/O處理。這樣一來,眾多的Linux應用程式不僅能在更多的平台運作,更可因此創造更大的價值,這也是我們強調"Programming 2.0"概念的展現。

期待您的指教!

2007年1月5日星期五

關於PCF的連結

在網站搜了一下,才發現PCF的資料並不如想像中的那麼多,找到的網站,幾乎都是格式轉換的用法,很少有提到PCF的規格和程式碼,在wikipedia甚至沒有專頁的介紹。

少歸少,還是找到了一些不錯的技術文件如下:

  • BDF的規格書」、「 PCF的規格」眼尖的人可以發現這裡可以找到大多數字型檔的規格書: Font File Format,這些資料是FontForge用心整理的, 對字型工作者提供莫大的幫助,而主頁有放正體中文翻譯的文件教學,,內容很棒!
  • BDF&PCF的深度文件」(日文) 因為是日文,所以從中得到的資訊很有限,不過有介紹到兩個字型的資料結構,內容相當深入,搜一下Google,發現作者多賀奈由太就是寫hexadecimal dump tool(hex)的人,難怪...
  • "Unicode fonts and tools for X11" 這篇文章也介紹了不少字型的資訊,尤其在最後兩三章提供了不少關於字型工具的聯結,很有幫助。
  • "QPF(QT Preredered Font)" 隨手逛到Qtopia也有自己的字型檔,不過他也支援Freetype的字型引擎,這讓我想到Freetype能否進一步輕量化,提供Embedded System高品質的字型引擎?不過文中也提到Unicode字型最大的弱點:
    All supported fonts use the Unicode character encoding. Most fonts available today do, but they usually don't contain all the Unicode characters. A complete 16-point Unicode font uses over 1 MB of memory.
寫到這裡,沒想到查個文件, 東點點西點點,就花了一個下午的時間。