My gut says this is probably due to a bad interaction between regexes and multibyte strings; if that's the case, we can't do much about it.

Basically what I think is happening is that the [^ ] part of the regex is selecting one byte, but the character at that position is really two (or more) bytes long. That one byte will be matched and replaced, but the second (and any subsequent) bytes will stick around and be interpreted as a different character. I'll try to confirm this suspicion later.

The suspicion in comment #1 doesn't seem to be right, so now I think this may have something to do with compound characters. Could you paste all texts from the PDF (textarea contents before, search regex, replace string, textarea contents after) in a bug comment?

The underlying search and replace code is completely different now that we are using an iframe rather than a textarea.

(In reply to comment #3)

The underlying search and replace code is completely different now that we are
using an iframe rather than a textarea.

That doesn't necessarily mean that multibyte character handling is magically fixed. Reopening and asking Calcey to try and reproduce again; please close as FIXED or WORKSFORME if this can't be reproduced any more.

I've tested this with double-byte characters quite a bit now, and am sure it's fixed.

Note that Sinhala seems to be using three-byte characters.

wikibugs wrote:

Verified and closed