This bug report pertains to LiberOffice Version: 188.8.131.52, Build-ID: 1:5.1.6~rc2-0ubuntu1~xenial4, CPU-Threads: 4; BS-Version: Linux 4.4; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group. The program runs under Xubuntu 16.04.3 LTS with current linux kernel version 4.4.0-116-generic x86_64
There is a function in LO Writer to track modifications of a document. In the German version this function can be invoked by Bearbeiten>Änderungen verfolgen>Änderungen aufzeichnen.
There is another function which controls, whether tracked modifications of the document are displayed or not (in which case the final version is displayed and all modification are just sored invisibly). In the German version this function can be invoked by Bearbeiten>Änderungen verfolgen>Änderungen anzeigen and this button works as a toggle-switch.
However, if this display mode not to show all deletions, insertions etc in another color is not chosen, it happens to get switched off very often without any user interaction through Bearbeiten>Änderungen verfolgen>Änderungen anzeigen. For example, of you store the current document, LO Writer automatically switches back to the display of modifications.
That’s quite clumsy and tedious, because the display of all modifications is very distracting and one actually wants to show them only in very special circumstances, to my experience.
The state of displaying modifications or not should not be changed except by the user interaction through the named function or its equivalent tool buttons or key combinations (if there are such bindings defined).
One more possible enhancement about recording modifications:
I would like to have four tool buttons (I hope I did not overlook them if they exist, in this case some help to find them would be welcome): One to proceed to the next modified place, one to go back to the last one and one to accept or reject the current modification. The found modification should be highlighted after clicking on one of the first two buttons.
The requested functionality is in principle present: In the German version under Bearbeiten>Änderungen verfolgen>Änderungen verwalten (the English version it might be called “manage modifications”). However you have to know where you are. If the cursor is on some unaltered part of the document, the highlight is on the next modification. So the current work point easily gets lost when working with this method. If the current cursor is on a modified part of the document, the proper modification record is highlighted, in this case it is ok for me.
This function to manage modifications would be improved, if a fat e.g. red line would be shown in the table of modifications between the one before and the one after the position of the cursor in the document, if that happens to be on some unaltered part.
Thank you for reporting the bug. It seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
Dear Adalbert Hanßen,
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 INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
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!
This demonstration is done with LibreOffice
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3;
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Since this is an English version, I now see the English names of the functions in the dialogues.
The relevant functions are (and most of them can also be accessed through View>Toolbars>Track Changes):
1. Edit>Track Changes>Record: If this one is checked, all modifications are recorded, otherwise they are not recorded (and those changes can not be verified as changes later).
2. Edit>Track Changes>Show: If this one is checked, modifications are shown in color and if the mouse is moved over one, the time of the change and the author are shown after a second. Otherwise the changes are not shown, the final version which is reached if all changes were accepted, is shown.
3. Edit>Track Changes>Manage which opens its own dialogue window with two sub-tabs, namely List and Filter.
4. Edit>Track Changes>Manage Tab List shows a list of all recorded changes together with the timestamps of them and the authors, who applied them.
5. Edit>Track Changes>Manage Tab Filter lets you enter criteria to filter changes by time, author, action or comment. Selected changes can be accepted or rejected altogether or one by one.
Other than complained about in the bug report, the Edit>Track Changes>Show flag is no longer set to True when the file gets stored.
It looks like this part of https://bugs.documentfoundation.org/show_bug.cgi?id=120729 is fixed in this version 184.108.40.206.alpha0+ used for my test.
I also made some more proposals to improve revising documents. One of my proposals dealt with going from one change to the next one or to the last one. If one uses Edit>Track Changes>Manage Tab List, the changes shown in that list reflect the order of the changes in the text. If one clicks on one of them in the Manage Changes dialogue with List, this immediately moves the cursor to the associated change. So by going through the list in forward or backward direction, it is now possible, to accept or reject the changes in the text and to quickly move to the next change without first having to search for it. Also this can be done with the purple bckwards arrow or with the blue foreward arrow in the View>Toolbars>Track Changes View>Toolbars>Track Changes toolbar.
However, the counterpart to selecting a changed position in the editor window does not move the mark in the corresponding Edit>Track Changes>Manage Tab List window. In order to find the appropriate change, one might sort the changes by time and then search the right one by looking at the time stamp shown by the mouse-over action in the editor window. That’s a bit awkward!
By using the criterion Action of the dialogue Edit>Track Changes>Manage Tab Filter, one can for example select Formats to select all format changes. If this is done, those format changes are selected in the parallel Edit>Track Changes>Manage Tab List dialogue. There they can be accepted all together, rejected altogether or accepted or rejected case by case ony dealing with format changes.
However, when revising a document, one often does not want to care for formatting issues and many formatting changes are very distracting. So it is advisable to be able to not show any format changes (all formatting stuff including insertion and deletion of multiple white spaces, replacing spaces with non-breaking spaces and vice versa, replacements of spaces with tabs and vice versa). Also it might be beneficial, to also suppress any orthography amendments (e.g. through something related to spell checking) and all amendments with respect to punctuation, since in almost all cases such changes are done on the fly and a subsequent proofreader prefers not be distracted by many of such (in most cases) unsubstantial changes.
Edit>Track Changes>Manage Tab Filter with selection of Date seems to have no influence: I would expect that they also operate on the changes shown in the Edit>Track Changes>Manage Tab List window and preferably those changes not selected through the filter criteria are not shown highlighted in the editor window (i.e. they all are shown as if they had been all accepted). Right now the modifications filtered out of the List window are shown in the editor window despite the filter function. The suppressed modifications are shown with highlight despite they are deselected through the filter critereon. That might be improved.
By the way: a version of Microsoft Word for Windows which I have used for some extended time before I completely switched to Linux+LibreOffice had the ability to not show all changes which only dealt with formatting. I often switched that off when revising documents.
I have seen, there already is a function to accept all changes in the marked part of the document: It can be found under Context Menu (of selected part of the document in the editor window) >Accept Change or Context Menu>Reject Change.
I'll also upload this comment as an odt file which has some Track Changes recorded in it, so that one has an easy start point for accepting or not accepting a document, applying format changes on the fly and see how easy it is to proceed with those functions. I would see myself often switching recording changes on and off between corrections of typing errors, correcting wrong punctuation and typos and real work on the text.
Created attachment 151254 [details]
My last comment as a playground to test a document with some changes in it
Please give enumerated steps on what we need to test with your document in order to confirm the issue (note: 1 issue per report).
Also edit the summary to describe the single issue you want this report to be about.
There have been further improvements to change tracking throughout the year 2019, so do also test with the latest version.
I understood the last comment by Buovjaga that I should file a new bug report after checking the issue with an actual version of LibreOfficeDev. I have done so, which resulted in
(In reply to Adalbert Hanßen from comment #6)
> I understood the last comment by Buovjaga that I should file a new bug
> report after checking the issue with an actual version of LibreOfficeDev. I
> have done so, which resulted in
So we can close this bug?
(In reply to Dieter Praas from comment #7)
> (In reply to Adalbert Hanßen from comment #6)
> > I understood the last comment by Buovjaga that I should file a new bug
> > report after checking the issue with an actual version of LibreOfficeDev. I
> > have done so, which resulted in
> > https://bugs.documentfoundation.org/show_bug.cgi?id=127098
> So we can close this bug?
Yes, we can close it. - Parts of what I have complained about are already in the current version. I change the status to "RESOLVED/WORKSFORME", therefore. The rest is more elaborated in in my new report.