Questions about the AreaTree, Traits and Renderers

[Peter Kullmann <p....@arenae.ch>]

I'd like to ask some questions that came up when I was trying to
understand the redesigned code.

1. Some traits have been implemented (eg font-size) and others have not.
For example the traits is-reference-area and is-viewport-area: Will they
be implemented eventually or is it the idea that these traits are
hard-coded into the classes - like "PageViewport" is obviously an area
with is-viewport-area = true.

2. Some traits like "top-position" are implemented as members of the
Area classes, I think (e.g. length, startIndent, getIPD and so on). Is
there a plan as to which traits will be accessible by their names in the
spec and which will be implemented through perhaps completely different
means in the Area classes. I'm rather confused with respect to this
issue, so I fear my question is rather unclear.

3. Im my imagination - or what I think I have understood from the spec -
the area tree (once it is finished) holds all information that is needed
before rendering. A renderer then takes the area tree and has a more or
less trivial task of actually painting what is described in the area
tree. In particular a renderer that is capable of adressing the output
medium in any order should be able just to translate fop coordinates to
renderer-specific coordinates and paint 'it'. So here is my question:
Why are currentIPPosition and currentBPPosition necessary in the
AbstractRenderer? Why does the renderer have to increment these
variables? In my opinion the positioning of areas to be rendered should
be done by the layout task. The renderer just reads the position of eg
word from the Word area (by accessing a trait or something else; see
Q2).

4. This isn't a question actually: Whilst trying to understand the area
tree and the rendering stuff I've written an XFig-renderer. The goal was
to create an xfig-drawing that contains boxes for the different areas of
a fo document (just on one page). The xfig renderer is working and is
producing some boxes. As you can see by the questions above I don't know
whether these boxes are 'right'. Is anyone interested in the xfig
renderer? 

Thanks a lot for answering some or all of these questions.

Peter




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

Re: Questions about the AreaTree, Traits and Renderers

[Keiron Liddle <ke...@aftexsw.com>]

Hi Peter,

On Fri, 2002-08-02 at 17:31, Peter Kullmann wrote:
> I'd like to ask some questions that came up when I was trying to
> understand the redesigned code.
> 
> 1. Some traits have been implemented (eg font-size) and others have not.
> For example the traits is-reference-area and is-viewport-area: Will they
> be implemented eventually or is it the idea that these traits are
> hard-coded into the classes - like "PageViewport" is obviously an area
> with is-viewport-area = true.

They might be implemented eventually if it is important for the
renderers. Some of those traits are relevant to the layout not the
renderer.

> 2. Some traits like "top-position" are implemented as members of the
> Area classes, I think (e.g. length, startIndent, getIPD and so on). Is
> there a plan as to which traits will be accessible by their names in the
> spec and which will be implemented through perhaps completely different
> means in the Area classes. I'm rather confused with respect to this
> issue, so I fear my question is rather unclear.

At the moment the idea is that decoration traits will be added as needed
to a list, position traits (and data) are members of the class and
layout traits are handled by the layout managers.
So it depends on what traits you are referring to.
Hope that answers the question.

> 3. Im my imagination - or what I think I have understood from the spec -
> the area tree (once it is finished) holds all information that is needed
> before rendering. A renderer then takes the area tree and has a more or
> less trivial task of actually painting what is described in the area
> tree. In particular a renderer that is capable of adressing the output
> medium in any order should be able just to translate fop coordinates to
> renderer-specific coordinates and paint 'it'. So here is my question:
> Why are currentIPPosition and currentBPPosition necessary in the
> AbstractRenderer? Why does the renderer have to increment these
> variables? In my opinion the positioning of areas to be rendered should
> be done by the layout task. The renderer just reads the position of eg
> word from the Word area (by accessing a trait or something else; see
> Q2).

The main reason is that areas are stacked within the parent area. So the
position of an area starts from the stacking position of the last area
plus its height.
If we need to have the x,y position then it would need more information
and I think it could get quite complex to calculate with different
reference orientations etc. Imagine if it was some text with rl mode and
orientation of 90 degrees, what is the position, then how is that
rendered.

> 4. This isn't a question actually: Whilst trying to understand the area
> tree and the rendering stuff I've written an XFig-renderer. The goal was
> to create an xfig-drawing that contains boxes for the different areas of
> a fo document (just on one page). The xfig renderer is working and is
> producing some boxes. As you can see by the questions above I don't know
> whether these boxes are 'right'. Is anyone interested in the xfig
> renderer? 

I have no idea what xfig is so someone else can answer...

> Thanks a lot for answering some or all of these questions.
> 
> Peter



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