我正在尝试使用 XSL(XML-FO) 生成 PDF 以从数据库转换生成的 XML。
由于此文档的分页规则复杂，因此在我生成将由 XSL 使用的 XML 时，计算确定分页符。我注意到这些计算得到的结果不一致。例如，就高度而言，所需的打印区域为 9 英寸，然后我将其乘以 72（即每英寸 72 点）= 648 点将其转换为点。
因此，对于每一行，我使用 MeasureString 来获取行的高度，然后从 648 中减去该高度，以查看是否仍有可用空间来打印该行。但是，每当确定分页符时，底部都会留下一个很大的空白。好像 648pt 转换是错误的。现在我还担心 MeasureString 方法返回的高度也可能是错误的。
我为这篇冗长的帖子道歉，但我感谢任何关于我可能做错的输入/建议。
非常感谢！
我认为最大的问题是您使用 GDI 方法来测量将在 PDF 中显示的字符串。这还不够准确。（即使你得到相同的字体，它们使用的渲染技术与我记忆中的不同。）
所以，你应该尝试其他形式的计算。一个简单的第一步是估计每行的字符，然后估计每行的高度，因为它会出现在 PDF 中。然后，只需使用这些数字。一旦接近，您可以通过关注特定字符来改进估计技术。（您可能不想达到计算字距调整的水平。）
另一种技术可能是做一些我在过去项目中做过的事情。使用 iTextSharp，我们必须在页面上对角添加空心文本（作为一种水印）。由于文本未知，我们猜测原始字体大小。然后代码进入一个循环，它将测量渲染文本的大小，并向上或向下调整它，直到它恰好适合填充页面而不剪切任何文本。（所有这些猜测和测量都是使用 iTextSharp 完成的。）
我假设您MeasureString在类上使用方法方法System.Drawing.Graphics。您必须将PageUnit属性设置为GraphicsUnit.Point以点为单位进行测量。
XSL-FO 很可能不会以与 GDI+ 相同的方式呈现。特别是用于包装文本的算法会有所不同。
但是，假设这PageUnit是正确的，并且您有一个不涉及已包装文本的简单布局，您在估计由 XSL-FO 生成的 PDF 的大小时可能会忽略一些明显的事情。也许，您可以尝试以 1 英寸为间隔将页面大小从 1 英寸更改为 9 英寸。然后，您可以使用标尺测量多余的空白并尝试确定页面大小和多余空白之间的关系。然后，您应该重新检查您的代码，以找出您对文本大小的错误假设。
几年前我有一个非常相似的问题。
我在自己的项目中发现，使用旧的 Win32 gdi 函数进行文本度量（http://msdn.microsoft.com/en-us/library/dd144821(VS.85).aspx）通过P/调用。它返回的引用结果与 GDI+ MeasureString 不同。它们与 PDF 中的内容更加一致。