[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