| Summary: | FILEOPEN, FILESAVE create document as odt, save as docx , corrupts | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | bravotwo.bugs |
| Component: | Writer | Assignee: | Miklos Vajna <vmiklos> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | osc, timur |
| Priority: | high | ||
| Version: | 4.0.0.3 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=62808 https://bugs.freedesktop.org/show_bug.cgi?id=63059 |
||
| Whiteboard: | target:4.1.0 target:4.0.3 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 54157 | ||
| Attachments: |
Odt that will generate bug when save as docx is used
The docx with display problem Screenshot docx+odt odt file with image - see comment 3 docx saved from new document - see comment 3 docx saved from existing odt document - see comment 3 |
||
Created attachment 74899 [details]
The docx with display problem
Created attachment 74900 [details]
Screenshot docx+odt
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. Created attachment 75230 [details] odt file with image - see comment 3 Created attachment 75231 [details] docx saved from new document - see comment 3 Created attachment 75233 [details] docx saved from existing odt document - see comment 3 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 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. (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 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. -4-0 review: https://gerrit.libreoffice.org/2981 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. (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. |
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