Description: Kerning shifts a little around dots (.) or comma (,) after applying highlighting/font color Steps to Reproduce: 1. Open the attached file 2. Double click www 3. Apply red font color -> notice a shift 4. Press CTRL+Z CTRLY multiple times to make it dancing 5. Type www, 6. Double click www and apply a font color... Actual Results: Change in kerning, which should be the case, IMHO Expected Results: Stable rendering 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 183624 [details] Example file
I only notice the change in kerning between the last W and the comma. Not for a, b or x. Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5b0a6621858b141022743dd8d500558895dedb1f 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 only notice the change in kerning between the last W and the comma. Not > for a, b or x. True Ending y, v, r (as w) are triggering the shift.. So words like: warrior, or your,
@Caolan, You might be interested in this one. I'm rather curious why the issue being limited to certain glyph combo's.
Created attachment 183632 [details] Different example 1. Open the attached file 2. Select the W 3. Apply Font Color -> Shift between 'W' and 'a' Not with old layout engine, present with the new engine (Harfbuzz) Version: 5.3.1.0.0+ Build ID: aa09fd58bd499a2a2c3a32c5f613892bad54076c CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; Layout Engine: old; Locale: nl-NL (nl_NL); Calc: CL
(In reply to Telesto from comment #5) > Created attachment 183632 [details] > Different example > > 1. Open the attached file > 2. Select the W > 3. Apply Font Color -> Shift between 'W' and 'a' > > Not with old layout engine, present with the new engine (Harfbuzz) > Version: 5.3.1.0.0+ > Build ID: aa09fd58bd499a2a2c3a32c5f613892bad54076c > CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; Layout Engine: > old; > Locale: nl-NL (nl_NL); Calc: CL Note: the 'W' needs to be uppercase to create the effect. Not occurring with small caps 'W'
Note also comment 0 being affected by Harfbuzz-rendering. This far less obvious with the old engine. However, shifts do occur when typing yyy, or highlighting yyy in 'yyy,' using the old engine.. So Harfbuzz made it more prominent, but probably present before.
Probably the same issue as bug 61444 that once formatting is applied to part of the text the layout of the text is done as two totally independent strings unaware of each other. Mentioned in slide 25 of https://events.documentfoundation.org/media/libreoffice-conference-2022/submissions/B87ZBP/resources/LibreOfficeCon-2022-ResolutionI_2TieDK1.odp
(In reply to Caolán McNamara from comment #8) > Probably the same issue as bug 61444 that once formatting is applied to part > of the text the layout of the text is done as two totally independent > strings unaware of each other. Mentioned in slide 25 of > https://events.documentfoundation.org/media/libreoffice-conference-2022/ > submissions/B87ZBP/resources/LibreOfficeCon-2022-ResolutionI_2TieDK1.odp Thanks.. marking this as a duplicate for now *** This bug has been marked as a duplicate of bug 61444 ***