Ad

Our DNA is written in Swift
Jump

Radar: UITextView Ignores Font Kerning

While researching the root cause for the UITextView line-height bug I also found another difference between attributed strings rendered via CoreText and UITextView. The latter ignores font kerning.

UITextView uses Webkit for displaying attributed strings. Unfortunately Kerning is disabled on Webkit views unless you specify a certain CSS style.

Kerning in Browser

If you look at the AV characters you can see how the version with Kerning enabled has the AV seem at a more natural distance while the lower line has an uncomfortably wide distance between them.

In the Radar (which I filed under #12889869) I argue that when setting text on UITextView via setAttributedString we developers expect for Kerning to be on by default since this is the way that is closest to how CoreText renders it.

Summary

When setting an attributedText on a UITextView the text is rendered with Kerning disabled.

Steps to Reproduce

Create a simple attributed string, e.g. “AV” in Times New Roman with 50 px font size

Expected Results

When setting this attributed string on a UITextView it should display the text with Kerning, as is the default when rendering this text via CoreText. For the example “AV” the right bottom of the A is overlapping the left top of the V.

Actual Results

Letters do not overlap making the text harder to read. Especially if using UITextView to display a longer text for reading it is bad to have Kerning disabled.

Regression

Support for NSAttributedText is new as of iOS 6.

Notes

Internally UITextView converts the attributed string to HTML via NSHTMLWriter and then displays it in a UIWebDocumentView. The default mode for this is to have Kerning disabled.

It can be enabled by the CSS style, which is mentioned here.

text-rendering: optimizeLegibility;

Having this not be the default also confuses developer, as you can see on this question on stack overflow.

I propose that when text is set via setAttributedText on UITextView to make this setting the default since as a developer we would expect the output to match CoreText as closely as possible.


Categories: Bug Reports

2 Comments »