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