Minimum Rect to enclose a String

General
1

Given : W=rectangle Width S=string of text

I would have thought that to determine the HEIGHT of a rectangle necessary to enclose all text in S
it would simply be

H=g.StringHeight(s,w)
p=new picture(w,h,32)
p.graphics.drawstring s,0,g.textascent,width,false

Which DOES actually give the correct results in CARBON
but in COCOA the linespacing seems to be greater, thereby cutting off the bottom of the last line of text

Anyone else have this issue? Fixes? Workarounds? or file yet another bug report?

Left is COCOA Right is CARBON
EXACT SAME CODE

2

Isn’t there another property textheight. I seem to remember having these issues some time ago on cocoa. Can’t remember my fix I’ll have a look when I’m at my desktop

3

Can you post the link to the bug report?

4

Text Height IS being calculated the same for both Carbon and Cocoa…
As a matter of fact ALL the metrics (StringHeight, StringWidth, TextHeight etc) seem to be the same.
What is DIFFERENT, is the LINESPACING when the text is actually drawn

5

I wonder if this is related to <https://xojo.com/issue/30154> ?

6

Sorry to necro this thread, but it’s now nearly four years later, and I’ve just tripped over the same issue… StringHeight returned correct results in Carbon, but appears to return incorrect results in Cocoa, in ways I don’t see how to easily work around. It’s not just the line spacing; the return value is too short even for a single line of text (though it gets increasingly more wrong the more lines you have).

Has anybody found a suitable workaround for this?

7

I posted this originally way back when… don’t recall what project I was working on… or what I changed at the time (if anything)

however.
I just used this as a test
paint event of a canvas

		dim s as string="this is"+EndOfLine+"a"+EndOfLine+"test"
		dim x as integer =0
		dim y as integer = 0
		dim h as integer
		dim w as integer=g.width
		g.TextSize=24
		h=g.StringHeight(s,w)
		g.drawstring s,x,y+g.textascent,width,false
		g.ForeColor=&cff0000
		g.drawrect x,y,w,h

and the results looked correct to me,

8

I seem to recall that the problem occurs if the bottom line contains characters with descenders, eg. g, j, p, q, y.

9

This one is a pain - primarily because text area (NSTextView I believe) & labels (NSLabel I believe) use one set of code for their layout and graphics (CoreGraphics in this case) use another and they vary slightly in terms of measuring for kerning leading etc
So the subtle differences in the core OS API’s manifest themselves in this way in your code (which sucks)
If I recall there was no way to make them behave the same or to make NSText/NSLabel measure using the exact same mechanism as CoreGraphics and vice versa

Carbon was more consistent in this way as the controls just used the exact same underlying text layout mechanism so you got consistent results

Are you drawing something that uses a framing rect ?
It might be possible to use a label / text view, set the text, call a declare into sizeToFit and then ask the label /text view for its frame rect instead of using a graphics object
That way your measuring is done by the same layout engine

10

No, this one has nothing to do with NSTextView and NSLabel (though I’m sure there are other issues there). This is just a matter of getting g.StringHeight to match g.DrawString.

In some fonts (e.g. Arial), they do match; but in some common fonts like Helvetica and Times, they do not. If you try to use the StringWidth to draw a box around text drawn with DrawString in these fonts, it looks like this:

1212×634 67.7 KB

This makes it really hard to do things like lay out reports. I found it reported as https://xojo.com/issue/42768 from early 2016.