cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: HSSFSerializer - Extensions?
Date Tue, 31 Dec 2002 17:31:07 GMT
Jody Goldberg wrote:

>We're amenable to extensions to the existing format.  Moreover
>gnumeric is going to be making a jump to a new wrapper format
>shortly at which time I hope to make larger scale changes to
>the xml representation and would appreciate any feedback you have on
>limitations or irritations in the current schema.
I know for me, the biggest irritation is with "style region".  While I 
like that in one respect its very
disjointed from Excel and produces a leaky abstraction, but thats not 
all, it can cause data loss.

Meaning I might want to group a particular set of cells as one type of 
style not particularly related to
location.  I might alter them all later.

My preference would be (this markup is off the top of my head and not 
intended to be accurate, just give the picture):

  <style number="1">....color, background, etc </style>

  <styleregion startcol....startrow...endrow.... style="1"/>

   <cell row="1", col="2" style="1"></cell>

Here we have a defined style which the style region is assinged to.  The 
style region is "optional" but serves as a "default" for cells in a
certain region of the sheet.  The cells may also be specifically defined 
a style which overrides the style region's style that the cell falls within.

This would allow an efficiency gain with the HSSFSerializer when users 
didn't use style regions (as assigning by cell is how excel does it).
I LIKE the style regions for some situations, but hate them for others 
(like total rows...its a pain to go up and create a style region, nor is it
particularly efficient).  Furthermore it allows you to assign one style 
to multiple regions...

Thats been our #1 gripe for like a year now (but I never said anything 
about it so its my fault ;-) )...  Hope that helps...


>On Fri, Dec 27, 2002 at 02:39:05PM -0500, Andrew C. Oliver wrote:
>>My thought would be to make the changes acceptable but not required and 
>>notify the gnumeric folks
>>( about the 
>>extensions.  They might be interested in
>>implementing them.  For the actually SCHEMA, create a different schema 
>>based on the original and mark
>>files which use the extensions as being compliant to that schema and not 
>>the one hosted at/by gnumeric...
>>Danny Mui wrote:
>>>There are some features that HSSF supports that gnumeric does not, one 
>>>instance is setting fonts for the header/footer (among others).  This 
>I'd be interested in a list of the others.  Adding this would be
>simple and would give me some insight into what sorts of features
>real users are looking for.
>>>is currently a need for my project I'm working on and I'm wondering 
>>>how I should go about implementing this.
>>>Should I extend the schema to accomodate these new features?
>>>I extended the schema to support a few things so far:
>>>1) Added an 'inches' unit designation to pass-through the values for 
>>>margins since the 'in' unit requires conversion.
>Requires conversion by what ?
>>>2) Added a &[FILE] attribute for the header/footer since excel 
>>>supports it but my version of gnumeric does not.
>I just added it in about 10 seconds.  The extension will be in
>1.1.15, and is trivial enough that I could back port it to be in the
>next stable release 1.0.12.

To unsubscribe, e-mail:
For additional commands, email:

View raw message