NSStringDrawingOptions.usesFontLeading不生效？其实际作用是什么？

Hey there! Let's unpack what's happening with that usesFontLeading option and why your tests aren't showing the expected results.

First, What Does usesFontLeading Actually Do? #

To start, let's clarify what "font leading" means: it's the extra vertical spacing font designers build into a font to create gaps between lines of text (think of it as the space between the bottom of one line's descenders and the top of the next line's ascenders).

The usesFontLeading option tells boundingRect(with:options:attributes:context:) to include this built-in leading when calculating the total height of your text block. Without it, the method calculates line heights using only the font's core vertical metrics (from ascender to descender) instead of the full line height that includes the leading.

Why You Didn't See a Change When Removing It #

Chances are, you were testing with single-line text—that's the key issue here. If your text doesn't wrap to multiple lines, there's no vertical spacing between lines to apply the leading to. The total height will be identical whether you include usesFontLeading or not, since there's only one line to measure.

Even with multi-line text, Apple's system fonts have very small built-in leading (often just 1-2 points for standard sizes). The height difference might be so subtle you don't notice it at first—try printing the calculated frame heights to spot the tiny numerical gap.

Why Using Only usesFontLeading Causes Weird Results #

The usesFontLeading option isn't meant to be used alone. It works as a supplement to usesLineFragmentOrigin, the critical option that tells the method to calculate text layout as multi-line, left-to-right, top-to-bottom (standard paragraph layout).

Without usesLineFragmentOrigin, the method defaults to single-line layout logic, and adding usesFontLeading breaks the baseline calculation—hence the abnormal results you saw. These two options are almost always paired together for wrapped text calculations.

Fixes and Next Steps to Test Properly #

1. Test with multi-line text: Use a long string that wraps into 2+ lines within your constrained width. This lets you see the cumulative effect of leading across lines.
2. Always pair usesFontLeading with usesLineFragmentOrigin: This is the correct combination for multi-line text layout calculations.
3. Try a font with larger leading: To make the difference obvious, use a custom font with generous built-in leading. You'll immediately see a bigger gap between total heights with and without the option.

Here's a quick test snippet to demonstrate:

let longMessage = "This is a sample multi-line text that will wrap across several lines when constrained to a narrow width. Using usesFontLeading should add a small amount of extra vertical space between each line."
let constrainedSize = CGSize(width: 220, height: CGFloat.greatestFiniteMagnitude)
let font = UIFont.systemFont(ofSize: 18)

// Correct combination: both options
let combinedOptions = NSStringDrawingOptions.usesLineFragmentOrigin.union(.usesFontLeading)
let frameWithLeading = NSString(string: longMessage).boundingRect(
    with: constrainedSize,
    options: combinedOptions,
    attributes: [NSFontAttributeName: font],
    context: nil
)

// Only usesLineFragmentOrigin
let noLeadingOptions = NSStringDrawingOptions.usesLineFragmentOrigin
let frameWithoutLeading = NSString(string: longMessage).boundingRect(
    with: constrainedSize,
    options: noLeadingOptions,
    attributes: [NSFontAttributeName: font],
    context: nil
)

print("Height with leading: \(frameWithLeading.height)")
print("Height without leading: \(frameWithoutLeading.height)")

Run this, and you'll see a small but measurable difference in total heights—this is usesFontLeading doing its job.

内容的提问来源于stack exchange，提问作者Ninja