C++ 用C+测量postscript字体宽度+；

这不可能这么难，但我就是做不到。谷歌、stackoverflow或ubuntu或ghostscript的文档都没有帮助

我从C++生成PASScript。我逐字放置文本以处理换行。为了决定下一个单词的位置以及它是否适合当前行，我依靠freetype来测量每个字形的“前进”

文本是普通文本和源代码的混合体，因此我使用了两种字体。我选择Helvetica作为普通文本，选择Courier作为源代码，因为两者都可以在postscript中使用，并且不需要嵌入。postscript输出中有问题的部分并不比

(Helvetica) findfont 11 scalefont setfont
40 100 moveto (hello world) show
123 100 moveto (hello again) show   % I care for the first number

当然，有一个适当的eps标题等

我没有在我的ubuntu 16.04系统上找到字体文件，所以我从免费字体网站下载了最佳猜测。事实证明，它们显然与我的postscript解释器使用的不同。至少，在使用

epstopdf

转换为PDF（据我所知，这是LaTeX附带的）后，我发现我的Helvetica字体太宽，Courier字体太窄，因此单词间距变小，以至于长单词与后续单词重叠

我的问题：如何获得与postscript解释器匹配的字体宽度测量值？

• 我甚至不确定这个问题是否提出得很好，但不知何故，我确实假设有一种且只有一种参考Helvetica字体，因此postscript输出在所有系统和打印机上看起来都是相同的
• 让freetype加载正确的字体可能是最简单的解决方案，但我不知道如何找到文件
• 下载完全匹配的字体的源代码也可以解决这个问题，尽管两次下载会很奇怪
• 更好的是，向像ghostscript这样的postscript解释器询问基本事实会更好，但ghostscript库文档非常稀少，我没有找到任何示例
• 我可以创建一个postscript文件，打印通过

  textwidth

  获得的文本宽度，转换为pdf格式，然后提取文本。这将是丑陋和缓慢的，我想去一个适当的C++解决方案。

---

在以上任何一个方面或其他方面取得进展都将是绝对伟大的

您使用的字体应该有一个.afm（Adobe字体度量）文件，如果它是PostScript字体，您可以从读取字体度量。同样，在所有PostScript实现中，“基本13”字体在度量方面应该是相同的。当然，如果您使用的是TrueType字体来获取度量，那么它们可能与PostScript字体不同

你还没有说你使用的PostScript解释器是什么，可能是因为它没有使用标准字体，但我猜你使用的是Ubuntu中的TrueType字体，它与你在“解释器”中使用的PostScript字体不太匹配。如果内存可用，您可以在/etc/fonts/fonts.conf中查看字体的存储位置

FWIW Ghostscript附带了与Adobe字体匹配的基本13种字体的实现，PostScript解释器应该与这些字体匹配。但是，我们不提供AFM文件，但您可以将字体加载到Fontographer中，或者使用FreeType，或者只需在PostScript程序中使用stringwidth（而不是textwidth）即可获得高级宽度

我不会说Ghostscript的文档是“稀疏的”。也许很难找到你想要的，但是那里有很多文档。基本信息Just use.htm是一个265Kb的HTML文件

---

当然，最后一种选择是下载您在PostScript程序中实际使用的字体，然后您就知道它们与您最初创建PostScript时使用的度量相匹配。与PDF一样，这是非常推荐的，特别是对于13号基座以外的字体，因为它是唯一可靠的输出方式。

如果你用C++编码，不要问C——它们是（根本上）不同的语言，特别是C++ 17和C11（C18）。@ Jonathan Leffler：要点。我提到C是因为我希望C库可以帮助我。在这方面，我发现“根本性的”争论：当然，图书馆的主题是：D——C和C++的部分是常见的，但是习惯的现代C++与习惯化的现代C完全不同（完全和彻底地）。你可以“去掉”到GHOSTScript并运行一个小PS程序并解析结果。Sthg如

/Helvetica 24选择font 0 0 moveto（my string）stringwidth pop=

。请反对者留下评论解释他们的理由好吗？我真的很想知道这个问题有什么不对。解决这个案子让我的头发有点灰白。非常感谢你的详细回复。我的翻译是“epstopdf”，我相信这是鬼魂脚本。我在我的系统上检查了.afm文件，发现了Helvetica.afm的三个（相同）副本，所有这些似乎都是matplotlib附带的。好消息是，它们很容易解析，甚至是人类可读的，并且标题声明它们是由Adobe制作的。快速检查显示，这些指标与freetype给我的有很大的不同。我将继续这条路线。我终于按照你的建议解决了我的问题，再次感谢你。首先，我解析了.afm文件，包括使用Adobe的AGL将字形名称转换为unicode。出于某种原因，.afm文件在大多数情况下运行良好，但在少数情况下它是非常错误的，比如负号。最后，我使用PostScript的show编写了一个小脚本，将stringwidth转换为字符串，应用于整个字符范围。我将文件转换为pdf格式，并通过从查看器中复制和粘贴的方式获取数字。不是一个好的解决方案，而是一个正确的结果。