W3C home > Mailing lists > Public > www-svg@w3.org > January 2008

Path length of a rounded rect in SVGT 1.2 conformance tests

From: Kalle Raita <kraita@nvidia.com>
Date: Tue, 8 Jan 2008 15:23:17 +0100
Message-ID: <85DD8D3F1695004A8A9A5AC16CE584BE048F548A@deemmail01.nvidia.com>
To: <www-svg@w3.org>
Hi,
 
It seems to me that the SVGT 1.2 beta conformance tests assume that for
a rounded rectangle path length compution starts from point (x+rx,y),
whereas the specification would indicate point (x,y+ry). In 
"9.2 The 'rect' element", the specification says:
A 'rect' <http://www.w3.org/TR/SVGMobile12/shapes.html#RectElement>
element, taking its rounded corners into account, must be rendered in a
way that produces the same result as if the following path
<http://www.w3.org/TR/SVGMobile12/paths.html>  were specified instead:
(Note: all coordinate and length values are first converted into user
space coordinates according to Units
<http://www.w3.org/TR/SVGMobile12/coords.html#Units> .)

*	perform an absolute moveto
<http://www.w3.org/TR/SVGMobile12/paths.html#PathDataMovetoCommands>
operation to location (x,y+ry), where x and y are the values of the 
'rect' <http://www.w3.org/TR/SVGMobile12/shapes.html#RectElement>
element's x
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElementXAttribute>
and y
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElementYAttribute>
attribute converted to user space, and rx and ry are the effective
values of the rx
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElementRXAttribute>
and ry
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElementRYAttribute>
attributes converted to user space
*	perform an absolute elliptical arc operation to coordinate
(x+rx,y), where the effective values for the rx
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElementRXAttribute>
and ry
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElementRYAttribute>
attributes on the 'rect'
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElement>  element
converted to user space are used as the rx and ry attributes on the
elliptical arc command, respectively, the x-axis-rotation is set to
zero, the large-arc-flag is set to zero, and the sweep-flag is set to
one
*	perform an absolute horizontal lineto
<http://www.w3.org/TR/SVGMobile12/paths.html#PathDataLinetoCommands>
operation to location (x+width-rx,y), where width is the 'rect'
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElement>  element's 
width
<http://www.w3.org/TR/SVGMobile12/shapes.html#RectElementWidthAttribute>
attribute converted to user space
*	...

As I interpret this, the path begins at point (x, y+ry). This is most
prominently visible in test case shapes-rect-03-t, where the line
(apprently) signifying the start of the path is after the first rounded
corner, not before.
 
I've included a SVG file that tries to demonstrate this. There are two
rounded rectangles. One on the left is constructed with separate paths
for each segment and they are made visible one-by-one. Rectangle on the
right is created with <rect> element and it has an animated
stroke-dasharray, which draws only the segment that appeared on the left
hand rectangle. In the first frame the on-dash is at the beginning of
the path. The subsequent frames the dash array begins with 0 on-dash and
increasingly long off-dash followed by on-dash that marks the current
segment.
 
This is relevant at least for test cases paint-stroke-202-t and
shapes-rect-03-t.
 
Any insights into this issue appreciated.
 
Thanks, 
  - Kalle Raita

Kalle Raita 
NVIDIA Corporation 
Tel. +358 40 723 1441 
kraita@nvidia.com 
http://eu.nvidia.com <http://eu.nvidia.com/>  

 

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------



Received on Tuesday, 8 January 2008 14:24:11 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:38 GMT