©1997–2019 Adobe。
特此免費授予任何獲取本文檔文件副本的人,以使用,複製,發布,分發,分配,轉銷和/或出售文檔的副本,並允許其他人這樣做,但前提是:
不允許對本文檔進行修改,編輯或其他更改;和
上述版權通知和該許可通知應包含在文檔的所有副本中。
特此免費授予獲得本文檔文件副本的任何人,從本文檔的內容中創建自己的衍生作品,以使用,複製,發布,分發,分發,轉銷和/或出售衍生作品,並允許其他人進行相同的工作,前提是派生的工作不被表示為本文檔的副本或版本。
Adobe對於任何收入或利潤的損失,或間接,偶然,特殊,後果或其他類似損害賠償的任何一方都不應承擔任何責任,無論是基於侵權行為(包括無限制的疏忽或嚴格的責任),合同或其他法律或公平的理由,即使Adobe已被告知或有理由知道有可能遭受此類損害的可能性。 Adobe材料以“原樣”為基礎提供。 Adobe明確否認與Adobe材料有關的所有明示,法定或暗示的保證,包括但不限於有關適銷或適合特定目的或不侵犯任何第三方權利有關Adobe材料的保證。
Adobe對本規範的主題沒有專利。
文檔版本2.9。最後更新於2019年8月21日
Adobe Glyph列表規範的目的是描述從一系列字形名稱中的Unicode字符串的計算。這是通過指定從字形名稱到Unicode字符字符串的映射來實現的。
該映射旨在將一系列字形名稱轉換為純文本,同時保留基本語義。例如,“ a”的字形名稱,“小資本A”的字形名稱以及“ A” swash變體的字形名稱都將映射到相同的UV( Unicode值)。這對於在某些環境中復製文本很有用,也可用於進行與“ A”相對應的原始字符串中所有字形名稱匹配的文本搜索。
確定合法字形名稱的集合不在此規範的範圍之內。字形名稱出現在許多不同的上下文中,每個名稱都對構成法定名稱的定義有自己的定義。該規範僅假定字形名稱對應於Unicode字符的任意有限序列。
該規範由AGL( Adobe Glyph列表)組成,該規範提供了特定的字形名稱與Unicode值的映射以及分解和解釋字形名稱的規則。因為預計該規範將在許多軟件中實施,並且不太可能修改使用它的所有實現,因此該規範旨在穩定,這意味著永遠不會以實質性的方式對其進行修訂。特別是,打算不會將映射添加到AGL中。另外,AGL並不是要作為選擇新字體的字形名稱的指南。為此,存在AGLFN(新字體的Adobe Glyph列表)(請參閱第6節)。
該規範支持Unicode標量值的全部範圍,即U+0000至U+10FFFF。它不取決於特定Unicode版本的字符曲目;因此,它適用於Unicode標準的過去,當前和未來版本。
強烈鼓勵字體生產商在為字體命名字形時尊重這種規範。鼓勵字體消費者在嘗試從字形名稱中得出內容時遵循此規範。
要將字形名稱映射到字符串,請按照以下三個步驟:
從第一次出現時(u+002E全停止)開始,從字形名稱中刪除所有字符(如果有)。
將剩餘的字符串分為組件序列,使用下劃線(U+005F低線)作為定界符。
根據下面的步驟將每個組件映射到字符串,並將這些字符串串聯;結果是映射字形名稱的字符串。
如果字體為zapf dingbats(PostScript FontName: ZapfDingBats ),並且該組件在ITC ZAPF dingbats Glyph列表中,則將其映射到該列表中的相應字符。
否則,如果組件在AGL中,則將其映射到該列表中的相應字符。
否則,如果該組件的形式為“ uni”(U+0075,U+006E和U+0069),則是一系列大寫近來的十六進制數字(0-9和a – f(含義u+0030和a – f),u+0030至u+0039和u+0039和u++0041和u++++0046,如果是四個序列,則該序列是一個序列,即一個序列的序列。在0000至d7ff或e000到ffff中,然後將每個範圍解釋為一個Unicode標量值,然後將組件映射到這些標量值的字符串。請注意,範圍和數字長度限制意味著“ Uni”字形名稱前綴只能與基本多語言平面(BMP)中的UV一起使用。
Otherwise, if the component is of the form 'u' (U+0075) followed by a sequence of four to six uppercase hexadecimal digits (0–9 and A–F, meaning U+0030 through U+0039 and U+0041 through U+0046), and those digits represents a value in the ranges 0000 through D7FF or E000 through 10FFFF, then interpret it as a Unicode scalar值並將組件映射到該標量值的字符串。
否則,將組件映射到一個空字符串。
名稱“ lcommaAccent”具有一個單個組件,該組件由AGL映射到字符串u+013b。
名稱“ UNI20AC0308”具有單個組件,該組件映射到String u+20AC U+0308。
名稱“ U1040C”具有單個組件,該組件映射到字符串u+1040c。
名稱“ unid801dc0c”具有單個組件,該組件映射到一個空字符串。 D801和DC0C都不在適當的集合中。該表單不能用於映射到UTF-16中以D801 DC0C(特別是U+1040C)表示的字符。可以使用字形名稱“ U1040C”正確映射此字符。
名稱“ Uni20Ac”具有一個單個組件,該組件映射到一個空字符串(請注意小寫“ A”和“ C”)。
名稱為“ lcommaaccent_uni20Ac0308_U1040C.Alternate”,有三個組件,它們是“ lcommaaccent”,“ uni20AC0308”和“ U1040C”。它映射到字符串U+013B U+20AC U+0308 U+1040C。
通常,可以將多個名稱映射到同一字符串。例如,組件“ lcommaAccent”,“ uni013b”和'u013b'全部映射到字符串u+013b。
名稱“ foo”映射到一個空字符串,因為“ foo”不在AGL中,並且因為它不是以“ u”開頭的。
第一步將名稱“ .notdef”簡化為一個空字符串,並在第三步的最後一個子句中映射到一個空字符串。
該規範支持將字形名稱映射到包含PUA值的字符串。例如,名稱“ ogoneksmall”和“ unif6fb”都映射到與u+f6fb相對應的字符串。
該規範不包括,暗示,也不包括任何特定的PUA用法;它僅允許命名字形,以便恢復的字符串包括PUA代碼點。由字形名稱的生產者和消費者決定了有關PUA使用的協議。
字體設計人員應注意,與通用字體的用戶建立此協議可能很困難。並非所有操縱由字形名稱構建的角色字符串的工具都可能正確地實現了PUA的用法,這可能會導致錯誤或意外的功能。因此,對於通用字體,建議所有字形名稱轉換為不包含PUA代碼點的字符串。
隨著時間的流逝,該規範已經演變。請參閱第7節(文檔更改)以進行更改。
對於與Unicode標準中字符相對應的字形,建議根據第2節中的規則在16個補充平面中使用基本多語言平面(BMP)中字符(BMP)中字符的“ Uni”前綴和16個補充平面字符的較短的“ U”前綴來指定名稱。
這並不意味著如果字體在沒有使用“ Uni”和“ U”前綴的字形前綴為其字形名稱的情況下製成,則這些字體是無效的。除了一組例外,AGL中的所有字形名稱當前都在所有已知環境中工作,以及“ Uni”前綴的名稱。例外是與PUA代碼點關聯的AGL字形名稱。這些包括所有上司和小帽子名稱。為了搜索文本,使用這些名稱的使用將導致一些當前的實現將諸如“ Asmall”之類的名稱映射到AGL中指定的PUA值,而不是用於“ A”的UV。現在,我們建議根據本節規定的規則命名這些字形。 AGLFN(新字體的Adobe Glyph列表)提供了不包括與PUA關聯的名稱的AGL子集。
如果字體中的多個字形表示Unicode標準中的相同字符,例如“ A”和“ A.Swash”,則可以通過使用具有不同後綴的相同基本名稱來區分它們。後綴(第一個時期之後的字形名稱的一部分)不參與字符序列的計算。字體設計人員可以使用它來指示字形的特殊特徵。後綴可能包含時期或任何其他允許的字符。例如,因此可以命名為“ uni0041.sc”或“ a.sc”的小帽“ a”。
如果存在相同基尺的多個變體,則變體後綴應包括零填充的固定長度數字,以便如果和何時對字形名稱進行排序,則可以保留預期的順序。例如,如果“ ampersand”字形具有23種替代形式,則通過'ampersand.alt.alt23'而不是'ampersand.alt.alt'命名為'ampersand.alt01',以及'ampersand.alt.alt1'通過'ampersand.alt.alt.alt22'。該規則僅為字體開發和測試提供了較小的便利性。如上所述,這些字形名稱後綴不參與字符序列的計算。
該規範不會標準化任何後綴。任何任意後綴都將用於文本搜索的目的。為了方便開發和測試,Adobe使用最合適的Opentype佈局功能名稱作為後綴。例如,一個小帽“ a”可以命名為“ a.smcp”,初始形式為“ a.init”,最終形式為“ a.fina”和swash form'a.swsh'。如果還有其他sw亂的表格,則可以將其命名為“ a.swsh1”,“ a.swsh2”,依此類推。以下是Adobe字體中使用的後綴的示例:
對於與Unicode標準中的任何字符的字形,該名稱將沒有任何技術有用性。任何名稱都可以分配,只要該名稱不會根據本文檔中的規則解釋為具有語義價值。 Adobe的類型開發團隊的實踐是,如果對字形有任何有用的描述標籤,請相應地命名,例如“鼠標”,“ signforsale”,“ clasthTreeball12”等。否則,將其命名為“ Orn”(裝飾品的簡短)的變體,例如'Orn001','orn123',等等。
對於代表標準Unicode字符的連接的字形,其字形名稱有兩種建議的格式,如下所示:
描述性分解是通過使用下劃線(U+005F低線)按順序連接標準Unicode字符的字形名稱來表達的。字符的字形名稱應指定“ Uni”或“ U”前綴,並如上所述使用大寫十六進制數字,或使用AGL的名稱。例如,“ OFF I”結紮應命名為“ O_F_F_I”。
帶有“ Uni”前綴的紫外線名稱為前綴為“ Uni”,然後是兩個或多個四個大寫十六進制數字的兩個或多個序列。四個大寫十六進制數字的每個序列都按順序指定BMP內的Unicode標量值。例如,不在unicode中的帶有繞行和墳墓的字符拉丁大寫字母EZH應命名為“ Uni01b70302020300”,因為拉丁語資本字母EZH是U+01B7,結合了Belfleflex的口音是U+0302,並且將Grave Grave Eccent是U+0300。名為“ T.Swash”和“ H”的字形的綁紮可以命名為“ T_H.SWASH”。 't.swash_h'將是不正確的,因為這將被解釋為“ t”的玻璃玻璃體變體。所有字形名稱均受到63個字符的長度限制,並要求它們完全由以下集合中的字符組成:A – Z,A – Z,0-9,'。 (週期; U+002E全停止)和“ _”(下劃線; U+005F低線)。一些較舊的實現可能會施加31個字符的長度限制。
對文檔名稱和當前實現(基於1.1版,日期為2003-01-31)中提供的一些過去實施問題以及對字形名稱的相應限制的簡要審查,該命名在下面提供:
引言本文是在很長時間的,因為它包含有關當前實現的評論。如果在2002年10月之後閱讀大量閱讀,請記住這一點。
在何處以及為什麼在(不可用的)文章unicode和Glyph名稱的命名慣例下使用的尺寸以及為什麼在PDF(便攜式文檔格式)文檔中復製文本和搜索文本的命名,而不是在多種情況下使用,而不是沒有任何名稱,或者沒有遵循這些慣例的名稱。在互聯網時代,必須搜索許多文檔才能有用,這非常重要。
當文檔引用的原始字體不可用,並且必須使用嵌入式字體數據時,許多PDF文件都是由PostScript打印機文件製成的。在這種情況下,opentype字體的Unicode“ CMAP”表不可用,並且PDF生產商可能對字形的語義可能擁有的唯一線索就是其名稱。
即使有原始字體文件可用,不直接與Unicode中的字符對應的字形仍然可以通過其名稱有效地連接到Unicode字符。例如,將“ t”的裝飾變體命名為“ t.alt”,允許PDF生產者註意到“ t.alt”具有與“ T”相同的語義,以搜索和其他目的。
將來,預計比Adobe自己的產品更多的產品將支持基於Unicode的文本字符串搜索字形,這意味著這些規則的實用性範圍將變得更廣泛。
對於可能完全缺少字形名稱的Truetype字體,在“ CMAP”表中的字形的Unicode值的存在仍然會導致在大多數情況下與Unicode角色正確關聯的字形。但是,對於不從Unicode代碼點繪製的字形,請使用上一條評論。
為什麼不建議在Unicode的BMP中編碼的字形前綴“ U”?前綴“ U”不受Acrobat版本4和5的支持。它得到了Acrobat版本6及以後的支持,這也是引入BMP(基本多語言平面)之外的Unicode字符的支持時。使用前綴“ Uni”的Agl名稱和字形名稱以及“。”。雜技版4和5已經支持“ _”解析規則。
Western Opentype/CFF和TRUETYPE字體的名稱字形的長度和字符集限制仍必須在許多工作流程中作為名稱鍵字體數據引用。結果,字形名稱仍然受到1型規範和後錄說明器實現所施加的長度和字符集限制的約束。儘管這兩者都表明字形名稱的長度不超過31個字符,但實際上,尤其是在現代環境中,字形名稱的長度可能長達63個字符,但不能以數字或週期開始,並且必須完全由以下有限集中的字符組成:
這些要求的唯一例外是特殊的“ .notdef”字形。
例如,“ Twocents”,“ A1”和“ _”是有效的Glyph名稱,但“ 2cents”和“ .twocents”不是。
ATM和KERNING對濾波器的多個應用程序,Windows和Macintosh版本的ATM( Adobe Type Manager )在有限的範圍內提供了對Opentype字體中對Kerning的支持。之所以出現此限制,是因為大多數不感知的應用程序都假定字體中的所有kerning對都可以合理地擬合是一個表,並且不超過幾千個kerning對。提供的Kerning對多於這使此類應用程序崩潰。在Opentype佈局支持基於班級的Kerning的情況下,即使只有220個字形的字體,也通常會超過此限制(如果良好的話)。為了允許使用此類Optyeoe字體而不會崩潰當前的應用程序,ATM通過首先將基於類的Kerning完全擴展到單字形名稱對的列表,然後通過基於Legacy OS的API支持Kerning,然後通過硬編碼的Glyph名稱列表過濾此列表。如果在濾波器列表中不存在Kerning對的兩側的字形名稱,則省略了整個Kerning對。 Windows 95和Mac OS 9的Kerning對過濾列表不再可用。
版本2.9(2019年8月21日)編輯更新。
版本2.8版(2018年8月9日),字形名稱的長度限制從31個字符調整為63個字符,以反映當前的實踐和實現,並註意到某些較舊的實現可能會施加31個字符的限制。
版本2.7(2017年8月12日),將標題為“字形名稱”和“當前實現”的外部文檔添加到第6節中。
版本2.6(2015年3月28日)與將其遷移到Github有關的小社論修訂。
版本2.5(2010年11月10日)次要編輯修訂與使其成為開放規範有關。
版本2.4(2003年9月24日)次要修訂。針對新字體的Adobe Glyph名稱的指向URL進行了新的修訂。
版本2.3(2003年4月17日)次要修訂。添加了一個簡短的句子,以表明“ Uni”前綴只能與BMP Unicode值一起使用。
版本2.2(2003年1月31日)次要修訂。在製作新字體時添加了一個鏈接到要使用的字形名稱列表,並強調AGL 2.0版本不是為此目的,也不是關於在字體中編碼字形。
版本2.1(2002年11月4日)次要修訂版,擴展了有關在新字體中分配字形名稱的部分。
版本2.0(2002年9月20日)主要修訂版,該版本將文檔重點放在將字形名稱轉換為Unicode標量值的轉換;在AGL中添加了許多名稱;更新Zapfdingbats列表到Unicode版本3.2。
版本1.1(1998年12月17日)通常修訂了整個文件。更新了大多數表和數據文件。添加了有關選擇字形名稱的部分。用於提取語義的偽代碼擴展到包括非固定的連接和字形變體。添加了有關為雙層構圖提供單獨設計的部分。刪除了有關WGL4差異的部分(不再適用; WGL4已更新)。
版本1.0(1997年11月10日)第一版。