当你其实有这个字体

上次我们写了字体缺失时会发生什么。Publisher 悄悄挑一个替代字体，每个字的宽度都变了，页面就自己重排了。

这篇是同一件事的另一半。很多时候字体根本不缺。那就是一个普通的 Windows 字体，文档理所当然会用它。问题出在我们这边：我们的转换器没认出它，于是用替代字体去量文字，页面照样跑位。

这个月，这一块好了很多。

认出字体，就是大半的活

我们的转换器现在能认出的字体范围比以前宽得多，也就是真实 Publisher 文档实际会用到的那些。认出之后，它按这些字体自己的字符宽度和行高来排版，而不是拿一个差不多的去凑。

听起来是个小差别，其实不是。字符宽度决定一行能放下几个词。行高决定行与行之间隔多远。两个都取自真正的字体，段落就在 Publisher 断行的地方断行，栏就在 Publisher 结束的地方结束，下面的页面也不会跑。取自替代字体，第一行以下的所有东西就会一行比一行偏得更多。

所以这次的收获不是"猜得更准了"，而是"需要猜的次数少多了"。

一个文件，前后对比

上线当天我们拿一份真实文档核对过。一张教会明信片，普通正文，没有任何特别的地方。

旧的输出把那段正文排成了粗斜体。不是稍微重一点，是从头到尾的粗斜体，而 Publisher 在这张卡片上排的是常规体。看起来像样式出了 bug，其实不是。转换器一认出这张卡片真正要的字体，正文就以正确的字重排成常规体，跟 Publisher 自己导出的 PDF 对上了。

一次诚实的更正

在量这件事的过程中，我们发现自己把问题说大了。

我们的统计说，字体没认出来解释了某个困难档位文件差距的大约 18%。仔细一看，我们的测量工具每份文档只记录一个字体，而不是这份文档用到的全部字体。修好工具之后，真实数字降到 9% 上下。这个活仍然值得做，我们也做了。但它只有我们自己说的一半大，而我们内部发布的那个数字是错的。

与其悄悄翻篇，我们更愿意在这里更正。

如果你有这个字体

上个月的建议不变。PDF 导出会把我们解析出来的字体嵌进去，所以 PDF 发到哪里都没问题。Word 和 IDML 的话，先在你自己的机器上装好字体，然后把文字的原始字体名改回来。Word 和 InDesign 会重新连到真正的字体，页面就按当初设计的样子重排。

关于换一个字体为什么会推动整页，见行为什么在那里换行。

有用了少见字体的文件吗？免费预览一下。