Hi Cameron and Thomas,
I have a question on stroke-dashing. The W3C-SVG Working group has
recently discussed the topic of stroke-dashing on basic shapes and path
elements. It is clear that stroke-dashing is underspecified when it
comes to the origin and direction of stroke-dashing in basic shapes and
path segments. This already led to different implementation results when
it comes to stroke-dashing. The effect is esp. apparent when one uses
long dashes. Another problem is with path elements. Some implementations
restart the stroking for each path segment, using the stroke-dashoffset
value (f.e. Batik, Opera), some continue using the remaining offset from
the last path segment (f.e. Mozilla SVG). Probably most implementations
just pass the rendering to the underlying rendering library and just do
what their rendering library does.
The WG now wants to fix these interoperability problems but wants to
contact the implementors what they think about this problem. Is this a
problem for you to fix if the WG decides to exactly specify the
behaviour of stroke-dashing, esp. if it might differ from what your
implementation does currently? If you can fix it, would this mean a
performance loss? It would probably mean that you have to render basic
shapes as path elements when it comes to stroke-dashing and have to
split up pathes with several segments into individual pathes.
Here are two test cases illustrating the interoperability problems:
http://www.carto.net/neumann/temp/dasharrayOrigin.svg
http://www.carto.net/neumann/temp/dasharrayOrigin.png (screenshot with
different rendering results)
http://www.carto.net/neumann/temp/stroke-dash_problem.svg
http://www.carto.net/neumann/temp/screenshot_path_stroke-dash.png
(screenshot, note the difference how Mozilla does it vs. Batik/Opera)
--------
This is the new wording for stroking the basic shapes:
Rect:
A 'rect' element, taking its rounded corners into account, must be
rendered in a way that produces the same result as if the following path
were specified instead: (Note: all coordinate and length values are
first converted into user space coordinates according to Units.)
perform an absolute moveto operation to location (x+rx,y), where x is
the value of the 'rect' element's x attribute converted to user space,
rx is the effective value of the rx attribute converted to user space
and y is the value of the y attribute converted to user space
perform an absolute horizontal lineto operation to location
(x+width-rx,y), where width is the 'rect' element's width attribute
converted to user space
perform an absolute elliptical arc operation to coordinate
(x+width,y+ry), where the effective values for the rx and ry attributes
on the 'rect' 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 a absolute vertical lineto to location (x+width,y+height-ry),
where height is the 'rect' element's height attribute converted to user
space
perform an absolute elliptical arc operation to coordinate
(x+width-rx,y+height)
perform an absolute horizontal lineto to location (x+rx,y+height)
perform an absolute elliptical arc operation to coordinate (x,y+height-ry)
perform an absolute absolute vertical lineto to location (x,y+ry)
perform an absolute elliptical arc operation to coordinate (x+rx,y)
--
Circle:
Within the current user coordinate system, stroking operations on a
circle begin at the point (cx+r,cy) and then proceed through the points
(cx,cy+r), (cx-r,cy), (cx,cy-r) and finally back to (cx+r,cy). For
stroking operations, there is only one line segment which has its
beginning joined to its end.
--
Ellipse:
Within the current user coordinate system, stroking operations on a
ellipse begin at the point (cx+rx,cy) and then proceed through the
points (cx,cy+ry), (cx-rx,cy), (cx,cy-ry) and finally back to
(cx+rx,cy). For stroking operations, there is only one line segment
which has its beginning joined to its end.
--
Polygon/Polyline: there shouldn't be any issues here.
--
Path:
we did not decide yet how to handle the stroke-dashoffset in indiv. path
segments.
---------
Thank you for your feedback on that topic,
Andreas
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: [EMAIL PROTECTED]
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
