Bug 90153 - A frame is not saved correctly if the document is saved as a docx file
Summary: A frame is not saved correctly if the document is saved as a docx file
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.3.2 release
Hardware: Other All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:5.1.0 target:5.0.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2015-03-22 07:45 UTC by A (Andy)
Modified: 2016-10-25 19:20 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description A (Andy) 2015-03-22 07:45:12 UTC
If you insert a frame and save it as a docx file, then it is not saved correctly.
I experienced this bug when I was testing Bug 90130.

Steps to Reproduce:
1. Open WRITER
2. Go to INSERT -> FRAME and press OK to insert a frame
3. Click with the mouse outside the frame into the document to deselect the frame (now it has no longer the green squares for selection)
4. Click with the mouse inside the frame (inside the inner frame of the frame), now you have the blinking cursor to insert a text
5. Write a word
6. Go to FILE -> SAVE AS and save the file as a docx file
7. After you have saved it, close it and reopen it

Result: 
The frame seems to been saved in the header, but not in the main section of the document (try to select it and move it down in the document).  This does not happen for rtf, odt and doc files and it also does not happen if you insert many empty lines before you insert the frame in Step 2.  
The inner text frame and outer frame itself are misplaced.  The inner text frame seems to be moved a little bit up in comparison with the frame itself.

Reproducible with LO 4.4.1.2, Win 8.1.
Comment 1 MM 2015-03-22 10:24:24 UTC
unconfirmed with v4.2.8.2 under mint 17.1 x64
confirmed with v4.3.6.2 under mint 17.1 x64
confirmed with v4.3.6.2 under windows 7 x64
confirmed with v4.3.2.2 under mint 16

The 4.2 branch looks fine. The bug starts in the 4.3 branch, so regression.
Bug is only there if you don't move the frame from the default position. If set to another position it's saved correctly.
Comment 2 Matthew Francis 2015-03-24 09:22:01 UTC
Bibisect results from 43all:

51361f6120a55607bea3903311bae3dfc4053e4e is the first bad commit
commit 51361f6120a55607bea3903311bae3dfc4053e4e
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sat May 10 23:10:23 2014 +0000

    source-hash-96af0825ab0d3d36df25a3983f9f422e987cb572
    
    commit 96af0825ab0d3d36df25a3983f9f422e987cb572
    Author:     Tor Lillqvist <tml@collabora.com>
    AuthorDate: Thu Dec 26 14:17:54 2013 +0200
    Commit:     Tor Lillqvist <tml@collabora.com>
    CommitDate: Thu Dec 26 15:23:17 2013 +0200


A few possibilities in that range, not immediately obvious which may be responsible
Comment 3 Matthew Francis 2015-04-13 10:10:16 UTC
This began at the below commit.
Adding Cc: to vmiklos@collabora.co.uk; Could you possibly take a look at this one? Thanks

commit 41927dce4217d60808a889f8dac546f55848eead
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Mon Dec 23 14:25:37 2013 +0100

    sw: enable drawingml export of textframes by default
    
    This was only available in experimental mode previously. Also note that
    export of shapes (including group shapes) was already enabled
    previously, this commit just enables the same for Writer Text Frames.
    
    Change-Id: I53e7f3fac84328cea316a9811ecd5eecec79b23d
Comment 4 Gordo 2015-07-09 16:53:40 UTC
The frame is no longer a text frame but a draw object.

"Finally, note that text frames are similar to text boxes in many ways, but their underlying XML is very different. They are not part of drawingML. Instead they are within wordprocessingML and their specification is part of the specification of a paragraph."  -- http://officeopenxml.com/drwOverview.php

Windows Vista 64
Version: 5.1.0.0.alpha1+
Build ID: d3b6f3790953bdfeaeebcd3ba9ec370d94ca4ebf
TinderBox: Win-x86@39, Branch:master, Time: 2015-07-09_00:11:56
Comment 5 Miklos Vajna 2015-09-25 15:58:09 UTC
Aha, during import we try to make the textframe at-paragraph anchored, and still have its vertical position based on the line position, that is only possible for at-char anchoring. I'll take care of this.
Comment 6 Commit Notification 2015-09-28 07:28:40 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=358666e4204364ce915ee95372dc6f2fca545253

tdf#90153 DOCX import: fix default sw TextFrame roundtrip

It will be available in 5.1.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 7 Commit Notification 2015-10-08 11:28:54 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f98d09c8325c642f0463f2e65ff57be0498e9c23&h=libreoffice-5-0

tdf#90153 DOCX import: fix default sw TextFrame roundtrip

It will be available in 5.0.4.

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 8 Robinson Tryon (qubit) 2015-12-17 08:49:51 UTC Comment hidden (obsolete)