Glen Mazza wrote: > --- 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-bord > er-padding
Hmmm. AFAIK, "traits" is just a semantical distinction for the Area Tree equivalent of the FO Tree properties. (Elements have attributes, Objects have properties, Areas have traits). Not all properties require refinement. For those that don't, you spit back out the user-supplied value. For those that do (because of inheritance, etc.) you spit out the computed or otherwise refined value. Or perhaps I missed your point? > (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). Yes, default-values should be handled in the FO Tree. You are absolutely right that none of that should be hard-coded in the renderers or the layout strategies. > (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? Yes. AFAIK, the getPaddingLeft() is just a convenience for the user. > [2] > http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#refine-bord > er-padding > > 2.) Resolving specific vs. the shorthand properties > (sec. 7.29)--Shorthand properties should not need to > be exposed, for similar reasons as above. Agreed. > > 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. Point taken. The point I was trying to make is that it is downstream of the FOTree, which I would like to be fairly capability-agnostic. Make Layout or Renderer complain if they can't handle a requested feature. We do have to (for now anyway) deal with Renderer-contextual things (AWT fonts for example), but we should IMO pretty aggressively keep these to a minimum with the hope of eventually getting rid of all of them. > > 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. OK. > > 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.] I don't see any advantage to even trying this and lots of disadvantages. However, it almost certainly makes sense to have similar accessor methods in the Area Tree that return its traits for the renderers. Also (this is way off-topic), someday I want to look at the possibility of having the content (as opposed to placement) portions of the Area Tree be "views" of the FO Tree. IOW, getText for an area might look like: String getText() { //maybe return char[] instead -- you get the idea return getParentFO.getText(getStart(), getOffset()); { The Area has stored the starting place and size of the text, which exists only in the parent FO. This goes against our current philosophy of a self-contained Area Tree, but once we get the FO Tree serialized when needed that concern should go away. Then, (someday) you can put a GUI on top of the Area Tree, and, (someday) if you can find a way to make the FO Tree simply be a view of the semantic XML document (XSLT is pretty one-way), you can have a nice GUI editor for your XML. Way, way off topic, pie-in-the-sky. But I think it is OK to think in these terms when your building the smaller pieces. > > 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. Interesting, but sounds like a chunk of work, esp. with our Forrest workflow. I hope that if we get all of these foundation pieces built, it will by then just be easier to go make the PCL renderer do it. > > 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. Fair enough. Also, we need to make sure we handle Peter West's gotchas in this scheme, i.e. the situations where we pass through an "I don't know" value that will be resolved in layout. Victor Mote
