最初の問題: 400 ピクセルの幅があり、その制約内にテキストをできるだけ大きく収める必要があります (したがって、テキストはその量のスペースを使用する必要があります)。
新しい制約を導入します。テキストが単に「A」の場合、高さ 100 ピクセル (または特定のフォント サイズ) を超えてズームしてはなりません。
次に、最終的な状況: 改行。たとえば、400 x 150 ピクセル内に可能な限り大きな方法でいくつかのテキストを合わせます。
明らかな方法は、ポイント 1 から始めて、それ以上収まらなくなるまで増やすことです。これは 3 つの問題すべてに有効ですが、非常に粗雑です。境界内の単一行のフィッティングは、固定小数点サイズで記述し、結果のテキストのピクセル境界を確認し、変換で単純にスケーリングすることで実行できます (テキストも適切にスケーリングされます。 TransformUIを確認してください)。
これを攻撃する他の方法のアイデアは大歓迎です!
モデリングする内容は複雑であり、特に改行があるため、すべてのサイズを試すという最初の提案は、特に正確である必要がある場合は、正しい線に沿っています。
ただし、各値をテストするのではなく、バイナリ検索を使用して適切なフォントサイズを見つけることができます。サイズは1から100（上限範囲）の間です。バイナリ検索を使用して、各テストはフォントサイズを設定し、結果のレイアウトをチェックします。テキストが大きすぎる場合は、現在可能な値の範囲の下半分を検索します。フォントサイズが収まる場合は、上半分を検索します。検索では最大7回の試行（100ログベース2を切り上げ）が使用され、正確で、超えずに最大サイズが検出されます。フォントの組み合わせなど、後で要件を追加する必要がある場合は柔軟になります。またはレイアウトに対するより厳しい制約。
行の折り返しを行うテキストコンポーネントを使用していて、最大幅を400に設定できると想定しています。したがって、フォントサイズを設定すると、必要な高さを返すレイアウトが行われ、テキストが与えられた幅。
ヒントを使用して、最初の推測を予想サイズに近づけるなど、アルゴリズムを結果にすばやく導くことができますが、テキストレンダリングは高速であるため、パフォーマンスの向上は実装作業の価値がない可能性があります。
ウィキペディア-二分探索アルゴリズムを参照してください
希望する最大サイズでインスタンス化しますFont。たとえば、72dpiの1インチのグリフの場合は72です。アスペクト比を維持しながら、（直接）または（オフスクリーン）を使用TextLayoutして境界とスケールを取得するために使用します。適切なヘルプも。AffineTransformAffineTransformOpRenderingHints
私は次のことをします：
Wピクセル幅のテキストが必要だとします。
たとえば10pt、任意のサイズを選択し、そのサイズに対してテキスト文字列が取得する境界ボックスを確認します。Nピクセル幅になるとしましょう。
新しいサイズを に設定し10pt * W/N、適切なしきい値内になるまで手順 1 から繰り返します。（うまくいけば、1回の繰り返しでうまくいくでしょう。）
これは、文字列の幅がフォントのサイズにほぼ比例するという事実に依存しています。