Maybe I am doing something wrong. But it seems that the g.StringWidth and g.StringHeight are doing some weird things.
The string height does not seem to be correct, somehow. And I can’t wrap my head around the problem.
I created a simple app to demonstrate the problem.
The demo app can be found here
The funny thing is, that if there is only one character to display, the correct heights are displayed. As soon as I change the text, the StringHeight doubles…
What am I doing wrong???
Or is it simply a bug 
I might end up doing the calculations for StringHeight myself.
The TextHeight function actually does seem to work, as I used it to draw the baseline lines.
I used t.CountFields( chr(13) ) to count the number of lines.
I multiplied it with the TextHeight to calculate the Y positions of the base line.
Using this method I can calculate the stringheight myself. But what I wanted to say is that I find it quite weird that the build in method gives me the incorrect values.
Make the second line a bit shorter and your method will show the right bounds, not only if one character is present. Your text is too long so that it breaks and appends a blank third line I have no clue why currently. Is the EOL at the end of the string a part of the string length calculation?
Yeah, I noticed that, too.
When calculating the StringHeight I added 1 to the StringWidth. That seemed to stop the auto-linebreaking problem.
You think it might be bug?
Apparently not. Try my demo app. When typing the EOL doesn’t change the box around the text
I think its rather a weirdness in the typesetting algorithm, but I am completely unsure.
Another piece of fun? Remove the trim and insert a return after the second line. Now it can be as long as it wants and the bounds are ok 
Ha, you beat me to it!
I just tried that. And the EOLs appear. But by adding the StringWith with 1 pixel still puzzles me. Seems a 0-based or 1-based width problem.
[quote=295159:@Ulrich Bogun]Try this:
g.DrawString t, x, y + g.TextAscent+g.TextHeight
Why do I want to add the g.TextHeight to the g.TextAscent? Doesn’t that move the text too far down?
Adding one pixel seemed to fix the problem. And that might be a bug… and that’s what I find weird 
Sorry, I had it wrong and didnt see the extra line at the top. After looking a bit more at it, I wonder if the wrap algorithm is ok? It looks to me like whenever the last line exceeds the previous length, the wrapping algorithm adds an invisible new line. I am still uncertain about this but I think it would be worth filing a bug report. Playing with WrapWidth didnt help (and without one it is supposed not to wrap anyway.)
Good you found a workaround!
As a matter of fact, I just did. I updated the demo app a little, and attached it to the Bug Report. It’s case #45644 