xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Neumann <neum...@karto.baug.ethz.ch>
Subject Re: Question about stroke-dashing
Date Thu, 08 Jun 2006 18:29:06 GMT
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

thomas.deweese@kodak.com wrote:

>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
>
>  
>


-- 
----------------------------------------------
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: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/


---------------------------------------------------------------------
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