Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getTextBounds behavior. #402

Open
rohoog opened this issue Sep 10, 2022 · 0 comments
Open

getTextBounds behavior. #402

rohoog opened this issue Sep 10, 2022 · 0 comments

Comments

@rohoog
Copy link

rohoog commented Sep 10, 2022

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant