Radar: “CoreText Line Spacing Bug”
No frills, just the latest news from hundreds of the best sources.
Radar: “CoreText Line Spacing Bug”
Feb 5, 2012 10:34 am
I finally got around to report an annoying bug in CoreText that has been bugging us in DTCoreText until I wrote a method to correct line origins as a workaround. rdar: rdar://0810114 The annoying thing about this bug is that it adds visual noise to otherwise pristinely rendered text. Especially on larger font sizes you see that additional space appears before each CTLine that ends with a paragraph break (\n). Label Buy an ad here Readability CoreText Line Spacing Bug Summary CoreText inserts too much space before any line that ends with a \n. This extra space depends on the font and font size. On large print this causes visual noise by not being uniform. Steps to Reproduce Create a CTFrame from a CTFrameSetter with a string that is long enough to wrap and that contains paragraph breaks. Use a non-UI font, like for example AriaMT. Expected Results Line origins should be spaced by exactly the same distance for identical text and identical attributes. Actual Results Each line that ends with a paragraph break is shifted down. With the system UI font, size 54 baselines are spaced exactly 64 pixels apart. With ArialMT, size 54, baseline spacing differs between 62 and 65. Regression This has been a bug since before iOS 4.3. Notes This does not occur with all fonts, Using a system font the spacing is precisely correct. I have attached a project to demonstrate the issue. See TextView.m. It appears that the text metrics for an (invisible) paragraph glyph are miscalculated. Since the glyph is not visible you’d expect neither and ascender nor descender value. But instead the descender is too large. If you walk through the entire line and get the maximum ascenders and descenders the value is correct if you omit the \n in this calculation. In short: A trailing \n messes up the font metrics for the entire CTLine. Attachment: CoreTextLineOrigins Demo Project