©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日)第一版。