Problem description: The following problem occurs in 3.4 Linux and Windows. I generate a documents in word 2003, which contains comments. These comments are numbered. I save the file in RTF or in doc (2003) format. I open the files in writer, I can see the text and the comments but the comments are not longer numbered. I attach 3 files: comment.rtf comment.doc comment.pdf Current behavior: numbers are not displayed Expected behavior: numbers should be displayed Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7 and windows xp
(In reply to comment #0) > I attach 3 files: > comment.rtf > comment.doc > comment.pdf No files attached in your bug.
Created attachment 60678 [details] RTF document created with MS Word, enumerated comments
Created attachment 60679 [details] pdf version of the attached rtf file
Created attachment 60680 [details] doc (2003) version of the attached RTF file
Confirmed with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Comments are not numbered in both attached files and newly created file. Seems like comments in Writer are not numbered anyway.
This is going down as an enhancement request. I have verified that it's the case but it's not really a bug, LibO works as intended, but this may make it better. I'm going to mark as NEW and prioritize as such. Enhancement - Not a bug but instead an addition that would make LibO work like Microsoft Office in enumerating comments Priority - Low, don't think this will add much functionality to LibO, some users will benefit slightly, probably not many. Thanks for reporting, we'll see if we can get this taken care of
Thanks for your comments. However I disagree with the low priority you want to assign this request. Having enumerated comments help very much to *locate* a comment. Like in the email exchange: comment 3 is very useful comment 5 is nonsense. without having a numbering it is not clear how to refer to these comments. Actually I had to use MS word in order to finish the task! Since I cannot contribute with code I can only ask you to re consider the priority.
Hi Uwe, First let me say thanks for being civil with your request, we all appreciate it. As for raising the priority, I have two points to make: 1. While priorities help guide development, they are not set in stone and when developers look through open bugs they don't use priority as their only rationale. Other reasons would include a general interest in the topic (which you title is really good at saying what this bug is pertaining to), how easy it is implement, and if a developer is already comfortable with that section of the code. So don't be discouraged by the priority, this isn't a really hard enhancement to implement so I don't see it sitting for years 2. When I triage I try to think "what is more important", when I do so I use this chart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg I think at best it would be a minor bug but in reality I see this as an enhancement as LibO is performing how it's designed to perform. Furthermore, you are in the minority using comments already (most users just type), this particular addition would only benefit those users who use comments and want them enumerated which, for them could be very useful, for most users, would never be noticed. Again, this isn't a terribly difficult thing to implement so don't take the low priority as a "this will never get done" it's just a signal to developers to say "crashes, performance degradation, etc..." will clearly be more important on face value than this bug. It's much better to have this bug correctly triaged rather than put at a higher priority than is called for and having devs look at it and think "why in the world was this put so high" If another QA member wants to change the status, feel free to do so, I've explained my rationale, if others disagree, no big deal. Uwe, once again thanks for your civility in your request, it helps and I'll make sure to see if any developers are available to check this out.
SwSidebarWin::CheckMetaText is probably the place to look at. It doesn't appear that the numbers shown are part of the file formats, just merely the count of previous comments by that author. So... SwSidebarWin::CheckMetaText could use its mrMgr member to get the count of sidebarwindows previous to the current one that share the same Author as itself and add an extra widget that displays that count into the window, following e.g. the mpMetadataAuthor or mpMetadataDate examples.
Hi all First of all thank you for this polite answer. Two remarks: As I see from Caolán McNamara remark, enumerated comments might not be part of the ODF or the OOXML specification, do I understand that correctly? There are two issues: 1. Libre Office displays enumerated comments (produced by word) 2. Libre office generate comments, which can be enumerated (at least optionality). I thought that maybe 2 is easier. Regards Uwe
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.