OpenType CFF 註解與欄位外觀
原生的外觀建構器在既有的 TrueType 輸入之外，也接受帶 CFF 1 輪廓的 OpenType OTTO 字型
plain、rich、shaped 與 family 文字外觀透過 FontFile3、Subtype OpenType 與 CIDFontType0 子字型內嵌完整的原始 OpenType 檔案
按名稱鍵控的 CFF 以字形索引充當 CID，而 CID-keyed CFF 保留真實的 Registry、Ordering、Supplement 以及從字形索引到 CID 的 charset 對應
產生的 Encoding CMap 把文字字元碼對應到真實 CID；寬度按這些 CID 計算，ToUnicode 保留邏輯文字，CIDFontType0 不帶 CIDToGIDMap
字形位置與邊界使用 HarfBuzz OpenType 度量，包含 rich fragment 與組合標記的邊界；rich fragment 共用每個樣式獨立的不可變字型讀取器與同一個內嵌字型資源
CFF 度量需要架構相符的 HarfBuzz 函式庫，即便 ShapeComplexText 為 False 也一樣；HOTPDF_HARFBUZZ_LIBRARY 可明確指定路徑，複雜整形還要額外依賴既有的 FriBidi
沒有 normal 外觀的可見 FreeText 註解可以使用包含完整 OpenType CFF 字型的合法預設外觀資源；既有的資源優先序、裁剪、顏色與唯讀內嵌策略照常生效
可編輯欄位產生仍需要 installable 或 editable 權限；唯讀 fallback 允許 preview-and-print 權限，restricted 或 bitmap-only 輪廓依舊被拒絕，no-subsetting 會保留每一個原始字型位元組
字型位元組、字形、物件大小、rich 字型彙總、取消與原生渲染預算仍然強制執行；畸形的 CFF INDEX 偏移、字典、charset 範圍、重複 CID 與缺失的集合字串都會在發佈前被拒絕
格式對應遵循 ISO 32000-1:2008 9.7.4.2 與 9.9，包含明確的 CID-keyed OpenType charset 對應
原生渲染、MuPDF 與 Ghostscript 都能通過 sparse-CID OpenType 測試夾具；受測的 Poppler 後端對 sparse-CID OpenType 對應存在獨立的不相容，而 Poppler 的 identity-CID OpenType 與 sparse raw CIDFontType0C 對照組渲染正常
第三方閱讀器合成缺失註解外觀的方式可能不同；明確產生的外觀與各閱讀器自身的 fallback 行為是分開驗證的
缺失的註解外觀也可以透過原始 raw 字型註解路徑保留原始的裸 Type1、Type1C 與 CIDFontType0C 資源；OpenType CFF2 輸入走單獨的靜態預設 instance 外觀後端做明確的格式轉換，而不是把 CFF2 直接嵌進 PDF 1.7 字型串流