Question

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.

Answer 1

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:

1. create an attributed string of the text in the main view, having set the appropriate font across the entire range;
2. create a suitable framesetter for the attributed string (using CTFramesetterCreateWithAttributedString);
3. create a 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);
4. hence create a frame from the framesetter plus the path plus the subrange of the string you’re interested in, which will likely be all of it (see CTFramesetterCreateFrame);
5. from the frame you can then obtain a CFArray of the individual lines it would output (using CTFrameGetLines), though these are the on-screen typeset lines rather than your source lines;
6. for each line you can get the range of the original string that it contains (using CTLineGetStringRange), allowing you to determine which begin immediately after your original newline characters rather than due to word wrap;
7. you can also get a C array of CGPoints 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.