--- Victor Mote <[EMAIL PROTECTED]> wrote:
> > So, are we back to square one with the pluggable
> > ElementMappers idea? Should we rip out that
> > functionality from FOTreeBuilder that allows FOP
> to
> > dynamically load brand-new ElementMappings? I
> still
> > don't see its utility.
>
> IMO,
Glen Mazza wrote:
> I'm confused about seeing Bookmarks referenced in
> FOTreeControl.java--I thought our pluggable
FOTreeControl is an abstraction of Document, and (by reference) of Driver so
that the FO Tree construction process can (eventually) be run by any object
that implements that interfa
We have currently about four sets of
ElementMappings--fo, svg, extension, and MathML in
examples.
I'm confused about seeing Bookmarks referenced in
FOTreeControl.java--I thought our pluggable
ElementMappings (including the Bookmark formatting
object) were designed to run with zero internal
hardc
For purposes of my FO Tree isolation work, I am including the "extensions"
package as part of the FO Tree. The BookmarkData class is going to move to
layoutmgr or area, and I haven't gotten all of the layout stuff out of the
other classes yet, but is there any objection to moving it to fo/extension
