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?