You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The getTextBounds returns the smallest rectangle encompassing the set pixels of a text string to be displayed using the current font.
I experience 2 issues with this approach:
Determining this is somewhat expensive
This is not very suitable for doing right-aligned text (see below)
There are some glyphs that don't have any pixels set in the right part of the glyph's bounding box, while others of the same class have. Notably the digit '1' is much narrower than other digits and doesn't fill the whole bounding box in horizontal direction. When the getTextBounds function is used to right-align a multi-digit number, the number 'jumps' a bit when the last digit changes between '1' and another digit, even if the font has same width boxes assigned for all digits. Of course one could use another numeric string (that doesn't end with '1') to determine the width of the displayed number, but I would say that is an ugly kludge.
I think it would be better for such alignment use of the function, if it would return at least the extends of the bounding boxes (xAdvance). This would sometimes lead to a slightly larger bounds rectangle than strictly needed, but it would make the function also suitable for such alignment use.
Of course any pixels beyond the xAdvance/yAdvance box must be included too. Only for the far left and far right (far top and far bottom) glyphs, the pixels outside the bounding box need accounting for. For 'internal' characters, only the xAdvance (yAdvance) needs to be taken into account. This could make the function less expensive.
Note that the above experience is for proportional fonts (gfxFont, non-monospace).
The text was updated successfully, but these errors were encountered:
The getTextBounds returns the smallest rectangle encompassing the set pixels of a text string to be displayed using the current font.
I experience 2 issues with this approach:
There are some glyphs that don't have any pixels set in the right part of the glyph's bounding box, while others of the same class have. Notably the digit '1' is much narrower than other digits and doesn't fill the whole bounding box in horizontal direction. When the getTextBounds function is used to right-align a multi-digit number, the number 'jumps' a bit when the last digit changes between '1' and another digit, even if the font has same width boxes assigned for all digits. Of course one could use another numeric string (that doesn't end with '1') to determine the width of the displayed number, but I would say that is an ugly kludge.
I think it would be better for such alignment use of the function, if it would return at least the extends of the bounding boxes (xAdvance). This would sometimes lead to a slightly larger bounds rectangle than strictly needed, but it would make the function also suitable for such alignment use.
Of course any pixels beyond the xAdvance/yAdvance box must be included too. Only for the far left and far right (far top and far bottom) glyphs, the pixels outside the bounding box need accounting for. For 'internal' characters, only the xAdvance (yAdvance) needs to be taken into account. This could make the function less expensive.
Note that the above experience is for proportional fonts (gfxFont, non-monospace).
The text was updated successfully, but these errors were encountered: