You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Andreas Neumann <ne...@karto.baug.ethz.ch> on 2006/06/08 18:03:39 UTC
Question about stroke-dashing
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: 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
Re: Question about stroke-dashing
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
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 <ne...@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
Re: Question about stroke-dashing
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Thank you for your additional input. I will take it into account when
rewriting this section. I will send you a revised version for review.
The vector effects is a good example where the directionality matters.
Thanks again,
Andreas
> This is a little like asking, why do we use positive numbers instead
>of negative numbers. If you just negate everything it works, right?
>
> From a mathematical point of view I think it is very odd to specify
>your basic shapes such that they have negative area. This also means
>that the winding count for the interior of the basic shapes is negative
>rather than positive.
>
> If the whole world buys into this system then there are probably no
>problems but when you consider things like vector effects where basic
>shapes can now be used/combined with other shapes I think you are
>likely to generate confusion among users. Like for boolean operations
>if you intersected a primitive rect with another 'properly defined'
>shape you would likely end up with the portion of the shape outside
>of the rect (it might be possible so force implementations to
>'normalize' shapes according to winding rule before boolean
>operations).
>
> This also could lead to missing or extra holes when paths are
>combined because folks are likely to be surprised that the primitive
>shapes decrement winding count rather than increment.
>
> In the end I suspect it will be viewed as short sighted to go
>"against the math" just because people would rather have shapes
>go clockwise.
>
>
>---------------------------------------------------------------------
>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
Re: Question about stroke-dashing
Posted by th...@kodak.com.
Hi Andreas,
Andreas Neumann <ne...@karto.baug.ethz.ch> wrote on 06/09/2006 03:00:57
PM:
> >>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.
>
> can you explain why this is important here? Does the direction matter
> for basic shapes?
This is a little like asking, why do we use positive numbers instead
of negative numbers. If you just negate everything it works, right?
From a mathematical point of view I think it is very odd to specify
your basic shapes such that they have negative area. This also means
that the winding count for the interior of the basic shapes is negative
rather than positive.
If the whole world buys into this system then there are probably no
problems but when you consider things like vector effects where basic
shapes can now be used/combined with other shapes I think you are
likely to generate confusion among users. Like for boolean operations
if you intersected a primitive rect with another 'properly defined'
shape you would likely end up with the portion of the shape outside
of the rect (it might be possible so force implementations to
'normalize' shapes according to winding rule before boolean
operations).
This also could lead to missing or extra holes when paths are
combined because folks are likely to be surprised that the primitive
shapes decrement winding count rather than increment.
In the end I suspect it will be viewed as short sighted to go
"against the math" just because people would rather have shapes
go clockwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Question about stroke-dashing
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
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.
>>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.
>
>
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.
>
>>--
>>
>>Circle:
>>
>>
>
> 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
--
----------------------------------------------
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
Re: Question about stroke-dashing
Posted by th...@kodak.com.
Hi Andreas,
Andreas Neumann <ne...@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