You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thierry Kormann <Th...@sophia.inria.fr> on 2000/11/10 16:19:41 UTC

[commit] bug with clip-path on clipPath element

Hi,

At last, I have fixed the clip-path on clipPath.
A complete complex but not fully complete test is clip.svg

CVS: Modified Files:
CVS: 	sources/org/apache/batik/refimpl/bridge/SVGClipPathElementBridge.java 


Thierry.

-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis






Re: [commit] bug with clip-path on clipPath element

Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <Th...@sophia.inria.fr> writes:

>> I've implemented anti-aliased clip-path in AbstractGraphicsNode
>> (makes the ovals look much nicer).  The only problem is that it
>> requires the creation of a ConcreteClipRable, at render time.
>> Right now I have inlined it but I see two ways to do it
>> "correctly".

TK> Excellent. You have committed ?

    No.  I pulled your updated stuff and I was looking at the clip
test (which is nicely anti-aliaed).  However 3_1 & 3_2 look the same
as 2_*.  Which I think is wrong, 3_3 looks correct to me.

    Can you comment on this?  Does my stuff break something (although
I have a hard time understanding how...).

>> 2) Make GraphicsNode always use a ClipRable (constructed and set by
>> the brige)

TK> I also prefer #2. If I understand correctly, the idea is to always
TK> create the ClipRable in the bridge. Then depending on
TK> RenderingHints, we use the ClipRable or we can extract the Space
TK> from the ClipRable and use g2d.clip.

TK> Am I right ? If yes, it sounds really good to me.

    Yes, you are correct. I'll continue down that road.

[commit] bug with clip-path on clipPath element

Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <Th...@sophia.inria.fr> writes:

TK> At last, I have fixed the clip-path on clipPath.  A complete
TK> complex but not fully complete test is clip.svg

    I've implemented anti-aliased clip-path in AbstractGraphicsNode
(makes the ovals look much nicer).  The only problem is that it
requires the creation of a ConcreteClipRable, at render time.  Right
now I have inlined it but I see two ways to do it "correctly".

1) Add a getClipFactory to GraphicsNodeRenderContext then it can use
   that instead of hard coding refimpl.gvt.filter.ConcreateClipRable,
   when it decides to use the anti-aliased clipping path.

2) Make GraphicsNode always use a ClipRable (constructed and set by
   the brige), when it is not using anti-aliased clip-paths (controled
   by render hints) it requests the clip-path the ClipRable would be
   using and then sets it as the g2d clip.  When it is using
   anti-aliased clipping it make sure the source of the ClipRable is
   set properly, and pulls data through it.

   My leaning is towards #2... Opinions?