Bug 140635 - Options for auto correction need 22 seconds to open and a correction cannot be found / disabled
Summary: Options for auto correction need 22 seconds to open and a correction cannot b...
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: IA64 (Itanium) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-24 09:03 UTC by Karsten
Modified: 2021-10-19 09:37 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Window with entries of auto correction (56.34 KB, image/png)
2021-02-25 15:07 UTC, Karsten
Details
Original DocumentList.xml that is part of acor_de.dat (160.10 KB, text/xml)
2021-02-26 08:59 UTC, Karsten
Details
file in user directory with added entry (18.55 KB, application/zip)
2021-02-27 10:39 UTC, Karsten
Details
Original file in /opt/libreoffice7.0/share/autocorr replacing "daß" with "dass" (18.43 KB, application/zip)
2021-02-27 17:29 UTC, Karsten
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karsten 2021-02-24 09:03:48 UTC
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.
Comment 1 Julien Nabet 2021-02-24 20:01:37 UTC
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)
Comment 2 Karsten 2021-02-25 09:41:11 UTC
(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
Comment 3 tommy27 2021-02-25 11:18:43 UTC
@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
Comment 4 Karsten 2021-02-25 15:05:53 UTC
(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?
Comment 5 Karsten 2021-02-25 15:07:44 UTC
Created attachment 170059 [details]
Window with entries of auto correction
Comment 6 tommy27 2021-02-26 06:13:56 UTC
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
Comment 7 Karsten 2021-02-26 08:03:41 UTC
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".
Comment 8 Karsten 2021-02-26 08:59:05 UTC
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?
Comment 9 Julien Nabet 2021-02-27 10:04:55 UTC
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.
Comment 10 Karsten 2021-02-27 10:12:51 UTC
(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.
Comment 11 Julien Nabet 2021-02-27 10:17:06 UTC
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)
Comment 12 Julien Nabet 2021-02-27 10:25:39 UTC
(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&#xDF;a" block-list:name="dass"/>
and it's coherent with the fact that tdf#139377 has been put into WONTFIX.
Comment 13 Karsten 2021-02-27 10:30:29 UTC
(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
Comment 14 Karsten 2021-02-27 10:39:13 UTC
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&#xDF;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.
Comment 15 Julien Nabet 2021-02-27 10:58:05 UTC
(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.
Comment 16 Julien Nabet 2021-02-27 10:59:47 UTC
(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.
Comment 17 Karsten 2021-02-27 13:34:02 UTC
(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 ?
Comment 18 Julien Nabet 2021-02-27 13:41:41 UTC
(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&#xDF;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
Comment 19 tommy27 2021-02-27 14:30:47 UTC
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.
Comment 20 Karsten 2021-02-27 17:29:35 UTC
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&#xDF;a" block-list:name="dass"/>
<block-list:block block-list:abbreviated-name="da&#xDF;" block-list:name="dass"/>
but this lines are not schown in the menu for deleting.
Comment 21 Karsten 2021-02-27 17:44:30 UTC
(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?
Comment 22 Julien Nabet 2021-02-27 17:53:21 UTC
I can't help here=>uncc myself
Comment 23 Karsten 2021-03-10 10:14:35 UTC
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 ...
Comment 24 tommy27 2021-10-17 14:28:56 UTC
you should retest using LibO 7.1.5 or later

the loading speed is much higher in this version

see Bug 128078
Comment 25 tommy27 2021-10-17 14:39:09 UTC
this one seems a dupe of Bug 133874
Comment 26 Karsten 2021-10-19 08:31:06 UTC
(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?
Comment 27 Buovjaga 2021-10-19 09:37:17 UTC
(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