Re: cvs commit: xml-fop/src/java/org/apache/fop/render AbstractRenderer.java

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

--- jeremias@apache.org wrote:
>
>   -    private void createSpan(int numCols) {
>   +    /**
>   +     * Creates a new span reference area.
>   +     * @param bodyRegion The region-body to
> create the span for
>   +     * @param spanned true if a spanned region
> should be created
>   +     */
>   +    private void createSpan(BodyRegion
> bodyRegion, boolean spanned) {


Jeremias, I would like to move the initialization of
the Span's columns/normal-flow-reference-areas to the
Span class directly.  The Span constructor will take
three parameters: #columns, column gap, and totalIPD,
instead of its current two, and automatically make
those columns/NFRAs using the calculations you have
here in PSLM.

As a result, we will no longer be creating the
n-f-r-a's within PSLM directly (no more
Span.addAdditionalNormalFlow() calls) because they
will all be created by Span at one time.  When one
column is finished, we just have curFlow point to the
next one in the Span.

Next, within PSLM, instead of a curFlow variable, we
have a int curFlowIdx variable that points to the
zero-based column within the Span currently being
filled.  i.e.,
curSpan.getNormalFlow/Column(curFlowIdx).  This
reduces the chances of curFlow accidentally pointing
to a different Span object's columns.  curFlowIdx
would get incremented each time a column is filled,
and when done a new page is created (or the
page-breaking strategy is activated, etc.)

[I have one more method I would like to add in Span,
public int balanceColumns(), which will be eventually
called by PSLM whenever column balancing needs to be
done (e.g., a new block-area with span traits
indicating a new Span is needed), and would perhaps
return the new, smaller, bpd as a result of the
balancing.  It will stay empty for some time, but PSLM
can call it and PSLM at least will be finished in this
regard.]

Once this is done, I would like to modify
MainReference so that it always has one span by
default.  90% of the time that one span is all that is
needed.  PSLM().addSpan(BR, spanned) (to become
BodyRegion/MainReference.addSpan(boolean spanned)
perhaps), would be called only for new spans needed as
a result of an incoming block-area's span trait
needing a different number of columns (either one or
BR.getColumnCount()).  But the changes in this
paragraph I would revisit after the Span issues above
are finished.

Basically, the change would be that PSLM will still
handle the page-breaking, the flow-mapping, the
collection of areas and determination of (1) when new
spans are needed, (2) when curFlowIdx needs to be
incremented to the next column, and (3) when columns
in a span need to be balanced; however:  the actual
*creating* of n-f-r-a's, spans, and column balancing
will move to Span and BodyRegion/MainReference as
appropriate.

Thoughts?

Thanks,
Glen 

Re: cvs commit: xml-fop/src/java/org/apache/fop/render AbstractRenderer.java

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

Over all, this sounds ok. There's one point, though: the one with the
column balancing. Following XP principles I'd skip that because I'm
almost sure that we can't implement column balancing just by calling a
balanceColumns() method like your foresee. Don't try to do too many
optimizations too soon as we're currently in "rough mode" (in the branch).

On 23.03.2005 00:22:44 Glen Mazza wrote:
> --- jeremias@apache.org wrote:
> >
> >   -    private void createSpan(int numCols) {
> >   +    /**
> >   +     * Creates a new span reference area.
> >   +     * @param bodyRegion The region-body to
> > create the span for
> >   +     * @param spanned true if a spanned region
> > should be created
> >   +     */
> >   +    private void createSpan(BodyRegion
> > bodyRegion, boolean spanned) {
> 
> 
> Jeremias, I would like to move the initialization of
> the Span's columns/normal-flow-reference-areas to the
> Span class directly.  The Span constructor will take
> three parameters: #columns, column gap, and totalIPD,
> instead of its current two, and automatically make
> those columns/NFRAs using the calculations you have
> here in PSLM.
> 
> As a result, we will no longer be creating the
> n-f-r-a's within PSLM directly (no more
> Span.addAdditionalNormalFlow() calls) because they
> will all be created by Span at one time.  When one
> column is finished, we just have curFlow point to the
> next one in the Span.
> 
> Next, within PSLM, instead of a curFlow variable, we
> have a int curFlowIdx variable that points to the
> zero-based column within the Span currently being
> filled.  i.e.,
> curSpan.getNormalFlow/Column(curFlowIdx).  This
> reduces the chances of curFlow accidentally pointing
> to a different Span object's columns.  curFlowIdx
> would get incremented each time a column is filled,
> and when done a new page is created (or the
> page-breaking strategy is activated, etc.)
> 
> [I have one more method I would like to add in Span,
> public int balanceColumns(), which will be eventually
> called by PSLM whenever column balancing needs to be
> done (e.g., a new block-area with span traits
> indicating a new Span is needed), and would perhaps
> return the new, smaller, bpd as a result of the
> balancing.  It will stay empty for some time, but PSLM
> can call it and PSLM at least will be finished in this
> regard.]
> 
> Once this is done, I would like to modify
> MainReference so that it always has one span by
> default.  90% of the time that one span is all that is
> needed.  PSLM().addSpan(BR, spanned) (to become
> BodyRegion/MainReference.addSpan(boolean spanned)
> perhaps), would be called only for new spans needed as
> a result of an incoming block-area's span trait
> needing a different number of columns (either one or
> BR.getColumnCount()).  But the changes in this
> paragraph I would revisit after the Span issues above
> are finished.
> 
> Basically, the change would be that PSLM will still
> handle the page-breaking, the flow-mapping, the
> collection of areas and determination of (1) when new
> spans are needed, (2) when curFlowIdx needs to be
> incremented to the next column, and (3) when columns
> in a span need to be balanced; however:  the actual
> *creating* of n-f-r-a's, spans, and column balancing
> will move to Span and BodyRegion/MainReference as
> appropriate.
> 
> Thoughts?
> 
> Thanks,
> Glen 



Jeremias Maerki