In the latest release (3.3.0.4), when opening, editing, and saving a document in .doc format, the comments are not preserved. That is, upon reopening a saved document, the comments are no longer present. I have tested this using the .odt format, and all works correctly. I have not tested other document formats.
In additional testing, this seems specific to the .docx format. Comments are retained when editing and saving .doc format documents.
confirmed, docx doesn't export comments, lubos fancy taking a cut at this?
This is a dataloss issue (can we add a dataloss keyword?) as I lost comments that I made on a small document last night. This happens on my Mac as well, should be all platform.
*** Bug 35602 has been marked as a duplicate of this bug. ***
I can confirm this behavior (docx only) for release 3.3.2 on Linux x86 rpm and Win32 builds: buildid=330m19(Build:202) Steps to reproduce: 1. Menubar: File->New->Text Document 2. Add some arbitrary short text to the document 3. Menubar: Insert->Comment 4. Add some text to the comment field 5. Menubar: File->Save As 6. Choose a file name and any of the two ".docx" file types for saving. 7. Close the document 8. Re-open the .docx document 9. Observe the missing comment.
@Richard and Lubos: I suggest to choose a more fitting description for the bug like: "DOCX: Document's comments are lost after document is saved in .docx format and then closed." As reporter or owner of the bug, would you please consider changing the description? Thanks.
I guess the comments (serialised as fields?) don't pop out of: sw/source/filter/ww8/docxattributeoutput.cxx (DocxAttributeOutput::EndRun) - somehow or in StartField_Impl (?). It does indeed seem that the data is discarded on export; hmm.
(In reply to comment #7) > I guess the comments (serialised as fields?) don't pop out of: > > sw/source/filter/ww8/docxattributeoutput.cxx (DocxAttributeOutput::EndRun) - > somehow or in StartField_Impl (?). > > It does indeed seem that the data is discarded on export; hmm. DocxAttributeOutput::PostitField(...) needs an implementation, worse since you don't output the comment but a reference to the comment you need to cache those comments ( per document/paragraph ? ) and then dump the comment meta-data into a comments.xml file in the docx zip.
I can confirm that comments are not being saved. Ubuntu 10.10, as updated. I repeated karlsen-masur@dfn-cert.de's experiment in comment 5. Has anyone experimented to see if comments created in Word, and re-saved in Writer are also lost? Sorry, I don't have Windows or Word and so cannot perform the experiment. charles@yendi:~$ pre libreoffice libreoffice-debian-menus 3.3-202 all libreoffice3 3.3.2-19 amd64 libreoffice3-base 3.3.2-19 amd64 libreoffice3-calc 3.3.2-19 amd64 libreoffice3-dict-en 3.3.2-19 amd64 libreoffice3-dict-es 3.3.2-19 amd64 libreoffice3-dict-fr 3.3.2-19 amd64 libreoffice3-draw 3.3.2-19 amd64 libreoffice3-en-us 3.3.2-19 amd64 libreoffice3-impress 3.3.2-19 amd64 libreoffice3-math 3.3.2-19 amd64 libreoffice3-ure 1.7.0-19 amd64 libreoffice3-writer 3.3.2-19 amd64 charles@yendi:
*** Bug 34542 has been marked as a duplicate of this bug. ***
"Has anyone experimented to see if comments created in Word, and re-saved in Writer are also lost? Sorry, I don't have Windows or Word and so cannot perform the experiment." Of course they are.
Title changed as per request.
Confirmed using 3.4, Ubuntu version. All attention appreciated. This is a dealbreaker for for anyone who works in a MS-driven office with collaborative documents.
[Reproducible] for XMS2007 and OPEN XML with "LibreOffice 3.4.1RC1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:103)]". No comments shown in MS WORD viewer. Modified Status due to facts
Comments created in Word are not lost when stored as an odt file.
Created attachment 50106 [details] .doc file with a comment Word comments are with respect to a region, whereas OpenOffice comments reference a point in the text.
(In reply to comment #16) > Created an attachment (id=50106) [details] > .doc file with a comment > > Word comments are with respect to a region, whereas OpenOffice comments > reference a point in the text. Is the region vs point a difference in Word and OO implementation, or what OOXML and ODF support? If former, seems like another bug should be filed against OO re region comment support, if latter, against ODF. (I did a few quick web searches and did not find any helpful leads to answer my question above; "comment" is not really a helpful term. :-(.)
Implemented in master for 3.5.
*** Bug 32779 has been marked as a duplicate of this bug. ***
Confirming that this bug still exists in LibreOffice 3.4.2 OOO340m1 (Build:203) on Fedora 15. Is there a patch for 3.4.2 or do we need to wait for 3.5? If the latter, As others have stated, this is a critical DATA LOSS bug and makes LibreOffice unsuitable for a production environment in it's current state.
Can someone please post the commit hash(es) for the fix, so end users can generate diffs -- id like to rebuild my own local version with this patch fixed.
Lubos Lunak, could you please provide a commit for this fix?
Created attachment 54358 [details] comment export patch I extracted a patch (there was no single commit that added this) for a potential 3.4.x merge - testing much appreciated, will try to get it into 3.4.5 RC1.
(In reply to comment #23) > Created attachment 54358 [details] [review] > comment export patch > > I extracted a patch (there was no single commit that added this) for a > potential 3.4.x merge - testing much appreciated, will try to get it into 3.4.5 > RC1. Do you mean we can test it in 4.4.5 rc1 once that is out or is there a chance for "normal" users to test it in some other snapshot build? If the latter and someone can provide a link/hint for downloading a snapshot build containing your patch, I will try it out.
fix is pushed to libreoffice-3-4 and should be in 3.4.5 rc1. Unfortunately, it seems to provoke a (prolly) unrelated import problem, such that comments end up with some double-strike-out style if you re-import them ;-) but at least there is no data loss.
*** Bug 43545 has been marked as a duplicate of this bug. ***
*** Bug 46101 has been marked as a duplicate of this bug. ***
*** Bug 47268 has been marked as a duplicate of this bug. ***