[Tickets #1932] NEW: Horde String::substr() function and spell check

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=1932
-----------------------------------------------------------------------
 Ticket             | 1932
 Created By         | horde at ndn.no
 Summary            | Horde String::substr() function and spell check
 Queue              | Horde Base
 Version            | 3.0
 State              | Unconfirmed
 Priority           | 1. Low
 Type               | Bug
 Owners             | 
-----------------------------------------------------------------------


horde at ndn.no (2005-05-09 06:50) wrote:

I have been trying to track down an error in the Spell Checker, using UTF-8
and norwegian dictionaries with aspell. This is the same case as bug 1849.

This bug can be reproduced by using UTF-8 as the characted set and using
aspell with the --encoding=UTF-8 option, using a norwegian dictionary. Spell
checking a message with norwegian (multibyte) characters will result in both
highlight errors and errors when changing words. There is a displacement of
the offset in a forward direction proportional to the amount of norwegian
characters present previously in the text. E.g. when replacing spel with
spell in "spel checker", the new text would become something like
"spspellecker".

A fix that seems to solve the problem is replacing the following line in
function substr():

return substr($string, $start, $length);
with
return @mb_substr($string, $start, $length, $charset);

in the function substr in lib/Horde/String.php.

Changing the relevant code (in the highlightError function and under CHANGE,
CHANGE_ALL switch cases) yields a fix "99%" of the time, but sometimes the
errors still occur, leading me to believe that the error propagates through
other String functions that use the substr function.

Duplicating the String.php file and fixing the problem there, changing the
String class name and changing imp/spelling.php and
imp/templates/compose/spelling.php to use the new class, also solves the
problem.

If this is too little information to dig into the problem, perhaps the spell
checking code should be documented as having potential multibyte problems?