two more class renamings

[Glen Mazza <gm...@apache.org>]

Team,

I see two LM classes that appear misnamed, which can
cause confusion as to their purpose:

1.) FlowLayoutManager is defined as "the layout
manager for an fo:flow object" -- but actually it can
also be for an fo:static-content object if the static
content is directed to the region-body of the page.

Further, the class processes a single
normal-flow-reference-area (i.e., a column) within a
span-reference-area of the region-body of the page[1].
 In other words, the processing of an fo:flow actually
could take *several* of these objects if the span is
multi-column, or its output takes several pages.  So I
think FlowLayoutManager should be renamed to
NormalFlowLayoutManager.

2.)  Similarly, the StaticContentLayoutManager should
be renamed to SideRegionLayoutManager, because the
output of both fo:static-content and fo:flow can be
directed to it, also fo:static-content can actually
end up being rendered by NormalFlowLayoutManager(s) if
(1) above occurs.

Any objection to the two renamings?

Thanks,
Glen

[1]
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_region-body

Re: two more class renamings

[Chris Bowditch <bo...@hotmail.com>]

J.Pietschmann wrote:

> Glen Mazza wrote:
> 
>> if the static
>> content is directed to the region-body of the page.
> 
> 
> Is this even allowed by the spec?

No, this isnt valid.

> 
>> 2.)  Similarly, the StaticContentLayoutManager should
>> be renamed to SideRegionLayoutManager, because the
>> output of both fo:static-content and fo:flow can be
>> directed to it,
> 
> 
> No, the latter can't happen. The 0.20.5 branch even tests
> for this and aborts in that case.

Glen: I dont think its appropriate to rename these classes as your reasoning 
appears flawed.

Chris

Re: two more class renamings

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

Glen Mazza wrote:
> if the static
> content is directed to the region-body of the page.

Is this even allowed by the spec?

> 2.)  Similarly, the StaticContentLayoutManager should
> be renamed to SideRegionLayoutManager, because the
> output of both fo:static-content and fo:flow can be
> directed to it,

No, the latter can't happen. The 0.20.5 branch even tests
for this and aborts in that case.

J.Pietschmann

Re: two more class renamings

[Simon Pepping <sp...@leverkruid.nl>]

What Andreas argues here is what I would think as well: The LMs are
tied to the formatting objects, not to the page regions they populate.

Regards, Simon

On Tue, Apr 05, 2005 at 07:10:40PM +0200, Andreas L. Delmelle wrote:
> > -----Original Message-----
> > From: Glen Mazza [mailto:gmazza@apache.org]
> >
> 
> Hi,
> 
> > I see two LM classes that appear misnamed, which can
> > cause confusion as to their purpose:
> >
> > 1.) FlowLayoutManager is defined as "the layout
> > manager for an fo:flow object" -- but actually it can
> > also be for an fo:static-content object if the static
> > content is directed to the region-body of the page.
> 
> So, IIC you're considering the FlowLM or StaticContentLM as being unrelated
> to the fo:flow or fo:static-content objects --or at least: more related to
> the page-regions than to the formatting objects?
> 
> Agreed that, according to the XSL Spec. --WD or not--, it's allowed to
> redirect the fo:static-content (for example) to a different region than
> 'before' or 'after', but it could be argued that another option is to let
> the StaticContentLM take care of the redirection of the fo:static-content to
> the right region... I suppose the current StaticContentLM should already
> allow for redirection to either 'xsl-region-before' or 'xsl-region-after',
> so it should be quite straightforward to add 'xsl-region-body' as another
> alternative (?) After all, there is a key difference between Flow and
> StaticContent when considering markers: the first one can contain
> fo:markers, while the second one can only retrieve them...
> One aspect that *does* seem to become increasingly important is the
> inter-play of the StaticContentLM and the FlowLM --if both can layout to the
> same region(s).
> 
> IMO there is no solid argument against the *reason* itself for this
> renaming --on the contrary, it seems more than reasonable--, but regardless
> of its validity, I do have my doubts on the end-result of the proposed way
> to solve the related issues...
> 
> 
> Cheers,
> 
> Andreas
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl

RE: two more class renamings

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Glen Mazza [mailto:gmazza@apache.org]
>

Hi,

> I see two LM classes that appear misnamed, which can
> cause confusion as to their purpose:
>
> 1.) FlowLayoutManager is defined as "the layout
> manager for an fo:flow object" -- but actually it can
> also be for an fo:static-content object if the static
> content is directed to the region-body of the page.

So, IIC you're considering the FlowLM or StaticContentLM as being unrelated
to the fo:flow or fo:static-content objects --or at least: more related to
the page-regions than to the formatting objects?

Agreed that, according to the XSL Spec. --WD or not--, it's allowed to
redirect the fo:static-content (for example) to a different region than
'before' or 'after', but it could be argued that another option is to let
the StaticContentLM take care of the redirection of the fo:static-content to
the right region... I suppose the current StaticContentLM should already
allow for redirection to either 'xsl-region-before' or 'xsl-region-after',
so it should be quite straightforward to add 'xsl-region-body' as another
alternative (?) After all, there is a key difference between Flow and
StaticContent when considering markers: the first one can contain
fo:markers, while the second one can only retrieve them...
One aspect that *does* seem to become increasingly important is the
inter-play of the StaticContentLM and the FlowLM --if both can layout to the
same region(s).

IMO there is no solid argument against the *reason* itself for this
renaming --on the contrary, it seems more than reasonable--, but regardless
of its validity, I do have my doubts on the end-result of the proposed way
to solve the related issues...


Cheers,

Andreas