对pdf的引用表明，用于定义字体资源的pdf字典需要包含属性/Widhts，以提供以下信息：
（除了标准的14种字体外，是必需的；间接引用 首选）（LastChar-FirstChar + 1）个宽度的数组，每个宽度 元素是等于的字符代码的字形宽度 FirstChar加上数组索引。对于超出范围的字符代码 FirstChar到LastChar，从中的MissingWidth的值 使用该字体的FontDescriptor条目。字形宽度为 以1000为单位，对应于文本中的1个单位 空间。 这些宽度必须与中给出的实际宽度一致 字体程序。 （请参阅附录H中的实施说明61。）
强调了。
再次提供宽度 有什么好处？
坦率地说：有人可以确认或拒绝应该在此处提供的信息吗，字形宽度是公然多余的信息，甚至考虑到它包含在字体程序中？
还是某些字体程序在不指定字形宽度的情况下包含字形？ 是因为有一些字体程序不包含宽度，还是仅仅是耐心的执行，使PDF文件的生成变得复杂，希望人们继续使用Adobe软件？
测试所引用字体（未嵌入）是否为“正确”的/Widths条目（即pdf查看器应检查pdf所需的字体程序是否为在平台上找到一个，比较/Widths）？
答案 0 :(得分：3)
将Widths数组记录为存在，以便应用程序无需确定字体就可以确定字形的度量。例如，当在文本周围绘制选择框或以某种方式突出显示文本时，这可能很有用。
请参阅PDF 1.7规范的第393和394页：
每个字形的宽度信息都存储在字体中 字典和字体程序本身。 （两套宽度 必须相同；将此信息存储在字体字典中， 尽管是冗余的，但它使用户应用程序无需查看内部即可确定字形的位置 字体程序。）
我还应该提到，有很多个PDF生产者认为滥用Widths数组是改变字体间距的便捷方法。如果Font数组的Width与字体程序中字形的度量不匹配，则Acrobat使用Widths数组值（这是您引用的文本所引用的附录H中的实现说明）。我似乎还记得，该规范的最新版本取消了基本14种字体的例外，所有字体现在应该具有/ Widths数组。 我们有大量的PDF文件示例，其中的指标数组与字体程序中的宽度不匹配。
请注意，如果宽度和规格不同，则Acrobat Pro中的Preflight检查器在检查PDF / A兼容性时将引发错误。
因此/ Widths数组在技术上确实是多余的，因为可以从字体中检索相同的信息，但是对于某些应用程序来说，以更易于访问的形式获取信息非常方便，并且如果（以PDF格式）消费者），您希望匹配Acrobat的渲染，则需要使用它。