Bug 63561 - FILESAVE: Removed tab stop returns on roundtrip
Summary: FILESAVE: Removed tab stop returns on roundtrip
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: All All
: low minor
Assignee: Justin L
URL:
Whiteboard: target:6.2.0 target:6.1.1
Keywords:
: 107835 111529 120661 (view as bug list)
Depends on:
Blocks: DOCX-Paragraph Paragraph-Tab-Stops 121456
  Show dependency treegraph
 
Reported: 2013-04-15 15:11 UTC by VanillaMozilla
Modified: 2018-11-19 11:35 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Minimal example (3.37 KB, application/xml)
2013-04-15 15:11 UTC, VanillaMozilla
Details
Minimal example, created by LibreOffice (3.40 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-04-15 18:34 UTC, VanillaMozilla
Details
Minimal example, created by AbiWord (3.72 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-04-15 18:41 UTC, VanillaMozilla
Details
Video showing failure (1.84 MB, video/ogg)
2013-04-29 18:47 UTC, VanillaMozilla
Details
Before and after editing (e) example DOCXs under Linux (L) and Win7HP (W). (22.42 KB, application/zip)
2013-05-06 07:56 UTC, Owen Genat (retired)
Details
original odt (8.06 KB, application/vnd.oasis.opendocument.text)
2017-05-14 01:52 UTC, Yousuf Philips (jay) (retired)
Details
original odt converted to docx (4.11 KB, application/wps-office.docx)
2017-05-14 02:04 UTC, Yousuf Philips (jay) (retired)
Details
tdf63561_clearTabs.docx: minimal test created by patched LO 6.2. Just round-trip this. (4.39 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-07-11 06:45 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description VanillaMozilla 2013-04-15 15:11:13 UTC
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.
Comment 1 VanillaMozilla 2013-04-15 18:34:32 UTC
Created attachment 78007 [details]
Minimal example, created by LibreOffice
Comment 2 VanillaMozilla 2013-04-15 18:41:53 UTC
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.
Comment 3 VanillaMozilla 2013-04-15 18:50:23 UTC
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.
Comment 4 Brenda Granados 2013-04-27 12:40:31 UTC
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
Comment 5 VanillaMozilla 2013-04-29 18:47:52 UTC
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.
Comment 6 VanillaMozilla 2013-04-29 19:30:06 UTC
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".
Comment 7 VanillaMozilla 2013-05-01 20:54:37 UTC
(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.
Comment 8 Brenda Granados 2013-05-03 01:57:03 UTC
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.
Comment 9 VanillaMozilla 2013-05-03 13:31:23 UTC
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".
Comment 10 Owen Genat (retired) 2013-05-06 07:45:40 UTC
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.
Comment 11 Owen Genat (retired) 2013-05-06 07:56:50 UTC
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 12 VanillaMozilla 2013-05-06 19:35:10 UTC
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.
Comment 13 Yousuf Philips (jay) (retired) 2017-05-14 01:49:04 UTC
So the problem is still present and is caused by LO not saving the removed tab at the paragraph level.
Comment 14 Yousuf Philips (jay) (retired) 2017-05-14 01:52:17 UTC
Created attachment 133302 [details]
original odt
Comment 15 Yousuf Philips (jay) (retired) 2017-05-14 02:04:44 UTC
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>
Comment 16 QA Administrators 2018-05-15 02:31:20 UTC Comment hidden (obsolete, spam)
Comment 17 Justin L 2018-07-11 06:45:05 UTC
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).
Comment 18 Commit Notification 2018-07-11 08:48:34 UTC
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.
Comment 19 Commit Notification 2018-07-18 05:38:53 UTC
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.
Comment 20 Commit Notification 2018-07-25 08:19:44 UTC
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.
Comment 21 Justin L 2018-07-25 09:55:14 UTC
*** Bug 107835 has been marked as a duplicate of this bug. ***
Comment 22 Commit Notification 2018-07-26 11:43:48 UTC
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.
Comment 23 Justin L 2018-08-11 13:51:15 UTC
*** Bug 111529 has been marked as a duplicate of this bug. ***
Comment 24 Timur 2018-10-18 09:01:01 UTC
*** Bug 120661 has been marked as a duplicate of this bug. ***