IIRC, The only problem is that Excel doesn't mark it consistently. Thus the UnicodeString actually only covers *one* way that Excel does this.
On 9/17/03 11:56 PM, "Height, Jason" <[EMAIL PROTECTED]> wrote: > Hmm I wonder if we should be using a UnicodeString here? > > I suspect that all Records should actually use & hold onto the UnicodeString > class which knows how to decode compressed/uncompressed, rich text etc. > > Looking at the Excel Developers Kit it seems to indicate this. At the moment > we potentially throw away information embedded within the excel Unicode > string when we store it as a java String object. This change would touch > every record that contains a string that already doesn't use UnicodeString. > For example. LabelRecord, HeaderRecord, FooterRecord, etc. > > Look at the source for HeaderRecord, whose to say that the string is always > compressed? > > Jason > > -----Original Message----- > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] > Sent: Thursday, 18 September 2003 1:11 PM > To: POI Developers List > Subject: Re: LabelRecord Uncompressed > > I think there is a marker which says whether or not it is one or the other. > > On 9/17/03 11:07 PM, "Height, Jason" <[EMAIL PROTECTED]> wrote: > >> Hello >> >> >> >> On the head I get some weird strings for uncompressed label records due to >> the following code: >> >> >> >> field_6_value = StringUtil.getFromUnicodeBE(data, 9 + offset, >> >> field_4_string_len); >> >> >> >> Now I think that this should be (well this causes it to work): >> >> field_6_value = StringUtil.getFromUnicodeLE(data, 9 + offset, >> >> field_4_string_len); >> >> >> >> Or is that only because I am testing on a LE machine. I thought that the >> byte swapping was handled at a much lower level. >> >> >> >> I know that a lot of this stuff changed during my absence, Should I change >> this to LE ?? >> >> >> >> Jason >> >> >> >> > ---------------------------------------------------------------------------- > -- >> -------------------------------------- >> This e-mail (including attachments) is confidential information of > Australian >> Submarine Corporation Pty Limited (ASC). It may also be legally > privileged. >> Unauthorised use and disclosure is prohibited. ASC is not taken to have >> waived confidentiality or privilege if this e-mail was sent to you in > error. >> If you have received it in error, please notify the sender promptly. > While >> ASC takes steps to identify and eliminate viruses, it cannot confirm that > this >> e-mail is free from them. You should scan this e-mail for viruses before > it >> is used. The statements in this e-mail are those of the sender only, > unless >> specifically stated to be those of ASC by someone with authority to do so. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
