--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Proposal:
> I propose that public "get" methods be used to
> retrieve FO Tree property
> values, and that the data behind these values be
> made as private as
> possible. The methods should be given a name based
> on the XSL-FO Standard.
> For example, the "max-width" property should be
> accessed using the method
> "getMaxWidth". The values returned should be the
> "refined" values.

(a) be careful--"refined" (resolved) values here would
imply "traits" according to the spec[1]--which would
be only a fairly small subset of all possible property
values.  Which do you mean (I'm personally inclined to
just returning "traits".)


(b) Where possible, I would like the API to
encapsulate the business logic away from the renderers
and the layout strategies to save repetition of
business logic code (for example, default-value

(c) Also, as I was mentioning above with limiting just
to traits, some properties should not need to be
accessible via the API.  Examples:

1.) Resolving absolute and relative border properties.
 The spec[2] gives specific rules for resolving
precedence when both relative and absolute properties
are given: (say, both "padding-left" and
"padding-start" are given).  

What I'd like is the API *not* to expose intermediate
properties that would need subsequent business logic
before using, such as getPaddingLeft()--layout and
renderers don't need it.  Have the API just provide
getPaddingStart(), and let that method determine,
based on the presence of absence of the PaddingLeft
(or PaddingRight, etc.) what the PaddingStart() value
is.  Would you be in agreement with this?


2.) Resolving specific vs. the shorthand properties
(sec. 7.29)--Shorthand properties should not need to
be exposed, for similar reasons as above.

> Discussion:
> 2. This could perhaps be implemented for now only in
> FObj (??).
> 3. This is not directly relevant to the question,
> but needs to be addressed
> from the "big picture" standpoint. With the FO Tree
> mostly isolated, and
> LayoutStrategy implemented, the issue of whether a
> certain feature is
> implemented or not moves from the FO Tree to the
> specific LayoutStrategy.

Not necessarily--although it now above the FO Tree,
it's really with the specific renderer.  For two

1) Some properties, such as background-color, aren't
even touched by LayoutStrategy.  LS never gets into
those properties.

2) (degenerate case) Some of our 1.0 renderers are all
of 50 or 60 LOC right now.  Now matter how work-of-art
the LS is or can be, "certain feature is implemented"
will be a "no" for those renderers, while not for

> Each LayoutStrategy eventually needs to track which
> objects and properties
> it supports. 
> The
> LayoutStrategy needs to be the entity that reports
> on whether a feature is
> supported (perhaps using a scheme similar to
> properties.xml).

Be careful--besides the background-color stuff
mentioned above, even certain border and padding
features end up being implemented via the specific
Renderer code.  So you'll have to ask the
Renderer--the LS wouldn't know.

> The FO Tree should always store and
> return the data, without
> regard to whether it can be used or not. 

What would you think about storing these accessor
methods (not necessarily the data itself) in the
Area.xxx class objects instead, for referencing by the
layout strategies and the renderers?

[However, not all FO's are represented by Area
objects, I believe, so storing the methods with the
Area Tree class object may not be possible.  Also,
there is not always a 1-to-1 mapping between fo:block
and Area.block (a new instance of the latter gets
created for each page needed in rendering the
fo:block).  So some properties defined for an
fo:block, such as space-after, would probably need to
resolve to '0' for each Area object created for its
rendering, except for the last, *if* we kept the
accessor methods in the Area.xxx objects.]

> In the
> future, our properties.xml
> file, "compliance" page, and perhaps other things
> need to handle this. 

I would like to see the compliance page change into
several pages.  The first page would just be a list of
FO's.  Clicking on one of the FO's will bring the
reader to another page, showing a table:

1) first column: All the possible properties for that

2) second--umpteeth column, one column for each output
type:  whether that property is implemented for that
current render-type.

3) at the bottom of the table--various "partially
implemented" comments, caveats, notes, etc.

That way people will know what works for PCL, PDF,

> 4. If accepted, this would be a great project for
> one of the new developers
> to tackle. I don't mean to volunteer anyone, but it
> might be a good "feet
> wet" project.

Not always--a getBorderBeforeColor() for a table cell
will need to take into account what was declared for
any row, column, and possibly table-edge that the its
before edge shares.  Keep in mind, some of these
accessor functions will require significant
programming logic that we don't presently have.

> My vote:
> +1
> Victor Mote

Abstaining currently--although I don't see anything
that bad right now.  I'd like to wait for more
comments from you and the others.


Do you Yahoo!?
Free Pop-Up Blocker - Get it now

Reply via email to