-
Notifications
You must be signed in to change notification settings - Fork 28.9k
Clipping if only one character text overflows #99146
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
Conversation
@@ -644,7 +650,7 @@ class RenderParagraph extends RenderBox | |||
size = constraints.constrain(textSize); | |||
|
|||
final bool didOverflowHeight = size.height < textSize.height || textDidExceedMaxLines; | |||
final bool didOverflowWidth = size.width < textSize.width; | |||
final bool didOverflowWidth = size.width < textSize.width || size.width < _textPainter.longestLine; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would _textPainter.longestLine
ever be smaller than textSize.width
(which is _textPainter.size,width
) for a one char long text? That seems odd. Is there a bug in how textPainter calculates its actual width?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also have TextWidthBasis
which essentially changed _textPainter.size.width
to be _textPainter.longestLine
. I am not too familiar with that setting, though.
/cc @justinmc who added it a while back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would
_textPainter.longestLine
ever be smaller thantextSize.width
(which is_textPainter.size,width
) for a one char long text? That seems odd. Is there a bug in how textPainter calculates its actual width?
The textPainter.size.width
always returns the layout constraints.width
, this should be the implementation of the engine layer. @LongCatIsLooong may know the details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_textPainter.longestLine is the width of the longest line of actual text. _textPainter.width is either the same thing or the constraints width depending on TextWidthBasis (code) as you guys noted.
So it's possible and even common for _textPainter.longestLine to be shorter than _textPainter.width, for example:
Here _textPainter.longestLine is just the width of that single character (a few pixels), while _textPainter.width is the width of the green Container (100px).
So the condition in the code here (size.width < _textPainter.longestLine
) makes sense to me. That will be true when the available space is less wide than a single character.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PS Sorry it took me so long to respond here! I'm bad with my notifications recently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Just a nit about an assert. The discussion around the width conditional seems ok to me.
@@ -644,7 +650,7 @@ class RenderParagraph extends RenderBox | |||
size = constraints.constrain(textSize); | |||
|
|||
final bool didOverflowHeight = size.height < textSize.height || textDidExceedMaxLines; | |||
final bool didOverflowWidth = size.width < textSize.width; | |||
final bool didOverflowWidth = size.width < textSize.width || size.width < _textPainter.longestLine; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_textPainter.longestLine is the width of the longest line of actual text. _textPainter.width is either the same thing or the constraints width depending on TextWidthBasis (code) as you guys noted.
So it's possible and even common for _textPainter.longestLine to be shorter than _textPainter.width, for example:
Here _textPainter.longestLine is just the width of that single character (a few pixels), while _textPainter.width is the width of the green Container (100px).
So the condition in the code here (size.width < _textPainter.longestLine
) makes sense to me. That will be true when the available space is less wide than a single character.
@@ -644,7 +650,7 @@ class RenderParagraph extends RenderBox | |||
size = constraints.constrain(textSize); | |||
|
|||
final bool didOverflowHeight = size.height < textSize.height || textDidExceedMaxLines; | |||
final bool didOverflowWidth = size.width < textSize.width; | |||
final bool didOverflowWidth = size.width < textSize.width || size.width < _textPainter.longestLine; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PS Sorry it took me so long to respond here! I'm bad with my notifications recently.
This pull request is not suitable for automatic merging in its current state.
|
The failed Google tests were a few visual diff tests where the rightmost pixel of some text had a very slight, unnoticeable change in opacity. It's slightly strange that this happened for text that wasn't a single character long, but probably just due to floating point math for the antialiasing. I've set the Google tests to "passing", but we'll have to accept the new reference images after merge. |
Interestingly, if this patch breaks things, it must be that |
I think it might be this: In the case where TextWidthBasis.longestLine is used and the parent's width tightly wraps the text, then Maybe we should try using something like If you want to try the floating point hack thing, I can re-run the Google tests and see if it has any effect. |
Something's not quite right here, in this scenario, Could you help to file a test to repro the google test? Or just make this breaking intended? I have no idea make which double value hack to check the test now, or do you have any thoughts? |
@justinmc Hey, Could we merge this and accept the new golden file? : ) |
) (#102389) This reverts commit 08e467d (Google test failures after merge). Co-authored-by: Justin McCandless <[email protected]>
This reverts commit 8817521.
…r#99146)" (flutter#102130)" This reverts commit 3f43d9f.
…r#99146)" (flutter#102130)" This reverts commit 3f43d9f.
…r#99146)" (flutter#102130)" This reverts commit 3f43d9f.
flutter#102130) Fixes a text clipping edge case.
…r#99146)" (flutter#102130)" (flutter#106964) This reverts commit 3f43d9f.
…lutter#107168) * Revert "Reland "Clipping if only one character text overflows (flutter#99146)" (flutter#102130)" This reverts commit 3f43d9f. * Revert "Implement frameData for TestWindow (flutter#105537)" This reverts commit 21841d7.
Fixes #99140