Hi Thomas,

I see the problem now and I think I found a fix:
http://svn.apache.org/viewcvs?rev=326600&view=rev

The Graphics.create() methods were simply not implemented properly. I've
added what I thought would be necessary but I'm not sure if I got
everything right, yet. I have yet to check an SVG with clipping inside
an FO document. So far I've only tested SVG with the PDFTranscoder.

In addition to that there was a problem with state tracking which I
solved using the new PDFContext class.

Feedback welcome.

On 18.10.2005 22:58:59 thomas.deweese wrote:
> Hi Jeremias,
> 
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 10/18/2005 04:51:00 PM:
> 
> > I recently cleaned up the PDF and PS transcoders so they behave much
> > more similarly. I may have broken clipping then, although I have done
> > quite extensive tests. 
> 
>    The problem isn't really with clipping, it's with the 'create'
> method of the Graphics interface.  I was pushed to use 'create'
> to deal with some clipping issues.
> 
> > Unfortunately, I can't quite follow your problem description. Would you
> > please post an example or describe how I can reproduce the
> > problem? I can then have a look at it. Thanks.
> 
>    I suspect that attempting to render any SVG to PDF with
> trunk Batik will cause the problem (the root SVG element
> almost always has an associated clip - which causes the
> use of create).  I was specifically using the test file:
>         samples/tests/spec/paints/linearGradientOrientation.svg
> 
>    from the Batik source tree (I was going to work on fixing
> PDF Gradients when I noticed the problem).
> 
> > On 18.10.2005 19:28:24 thomas.deweese wrote:
> > > Hi all,
> > > 
> > >    I don't know if you want to deal with this here in FOP land or over 
> in 
> > > Batik land but since the
> > > code in question is currently in FOP I thought I would start here. The 
> 
> > > PDF transcoder is
> > > currently broken.  This appears to be due to a recent change to the 
> way 
> > > clips are done.
> > > Previously a new clip was done something like:
> > > 
> > >         Shape oldClip = g2d.getClip();  // get clip, in the current 
> > > coordinate system
> > >         g2d.clip(newAdditiveClip);
> > > 
> > >         // Draw things, blah blah
> > > 
> > >         g2d.setClip(oldClip);  // restore clip, in current coordinate 
> > > system.
> > > 
> > > ----
> > >         This as it turns out has problems, the basic issue is that the 
> 
> > > clip can
> > > 'waver' as it is gotten and restored in various coordinate systems 
> (shift 
> > > one pixel left or 
> > > right).   To avoid  the need to get and restore the clip I started 
> using 
> > > the 'create' 
> > > method of the Graphics.  So the new code looks something like:
> > > 
> > >         g2d = g2d.create();                  // create new graphics 
> with 
> > > independent drawing state
> > >         g2d.clip(newAdditiveClip);
> > > 
> > >         // Draw things, blah blah
> > > 
> > >         g2d.dispose();  // parent node will use 'old' graphics 2D.
> > > 
> > > ----
> > > 
> > >         The real code is a bit more complex than this but you get the
> > > idea.  The problem is that the PDFGraphics2D doesn't seem to properly
> > > implement 'create()'.  I've tried to hack this in but I get garbage 
> PDF 
> > > out.
> > > 
> > >         So what I'm looking for is a basic analysis of how hard this 
> would
> > > be to fix, as well as suggestions on how to fix it.  There are some 
> other
> > > potential solutions to the wavering clip issue, although I think the 
> above 
> > > is
> > > by far the cleanest (and hence most desirable) of them.
> > 
> > 
> > 
> > Jeremias Maerki
> > 



Jeremias Maerki

Reply via email to