Bug 52065 - FORMATTING: LO mishandles the placement of a tab-stop following a center-aligned tabstop.
Summary: FORMATTING: LO mishandles the placement of a tab-stop following a center-alig...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.3 release
Hardware: Other All
: medium normal
Assignee: Justin L
Whiteboard: target:7.2.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Tab-Character
  Show dependency treegraph
Reported: 2012-07-13 18:36 UTC by Milos Sramek
Modified: 2021-05-10 15:11 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:

doc version of the buggy file (23.50 KB, application/msword)
2012-07-13 18:36 UTC, Milos Sramek
Document that show the TABs bug. (14.03 KB, application/vnd.oasis.opendocument.text)
2012-12-18 10:34 UTC, ydutrieux

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Sramek 2012-07-13 18:36:08 UTC
Created attachment 64186 [details]
doc version of the buggy file
Comment 1 Milos Sramek 2012-07-13 19:05:10 UTC

There are two "signature" placeholders in the attached doc file - the right has three text lines. When loaded in LO, only second and third appear, the text "Pečiatka zamestnávateľa" is hidden. It appears, however, if the tab after "Podpis zamestnanca" (in the left signature) is deleted (and vanishes if the tab is inserted again). So, it appears that the missing text is "behind a corner".

If opened in MSO and Abiword, all three lines are displayed.

If the file is after loading in LO saved in the odf format, the line is still missing when loaded in LO, but is OK when opened in MSO and Abiword.
Comment 2 ydutrieux 2012-12-18 10:34:49 UTC
Created attachment 71719 [details]
Document that show the TABs bug.

Confirmed in libo 4 Version (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)
Unbuntu 12.04 64bits

what it do : The Third tab is over the line end depending on the size of text of previous tab (when centered ? ) - text could be inserted but not visible.

Document joined is original of libo with same bug.
Comment 3 bfoman (inactive) 2013-01-28 12:53:11 UTC
NEW per comment 2.
Comment 4 QA Administrators 2015-04-19 03:21:54 UTC Comment hidden (obsolete)
Comment 5 Milos Sramek 2015-04-19 07:35:22 UTC
the bug is still present in Version: and
Comment 6 QA Administrators 2016-09-20 09:24:29 UTC Comment hidden (obsolete)
Comment 7 Milos Sramek 2016-09-21 07:43:07 UTC
The bug is still present in master
It is a regression present since LO36, not present in LO33
ApacheOO41 is also OK

Bibisected using the file BUG52065.odt:
 7a864e30bffdf16060a3e8abe6d1f6853e841ce7 is the first bad commit
commit 7a864e30bffdf16060a3e8abe6d1f6853e841ce7
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed Apr 25 10:25:21 2012 +0200

    commit 4ff7252375b7b85eafbf176ca4e9184cc392d980
    Author:     Michael Stahl <mstahl@redhat.com>
    AuthorDate: Sun Feb 12 21:42:44 2012 +0100
    Commit:     Michael Stahl <mstahl@redhat.com>
    CommitDate: Mon Feb 13 00:25:03 2012 +0100

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4
git bisect bad 369369915d3582924b3d01c9b01167268ed38f3b
# good: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c
git bisect good 351622aec2dff3cc3bbbb020ad0097c4322d2a21
# bad: [378efb6e51212a05d1bd4b85c916eec5753c1744] source-hash-d453788ac0476cc02b929b0907718ca771d6d956
git bisect bad 378efb6e51212a05d1bd4b85c916eec5753c1744
# good: [1a3c4b54a8782fe0f4bdba221e87012a92e4d323] source-hash-a330f38093e2643a26239557050561afae9ff23d
git bisect good 1a3c4b54a8782fe0f4bdba221e87012a92e4d323
# bad: [5313c0086bde1a424c33b54120f14c4c79989cf7] source-hash-243fbda523cb71d0919539081d286eec4717ce15
git bisect bad 5313c0086bde1a424c33b54120f14c4c79989cf7
# bad: [45f31a35bb84d90093b303692f7424e63043f9aa] source-hash-f1c162967f032fcc5e4859f67c5b614c5dd19642
git bisect bad 45f31a35bb84d90093b303692f7424e63043f9aa
# bad: [7a864e30bffdf16060a3e8abe6d1f6853e841ce7] source-hash-4ff7252375b7b85eafbf176ca4e9184cc392d980
git bisect bad 7a864e30bffdf16060a3e8abe6d1f6853e841ce7
# good: [9ee4ea8545fce94fc73af72ea32cc77621dedb3e] source-hash-f484e0b07820d5772376aa75bc0f823f1e77e2f2
git bisect good 9ee4ea8545fce94fc73af72ea32cc77621dedb3e
# first bad commit: [7a864e30bffdf16060a3e8abe6d1f6853e841ce7] source-hash-4ff7252375b7b85eafbf176ca4e9184cc392d980
Comment 8 Michael Stahl (allotropia) 2017-06-22 14:15:32 UTC
bibisect range: f484e0b07820d5772376aa75bc0f823f1e77e2f2..4ff7252375b7b85eafbf176ca4e9184cc392d980

regression from:

commit 36c905d8c2874f6f984d5fbbc07784ec20c43524
Author:     Cédric Bosdonnat <cedric.bosdonnat.ooo@free.fr>
AuthorDate: Fri Feb 10 21:57:54 2012 +0100

    fdo#45908: Cleaning up the tabs too early can cause loops
Comment 9 QA Administrators 2018-10-08 02:47:36 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2020-10-08 04:08:17 UTC Comment hidden (obsolete, spam)
Comment 11 Justin L 2021-03-12 09:07:53 UTC
repro 7.2+.
I imagine the problem is related to a tab-stop following a centre-aligned tab-stop. Changing the 4.00cm tab-stop to left-aligned "fixes" the unseen content.

Probably the space required for that first portion is mis-calculated (or simply needs to be calculated LATER and for some reason that isn't done).

It is not a file open or save problem - since Word reads a round-tripped file just fine still. So it is "just" a layout issue.
Comment 12 Justin L 2021-03-12 12:45:28 UTC
Nice. PostFormat and PreFormat commands with no comments indicating why one would want to pre-format or post-format. And what does LastTab really mean - especially when it is nullptr?

In any case, we get this warning at the moment:
sw/source/core/text/txttab.cxx:325: SwTabPortion::PreFormat: rush hour

Reverting Cedric's patch still causes that one document to hang.

However, revert and removing the "return 0" fixes everything. (But what does it break?)
Comment 13 Justin L 2021-03-15 07:19:30 UTC
(In reply to Justin L from comment #12)
> Reverting Cedric's patch still causes that one document to hang.

That's attachment 56887 [details] (invoice.odt) from bug 45908.
It would be good to add this file to sw/qa/core/data/oedt/pass as a unit test.
Comment 14 Justin L 2021-03-16 13:34:24 UTC
Proposed fix with unit tests at http://gerrit.libreoffice.org/c/core/+/112559
Comment 15 Commit Notification 2021-03-17 08:29:53 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#52065 sw: revert tdf#45908: Cleaning up the tabs too early

It will be available in 7.2.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:

Affected users are encouraged to test the fix and report feedback.
Comment 16 Xisco Faulí 2021-05-10 15:11:39 UTC
Verified in

Version: / LibreOffice Community
Build ID: d4f116d9576453f5974eb63db37a33c59ac53bc9
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Justin, thanks for fixing this issue!!