Created attachment 119096 [details] screenshot showing problem When I load a file into Writer, the statusbar used to immediately show the word and character count for the document, no matter what kind of file was being loaded (e.g. ODT, DOC, DOCX, RTF). I have just got the 5.0.2.2 upgrade via PPA, and the statusbar now displays word/character count on file-load *only* for ODT files. For all the others, the count for word and character is "0" until I make some intervention (and a character, delete a character, whatever), and *then* the statusbar updates. I have appended a small PNG showing the "same" file, one in ODT format, the other a DOCX format, both showing the state of the statusbar on file-load. Not a *serious* problem, but it would be good to have this working. I edit a small journal, and use Writer for checking manuscript word-counts - and almost all come in as DOCX!
I just checked this on a MacBook (Early 2015) I have access to, running LibreOffice Version: 5.0.1.2 (Build ID: 8a217da6e01cf55a41786945d955ae21741fd47b) and the behaviour is identical: ODT files load with the word/character count updated. Other filetypes (DOC, DOCX, etc.) register "0 ... 0" for word/character count in the statusbar until the file has been modified in some way.
Reproduced. In 4.3.0.1 it is ok. Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI) Version: 5.1.0.0.alpha1+ Build ID: 25de5cfa43b2b1cb7d7214470acc7719839e13fe TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-01_08:49:54 Locale: en-US (fi_FI)
Works OK in latest range in bibisect-win32-5.0, latest:Version: 5.0.0.0.alpha1+ Build ID: ab465b90f6c6da5595393a0ba73f33a1e71a2b65
*** Bug 94229 has been marked as a duplicate of this bug. ***
*** Bug 95043 has been marked as a duplicate of this bug. ***
This seems to have begun at the below commit. Adding Cc: to ashodnakashian@yahoo.com ; Could you possibly take a look at this one? Thanks 1657a726e928c2b658abceb7deb618f20ef40a72 is the first bad commit commit 1657a726e928c2b658abceb7deb618f20ef40a72 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Jul 29 13:34:37 2015 -0700 source b0fde7a912ff3aa370496802f20895b1158b072c source b0fde7a912ff3aa370496802f20895b1158b072c author Ashod Nakashian <ashodnakashian@yahoo.com> 2015-07-05 16:05:26 (GMT) committer Caolán McNamara <caolanm@redhat.com> 2015-07-15 07:46:01 (GMT) commit b0fde7a912ff3aa370496802f20895b1158b072c (patch) tdf#38837 Reduce power consumption by minimizing idle timers
*** Bug 95291 has been marked as a duplicate of this bug. ***
The problem is reproducible and seems to be caused by my commit. Will provide a fix at the soonest.
I experienced this bug since 5.0.1. (Benoe)
*** Bug 96033 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
This is still present in 5.0.4.2 (Arch Linux) running on i686 architecture. Thee word counts not only do not appear on the status bar, but cannot be obtained from the word count tool either. As a translator who receives many .doc(x) files, this tool is essential and the bug *not* minor at all. While I have LO 5 on a secondary machine (which allows me to check on the status of this bug), I was forced to revert to LO 4 on my main machine after LO 5 became available. I note the comment from the committer (ashodnakashian@yahoo.com) dates from October 2015 and the issue is still present. I am all in favour of reducing power consumption since all my machines are laptops, but if the commit cannot be fixed, perhaps it needs to be completely undone.
(In reply to Roy Reese from comment #12) > This is still present in 5.0.4.2 (Arch Linux) running on i686 architecture. > Thee word counts not only do not appear on the status bar, but cannot be > obtained from the word count tool either. > > As a translator who receives many .doc(x) files, this tool is essential and > the bug *not* minor at all. While I have LO 5 on a secondary machine (which > allows me to check on the status of this bug), I was forced to revert to LO > 4 on my main machine after LO 5 became available. Well it is minor, because the word count *does* show after any change. So there is a workaround and it is a very quick one. https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
(In reply to Roy Reese from comment #12) > I note the comment from the committer (ashodnakashian@yahoo.com) dates from > October 2015 and the issue is still present. I am all in favour of reducing > power consumption since all my machines are laptops, but if the commit > cannot be fixed, perhaps it needs to be completely undone. We appreciate your situation, Roy. This side-effect is unfortunate but it affects only some documents types and not all (.odt is not affected, f.e.). In addition, the benefits of this commit are far more resounding than the side-effect, especially so--as Beluga correctly noted--that a single new-line or space-bar press forces the counter to update. For many the high-cpu usage is not just a power consumption issue, it's a usability issue. On large documents the high-cpu makes editing painfully slow. Finally, we appreciate patches and help anyone willing to take any steps in improving LibreOffice. Rest assured that the committer of the patch in question worked on his own time, at his own expense. It's unfortunate that the results are not ideal, and in spite of his best intentions to follow up with another patch to fix the issue you mention, life isn't ideal either and sometimes we have to accept reality. Again, sorry for the difficulty this is causing you and patches are always welcome.
*** Bug 98391 has been marked as a duplicate of this bug. ***
(In reply to Ashod Nakashian from comment #14) > > We appreciate your situation, Roy. This side-effect is unfortunate but it > affects only some documents types and not all (.odt is not affected, f.e.). > In addition, the benefits of this commit are far more resounding than the > side-effect, especially so--as Beluga correctly noted--that a single > new-line or space-bar press forces the counter to update. > > For many the high-cpu usage is not just a power consumption issue, it's a > usability issue. On large documents the high-cpu makes editing painfully > slow. > > Finally, we appreciate patches and help anyone willing to take any steps in > improving LibreOffice. Rest assured that the committer of the patch in > question worked on his own time, at his own expense. It's unfortunate that > the results are not ideal, and in spite of his best intentions to follow up > with another patch to fix the issue you mention, life isn't ideal either and > sometimes we have to accept reality. > > Again, sorry for the difficulty this is causing you and patches are always > welcome. I appreciate the responses and knowing the "workaround". In fact I had not noticed that the word count updated with the insertion of a character as the time I find it critical is when I need to open a document in order to give a cost estimate. Had I been editing, I would have noted the change. After posting I have actually downgraded my two main systems to LO 4 (now that 5 has gone to stable) and may leave it there for the time being as I see the latest LO-fresh seems to have changed the menus quite a bit and I find them harder to read and work with. Nonetheless, when the LO-5 dust settles and I shift back to LO 5, I will keep the workaround in mind. Two asides: 1) I DO appreciate the contributions that are made and must thank you for the work. Programming is not a way that I am able to contribute, but it is one of the principal benefits of open-source software. 2) For a variety of reasons 99% of my work is done on aging 32-bit laptops, so, while I had not noticed any particularly high cpu usage, it is an important consideration. Thanks much.
(In reply to Roy Reese from comment #16) > Two asides: 1) I DO appreciate the contributions that are made and must > thank you for the work. Programming is not a way that I am able to > contribute, but it is one of the principal benefits of open-source software. Non-programmers can participate in The War On Bugs by doing QA and triage: https://wiki.documentfoundation.org/QA I am happy to mentor all newcomers personally.
*** Bug 98392 has been marked as a duplicate of this bug. ***
reset assignee, assuming accident.
> author Ashod Nakashian <ashodnakashian@yahoo.com> 2015-07-05 16:05:26 (GMT) > committer Caolán McNamara <caolanm@redhat.com> 2015-07-15 07:46:01 (GMT) > commit b0fde7a912ff3aa370496802f20895b1158b072c (patch) > tdf#38837 Reduce power consumption by minimizing idle timers That patch above caused the problem. The document statistic was set to unmodified without ever been updated or assigned. Loading odf assigns the statics value directly while loading other file types requires one initial calculation. Fix is in https://gerrit.libreoffice.org/#/c/23589/1(In reply to raal from comment #6)
Oliver Specht committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=49152948ddfb1a457ab2fc149fcede57dc2c255b tdf#94570: document statistic of none odf files fixed It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Assuming this to be fixed as per comment 21.
*** Bug 99564 has been marked as a duplicate of this bug. ***
*** Bug 100806 has been marked as a duplicate of this bug. ***