poi-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Zalewski <zalew...@optonline.net>
Subject RE: Problem generating a large file when following the POIFSstandard
Date Thu, 26 Feb 2004 14:43:18 GMT
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

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: poi-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-user-help@jakarta.apache.org

View raw message