Description: The applied underlining shift a little after applying highlighting Steps to Reproduce: 1. Open the attached file 2. Zoom in to lets say 310% 3. Double click libreoffice to dselect it 4. Apply Character Highlighting from the toolbar -> notice the underline shifting down a little 5. Press CTRL+Z CTRL+Y in repeat to make it dancing Actual Results: A minor shift in rendering Expected Results: Highlighting should not affect the rendering, in the ideal world, IMHO Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 7a89eae97a970939174d59aa58147eaa194acaee CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 183623 [details] Example file
I can see the whole of the line (even if only the word "libreoffice" is highlighted) shift down, but I had to go to 440% zoom to notice it. Side note: I also notice the spellcheck red underline shifting horizontally, and a letter too (which one depends on the zoom level). Not sure if that's been reported elsewhere. Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #2) > I can see the whole of the line (even if only the word "libreoffice" is > highlighted) shift down, but I had to go to 440% zoom to notice it. > Likely everything depends on zoom-level, screen resolution, screen DPI > Side note: I also notice the spellcheck red underline shifting horizontally, > and a letter too (which one depends on the zoom level). Not sure if that's > been reported elsewhere. No clue, I'm seeing it too > Version: 7.4.2.3 / LibreOffice Community > Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded
@Caolan, Any change to give some feedback, what is happing here.
IMO this is the same as bug 152068, and probably the same issue as bug 61444 Once the text gets broken into different "runs", those runs are laid out independently of each other, which is why "undo" which undoes the split into runs will have a different effect than toggling off the highlight. In the 2nd case, there are still two runs so the initial shift doesn't go away on doing that, but the shift does go away with undo. This is the same case as the animation on slide 25 of https://events.documentfoundation.org/media/libreoffice-conference-2022/submissions/B87ZBP/resources/LibreOfficeCon-2022-ResolutionI_2TieDK1.odp about bug 61444
Thanks for the feedback. And sorry for the noise :-). I somewhat forgot about bug 61444.. *** This bug has been marked as a duplicate of bug 61444 ***