XSL（XML-FO）を使用してPDFを生成し、データベースから生成されたXMLを変換しようとしています。
このドキュメントのページングに関するルールは複雑であるため、XSLで使用されるXMLを生成するときに、ページ分割を決定する際に計算が行われます。これらの計算で一貫性のない結果が得られていることに気づきました。たとえば、高さの観点から必要な印刷領域は9インチで、これに72（1インチあたり72ポイント）=648ポイントを掛けてポイントに変換します。
したがって、すべての行について、MeasureStringを使用して行の高さを取得し、それを648から減算して、行を印刷するための使用可能なスペースがまだあるかどうかを確認します。ただし、ページ分割が決定されると、下部に大きな空白が残ります。648pt変換が間違っているかのようです。ここで、MeasureStringメソッドによって返される高さも間違っている可能性があることも心配しています。
長い投稿をお詫びしますが、私が間違っている可能性があることについての入力/提案に感謝します。
どうもありがとう！
最大の問題は、GDIメソッドを使用してPDFに表示される文字列を測定していることだと思います。それだけでは十分に正確ではありません。（同じフォントを使用しても、私が覚えているものとは異なるレンダリング手法を使用します。）
したがって、他の形式の計算を試す必要があります。簡単な最初のステップの1つは、1行あたりの文字数を見積もり、次に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で見られたものとはるかに一致していました。