Andy,
So if i did an audit over the code and made sure that getBytes() is not
called without specifying an encoding ie getBytes(UTF-16LE) then
everything should be sweet.
UnicodeRecord does specifying an encoding when it is about to serialize
the string bytes, so it shoud perform the
All,
Why is there a need for the setEncoding method on HSSFCell. At least with
my latest UnicodeRecord changes the UnicodeRecord will iterate over the
characters in the string to determine if there are high bytes, or not, and
set the appropriate encoding method. All the HSSFCell stuff does is
All,
Any idea why the following line from UnicodeRecord (current HEAD rev and
previous) is actually required?
String unicodeString = new
String(getString().getBytes(Unicode),Unicode);
If i remove it and use:
String unicodeString = getString();
1) All of the unit tests still pass, and
2)
All,
Basically i have finished implementing rich text support (yaa!) but have
come across an interesting quirk. Currently the SST record will grow based
on the number of nuique strings in the file, it never colapses (unless i
am missing something), so for example if i continually update a
All,
How do we want to handle this patch for the rich text support. The patch
is quite large because it includes the pull method patch attached to bug
31906. I dont believe that this mailing list will allow me to send an
email with a file that is arround the 500K mark, so this makes reviewing
