ed1032975e
When we're calculating the width of the layout, we include the
right bearing of the last character in the text line if it is
negative (i.e. it exceeds the advance width). We do this by
storing the last glyph that has been verified to fit in the
line, so that we can retrieve its right bearing when we find
a break.
However, when we were wrapping on spaces this previous glyph
would always be a space, and the right bearing would
subsequently be 0. But then the trailing spaces would be
trimmed and the right bearing of the actual last glyph
would not be recorded and never added to the text width.
This caused a failure in tst_qquicktext on Windows with both
DirectWrite and Freetype: This was purely unlucky, because
the metrics of the Tahoma font happened to be such that the
right bearing on the 'k' was enough to cause a line to
overflow. Since we didn't account for it when setting the
width, we ended up with unexpected line breaks, causing the
test to fail.
This did not happen with GDI, since it rounded the right
bearing of the character down to 0 (which was actually
visible in the layout, in that the k was painted a fraction
of a pixel outside the text layout's width).
In addition, QTBUG-130313 was causing us to pick a different
font when resolving the non-existent font requested by the test,
so therefore the bug was not found immediately when moving to
DirectWrite as the default but only when QTBUG-130313 was fixed.
We fix this by
1. When adding a chunk of whitespace, we record the previous
non-whitespace glyph that has been verified to fit.
2. When adding a chunk of non-whitespace, we only record the
previous glyph verified to fit *if* it is not whitespace.
Otherwise we keep whatever we recorded before adding the
spaces.
Pick-to: 6.8
Fixes: QTBUG-132075
Change-Id: I8d9a2f3197068f5f93520d217a6bb89633644e95
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
(cherry picked from commit 250117086ff15bba79df8f0e15ee66192edc9ea9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>