Graphics.TextHeight

Syntec

Graphics.TextHeight does not report the correct height of the text.

g.FontName = "Inter"
g.FontSize = 12.0
g.TextHeight("[",0) #Or g.TextHeight("[",100") same result
g.DrawText("[",0,0)

g.TextHeight returns 14.51953125 but g.DrawText draws text that is actually around 11 pixels tall (could be plus minus 0.5 px)

Syntec

Syntec To add to this g.TextWidth does not handle white space at the beginning or end of a string. It makes it difficult to track a caret on a custom canvas based textfield without using a monospace font (we can substitute spaces with any character to get the caret position). I have also tried to replace spaces with non-breaking spaces but that didn't work. I am pretty sure this is the expected behaviour, I will handle white space by calculating its width and adding it where appropriate. I was just wondering if there was an easier way 🙂

Garry

Thanks for reporting this. There were two different measurement concepts involved here.

Graphics.TextWidth did contain a bug: it was using a backend measurement that deliberately excluded trailing whitespace. I’ve fixed that for the next Studio release: https://feedback.objo.dev/bug/1136

TextWidth will now include leading and trailing spaces, strings consisting entirely of spaces, and trailing non-breaking spaces. Measuring the text prefix before a caret should therefore work without substituting another character.

Graphics.TextHeight is behaving correctly, but the documentation was unclear. It returns the text’s line-layout height, including the font ascent, descent and line spacing, not just the height of the visible glyph pixels. Consequently, a [ glyph may visibly occupy about 11 pixels while its Inter 12 line box is approximately 14.52 pixels tall. This line-box measurement is what DrawText uses for layout. A wrap width of 0 and 100 produces the same height here because the single character does not wrap.

I’ve clarified the documentation (will update when the next build is released).

Syntec

Garry Hey Gary, totally understand thanks for the clarification, in trying to experiment with text drawing I believe I found another bug, I can write a new post but it I will share it here so I don't clutter up the feed.

Window1 has a canvas1 control and the following code is in the paint event of the canvas (200 x 200 sized canvas)

g.DrawingColour = Colour.RGB(255,255,255)

g.FontName = "Inter"
g.FontSize = 12.0
g.TextAlignment = TextAlignment.Centre
g.VerticalTextAlignment = TextAlignment.Middle

g.DrawText("test",0,0,Me.Width,Me.Height)

The expected result is test centred in the 200x200 canvas, actual result is no visible text. This is because me.width and me.height are incorrectly reporting the window width and height (800x600).

Looking at example code if we have a button and in the pressed event me.width reports correctly so this appears to be a canvas bug with the paint event, is the parent window calling the underlying code of canvas.Paint event and therefore taking ownership of the canvas calls?

If the above code is in a custom canvas class, me.width and me.height report correctly.

Garry

The Canvas Me binding was another genuine bug: inside a Window-owned Canvas1 Paint handler, Me was incorrectly resolving to the Window (the handler's bound subscriber) instead of the Canvas. It's fixed now in the next release: https://feedback.objo.dev/bug/1141

Me now correctly refers to the Canvas that fired Paint, so Me.Width/Me.Height reports the Canvas's dimensions and g.DrawText("test", 0, 0, Me.Width, Me.Height) lays centred text out inside the Canvas.

Self refers to the containing Window (the subscriber that owns the handler), so Self.Width/Self.Height report the Window.

g.Width and g.Height remain the direct, immediate paint-surface dimensions and are the simplest way to size drawing to the Canvas.

Syntec

Garry I am oblivious, I have no idea why in the world I was doing Me.Width and Me.Height... but hey I found a bug no one else may have!