There should be a "coalesce" method. However, it shouldn't run by
default as it is probably time consuming. Many people would consider
extra filesize a happy tradeoff vs memory consumption or processor
utilization. It just depends.
It might also be good to optionally (this costs more memory) keep
reference counts in the SST and support an "an autocoalesce" method such
that it can do it automatically; however, I really don't want to have
that happen by default (too much memory used up for ref counts + too
much processor for looking them up on every change).
-andy
Jason Height wrote:
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 HSSFCell string value by appending to it ie always creating a unique
string by overwriting the current value then the SST record will
continue to grow with many of the string entries being orphaned.
This will be the similar behaviour if i change the formatting of a
HSSFRichtextString.
Should there be something to delete orphaned strings in the SST record?
Presumably during serialization?
Thoughts?
Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/
