Thank you Thomas for your valuable input.
We will discuss it today and I'll send you a revised version for review
later. I think we'll follow most of your advice.
Andreas
[EMAIL PROTECTED] wrote:
Hi Andreas,
Andreas Neumann <[EMAIL PROTECTED]> wrote on 06/08/2006 12:03:39
PM:
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.
There are two issues:
1) Basic path rendering is not mapped cleanly/clearly to paths.
2) Stroking - mostly an issue for paths with sub-parts.
For #1 I think it is reasonable and desirable for the WG to
define this. The impact on implementations will likely be minimal
as most rendering engines end up mapping the primitives to general
paths (perhaps just polygons) at some point before rendering.
For #2 I think it is much less important and less desirable
for the WG to define. Most implementations don't control the
stroking alg. Stroking alg are very complex and I worry that in
cases where the stroke is wide enough for stroked 'sub paths' to
intersect an implementation would rendering slowly and incorrectly
(the stroke would be double opaque in the overlap region).
My personal feeling is that the Spec should leave most of
the aspects of stroking to implementations. When the
stroke becomes significantly more than a "dotted line" I think
authors should switch from stroke to explicit geometry if they
are concerned about uniform rendering...
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)
I assume everyone does it the same for path?
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)
Yes, but this is still fairly subtle. I can understand that the
difference might be important in some cases but the vast majority of
users won't notice.
Rect:
A couple of comments on this.
1) The shape described is really a hole (the area of the shape
is negative, given the SVG coordinate system). It should
go counter clock wise.
2) There should be some text allowing the elliptical arcs
to be omitted when r="0" otherwise an implementation would
be forced to place 'double markers' in the corners of a rect.
Probably similar text for when rx >= w/2 and/or ry >= h/2.
3) Finally I would like the definition to start with an elliptical
arc (if needed) so it can end with a 'z' rather than an arc-to
that 'hopefully' matches the start.
It is also worth noting that w/o explicit mention of the 'z'
the path is _not_ closed and hence end-capping should take
place (also angle calculations for markers are affected).
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:
1) This is also has negative area.
2) It's start point is different from a rect with
rx=w/2 and ry=h/2. I think this is sub-optimal.
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:
1) This is also has negative area.
2) It's start point is different from a rect with
rx=w/2 and ry=h/2. I think this is sub-optimal.
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,
I hope this helps. I also greatly appreciate the
WG taking the time to contact implementations.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
----------------------------------------------
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]
