Bug 64864 - RTF: Tab-stop repeats when it should not (regression)
Summary: RTF: Tab-stop repeats when it should not (regression)
Status: RESOLVED DUPLICATE of bug 44715
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-22 11:56 UTC by mloc
Modified: 2013-09-22 08:44 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Extract showing the unexpected behaviour (13.16 KB, application/rtf)
2013-05-22 11:56 UTC, mloc
Details
Table rendered by Word 2003, tab-stop highlighted (25.13 KB, image/png)
2013-05-22 11:58 UTC, mloc
Details
Table rendered by LibO 4.0.3.3 Writer, tab-stop highlighted (34.98 KB, image/png)
2013-05-22 11:59 UTC, mloc
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mloc 2013-05-22 11:56:06 UTC
Created attachment 79648 [details]
Extract showing the unexpected behaviour

Problem description: some documents including dirty tabulation/spaces to align text have stopped behaving as expected by users (noticed when upgrading to LibO 4.0.x). It seems one tab-stop in the first row of a table is repeated by Writer now, thus shifting alignment. See pictures attached comparing LibO 4.0.3 and MSOffice 2003).


Steps to reproduce:
1. Open sample RTF with Writer 4.0.3 or 4.0.2
2. Notice non-alignement
3. Compare to Word 2003 or Writer 3.6.4.3

Operating System: Windows XP
Version: 4.0.2.2 release
Comment 1 mloc 2013-05-22 11:58:11 UTC
Created attachment 79649 [details]
Table rendered by Word 2003, tab-stop highlighted
Comment 2 mloc 2013-05-22 11:59:17 UTC
Created attachment 79650 [details]
Table rendered by LibO 4.0.3.3 Writer, tab-stop highlighted
Comment 3 Urmas 2013-05-22 14:59:44 UTC
Confirmed with master version.
Comment 4 Julien Nabet 2013-06-23 07:57:39 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

Miklós: one for you?
Comment 5 mloc 2013-08-21 10:20:47 UTC
Bug noticed in latest 3.6 branch version 3.6.7.2 too.
Comment 6 Julien Nabet 2013-08-24 11:53:37 UTC
I gave an update, now the tab is present in the ruler and text is ok.
I noticed these kinds of logs:
warn:writerfilter:849:1:writerfilter/source/dmapper/StyleSheetTable.cxx:398: Style type needs to be processed first
warn:legacy.osl:849:1:sw/source/core/layout/paintfrm.cxx:4357: new ShadowLocation() ?

With 4.1 sources updated today, I had the same result (tab is present in the ruler and text is ok).
I noticed only this kind of logs:
warn:writerfilter:849:1:writerfilter/source/dmapper/StyleSheetTable.cxx:398: Style type needs to be processed first

Miklós: Should we put this tracker to FIXED? (since the fact a tab present in ruler is more coherent)
Comment 7 Miklos Vajna 2013-09-22 08:44:52 UTC
So, this was indeed a problem, then now latest master is fine. Bisect says it got fixed with b9c1a9b9aa41dbbb6bed0c77f4370ab6105c7fb1, so I'll mark this a duplicate.

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