--- 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".) [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#refine-border-padding (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 setting). (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] http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#refine-border-padding 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 reasons: 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 others. > 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 FO. 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, etc. > 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. Glen __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
