摘要
X渲染擴展（X Render Extension）提供了一個新的基於客戶方字形（glyph）和字體管理的字形渲染體系結構
這個擴展設計在解決了許多相關技術難題的同時
也把光柵化字體
配置字體以及定制字體使用的責任交給了每一個X客戶程序
編寫Xft庫是為了給X應用程序提供一個能訪問FreeType字體光柵化引擎和X渲染擴展的
便於使用的接口
鑒於FreeType沒有提供配置和定制字體的功能
Xft也擔負了這一任務
Xft提供了新的字體命名約定
復雜而精密的字體匹配和選擇機制
並對相關功能進行充分的抽象
從而使得一般應用程序既能夠從使用X渲染擴展的文本輸出獲得益處
又能在不支持這一擴展的X服務器上正常工作
引言
X渲染擴展[Pac
]把訪問字體文件和生成字形圖像的功能從X服務器移到了X客戶一方
采用客戶方字形管理的X應用程序在以下幾個方面有優勢
可以訪問字體文件的所有細節
應用程序可以指定特有字體
漸增的光柵化處理（incremental rasterization）
並且有可能與其他部件共享字體
例如打印機
此外
鑒於底層的渲染機制基於圖像而非字形
字形的光柵化技術
乃至字體文件格式本身都不再依賴於X服務器的能力
所以現在新字體技術的集成速度可以跟得上獨立應用程序的開發
而不必遙遙無期地等待新的X服務器增強技術
當X服務器不再負責管理字體文件的訪問和字形生成
就需要一個新的函數庫在客戶方完成相應的任務
由於X渲染擴展在設計上支持消鋸齒（anti
aliased）圖形
這個新的函數庫需要支持高質量的消鋸齒字形光柵化
FreeType項目[TT
]開發了一個完整的字體光柵化引擎
不僅支持大多數輪廓字體格式
還支持標准的X PCF位圖字體
X渲染擴展接收字形圖像並使之在屏幕上顯現
為了讓應用程序能在屏幕上顯現高質量的文本
所需要做的就是在FreeType和X渲染擴展之間放置一層薄薄的
粘合
代碼
對於不支持渲染擴展的X服務器
這個函數庫還需要提供訪問
核心
字體（使用原始X核心協議訪問的字體）的能力
這就使得應用程序能在轉向新函數庫時仍然支持老式X服務器
FreeType庫沒有指定如何定位字體文件
而是需要應用程序提供字體文件名
這就把配置和定制可用字體集合的負擔放在了FreeType庫以外
因此
這個新的
粘合
層也需要提供一些配置功能以便在桌面環境中應用
X渲染擴展字形管理
X渲染擴展提出了幾個簡單抽象供應用程序管理字形
每個Glyph結構包括一個覆蓋字形外形的alpha掩碼（一個描述不透明值的矩形映象）
從alpha掩碼原點到名義字符原點的偏移量
到下一字形的位移（包括垂直和水平的偏移量）
GlyphSet結構則包含了一個字形結構的集合
應用程序使用一個
位的索引對字形集進行編號
應用程序繪制文本時
把一個GlyphSet標識符以及一系列針對該GlyphSet的索引發送到X服務器
X服務器通過對指定位置使用字形結構中的偏移量調整確定繪制位置
並渲染alpha掩碼來完成對每個字形的處理
後續字形的繪制位置則是通過在當前原點加上位移向量實現
正如X核心協議中的PolyText請求
在同一個請求中可以對字形序列作出調整位置
改變GlyphSet等變動
從而使得一個復雜的字符串在一次操作中完成渲染
為了覆蓋世界上更多的民族
操作系統支持的語言和區域集合不斷擴展
伴隨這種擴展
大多數字體中包含的字形數也大大增加
當今流行的輪廓字體中會包含幾千個字形
十多年前
漸增式渲染字形被看作一種合理的優化
現在已成為各種字體機制中的基本組成部分
以盡可能減少每種字體占用的內存
並縮短訪問一種新字體時所需的時間
X渲染擴展通過允許在需要時把一個Glyph加入已存在的GlyphSet
提供了這種漸增式渲染支持
由於在添加Glyph的過程中沒有任何從X服務器到X客戶的信息流
這一過程可以完全異步進行
這種異步性保證了即使面對一個高網絡延遲的環境
仍有可接受的性能表現
當應用程序傳送它們需要顯示的字形圖像時
X服務器通過在任何可能情況下共享相同字形來節省內存
FreeType庫
FreeType項目的初衷是要構建一個自由的TrueType字體光柵化器
FreeType的第一版提供了與現有系統相當的高質量TrueType光柵化器
FreeType的第二版對內部結構進行了一般化以支持更多字體格式
除了支持Type
OpenType和CID等眾多輪廓字體格式
FreeType現在還支持X的標准PCF格式（可移植編譯格式）的位圖字體
FreeType不僅提供光柵化以及度量字形的接口
還提供存取字體文件內各種形式的字距調整和字形替換等表格的機制
這就在基礎字體含有相應表格的前提下
使應用程序能夠獲得在各種區域中定位字形所必需的數據
既然FreeType項目明確地要構建一個通用的字體函數庫
在XFree
開發一個新函數庫的負擔就可以大大減輕
因為可以直接采用現有系統
並提供
粘合代碼
改變FreeType數據結構使之使用X渲染擴展的要求
這固然使得應用程序需要面對FreeType函數庫可能的變化
但考慮到FreeType是一個成熟的項目
相對於完全由XFree
開發一個新函數庫的情形
這種變化的嚴重性大概會輕很多
字體命名和配置不屬於FreeType函數庫
這些
雜務
交給了應用程序
考慮到FreeType應用於各種環境
有些甚至沒有文件系統
為保證FreeType得到最大程度應用並獨立於系統策略
這種設計思想是適當的
提供這些支持成為Xft實現中最困難的部分
並且其中一部分可能很快就被替換
XLFD命名
X核心協議規定了用非結構化字符串命名字體的方法
X邏輯字體描述（XLFD）[SG
]用於在字符串名格式中加入結構信息
在開發X時
用於桌面計算的輪廓字體還是一個相對新奇的事務
所以X核心協議和XLFD都是基於位圖字體設計的
當圍繞縮放字體命名的語法和語義加入XLFD時
基於XLFD的開發已經進行了相當長的時期
XLFD中字體命名語法的意圖在於僅通過名字就可以向應用程序提供足夠的字體信息
這樣就可以在不訪問字體數據情況下
進行字體選擇和字體列表表示
XLFD還提供了使用包含
?
和
*
的名字打開字體的標准策略
使用這類名字時
選中的字體將是第一個匹配的字體
即使用相同模式請求列出字體時返回的第一個
不幸的是
X服務器保存字體名時為了高效搜索
會在各字體目錄中進行內部排序
所以不能保證
*
的默認值是合理的
例如
當在字體名的weight字段使用
*
時
X服務器會把bold字體列在normal字體之前
這個策略真正失敗之處在從point（點值）尺寸到pixel（像素）尺寸的映射
XLFD在字體名中分別提供了兩個軸向上的pixel尺寸
point尺寸和resolution（解析度）
標准的X字體按照解析度分別存放
dpi
和
dpi
下各自存放著與該解析度匹配的各種點值尺寸的字體
其他字體目錄下一般是為了在
dpi屏幕光柵化
協議指導X服務器按照在字體路徑（譯注
font path
應指配置文件中相應節）中出現的順序去搜索字體目錄
這就使字體路徑決定了對解析度的傾向性
如果
dpi的目錄列在前面
當應用程序在字體名的resolution字段用
*
時
只要在
dpi目錄下存在匹配字體就會使用該字體
否則才去嘗試
dpi的字體
應用程序如果在字體名中僅指定point尺寸
而在resolution字段使用
*
那麼最終將會得到一組隨即尺寸的字體
那些在
dpi目錄下發現的字體按照
dpi屏幕光柵化
其他字體則按照
dpi屏幕光柵化從而會顯得小一些
最終的結果是XLFD的字體匹配充滿了危險
應用程序經常列出所有可用字體（作出選擇）然後提交完整XLFD字體名（譯注
不含
?
和
*
）給X服務器
XLFD的另一個問題是在字體名中包含了字形的平均寬度字段
對於需要在不同總體寬度的字體中進行選擇的應用程序而言
這是個非常有用的信息
而且對位圖字體也很容易計算
但是對輪廓字體
除非在指定尺寸下對每個字形進行光柵化計算
該字段值不能算出
僅僅列出一個特定尺寸下所有的可用字體就會導致光柵化每一個字體的每一個字形
XLFD提供了關於可用字體的有用信息
出列平均寬度
這些信息都是容易計算並交付應用程序的
使用XLFD的應用程序應該在本地管理XLFD字體名
而不要依賴服務器方字體匹配
也就是通過列出可用字體收集信息
再利用這些信息構造完整字體名
鑒於XLFD沒有提供一種按照語義匹配的合理方案
需要有新方案允許在應用程序給定一組約束情況下
基礎的字體系統能夠定位一個適當的字體
這樣的系統需要有足夠的靈活性以便能夠包含現在不能預料的新字體特性
也不需要應用程序完全指定字體的方方面面
設計一個新函數庫
Xft在三個方面與環境交互
通過編程接口與應用程序交互
通過配置文件與系統交互
通過讓用戶指定字體名與用戶交互
雖然這三方面在函數庫中緊密相關
但從設計角度來說
它們是分離的
應用程序接口設計
Xft的首要目標是把FreeType的輸出和X渲染擴展結合起來
但是
為了Xft能作為現有的Xlib文本輸出例程的替代物而被人接受
其次要目標包括支持核心X字體
盡管這樣做可能以損失應用程序功能為代價
由於FreeType不提供字體選擇功能
所以Xft的一部分要進行字體匹配
采用現有的XLFD機制會極大地限制字體匹配地能力
所以Xft提出了一種新格式
這種選擇機制被設計為總能匹配某種字體
允許應用程序假設適當地字體存在
避免在每個級別上都要考慮失敗回落
另一個要求是函數庫要提供
From:http://tw.wingwit.com/Article/program/Oracle/201311/18564.html
