Created attachment 179841 [details] Comparison shows the fill character is the wrong one in the dev version. A bug was recently added in the dev version of LibreOffice and the tab fill character for a table of content is no longer applied when opening a document. Steps to Reproduce: 1) Create a Writer document with at least one heading and a table of content. 2) Format the table of content entry so the tabulation is using a dot with spacing ( ․ ), the fifth choice from the top in the fill character list. 3) Save and reload the document. Actual Result: The table of content displays what looks like an optional hyphen mark character. Expected Results: The table of content should display the dot character. 4) Update indexes and tables. The table of content now displays the correct fill character. Also if you saved again the document without updating the table of content, the wrong character replaces the correct one in all LibreOffice versions. The Writer document in attachment allows to experiment this bug when opened in the last LibreOfficeDev version.
Created attachment 179842 [details] Test document with table of content and fill character
I can't confirm with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 83d0f2eebae41d431d9a5bfd1a918523977752d0 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
I still have this bug in the latest version of LibreOfficeDev. I uninstalled the previous version (alpha 0), installed the latest one (alpha 1), and did a safe boot. Result: the tab characters in the table of contents are not the ones that were defined. This bug is recent, and even though I can't exclude that the issue comes from my side, I find it peculiar that it appeared so unexpectedly after an update of the dev version.
Created attachment 180148 [details] Persistent issue in safe mode This happens only with the last three characters proposed in the "Fill character" list. I tried with different fonts, unchecking the alignment options, but the issue persists. Updating the table of contents makes the right characters appear, the issue is when the document is loaded for the first time.
Confirm with Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: 75f7e057039aaa49558e22d18cad651d11589da9 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: x11 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo
This seems to have begun at the below commit. Adding Cc: to Noel Grandin; Could you possibly take a look at this one? Thanks 3aebb65457ff94cc7d693f621e630c060176ae3b is the first bad commit commit 3aebb65457ff94cc7d693f621e630c060176ae3b Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Apr 20 10:44:15 2022 +0200 source 8e4453c2117b6c3bb15be6b949a0a8a43df66647 https://git.libreoffice.org/core/+/8e4453c2117b6c3bb15be6b949a0a8a43df66647 use more FastAttributeIter::toView
Thanks for having took the time to check this bug. Could we change the status to "confirmed" to speed up its processing? Thank you.
(In reply to phv from comment #7) > Thanks for having took the time to check this bug. Could we change the > status to "confirmed" to speed up its processing? Thank you. NEW = CONFIRMED
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b1a4d2a49a47cd8b457b8c704134c0f1beaa9210 tdf#148846 TOC: Character fill for tabulation is wrong It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.