How to make a Text to be align centered vertically ?

[Nzhan.15]

Assuming the height of the drawable object is H (getHeight()), and the height of text is TH (getTextHeight()), how to figure out the correct y value of the text object ??

I tried (getHeight() - text.getTextHeight() - text.getTypedText().getFont->getSpacingAbove()) / 2 and (getHeight() - text.getTextHeight() ) / 2, neither of them is right.

[sasha]

Hi, I am also trying to achieve vertical text centering. Did you get this working? I can't get this line of code to compile:

text.getTypedText().getFont()->getSpacingAbove() + text.getTypedText().getFont()->getMaxTextHeight()

I get these errors:

'no matching function for call to 'touchgfx::Font::getSpacingAbove() const'

'no matching function for call to 'touchgfx::Font::getMaxTextHeight() const'

I have included Font.hpp, but this function is declared as Virtual and there seems to be no other implementation.

How did you get this working? I'm sure I'm missing something obvious here...

[scottSD]

I am not sure if you still need this as your post is 2 months old, but the functions getSpacingAbove() and getMaxTextheight() require text to be passed to them. I casted some characters to const Unicode::UnicodeChar* and the compiler did not complain:

 int spacingAbove = text.getTypedText().getFont()->getSpacingAbove((const Unicode::UnicodeChar*)"TEXT");

 int maxHeight = text.getTypedText().getFont()->getMaxTextHeight((const Unicode::UnicodeChar*)"TEXT");

[scottSD]

I have not received an answer to this question. I would like to reduce the text area to the actual text size only to reduce the invalidated rectangle which will improve performance.

@Martin KJELDSEN​ Will using a custom font that has no padding above the characters do this for me?

[Martin KJELDSEN]

Hi @scottSD​,

No, it's not a font issue. It's an "issue" with the TextArea widget where it invalidates the entire area of the area and not just the area that contains the text. I may have a look at creating this enhanced widget. I think during original design we didn't anyone would create areas larger than the text (hence the .resizeToCurrentText() function).

But, it actually makes good sense to use the TextArea dimensions as a positional tool.

/Martin

[scottSD]

@Martin KJELDSEN​ Thanks for your reply. Hope all is well with you in this crazy world right now.

I would really like the enhanced widget. In my application, I am striving for even the smallest improvement in animations. I will have a large digital gauge which can change often. When it changes, the large text area is invalidated and not just the text. I know there is some space above the text as the font function getSpacingAbove() is saying as much--this is why I think it is a FONT issue. This area is invalidated along with the actual text even though that area of the frame buffer is not changing.

As shown in my post above, when I attempt to bring the top of the text area down, it drops the text and clips it off. This is why I thought it was a FONT issue. Apparently not? It is my thought that if the Designer would have a "center vertically", it would take care of the problem.

I have found a work around for this, but an improvement to the widget would be much appreciated.

My workaround is to place the text area in a container with the top of the container coming down to just above the actual text (not the text area) . This essentially clips/crops the text area so that only the text is invalidated when it changes. This has improved performance and is a workable solution. But anything you can do to enhance the widget would be great.

[Martin KJELDSEN]

Hi @scottSD​,

Thanks, man! Hope everything is OK with you too. Let's just say things are c-r-a-z-y around here (i have two kids at home), but we're getting into the rhythm of things.

Well, it shouldn't be a font issue, but it could be. My immediate thought was just "no". But it would be highly unlikely that glyphs in a font would be constructed in that way, especially since they're latin characters. If you still have this issue after calling resizeToCurrentText() then you do have a font problem.

Using a container as a view-port is clever, in this case :) (Paying a small price with RAM).