Description: RSID text attributes causes the creating of more text portions, and the portion breaks make font kerning Steps to Reproduce: Example A: Created attachment 163982 [details] STR 1. Open the attached file 2. Zoom out so you can see the full page 3. Select the the table 4. Apply different table styles from sidebar -> Table styles. Notice shifting text (vertical) Example B: Created attachment 169357 [details] Example file 1. Open the attached file 2. CTRL+A 3. CTRL+X 4. CTRL+V 4. Scroll up 5. Triple click "pour at the top of the page" 6. Nothing happening -> File reload -> Possible shift visible (not sure) 7. If not repeat 2-6 2 times.. it should have happened by now See also bug 139296 comment 42 and comment 43 (for a bibisect.. so why it is hidden sometimes) Example 3 ("officially" bug 140101) 1. open attachment 169403 [details] 2. Place cursor before Historique 3. Press backspace. 4. Notice certain letters moving: in the line L’enseignement de l’informatique dans le cadre des sciences et technologies 5. Press Undo 6. Repeat.. 7. Change zoomlevel repeat 8. Delete the paragraph prior to the first heading.. 9. Repeat.. now it's OK -- This kind of fits the bill, IMHO: fdo#52028: sw: let text formatting ignore RSID in automatic styles A suprising regression from 062eaeffe7cb986255063bb9b0a5f3fb3fc8e34c: The RSID text attributes that are inserted for every user-inserted text cause the text formatting (SwAttrIter) to create a lot more text portions, and the portion breaks make font kerning impossible. This is the only way i can think of to fix this problem; alternatives that don't work are splitting the RSID out of the AUTOFMT hint into a separate one and combining them in the sw UNO wrappers (fails because SwXAutoStylesEnumerator actually does need to enumerate every AUTOFMT including RSID), trying to detect and ignore them just in the text formatting (the SwAttrIter cannot easily/cheaply detect when it's allowed to skip), and having an internal subdivision inside the AUTOFMT hint (one subsection for every RSID change) (which does not work because it cannot ignore RSID-only AUTOFMTs completely). Solve the problem with 2 additional flags on AUTOFMT and CHARFMT attributes: FormatIgnoreStart and FormatIgnoreEnd, which indicate to SwAttrIter::GetNextAttr() that the start or end of the hint should be ignored, so that effectively it is merged with the preceding/subsequent hint. Of course the UNO API does not respect the flags so we can store the RSIDs in automatic styles. The flags are maintained in SwpHints::MergePortions, which detects both RSID-only AUTOFMT hints (which can be ignored completely), and the situation of N CHARFMT hints + AUTOFMT hint vs. N CHARFMT hints + AUTOFMT hint where the AUTOFMT hints differ only in their RSID attribute. This means that MergePortions needs to be called more often now, in cases where the ignore flags may have been invalidated, such as: - insertion of text with possible DontExpand flag set on hints - deletion of hints - SETATTR_NOHINTADJUST mode Source: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6db39dbd7378351f6476f6db25eb7110c9cfb291 Actual Results: Shifting Expected Results: Stable Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 66013201749df7d5ac5ddaf377a7b3732518a93b 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 3.5
@Michael My speculation is that you're fix back in the day: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6db39dbd7378351f6476f6db25eb7110c9cfb291 is falling apart.. it maybe never worked perfectly - at least I have seen this also in 4.3 on macOS (and also bug 138919 might fit in) but surely becoming even more prominent. And kind of expecting that the glyph positioning drama of bug 103322 can be directed to this too.. The kerning in example 3 pretty OK after step 3 as far I can tell.. There is also a bounty open for solving this :P. However $250 kind of a joke
oh, that's tragic... would be interesting to know if this is a regression and to bibisect it, it used to work reasonably well when i wrote that commit.
Pretty straight forward: bug 140101 and bug 140197: https://cgit.freedesktop.org/libreoffice/core/commit/?id=568b820bc2d52c007ee08ad7a3849c94a458115d Bit more dubious, but makes sense bug 139296: https://cgit.freedesktop.org/libreoffice/core/commit/?id=378c74ce290ab772f962db51ff8cba200cb40144 (partly redraw instead of full.. causing misalignment) Bit more dubious, but makes sense bug 138919: https://cgit.freedesktop.org/libreoffice/core/commit/?id=cba7370aab56212ca9e8def72ce821746835b4ff [a change I hijacked the bug, so 2 topics in 1] The deleting of paragraph in case of bug 140101 causes proper font kerning, IMHO. So it's possible to have good kerning. I think I assume there is also a part which never got fixed; bug 103322. I have seen enough shifts in 4.3 on macOS. Pretty sure backend matters. GDI always pretty stable for me. OpenGL/Skia are affected. GEN backend & macOS backend. Not sure about the impact of Harfbuzz, don't think so.. There are two issues: 1. Initial rendering with bad kerning 2. Sub sequential font renderings (repaints) with different kerning. Where the distances between letters suddenly differently distributed (causing certain letters to move left/right; also depending on zoom, backend) 3. There also misalignments top/down, but not totally sure if it's related or not.. 4. There are cases where black line occurs below a paragraph/sentence. Speculating this 2 lines of pixels of the sentence not being repainted (while letters moved horizontally).. I added few screencast here an there.
Alternative to RSID explanation: GetTextBreak code (or some combo of both). See bug 138919; involves: https://cgit.freedesktop.org/libreoffice/core/commit/?id=cba7370aab56212ca9e8def72ce821746835b4ff
No advantage of having this longer around. Example B/C looking fixed to me. Example A is mentioned somewhere else