I'm trying to solve this problem for a week now and I have tested a lot of ideas that I had on my mind but I'm unable to properly calculate size of the NSString
with custom font.
I have UITextView
which contains text and one UIView
on which I draw line numbers for the lines in UITextView
. The problem is that NSString
UIKit
Additions are ignoring tab width in calculation of size of the NSString
.
Here on picture you can see that clearly on line 7, which is line with line break when rendered in UITextView
, and after that all lines are affected.
Font that I'm using is Adobe Source Code Pro.
I have tried all methods from NSString
UIKit
Additions without success.
sizeWithFont
sizeWithFont:forWidth:lineBreakMode:
sizeWithFont:minFontSize:actualFontSize:forWidth:lineBreakMode:
I have also tried to replace all tabs in string with four spaces, it helps, but still it doesn't work all the time. For some lines it helps but for some it doesn't.
Any suggestions how to calculate NSString
height properly? CoreText
maybe?
One small note. I have tried to solve this also with using Geometry hit testing methods from UITextInput
Protocol and while they are working, cpu load is 100% on simulator, so on real device it's going to kill the app, specially if I load file that is about 1500+ lines of code.
And here is the gist with code that I'm using for LineNumbersView.m.
Assuming UITextView
and Core Text always exactly agree then the latter is definitely a solution, though it's not desperately straightforward for this problem.
You'd:
CTFramesetterCreateWithAttributedString
);CGPath
that describes the drawing area that the string will be drawn to (either as a UIBezierPath
and then getting the CGPath property or by creating one and using CGPathAddRect
);CTFramesetterCreateFrame
);CFArray
of the individual lines it would output (using CTFrameGetLines
), though these are the on-screen typeset lines rather than your source lines;CTLineGetStringRange
), allowing you to determine which begin immediately after your original newline characters rather than due to word wrap;CGPoint
s where each represents the origin of an on-screen line (CTFrameGetLineOrigins
); by using what you learn in (6) to look up positions in that you can get the on-screen origins of the relevant lines.For added fun, the pixel output of Core Text is identical on OS X and on iOS. However OS X considers the screen's original to be the lower left corner, like graph paper. iOS considers it to the top left corner, like English reading order. The roughly worded net effect is that on iOS Core Text draws upside down. So you'll need to take that into account. In iOS terms you'll apparently see the first line as being at the very bottom of your frame, the second as being one line above that, etc. You'll need to flip those coordinates.
It'll probably end up being just a hundred or so lines of code even though you're jumping through so many hoops.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With