Bug 60922 - FILEOPEN, FILESAVE create document as odt, save as docx , corrupts
Summary: FILEOPEN, FILESAVE create document as odt, save as docx , corrupts
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: x86-64 (AMD64) All
: high normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:4.1.0 target:4.0.3
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2013-02-15 18:53 UTC by bravotwo.bugs
Modified: 2013-12-15 23:48 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Odt that will generate bug when save as docx is used (11.12 KB, application/vnd.oasis.opendocument.text)
2013-02-15 18:53 UTC, bravotwo.bugs
Details
The docx with display problem (4.71 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-02-15 18:54 UTC, bravotwo.bugs
Details
Screenshot docx+odt (116.62 KB, image/png)
2013-02-15 18:58 UTC, bravotwo.bugs
Details
odt file with image - see comment 3 (17.33 KB, application/vnd.oasis.opendocument.text)
2013-02-21 07:52 UTC, Winfried Donkers
Details
docx saved from new document - see comment 3 (4.38 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-02-21 07:53 UTC, Winfried Donkers
Details
docx saved from existing odt document - see comment 3 (11.27 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-02-21 07:53 UTC, Winfried Donkers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bravotwo.bugs 2013-02-15 18:53:50 UTC
Created attachment 74898 [details]
Odt that will generate bug when save as docx is used

When creating an odt and saving it as docx, fonts look funny upon reopening (fonts still take the same space, but actual displayed font is smaller, resulting in visible whitespaces around characters). This is not the case when opened in google docs or MS Office. Pressing clear direct formatting restores the original font. This seem to happen for all fonts.

LibreOffice 4.0.0.3 was installed using debs on website. OS: Ubuntu 12.10

Attached: 
-original odt
-saved docx
-screenshot odt
-screenshot opened docx
Comment 1 bravotwo.bugs 2013-02-15 18:54:29 UTC
Created attachment 74899 [details]
The docx with display problem
Comment 2 bravotwo.bugs 2013-02-15 18:58:30 UTC
Created attachment 74900 [details]
Screenshot docx+odt
Comment 3 Winfried Donkers 2013-02-21 07:51:34 UTC
I confirm this behaviour -and more- on Windows.

Way to reproduce (see attachments):
1. start new writer document
2. insert-image-from file..
3. select png image
4. save as dd1.odt
5. save as dd1-1.docx
6. close dd1-1.docx
7. open dd1.odt - shows as expected
8. save as dd1-2.docx
9. close dd1-2.docx
10. open dd1.odt - shows as expected
11. open dd1-1.docx - shows error where image should be visible
12. open dd1-2.docx - shows as expected

It seems that saving a new document as docx results in a corrupted docx where saving an existing odt as docx does not.
Comment 4 Winfried Donkers 2013-02-21 07:52:32 UTC
Created attachment 75230 [details]
odt file with image - see comment 3
Comment 5 Winfried Donkers 2013-02-21 07:53:03 UTC
Created attachment 75231 [details]
docx saved from new document - see comment 3
Comment 6 Winfried Donkers 2013-02-21 07:53:35 UTC
Created attachment 75233 [details]
docx saved from existing odt document - see comment 3
Comment 7 Miklos Vajna 2013-03-22 17:30:35 UTC
Hi,

I can reproduce this, will have a look. Most probably we should just ignore 'w:position w:val="0"' on import and be done with it.

Winfried,

In case that won't fix your problem, please open a separate bug for your part, the original description didn't refer to any images, so it's possible you hit an independent problem.

Miklos
Comment 8 Miklos Vajna 2013-03-22 17:32:15 UTC
Forgot to note: first I failed to see the problem, an easy way to spot it is to set the zoom level to 219%, then simply comparing the original odt and the imported docx will show the obvious difference.
Comment 9 Winfried Donkers 2013-03-25 07:58:33 UTC
(In reply to comment #7)
> Winfried,
> 
> In case that won't fix your problem, please open a separate bug for your
> part, the original description didn't refer to any images, so it's possible
> you hit an independent problem.
> 
> Miklos

Hi Miklos,

OK, I will test when the patch has been pushed, give my feed back and open a separate bug if my problems persist.

Winfried
Comment 10 Commit Notification 2013-03-25 09:32:01 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

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

fdo#60922 ignore DOCX import of w:position w:val="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 11 Miklos Vajna 2013-03-25 09:40:50 UTC
-4-0 review: https://gerrit.libreoffice.org/2981
Comment 12 Commit Notification 2013-03-25 09:58:57 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f2dac0d945b8f1636ee203ec55cf7f21390e32e&h=libreoffice-4-0

fdo#60922 ignore DOCX import of w:position w:val="0"


It will be available in LibreOffice 4.0.3.

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 13 Winfried Donkers 2013-03-27 12:45:40 UTC
(In reply to comment #7)
> Winfried,
> 
> In case that won't fix your problem, please open a separate bug for your
> part, the original description didn't refer to any images, so it's possible
> you hit an independent problem.
> 
> Miklos

Hi Miklos,

I just tested with version 4.0.2.2; the image problem persists (as I expected).
I tested with daily build of master from yesterday; the image problem persisted.

I created a new bug #62808 and took the liberty to add you to the cc-list.
I also filled in 'see also' for both bugs.