Description: Hello, this can be seen as a minor problem, but it is annoying in comparison to version 6.4.62 In the new version are a couple of new auto corrections, one is in german that the word "daß" is corrected in "dass". But this is not wanted and it cannot be deleted in the substitutions. It is only possible to deactivate the auto correction complete. Maybe i have something overseen? Version: 7.0.4.2 Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kf5 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Steps to Reproduce: Open autocorrections Actual Results: This needs about 22 seconds to wait. There cannot be found a substitution "daß" with "dass" Expected Results: Opens immediate. There is a substitution "daß" with "dass" that can be deleted. Reproducible: Always User Profile Reset: No Additional Info: It's nice when new features are added, but it is always more important that the old functionality is running stable.
Please make one bug/one pb. Either it's the slowliness or it's about deleting not wanted replacements. In first case, there's tdf#74206 In second case, it's fixed from 7.0.5 (see tdf#96787) Concerning daß" corrected in "dass", see https://bugs.documentfoundation.org/show_bug.cgi?id=139377 (see https://bugs.documentfoundation.org/show_bug.cgi?id=139377#c25 specifically for a workaround)
(In reply to Julien Nabet from comment #1) > In first case, there's tdf#74206 This is a different problem. Here the window itself takes the time to open. > In second case, it's fixed from 7.0.5 (see tdf#96787) This is a different problem too. > Concerning daß" corrected in "dass", see > https://bugs.documentfoundation.org/show_bug.cgi?id=139377 (see > https://bugs.documentfoundation.org/show_bug.cgi?id=139377#c25 specifically > for a workaround) Yes - this fixes the problem - thank you! So this bug can be merged with bug 139377. The file has to be placed in /opt/libreoffice7.0/share/autocorr/acor_de.dat For the problem of working slow, it maybe the same reason as here: https://bugs.documentfoundation.org/show_bug.cgi?id=140639
@Karsten how many autocorrect entries do you have? It seems to me you are describing a performance issue of the autocorrect replacemnet table I reported several times.. take a look at this one: Bug 128078
(In reply to tommy27 from comment #3) > @Karsten > how many autocorrect entries do you have? More then possible for an easy manual count. (See screenshot) The file is not in a readable format. > It seems to me you are describing a performance issue of the autocorrect > replacemnet table I reported several times.. > > take a look at this one: Bug 128078 Hmmm - when there is a performance issue, why there is such a big standard table with entries most of the people don't need?
Created attachment 170059 [details] Window with entries of auto correction
the problem is when you manually add many autocorrect items in the replacement table, it makes the loading speed slower and slower in time. this is true if you have more than 100K entries. so I suppose that if it takes more than 20 seconds to open it, you have a lot of them. so if the issue is that one, this is already Bug 128078 and this report may be labeled as a duplicate. if you don't have so many entries, it could be a different issue... a standard autocorrect table should load in a few seconds. did you try to reset the user profile? (remember to backup first the old one) as said, I have more than 300K entries that I collected in more than 10 years of usage of OpenOffice/LibreOffice
I never used this list active. So - why is there such a huge standard list? From my point of view an autocorrection list with 300.000 entries makes no sense, because it is no correction anymore, it is a macro or phrase machine. So all this :entries: should be optional. It's only senseful to replace standard words, that are not typed correct like "ihc" with "ich" or "dsa" with "das".
Created attachment 170068 [details] Original DocumentList.xml that is part of acor_de.dat Linux says that acor_de.dat is a zip-file, so the information could be extracted. After adding linefeeds the main correction list is in an readible format as attached. You can see that there where 1815 entries in the list. Is this enough for a performance issue? In the original list is no correction of "daß" with "dass", so where is this done?
If I remember well, if for a specific language, you added/deleted (for delete after 7.0.5 since it doesn't work before) some entries, a file is created in user/autocorr and so the file in share/autocorr is not used anymore for this language. So when looking at the number of entries, you also got to take this into account.
(In reply to Julien Nabet from comment #9) > If I remember well, if for a specific language, you added/deleted (for > delete after 7.0.5 since it doesn't work before) some entries, a file is > created in user/autocorr and so the file in share/autocorr is not used > anymore for this language. > > So when looking at the number of entries, you also got to take this into > account. There is no path or file named "autocorr" in the users home-directory.
Here's what I got in a Debian testing in ~/.config/libreoffice/4/user: autocorr autotext basic config database extensions gallery pack psprint registrymodifications.xcu uno_packages For the test could you add an entry and check again? Also on which Linux distrib are you? (+version)
(In reply to Karsten from comment #8) > ... > In the original list is no correction of "daß" with "dass", so where is this > done? In the original file, the replace of "daß" with "dass" is still there. If you take the original "acor_de.dat" (not the one I provided with https://bugs.documentfoundation.org/attachment.cgi?id=168648 from tdf#139377), its DocumentList.xml still contains: <block-list:block block-list:abbreviated-name="dßa" block-list:name="dass"/> and it's coherent with the fact that tdf#139377 has been put into WONTFIX.
(In reply to Julien Nabet from comment #11) > Here's what I got in a Debian testing in ~/.config/libreoffice/4/user: Hihi - the search failed because of missing the .directories. There is a file ~/.config/libreoffice/4/user/autocorr/acor_de-DE.dat with 18.4 KB instead of 17.8 KB There can't be really more entries in it. Why the problem with the replacement of "daß" with "das" could be fixed, by replacing the file in /opt/libreoffice7.0/share/autocorr/acor_de.dat ? https://bugs.documentfoundation.org/show_bug.cgi?id=140635#c2 There are coming more and more questions what autocorrections is doing? > For the test could you add an entry and check again? > Also on which Linux distrib are you? (+version) Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster
Created attachment 170107 [details] file in user directory with added entry (In reply to Julien Nabet from comment #12) > (In reply to Karsten from comment #8) > In the original file, the replace of "daß" with "dass" is still there. > If you take the original "acor_de.dat" (not the one I provided with > https://bugs.documentfoundation.org/attachment.cgi?id=168648 from > tdf#139377), its DocumentList.xml still contains: > <block-list:block block-list:abbreviated-name="dßa" > block-list:name="dass"/> Why this entry is not in the autocorrection list so that it can be deleted? > and it's coherent with the fact that tdf#139377 has been put into WONTFIX. WONTFIX is a really good solution for such an behaviour. ;-) I added now an entry replace "plop" with "plopp" and the file in ~/.config/libreoffice/4/user/autocorr/acor_de-DE.dat has been updated.
(In reply to Karsten from comment #13) > ... > Why the problem with the replacement of "daß" with "das" could be fixed, > by replacing the file in /opt/libreoffice7.0/share/autocorr/acor_de.dat ? > https://bugs.documentfoundation.org/show_bug.cgi?id=140635#c2 If there's nothing in user directory, share directory will be used. However, if you use a localization for which there's something in user directory, only the file in user directory will be used. So when installing LO first time, you got nothing in user/autocorrect, only share/autocorrect will be used. Now, let's say I use German language and Germany localization. I'm adding an entry "test" should be replaced by "test1". I validate and close LO. => in user/autocorr, I got a brand new file called: acor_de-DE.dat If you select "Deutsch (Schweiz)" in AutoKorrectur and add the replace "test" => "test2", then click ok button, you'll got another file in user/autocorr: acor_de-CH.dat If you define your whole document is German from Germany, LO will use acor_de-DE.dat from user directory. If you define your whole document is German from Switzerland, LO will use acor_de-CH.dat from user directory. If you define your whole document is German from Luxemburg LO will use acor_de.dat from share directory. After all this: if you configure LO with German/Germany it'll use acor_de-DE.dat from user directory. If you upgrade LO and the new version contains an increased acor_de.dat, LO will still ignore the file in share directory and will only use the file in your user directory. If you don't want LO to use the file in user directory anymore (and keep the same language/localization), you got to remove acor_de-DE.dat from user From this point LO will start from acor_de.dat from share directory. Have in mind that, when using German language, LO uses either acor_de.dat from share directory, or a specific user file acor_de-<DE/CH...>.dat, never both at the same moment. Hope the mechanism is a bit clearer now.
(In reply to Karsten from comment #14) >... > Why this entry is not in the autocorrection list so that it can be deleted? I suppose the share dir contains the fixed file I proposed but LO doesn't use it because you must have a file in user autocorrect.
(In reply to Julien Nabet from comment #16) > (In reply to Karsten from comment #14) > >... > > Why this entry is not in the autocorrection list so that it can be deleted? > I suppose the share dir contains the fixed file I proposed but LO doesn't > use it because you must have a file in user autocorrect. As written above, first only the file in /opt/libreoffice7.0/share/autocorr/acor_de.dat was replaced. This fixed the problem with "daß" -> "dass". Thanks for you explanation above. The file /libreoffice/4/user/autocorr/acor_de-DE.dat seems to exist before an own entry was made. But it is possible that it exists from an older installation of Libreoffice. At this moment two questions will remain: a) Why is the replacement "daß" -> "dass" not in the user menu for delete? b) Why the user menu is so slow with about 1800 entries ?
(In reply to Karsten from comment #17) > ... > At this moment two questions will remain: > a) Why is the replacement "daß" -> "dass" not in the user menu for delete? if /libreoffice/4/user/autocorr/acor_de-DE.dat doesn't contain <block-list:block block-list:abbreviated-name="dßa" block-list:name="dass"/> it's expected. If it contains it, I don't know. > b) Why the user menu is so slow with about 1800 entries ? I don't know
I'm my decennal experience with large autocorrect lists (I reported many bug reports) the loading slowdown should only appear with huge acor.dat files like the one I use (see Bug 128078). if your .dat file only has 1800 entries it should load in a few seconds, if not instantly... at least on Windows would you please upload the original .dat file you are having this annoying, so I can test the time it takes on my PC? in the meantime you may also try loading one of my huge autocorrect files (download attachment 100586 [details] ) that includes acor_und.dat and acor_it-IT.dat containing 191034 and 83027 entries tell how much time does it takes to load.
Created attachment 170119 [details] Original file in /opt/libreoffice7.0/share/autocorr replacing "daß" with "dass" Sorry, we talk past each other. What Julien is writing is logically, but this is not the behaviour of the Writer 7. When i replace the file /opt/libreoffice7.0/share/autocorr/acor_de.dat with the attached Original file, then Wrtier is replacing "daß" with "dass". The file in the user directory is ignored! When the modified file is copied over it, then the replacement has gone. So in every case this fiel overrides the file in the user directory. But additional entries are stored in the file of the user directory and are used! Yes - in the original file are 2 lines <block-list:block block-list:abbreviated-name="dßa" block-list:name="dass"/> <block-list:block block-list:abbreviated-name="daß" block-list:name="dass"/> but this lines are not schown in the menu for deleting.
(In reply to tommy27 from comment #19) > in the meantime you may also try loading one of my huge autocorrect files > (download attachment 100586 [details] ) that includes acor_und.dat and > acor_it-IT.dat containing 191034 and 83027 entries > > tell how much time does it takes to load. When i place your file acor_und.dat as /opt/libreoffice7.0/share/autocorr/acor_de.dat then only the short list is loaded within the 22 seconds. When i place your file acor_und.dat as ~/.config/libreoffice/4/user/autocorr/acor_de.dat then it is loaded within about 3 seconds and i can see a huge list with italian words. This makes absolut no sense! Why the big list takes less time?
I can't help here=>uncc myself
I deinstalled LibreOffice 7, because there where other annoying new bugs. I installed Version: 6.4.7.2 Build-ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU-Threads: 4; BS: Linux 4.19; UI-Render: Standard; VCL: kf5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded now, but it still takes much time to load the short list. So this is an older problem ...
you should retest using LibO 7.1.5 or later the loading speed is much higher in this version see Bug 128078
this one seems a dupe of Bug 133874
(In reply to tommy27 from comment #24) > you should retest using LibO 7.1.5 or later > > the loading speed is much higher in this version > > see Bug 128078 What is Lib0 and where i get it and where it should be installed?
(In reply to Karsten from comment #26) > (In reply to tommy27 from comment #24) > > you should retest using LibO 7.1.5 or later > > > > the loading speed is much higher in this version > > > > see Bug 128078 > > What is Lib0 and where i get it and where it should be installed? LibO is short for LibreOffice
Dear Karsten, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
There seems to be no further Regression-Tests for Lo and Linux any more. The last usable Version for Linux seems to be now: Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Im am sorry to say this, but after this version there are more and more such little bugs rendering LO as unusable. Nobody seems to fix it.
(In reply to Karsten from comment #29) > There seems to be no further Regression-Tests for Lo and Linux any more. > > The last usable Version for Linux seems to be now: > Version: 7.1.8.1 / LibreOffice Community > Build ID: e1f30c802c3269a1d052614453f260e49458c82c > CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 > Locale: de-DE (de_DE.UTF-8); UI: de-DE > Calc: threaded > > Im am sorry to say this, but after this version there are more and more such > little bugs rendering LO as unusable. Nobody seems to fix it. What do you mean by "last usable version"? Do you still see this autocorrect dialog opening delay in any version?
Sorry for the frustrated comment. The good news are that there is no delay any more for opening auto correction in the above version. Really annoying are bugs like https://bugs.documentfoundation.org/show_bug.cgi?id=147193 that render LO unusable for me. In newer versions there are bugs that cannot be described, like that the mouse cursor vanish for a certain time. The conditions are absolute not clear, so it makes no sense to open an bug.