Bug 94570 - STATUSBAR: Word and character count not reported for non-ODT files until altered
Summary: STATUSBAR: Word and character count not reported for non-ODT files until altered
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: x86-64 (AMD64) All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0
Keywords: bibisected, bisected, regression
: 94229 95043 95291 96033 98391 98392 99564 100806 (view as bug list)
Depends on:
Blocks: Word-Count
  Show dependency treegraph
 
Reported: 2015-09-28 12:21 UTC by David
Modified: 2016-10-24 21:20 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot showing problem (60.63 KB, image/png)
2015-09-28 12:21 UTC, David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2015-09-28 12:21:59 UTC
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!
Comment 1 David 2015-09-28 20:52:06 UTC
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.
Comment 2 Buovjaga 2015-10-02 08:13:43 UTC
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)
Comment 3 raal 2015-10-05 09:21:17 UTC
Works OK in latest range in bibisect-win32-5.0, latest:Version: 5.0.0.0.alpha1+
Build ID: ab465b90f6c6da5595393a0ba73f33a1e71a2b65
Comment 4 Buovjaga 2015-10-09 17:36:25 UTC
*** Bug 94229 has been marked as a duplicate of this bug. ***
Comment 5 raal 2015-10-14 12:27:47 UTC
*** Bug 95043 has been marked as a duplicate of this bug. ***
Comment 6 raal 2015-10-15 04:41:45 UTC
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 sha:b0fde7a912ff3aa370496802f20895b1158b072c

    source sha: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
Comment 7 raal 2015-10-27 13:38:02 UTC
*** Bug 95291 has been marked as a duplicate of this bug. ***
Comment 8 Ashod Nakashian 2015-10-27 14:22:25 UTC
The problem is reproducible and seems to be caused by my commit. Will provide a fix at the soonest.
Comment 9 Benoe Baarczy 2015-11-05 15:24:33 UTC
I experienced this bug since 5.0.1. (Benoe)
Comment 10 raal 2015-11-24 19:46:51 UTC
*** Bug 96033 has been marked as a duplicate of this bug. ***
Comment 11 Robinson Tryon (qubit) 2015-12-13 11:14:26 UTC Comment hidden (obsolete)
Comment 12 Roy Reese 2016-02-13 13:13:53 UTC
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.
Comment 13 Buovjaga 2016-02-13 14:58:29 UTC
(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
Comment 14 Ashod Nakashian 2016-02-17 22:24:03 UTC
(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.
Comment 15 Cor Nouws 2016-03-03 22:23:52 UTC
*** Bug 98391 has been marked as a duplicate of this bug. ***
Comment 16 Roy Reese 2016-03-05 19:21:52 UTC
(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.
Comment 17 Buovjaga 2016-03-05 20:22:23 UTC
(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.
Comment 18 Pavlo Chavyr 2016-03-23 07:45:30 UTC
*** Bug 98392 has been marked as a duplicate of this bug. ***
Comment 19 Björn Michaelsen 2016-03-25 02:02:53 UTC
reset assignee, assuming accident.
Comment 20 Oliver Specht (CIB) 2016-03-29 08:24:36 UTC
> 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)
Comment 21 Commit Notification 2016-03-29 09:11:22 UTC
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.
Comment 22 Björn Michaelsen 2016-04-15 13:32:29 UTC
Assuming this to be fixed as per comment 21.
Comment 23 Buovjaga 2016-05-06 11:54:29 UTC
*** Bug 99564 has been marked as a duplicate of this bug. ***
Comment 24 mike.hall 2016-07-09 06:05:51 UTC
*** Bug 100806 has been marked as a duplicate of this bug. ***