PDF中的嵌入式OpenType(CFF)字體在某些查看器中顯示出奇怪的行為

在我自己的庫生成的 PDF 中嵌入帶有 CFF 輪廓 (

Chrome 渲染（Noto HK 頂部，PingFang HK 底部）： 預覽渲染（Noto HK 不可見，PingFang HK 符合預期）： 其他香港中文 CFF 字體（如 PingFang HK）在我測驗過的每個 PDF 閱讀器中都能完美呈現，但 Noto Sans HK 剛剛贏了'噸。就嵌入限制而言，FontBook 顯示 Noto Sans HK 沒有“限制”，因此也沒有任何限制。

我將所有字體嵌入為帶有 Identity-H 編碼的 CIDFontType0C 字體，雖然我還沒有提供 ToUnicode 映射，因為它們是路線圖上的下一個東西，但這對渲染沒有影響。

Noto HK 字體物件（為簡潔起見洗掉了寬度）：

6 0 obj
<< /Ascent 1160 /CapHeight 733 /Descent -288 /Flags 4 /FontBBox [ -991 -1050 2930 1810 ] /FontFile3 10 0 R /FontName /NZGUSD NotoSansHK-Thin /ItalicAngle 0 /StemV 58 /Type /FontDescriptor >>
endobj
7 0 obj
<< /BaseFont /NZGUSD NotoSansHK-Thin /DescendantFonts [ 8 0 R ] /Encoding /Identity-H /Subtype /Type0 /Type /Font >>
endobj
8 0 obj
<< /BaseFont /NZGUSD NotoSansHK-Thin /CIDSystemInfo << /Ordering (Identity) /Registry (Adobe) /Supplement 0 >> /FontDescriptor 6 0 R /Subtype /CIDFontType0 /Type /Font /W 9 0 R >>
endobj

等效的 PingFang 物件：

11 0 obj
<< /Ascent 1060 /CapHeight 860 /Descent -340 /Flags 4 /FontBBox [ -72 -212 1126 952 ] /FontFile3 15 0 R /FontName /DYBBAB PingFangHK-Regular /ItalicAngle 0 /StemV 95 /Type /FontDescriptor >>
endobj
12 0 obj
<< /BaseFont /DYBBAB PingFangHK-Regular /DescendantFonts [ 13 0 R ] /Encoding /Identity-H /Subtype /Type0 /Type /Font >>
endobj
13 0 obj
<< /BaseFont /DYBBAB PingFangHK-Regular /CIDSystemInfo << /Ordering (Identity) /Registry (Adobe) /Supplement 0 >> /FontDescriptor 11 0 R /Subtype /CIDFontType0 /Type /Font /W 14 0 R >>
endobj

相關頁面物件：

3 0 obj
<< /F4v0 12 0 R /F5v0 7 0 R >>
endobj
4 0 obj
<< /Contents 5 0 R /CropBox [ 2.5 4 595 842 ] /MediaBox [ 0 0 600 850 ] /Parent 2 0 R /Resources << /Font 3 0 R >> /Type /Page >>
endobj
5 0 obj
<< /Length 462 >>
stream
q 1 1 1 rg 0 0 600 850 re F Q  BT /F5v0 15.000000 Tf 0 0 0 rg 0 Tr 27.500000 802.000000 Td [<0AFD292728192FFF3162282746BB112F14E410E20E96201D0D820A9111440EC016922CB046A10AFD0EC039AF1D0B272D17D431C92A2B4F4D384719160F2C29C9297634F34F4D1846>] TJ ET  BT /F4v0 15.000000 Tf 0 0 0 rg 0 Tr 27.500000 780.280000 Td [<05487DE1129E161216D412A7726A08C175A77465074A7A1706A504E4748207710B1814B5726605480771641D0E4D12580BD481D113A37267628146D107BE7E0D1358AD3772670C18>] TJ ET endstream
endobj

我正在使用 HarfBuzz 生成帶有HB_SUBSET_FLAGS_RETAIN_GIDS標志集的子集，當我在 FontForge 中查看生成的子集時，預期的字形存在正確的 GID。

在 chrome 中，結果與以前相同：

呈現的字形肯定與提供的字形 ID 不對應（再次，用 FontForge 驗證）。

和以前一樣，無論哪種情況，PingFang 和其他字體都可以完美呈現。

我開始認為我可能在字形索引方面錯過了一個邊緣情況，其中 Cairo 和其他 PDF 生成器正在將 GID 重新映射到低數字，因此它們沒有問題，但我保留了原始 GID（仍然適合2 個位元組，但可能是我沒有看到的實作限制？）。

我將嘗試重新映射 GID 以查看是否有幫助并報告回來。

uj5u.com熱心網友回復：

發生這種情況是因為我對 CID 字體在 PDF 中的作業方式存在誤解。

讓我解釋。

在 PDF 中使用字體時，您將提供幾種結構（字體描述符、字體字典和 Type0 的后代字體）來描述字體，并將其分類為預定義型別之一（Type0、Type1、Type3 或 TrueType），以及在 Type0 的情況下，一個子型別（/CIDFontType0 或 /CIDFontType2）。

我不明白的是，帶有子型別 /CIDFontType0 的 Type0 字體實際上在 TopDICT 結構中使用 CIDFont 運算子的字體與不使用 CIDFont 運算子的字體（包括所有 CFF2 字體）之間存在進一步的隱含區別。

字形查找的作業方式也因使用的字體型別而異：使用“簡單”字體（Type1，TrueType），您將使用實際字串（(like this)或<0074006800690073>）作為顯示運算子的文本的運算元，而對于復合字體（Type0），您通常會使用十六進制編碼的 CID 字串 ( <DEADBEEF...>)。

當使用帶有 CID 字體的標識映射時，CID == GID，因此我們可以直接在這些字串中使用 GID —除非您使用的 CID 字體帶有 CFF 輪廓，并且其 TopDICT 中有 CIDFont 運算子。在這種（現在相當罕見）的情況下，CID 可能等于也可能不等于 GID——在我的測驗中，NotoSansHK 是唯一使用不同映射的字體，因此其他字體作業得很好。

我需要的是決議charsetTopDICT 結構中的陣列，并查找有問題的 GID 以獲得 SID。通常每個 SID 對應于字串索引中的一個字串，但在 OpenType 字體中，SID 似乎實際上對字體的 CID 進行了編碼。獲得 CID 后，可用于對 PDF 中的文本進行編碼。

在我的例子中，人 (U 4EBA) 的 GID 為 2813，但 PDF 閱讀器將其解釋為 CID，在這種情況下并不存在。但是，當使用 9749 的 CID 時，字形會按預期顯示。

標籤：pdf字体哈夫布兹

上一篇：洗掉和移動pikepdf中的元素

下一篇：iText7PDF解鎖器不適用于一些拋出BadPasswordException的加密pdf