| Summary: | FILESAVE Tab stop in right margin different in .doc export | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Jaime Velasco Juan <jsagarribay> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED NOTABUG | ||
| Severity: | normal | CC: | jluth, jmadero.dev, michael.stahl, vmiklos, xiscofauli |
| Priority: | medium | Keywords: | bibisected, bisected, filter:doc, regression |
| Version: | 4.0.0.1 rc | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
screenshot showing the difference
sample documents screenshot of MSWord 2013 after opening rightTab.odt (the LO format) |
||
Created attachment 73395 [details]
sample documents
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 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: 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? 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: 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 (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) [NinjaEdit] 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)
|
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.