Created attachment 51965 [details] Sample document, pls see original report! Spell check is completely broken with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 81607ad-3dca5fd-da627d2)]" Steps to reproduce: 1. open attached sample 2. Activate auto spellcheck. Expected: If you have dictionaries, most words should be underlined as misspelled Actual: nearby no word underlined 3. Start spell check with <f7> Expected: nearby all words protested as misspelled Actual: nearby no word protested as misspelled When You open attached "sample.odt" with 3.4.3, you see nearby all words underlined, none of the languages contains many lorem ipsum words. I submitted this Bug because I do not understand what the problem in "Bug 41447 - Based on Bug 40449 - SPELLCHECK does not recognize text language" might be.
For me already a problem with Server installation of Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]"
@manj_k: I had too many difficulties to understand "Bug 41447 - Based on Bug 40449 - SPELLCHECK does not recognize text language". So I filed this one with a very simple sample document. My results (also from other tests): When I start typing in a new WRITER document (with language "English") Spell check works well. But when I add a lorem ipsum paragraph spell check breaks, also for existing English Text (modifications making a word misspelled will not be recognized) That sounds similar to "Bug 39365 - Spell check does not work after copy ..." or "Bug 40449 - SPELLCHECK does not recognize text language". When I start spell check test at the beginning (<f7> the correct language will be shown in the text language indicator in the spell check dialog, but check does not work either. And when I select some lorem ipsum words in the text and start spell check with <f7>, the text language indicator is empty. With 3.4.3. the correct text language will be shown. May be the fix is incomplete? May be you can help here?
@Rainer Bielefeld: 1. "LibO-dev 3.5.0 – (Build ID:81607ad-3dca5fd-da627d2)]" seems to be 'master~2011-09-13_20.44.55'? Sorry, I've removed the installation and the unpacked *.exe due to 'Bug 40902 - FILEOPEN CRASH...' (maybe there are other regressions?). (That build isn't anymore available on the mirrors; still available builds '2011-09-22_20.23.05/' and '2011-09-24_00.41.37/' are out of the question...) I'll try 'Sample.odt' once more with the next available master build for Windows. 2. A test of your attached 'Sample.odt' with the previous version 'LibO-dev 3.5.0 Build ID: 8cc839d-3dca5fd-4525197 / master~2011-09-12_16.09.34' worked fine for me (AutoSpelcheck and <F7>). 3. The added screenshot (spell check for second Spanish paragraph) shows exactly my interpretation of 'Bug 40449 - SPELLCHECK does not recognize text language', see Bug_40449_Comment_1: "I think the text language is recognized, but spell check is fatally broken. It seems that only the first word of a paragraph (if misspelled) is recognized (as misspelled) when opening a document." 3.1. Your screenshot and description is exactly reproducible with 'LibO Master LibO-dev 3.5.0 Build ID: d3d1481-3f8994a-2ba0a9f / master~2011-09-06_02.34.59' (a version before bug-fixing fdo#40449). 3.2. Back to the 'Spanish paragraph': 'Nunc ac vulputate purus.' is the first sentence after the colon. Adding a space after 'Nunc' should show 'Nunc' as misspelled and with a red wavy line. The same with most of the other words in this paragraph (also the English and the French paragraph). That bug has been fixed by Caolán. 3.3. Please could you try a test with 'Build ID: 8cc839d-3dca5fd-4525197', mentioned above under 2.? 4. Attached screenshots 4.1. Screenshot 1: Bug reproducible · 'Sample.odt' opened with 'Build ID: d3d1481-3f8994a-2ba0a9f' [2011-09-06] 4.2. Screenshot 2: Bug not reproducible · 'Sample.odt' opened with 'Build ID: 8cc839d-3dca5fd-4525197' [2011-09-12]
Created attachment 51970 [details] Screenshot 1: Bug reproducible
Created attachment 51971 [details] Screenshot 2: Bug not reproducible
@manj_k Results are rather worrying, I agree, we should wait for new Master builds and then test again. > 1. Yes, it's 2011-09-13_20.44.55_LibO-Dev_OOO350m1_Win_x86 >2. That version is not available for me, one from 120906 shows the problem >3. - 3.2 I agree, so it is > 3.3 could you try a test with 'Build ID: 8cc839d-3dca5fd-4525197'? No, not available > 4. My [2011-09-06] also shows the problem, [2011-09-12] not available for my, later versions all crash with WRITER IMHO this one is concerning the same problem as Bug 41447, or do you see differences?
(In reply to comment #6) > @manj_k > Results are rather worrying, I agree, we should wait for new Master builds and > then test again. > > > 1. > Yes, it's 2011-09-13_20.44.55_LibO-Dev_OOO350m1_Win_x86 > > >2. > That version is not available for me, one from 120906 shows the problem > > >3. - 3.2 > I agree, so it is > > > 3.3 could you try a test with 'Build ID: 8cc839d-3dca5fd-4525197'? > No, not available > > > 4. > My [2011-09-06] also shows the problem, [2011-09-12] not available for my, > later versions all crash with WRITER > > IMHO this one is concerning the same problem as Bug 41447, or do you see > differences? Yes, this one appears to be the same problem as Bug 41447. Thank you for the clarification.
No longer reproducible with Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [(Build ID: 4f11d0a-adcf6d5-c4bb9bd)]" Windows_2008R8 - 111118) for English texts (I believe all languages will work, too). It seems fix has not been integrated into MinGW, I still see the bug with parallel installation of MinGW Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI (Build ID:fba911f-2fcbe65-8b4f344-3bd0388) (daily/Win-x86@7-MinGW/master/2011-11-25_08.14.45)"
I'm wrong. The reason for the problem is that my MinGW build does not contain any dictionary. So I close this one WFM (without knowing what exactly might have fixed the problem) and will observe later with a MinGW with dict.