If this is a discussion towards the development of POI and not on usage it should move to POI-dev. -- 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? > From: Michael Zalewski <[EMAIL PROTECTED]> > Reply-To: "POI Users List" <[EMAIL PROTECTED]> > Date: Thu, 26 Feb 2004 09:43:18 -0500 > To: POI Users List <[EMAIL PROTECTED]> > Subject: RE: Problem generating a large file when following the POIFSstandard > > I don't mean to add fuel to the fire. But I have some questions: > > 1. Brandon pointed out that a C++ implementation based on POIFS has trouble > writing files larger than 6.8 MB, where XBATs must be created. Do we know > that POIFS creates these large files correctly? Has anyone used HSSF to make > a XLS larger than 7 MB? How much heap space was required? > > 2. For that matter, where does the term XBAT come from? I thought it was > called DIF (Double Indirect FAT). > > 3. There are some other differences that I notice in the way POIFS handles > things versus COMPOBJ.DLL. The most notable is that HSSF does not put > something called the 'Storage Class ID' into the root entry or the OLE Doc > file header. But Excel doesn't seem to care. POIFS has no support for > 'CompObj' stream, which is required for embedding (and is used for Word and > Project even when the files are not embedded - but again the application > doesn't seem to care if the stream is present or not when the document is > read from a file). POIFS cannot create a document stream of 0 length (it's a > known bug). And finally, POIFS puts the directory structure in block 0 > whereas Office always puts the document stream into block 0. None of these > differences should account for Brandon's problems (I don't think). > > 4. Does POIFS support any block size other than 512 bytes? Not sure, but I > think Microsoft Map uses a larger sector size. Since > POIFSConstants.BIG_BLOCK_SIZE is statically defined (instead of interpreting > the value at offset 30 from the beginning of the file. This value is (I > guess) ignored by POIFS, but should be interpreted as the base 2 logarithm > of the large sector size (so it should be 9 for 512 bytes used by Microsoft > Office, and I think 10 for 1024 bytes on some files produced by Microsoft > Map). > > If Brandon's C++ derivative supports the variant block sizes, perhaps he > could try using a 1024 block size. Doing this should allow you to go to over > 12 MB without the need for XBATs (or DIFs). I would really like to know if > that works - but I seriously wonder if he would report back anyway. > > Note: I am not at all certain about Microsoft Map. Just had reports of > someone using POIFS to read that file, and everything was 'one block off'. > When (if) I ever follow up on it, I will report results back to this list > (unless I get viciously shouted down). > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
