https://bugs.documentfoundation.org/show_bug.cgi?id=146453
--- Comment #13 from Caolán McNamara <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
