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 freetype-go package API doesn't yet support computing text extents without actually rendering the text to the image. Currently, the workaround is to calculate a "maximum" bounding box using the number of pixels in a single em unit. While this prevents text from ever being cut off, it tends to dramatically overestimate when fonts aren't monospace (since many characters have a width or height less than one em unit). Thus, the image is then cropped using the (x, y) offset returned from (*Context).DrawString.
Ideally, we should be able to calculate extents before rendering, therefore saving wasteful allocation. (For my use cases, the wasted allocation isn't too big of a deal.)
The freetype-go package API doesn't yet support computing text extents without actually rendering the text to the image. Currently, the workaround is to calculate a "maximum" bounding box using the number of pixels in a single em unit. While this prevents text from ever being cut off, it tends to dramatically overestimate when fonts aren't monospace (since many characters have a width or height less than one em unit). Thus, the image is then cropped using the (x, y) offset returned from (*Context).DrawString.
Ideally, we should be able to calculate extents before rendering, therefore saving wasteful allocation. (For my use cases, the wasted allocation isn't too big of a deal.)
For more details, see Issue 5 on the freetype-go issue tracker.
The text was updated successfully, but these errors were encountered: