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 th...@kodak.com on 2005/10/18 19:28:24 UTC
SVG PDFTranscoder broken...
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.
Re: SVG PDFTranscoder broken...
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks, I'll look into it tomorrow and will get back to you when I have
a good idea what's happening.
On 18.10.2005 22:58:59 thomas.deweese wrote:
> Hi Jeremias,
>
> Jeremias Maerki <de...@jeremias-maerki.ch> 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
Re: SVG PDFTranscoder broken...
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 20.10.2005 13:38:00 thomas.deweese wrote:
> Hi Jeremias,
>
> Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 10/19/2005 12:37:56 PM:
>
> > 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.
>
> Right, thanks for fixing it for me. It looks like even with some
> of the more complex clipping cases everything is right. Back to
> trying to figure out what's wrong with gradients... ;)
>
> On this point any objection if I have it fall back to rasterizing
> in some cases that I don't think can be represented in PDF (mostly
> the complex repeat modes)?
Not at all. Actually, I would be quite happy about it especially if the
EPS renderer would profit from that indirectly (since it doesn't do
gradients at all ATM).
Jeremias Maerki
Re: SVG PDFTranscoder broken...
Posted by th...@kodak.com.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> wrote on 10/19/2005 12:37:56 PM:
> 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.
Right, thanks for fixing it for me. It looks like even with some
of the more complex clipping cases everything is right. Back to
trying to figure out what's wrong with gradients... ;)
On this point any objection if I have it fall back to rasterizing
in some cases that I don't think can be represented in PDF (mostly
the complex repeat modes)?
Re: SVG PDFTranscoder broken...
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <de...@jeremias-maerki.ch> 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
Re: SVG PDFTranscoder broken...
Posted by th...@kodak.com.
Hi Jeremias,
Jeremias Maerki <de...@jeremias-maerki.ch> 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
>
Re: SVG PDFTranscoder broken...
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hi Thomas,
as long as the code is still here we probably have to deal with it here.
Migrating this stuff is pretty high on my list as soon we have the
preview release out which should happen real soon now.
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. But then, we probably have to set up the same
kind of testing infrastructure we already have for FO.
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.
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