Hi Mark,
Great to see:
commit e99f22bbc499ab0566621ee0bb01e4a7747efe76
Author: Mark Hung <marklh9@gmail.com>
Date: Sun Jan 10 00:28:14 2016 +0800
Fix FastSaxSerializer::write() for non-BMP unicode characters.
Clearly we don't want to mangle UTF-16 etc. characters - and the code
looks dodgy indeed for that =)
I'm somewhat suspicious though that this will cause some unhelpful
performance regression; and I was wondering if you could look into
fixing that ? and (ideally) helping out with a regression test for these
characters ? =)
Memory allocation of OStrings etc. via rtl/sal is rather expensive in
most of the profiles I've seen; and particularly doing it for every
attribute ;-)
Would it be possible to replace the original code - but - as soon as we
hit a non-ASCII character to convert the rest of the string, and write
that - so something like:
write (OString(sOutput[i], nLength-i, RTL_TEXTENCODING_UTF8), bEscape);
return;
So we can get the character conversion and pairing correct - while
keeping the lack of allocation there ? =)
Anyhow - thanks muchly for the fix ! great to see complex text support
improve.
All the best,
Michael.
--
michael.meeks@collabora.com <><, Pseudo Engineer, itinerant idiot
Context
- FastSaxSerializer::write ... · Michael Meeks
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.