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
// 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.
The text was updated successfully, but these errors were encountered:
itsjamie
changed the title
Text Rendering Vertical Positioning
Text Rendering - Oversized Canvases - Baseline and Vertical Positioning
Sep 13, 2024
I've been dragging my feet to look at this, its a bit of an interesting corner of the renderer. Would you need this both on SDF as well as on the Canvas text renderer or just Canvas?
Can probably whip up a PoC that covers this just to get some feedback on the behavior.
I would think it should be the same across all renderers if done this pass to prevent the issue that caused the rollback where the advanced text renderer laid the text out differently.
The oversized canvas becomes a larger problem when working with Figma like tools for designs that use web layout tech (flex) and then content sized layouts are wrong because the content is larger than it need be or would be with web.
I understand that automatically reading font baselines for each font used isn’t reasonable at runtime. But having a place to provide it so multiline and single line content is sized as needed will help for content-size based layouts.
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.
rdkcentral/Lightning#378
Effectively, with a fonts baseline ratio:
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.
rdkcentral/Lightning#428
Which was closed by removing the handling for the rendering in the cases where
lineHeight
was greater thanfontSize
.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.
The text was updated successfully, but these errors were encountered: