Bug 59671 - FILESAVE Tab stop in right margin different in .doc export
Summary: FILESAVE Tab stop in right margin different in .doc export
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: 4.0.0.1 rc
Hardware: All All
: high normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: bibisected
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2013-01-21 17:59 UTC by Jaime Velasco Juan
Modified: 2014-10-16 14:59 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
screenshot showing the difference (79.00 KB, image/png)
2013-01-21 17:59 UTC, Jaime Velasco Juan
Details
sample documents (8.32 KB, application/zip)
2013-01-21 18:02 UTC, Jaime Velasco Juan
Details

Description Jaime Velasco Juan 2013-01-21 17:59:45 UTC
Created attachment 73394 [details]
screenshot showing the difference

Steps to reproduce:

Create new Writer document and set a right aligned tab stop past the right margin. Type [tab] and some text. The text will end aligned to the right margin. Save document as .odt and also export as .doc

Open again both files.

Expected result:

Both documents should look the same.

Actual result:

the .odt file will look as expected but the .doc one will have the text beyond the right margin (I hope the diagram shows it clearly).


 page border                                 right margin
 /          left margin                        /    right-aligned tab stop
|          /                                  |     /      right page border
|         |                                   |    |        /
|         |                                   |    +       |

                               Some text in ODT
                                    Some text in DOC

Notes:

Word 2003 will show the exported .doc file with the text beyond the margin, just like Libreoffice.
Comment 1 Jaime Velasco Juan 2013-01-21 18:02:22 UTC
Created attachment 73395 [details]
sample documents
Comment 2 Joel Madero 2013-01-21 22:29:25 UTC
Verified as a regression, doesn't exist in 3.6, exists in 4.1 master.

Marking as:

New (confirmed)
Normal (can prevent high quality work)
Highest (regression + preventing high quality work + .doc interoperability + very common use of Writer could affect a lot of people)

Will bibisect shortly
Comment 3 Joel Madero 2013-01-21 22:40:21 UTC
Outside of the range of our bibisect package. Every step came out good through bibisect, tested again with 4.1 master and confirmed there is a problem - looks like a patch near release of RC1
Comment 4 Michael Stahl 2013-01-23 22:59:49 UTC
between beta 2 and rc 1...
this was introduced with:

commit 908bcce46c54e999916b32dffef34d34f21878d4
Author: Miklos Vajna <vmiklos@suse.cz>
Date:   Tue Jan 8 11:57:13 2013 +0100

    n#793998 sw: add TabOverMargin compat mode
    
    In case the right margin is larger then the tab position (e.g. the right
    margin of 7cm, there is a tab position at 16cm and right margin begins
    at 9cm), we have a conflicting case.  In Word, the tab has priority, so
    in this conflicting case, the text can be outside the specified margin.
    In Writer, the right margin has priority. Add a compat flag to let
    the tab have priority in Writer as well for Word formats.
    
    This is similar to TabOverflow, but that was only applied to left tabs
    and only in case there were no characters after the tabs in the
    paragraph.

... which sounds nice but is probably not supposed to be turned on when loading the ODF file attached here?  it has this in settings.xml:

      <config:config-item config:name="TabOverMargin" config:type="boolean">false</config:config-item>

hmm... it appears it is always turned on when importing a Word format file,
the flag is not stored in such files.  is that even possible?

is it necessary to convert such tabs on export to Word formats
so the file looks the same in Word as the ODT did in Writer?
Comment 5 QA Administrators 2013-05-27 17:56:16 UTC
This isn't really bibisected but it's basically there as the patch has been identified.

Marking as bibisected
Comment 6 Björn Michaelsen 2014-01-17 00:43:39 UTC
(This is an automated message.)

LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched.

You can find out more about MABs and how the process works by contacting libreoffice qa on irc:

 http://webchat.freenode.net/?channels=libreoffice-qa

The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list):

 https://wiki.documentfoundation.org/QA
Comment 7 Björn Michaelsen 2014-10-16 14:59:09 UTC
(This is an automated message.)

It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)

Thus setting keyword "bisected".


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.