Bug 146078 - Text starts wiggling/ changing kerning after auto-hyperlink creation (RSID)
Summary: Text starts wiggling/ changing kerning after auto-hyperlink creation (RSID)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Kerning
  Show dependency treegraph
 
Reported: 2021-12-06 15:24 UTC by Telesto
Modified: 2022-02-08 18:47 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Example file (9.24 KB, application/vnd.oasis.opendocument.text)
2021-12-06 15:25 UTC, Telesto
Details
Example File 2 (10.43 KB, application/vnd.oasis.opendocument.text)
2021-12-06 18:26 UTC, Telesto
Details
Bibisect log (6.32 KB, text/plain)
2021-12-06 18:31 UTC, Telesto
Details
Bibisect log (1.70 KB, text/plain)
2021-12-06 19:21 UTC, Telesto
Details
Screencast (2.50 MB, video/mp4)
2021-12-27 15:19 UTC, Telesto
Details
Screencast (655.27 KB, video/mp4)
2022-01-18 10:07 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-12-06 15:24:59 UTC
Description:
Text starts wiggling/ changing kerning after auto-hyperlink creation 

Steps to Reproduce:
1. Open the attached file (modified version of bug 97171 example file)
2. place cursor after cc at second line & press space
3. CTRL+Z/ CTRL+Y CTRL+Z/ CTRL+Y  CTRL+Z/ CTRL+Y  to see the change

Actual Results:
Wiggling

Expected Results:
No wiggling


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: ddc57169ac8d1de00403dbb09fef5221beaa0f3d
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
Comment 1 Telesto 2021-12-06 15:25:19 UTC
Created attachment 176735 [details]
Example file
Comment 2 Telesto 2021-12-06 18:26:02 UTC
Created attachment 176740 [details]
Example File 2
Comment 3 Telesto 2021-12-06 18:31:46 UTC
Created attachment 176741 [details]
Bibisect log

I used example File 2 to bibisect. I typed .cc + space after surfxs.
Typing the . after surfxs caused a shift in the area " xs"  until commit  736adbb4687eaa6b6a7a350a6452df2eceaad96 somehow resolved that.

With 6db39dbd7378351f6476f6db25eb7110c9cfb291 the 'W'  of world started moving instead.. 

Bisected to:
author	Michael Stahl <mstahl@redhat.com>	2013-06-15 21:25:27 +0200
committer	Michael Stahl <mstahl@redhat.com>	2013-06-20 00:34:38 +0200
commit 6db39dbd7378351f6476f6db25eb7110c9cfb291 (patch)
tree 0f9321d40740e87e80d8ed05a7c7f474d5310afd
parent e012f326c1c32c053304998a6826cb322f2c7728 (diff)
fdo#52028: sw: let text formatting ignore RSID in automatic styles

https://cgit.freedesktop.org/libreoffice/core/commit/?id=6db39dbd7378351f6476f6db25eb7110c9cfb291
Comment 4 Telesto 2021-12-06 19:21:47 UTC
Created attachment 176743 [details]
Bibisect log

The wiggling was also present in older versions... 
1. Add .cc after surfxs follow by + space
2. Press undo
3. Type .cc again 
4. Press Undo.. wiggling should have occurred

However, no wiggling with LibreOffice 3.6.0 Build ID: 43c7830 and older
Comment 5 Telesto 2021-12-06 19:40:46 UTC
(In reply to Telesto from comment #4)
> Created attachment 176743 [details]
> Bibisect log
> 
> The wiggling was also present in older versions... 
> 1. Add .cc after surfxs follow by + space
> 2. Press undo
> 3. Type .cc again 
> 4. Press Undo.. wiggling should have occurred
> 
> However, no wiggling with LibreOffice 3.6.0 Build ID: 43c7830 and older

Which makes the identified commit at bug 52028 comment 17 the lovely candidate
Comment 6 Rainer Bielefeld Retired 2021-12-06 21:46:42 UTC
REPRODUCIBLE with  Installation of Version 7.2.3.2 (x64) / LibreOffice 
Build  d166454616c1632304285822f9c83ce2e660fd92; CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: de-DE; Calc: threaded;  My normal User Profile
Here also the affected  characters of the word depend on zoom factor.
Comment 7 Telesto 2021-12-07 07:59:39 UTC
Adding CC: to Michael Stahl
Comment 8 Telesto 2021-12-07 08:20:54 UTC
@Buovjaga
A hypothesis 
1. "sw: Improved document comparison based on RSIDs." introduced the broken kerning
2. Khaled attempt 'some fix' to broken kerning. Which I he - probably - did without knowledge of the true cause. It solved the wiggle at bug 146080. See bug 52028 comment 26
3. "fdo#52028: sw: let text formatting ignore RSID in automatic styles" introduced the true fix. However, the change that Khaled prior to that, might now introduce the averse effect - broken kerning. 

author	Tzvetelina Tzeneva <tzvetelina@gmail.com>	2011-12-22 17:27:32 +0100
committer	Cédric Bosdonnat <cedric.bosdonnat@free.fr>	2011-12-22 17:53:53 +0100
commit 062eaeffe7cb986255063bb9b0a5f3fb3fc8e34c (patch)
tree 0f065352d000a11131203cf6832354bde597ff50
parent 61329db01af7fd7c5915a4d81896d52fda7168db (diff)
sw: Improved document comparison based on RSIDs.

----
author	Khaled Hosny <khaledhosny@eglug.org>	2013-05-23 09:34:27 +0200
committer	Khaled Hosny <khaledhosny@eglug.org>	2013-05-23 09:50:46 +0200
commit 736adbb4687eaa6b6a7a350a6452df2eceaad960 (patch)
tree 349302bc147dd1317261093fc57f887a284d8e29
parent 62b74b6c21b0b30bbb5a2053dabff375273b0c8e (diff)
Fix left to right full justification
I was overloading ApplyDXArray() with a HarfBuzz specific implementation
because the GenericSalLayout one was screwing right to left kerning, but
it seems to have broken left to right full justifications. Since
mnXOffset was introduced a bit earlier to fix a similar issue, it can
now be used here as well to minimize the possible side effects.

Seems to work fine for both left to right and right to left text now,
but at least one of my Arabic tests is regressing, so might need some
tweaking.

-----
Bisected to:
author	Michael Stahl <mstahl@redhat.com>	2013-06-15 21:25:27 +0200
committer	Michael Stahl <mstahl@redhat.com>	2013-06-20 00:34:38 +0200
commit 6db39dbd7378351f6476f6db25eb7110c9cfb291 (patch)
tree 0f9321d40740e87e80d8ed05a7c7f474d5310afd
parent e012f326c1c32c053304998a6826cb322f2c7728 (diff)
fdo#52028: sw: let text formatting ignore RSID in automatic styles

Me lacking a build environment (and setting it up costs a lot of time). Could you possibly do a manual revert of 736adbb4687eaa6b6a7a350a6452df2eceaad960 and see if things improve?
Comment 9 Telesto 2021-12-07 08:21:30 UTC
@Buovjaga
See comment 8
Comment 10 Buovjaga 2021-12-07 11:04:34 UTC
(In reply to Telesto from comment #9)
> @Buovjaga
> See comment 8

Too much churn after 2013 to easily revert:

Performing inexact rename detection: 100% (184590/184590), done.
CONFLICT (modify/delete): vcl/generic/glyphs/gcach_layout.cxx deleted in HEAD and modified in parent of 736adbb4687e (Fix left to right full justification).  Version parent of 736adbb4687e (Fix left to right full justification) of vcl/generic/glyphs/gcach_layout.cxx left in tree.
CONFLICT (modify/delete): vcl/inc/generic/glyphcache.hxx deleted in HEAD and modified in parent of 736adbb4687e (Fix left to right full justification).  Version parent of 736adbb4687e (Fix left to right full justification) of vcl/inc/generic/glyphcache.hxx left in tree.
Auto-merging vcl/source/gdi/sallayout.cxx
CONFLICT (content): Merge conflict in vcl/source/gdi/sallayout.cxx
error: could not revert 736adbb4687e... Fix left to right full justification
Comment 11 Telesto 2021-12-11 17:06:21 UTC
Bumping importance under the assumption that multiple kerning issues are caused by it (see previous speculation at bug 140161) and more or less proof (including bibisect) here. I doesn't seem to be true floating point for glyph positioning issue as suggested at bug 103322
Comment 12 Telesto 2021-12-23 12:11:39 UTC
Still present
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6dbe55d34ad65627ef37f10dfdb548a717bb8c78
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
Comment 13 Telesto 2021-12-24 10:28:30 UTC
@Caolan
You're currently in the possession of active in depth knowledge of glyph positioning (bug 144862). So you might have some clue what's going on here. 

The wiggle is visually exactly the same as bug 144862, but well a different trigger. 

I can't tell if commit 6db39dbd7378351f6476f6db25eb7110c9cfb291 being incomplete/broken (so shifting being caused by multiple text portions) or something else is intervening (like 6db39dbd7378351f6476f6db25eb7110c9cfb291)

To get things straight: no expectations for a fix nor an implicit requesting to spend lots of time this. 

My primarily intension to get to the bottom of the problem. Is the primarily problem in the glyph positioning code or RSID creating text portions (or combo of both) 

I obviously have to admit this topic being one of my pets. I dislike dancing/wiggling glyphs /unstable kerning (and there are more people likely me: bug 103322). And skeptical about floating point being the silver bullet
Comment 14 Telesto 2021-12-27 15:19:23 UTC
Created attachment 177156 [details]
Screencast

(In reply to Telesto from comment #13)
I tested the wrong build, so prior "explore alternatives to writer's on-screen glyph positioning "

So the change without 'no logic change intended' apparently do change something (in a positive sense)

---- now with "explore alternatives to writer's on-screen glyph positioning "

ClassicInspired/Readability
* Both have issues with cursor position. The spacing between text & cursor differs depending on zoom-level

* The text goes out of page margins on different zoom-levels

* No wiggle!

--
Layout/Classic
* Wiggling letters on pressing space

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 9c95415de877af1430ab5b7123e11dedd0ea622c
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
Comment 15 Caolán McNamara 2022-01-14 14:44:11 UTC
Try again now with: "Layout & Match Render" ?
Comment 16 Telesto 2022-01-18 10:07:08 UTC
Created attachment 177629 [details]
Screencast

(In reply to Caolán McNamara from comment #15)
> Try again now with: "Layout & Match Render" ?

The 'l' of Hello is still shifting
Comment 17 Caolán McNamara 2022-01-19 16:12:01 UTC
(In reply to Telesto from comment #16)
> The 'l' of Hello is still shifting

I think I can see this shift, but it is far smaller for me than in the video, but it's there. This *doesn't* seem to be the same problem as bug 146453 comment #13 and might be possible to improve without adverse sideeffect.