Re: future renderer design (was: Reverting changes in AFP Renderer)
On 27.02.2008 17:09:49 Adrian Cumiskey wrote: > Reply below.. > > Jeremias Maerki wrote: > > I'm not sure I follow you. Do you mean that you'd always maintain the > > transformation stack in the renderer? That's certainly something that > > needs to be done in a uniform way. > > Yes, a base renderer/painter could maintain both the transformation stack and > common palette state > features (paint color, brush thickness, font etc) as it traverses the block > levels within the area tree. > > > For PDF/PS/Java2D you'd still always > > apply any transformation to the output formats. For PCL (and probably > > AFP) you wouldn't do that (because you can't) but instead apply the > > current transformation to any coordinate that needs to be accessed in a > > uniform way. Is that it? If yes, you could simply pull up the > > graphicContext and graphicContextStack fields from PCLRenderer and > > establish that pattern for all subclasses. > > Could these coordinate transformations not be done by FOP as it is rendering > the output file rather > than delegating responsibility of performing these transformations to the > PDF/PS interpreter? Only to a certain extent. For painting text, you still have to write a text matrix (Tm) to the output format because otherwise, you'd have to paint the text using shapes which is not what we want. And for painting nested graphics you'd also have no other way than to establish new coordinate systems in the output format because you may not have full control over what plug-ins do in terms of painting code production (EPS, for example). At any rate, I'd find it unfortunate if we didn't make use of some of the basic features of such document formats. > With > this approach, the same rendering mechanism could be shared amongst > renderers, just the absolute > coordinates would be provided in the output file and not a series of matrices > with which to derive > the coordinates. This should result in printing/displaying being a little > faster as the output > format interpreter would be saved from having to do as many matrix > calculations at runtime, also the > resulting output file would be smaller for each document. Hope you follow my > thinking. I don't buy the "faster" and "smaller" argument. The "smaller" maybe to a very small extent. You'd still have to write many transformation matrices to the output format. And these will be more complex (and more difficult to debug) if they are always combined with all previous transformations. You'd only save a bit if you have many fixed positioned block-containers (break-out & restore). Concerning the performance aspect, the critical parts are the parsing of the intermediate format, handling nested graphics and font embedding, not the renderer itself. Whether you do the transformation inside FOP or in the output format I don't expect a significant change in performance. Or did you do some profiling that would lead you in this direction? Jeremias Maerki
Re: Reverting changes in AFP Renderer
Reply below.. Jeremias Maerki wrote: I'm not sure I follow you. Do you mean that you'd always maintain the transformation stack in the renderer? That's certainly something that needs to be done in a uniform way. Yes, a base renderer/painter could maintain both the transformation stack and common palette state features (paint color, brush thickness, font etc) as it traverses the block levels within the area tree. For PDF/PS/Java2D you'd still always apply any transformation to the output formats. For PCL (and probably AFP) you wouldn't do that (because you can't) but instead apply the current transformation to any coordinate that needs to be accessed in a uniform way. Is that it? If yes, you could simply pull up the graphicContext and graphicContextStack fields from PCLRenderer and establish that pattern for all subclasses. Could these coordinate transformations not be done by FOP as it is rendering the output file rather than delegating responsibility of performing these transformations to the PDF/PS interpreter? With this approach, the same rendering mechanism could be shared amongst renderers, just the absolute coordinates would be provided in the output file and not a series of matrices with which to derive the coordinates. This should result in printing/displaying being a little faster as the output format interpreter would be saved from having to do as many matrix calculations at runtime, also the resulting output file would be smaller for each document. Hope you follow my thinking. Adrian.
Re: Reverting changes in AFP Renderer
I'm not sure I follow you. Do you mean that you'd always maintain the transformation stack in the renderer? That's certainly something that needs to be done in a uniform way. For PDF/PS/Java2D you'd still always apply any transformation to the output formats. For PCL (and probably AFP) you wouldn't do that (because you can't) but instead apply the current transformation to any coordinate that needs to be accessed in a uniform way. Is that it? If yes, you could simply pull up the graphicContext and graphicContextStack fields from PCLRenderer and establish that pattern for all subclasses. On 26.02.2008 18:02:13 Adrian Cumiskey wrote: > Generally speaking (not just AFP), at the moment the > AbstractPathOrientedRenderer and its parents > dumbly pass coordinates down to their implementing renderer and rely upon the > implementing renderer > to workout the transformation using lots of pts2units()/mpts2units() method > calls. I think it would > be better if each implementing renderer/painter provides a base > AffineTransform to which a base > renderer/painter is able to transform coordinate values. The base class > could then maintain > rendering/painting state, pushing and popping on breakin/breakout as the area > tree is traversed, > passing on the correctly transformed coordinates (using the implementing > transformation matrix) to > the concrete implementations. > > Adrian. > > Jeremias Maerki wrote: > > The revision 603590 is now reverted and a couple of other changes > > applied: http://svn.apache.org/viewvc?rev=631178&view=rev > > > > On 26.02.2008 11:45:17 Adrian Cumiskey wrote: > >> Hi Jeremias, > >> > >> Yes I noticed this too in the AFP renderer and I am looking at trying to > >> reuse more of > >> AbstractPathOrientedRenderer and bring it more into line with the > >> state/breakout approach of the > >> PDF/PS renderers in the Temp_AFPAffineTransform branch. Also looking to > >> start using stateful > >> (depending on breakin/out) AffineTransform for all coordinate calculations > >> rather than using these > >> mpts2units() type methods everywhere. I'd be interested to hear your > >> thoughts on this. > > > > I don't know enough of AFP to say if a coordinate system stack is > > somehow supported. If it is, please try to make use of it especially if > > this gives you clipping functionality as a side-effect. Otherwise, please > > take a look at the PCLRenderer where I had to take a slightly different > > approach handling the coordinate system changes. I used AffineTransform > > heavily there and I think the AFP Renderer should do something similar. > > BTW, we should try to get away from using the CTM class as it's > > basically a clone of AffineTransform. I'm really not sure if coercing > > the AFPRenderer into the patterns of AbstractPathOrientedRenderer is > > such a good thing. Maybe AbstractPathOrientedRenderer has to be split up > > into two classes to avoid certain hacks in the concrete subclasses. > > > > How well we can avoid unit transformations is another question. The > > PDF/PS renderer uses points as basic length unit and the layout engine > > uses millipoints. The use of points and millipoints is mixed in many > > places which is not beautiful. I tried to harmonize the whole usage in > > the various renderers over time but I haven't taken any radical approach > > there, yet. > > > >> I think its important to try and bring all the renderers more closely into > >> line with each other > >> prior to to the new area tree design Painter implementation > >> (http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign). > > > > I'm not sure that is necessary, helpful or worth the effort. Relying on > > the old approach (which has organically grown too much over time) may > > not be the best idea, i.e. implementing the new IFRenderer based on > > AbstractPathOrientedRenderer. At any rate, it's going to be extremely > > important to design the details by taking all currently supported output > > formats into account. Especially PCL is going to be a PITA if we want to > > stick to PCL native commands rather than rendering whole pages as > > bitmaps like many Windows printer drivers do. > > > > HTH > > > >> Adrian. > >> > >> Jeremias Maerki wrote: > >>> Interesting. I just noticed that the break-out mechanism hasn't been > >>> implemented for the AFP renderer and therefore fixed positioned > >>> block-containers are not even supported in 0.94. Hmm. I guess I will > >>> skip that then. I'm only hacking together the same feature level as in > >>> 0.94 anyway. > >>> > >>> It turns out the AFP renderer has more in common with the PCL renderer > >>> (no nested coordinate system mechanism is used) than with PDF/PS/Java2D > >>> and still it's been derived from AbstractPathOrientedRenderer. I guess > >>> this should be improved when the GOCA stuff is working again. I just > >>> want the release done. > >>> > >>> On 26.02.2008 10:53:01 Jeremias Maerki wr
Re: Reverting changes in AFP Renderer
Generally speaking (not just AFP), at the moment the AbstractPathOrientedRenderer and its parents dumbly pass coordinates down to their implementing renderer and rely upon the implementing renderer to workout the transformation using lots of pts2units()/mpts2units() method calls. I think it would be better if each implementing renderer/painter provides a base AffineTransform to which a base renderer/painter is able to transform coordinate values. The base class could then maintain rendering/painting state, pushing and popping on breakin/breakout as the area tree is traversed, passing on the correctly transformed coordinates (using the implementing transformation matrix) to the concrete implementations. Adrian. Jeremias Maerki wrote: The revision 603590 is now reverted and a couple of other changes applied: http://svn.apache.org/viewvc?rev=631178&view=rev On 26.02.2008 11:45:17 Adrian Cumiskey wrote: Hi Jeremias, Yes I noticed this too in the AFP renderer and I am looking at trying to reuse more of AbstractPathOrientedRenderer and bring it more into line with the state/breakout approach of the PDF/PS renderers in the Temp_AFPAffineTransform branch. Also looking to start using stateful (depending on breakin/out) AffineTransform for all coordinate calculations rather than using these mpts2units() type methods everywhere. I'd be interested to hear your thoughts on this. I don't know enough of AFP to say if a coordinate system stack is somehow supported. If it is, please try to make use of it especially if this gives you clipping functionality as a side-effect. Otherwise, please take a look at the PCLRenderer where I had to take a slightly different approach handling the coordinate system changes. I used AffineTransform heavily there and I think the AFP Renderer should do something similar. BTW, we should try to get away from using the CTM class as it's basically a clone of AffineTransform. I'm really not sure if coercing the AFPRenderer into the patterns of AbstractPathOrientedRenderer is such a good thing. Maybe AbstractPathOrientedRenderer has to be split up into two classes to avoid certain hacks in the concrete subclasses. How well we can avoid unit transformations is another question. The PDF/PS renderer uses points as basic length unit and the layout engine uses millipoints. The use of points and millipoints is mixed in many places which is not beautiful. I tried to harmonize the whole usage in the various renderers over time but I haven't taken any radical approach there, yet. I think its important to try and bring all the renderers more closely into line with each other prior to to the new area tree design Painter implementation (http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign). I'm not sure that is necessary, helpful or worth the effort. Relying on the old approach (which has organically grown too much over time) may not be the best idea, i.e. implementing the new IFRenderer based on AbstractPathOrientedRenderer. At any rate, it's going to be extremely important to design the details by taking all currently supported output formats into account. Especially PCL is going to be a PITA if we want to stick to PCL native commands rather than rendering whole pages as bitmaps like many Windows printer drivers do. HTH Adrian. Jeremias Maerki wrote: Interesting. I just noticed that the break-out mechanism hasn't been implemented for the AFP renderer and therefore fixed positioned block-containers are not even supported in 0.94. Hmm. I guess I will skip that then. I'm only hacking together the same feature level as in 0.94 anyway. It turns out the AFP renderer has more in common with the PCL renderer (no nested coordinate system mechanism is used) than with PDF/PS/Java2D and still it's been derived from AbstractPathOrientedRenderer. I guess this should be improved when the GOCA stuff is working again. I just want the release done. On 26.02.2008 10:53:01 Jeremias Maerki wrote: Thanks for the hint. That worked indeed. I've almost finished by now. I only have to finish the adjustment for the changed CTM behaviour in BlockViewports. On 25.02.2008 14:27:27 Adrian Cumiskey wrote: Hi Jeremias, I started to do this but if you prefer then be all means go ahead and revert yourself. The approach I took was to take a trunk checkout and then apply svn merge -r603590:603589 . This should give you all the changes between commits (as 603589 works ok, but 603590 is broken) and this should affect only the files in the 603590 commit you should keep all the new stuff in trunk. Adrian. Jeremias Maerki wrote: FYI, I'm going to revert the AFP Renderer in Trunk to revision 601712 (the revision before 603590 (2007-12-12) which broke the AFP Renderer). Obviously, I'll have to reapply some of the changes that were done in the meantime (like the image integration or changes in AbstractPathOrientedRenderer). I'll do this so I can prepare the 0.95 release candidate
Re: Reverting changes in AFP Renderer
The revision 603590 is now reverted and a couple of other changes applied: http://svn.apache.org/viewvc?rev=631178&view=rev On 26.02.2008 11:45:17 Adrian Cumiskey wrote: > Hi Jeremias, > > Yes I noticed this too in the AFP renderer and I am looking at trying to > reuse more of > AbstractPathOrientedRenderer and bring it more into line with the > state/breakout approach of the > PDF/PS renderers in the Temp_AFPAffineTransform branch. Also looking to > start using stateful > (depending on breakin/out) AffineTransform for all coordinate calculations > rather than using these > mpts2units() type methods everywhere. I'd be interested to hear your > thoughts on this. I don't know enough of AFP to say if a coordinate system stack is somehow supported. If it is, please try to make use of it especially if this gives you clipping functionality as a side-effect. Otherwise, please take a look at the PCLRenderer where I had to take a slightly different approach handling the coordinate system changes. I used AffineTransform heavily there and I think the AFP Renderer should do something similar. BTW, we should try to get away from using the CTM class as it's basically a clone of AffineTransform. I'm really not sure if coercing the AFPRenderer into the patterns of AbstractPathOrientedRenderer is such a good thing. Maybe AbstractPathOrientedRenderer has to be split up into two classes to avoid certain hacks in the concrete subclasses. How well we can avoid unit transformations is another question. The PDF/PS renderer uses points as basic length unit and the layout engine uses millipoints. The use of points and millipoints is mixed in many places which is not beautiful. I tried to harmonize the whole usage in the various renderers over time but I haven't taken any radical approach there, yet. > I think its important to try and bring all the renderers more closely into > line with each other > prior to to the new area tree design Painter implementation > (http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign). I'm not sure that is necessary, helpful or worth the effort. Relying on the old approach (which has organically grown too much over time) may not be the best idea, i.e. implementing the new IFRenderer based on AbstractPathOrientedRenderer. At any rate, it's going to be extremely important to design the details by taking all currently supported output formats into account. Especially PCL is going to be a PITA if we want to stick to PCL native commands rather than rendering whole pages as bitmaps like many Windows printer drivers do. HTH > Adrian. > > Jeremias Maerki wrote: > > Interesting. I just noticed that the break-out mechanism hasn't been > > implemented for the AFP renderer and therefore fixed positioned > > block-containers are not even supported in 0.94. Hmm. I guess I will > > skip that then. I'm only hacking together the same feature level as in > > 0.94 anyway. > > > > It turns out the AFP renderer has more in common with the PCL renderer > > (no nested coordinate system mechanism is used) than with PDF/PS/Java2D > > and still it's been derived from AbstractPathOrientedRenderer. I guess > > this should be improved when the GOCA stuff is working again. I just > > want the release done. > > > > On 26.02.2008 10:53:01 Jeremias Maerki wrote: > >> Thanks for the hint. That worked indeed. I've almost finished by now. I > >> only have to finish the adjustment for the changed CTM behaviour in > >> BlockViewports. > >> > >> On 25.02.2008 14:27:27 Adrian Cumiskey wrote: > >>> Hi Jeremias, > >>> > >>> I started to do this but if you prefer then be all means go ahead and > >>> revert yourself. The approach > >>> I took was to take a trunk checkout and then apply > >>> > >>> svn merge -r603590:603589 . > >>> > >>> This should give you all the changes between commits (as 603589 works ok, > >>> but 603590 is broken) and > >>> this should affect only the files in the 603590 commit you should keep > >>> all the new stuff in trunk. > >>> > >>> Adrian. > >>> > >>> Jeremias Maerki wrote: > FYI, I'm going to revert the AFP Renderer in Trunk to revision 601712 > (the revision before 603590 (2007-12-12) which broke the AFP Renderer). > Obviously, I'll have to reapply some of the changes that were done > in the meantime (like the image integration or changes in > AbstractPathOrientedRenderer). I'll do this so I can prepare the 0.95 > release candidate later this week without a broken AFP renderer. > > Adrian, please continue working on the branch you've created. We can > merge it back into Trunk when you've fixed the AFP Renderer with the > GOCA addition. > > Jeremias Maerki > > > >> > >> > >> > >> Jeremias Maerki > >> > > > > > > > > > > Jeremias Maerki > > > > Jeremias Maerki
Re: Reverting changes in AFP Renderer
Hi Jeremias, Yes I noticed this too in the AFP renderer and I am looking at trying to reuse more of AbstractPathOrientedRenderer and bring it more into line with the state/breakout approach of the PDF/PS renderers in the Temp_AFPAffineTransform branch. Also looking to start using stateful (depending on breakin/out) AffineTransform for all coordinate calculations rather than using these mpts2units() type methods everywhere. I'd be interested to hear your thoughts on this. I think its important to try and bring all the renderers more closely into line with each other prior to to the new area tree design Painter implementation (http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign). Adrian. Jeremias Maerki wrote: Interesting. I just noticed that the break-out mechanism hasn't been implemented for the AFP renderer and therefore fixed positioned block-containers are not even supported in 0.94. Hmm. I guess I will skip that then. I'm only hacking together the same feature level as in 0.94 anyway. It turns out the AFP renderer has more in common with the PCL renderer (no nested coordinate system mechanism is used) than with PDF/PS/Java2D and still it's been derived from AbstractPathOrientedRenderer. I guess this should be improved when the GOCA stuff is working again. I just want the release done. On 26.02.2008 10:53:01 Jeremias Maerki wrote: Thanks for the hint. That worked indeed. I've almost finished by now. I only have to finish the adjustment for the changed CTM behaviour in BlockViewports. On 25.02.2008 14:27:27 Adrian Cumiskey wrote: Hi Jeremias, I started to do this but if you prefer then be all means go ahead and revert yourself. The approach I took was to take a trunk checkout and then apply svn merge -r603590:603589 . This should give you all the changes between commits (as 603589 works ok, but 603590 is broken) and this should affect only the files in the 603590 commit you should keep all the new stuff in trunk. Adrian. Jeremias Maerki wrote: FYI, I'm going to revert the AFP Renderer in Trunk to revision 601712 (the revision before 603590 (2007-12-12) which broke the AFP Renderer). Obviously, I'll have to reapply some of the changes that were done in the meantime (like the image integration or changes in AbstractPathOrientedRenderer). I'll do this so I can prepare the 0.95 release candidate later this week without a broken AFP renderer. Adrian, please continue working on the branch you've created. We can merge it back into Trunk when you've fixed the AFP Renderer with the GOCA addition. Jeremias Maerki Jeremias Maerki Jeremias Maerki
Re: Reverting changes in AFP Renderer
Interesting. I just noticed that the break-out mechanism hasn't been implemented for the AFP renderer and therefore fixed positioned block-containers are not even supported in 0.94. Hmm. I guess I will skip that then. I'm only hacking together the same feature level as in 0.94 anyway. It turns out the AFP renderer has more in common with the PCL renderer (no nested coordinate system mechanism is used) than with PDF/PS/Java2D and still it's been derived from AbstractPathOrientedRenderer. I guess this should be improved when the GOCA stuff is working again. I just want the release done. On 26.02.2008 10:53:01 Jeremias Maerki wrote: > Thanks for the hint. That worked indeed. I've almost finished by now. I > only have to finish the adjustment for the changed CTM behaviour in > BlockViewports. > > On 25.02.2008 14:27:27 Adrian Cumiskey wrote: > > Hi Jeremias, > > > > I started to do this but if you prefer then be all means go ahead and > > revert yourself. The approach > > I took was to take a trunk checkout and then apply > > > > svn merge -r603590:603589 . > > > > This should give you all the changes between commits (as 603589 works ok, > > but 603590 is broken) and > > this should affect only the files in the 603590 commit you should keep all > > the new stuff in trunk. > > > > Adrian. > > > > Jeremias Maerki wrote: > > > FYI, I'm going to revert the AFP Renderer in Trunk to revision 601712 > > > (the revision before 603590 (2007-12-12) which broke the AFP Renderer). > > > Obviously, I'll have to reapply some of the changes that were done > > > in the meantime (like the image integration or changes in > > > AbstractPathOrientedRenderer). I'll do this so I can prepare the 0.95 > > > release candidate later this week without a broken AFP renderer. > > > > > > Adrian, please continue working on the branch you've created. We can > > > merge it back into Trunk when you've fixed the AFP Renderer with the > > > GOCA addition. > > > > > > Jeremias Maerki > > > > > > > > > > > Jeremias Maerki > Jeremias Maerki
Re: Reverting changes in AFP Renderer
Thanks for the hint. That worked indeed. I've almost finished by now. I only have to finish the adjustment for the changed CTM behaviour in BlockViewports. On 25.02.2008 14:27:27 Adrian Cumiskey wrote: > Hi Jeremias, > > I started to do this but if you prefer then be all means go ahead and revert > yourself. The approach > I took was to take a trunk checkout and then apply > > svn merge -r603590:603589 . > > This should give you all the changes between commits (as 603589 works ok, but > 603590 is broken) and > this should affect only the files in the 603590 commit you should keep all > the new stuff in trunk. > > Adrian. > > Jeremias Maerki wrote: > > FYI, I'm going to revert the AFP Renderer in Trunk to revision 601712 > > (the revision before 603590 (2007-12-12) which broke the AFP Renderer). > > Obviously, I'll have to reapply some of the changes that were done > > in the meantime (like the image integration or changes in > > AbstractPathOrientedRenderer). I'll do this so I can prepare the 0.95 > > release candidate later this week without a broken AFP renderer. > > > > Adrian, please continue working on the branch you've created. We can > > merge it back into Trunk when you've fixed the AFP Renderer with the > > GOCA addition. > > > > Jeremias Maerki > > > > Jeremias Maerki
Re: Reverting changes in AFP Renderer
Hi Jeremias, I started to do this but if you prefer then be all means go ahead and revert yourself. The approach I took was to take a trunk checkout and then apply svn merge -r603590:603589 . This should give you all the changes between commits (as 603589 works ok, but 603590 is broken) and this should affect only the files in the 603590 commit you should keep all the new stuff in trunk. Adrian. Jeremias Maerki wrote: FYI, I'm going to revert the AFP Renderer in Trunk to revision 601712 (the revision before 603590 (2007-12-12) which broke the AFP Renderer). Obviously, I'll have to reapply some of the changes that were done in the meantime (like the image integration or changes in AbstractPathOrientedRenderer). I'll do this so I can prepare the 0.95 release candidate later this week without a broken AFP renderer. Adrian, please continue working on the branch you've created. We can merge it back into Trunk when you've fixed the AFP Renderer with the GOCA addition. Jeremias Maerki
Reverting changes in AFP Renderer
FYI, I'm going to revert the AFP Renderer in Trunk to revision 601712 (the revision before 603590 (2007-12-12) which broke the AFP Renderer). Obviously, I'll have to reapply some of the changes that were done in the meantime (like the image integration or changes in AbstractPathOrientedRenderer). I'll do this so I can prepare the 0.95 release candidate later this week without a broken AFP renderer. Adrian, please continue working on the branch you've created. We can merge it back into Trunk when you've fixed the AFP Renderer with the GOCA addition. Jeremias Maerki