lewisje / svgweb

Automatically exported from code.google.com/p/svgweb
Other
0 stars 0 forks source link

clip-path not used when part of style attribute value #514

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create a clip-path element with id "clipPath1" and child path or rect 
element defining the clip area.
2. Create a rect that has the style attribute value of 
"clip-path:url(#clipPath1);" and that overlaps the clip area.

What is the expected output? What do you see instead?
The rect should use the clip path, however it does not, due to it being 
specified in the style attribute as opposed being specified as its own 
attribute.

What version of the product are you using? On what operating system,
browser, and version of Flash?
Windows, IE8, Flash 10.1

Please provide any additional information below. Reduced test cases are
always appreciated!
Opera indicates it allows clip-path as part of the style attribute:
http://www.opera.com/docs/specs/presto25/svg/cssproperties/
Batik lists clip-path as one of the CSS stylable attributes in the 
org.apache.batik.svggen.SVGStylingAttributes class.  Chrome's native renderer 
allows it, as does FireFox.  I couldnt find an official list of the properties 
which can be placed into the style attribute in the SVG specification.  Perhaps 
I missed it.

The only real change needed for this issue was changing getAttribute in 
SVGNode.applyClipPathMask to getStyleOrAttr for clip-path.  However, I found 
that there were several additional references to clip-path as an attribute in 
the createSVGSprites function.  This function is only ever called from the XML 
setter.  Odd thing about that setter is that it explicitly checks for a 
non-null xml variable before calling parseStyle, however, the createSVGSprites 
function before the check and updateClones after the check both dereference 
xml.  This leads me to believe that xml can never be null.  Therefore, the 
setter can be restructured such that parseStyle can happen before the 
createSVGSprites call.  By doing so, we can use getStyleOrAttr in 
createSVGSprites when looking for clip-path.  While in there I thought it would 
be consistent to use getAttribute for the other, non style attributes that are 
being retrieved.  The function createSVGSprites was unfamiliar to me, so more 
experienced eyes should really give it a look, as well as the xml setter, 
though I believe I've left that functionally equivalent to before my changes.

Attached is a sample SVG showing the problem, clipPathStyleAttribute.svg.  I 
have also attached images showing before and after the fix.  The fix itself has 
been attached as a svn diff, clipPathStyleAttribute-fix.diff.

Original issue reported on code.google.com by bduncan%...@gtempaccount.com on 14 Jun 2010 at 9:08

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Upon further testing of this, my changes in the diff file have exposed a 
problem combining animation on shapes that use a clip-path.  I will submit an 
example of the problem later.  I would like to resolve that problem as part of 
this issue or at least in conjunction with the changes to this issue so as not 
to break things while fixing something :)

Original comment by bduncan%...@gtempaccount.com on 15 Jun 2010 at 1:39

GoogleCodeExporter commented 8 years ago
I've redone my patch.  This includes fixes for both Issue 526 and Issue 321.  
The paragraph in the previous comment describing my process for producing this 
patch still holds true.  I'm attaching a version of my test case from Issue 
526.  See it for a description of how it works.  The difference with this 
version is that the clip path is kept in the style instead of as an attribute.  
It functions in the same way, and looks identical to the one in Issue 526 once 
this new patch is applied.

Original comment by bduncan%...@gtempaccount.com on 29 Jun 2010 at 6:57

Attachments:

GoogleCodeExporter commented 8 years ago
Fixed in r1209.
Thanks for the patch!

Original comment by grick23@gmail.com on 3 Aug 2010 at 2:57