Thanks for the clarification. PDF Bookmarks aren't working currently, so that's what I'm looking at ATM. We may have another object extending the TreeExt interface, should we have a fox:metadata in the future.
Still, I wonder if it may be better to do away with this interface and just hardcode the layout/rendering of these objects (i.e. bookmarks) directly, just like we do all the other Area objects that are created during the layout process. This would simplify area.extensions.BookmarkData and area.AreaTreeModel processing code. Thoughts (anyone)? The major benefit I see of TreeExt is that our Renderer interface can remain with a single renderExtension() for this and any other TreeExt in the future. But OTOH clarity arguments can be made for explicitly spelling out each object that a Renderer may need to support. For example, having renderBookmarks(), processMetaData(), etc. methods instead of using instanceof within renderExtension() methods to determine the TreeExt object in question. Thanks, Glen --- Keiron Liddle <[EMAIL PROTECTED]> wrote: > Hi Glen, > > Yes it is sort of #2. I think the naming is along > the lines that it is > an extension at the tree level, outside the normal > formatting areas, not > an extension to the area tree as such. > > In the example of the bookmarks it is an extension > that encompasses the > whole document (in terms of resolving and output) so > rather than being > an area it is an extension at the area tree > (document) level. > > Not sure what other examples there would be, but of > course it was > originally done to handle bookmarks and anything > like that that came > along. > > Hope that is clear. > > Keiron > > -----Original Message----- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > Sent: Sunday, 24 October 2004 10:46 AM > To: [EMAIL PROTECTED] > Subject: meaning of Area.TreeExt interface > > Keiron (or others?), > > A few years back Keiron created an Area.TreeExt > interface for area tree extensions. PDF Bookmarks > are > our only object that implements this interface > currently. > > I'm not certain what was originally meant by an > "area > tree extension" though. Is it: > > 1.) A layout area that is generated from a non-W3C > formatting object (i.e., were fox:bookmarks > fo:bookmarks instead, it wouldn't be extending > TreeExt.) > > or > > 2.) A layout area that is external to what gets > printed on the document itself (i.e., fox:bookmarks > again, because PDF bookmarks appear outside the > document.) > > From the coding, I'm guessing #2 is the intent. Am > I > correct? > > Thanks, > Glen > > > >
