Re: NSAttributedString + NSLayoutManager versus Core Text


Quincey Morris
 

On Nov 22, 2019, at 17:28 , Graham Cox <graham@...> wrote:

NSTextContainer has a property called lineFragmentPadding. For some inexplicable reason, this value defaults to 5, rather than 0. Why 5 would be what you want I can’t think, but setting it to 0 solves my problem.

I don’t know exactly *which* typographic problem is intended to be solved by line fragment padding, but the most likely one is that various letters may extend outside their layout boxes. The layout box starts at the glyph origin on the left, and extends the distance of the advance width on the right. Layout proceeds by placing glyphs layout boxes side by side. Note that the layout box is only loosely related to the glyph bounding box.

That works fine if the glyph’s bounding box lies within the layout box, but some glyphs extend outside their layout box. (A typical example is “j” or “J”, which will have a similar advance width to “i” or “I”, but the hook can extend quite a way to the left.)

Within a line, that still works fine, because the glyph extension simply draws over an adjacent glyph's layout box. However, at the ends of the line, there is usually clipping to an enclosing text frame, and that results in bits of glyphs sometimes being clipped away.

“lineFragmentPadding” solves the problem by leaving space at the ends of the lines for glyphs to overflow into. Setting it to 0 isn’t a terrible thing to do, but will occasionally cause unsightly clipping. Maybe a better solution would be to fetch the value and use it in your overbar placement.

Join cocoa@apple-dev.groups.io to automatically receive all group messages.