To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=87672
------- Additional comments from tomm...@openoffice.org Thu May 7 16:24:22 +0000 2009 ------- Thanks for feedback... however i respectfully diasgree with some of the things you said: a- issue priority maybe is not the highest, but it's still a P2 issue which is higher than many P3 and P4 issues i see round here. b- the way i use autocorrect well, i think my use of autocorrect is not that strange. The whole database is a list of the many typing errors i made in my daily work. I write medical reports all the day and i have to write them fast... that's why i have collected so many mistakes and i entered in the replacement table to avoid future errors. With my massive everyday use of Writer i saturated the OOo acor.dat file with 65534 entries in 2 years. You should expect that other users will reach that limit one day... maybe they will take longer than me but day after day they will get at that point. I think the problem is that: 1- autocorrect entries number is limited entries are not infinite unlike in MS Word (as far as i know - read previous posts) and this is a weak point of OOo. 2- reaching the limit causes data loss as i reported, once you add entry number 65535 the acor.dat file crashes and all the database is permanently erased... this is really bad... i was lucky i had backupped it before so i did not loose my precious autocorrect databases... i would have been very pissed off if that ever happened POSSIBLE SOLUTIONS i think you should find a way to address at first the data loss issue and, if possible, also the entry limit issue. Solution A: lock the acor.dat file once entry 65534 is added. you should prevent users to add entry 65535 that causes the crash and data loss. I remember that OOo user custom dictionaries had a 2000 words limit (that has been now set to 30000), once you reached that limit and tried to add a new word, you were alerted with an error message telling you “dictionary is full”. Solution B: let acor.dat file store more than 65K entries. I know that would make OOo replacement table open very slowly (even 15 minutes with the actual 65K limit) Solution C (which would be my favourite one and that i suggested in earlier posts): allow creation of additional acor.dat files once an acor.dat file is full, the user should be allowed to start a new replacement table database just like with dictionaries. Old autocorrection would still be active and new ones should be added to the brand new acor.dat file which woyld also load faster since it is almost empty. Issue 101224 that i open few days ago could be a kind of workaround for this. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@framework.openoffice.org For additional commands, e-mail: issues-h...@framework.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
