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://10810114
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).
UPDATE: This is a duplicate of rdar://9931615.
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
扫一扫
2376
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
