You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Marc Portier <mp...@outerthought.org> on 2006/06/12 12:21:48 UTC

why limit the size of style-regions?

Hi there,

I'm looking for getting maybe a more permanent solution for issue 24480
(http://issues.apache.org/bugzilla/show_bug.cgi?id=24490)

I think it's safe for poi-dev to just close it as the issue actually is
inside the cocoon codebase rather then the poi-codebase. (I'm planning
on opening a new issue on this in cocoon's jira and will drop the link
as a comment on #24490 as soon as that is done)

The cause for the described behavior is actually a hard coded limit in
our serializer [1]

(relevant portions)

>     58      //kludge constant to fix gnumeric's love of declaring large stlye regions
>     59      //for the blank sections of the sheet w/no apparent purpose that we can
>     60      //
>     61      private int MAX_AREA = 2001;
>     62

and:

>     93          if (region.getArea() < MAX_AREA) {
>     94              //protect against stupid mega regions
>     95              //of generally NOTHING and no real
>     96              //puprose created by gnumeric
>     97              getLogger().debug("region added");
>     98              _style = getSheet().addStyleRegion(region); //test
>     99          } else {
>    100              invalid = true;
>    101          }


This code has been in cocoon pretty much unchanged since its original
commit (11-2002) and over in cocoon land there doesn't seem to be real
live memories [2] around the reasoning and argumentation for this
built-in limitation.

So before doing something stupid like ignorantly removing the limits I'm
polling this list for known issues around the size of these
style-regions you guys might be aware of.

Some questions popping up:
-Should the size of these regions still be limited?
-What is this limitation to prevent? OutOfMemory?
-Is the limit (actual value) still appropriate?
-Are there other ways to achieve the same?
-Suppose people would work around the limitation by introducing multiple
2000-cell-sized regions in the stream: would they still be faced with
(whatever) problem this code tries to circumvent?
-If not: would it be meaningful to just chunk it up inside the
serializer rather then push this burdon to our end-users...
-Are there test-cases around showing why the POI API should be used in
this way?


Thx, upfront for all insights you could share.

regards,
-marc=
[1]
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-poi/cocoon-poi-impl/src/main/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/EPStyleRegion.java

[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114907748501047&w=2
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
Mailing List:    http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta POI Project: http://jakarta.apache.org/poi/