Bug 140161 - RSID text attributes causes the creating of more text portions, and the portion breaks make font kerning
Summary: RSID text attributes causes the creating of more text portions, and the porti...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2021-02-04 17:56 UTC by Telesto
Modified: 2021-10-03 12:38 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-02-04 17:56:34 UTC
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]

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
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

Source: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6db39dbd7378351f6476f6db25eb7110c9cfb291

Actual Results:

Expected Results:

Reproducible: Always

User Profile Reset: No

Additional Info:
Found in
Version: (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
Comment 1 Telesto 2021-02-04 18:07:18 UTC
My speculation is that you're fix back in the day: 

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
Comment 2 Michael Stahl (allotropia) 2021-02-08 13:55:08 UTC
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.
Comment 3 Telesto 2021-02-08 14:20:37 UTC
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.
Comment 4 Telesto 2021-10-03 12:38:11 UTC
Alternative to RSID explanation: GetTextBreak code (or some combo of both). 
See bug 138919; involves: https://cgit.freedesktop.org/libreoffice/core/commit/?id=cba7370aab56212ca9e8def72ce821746835b4ff