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.
Both documents should look the same.
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
Word 2003 will show the exported .doc file with the text beyond the margin, just like Libreoffice.
Created attachment 73395 [details]
Verified as a regression, doesn't exist in 3.6, exists in 4.1 master.
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
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
between beta 2 and rc 1...
this was introduced with:
Author: Miklos Vajna <firstname.lastname@example.org>
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
... 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?
This isn't really bibisected but it's basically there as the patch has been identified.
Marking as bibisected
(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:
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):
(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".
Migrating Whiteboard tags to Keywords: (bibisected)
adding filt:doc keyword.
Adding Cc: to Miklos Vajna
I would suggest this is NOTABUG. The .doc file is doing exactly what it is told to do. Just because ODT doesn't do what it is told to do is somewhat irrelevant.
The fact that MSWord displays the .doc (and .docx btw) file identically to LO is a good indication that LO is doing this correctly. Doing something correctly now is not a regression.
There is no interoperability problem here right? Since both Word and LO open it the same way, it is easily shared. The only problem is format "convertability" and that is because the user has chosen settings that do not match his intentions. (If you want your right tab to end at the right margin, the marker ought to be placed there, and not at some random location beyond that point.) The lack of CCs over 4 years confirms that this will not affect a lot of people. Resetting priority to be medium.
P.S. MSWord uses the actually position of the right-tab in the *ODT* file as well, the interoperability problem actually comes from incorrectly designed ODT itself. (I wasn't going to change the status at first, but because of this I will actually change the status to notabug.)
IMHO, the only thing that could possibly be done at this point is to reset the right tab to be flush with the right margin when loading an ODT format, OR to change ODF so that it also is allowed to bTabOverMargin.
Created attachment 129717 [details]
screenshot of MSWord 2013 after opening rightTab.odt (the LO format)