Description: In Microsoft Word, it is possible to print a list of tracked changes only, without the rest of the document. See the first point of this blog post, which gives a screenshot: https://theopendesk.com/2018/09/19/summarising-tracked-changes-word/comment-page-1/ If there are many changes to a long document, this can help a reviewer quickly see the edit history: who edited what, and when. Please consider implementing something similar in Writer. It would be really awesome if the output was to an ods file (or something else import-able into Calc), with each edit on a separate line, with columns for "Author", "Edit Time", "Changed Text","Added/Deleted" (i.e, what happened to the "Changed Text"), and whatever the best positional information available is (e.g., character position). That way one could then sort to see the most salient information: changes in chronological order, changes by a particular person, changes in document order, etc. That would I suppose have to be some sort of export, rather than part of the printing functionality. If you were doing it as a print output, there is similar functionality of "print comments only" in the "LibreOffice" tab of the print dialog, so if that were the method you choose (i.e., print rather than export), a checkbox/dropdown there ("print changes only") would seem most logical UI. Steps to Reproduce: n/a Actual Results: n/a Expected Results: n/a Reproducible: Always User Profile Reset: No Additional Info: n/a
Cross reference to ask.libreoffice.org question https://ask.libreoffice.org/t/is-there-any-way-to-print-a-list-of-only-tracked-changes-without-the-rest-of-the-document-in-writer/104216
I was very surprised, that I couldn't find a similiar report. Personally I won't see an advantage in printed list (using the overviw in sidebar or manage changes dialog is better for me), but of course, there might be different opinions. So let's ask design-team.
I wonder if you are aware of the sidebar deck that lists all TC. Besides, printing sounds very niche (and we have the responsibility of conservation) but export to Calc might make sense. However, assuming you can sort in Writer's sidebar (just filtering for now), what is a spreadsheet good for then? And last but not least the extension on ask.libreoffice looks promising, if we decide this to be a special use case for only a few users.
I support this feature request, or rather: I support the ability to export the list of tracked changes. (In reply to Heiko Tietze from comment #3) > printing sounds very niche (and we have the responsibility of > conservation) Disagree. If it is not niche to go over the tracked changes (e.g. in a sidebar), it is not niche to export/print them. Export could be: * to a Writer document with the changes in sequence - in styled paragraphs. * to a Calc table (not a CSV table, since we need the formatting), maybe. and the export could be either into a file or into a new document. The file can then be printed.
We discussed the topic in the design meeting. The proposed macro solution seems to be the right way to tackle this niche use case.
(In reply to Heiko Tietze from comment #5) > We discussed the topic in the design meeting. The proposed macro solution > seems to be the right way to tackle this niche use case. 1. See my last comment 2. How does the macro reproduce complex, formatted, Writer objects within that Calc spreadsheet? Suggest reopening.
(In reply to Heiko Tietze from comment #3) > I wonder if you are aware of the sidebar deck that lists all TC. The sidebar just gives the author and the date of each change, which is completely useless: If I just distribute this list, even together with the PDF of the full document (the ODT file itself is private and must not be distributed), the users will not be able to do anything with it. (In reply to Heiko Tietze from comment #5) > We discussed the topic in the design meeting. The proposed macro solution > seems to be the right way to tackle this niche use case. Macros are typically disabled for security reasons.
Feel free to reopen.
OP here. The macro works well for me. Heiko writes "The proposed macro solution seems to be the right way to tackle this niche use case". So it sounds like the macro is good. My last question is: since it is good, would it make sense to have it become part of the "Application Macros" that ship with LibreOffice? Or stated more generally: is a comment on ask.libreoffice.com the best place for a high-quality (if niche) macro to reside, or is there somewhere better?
This boils down to the question how many users need this function. If it's not more than 1% I'd say shipping the macro or making it somehow more easy to find is not necessary. Search machines crawl ask.libreoffice and find the topic. If we talk about up to 10%, which you seem to expect, it's a different topic. In this case a macro might not be the appropriate solution.
(In reply to Heiko Tietze from comment #10) > This boils down to the question how many users need this function. I would say it does not. You see, there's a principle involved: If you can show the user just the tracked changes on screen, it's a reasonable expectation to be able to get that "view" exported from the app. > If it's > not more than 1% I'd say shipping the macro or making it somehow more easy > to find is not necessary. Search machines crawl ask.libreoffice and find the > topic. If we talk about up to 10%, which you seem to expect, it's a > different topic. In this case a macro might not be the appropriate solution. 1% is already a lot. Many of our features are used by less than 1% of users (who are at least 50K people, if we assume 50M users). I actually believe it is more like 5% who would say they want it, and 10% or more who may find it useful if it were available. But this would not necessarily reflect in ask.lo.org posts. Perhaps the most visible bugs I've filed about RTL - with 50% or even 100% visibility to users - have never had any posts about them, because people just assumed that "it is how it is", and because extremely few people ask anything on ask.lo.org - unfortunately.
(In reply to Eyal Rozenberg from comment #11) > 1% is already a lot. Many of our features are used by less than 1% of users > (who are at least 50K people, if we assume 50M users). Note that 1% of 50M is 500K. Yes, we have such a scale, that 1% is already a huge number; this is the same thing that makes the "most people do not file bugs, that's why we don't have related issues in Bugzilla" argument unapplicable to our project. About the proposed feature: having a respective extension would IMO be adequate.
(In reply to Mike Kaganski from comment #12) > Note that 1% of 50M is 500K. Sorry, mistype :-( > Yes, we have such a scale, that 1% is already a > huge number; this is the same thing that makes the "most people do not file > bugs, that's why we don't have related issues in Bugzilla" argument > unapplicable to our project. Unfortunately - it is applicable. There are bugs experienceds by millions of users on a daily basis which I have been the first one to file, despite their having been manifesting since OpenOffice times. > About the proposed feature: having a respective extension would IMO be > adequate. Well, it would be tolerable. But - that is not, I believe a justification of WONTFIX. To mark something as WONTFIX, it must be _better_ for LibreOffice to not have the feature than to have it. Consistency and and avoidance of excessive complexity can be arguments for WONTFIX; but in this case - missing this introduces an aspect of inconsistency, as well as frustrating user expectations. I would say that the lack of previous bug reports about this should lead us to assign this a lower priority rather than a WONTFIX. As you can tell, though, I don't feel strongly enough about this to just reopen and claim that we absolutely must have this.