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
Created attachment 193410 [details] Sample document showing behaviour (on my system, anyway!) Attachment of sample document as promised in the bug report.
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.
... 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.
... 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
... 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
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
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...
Created attachment 193418 [details] Sample PDF export showing that the formatting isn't just on-screen rendering (but for only one entry)
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
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?
*** This bug has been marked as a duplicate of bug 160342 ***