This is a feature request and an inquiry. If I understand correctly -cellBaselineOffset is being ifdef’d out for iOS. We’re trying to make it work.
There’s a situation where some text must appear after a certain glyph and both must be kept together. That calls for a rectangular attachment cell. With current implementation in OUITextLayout et al. the cell is put on the baseline. If we simply shift the drawn frame downwards, part of the cell could be drawn out of the bounds of the view because the shift is unexpected by current code. So I think if -cellBaselineOffset is available things can be easier.
We’re experimenting with a somehow working patch so please advise if that’s the way to go.
I would expect that the Y component of -cellBaselineOffset should be used to shift or extend the values returned by our getAscent and getDescent functions in CTRunDelegateCallbacks (we don't have getDescent right now, so it is always zero).
This should (hopefully) be all that is needed to let CoreText adjust its layout to include space for the descent of the attachment. Some trickery may be possible to support the X component of -cellBaselineOffset, but we've never found that particularly useful on the Mac, even.
As an aside, this may be how we need to implement synthesized superscript, subscript, and of course the simple baseline adjust style attributes for text.
Pushed the in-progress patch to a branch on our fork, that supports baseline offset (currently Y only).
WIP: supporting vertical -cellBaselineOffset for OATextAttachmentCell
updates _logLines() so it works with iOS