Description: Text will split differently after applying highlighting (or font color) independent of zoom-level Steps to Reproduce: 1. open the attached file 2. Select "nofeature differences" 3. Apply highlighting or change font color Actual Results: "given" moves to next line Expected Results: Highlighting font color is no 'actual change' of font position.. so everything should stay put, IMHO Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.2.0.0.alpha0+ (x64) Build ID: 35e471bb4d1388cf5afcdcee214cf5111edf44e3 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 and in 4.4.7.2 and in 4.2 and in 4.0 not in 3.5.0.3 [or spurious luck.. or actual difference]
Created attachment 168169 [details] Example file
Thank you for reporting the bug. Highlighting or change in font color of "nofeature differences" does not move to next line I can not reproduce the bug in Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.2.0.0.alpha0+ (x64) Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 168172 [details] Screencast
(In reply to Telesto from comment #3) > Created attachment 168172 [details] > Screencast Screenshot is not visible. Can you please verify
Bibisected with Linux 43all to range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=35be7d7574cd0f45a18ee5838dd14cb1040890d4...3a35fd8f1c6b176e675b998a82526636aad5a00b From the range, this caught my eye: https://git.libreoffice.org/core/commit/cba7370aab56212ca9e8def72ce821746835b4ff n#757651 vcl: sync GenericSalLayout and SimpleWinLayout with MultiSalLayout As it was easy to change back, I tried it and compiled and indeed, line splitting no longer changed upon changing highlighting. Adding Cc: to Miklos Vajna
@V Stuart You might find this interesting.. Initially I would have assumed some quirky VCL floating point thingy.. but this case being actual regression.. Or hitting the floating point topic from a different side.. I could even consider Harfbuzz might be nitpicking on the matter here.. But well you're certainly better qualified to do some analysis on that.
I believe the above just uncovers an existing problem. That commit simply made the behavior consistent across multiple platforms, nowadays we don't even have multiple layouts, just the harfbuzz-based one. But try this on master: 1) Type "AV", set font size to 40pt (leave font at Liberation Serif, kerning enabled). 2) Highlight "A" with e.g. yellow. The V will obviously shift to the right a bit, because "A" and "V" now have different char props, so they are laid out separately, because "A" has a yellow background and "V" does not. I think the request to avoid this "shift to the right" is fair, but this never worked, so I think this is rather an implementation error. (E.g. an implementation of text highlighting in a pdf viewer never does this.) Adjusting keywords accordingly.
(In reply to Miklos Vajna from comment #7) > I believe the above just uncovers an existing problem. That commit simply > made the behavior consistent across multiple platforms. > The V will obviously shift to the right a bit, because "A" and "V" now have > different char props, so they are laid out separately, because "A" has a > yellow background and "V" does not. @Miklos Thanks for taking a peak. Any change to 'estimate' if this in the core being bug 103322? So floating point issue, or something else? I'm having a certain - desire / wishful thinking - this not to be a floating point precision issue. As floating point will need lots of work.. and the whole moving font thingy not being pretty frustrating (optical).. fonts not being aligned properly .. or even practical (moving stuff to different lines). So if there something else doing this.. being unrelated to roundings.. well would like no now. Else the waiting for bug 103322 fix being kind of pointless and searching it in the wrong area too.. It might fix this bug here to, in the process , but maybe not needed in the essence to get this solved. I would really love answer from someone who is actually able to make a proper assessment. Be leaving this open as a separate bug 'creating the impression' this being something different from bug 103322. Something I 'desire' but maybe not the 'truth'
> So floating point issue, or something else? My guess is that this has little to do with floating point, it's more about LO's model of text highlight is a char property, and we break up paragraph text to text portions when char props change. If we magically switch to floating point, you would still have the same problem.
Created attachment 168993 [details] Example file I think this illustrates the same issue in a different way" (big spacing between letters) Select a word and apply highlighting. Or any formatting for that matter
*** Bug 135127 has been marked as a duplicate of this bug. ***
Created attachment 173841 [details] Acrobat's text highlighting Could we think about something like other programs do without shifting the character itself?
Created attachment 173842 [details] Evince's text highlighting
I guess what could work is to render these highlights similar to annotated text ranges or the cursor selection, which is an overlay on top of already positioned text. Doing that correctly (not sure if e.g. PDF export handles such overlays) and without introducing performance problems (now you would need to produce those overlays as well) sounds tricky, though. Once you have such an overlay, the exact geometry of it is just a detail. Last, this is layout, so if you change it, you perhaps need a compat option to not break old documents?
Created attachment 177596 [details] Screencast What can be seen here is also interesting 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
*** This bug has been marked as a duplicate of bug 61444 ***