Constrained buffer with unconstrained buffer's width does not produce the same result #134
Comments
Imberflur
added a commit
to Imberflur/cosmic-text
that referenced
this issue
Aug 26, 2023
Try to ensure that using "the width computed during an unconstrained layout" as the width constraint during a relayout produces the same layout. This is useful for certain UI layout algorithms. See pop-os#134 * Instead of computing the LayoutLine width from the positioned and aligned glyphs, we pass through width computed during line wrapping (unless justified alignment is used, in this case we use the old approach because the use case for measuring the width isn't really applicable to justified text since that will just expand to the provided width). For the produced width to later give the same wrapping results when passed in as the `line_width` it needs to use the same exact float arithmatic that was used to compute the width that is compared against `line_width` when making line wrapping choices. Passing this width through as the LayoutLine width is the most covenient option without making more major changse to the API. Nevertheless, I am imagining that if we get a dedicated measurement method (i.e. that doesn't do the final positioning and alignment of glyphs and which caches `Vec<VisualLine>`), then this width can just be exposed there instead of preservering it in LayoutLine. * Incidentally, this fixes pop-os#169. * Switch substraction from `fit_x` to checking whether potential addition to the current line width would exceed the `line_width`. This avoids the float error being dependent on the provided `line_width` value. * When eliminating trailing space from the line width, we avoid backtracking with subtraction (which would not give the same exact value due to float error) and instead save the previous width and use that. * If the previous word did not exceed the line_width, we now include a single blank word even if it would cross the width limit since its width won't be counted. This is necessary to get the same wrapping behavior when re-using the measured width (which doesn't count a single trailing blank word). Note, this whitespace logic may be reworked anyway if <pop-os#155> is addressed. * Change tests to use `opt-level=1` to keep test runtime down. * Add `fonts` folder for fonts used in tests. * Fix an issue where a non-breaking whitespace was assumed to be the start of a section of spaces which included characters that weren't even whitespace. * Add some TODOs about incongruencies between `is_whitespace`, justification, and line breaks.
jackpot51
added a commit
that referenced
this issue
Aug 28, 2023
Fix #134 and include a test for it.
|
@tigregalis please check if this is fixed now |
|
Looks good to me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reproduction: https://github.com/tigregalis/cosmic-text-width-constraint-bug
When we draw text in Bevy, we currently do 2+ "size" passes (1+ node measurement pass during layout, and 1 rendering pass); the calculated width from the first pass determines the size of the node.
A rare bug(?) occurs when laying out the text
(6) SomewhatBoringDisplayTransformwith a font size of18.0pixels and the fontFiraMono-Medium.ttf. This shows up in a specific Bevy example, and I haven't been able to reproduce it with other text / font sizes / fonts, but the possibility exists.We lay out this text in a buffer (
buffer1) with anUNBOUNDEDsize; the buffer has one line (one layout run) with a certainwidth1(run.line_w).Later, we lay out the same line in a buffer (
buffer2) with a maximum size ofwidth1pixels wide.That is, the first buffer's width determines the width constraint of the second buffer. I expected that they would produce the same result.
However, this second buffer (
buffer2) is not considered wide enough to fit that text, so the second word breaks onto a second line.Even
ceiling the width still causes it to break. However,ceiling it and adding some small value (e.g.0.001) gets around this behaviour.The text was updated successfully, but these errors were encountered: