UIFontのポイントサイズは正確に何ですか？
UIFontのポイントサイズの意味を正確に理解するのに苦労しています。ピクセルではなく、ポイントの標準的な定義ではないようです。つまり、1/72インチに関連しているということです。
さまざまなサイズの-[NSString sizeWithFont:]フォントを使用してピクセルサイズを計算し、以下を取得しました。
| Point Size | Pixel Size |
| ---------- | ---------- |
| 10.0 | 13.0 |
| 20.0 | 24.0 |
| 30.0 | 36.0 |
| 40.0 | 47.0 |
| 50.0 | 59.0 |
| 72.0 | 84.0 |
| 99.0 | 115.0 |
| 100.0 | 116.0 |
（[@"A" sizeWithFont:[UIFont systemFontOfSize:theSize]]をしました）
そして、72.0ポイントサイズを見ると、これはDPIが163のデバイス上にあるため1インチではないので、1インチは163.0ピクセルになります。
誰でもUIFont用語の「ポイント」が何であるかを説明できますか？つまり、上記の私の方法は間違っていますか？実際に何か他のものを使用すると、フォントに関する何かが72ポイントで163ピクセルであることがわかりますか？それとも、純粋にポイントが他の何かから定義されているのですか？
フォントには内部座標系があり、単位正方形と考えてください。その内部では、フォント内のすべてのグリフを収容する任意のサイズでグリフのベクトル座標が指定されます。
72.0ポイントでは、フォントの単位正方形は1インチです。グリフxフォントyは、この平方インチに関して任意のサイズを持ちます。したがって、フォントデザイナーは、他のフォントに比べて大きくまたは小さく見えるフォントを作成できます。これは、フォントの「文字」の一部です。
したがって、72ポイントで「A」を描画すると、同じフォントで36ポイントで描画された「A」の2倍の高さになり、実際のビットマップサイズがどうなるかはまったくわかりません。
すなわち、与えられたフォントについて、ポイントサイズとピクセルの関係を決定する唯一の方法は、それを測定することです。
-[NSString sizeWithFont:]が高さを測定する方法がわかりません。ラインの高さ、またはベジェのピーク間の差を使用していますか？どのテキストを使用しましたか？
-[UIFont lineHeight]の方が高さを測定した方が良いと思います。
編集：また、どの測定方法もサイズをピクセル単位で返さないことに注意してください。 pointsにサイズを返します。結果に[UIScreen mainScreen].scaleを掛ける必要があります。
フォントの作成時に使用されるtypographic pointsとiOSからのpointsdefault logical coordinate spaceの違いに注意してください。残念ながら、その違いはドキュメントではあまり明確に説明されていません。
UIレイアウトポイントが1インチあたり72で定義されているのに対し、これは[CSSピクセルが1インチあたり96で定義されている] [1]に関係があるのかと最初に思いました。 （もちろん、「インチ」は物理的なインチとは関係ありません。）なぜWeb標準がUIKitビジネスに影響するのでしょうか？デバッガーまたはクラッシュレポートでスタックトレースを調べると、UIWebViewを使用していない場合でも、多くのUIKitの基礎となるWebKitコードがあることがわかります。実際には、それはそれよりも簡単です。
最初に、フォントサイズは、最小のディセンダーから最大のアセンダーまで測定されます通常のラテン語のテキストで-- 「j」の下部から「k」の上部、または単一文字での便利な測定のために、「ƒ」の高さ。 （U + 0192「ラテン語小文字Fフック付き」は、US Macキーボードでoption-Fを使用して簡単に入力できます。人々は「フォルダ」を略して昔の略語を使用しました。）このスキームで測定すると、ピクセル単位の高さ（1xディスプレイ上）は、指定されたフォントサイズと一致します-例[UIFont systemFontOfSize:14]の場合、「ƒ」の高さは14ピクセルになります。 （大文字の「A」を測定すると、フォントサイズで測定されるスペースの任意の部分のみが考慮されます。この部分は、小さいフォントサイズで変化する可能性があります。フォントベクトルをピクセルにレンダリングする場合、「hinting」 ）
ただし、フォントには、そのメトリックで定義されたスペースに収まらないあらゆる種類のグリフが含まれています。東ヨーロッパの言語では、アセンダーの上に発音区別記号が付いた文字があり、「レイアウトボックス」に収まるすべての種類の句読点と特殊文字がはるかに大きくなっています。 （多くの例については、Mac OS Xの特殊文字ウィンドウの数学記号セクションを参照してください。）
-[NSString sizeWithFont:]によって返されるCGSizeでは、幅は文字列の特定の文字を考慮しますが、高さは行数のみを反映します。行の高さは、フォントで指定されるメトリックであり、フォントの最大文字を含む「レイアウトボックス」に関連しています。
これは非常に紛らわしいことに同意します。わかりやすくするために、ここで基本的な説明をします。
まず、DPI（1インチあたりのドット数）は、物理的な紙に印刷することに由来します。フォントも同様です。単位点は、通常のテキストサイズに対してインチが大きすぎるという理由だけで、テキストの物理的な印刷サイズを記述するために考案されました。それから人々は、テキストサイズを簡単に記述するために、ポイント、つまり1/72インチの長さ（実際には歴史の中で進化した）を発明しました。そのため、Wordまたは他のワードプロセッシングソフトウェアで文書を印刷用に作成している場合、72ptフォントを使用すると、1インチの高さのテキストを取得できます。
第二に、理論的なテキストの高さは通常、実際に目で見ることができるレンダリングされたストロークとは異なります。元のテキストの高さのアイデアは、印刷に使用される実際のグリフに由来していました。すべての文字は、フォントポイントの高さと一致する同じ高さを共有するグリフブロックに刻まれています。ただし、異なる文字や異なるフォントデザインによっては、テキストの実際に見える部分が理論的な高さより少し短くなる場合があります。 Helvetica Neueは実際には非常に標準的です。文字「k」の上部から文字「p」の下部までを測定すると、フォントの高さと一致します。
第三に、コンピューターのディスプレイがDPIを台無しにし、同時にポイントの定義を台無しにしました。コンピューターのディスプレイの解像度は、1024 x 768や1920 x 1080などのネイティブピクセルで表されます。実際、ソフトウェアはモニターの物理的なサイズを気にしません。 —物理的な解像度だけでは、すべてがスムーズで合法になるほど高くありません。ソフトウェアは非常にシンプルで行き詰まった方法を使用します。使用するモニターのDPIを修正しました。 Windowsの場合、96DPIです。 Macの場合、72DPIです。つまり、モニター上で1ピクセルが何ピクセルになっても、ソフトウェアはそれを無視します。オペレーティングシステムが72ptでテキストをレンダリングする場合、Windowsでは常に96px、Macでは72pxになります。 （だからこそ、Microsoft Word文書は常にMacで小さく見えるので、通常は125％にズームする必要があります。）
最後にiOSでは、iPhone、iPod touch、iPad、またはAppleウォッチ、iOSは非網膜スクリーンに固定72DPI、@ 2x網膜ディスプレイに144DPI、216DPIを使用しますiPhone 6 Plusで使用される@ 3x Retinaディスプレイ用。
本当のインチを忘れてください。実際の印刷時にのみ存在し、表示用ではありません。画面にテキストを表示するソフトウェアの場合、物理的なピクセルに対する人為的な比率にすぎません。
私が確認できた限り、真実はUIFontがあるということです。すべてのUIKitは、フォントに自由を取ります。真実が必要な場合は、CoreTextを使用する必要がありますが、多くの場合、遅くなります！ （だからあなたのピクセル高さテーブルの場合、それはxがポイントサイズである種のa + bx係数を追加することだったと思う。
なぜこれを行うのですか？速度！ UIKitは、ビットマップをキャッシュできるように、スペースとフィドルを切り上げます。または、少なくともそれは私の持ち帰りでした！