[Libreoffice] autocorrect limits
Tommy
barta at quipo.it
Wed Feb 1 08:19:30 PST 2012
On Wed, 01 Feb 2012 15:42:26 +0100, Caolán McNamara <caolanm at redhat.com>
wrote:
> On Wed, 2012-02-01 at 06:12 +0100, Tommy wrote:
>> this issue sounds similar to
>> https://issues.apache.org/ooo/show_bug.cgi?id=87672
>> Bug 87672 - autocorrect limit. acor.dat with entry 65535: Loop and/or
>> loss
>> of acor data
>
> *probably* the entries are shoved into one of our old container classes
> which are maxed out with a 16bit count. There's an ongoing series of
> "easy-hacks" e.g. https://bugs.freedesktop.org/show_bug.cgi?id=38832 to
> replace those with generic STL ones which happen to support far larger
> amounts, so it would be doable, *if* someone finds where the autocorrect
> entries are stored :-)
under Windows the autocorrect entries are stored under
...\User\LibreOffice 3\user\autocorr
inside .dat files such as: acor_it-IT.dat (italian autocorrect) or
acor_en-US (american english autocorrect)
those .dat files are just .zip files... if you change extension and
extract their content you will find
several other files, the most important of those is: DocumentList.xml
which is the whole list of autocorrect entries
the whole list is on a single line and as I reported in OOo Bug 87672
https://issues.apache.org/ooo/show_bug.cgi?id=87672
it may contain up to 65535 entries. if you enter 65536 the whole database
crashes and
the .xml is resetted to 0 loosing all your data
the OOo devs told me that the issue was due to a 16-bit limit and they did
not
propose a solution to this.
so, if I got it right, moving from 16-bit to 32-bit would exponentially
increase the
maximum capacity of autocorrect entries.
> You might get lucky and someone already converted the container to STL
> already in 3.4
>
> C.
really?
More information about the LibreOffice
mailing list