Description: The whole sentence is moving once after file opening when applying formatting and wiggling characters Steps to Reproduce: 1. Open the attached file 2. Zoom 490% at 1920x1080 96 dpi screen 3. Scroll horizontal so the first L is at the left corner of the screen 4. Select the fifth 'Lorem' (reading LTR) and press CTRL+U 5. Press CTRL+Z/ CTRL+Y Note: the first lorem has no formatting. the other lorems have character DF set. This does matter Actual Results: 1) Initially a shift across the full line of text 2) CTRL+Z CTRL+Y shows a wiggling EM at the selected LOREM and a moving m at the next lorem Expected Results: Possibly stable results? Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a81e957f5026373f3935390c786c21416fc74fcc 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 threaded
Created attachment 183650 [details] Example file
Created attachment 183651 [details] Screencast
@Caolan I should probably drop the topic: likely again bug 61444. However I'm not underling a word partially... There are 2 effects: A) activating underline causes a shift across to board. B) There is a shifting of glyphs in a number of area's. Both can be seen in the screencast
Similar issue with: Version: 7.3.6.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 1; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: es-MX (en_US.UTF-8); UI: en-US Calc: threaded The screen is 1152x864. I tested with the fifth and with the fourth Lorem. The effect is reset if the text is scrolled out (to left or right) and in again.
@Caolan: likely, this is related to bug 103322 comment 49?
I could only reproduce the kerning issue on Linux (screen 1920×1080): Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: deb7bc82de19ea8e20c767fdf21f9ba4feb5e9f0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded But I could reproduce both issues on Windows (whole line shift, single-character kerning) with: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: deb7bc82de19ea8e20c767fdf21f9ba4feb5e9f0 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Screen: 640×480
I seem to see this even in very old versions.
I think the thing to watch is the cursor at the start of the text when scrolling horizontally. As we scroll the text begins to appear to overlap the first letter, scroll the other way and it returns to the start. The cursor is at the correct place and the text isn't. That's the big effect I think, with the text snapping to the correct place when the repaint is forced on the first ctrl+u
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/96880f5af713a55d87556af30a08b5f09f00ba48 tdf#152094 don't attempt scroll paint optimization for devices with a mapmode It will be available in 7.5.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.
Whole sentence shifts issue disappeared Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 651658d37bcb3f493942dd5d0b9a0d65c96f105c 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 threaded The wiggling character issue is still present, but well I merged to bugs into a single report... So I'm happy to create another one, and call this one FIXED
Note: The wiggling can simply reproduced: 1. Open Writer 2. Insert Lorem Ipsum auto-text 3. Double click on 'ipsum' (second word first line) and press CTRL+U. Press CTRL+Z/CTRL+Y to make it dance I see this across all zoom-levels. What exactly starts moving depends on zoom-level.
In the other cases generally we had high accuracy in writer which was lost on the way to the screen. In this case we have high accuracy in the reference device writer layouts against, 6 times higher than writer's internals, so vcl's text positions are scaled down by 6 and this jitter can happen. If the reference device was set to writer's max then this wouldn't happen I think, and it was at that resolution at one point before https://bz.apache.org/ooo/show_bug.cgi?id=14805 and the test case that was motivation for that still reproduces the original problem on reverting the change done back at https://cgit.freedesktop.org/libreoffice/core/commit/?id=ef7e326c3e0b812b883b2d075e3a2c6271f182b1 Tricky, maybe SwFntObj::DrawText could be tweaked to operate at that higher than normal resolution to retain unscaled values from GetTextArray and pass them along to DrawTextArray.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bfe18cbb5eebe975bd469bb884b4c86f03fc48c0 Related: tdf#152094 experiment with snapping to a subpixel It will be available in 7.5.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.
(In reply to Commit Notification from comment #13) > Caolán McNamara committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > bfe18cbb5eebe975bd469bb884b4c86f03fc48c0 > > Related: tdf#152094 experiment with snapping to a subpixel I guess more patches a coming... anyhow, in between feedback Problem still around, I'm not seeing anything using the exact steps at comment 11. But visible when underlining 'Curabitur' on the second line (wiggling i and g in dignissim, 220% zoom, 96DPI) or "consectetur" on the third (wiggling i in mauris & g in ligula, 220% zoom, 96DPI) Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ce60a3dd4dbff0dcb5b82c9053ae5d90f8ac929d 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 threaded
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f9395a123e8c85134bdd6e471bc93b2745e22a9d tdf#152094 retain more accuracy from RefDevMode::MSO1 It will be available in 7.5.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.
yeah comment #13 does nothing for Windows, comment #15 hopefully has the same effect for you under Windows as it does for me on addressing this issue
I'll risk claiming this is fixed for this case
Created attachment 183995 [details] Screencast GDI rendering @Caolan Good & bad news In my perception: * GDI rendering: rendering is stable. However the whole sentence moves underlining "Vestibulum in the first line of Ipsum Lorem Dummy Text * Skia Raster: not much of a change, still 'jittering' a lot. And has also the 'Vestibulum' shift. Should I report two follow-up bugs? Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: c50cf1883af26daebdfc9d796ced3c20c222f43b 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 threaded
Created attachment 183996 [details] Screencast Skia rendering First 12 seconds 350% zoom-level. Next 15 seconds 180%. It's better noticeable at 180%
(In reply to Telesto from comment #18) > * GDI rendering: rendering is stable. However the whole sentence moves > underlining "Vestibulum in the first line of Ipsum Lorem Dummy Text I'm fairly ok with the shift of Vestibulum. We've got an open bug for that conundrum wrt breaking a single run into multiple runs and I think that falls into that. > * Skia Raster: not much of a change, still 'jittering' a lot. That does seem to be the case, inter-glyph jitter. Yeah, file a new bug for that. Maybe its worth additionally trying something like comment #13 for skia, though it is something of a hack.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/344d90b20bdf95e9888f916672bbe51a5d700d02 tdf#152094 don't attempt scroll paint optimization for devices with a mapmode It will be available in 7.4.4. 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.