xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Question about stroke-dashing
Date Thu, 08 Jun 2006 16:51:03 GMT
Hi Andreas,

Andreas Neumann <neumann@karto.baug.ethz.ch> 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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message