Version: 7.1.5.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.utf8); UI: en-US 7.1.5-2 Calc: threaded I hope this is not a duplicate. I found a few (fixed) bugs related to erroneous word count (WC) and tracked changes, but those did not match my observations: When changes are tracked, deleted words are not counted (as expected). However, I experience erroneous word counting when a whole paragraph is deleted: 1) New document 2) Insert this content: w1 w2 w3 w4 w5 3) Select all -> WC 5 4) Activate track changes 5) Delete the second paragraph. Hide the tracked changes; the document shows: w1 w4 w5 6) Select all -> WC 5 (Expectation: WC decreased by 2. Behavior: WC unchanged.) 7) Delete " w5" 8) Select all -> WC 4 (Expectation: WC decreased by 1. Behavior: WC decreased by 1.)
I confirm it with Version: 7.2.0.3 (x64) / LibreOffice Community Build ID: 2a7ea282da28d665a7dc086360567b4aea27bf08 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL I can't see a consinstence behaviour here and I also think, that word count is completely useless in such a case. Second example: 1. Write a sentence with five words 2. Enable record and view track changes 3. Delete that sentence and write a new sentence with three words => WC 8 words The display shows eight words, but for the author, this is a completely irrelevant information. Either the text has three words (if you accept changes) or it has five word (if you reject changes) => NEW I don't know, if there is a consenus about the expected behaviour, but we chould have one. Personally I can sse two possibilities a) Word Count has always the result of the document without showing track changes (that's also the expecatation from bug reporter) b) Word count is disabled, if document shows track changes I would prefer solution b), because it obvious, that you can't count the words with visible track changes in a helpful way. cc: Design-Team for further input and decision.
Reported and fixed (Muhammet) with a unit test (Caolan) in bug 46757. (In reply to Dieter from comment #1) > a) Word Count has always the result of the document without showing track > changes (that's also the expecatation from bug reporter) > b) Word count is disabled, if document shows track changes And c) Measurement with and without TC, see also bug 123083.
No further opinion (and I don't want to keep it on the agenda for the design meeting). So my take is a) respectively WYPIWYG: Show the actual number of words/characters without TC as if it was printed.
(In reply to Heiko Tietze from comment #3) > No further opinion (and I don't want to keep it on the agenda for the design > meeting). So my take is a) respectively WYPIWYG: Show the actual number of > words/characters without TC as if it was printed. O. K. for me (I changed bug summary).
No repro with: Version: 7.0.0.0.alpha1+ (x64) Build ID: 574c57090642347980d2395e1e183cc7b5c171ad CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded Version: 7.1.0.0.alpha1+ (x64) Build ID: 738bcf5e9a8c443d60c29c3a8068e8c16c72638a CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded Repro with: Version: 7.1.8.0.0+ (x64) / LibreOffice Community Build ID: a94b58277c7aeaa83ce14347cd0b8f7137969d03 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded But no repro with: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: df3b95a39472e18ea8acdaae447b7176e37a9256 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded The bug seems resolved in the last version of LibreOffice.
Note: while testing I was looking at word count in the status bar, but Tools - Word Count works the same way. (In reply to f.zit from comment #0) > 1) New document > 2) Insert this content: > w1 > w2 w3 > w4 w5 > 3) Select all -> WC 5 > 4) Activate track changes > 5) Delete the second paragraph. Hide the tracked changes; the document shows: > w1 > w4 w5 > 6) Select all -> WC 5 (Expectation: WC decreased by 2. Behavior: WC > unchanged.) In the latest version this step gives the expected result of 3 words. I bibisected this change with Linux 7.6 repo to 9788a565b3241d1bd62394b9e29c322361d05f80 It seems to be due to this added line in sw/source/uibase/wrtsh/select.cxx: GetView().GetViewFrame().GetBindings().Update(FN_STAT_SELMODE); // make selection mode control icon update immediately > 7) Delete " w5" > 8) Select all -> WC 4 (Expectation: WC decreased by 1. Behavior: WC > decreased by 1.) In the latest version, this gives the unexpected result of 4 words. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8c982bf86ff9ca5a4ed86505ec1133cc183f1b58 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Dear f.zit, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #7) Bug still present as originally described. Version: 25.8.1.1 (X86_64) / LibreOffice Community Build ID: 580(Build:1) CPU threads: 4; OS: Linux 6.16; UI render: default; VCL: kf6 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US 25.8.1-2 Calc: threaded