hack to avoid memory overflow with tables

["J.Pietschmann" <j3...@yahoo.de>]

Hi all,
now that there are a few more modifications in the maintenance
branch, waht about including the fixes mentione here:
http://marc.theaimsgroup.com/?l=fop-user&m=105371539508744&w=2

It would need some testing (read 0.20.5rc4)

J.Pietschmann



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RC4 (was Re: hack to avoid memory overflow with tables)

[Christian Geisert <ch...@isu-gmbh.de>]

J.Pietschmann schrieb:
> Hi all,
> now that there are a few more modifications in the maintenance
> branch, waht about including the fixes mentione here:
> http://marc.theaimsgroup.com/?l=fop-user&m=105371539508744&w=2
> 
> It would need some testing (read 0.20.5rc4)

Nooo, no more RCs for 0.20.5 please
It's almost one year after the last release and as it seems
quite stable now so I would really like to make the release
soon.

Yes I know we agreed on 0.20.5 beeing the last release from
maintenance branch but making RCs after RCs is IMHO worser
than making changes after the "last release" and providing
daily builds or whatever.

Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: hack to avoid memory overflow with tables

[Jeremias Maerki <de...@greenmail.ch>]

My thoughts tend to go in the direction to factor out support subsystems
like fonts, PDF, SVG etc. These are areas where a lot of improvements
have happened during the last months and I'm currently ending up
applying bugfixes in two places. As Peter I see a lot of complications
in trying to bring the two layout engines under one umbrella, though if
you find a good way I'm certainly not going to stand in the way. I've
decided to stay out of the layout engine (for now) because I've never
invested enough time to really be of use in there. So my place is
currently the "support subsystems" because that's where I can really
make a difference.

On 27.05.2003 19:32:07 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > I'm slowly getting the impression it may be better if we really totally
> > modularize FOP (splitting it up into several independently usable
> > subprojects) so development is only split in the layout field which is
> > the major problem-child here. But that alone would take long enough and
> > I can't even imagine how much it will hurt the redesign.
> 
> You're on the right track, but I don't know that we need separate
> subprojects. I am just starting to implement an idea that I have been
> kicking around for several weeks. I want to create a LayoutStrategy that is
> either abstract or an interface, and which can be subclassed/implemented by
> each concrete strategy. We currently have two -- one in the redesign branch,
> and one in the maintenance branch. The goal would be to eventually drop the
> maintenance branch layout system into the redesign code as an implementation
> of LayoutStrategy. It will always be a deficient implementation, but right
> now it is the best one that we have (else we would be releasing code from
> the trunk). This would allow us to start releasing code from the trunk, and
> would unify our efforts in infrastructure, control, FO Tree, Area Tree, etc.
> This is something we really should do eventually anyway, and IMO it is
> better to do sooner than later.
<snip/>

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: hack to avoid memory overflow with tables

[Victor Mote <vi...@outfitr.com>]

Peter B. West wrote:

> While I don't denigrate any of these ongoing efforts, I am increasingly
> of the view that everything occurring between the reading of the fo xml
> and the layout of the area tree is interconnected in very nasty and
> intricate ways.  The description of this process in the Rec (I resisted
> the obvious temptation here) has done many developers, including the FOP
> developers, a great disservice.
>
> It's this intertwining that makes me skeptical about pluggable layout.
> It may be feasible, but I don't see that it is feasible until we have a
> very good understanding of the way layout will be achieved, and a full
> picture of the flow of control in the first full implementation.

My naive understanding of the Area Tree is that it could / should be
constructed as a "view" of the FO tree. It should not, for example, IMO,
contain any Strings at all, but objects in it should contain offset and size
values for the parent FOText object in the FO tree. Similarly, perhaps it
should not contain the trait values at all, but should compute them from the
parent on-the-fly. The FO tree should normalize the values as much as
possible (which in many cases is completely), then the Area tree can
complete whatever computation is necessary before returning the value to
use. I realize that this violates your compute-it-once principle, but I was
frankly confused by that principle. It seemed to me that the intertwining
issues that you mention utterly prevent compute-it-once.

Second, and more importantly, regardless of what design is used in the Area
Tree, there is nothing that prevents us from factoring code that is common
to more than one LayoutStrategy into a module that is usable by any
LayoutStrategy. If there are issues that force things to be intertwined,
then those could be "common" code.

> Factoring out the high-level control is still a valuable and achievable
> step forward, but I'm not sure about "control of when layout is started,
> when FO trees are destroyed."  I assume that refers to the patient vs.
> eager layout discussion.  At that level, certainly, control values can
> be factored out.

Actually the two examples listed are, in my mind, examples of the high-level
control issues that we want factored out. Patient vs. eager is only part of
the story. Also included here are such issues as reusing session and
document objects in embedded environments.

> I don't want to discourage your efforts, but I think you will need to
> keep these things in mind.

I will. Thanks. If I come back humbled from the effort, perhaps at least
some useful documentation will emerge.

Victor Mote



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: hack to avoid memory overflow with tables

["Peter B. West" <pb...@powerup.com.au>]

Victor, Jeremias,

Just a couple of notes on the discussion below.

It is a mistake to say, because there is no great ferment of coding, 
that nothing is being done on the redesign of layout.  I, for one, am 
currently giving the layout a great deal of thought, triggered in my 
case by the requirements of integrating the alt.design FO tree.  I'm 
sure the Keiron is in the same boat, as are you, Jeremias and, I think, 
Jo"rg (my mailer may scramble this).

While I don't denigrate any of these ongoing efforts, I am increasingly 
of the view that everything occurring between the reading of the fo xml 
and the layout of the area tree is interconnected in very nasty and 
intricate ways.  The description of this process in the Rec (I resisted 
the obvious temptation here) has done many developers, including the FOP 
developers, a great disservice.

It's this intertwining that makes me skeptical about pluggable layout. 
It may be feasible, but I don't see that it is feasible until we have a 
very good understanding of the way layout will be achieved, and a full 
picture of the flow of control in the first full implementation. 
Factoring out the high-level control is still a valuable and achievable 
step forward, but I'm not sure about "control of when layout is started, 
when FO trees are destroyed."  I assume that refers to the patient vs. 
eager layout discussion.  At that level, certainly, control values can 
be factored out.

I don't want to discourage your efforts, but I think you will need to 
keep these things in mind.

Peter

Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> 
>>I'm slowly getting the impression it may be better if we really totally
>>modularize FOP (splitting it up into several independently usable
>>subprojects) so development is only split in the layout field which is
>>the major problem-child here. But that alone would take long enough and
>>I can't even imagine how much it will hurt the redesign.

...

>  In short, nothing is being done on redesign now, so how
> can it possibly be hurt by anything?

...

>   It would be helpful to resolve some
> of our high-level control issues before starting down this path, or at least
> as part of this project. Moving control of when layout is started, when FO
> trees are destroyed, etc. up to higher-level objects will be extremely
> helpful in isolating these subsystems from each other and allowing multiple
> layout strategies.
> 
> I see the sequence as follows:
> 1. Resolve design of, then implement the high-level control changes. This is
> the Session / Document / Rendering Context issue discussed on the
> Avalonization wiki, section entitled "Startup Concepts Proposal" at
> http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization
> 
> 2. Isolate the (existing redesign) layout by forcing all contact with the
> layout systems to run through the LayoutStrategy. Every layout class except
> the Stategy implementation becomes non-public (I think).
> 3. Drop in the maintenance branch layout as an implementation of
> LayoutStrategy, keeping it isolated as well. Even if this effort is
> unsuccessful for some reason, or the redesign layout is completed before
> this can be done, steps one and two above are still needed & useful.

-- 
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: hack to avoid memory overflow with tables

[Glen Mazza <gl...@yahoo.com>]

--- Victor Mote <vi...@outfitr.com> wrote:
> The goal would be
> to eventually drop the
> maintenance branch layout system into the redesign
> code as an implementation
> of LayoutStrategy. It will always be a deficient
> implementation, but right
> now it is the best one that we have (else we would
> be releasing code from
> the trunk). 

FOP is ultimately a mathematical entity, so we should
be able to avoid the matter-of-opinion conclusions
that would lead to multiple layout strategies.

I see FOP's goals as twofold:

1.) Generate multiple document types accurately.

2.) Generate a high number of very large documents in
a very short amount of time, with "high", "very
large", and "very short" taken to their mathematical
limits.

While there can be plenty of discussion of how best to
obtain #1 and #2, once it is determined that solution
A takes x seconds and solution B takes x + 2 seconds,
you tend to go with solution A.  So over the long
term, multiple layout strategies may not be needed.  

Glen


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: hack to avoid memory overflow with tables

[Victor Mote <vi...@outfitr.com>]

Jeremias Maerki wrote:

> I'm slowly getting the impression it may be better if we really totally
> modularize FOP (splitting it up into several independently usable
> subprojects) so development is only split in the layout field which is
> the major problem-child here. But that alone would take long enough and
> I can't even imagine how much it will hurt the redesign.

You're on the right track, but I don't know that we need separate
subprojects. I am just starting to implement an idea that I have been
kicking around for several weeks. I want to create a LayoutStrategy that is
either abstract or an interface, and which can be subclassed/implemented by
each concrete strategy. We currently have two -- one in the redesign branch,
and one in the maintenance branch. The goal would be to eventually drop the
maintenance branch layout system into the redesign code as an implementation
of LayoutStrategy. It will always be a deficient implementation, but right
now it is the best one that we have (else we would be releasing code from
the trunk). This would allow us to start releasing code from the trunk, and
would unify our efforts in infrastructure, control, FO Tree, Area Tree, etc.
This is something we really should do eventually anyway, and IMO it is
better to do sooner than later.

There are three issues: 1) Some will not like this approach as it seems to
draw resources away from the redesign. I'll not reargue this issue again now
unless it is needed. In short, nothing is being done on redesign now, so how
can it possibly be hurt by anything? Also, eliminating thrashing between two
branches will help all of us find resources to work on layout redesign. 2)
Some will think that bringing the maintenance branch layout into the
redesign will reintroduce the maintenance branch problems. Obviously, this
should be avoided, and I think it can be. There are no doubt methods and
data which will need to be moved around to get the maintenance branch layout
modularized, but it seems possible. 3) It would be helpful to resolve some
of our high-level control issues before starting down this path, or at least
as part of this project. Moving control of when layout is started, when FO
trees are destroyed, etc. up to higher-level objects will be extremely
helpful in isolating these subsystems from each other and allowing multiple
layout strategies.

I see the sequence as follows:
1. Resolve design of, then implement the high-level control changes. This is
the Session / Document / Rendering Context issue discussed on the
Avalonization wiki, section entitled "Startup Concepts Proposal" at
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization

2. Isolate the (existing redesign) layout by forcing all contact with the
layout systems to run through the LayoutStrategy. Every layout class except
the Stategy implementation becomes non-public (I think).
3. Drop in the maintenance branch layout as an implementation of
LayoutStrategy, keeping it isolated as well. Even if this effort is
unsuccessful for some reason, or the redesign layout is completed before
this can be done, steps one and two above are still needed & useful.

I really didn't want to mention any of this until it was done, but I wanted
to encourage Jeremias' train of thought. Also, coming to an agreement on
steps one and two, and completing them, makes step three much easier. If we
can reach a consensus on items 1 and 2, I'll start on them right away. I
don't think they are big tasks, but they are pervasive and design-oriented,
and I think they require your approval.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: hack to avoid memory overflow with tables

[Jeremias Maerki <de...@greenmail.ch>]

Hmm, good for the users in short-term, bad for FOP's evolution and for
users in long-term. I'm -0.

I'm slowly getting the impression it may be better if we really totally
modularize FOP (splitting it up into several independently usable
subprojects) so development is only split in the layout field which is
the major problem-child here. But that alone would take long enough and
I can't even imagine how much it will hurt the redesign.


On 27.05.2003 01:08:47 J.Pietschmann wrote:
> Hi all,
> now that there are a few more modifications in the maintenance
> branch, waht about including the fixes mentione here:
> http://marc.theaimsgroup.com/?l=fop-user&m=105371539508744&w=2
> 
> It would need some testing (read 0.20.5rc4)


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org