--- "Peter B. West" <[EMAIL PROTECTED]> wrote:
> Jeremias' ideas about factoring out useful
> stand-alone elements from the 
> combination of FOP and Batik are essential to the
> direction I am taking 
> with layout and rendering, aside from being a Good
> Thing in their own 
> right.  

Yes, I've pulled about 8 methods from the Renderer
interface so far, giving Renderer implementors a
little more freedom in how they choose to implement

Also, I removed direct
FOTreeBuilder.addElementMapping() methods which should
HEAD a little bit more FAD-friendly (FAD, of course,
doesn't have element mappings).  The external user
sets them in FOUserAgent instead, and HEAD's
FOTreeBuilder reads from the FOUserAgent object to
obtain them.  The FAD version of an FOTreeBuilder
would simply ignore this setting.

This doesn't mean I'm trying to move to FAD's pull
parsing--I'm not--but if I can increase the number of
components you can use, so much the better.  (To that
end, notice the one-line of code in
getDefaultHandler() in Driver that initializes
FOTreeBuilder.  If FAD's FOTreeBuilder equivalent can
work with these arguments--a render type, output
stream, FOUserAgent object--great!  That would mean
fop.apps package can be the same between two systems.)

In general, I'm trying to move away from supporting
direct manipulation of internal objects from external
users: e.g., AreaTree.setWidget(), etc. and instead am
placing the customization in FOUserAgent (or the xml
configuration file, perhaps) for the internal objects
to read.  That way if an alternative implementation
has nothing to do with widgets, it can simply ignore
the setting in FOUserAgent without being forced to
implement an architecture-breaking setWidget().  This
also gives future implementors ability to completely
revamp things internally without worrying about the


Reply via email to