-
Notifications
You must be signed in to change notification settings - Fork 30
Description
Hello!
I'd like to re-raise an issue from Lightning 2 before the same behavior is codified in many applications.
Initially I added and PRed in an improvement to the advanced text renderers support for line height rendering, and handling font baseline ratios.
Effectively, with a fonts baseline ratio:
// This calculates the baseline offset in pixels from the font size.
// To retrieve this ratio, you would do this calculation:
// (FontUnitsPerEm − hhea.Ascender − hhea.Descender) / (2 × FontUnitsPerEm)
//
// This give you the ratio for the baseline, which is then used to figure out
// where the baseline is relative to the bottom of the text bounding box.
The actual positioning of where the text should be positioned vertically could be set properly. This was enabled by creating a properly sized canvas to write the text to, including handling the cases where line height was greater than the font size.
The change to the advanced renderer was reverted after the issue below was filed, showcasing the difference between the two renderers.
Which was closed by removing the handling for the rendering in the cases where lineHeight was greater than fontSize.
This resulted in our app rendering incorrect sizes due to the now oversized canvases for text.
rdkcentral/Lightning#487
This led to us having to use negative paddings to shrink the rendered size of the text elements if we wanted to upgrade Lightning.
With the Lightning 3 framework, it would be appreciated if you could reconsider the text layout on canvas and calculating the vertical alignment offsets in text rendering, while fixing the issue raised in 428, where truncation resulted in the vertical alignment using a different code path.