I am running LibreOffice in a 2008 R2 RDS (Remote Desktop Services) environment. We have many servers running LibreOffice. Users have their application data folder redirected to a network location. Consider the following scenario with the environment above: 1. User A and B open LibreOffice running on server 1 2. User A and B close LibreOffice 3. User A opens LibreOffice and it runs on server 2. User A will not have Language Modules and spellcheck will fail to work 4. User B opens LibreOffice and it runs on server 1. Users B will have Language Modules and spellcheck will work 5. If User A closes LibreOffice on server 2 and opens it on Server 1. Language Modules will be there, and spellcheck will work It seems that when LibreOffice first runs it saves something that relates to the computer that it was first run on. So long as LibreOffice continues to run on that computer (or server) spellcheck will continue to work. However as this is a RDS environment, it is very likely that users will run LibreOffice on other computers. I tracked the issue down to the LibreOffice/3/user/extensions folder. If I delete this folder it will re-create the next time LibreOffice is run and spellcheck will work correctly. Indeed all I really need to do is delete a lastsynchronized file. While I have a workaround (deleting the lastsynchronized file when the user logs off), its not exactly elegant. If this can be fixed I would appreciate it.
I can only chime in with a "me too", and add that even creating a brand new profile does not make spellcheck work. I tried just removing the extensions folder first. We're running Swedish UI, if that makes any difference. None of the spellchecks work, not even the English one. I dont know if it's somehow related, but the first time LO is run without a profile, it'll fire upp the soffice.exe and soffice.bin processes, create the profile, and then die. Subsequent runs sometimes start up as expected, other times it takes a really long time to start.
I just checked, and it's the same on Windows 7 as well. If I go into the language options, the Hunspell option is nowhere to be found, neither is anything but the Lightproof options. For a regular user without redirected appdata, this works as expected.
I forgot to mention both of the above from me was tested using LibreOffice 3.5.4...
See also bug 50542.
is bug still present with current 4.0.5 or 4.1.1 final releases?
set status to NEEDINFO waiting for user feedback
Same situation with LibreOffice 4.2.2 redirect %APPDATA% to shared folder : \\appdata\user01\Datos de programa lost SPELL dictionary funcionality. If this folder is local to the machine where the LibreOffice is working the spell dictionary works
It seems like the problem is partially in hunspell, it collapses large file/folder names into old 8.3 file name format. The hunspell maintainer is aware. Jan mentioned there might be some extra fixes needed in LO, he should probably add more details. Let's party like it's 1989!
Laszlo is on this - added him to CC. Seems it is caused by the code here: http://cgit.freedesktop.org/libreoffice/core/tree/lingucomponent/source/spellcheck/spell/sspellimp.cxx#n306 Unfortunately needs some changes to hunspell to be able to support wchar_t* filenames...
Laszlo Nemeth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e4b21e2d627de0c815370ed886ff95675bf28d1 fdo#48017 fix WIN32 long path name support of spelling dictionaries 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.
Kendy: the previous patch has checked only partially (myfopen()/_wfopen() in wine/MinGW, the LibreOffice patch in a Linux build). If it works in a Windows build environment, solving the problem, I will fix the hyphenation and the thesaurus libraries, too, and remove the unnecessary Win_getShortPathName().
Hello I test master~2014-04-26_00.32.11_LibreOfficeDev_4.3.0.0.alpha1_Win_x86, with spanish dictionary and the spellcheck is working. My environment uses roaming profiles for users. Thanks
@Rafael does it mean it's fixed for you, right?
Yes, I think it's fixed.
I cannot reproduce this issue with 4.3.0. But my environment has somewhat changed since I initially opened this bug. I haven't been able to reproduce the issue with 4.2.x either... So I'm not sure whether this issue was fixed in earlier versions or not. Either way, at least in my case, this issue is resolved. Thanks.
Laszlo Nemeth committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=59906c3d54e6541185f4bf85b1d1c70530198059&h=libreoffice-4-2 fdo#48017 fix WIN32 long path name support of spelling dictionaries It will be available in LibreOffice 4.2.5. 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.
Laszlo Nemeth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d06aa8ba83b7629603cd86cf14a63c432ce268f fdo#48017 WIN32 long path support in Hyphen and MyThes 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.
Laszlo Nemeth committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f98f4981cb29e84723128ab3839110526e33655&h=libreoffice-4-3 fdo#48017 WIN32 long path support in Hyphen and MyThes It will be available in LibreOffice 4.3. 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.
(In reply to comment #18) > Laszlo Nemeth committed a patch related to this issue. > It has been pushed to "libreoffice-4-3": Thanks !
All: thanks for your feedbacks!