Bug 160438 - Unwanted preceding dot *after* fill characters but *before* page numbers in table of contents
Summary: Unwanted preceding dot *after* fill characters but *before* page numbers in t...
Status: RESOLVED DUPLICATE of bug 160342
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2024-03-30 19:54 UTC by ProfYaffle
Modified: 2024-05-09 18:41 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing renegade dots (36.73 KB, image/png)
2024-03-30 19:54 UTC, ProfYaffle
Details
Sample document showing behaviour (on my system, anyway!) (15.24 KB, application/vnd.oasis.opendocument.text)
2024-03-30 19:55 UTC, ProfYaffle
Details
Sample PDF export showing that the formatting isn't just on-screen rendering (but for only one entry) (24.95 KB, application/pdf)
2024-03-31 16:38 UTC, ProfYaffle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ProfYaffle 2024-03-30 19:54:09 UTC
Created attachment 193409 [details]
Screenshot showing renegade dots

Actually seen on 24.2.2.2

Other reports:

https://ask.libreoffice.org/t/table-of-contents-adding-leading-dot-before-page-numbers/103241

https://superuser.com/questions/1831051/remove-the-dot-before-pages-in-the-table-of-content-entries-in-libreoffice

* New document
* Filled in placeholder headings
* Inserted ToC.
* Adjusted default style to change font
* Updated ToC.
* All entries have an unwanted - and, presumably, erroneous - dot before the page number.

What's expected:

Table entry ............................... 1

What's happening:

Table entry ............................   .1

Screenshot attached. Recreated on entirely blank document (new, insert text for headings, format as H1/H2, insert ToC - dots appear). I'd add this sample document as well, but it looks like it's one attachment only, so I'll see if I can update the report later with this.

Version info:

Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Ubuntu package version: 4:24.2.2~rc2-0ubuntu0.22.04.1~lo1
Calc: threaded
Comment 1 ProfYaffle 2024-03-30 19:55:09 UTC
Created attachment 193410 [details]
Sample document showing behaviour (on my system, anyway!)

Attachment of sample document as promised in the bug report.
Comment 2 ProfYaffle 2024-03-30 20:02:16 UTC
Update: document saved and opened in an earlier version - dots are *not* apparent. behaviour is as expected. That suggests a new bug, not anything long-standing.

Version: 7.6.5.2 (X86_64) / LibreOffice Community
Build ID: 60(Build:2)
CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 4:7.6.5-0ubuntu0.22.04.1~lo1
Calc: threaded

I'll try with a Windows version or two as well when I find one.
Comment 3 ProfYaffle 2024-03-30 20:50:24 UTC
... and, while I find a Windows system, upgrading that (X)Ubuntu system to 24.2.2.2 from 7.6.5.2 introduces the bug.
Comment 4 ProfYaffle 2024-03-30 20:54:47 UTC
... and does *not* appear in the same version on Windows:

Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01
CPU threads: 16; OS: Windows 10.0 Build 22000; UI render: Skia/Vulkan; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: CL threaded
Comment 5 ProfYaffle 2024-03-30 21:01:24 UTC
... but, interestingly, *does* appear on an earlier version on a Win10 VM (VMM/QCOW2) on that second 'buntu machine, so I've no idea what's going on. Renderer?

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 1; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded
Comment 6 m_a_riosv 2024-03-31 01:42:29 UTC
Seems it is a scale issue.
Changing the scale from 100 to 120 it looks fine.

Reproducible with
Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 40d3d510fca99b555381deb74b9915c91c924de5
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

Regression because works fine for me with
Version: 7.6.6.3 (X86_64) / LibreOffice Community
Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL threaded
Comment 7 ProfYaffle 2024-03-31 16:37:44 UTC
It might be a scaling issue, as - as you say - it's not apparent at different zoom levels. However, be aware that it appears on Print Previews, and kind-of-appears on a PDF export, which suggests that it's more than just a rendering issue.

I don't have a printer to hand to see if it appears on paper as well.

New attachment: PDF showing the bug, but only on one entry for some reason...
Comment 8 ProfYaffle 2024-03-31 16:38:22 UTC
Created attachment 193418 [details]
Sample PDF export showing that the formatting isn't just on-screen rendering (but for only one entry)
Comment 9 raal 2024-04-01 10:46:09 UTC
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2.
Adding Cc: to Khaled Hosny ; Could you possibly take a look at this one?
Thanks
 4ce9836c2406d6fc50482782ef4675b5e5078edb is the first bad commit
commit 4ce9836c2406d6fc50482782ef4675b5e5078edb
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Sun Jul 23 06:26:11 2023 +0200

    source 4b743de97fc133623e46827869c4ea3eb845ad47

154292: tdf#156234: Don’t round glyph coordinates when doing subpixel positioning | https://gerrit.libreoffice.org/c/core/+/154292
Comment 10 Mike Kaganski 2024-04-06 07:54:45 UTC
SwTabPortion should use some technique similar to what is used in SwTextAdjuster for IsOneBlock case (last line of justified paragraph is also justified, even with a single word case). That works through SwLineLayout::InitSpaceAdd, and then the additional inter-character spacing stored in SwLineLayout::m_pLLSpaceAdd is "installed" into SwTextPaintInfo using its SetpSpaceAdd/ResetSpaceIdx (see e.g. SwTextPainter::DrawTextLine). A constant named SPACING_PRECISION_FACTOR should be used in the spacing value calculation somehow.

But I have no idea where can we calculate the correct value. A naive approach of adding such code in SwTabPortion::Paint (calculating the resulting string length, and using (Width() - resultingStringWitdh) as a value in a vector passed to SwTextPaintInfo::SetpSpaceAdd) doesn't work for me.

Laszlo made quite a large change lately in character spacing code; could you please take a look here?
Comment 11 Mike Kaganski 2024-04-07 08:16:38 UTC

*** This bug has been marked as a duplicate of bug 160342 ***