Bug 50141 - : Word Count Characters (with spaces) incorrect with Numbering on
Summary: : Word Count Characters (with spaces) incorrect with Numbering on
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.3 release
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Muhammad Haggag
URL:
Whiteboard: BSA target:3.6.0.0.beta2 target:3.7.0...
Keywords: regression
Depends on:
Blocks: Word-Count 51908
  Show dependency treegraph
 
Reported: 2012-05-20 02:20 UTC by kmitko
Modified: 2019-03-02 12:10 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
A test document to reproduce the problem. (8.93 KB, application/vnd.oasis.opendocument.text)
2012-05-20 02:20 UTC, kmitko
Details
Proposed patch. (1.25 KB, patch)
2012-06-09 14:54 UTC, Muhammad Haggag
Details
Screenshot after step 3 (5.84 KB, image/png)
2012-07-06 08:35 UTC, pierre-yves samyn
Details
Screenshot after step 4 (5.69 KB, image/png)
2012-07-06 08:36 UTC, pierre-yves samyn
Details
Screenshot after step 5 (5.75 KB, image/png)
2012-07-06 08:37 UTC, pierre-yves samyn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kmitko 2012-05-20 02:20:04 UTC
Created attachment 61877 [details]
A test document to reproduce the problem.

Problem description: 

Word count shows incorrect number of characters with spaces if numbering is on. 

(This is a copy of Ubuntu bug #1001556 <https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1001556> as requested there)

Steps to reproduce:
1. Open the attached file test.odt (one line saying "test test" with numbering on).
2. Tools -> Word Count

Current behavior:

Word count shows 2 characters with spaces and 10 without spaces.

Expected behavior:

Word count should show 12 characters with spaces and 10 without.

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Comment 1 Stefan Knorr (astron) 2012-06-06 04:30:00 UTC
Can reproduce on LibreOffice 3.6 a1+.


Curiously, the problem goes away when one adds a second item to the numbering.
Comment 2 Muhammad Haggag 2012-06-09 09:21:13 UTC
Investigating.
Comment 3 Muhammad Haggag 2012-06-09 14:54:23 UTC
Created attachment 62850 [details]
Proposed patch.

Added a patch.

Note that if you were to test the patch using the attached test document (61877), you have to type a character first to invoke the fixed character counting code and show the correct count. The initial character count for the document is loaded from the document statistics, and is incorrect because it was calculated without the patch.
Comment 5 Not Assigned 2012-06-11 04:07:27 UTC
Muhammad Haggag committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=29ff3d49c8f0bc45a322d3ab67300bd269593181&g=libreoffice-3-6

fdo#50141: Character count (with spaces) incorrect with numbering on.


It will be available in LibreOffice 3.6.
Comment 6 Not Assigned 2012-06-11 04:07:52 UTC
Muhammad Haggag committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a585863f013aa4207270e11f5e031126adf1ed4a

fdo#50141: Character count (with spaces) incorrect with numbering on.
Comment 7 Not Assigned 2012-06-11 04:15:01 UTC
Muhammad Haggag committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fbfc736fcdf06bd2d02aac7fe83cd3080c897c27&g=libreoffice-3-5

fdo#50141: Character count (with spaces) incorrect with numbering on.


It will be available in LibreOffice 3.5.5.
Comment 8 Michael Stahl (allotropia) 2012-06-11 04:19:39 UTC
interesting, that looks like a regression from 12db5315fca413ae66e88c4cd8212ee3b01667b7
"Follow UAX-29 and present user-perceived character counts".
Comment 9 Caolán McNamara 2012-06-11 06:57:04 UTC
groan... 
- nTmpChars += nNumStringLen;
+ nTmpChars = pBreakIt->getGraphemeCount(aNumString);
yup.
Comment 10 pierre-yves samyn 2012-07-06 08:35:44 UTC
Created attachment 63895 [details]
Screenshot after step 3
Comment 11 pierre-yves samyn 2012-07-06 08:36:44 UTC
Created attachment 63896 [details]
Screenshot after step 4
Comment 12 pierre-yves samyn 2012-07-06 08:37:12 UTC
Created attachment 63897 [details]
Screenshot after step 5
Comment 13 pierre-yves samyn 2012-07-06 08:43:56 UTC
Hello

It seems to remain a problem in the word count in case of paragraph numbering

Steps to reproduce:

1. File> New> Text Document
2. Type "test" then apply numbering (toolbar Formatting)
3. Tools> Word count

Actual result: 1 word, character 4
Expected result: 2 words, 6 characters

see Screenshot after step 3

4. Type <Enter> then Tools> Word count

Actual result: 2 words and six characters
Expected result: 3 words, 8 characters

see Screenshot after step 4

5. Type <Enter>

Actual & Expected results: stop numbering & 6 characters and 2 words

see Screenshot after step 5

The problem seems to be the "pending" status after Step 4. If we redo <enter> (step 5) will cancel the current numbering. These are the "waiting" numbers which are not counted ... but they are there and IMHO they should be counted.

Platform: Windows 7 64bits & Version 3.6.0.0.beta3 (Build ID: 3e2b862)
Reproduced on XP (en-discuss)

Regards
Pierre-Yves
Comment 14 Muhammad Haggag 2012-07-06 23:23:07 UTC
Confirmed. I'll be investigating it shortly.
Comment 15 Caolán McNamara 2012-07-09 13:30:14 UTC
Investigating the issue with comment #13 I find that its a pre-existing problem and not a regression so...

I've split this bug, and reset the original regression report back to fixed and closed the additional problem as bug 51908
Comment 16 Rainer Bielefeld Retired 2012-08-03 09:21:46 UTC
We need exact and correct target information for automated lists in Wiki and LibO Web Site.