Created attachment 163445 [details] Writer doc. showing rendering problem with tab periods/full stops Version: 6.4.4.2 (x64) Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded Open the attached document. It was created in Open Office in 2018. I have edited out just the relevant section. 1. The dotted lines were created in "Paragaraph styles > Tabs" (using the period/full stop option). These lines looked fine in the original Open Office program, but in LibreOffice have become wrongly-rendered. This error also propagates to any exported pdfs. This seems to happen only with "Linux Libertine" font (but not the "Linux Libertine G" variant). 2. Change the font to Linux Libertine G. Notice that the error self-corrects. 3. Create the same style in a new LibreOffice document. Thne add some text and a Tab to create a dotted line. Notice, that the error does not occur. So the question is: Why is this problem (1) only occurring with "Linux Libertine" and (2) why is it affecting ONLY documents created in Open Office a few years ago.
Since you have a number of bug reports please do: -always search before reporting for duplicates and similar See Also bugs -see if you can use older LO versions to test, easiest im Windows is with SI-GUI that downloads and extracts them (it says Install but it means Extract) -see if this was ever OK with older LO, that would be regression then Marking regression helps because it can be bibisected then. Of course, you may also do bibisects, we have instructions in Wiki, it's not complicated, it just takes time and disk space to set environment. But marking exact LO where problem started is of help, like: not seen in LO 4.0,seen in 4.1,as close as possible, but anything is of help.
If it's any help, I used OpenOffice until about a year or so ago, and it definately wasn't present there.
Actually, I've reported the problem wrongly. To save confusion, I'll close and reopen with a corrected report.
See Bug 135558 instead.