|
1 引 言 高通作為全球領先CDMA手機平臺供應商，在國內得到廣大手機設計公司和手機廠商的青睞，其中包括德信無線、上海精佑、賽龍上海和UT斯達康等國內許多手機設計公司和手機廠商。為了支持國內市場，漢字顯示是必不可少的，而高通手機平臺上沒有直接提供完備的漢字顯示解決方案，本文就這個熱點論題，通過對高通手機平臺字符顯示特點進行了分析，具體地給出了基于BMP文件格式存儲漢字字庫的一種漢字顯示方案。 2 高通手機平臺Brew字符顯示原理 高通手機平臺Brew字符顯示由兩部分構成，一部分為上層應用提供一個統一的字符顯示接口部分，另一部分為某一種字符集或字體具體實現部分，這兩個部分是通過虛函數機制綁定在一起。在Brew字符顯示接口統一定義如下： IFONT AddRef（）：用于引用記數功能； IFONT_Release（）：釋放當前應用程序字符顯示實例； IFONT_QueryInterface（）：他根據字符ID檢索當前應用程序字符顯示實例； IFON_DrawText（）：他用于顯示具體的文本； IFONT_MeasureText（）：他用于計算以象素為單位文本的大小和字符的總數目； IFONT_GetFontInfo（）：他用于檢索字符相關信息，比如ascent和descent的值。 從上面的顯示接口定義可見，系統的設計者將字符顯示接口視為一個脫離依賴具體字符顯示的轉換模塊，而字符具體實現部分則需要根據顯示接口每個接口函數給出一個標準實現，功能就是針對某一種字符實現文本顯示，計算文本大小，返回該種字體一些信息等。 例如：高通關于ASCII字符顯示的參考設計中就定義了一組與顯示接口一致的一組函數： 然后通過指針賦值方式把這組函數與接口函數對應部分關聯起來，即在函數AEEVarBitFont_NewFromBBF內部通過指針賦值方式使顯示接口部分與具體實現部分綁定在一起。 上層應用模塊調用字符顯示模塊的過程如下： 3 高通手機平臺上漢宇字庫的BMP文件存儲結構的設計 在手機平臺上漢字顯示可以采用國標碼或Unicode任何一種編碼方案，但為了信息交換方便，大多數手機開發采用Unicode顯示方式，這里以Unicode為例來說明。傳統的漢字存儲結構采用數組方式，明顯地，字符集這種存儲方式無法直觀地顯示給用戶和軟件開發者，用戶和軟件開發者也很難了解字符集內真正包含了那些字符，再者，當顯示漢字時，系統需要將漢字字模存儲方式轉換為屏幕顯示方式，這將會增加系統開銷，降低運行效率。這里設計了用BMP文件格式來存儲漢字字庫，他保證整個存儲空間沒有明顯增加的同時，能夠使用戶直觀地了解字符集內包含了那些字符，提高系統運行效率。 與現有其他的漢字存儲結構和漢字顯示方法相比，該方法具有3個主要特點： 直觀性強 由于采用BMP圖片存儲結構方式，可以瀏覽漢字字符集中包含的漢字； 運行效率高 由于采用BMP圖片存儲結構方式，使得單個字符的字模存儲方式與屏幕顯示方式保持一致，當顯示漢字時，不需要把漢字字模存儲方式轉換為屏幕顯示方式； 可移植性強、開發周期較短 對上層應用模塊漢字顯示耦合得更好，由于這種方法盡可能地采用了Brew系統現有的字符顯示參考設計和已有的顯示接口機制。 由于漢字的Unicode編碼范圍為u4E00～u9FA5和uF900～uFA2D，如果不在這個范圍內就不是漢字了。為了討論方便，這里考慮漢字Unicode編碼范圍為u4E00～ugFA5，總計有20 901個漢字，他們是連續編碼的。 16*16漢字字庫BMP文件格式描述如下： 從上面的存儲結構可知，他實際就是一幅BMP格式的漢字字庫圖片，這幅BMP圖片就是漢字字符集的二進制表示，他是從BMP圖片格式轉換過來的。這里每個字符字模對應BMP圖片中一個圖片片，字模存儲方式與屏幕顯示方式是一致的。 4 基于BMP文件存儲結構漢字顯示實現 實現本地漢字顯示較早的一種方案基于Native UI，他不需依賴Brew顯示接口。目前較多的漢字顯示方案會涉及到Brew顯示接口，常見漢字顯示解決方案為： （1） 基于Native UI方案，實現漢字顯示。完全自己開發一套點陣存儲、點陣獲取、點陣顯示、漢字顯示函數，使用者使用特定的漢字顯示函數把漢字顯示出來。該方法具有最大的靈活性，甚至不理睬Brew任何顯示接口機制，直接在上層組件里實現，但這種方法使程序可移植性比較差，對第三方應用程序漢字顯示支持也不方便。 （2） 基于Brew方案，實現漢字顯示。自己開發點陣存儲、點陣獲取、點陣顯示，改造Brew的顯示接口函數，使其能判斷漢字碼，一旦判斷出漢字碼，則使用自己開發的點陣獲取、點陣顯示等把漢字顯示出來。然后把該自己開發的顯示函數綁接到Brew顯示接口上。該方法對點陣的操作更加靈活，工作量較大，開發周期較長，這種方法比較適用已有成熟的點陣操作方法開發者。 這里利用Brew對BMP文件格式的支持，使用BMP文件格式實現對漢字的點陣存儲、點陣獲取、點陣顯示的全過程，并使用Brew的顯示函數實現漢字碼到漢字顯示。這種方法盡可能地使用了Brew系統現有的字符顯示參考設計和已有的顯示接口機制，開發周期較短，是最根本的解決方法，他使得Brew的其他上層應用模塊能很方便實現漢字顯示。這種方法使程序通用性好，可移植性強，支持第三方應用程序開發也較方便等特點。 為了支持第三方軟件廠商集成不同國家文字顯示，高通手機平臺提供一個綁定顯示接口和對應的實現部分的接口函數，通過這個函數就可以把各種不同文字類型顯示方式綁定到Brew統一的顯示接口上，軟件廠商只需要根據具體文字的顯示方式實現具體的接口函數即可。這個接口如下： 各個參數介紹如下 IFont**ppif：漢字接口函數； const uint16*pwGlyphs：漢字碼表； int cntGlyphs：漢字總數目； const CHAR*pbyBitmap：用BMP表示的漢字字庫； int cbBitmap：用BMP表示的漢字字庫總的字節數目； int xCHARWid：每個漢字寬度； int yCHARHeight：每個漢字高度； int yCHARDescent：點陣打點開始位置在baseline之下的偏移； uint16 wUndefGlyph：未定義的ASCII字符數目； int nHalfCHARs：ASCII字符數目； UTFONTTYPE FontType：漢字類型。 為了實現BMP文件格式存儲結構字庫的漢字顯示方式，主要工作集中于下面兩個方面： （1） 定義創建字體實例接口函數 在Brew方案中，上層應用模塊都是通過ID創建字體實例，這里可以按照如下方式定義創建字體接口函數。 （2） 實現漢字顯示一組具體的接口函數 由于Brew方案中已經實現了基于BMP格式對ASCII碼顯示支持方式，所以顯示接口函數IFONT_Ad-dRef（），IFONT_Release（），IFONT_QueryInterface的功能已經實現，而漢字顯示方式這三個函數要實現的功能與ASCII是一致的，不需要改動。函數IFONT GetFon-tInfo對于漢字顯示不適用，因為漢字的ascent和descent的值為0，這里只要考慮IFONT_DrawText（）和IFONTMeasureText（）兩個函數的實現問題。 為了實現IFONT_MeasureText（），在他對應的實現函數內部增加計算一個漢字寬度的相應代碼。 為了實現IFONT_DrawText（），由于Brew提供了基于BMP格式對ASCII碼顯示支持方式，對于漢字顯示關鍵是計算漢字UNICODE碼與BMP格式的漢字字模的對應關系。由于漢字的UNICODE碼是連續，在BMP圖片中字模已經按照UNICODE碼順序排列，對于任何漢字只要計算他與第一個漢字（4E00）的偏移量，然后根據偏移量直接拷貝BMP圖片中該字符的圖片片到顯示緩沖區即可，不需要把單個字符字模轉換為屏幕顯示方式，提高了系統顯示速度。 5 注意事項 在實際開發中，手機軟件開發商一般以點陣形式從第三方購買字庫，為了能夠應用第三方字庫到高通手機平臺上需要轉換成BMP格式的文件。另一個要注意的問題是這里把漢字顯示作為單獨的一個字符集來考慮的，在實際中可以把ASCII，漢字和漢字偏旁部首構成一個字符集來考慮。只要根據不同的碼值分別計算他們各自對應BMP圖形的偏移量即可。 6 結 語 本文就高通手機平臺關于漢字存儲和漢字顯示方式這一熱門論題進行了詳盡討論，論述高通手機平臺Brew字符顯示原理、傳統漢字存儲結構的不足和不同漢字顯示方案的特點，并在論述這些原理和方案的同時提出了一種具有通用強，移植方便和容易擴展的漢字顯示方案，也提出了在實際應用需要注意問題。 |
