Created attachment 80511 [details] Screenshot of the issue Problem description: When adding a comment in a the middle of a word, the word is then recognised as misspelt by the spellchecker. Furthermore, running the Spelling and Grammar tool and correcting the broken word makes the comment disappear. Steps to reproduce: 1. With Auto Spellcheck on, write a sentence 2. Click in the middle of a word and add a comment (ctrl + alt + C) 3. Write something in the comment field and click out 4. The word is underlined in red 5. Run the Spelling and Grammar tool (F7) and correct the supposedly misspelt word as proposed. Current behaviour: The comment breaks the words, makes it seen as misspelt by the spellchecker, and running the the Spelling and Grammar tool and trying to fix the supposedly misspelt word deletes the comment. Expected behaviour: The word where the comment is inserted should not be recognised as misspelt by the spellchecker in the first place. Operating System: Ubuntu Version: 4.0.3.3 release
I can confirm this happens, and it happens on Windows too.
This is still the case in 4.1.2.3
As simple 'workaround' might be to add the comment not in the middle of a word, but at the end (or at the start). Is it possible to do this automatically? This way spelling checker should not give problems. If the comment is at the start of the word, than adding letters to the start of that word should be done AFTER the comment, and if the comment is at the end of the word, it should be done BEFORE that comment ;)
oops forgot to say it's still a problem in 4.1.3.2 (OS:Windows7)
Issue is still there in 4.3.1.2 OS: Win7 See new attachment also
Created attachment 107675 [details] Failed spell check in a commented word
Created attachment 107713 [details] a comment is seen as the end (or start) of a word.....
The comment is a character within the word and cannot be ignored by the spellchecker. Also, it is desirable to have comments everywhere within the word, not only at the start/end.
"Also, it is desirable to have comments everywhere within the word, not only at the start/end." Can you clarify that? I'm not sure what you mean by that.... I would call this a BUG if the place of a comment influences the working of the spellings checker.
When using the Spelling and Grammar tool, pressing either the Ignore Once or Ignore All on the word with the comment, will result in an extra letter being added to the word where the comment used to be. Also, this happens with range comments within the word. Having a range comment from the beginning of a word to the middle of a word will be marked as misspelt, but the Spelling and Grammar tool does not delete the comment when ignored. Having a range comment from the middle of a word to the end of the word does not show as being misspelled. All of this is assuming that the word you typed is correct. If the word is actually misspelled, then the only way to correct it is to run the Spelling and Grammar tool again or manually right click on it. Summary: Spellchecker deleting comment. Spellchecker adding extra letter because of comment. I propose that Automatic Spell Checking and Spelling and Grammar be adjusted to take into account a comment anchor between letters. See also #32773. Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
*** Bug 77406 has been marked as a duplicate of this bug. ***
This bug has already been fixed previously, so this is a regression. https://bugs.documentfoundation.org/show_bug.cgi?id=32773
The word count in a current version of a LibreOffice document is OK. Bug 32773 talks about word count, therefore this bug (65535) is not a regression of bug 32773.
Works in 3.6.0.4, broken since 4.0.0.3, occurs in master, too.
Reproduced in the current still version of LO: Version: 5.3.5.2 Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; VCL: kde4; Layout Engine: new; Locale: en-GB (en_GB.UTF-8); Calc: group Comment in middle of word still makes spellcheck see the word as misspelled. "Correcting" the word with spellcheck still makes the comment disappear. However, I could not reproduce what Gordo described, with the tool adding a letter to the word if it was ignored.
Version 5.4.3; OS: MAC OS. Issue is still present
ce3917fd9ea98ae2089cf4dca9cc742c10935e7f is the first bad commit commit ce3917fd9ea98ae2089cf4dca9cc742c10935e7f Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 01:49:34 2012 +0000 source-hash-b0f170d7df9cff12535d2ecfd146b32b745a8ef8 commit b0f170d7df9cff12535d2ecfd146b32b745a8ef8 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Jul 18 17:00:52 2012 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Jul 18 17:27:09 2012 +0100 0xFFF9 is a better choice for CH_TXTATR_INWORD than 0x0002. a) the default properties for the code point make it not split a word it appears in into two different words in any break mode we have. Which is what we want from a CH_TXTATR_INWORD b) unicode TR#20 gives for the interlinear annotation anchor: "What to do if detected: In a proxy context or browser context, remove U+FFF9", so when we need to strip it from text to run that text through e.g. the spellchecker or word counting then there's a solid precedent for stripping it In addition I *do* want the footnote placeholder to break the word it appears in, that gives the desired wordcount and cursor travelling behaviour The BREAKWORD and other *random* selection of CH_TXTATR are still odd choices, and there's way too many of them. Change-Id: I930ff8ff806af448829bc1a1ae6cb92053e9a284 :100644 100644 9d81536e7984b62a455c0e28fd5742cf487e4184 68f099b9e694f9e81548a97f2ca9d3f0d5db65b8 M ccache.log :100644 100644 795b25464739ab134d722aa7e7d34d6535537138 e8290ad8beece52dc0da61c0d2ce30d3182ed694 M commitmsg :100644 100644 c248b041df516d7e0f62b85c84ac0ebb59545ff3 630d940d889565aa459edecb3919bda5e64f0588 M dev-install.log :100644 100644 acfe8830a332b6879cfcec6f74f902d0fb64c562 32e06662778eeba496c378cc426ad2f20e708d32 M make.log :040000 040000 8b82c14ad77224021d3034b6517a3a67f938064f 36b63cc40dd49eb461a38f39f246f13776b0e07d M opt
Dear stragu, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 151919 [details] bug as seen in LO Writer 6.2 Confirmed in both 6.2 and 6.3 branches: - Commenting inside a word / on a range inside a word makes the word being detected as misspelled (you might have to keep writing a bit more text for spellcheck to notice it) - The spellcheck window shows the word with a "IAA" rectangle where the comment is located - Correcting the word as suggested removes the comment I can't reproduce Gordo's issue though (with a letter being added inside the word when ignoring). Details about versions: Version: 6.2.4.2 Build ID: 1:6.2.4-0ubuntu0.18.04.1~lo1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-GB Calc: threaded Version: 6.3.0.0.alpha1 Build ID: 547edd20e527fb02900f6174973770d26306e2e7 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
Step 4 on original bug-report does not happen anymore, but spelling still mis-behaves, see 'F7_after addingComment.jpg'
Created attachment 152037 [details] F7_after adding comment
(In reply to Luuk from comment #21) > Created attachment 152037 [details] > F7_after adding comment LibreOffice 6.2.4.2 (Windows 10)
Hi Luuk I also noticed that it might not straight away underline the word in red, but I believe that if you keep editing your document, it will eventually register it and mark it as misspelled with the red wiggly line (also using 6.2). Would you mind confirming that?
Indeed, when starting to type some red wiggly line is shown.
And, when choosing 'Correct' the comment is lost.
This is still present in: Version: 6.3.0.1 Build ID: 41ac97386aba908b6db860cfb4cfe2da871886ae CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
Reproduced as described in comment 19, using: Version: 6.4.0.0.alpha1 Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
This might be a complete red herring, but recently a bug was found with how search was handling special characters (eg. soft-hyphens, comment or footnote markers), and was fixed with the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=d8270636a57e7dc68ede51308c380e2098f765d7 The commit is only relevant for search/replace(!), but perhaps the logic is similar in both cases, and if someone gets around to looking at this bug, they might find something useful in that reference.
Still reproducible with: Version: 7.0.2.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Ubuntu package version: 1:7.0.2_rc2-0ubuntu0.18.04.2 Calc: threaded
