Re: Rendering and Pointer-Events (ACTION-2372, ACTION-2358)

Hi Doug,


> In preparing the SVG 1.1 2nd edition spec, we had an outstanding issue
> regarding clip-paths and pointer events.
[...]
> We hope this satisfies people who had concerns and questions on the matter.
>  We recognize that some may disagree with this conclusion, and that this
> means some implementations will have to change to conform to the clarified
> spec, which we regret.

It's great to see this revisited and clarified IMHO. :-)


I'm currently trying to make sense of this (mostly in the scope of
Apache Batik, at the moment). I've seen in the current implementation
report [1] that there seem to be two applicable tests in the suite:
interact-pointer-02-t [2] and interact-pointer-03-t [3].


The first [2] still fails, even after applying the current relevant
patch [4]. After crawling a bit on why, I believe I may have bumped
into a test case issue. The current markup is:

<clipPath id='c' clipPathUnits='userSpaceOnUse' x='10' y='80'
width='50' height='50'/>

It contains x, y, width and height properties as if there was a child
rectangle defined. Unless I'm missing something (I found nothing in
the clipPath definition [5] regarding that possibility), what seems to
be an invalid clipPath is probably causing other implementations to
"pass" as they are probably ignoring that and applying the wording:

«An empty clipping path will completely clip away the element that had
the ‘clip-path’ property applied.» [5]

As a side note, this seems to have triggered a bug in Batik, which
isn't fulfilling the above requirement (expensive wording for "bug").
Just for curiosity, with a locally patched install, together with a
modified test case (containing an empty rectangle in order to simulate
the empty clipPath), it now passes:

<clipPath id='c' clipPathUnits='userSpaceOnUse'>
  <rect x='0' y='0' width='0' height='0'/>
</clipPath>


The second [3] currently is failing because Batik Squiggle complains
about a broken reference to a clip path ("#c"). This seems to be a
test case issue and, after fixing it locally, it passes the test. Was
the broken reference meant to be (i.e., am I missing something)? I did
notice that Batik should be ignoring the broken reference - at least,
according to the wording in the clip-path property [5]:

«If the URI reference is not valid (e.g it points to an object that
doesn't exist or the object is not a ‘clipPath’ element) the
‘clip-path’ property must be treated as if it hadn't been specified.»
[6]

But, in the end, it didn't seem like a broken URI was required for the test. :-)


Cheers,
 Helder


[1] http://dev.w3.org/SVG/profiles/1.1F2/errata/implementation-report.html
[2] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/interact-pointer-02-t.svg
[3] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/interact-pointer-03-t.svg
[4] https://issues.apache.org/bugzilla/show_bug.cgi?id=46289
[5] http://dev.w3.org/SVG/profiles/1.1F2/publish/masking.html#ClipPathElement
[6] http://dev.w3.org/SVG/profiles/1.1F2/publish/masking.html#ClipPathProperty

Received on Sunday, 31 January 2010 19:28:41 UTC