3

CFF 规范第 11 章到第 13 章对文件中组织的编码和字符集数据进行了粗略的描述。CFF 规范。这里有一些问题。

  1. 考虑到多字体文件的可能存在，并且字符串是以每种字体的方式访问的，相应的索引也应该只对每种字体有意义。但是，文件最多只有一种编码和一个字符集表吗？如果是这样，字形索引与字符字符串的索引如何对应？如果不是，它们是否在访问它们的 TopDict 中多次出现？ （已解决。请参阅下面的答案。）

  2. 字符集似乎为每个字形命名。编码呢？每个数组元素中存储的 Card8 数据是什么？鉴于它的 256 限制，编码会不会很受限制？为什么在补充格式中数据是通过 SID 来的？通过编码访问字形的设计方法是什么（以混合字符串/代码方式）？当涉及到预定义的编码时，为什么又是这些数据字符串？

谢谢

4

2 回答 2

1

以下是对问题 1 的回答：

认为单个字体文件中只有一个字体文件是错误TopDict的。TopDict是一个索引结构，它可能包含 FontSet 中每种字体的多个顶部表。因此encodingand的定义charset自然是按字体定义的。Name在规范的数据布局中，并TopDict没有用“per-font”标记，这有点令人困惑。见第 8 节。

这包含存储在 INDEX 结构中的 FontSet 中所有字体的顶级 DICT。此 INDEX 中包含的对象在顺序和编号上都与 Name INDEX 中的对象相对应。每个对象都是一个 DICT 结构，对应于 PostScript 字体的顶级字典。字体由 Name INDEX 中的条目标识，其数据可通过相应的 Top DICT 访问。

于 2020-08-15T22:53:07.107 回答
0

我可以从实际的角度来回应：

关于#1，问题似乎与多个 CFF 字体集有关，这在 OpenType/CFF 字体的上下文中是非首发：仅允许/识别一个 CFF 字体集。

关于#2，编码问题在 OpenType/CFF 字体的上下文中也不是一个初学者，因为编码是由“cmap”表强加的。

总之，独立的 CFF 实际上毫无价值，它抵消了多个 CFF 字体集和内置 CFF 编码的任何实际或感知的好处。

于 2020-08-15T01:20:57.497 回答