Bug 61667

Summary: EDITING: saving in MS Word docx
Product: LibreOffice Reporter: hunter.croil
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: NEW --- QA Contact:
Severity: normal    
Priority: medium CC: jmadero.dev, jorendc
Version: 4.0.0.3 release   
Hardware: All   
OS: All   
Whiteboard: BSA
i915 platform: i915 features:
Attachments: original1
copy1
original2
copy2
the finished doc should look like this
The docx looks like this after reopening

Description hunter.croil 2013-03-01 17:27:58 UTC
Problem description: LibreOffice inserts its own text flow and paragraph formatting, contrary to that which the formatting the text in the doc when saved.

Expected behavior: When specific paragraph format changes are made to single paragraphs here and there within the doc, LibreOffice should not change that formatting to whatever default formatting it may have. This sometimes happens with page formatting as well.

It's not clear or easy to change the default formatting, and then to make it stick for any single doc.

              
Operating System: Windows 7
Version: 4.0.0.3 release
Comment 1 Jorendc 2013-03-01 17:46:28 UTC
@Bug reporter: Is it possible for you to add a step-by-step walkthrough how we can reproduce your behavior?

Kind regards,
Joren

-------------------
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-list
Comment 2 Joel Madero 2013-03-18 23:01:06 UTC
marking as NEEDINFO - we need reproducible steps and a test document if applicable. Once steps and attachment (if possible) are added, mark as UNCONFIRMED and we'll investigate.
Comment 3 hunter.croil 2013-03-20 01:30:33 UTC
Created attachment 76792 [details]
original1
Comment 4 hunter.croil 2013-03-20 01:31:07 UTC
Created attachment 76793 [details]
copy1
Comment 5 hunter.croil 2013-03-20 01:33:44 UTC
Created attachment 76794 [details]
original2
Comment 6 hunter.croil 2013-03-20 01:34:08 UTC
Created attachment 76795 [details]
copy2
Comment 7 hunter.croil 2013-03-20 01:35:16 UTC
(See my previous post.)
Comment 8 hunter.croil 2013-03-20 01:44:12 UTC
Seems when I was seeing if I could attach more than one file I lost my first comments that accompanied the attachments. Again, albeit more briefly this time:

-- Original1/copy1: when making a copy of the file to then make edits and formatting changes the copy wouldn't retain the logo object. It showed in the original copy, but then after saving it and coming back to it the next day the logo was missing, tho it was still there in the original file.

-- Original2/copy2: similar to the above except that the copied file doesn't retain the table size settings after saving and closing it, coming back to it a day or so later.

Similar things happen with various paragraph formatting. It seems that LO doesn't hold the new settings, but rather reverts back to some internal default values. It's like LO tries to interpret or has some default settings that presume what may be best at least in average situations?--I don't know. My main question is how do I turn off any or all default settings so I can set my own as I go file by file?
Comment 9 hunter.croil 2013-03-20 14:32:21 UTC
Created attachment 76818 [details]
the finished doc should look like this
Comment 10 hunter.croil 2013-03-20 14:33:27 UTC
Created attachment 76819 [details]
The docx looks like this after reopening
Comment 11 QA Administrators 2013-09-24 01:44:05 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team
Comment 12 hunter.croil 2013-09-24 15:34:41 UTC
Thank you for informing me that I needed to change the NEEDINFO designation to UNCONFIRMED.

I'm now on LO 4.0.5.2 and there are still problems with saving a doc and the doc not retaining my formatting or paragraph settings. Another example is LO randomly inserting "Keep With Next Paragraph" settings. I specifically uncheck the box both in the overall Styles and Formatting set up and in that particular paragraph's individual paragraph Text Flow setting.

This is similar to the difficulties with Tables "automatically" inserting very large "Spacing to Content" rendering the cell contents invisible. When the Spacing to Content is adjusted the cell content reappears.

I'd also like to find out how I can turn off all automatic formatting settings. I prefer all my formatting (page, paragraph, table, etc) settings to be completely manual--no interpretive settings made by LO.
Comment 13 Joel Madero 2013-09-24 15:38:30 UTC
Version is oldest version we confirm the issue, not the latest tested on. Thanks
Comment 14 hunter.croil 2013-09-24 15:55:43 UTC
Okay.  Sounds good. Tx!


On 9/24/2013 10:38 AM, bugzilla-daemon@freedesktop.org wrote:
> Joel Madero <mailto:jmadero.dev@gmail.com> changed bug 61667 
> <https://bugs.freedesktop.org/show_bug.cgi?id=61667>
> What 	Removed 	Added
> Version 	4.0.5.2 release 	4.0.0.3 release
>
> *Comment # 13 <https://bugs.freedesktop.org/show_bug.cgi?id=61667#c13> 
> on bug 61667 <https://bugs.freedesktop.org/show_bug.cgi?id=61667> from 
> Joel Madero <mailto:jmadero.dev@gmail.com> *
> Version is oldest version we confirm the issue, not the latest tested on.
> Thanks
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>
Comment 15 Jorendc 2013-11-17 19:32:08 UTC
Tested using Mac OSX 10.9 and LibreOffice Version: 4.2.0.0.alpha1+
Build ID: 868103846b9b32bfecd77c08055fdca69d0265c2
TinderBox: MacOSX-x86@48-TDF, Branch:master, Time: 2013-11-14_23:51:46
I think the behavior is much improved :)!

I opened the original document, resaved it with another name as .docx and opened that docx. Then I compared that document with your provided copy of your result. With my tests you don't lose the image (no read error) in original1. Also the table doesn't split up in original2 and it saves/opens the column sizes correctly. I still see in Original1 on the second page an incorrect placed image. Also the table in original2 isn't 100% imported correctly. The first column isn't adjusted to the width of the longest sentence in that column. That's why in word the whole table is on page 1, in LibreOffice there are still 4 rows on the second page.

Kind regards,
Joren
Comment 16 hunter.croil 2013-11-23 21:02:55 UTC
A couple clarifiers: I don't use Word, only LO. I created the original files in LO. There wasn't a problem with the table breaking over two pages, only with LO inserting a 1.97" margin or tab at the beginning of the top-left cell (title row), which I did not insert. LO inserted it on it's own.

Concerning the incorrectly placed image; that's a separate problem--LO moving images to different places other than where on the page they were when the file was saved and closed.

You said the table wasn't imported correctly. How do you import it correctly?--Especially when the table was created in LO.
Comment 17 Jorendc 2013-11-24 20:29:48 UTC
(In reply to comment #16)
> A couple clarifiers: I don't use Word, only LO.
Just a simple question then, why you don't save it as ODF format (.odt, .ods, ...)? This is so far, and probably the only format we support 100% (and even beyond (read: extended)).

> I created the original files
> in LO. There wasn't a problem with the table breaking over two pages, only
> with LO inserting a 1.97" margin or tab at the beginning of the top-left
> cell (title row), which I did not insert. LO inserted it on it's own.

Might be some error when exporting to/importing from docx. Not sure about that, and if it's still reproducible with current version. If you already saved it with multiple versions of LibreOffice, it's hard to determine which version introduced this.
 
> Concerning the incorrectly placed image; that's a separate problem--LO
> moving images to different places other than where on the page they were
> when the file was saved and closed.
Indeed, differnt problem, so if you would like to address it, you'd have to create a new bug report. 
> 
> You said the table wasn't imported correctly. How do you import it
> correctly?--Especially when the table was created in LO.

Not sure you can manually change something about that without digging into the code and determine which caused this behavior. I only see that all text in the first column is in 1 line when importing using Word. When importing using LibreOffice some long sentences are placed on 2 lines, which result in more vertical space needed. So that's why 3 rows (if I recall correctly) are on page 2, not on 1 page.

I also know there are some various improvements made related to docx compatibility in LibreOffice 4.2.0. Still not 100%, which we probably can't guarantee actually. So I still recommend to use an ODF format when you don't have to edit it on MS Office (or share with someone that uses MS Office). If you don't have to edit it again (or your correspondent), you can use PDF too.

Kind regards,
Joren
Comment 18 hunter.croil 2013-11-24 20:50:34 UTC
Thanks, Jorend. Good advice.

I use docx because most people I work with use Word, only a few of us 
are using LO. It's nice to hear that 4.2 is addressing some of the 
idiosyncrasies.

Have a great day.



On 11/24/2013 2:29 PM, bugzilla-daemon@freedesktop.org wrote:
>
> *Comment # 17 <https://bugs.freedesktop.org/show_bug.cgi?id=61667#c17> 
> on bug 61667 <https://bugs.freedesktop.org/show_bug.cgi?id=61667> from 
> Jorendc <mailto:jorendc@libreoffice.org> *
> (In reply tocomment #16  <show_bug.cgi?id=61667#c16>)
> > A couple clarifiers: I don't use Word, only LO.
> Just a simple question then, why you don't save it as ODF format (.odt, .ods,
> ...)? This is so far, and probably the only format we support 100% (and even
> beyond (read: extended)).
>
> > I created the original files
> > in LO. There wasn't a problem with the table breaking over two pages, only
> > with LO inserting a 1.97" margin or tab at the beginning of the top-left
> > cell (title row), which I did not insert. LO inserted it on it's own.
>
> Might be some error when exporting to/importing from docx. Not sure about that,
> and if it's still reproducible with current version. If you already saved it
> with multiple versions of LibreOffice, it's hard to determine which version
> introduced this.
>
> > Concerning the incorrectly placed image; that's a separate problem--LO
> > moving images to different places other than where on the page they were
> > when the file was saved and closed.
> Indeed, differnt problem, so if you would like to address it, you'd have to
> create a new bug report.
> >
> > You said the table wasn't imported correctly. How do you import it
> > correctly?--Especially when the table was created in LO.
>
> Not sure you can manually change something about that without digging into the
> code and determine which caused this behavior. I only see that all text in the
> first column is in 1 line when importing using Word. When importing using
> LibreOffice some long sentences are placed on 2 lines, which result in more
> vertical space needed. So that's why 3 rows (if I recall correctly) are on page
> 2, not on 1 page.
>
> I also know there are some various improvements made related to docx
> compatibility in LibreOffice 4.2.0. Still not 100%, which we probably can't
> guarantee actually. So I still recommend to use an ODF format when you don't
> have to edit it on MS Office (or share with someone that uses MS Office). If
> you don't have to edit it again (or your correspondent), you can use PDF too.
>
> Kind regards,
> Joren
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>
Comment 19 Joel Madero 2013-11-24 20:57:32 UTC
My advice is to always use .doc - Microsoft keeps screwing up the .docx format (proof is that many times the format is broken if you make a file in Microsoft Office 2013 and then try to open the file in Microsoft Office 2007) -- they can't even keep up with their own format, so it's pretty hard for us to keep up with it. The .doc support is quite a bit better (although still needs some work) in LibreOffice
Comment 20 Joel Madero 2013-11-24 20:58:13 UTC
In the future please reply directly to the bug (ie. not via email) - it clutters the bug tracker with additional text that makes it hard to follow. Thanks!
Comment 21 Jorendc 2013-11-24 22:12:21 UTC
(In reply to comment #19)
> My advice is to always use .doc - Microsoft keeps screwing up the .docx
> format (proof is that many times the format is broken if you make a file in
> Microsoft Office 2013 and then try to open the file in Microsoft Office
> 2007) -- they can't even keep up with their own format, so it's pretty hard
> for us to keep up with it. The .doc support is quite a bit better (although
> still needs some work) in LibreOffice

IMHO .doc is less supported with my experience. I can't tell you that with 100% knowledge of the underlying know-how. But as far I know the .doc import/export code is hard to understand. Most enhancements regard compatibility with MS Office are made on .docx. Here you can see some awesome work, done by our developers related to this matter: http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=docx
I know .docx is more complex then .doc, but from my experienced better supported and it's "easier" (compared to .doc) to make improvements on this side. Testing with your usecase is recommended.

Kind regards,
Joren
Comment 22 Timur 2015-01-19 16:23:24 UTC
After reading, it's not clear what this bug is about. Each problem should be first searched for. For example, for images, there are Bug 37315 to Bug 77794, multiple bugs with EMF/WMF, etc. 
If bugs don't exist, they should be reported separately, even if they happen with the same file. Please test with current LO versions.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.