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/