This bug wouldn't necessarily stop 1.5. This is a feature we don't currently support (rich strings).
I don't think this is so bad. Its some sucky design on M$'s part, but not so bad. We just need a new String class that contains a string and formatting information. xAxBxC = HSSFRichString String data; byte[] styleinfo; String getString(); byte[] getRawString(); We'll need some methods to handle styling things. Which means we need to figure out what those styles mean. We'll also need to know when to use the Rich/Unicode/Compressed Unicode. Not a big deal IMO, just one more feat in the quest for catching all the strange cases of HSSF records. -Andy On Tue, 2002-04-02 at 06:47, Glen Stampoultzis wrote: > > > > > Well, it's plain to me, then, that what SST record needs to hold is not > > plain strings (too bad) but the entire string data elements. > > I figured as much. It's slightly tricky since it's exposed in the user > model as string (as it probably should be) so which SST string you should > match against becomes a little confused. > > I'm begining to think we'll never get 1.5 out the door... *sigh* > > Regards, > > Glen Stampoultzis (TriNexus Pty Ltd) > +63 3 9753-6850 0402 835 458 > ICQ: 62722370 EMail: [EMAIL PROTECTED] > > -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh
