Created attachment 177176 [details]
Example file

Another example for demonstration purposes
Even in 2.2.0

I cna't confirm it with

Version: 7.2.5.2 (x64) / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Does it depend on zoom factor? Tested with 140%

I couldn't reproduce under windows either, would be good to know if tools, options, writer, view, "Layout & Match Render" fixes ?

Created attachment 177570 [details]
Screencast

Still visible with:
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 628fedabdd27ad08e9a42f47106864751e493c2c
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Created attachment 177571 [details]
Screencast

Even worse with rotating text 90 degrees. The glyps are dancing

wrt comment #5 I can reproduce it now, I thought it was on a single backspace, but yes with backspace held down then as more is striked-through there was a lot of instability.

With "Layout & Match Render", then after

commit dab0d4e1f36faace21145a51733bd3a946992624
Date:   Sat Jan 15 21:47:02 2022 +0000

    tdf#146439 retain precise base start pos when using ResolutionIndependentLayout

this case appears stable for me.

rotated text as in comment #6 adds a bit of complexity because there is two things going on. One is that it is vertical of course, but the other is that changing the properties while change tracking is enabled makes the text bold to indicate formatting changes and then deleting it marks it strikethrough and no longer bold. The same effect can be seen horizontally where selecting the whole text, and changing its language to another language will mark it all "bold" for properties changed, and then pressing delete will unbold it and strike it through, and bold is wider than regular so it naturally changes layout.

Best to disentangle those two things by 1st turning off change tracking, do the format character to rotate character, and then reenable change tracking so we're just testing the stability of the rotated text case alone.

Created attachment 177578 [details]
rotated case without additional bolding for property changes

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/99460be87a11a404ce6c055fc540ec7ece404fb6

Related: tdf#146453 retain accurate positioning in rotated text rendering

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/95ade11df658d73e90d196f041d0839895aca3f0

tdf#146453 retain precise vertical base pos with ResolutionIndependentLayout

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

it seems stable to me now after those two additional changes

Created attachment 177604 [details]
Screencast

(In reply to Caolán McNamara from comment #11)
> it seems stable to me now after those two additional changes

Well it's surely has improved, but I do still notice wiggles around a 'full stop' symbol. But not clue if this is glyph related..

----
Another cause for shifting: can be seen in here (screencast): attachment 177596 [details]
1. Open attachment 168993 [details]
2. Select quite. Apply highlighting. Notice selecting moving from to big to much left, to be oversized at the right

Originally reported at bug 138919

This moves out of the bounds of rendering/on-screen preview positioning and into the "true" layout that would affect the final output. It's due to the nature of how we split up that text for measuring purposes.

If we look at the positions we get back from harfbuzz when the changetracking includes that troublesome space and when it doesn't.

Where * marks the space

case a, where the first run ends in a space.

measuring "He heard quiet steps behind him. "
advances are 1479 909 512 1024 909 909 682 1024 512 1024 1024 569 909 569 512 797 569 909 1024 797 512 1024 909 1024 569 1024 1024 512 1024 569 1593 512 512*

measuring "That didn't bode well."
advances are 1251 1024 909 569 512 1024 569 1024 1024 369 569 512 1024 1024 1024  909 512 1479 909 569 569 512

vs

case b, where the second run starts with a space

measuring "He heard quiet steps behind him."
advances are 1479 909 512 1024 909 909 682 1024 512 1024 1024 569 909 569 512 797 569 909 1024 797 512 1024 909 1024 569 1024 1024 512 1024 569 1593 512

measuring " That didn't bode well."
advances: 475* 1251 1024 909 569 512 1024 569 1024 1024 369 569 512 1024 1024 1024 909 512 1479 909 569 569 512

and we can see that a space followed by a T is 475 units wide, while a bare space (or followed by e.g. an M) is 500 units, and so it visually shifts horizontally.

What we could do is to measure the whole text as one run of text and then that
space would always be 475 units wide case and allocate the advances afterwards to the two runs, which is what something like https://gerrit.libreoffice.org/c/core/+/128573 could do. But that's then a higher category of risk than just changing how the wysiwyg tries to render the current layout which is all I've changed to date.

Well it's still early in 7.4, so still think it's worth a try

However I do like to prioritize dancing glyphs bugs first, before adding (more) experimental changes. I prefer some reliable baseline to spot issues.. Testing new stuff with (know) pre-existing bugs in same area isn't great.

I'm having rather specific bug in mind: bug 105936. It's bit of recycled bug; with multiple cases of dancing glyphs.

Dear Telesto,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug