[Libreoffice-bugs] [Bug 97198] Calc: incorrect formula text function result from Unicode' s non-BMP characters. Functions LEN(), LEFT(), RIGHT(), MID(), SEARCH(), FIND(), REPLACE()

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Thu Nov 9 14:30:06 UTC 2017


https://bugs.documentfoundation.org/show_bug.cgi?id=97198

--- Comment #12 from Winfried Donkers <winfrieddonkers at libreoffice.org> ---
(In reply to Eike Rathke from comment #11)
> As for the first attachment, these are real non-BMP characters. For this to
> work correctly the mentioned spreadsheet functions should operate on the
> actual Unicode characters code points instead of the 16-bit units. There's
> OUString::iterateCodePoints() to do that properly, a change in LO's string
> handling is not necessary.
> 
> > As Excel 2016 has the same results as LO, interoperability would be affected
> > when LO is changed.
> Also the same result with the first attachment and real non-BMP characters?
> Anyway, I couldn't find a definition for Excel how they'd treat non-BMP
> characters, but as LEN() is supposed to return the length in *characters*,
> not in 16-bit code units, I propose to actually handle it that way. I
> consider treating these string functions in code units wrong. Specifically
> with LEFT() or RIGHT() or MID() or REPLACE() that should operate on
> characters, otherwise with code units could cut non-BMP characters in the
> middle.

Thanks for your clarification, I will see if I can fix this.
(And I will document the Excel results in the unit test documents.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20171109/4cc498f9/attachment-0001.html>


More information about the Libreoffice-bugs mailing list