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

Reply via email to