--- Glen Mazza <[EMAIL PROTECTED]> wrote:

> --- Finn Bock <[EMAIL PROTECTED]> wrote:
> 
> > [Glen]
> > 
> > > 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)?
> > 
> > That would make the life of extension writers
> > harder. Thus I would 
> > prefer that TreeExt stay.
> > 

Actually, to clarify what I wrote: why do we need an
extension interface (TreeExt) for objects placed
outside the document (pdf bookmarks/metadata), while
*not* needing one for extension objects that end up
placed *on* the document?  For the latter types, area
creation is hardcoded within our layout managers (to
be replaced by extension writers when they have new
FO's), so I don't logically see why we can't do the
same with the former types.

In other words, extension writers may very well create
extension FO's that create areas *on* the document. 
Here, TreeExt won't help them--so I'm not really sure
if it is actually buying us anything.

Glen

Reply via email to