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
> 
> 
> 
> 

Reply via email to