Hi all,
I've been looking through the code on HSSF due to a bug I've found
in the font handling and have some questions, please note I am not trying to
pick at anyone's code. Just get a better understanding of the reasons why
some things are done. Then again, these might be areas that need a little
work too ;-)
1. This is the bug. Using the HSSFWorkbook.createFont() to add a font and
then using HSSFWorkbook.findFont(,...) using the newly created fonts getters
to fill in the parameters will fail (returns a null). This only happens with
the first font added. It seems to be something to do with the Excel doco's
statement that font index 4 is not used. I think that the create adds the
font in at index 4 instead skipping it because there is no code in the
Workbook.createNewFont() method to ship this index. So when the
HSSFWorkbook.findFont(...) method comes along, it cannot find the new font
because it is in index 4.
2. Design of this, I noticed that the index management of the records in
HSSF is handled in the HSSFWorkbooks and Workbook classes. I'm wondering why
this is so ? It would seem logical to me that the WorkbookRecordList class
should handle it's own indexes internally. This would centralise the index
handling rules, reduce bugs (such as the one above) and make maintenance a
lot simpler. I.e. it would effectively hide the implementation from the
workbook classes which at the moment have to be aware of it. Is there a
reason why index handling should occur outside of the record management
class ?
3. Also noticed that the WorkbookRecordList works by maintaining a single
ArrayList and pointers to various indexes within it. This seems a bit
clunky. I was thinking that an array of ArrayLists, one for each record type
needed. Then indexes would not have to be maintained. Loading of records
into each array could be handled by looking at the record types or using
constant type indicators and writing would be a simple matter of writing out
each in turn. Something like this would remove the requirement for index
maintainance and make accessing records much easier because all the records
of a specific type would be in a single ArrayList. Is this a valid idea ?
Regards,
Derek Clarkson
Global Applications
Lonely Planet Publications
ph: (03) 8379-8000
Direct: (03) 8379-8100-8401
"It's not a bug - it's an undocumented feature!"
______________________________________________________________________
This email, including attachments, is intended only for the addressee
and may be confidential, privileged and subject to copyright. If you
have received this email in error, please advise the sender and delete
it. If you are not the intended recipient of this email, you must not
use, copy or disclose its content to anyone. You must not copy or
communicate to others content that is confidential or subject to
copyright, unless you have the consent of the content owner.
