Glen Mazza wrote:

> But, this is a two-vote procedure because something
> else has to be done first:
> 1.)  Discontinue the dynamic discovery and run-time
> adding capability of ElementMappings.  The code
> currently allows you to add user-created
> ElementMappings to the FOTreeBuilder at run-time
> without changes to the source code.  I think we can
> turn off this feature for two reasons:
> (a) It doesn't appear to work without source code
> changes anyway -- I was suspecting, and Peter had
> confirmed
> (,
> that dynamically adding mappings won't help unless the
> code understands the semantics of the new mappings,
> i.e., what the Area Tree needs to do with them.
> But users skilled and inclined enough to create
> user-defined ElementMappings can still do so by
> modifying the source code.

What about instream-foreign objects that get passed through? SVG is the only
one I know of, and it is hard-wired in already, but I'm not sure that this
capability should be lightly tossed. Please explain why this is a
prerequisite for the proposed move.

> (b) We're a bit overloaded already for 1.0 -- removing
> run-time ElementMapping configuration will allow us to
> keep focused on other areas.  ("Moving Part Reduction"
> design pattern, my favorite ;)

If it is gumming up the works, then OK. Otherwise, why remove it?

> Here's my +1.

I'll abstain pending further clarification.

> 2.)  Finally, move the code setting up the default
> element mappings from Driver class to FOTreeBuilder
> directly.  The Driver class will be
> ElementMapping-free.
> Here's my +1.

+1 (on part 2).

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to