Adrian,

thanks for uploading your changes to the Temp_AreaTreeRedesign branch.
I made a mistake which sent you off in the wrong direction. The text was
describing a different design than was shown in the graphic [1]. I've
now updated the graphic. The clue here is to avoid going through the SAX
ContentHandler when painting without serialization to the intermediate
format. That would have caused a performance penalty. So the IFRenderer
actually doesn't generate any XML itself. That will be the job of the
IFSerializer. So IFRenderer will not subclass AbstractXMLRenderer. Sorry
for the confusion.

[1] http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign

On 08.07.2008 11:25:31 Adrian Cumiskey wrote:
> As it is, I have a class in the Temp_AreaTreeRedesign branch that extends 
> AbstractXMLRenderer.  I 
> thought it useful to provide the class in trunk for anyone else who may wish 
> to create their own XML 
> based renderer for whatever purposes.
> 
> However, IMO you can never have enough abstract classes, helps to hide/break 
> up some of the 
> complexity and remove some unnecessary code dependencies and give yourself 
> options to extend the class.
> 
> Adrian.
> 
> Andreas Delmelle wrote:
> > On Jul 7, 2008, at 15:39, Jeremias Maerki wrote:
> > 
> >>> On 07.07.2008 15:28:26 acumiskey wrote:
> >>>> Author: acumiskey
> >>>> Date: Mon Jul  7 06:28:26 2008
> >>>> New Revision: 674484
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?rev=674484&view=rev
> >>>> Log:
> >>>> Added new AbstractXMLRenderer base class.
> >>>>
> >>>> Added:
> >>>>     
> >>>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
> >>>>    
> >>>> (with props)
> >>>>
> > 
> >> What for? Just curious.
> > 
> > Me too... Just abstracting to abstract seems to make little sense. :-/
> > 
> > 
> > Cheers
> > 
> > Andreas
> > 
> > 




Jeremias Maerki

Reply via email to