--- Victor Mote <[EMAIL PROTECTED]> wrote: > AreaTree > is not > renderer-specific, but RenderContext specific. So, > for example, the same > AreaTree can be used to generate PostScript and PDF > output.
Are you sure? Please read http://marc.theaimsgroup.com/?l=fop-dev&m=105455951226310&w=2 (Peter, Jeremias' writing)--they appear to indicate that the area tree is dependent upon the specific renderer being used, because of the fonts. > Also, while currently it is true that the AreaTree > creation is somewhat > bound to the FOTree creation, that is one of the > things that I think we are > trying to change (I am anyway). currently it's: FOP -----> Driver -------> FOTreeBuilder | | | | | | \/ | Structure Handler <--- As in (1) FOP class determines if the render_type requires an area tree. (2) Driver activates the FOTreeBuilder. (3) Based on the render_type, Driver determines the type of StructureHandler (AreaTree) that FOTreeBuilder should send SAXEvents to, and gives it to FOTreeBuilder. (4) FOTreeBuilder sends SAX events to the StructureHandler that was given to it by Driver. I wanted to move to: (1) Doc/Dri API/Apps --------> FOTreeBuilder ------> its Area Tree > The only reason that > I know of for the > processing to be the way it is now is to facilitate > eager processing. > If we > return control of that up to these Control/API > classes, we get a clean > separation of these tasks, add the option for > patient processing as well, > and add the possibility of pluggable layout. > > Victor Mote > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, email: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
