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 Fri, 09 Jun 2006 19:00:57 GMT
Hi Thomas,

we just discussed this problem and would like to know a bit more on it:

>   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.
yes, thats what we want to do.

>   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...
thats what we decided for now. At least for now in the tiny version 
we'll leave it to the UA. I also agree that it probably wouldn't matter 
for many cases.

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

can you explain why this is important here? Does the direction matter 
for basic shapes?

>        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.
good point. Will be added.

>        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).
good point, will be added.

>    1) This is also has negative area.

same question: why is it important? people think it is natural to do it 
clockwise. Same question applies for ellipse.

>    2) It's start point is different from a rect with
Thank you for your feedback on this,

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

View raw message