You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2008/07/07 15:39:26 UTC
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
What for? Just curious.
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)
>
> Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
> URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java?rev=674484&view=auto
> ==============================================================================
> --- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java (added)
> +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java Mon Jul 7 06:28:26 2008
<snip/>
Jeremias Maerki
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
Posted by Adrian Cumiskey <ad...@gmail.com>.
Hi Jeremias,
You'll see in a moments time when the recent svn commit on XMLRenderer arrives... :).
Just thought I would put these small changes planned in the Temp_AreaTreeNewDesign into trunk as
they do no harm and may actually be useful for someone else who may wish to write their own custom
XML based Renderer.
Adrian.
Jeremias Maerki wrote:
> What for? Just curious.
>
> 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)
>>
>> Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
>> URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java?rev=674484&view=auto
>> ==============================================================================
>> --- xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java (added)
>> +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java Mon Jul 7 06:28:26 2008
> <snip/>
>
>
>
> Jeremias Maerki
>
>
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 11.07.2008 22:31:03 Andreas Delmelle wrote:
> On Jul 11, 2008, at 10:55, Jeremias Maerki wrote:
>
> > ... So the IFRenderer actually doesn't generate any XML itself.
> > That will be the job of the
> > IFSerializer. So IFRenderer will not subclass AbstractXMLRenderer.
>
> Apart from that, I also completely forgot about the SVGRenderer
> (currently still in the sandbox).
> Not sure, but that one could be considered an AbstractXMLRenderer as
> well.
Actually, I'm planning to write an SVGPainter as one of the first
formats for the new intermediate format. Adrian proposed to use SVG for
the intermediate format itself. I fear it would be too slow and too
complicated to do. But I think it's worthwhile to set those two beside
each other to see if my assumption is correct and if my highly optimized
(and proprietary) approach is really worth it. So if it isn't it will be
easy to switch over and as a nice side-benefit (if nothing else) we get
SVG output support.
That means I'm actually abandoning the idea of having an SVGRenderer at
all, especially since the SVGPainter will be easier to implement than
an SVGRenderer.
> And yes, I agree that it's not really a bad thing to have lots of
> abstractions, as long as they're actually useful.
> If you have only one class that extends it, and there's no immediate
> benefit, it's worth to stop and think for a second...
+1 to that.
> Considering the above: even if not useful for the new IF, there does
> seem to be potential benefit for rendering to XML formats.
>
>
> Cheers
>
> Andreas
BTW, I've started working on the new IF yesterday. I've changed the
IFRenderer to subclass AbstractPathOrientedRenderer in the hopes that
this will work out. I'll start with the IFSerializer (implements
IFPainter, writes the actual IF) and with the SVGPainter.
Jeremias Maerki
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
Posted by Andreas Delmelle <an...@telenet.be>.
On Jul 11, 2008, at 10:55, Jeremias Maerki wrote:
> ... So the IFRenderer actually doesn't generate any XML itself.
> That will be the job of the
> IFSerializer. So IFRenderer will not subclass AbstractXMLRenderer.
Apart from that, I also completely forgot about the SVGRenderer
(currently still in the sandbox).
Not sure, but that one could be considered an AbstractXMLRenderer as
well.
And yes, I agree that it's not really a bad thing to have lots of
abstractions, as long as they're actually useful.
If you have only one class that extends it, and there's no immediate
benefit, it's worth to stop and think for a second...
Considering the above: even if not useful for the new IF, there does
seem to be potential benefit for rendering to XML formats.
Cheers
Andreas
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
Posted by Adrian Cumiskey <ad...@gmail.com>.
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
>
>
Re: svn commit: r674484 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/xml/AbstractXMLRenderer.java
Posted by Andreas Delmelle <an...@telenet.be>.
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