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
@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
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.
Created attachment 76792 [details] original1
Created attachment 76793 [details] copy1
Created attachment 76794 [details] original2
Created attachment 76795 [details] copy2
(See my previous post.)
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?
Created attachment 76818 [details] the finished doc should look like this
Created attachment 76819 [details] The docx looks like this after reopening
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
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.
Version is oldest version we confirm the issue, not the latest tested on. Thanks
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. >
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
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.
(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
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. >
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
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!
(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
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
I asked what this bug is about and there was no reply. Also: - it's highly unlikely that any bugs of type "multiple problems with this file/bad rendering/this should look like", will be fixed - each issue (section break, paragraph break, text box, picture...) should be reported separately, but only after a search for already reported bugs - if bugs don't exist, they should be reported separately, even if they happen with the same file - example file should be reduced to minimum test case for a specific problem - FILEOPEN problems are differenet from FILESAVE, and DOC is different filter from DOCX - if there's a problem with saving to DOCX, there should be original ODT to test, direct saving to DOC/DOCX doesn't reveal how it was supposed to look like. So, this shouldn't have been confirmed at all. Those who confirm should also check each problem in the newer versions up to the current master. I'll close this one as Invalid.