Created attachment 78001 [details] Minimal example Steps to reproduce In the attached minimal example: 1. Select all. 2. Remove the tab at 1/2" by dragging off the tab bar. 3. Save as .docx file, close, and reopen. Results: The tab at 1/2" is recreated. This also occurs on version 3.4.3 for Windows. I have marked the severity as major, because it seriously subverts the use of tabs, and it's quite a nasty surprise when important documents are messed up.
Created attachment 78007 [details] Minimal example, created by LibreOffice
Created attachment 78008 [details] Minimal example, created by AbiWord I have some more clues. The first example was created by LibreOffice and saved as an XML (.docx) file. LibreOffice does not correctly read that file, but AbiWord 2.8.6 does. I.e., LibreOffice does not correctly read its own files, but AbiWord does. Moreover, LibreOffice correctly reads an equivalent .docx file (also attached) that was created by AbiWord. Thus, the problem occurs with XML (.docx) files that are created either by MS Word or by LibreOffice, but apparently not by AbiWord. I changed the bug summary to one that is more accurate.
I have attempted to change the bug summary to "Writer inserts extra Tab character in .docx documents" for accuracy, but apparently I lack the privilege.
Hi, I have tried to reproduce this issue on Writer version 4.0.3.1. So far, I am able to open the .docx you have provided, select all the text, and drag the tab bar at the top to remove the tab. When I save and reopen the document, my changes are still there. To start from scratch, how did you create the document? What I did was open a new document in Writer, pressed the Tab key to indent "Tab 1" in the first line. Then I went to the second line, wrote "filler text", pressed the tab key, and then wrote "Tab 2". I then saved the document as a .docx. I am able to reopen this file, and proceed with your instructions. I do not see an error. Please let me know if there is anything I might have missed or am not understanding about your bug report. Version: 4.0.3.1 (Build ID: a67943cd4d125208f4ea7fa29439551825cfb39) Platform: Ubuntu 13.04 Thank you, Brenda Granados ------------------------------- LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists
Created attachment 78612 [details] Video showing failure I have no idea why you can't reproduce it, but I just tested completely new installations of version 4.0.2.2 for Windows XP and version 3.5.7.2 for Ubuntu. These are both completely new installations with new operating systems and new, unused, default copies of LibreOffice. Both versions fail. I have attached a video recording from Ubuntu. I don't have the capability of recording video with the newer version in Windows, but the procedure and results are identical.
Version 4.0.3.1 for Windows also fails. When trying to duplicate the problem, be sure to use the file described as "Minimal example, created by LibreOffice".
(In reply to comment #4) > To start from scratch, how did you create the document? What I did was open > a new document in Writer, pressed the Tab key to indent "Tab 1" in the first > line. Then I went to the second line, wrote "filler text", pressed the tab > key, and then wrote "Tab 2". I then saved the document as a .docx. To answer your question, yes, I think that's the sequence, except that at some point I created left-justified tabs instead of center tabs. I did this by dragging left tab stops over the previously existing default center tabs, although the method of creating the tab stop (whether clicking on the bar or dragging) doesn't seem to matter.
After following your steps in the video, I get the same result as you. Forgive me if I am just not understanding, but it looks like Writer is deleting a tab character. You indent a paragraph further, save and close, and reopen, and it has removed the indent.
When you reopen it, it should look exactly like it did before you saved it. But it doesn't. Instead, it has reinserted the extra tab at 1/2".
Setting Version to v3.5.7.2 as the video in comment #5 indicates this was the initial version used in testing. I can confirm that the problem (as described) does exist for v3.5.7.2. I have also set the Importance to low/minor as there are workarounds i.e., Format > Paragraph… > Tabs and deleting the appropriate tab. Also set the Platform to All as a result of testing here under x86_64. Further comments and test files to follow.
Created attachment 78908 [details] Before and after editing (e) example DOCXs under Linux (L) and Win7HP (W). To clarify: Lv3572.docx = DOCX created under Ubuntu TDF/LOv3.5.7.2 with TABs at 36 & 72 pt / half and one inch / 720 & 1440 pos. Lv3572e4022.docx = DOCX created under Ubuntu TDF/LOv3.5.7.2 and subsequently edited under Ubuntu TDF/LOv4.0.2.2 to remove TAB at 36 pt / half inch / 720. Wv4002e.docx = DOCX created under Win7HP TDF/LOv4.0.2.2 and subsequently edited to remove TAB at 36 pt / half inch / 720. This no longer appears to be a bug under v4.0.2.2 for the creation of NEW files. It is only a problem if editing a 2007/2010 DOCX file - created under v3.5.7.2 - with v4.0.2.2 (or later as indicated in comment #6). In this case the indicated actions do not remove the TAB. I have tested this under: Windows 6.1.7601 SP1 Build 7601: v4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) Ubuntu 10.04 x86_64: v4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) and v3.5.7.2 (Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b) The document.xml file in v3.5.7.2 and v4.0.2.2 edited DOCXs appear to be identical, when conducting a rudimentary test. The differences appear to be in the styles.xml file, which contains this additional bit of code in the v3.5.7.2 version (even after editing by v4.0.2.2): <w:tabs> <w:tab w:leader="none" w:pos="720" w:val="left"/> </w:tabs> This would appear to be the cause of the problem in DOCX files created by older versions of LO. I would think this bug could be closed now as being RESOLVED.
Comment 11 is substantially correct. The problem appears to occur only in files that were created or edited in version 3.x or possibly older. In particular, .docx files that were created by MS Word are handled correctly. However, I cannot verify the proposed workaround. The only workaround that I know of is saving as a different file type (e.g, .doc or .odt). The bug as it appears in version 3.x does appear to be fixed in version 4. However, version 4 is unable to handle the tag, which is a separate bug. I'm attempting to close this bug if Bugzilla will allow. I have no plans to file the second bug.
So the problem is still present and is caused by LO not saving the removed tab at the paragraph level.
Created attachment 133302 [details] original odt
Created attachment 133303 [details] original odt converted to docx Steps: 1) Open attached docx 2) Select both lines 3) Remove the first tab at 0.50" 4) Save file, close, and reopen 5) 0.50" tab returns Version: 5.4.0.0.alpha0+ Build ID: 74ccd02eda2d6325a27266fd935aba29b3d75020 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-04-27_23:51:14 Locale: en-US (en_US.UTF-8); Calc: group As the 0.50" tab stop is set at the paragraph style, omitting it from the paragraph properties <tabs> tag isnt correct. <w:p> <w:pPr> <w:tabs> <w:tab w:val="left" w:pos="1440" w:leader="none" /> </w:tabs> <...> </w:pPr> <...> </w:p> MSO outputs it like so <w:p> <w:pPr> <w:tabs> <w:tab w:val="clear" w:pos="720" /> <w:tab w:val="left" w:pos="1440" /> </w:tabs> </w:pPr> <...> </w:p>
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 143447 [details] tdf63561_clearTabs.docx: minimal test created by patched LO 6.2. Just round-trip this. proposed fix https://gerrit.libreoffice.org/57255 Comment 15 had great information. The key to reproducing this problem is to have the style containing some set of tabs, and the paragraph contain a different set of tabs. (I created a minimal test using LO 6.2 on Linux, so this doesn't just affect old documents as some of the comments suggested).
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=859a0389b5639397e9c46cd4828a35793bd194f8 tdf#63561 docx export: "clear" unused inherited tabs It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2bc84658cce1df5050fe788dd0c8a0906a1ca2c3 related tdf#63561 docx: styles inherit tabstops too It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5fa898acb96fb344b526bd6e3892c4f4fae6e4f8&h=libreoffice-6-1 tdf#63561 docx export: "clear" unused inherited tabs It will be available in 6.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 107835 has been marked as a duplicate of this bug. ***
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=971a82bab0cd1381fc5623c2ead3e72580c5006f&h=libreoffice-6-1 related tdf#63561 docx: styles inherit tabstops too It will be available in 6.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 111529 has been marked as a duplicate of this bug. ***
*** Bug 120661 has been marked as a duplicate of this bug. ***