Ad

Our DNA is written in Swift
Jump

Radar: UITextView Ignores Minimum/Maximum Line Height in Attributed String

I’m working on making DTCoreText iOS 6 compatible and when implementing line heights I found this problem. Naturally I filed a radar.

This is one of many shortcomings of UIKit’s support for attributed strings. A workaround for this was described as having to omit font attributes from the attributed string. So you can either have multiple fonts and unchanging line height or only the font you set on the font property of UITextView.

Other people are having the same problem, as outlined by this question on StackOverflow.

Filed as rdar://12863734

Summary

If an attributed string contains both a font attribute as well as a paragraph style attribute that sets minimum/maximum line height those line height constraints are ignored.

Steps to Reproduce

Create an attributed string that contains a font and paragraph style attribute. Make sure the paragraph style attribute sets a minimum and maximum line height that is less than the font line height.
Set this attributed string on a UITextView’s attributedString property.

Expected Results

The lines should be spaced by the amount of the specified minimum/maximum.

Actual Results

The lines are spaced as they would be without the paragraph style settings.

Regression

UITextView only supports attributed strings since iOS 6. Since then this is broken.

Notes

The problem seems to result if you have multiple different fonts, like when you have some bold or italic text in the string.


Apple engineering asked for a sample app which I provided to them: minmaxlineheightbug.zip.

I also added those further findings:

I have attached a sample app that demonstrates the problem. Launch it and you see a selector at the top which sets the text view to a version with and without a font attribute.

For your convenience I did further research and found that the bug lies with NSHTMLWriter. You can see the two kinds of output in the lower text view, they only differ on the p.p1.

Compare the output for p.p1 (the first paragraph) for the version WITHOUT font:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 40.0px}

and WITH font:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 40.0px; font: 14.0px Helvetica}

The bug here is easy to miss, I also had to look up the font CSS shorthand.

The font shorthand sets BOTH the font-size as well as the line-height thus overruling the 40px. This is true both for UIWebView as well as Safari.

WORKAROUNDS:

If you change the order of items in p.p1, then it works:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica;line-height: 40.0px;}

Alternatively you can dispense with the font short hand and spell out all items, that works as well:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 40.0px;font-size:14px;font-family:Helvetica;}

Categories: Bug Reports

4 Comments »

  1. Very clever research!! I hope this problem will get some attention. It is the only thing stopping me from ditching web views.

  2. Hi, The bug seems to be resolved in iOS7 however when I change the lineheight property like this
    paragraphStyle.minimumLineHeight = 10.f;
    paragraphStyle.maximumLineHeight = 10.f;
    paragraphStyle.lineSpacing = 10;

    The cursor looks funny! eight I can’t get the values right or there is now a different bug!, I would like to know how I can resolve the issue even if its just for iOS7

Trackbacks

  1. Radar: UITextView Ignores Font Kerning | Cocoanetics