4:07 a.m.
Hi.
I'm Juan Luis Boya. As a Semester of Code project
(http://semesterofcode.com/) I've have been for some time trying to add
alternative stroke alignment options to Inkscape.
There is an in-progress W3C draft for SVG2 that attempts to introduce a
property named `stroke-alignment` for this purpose. This is an attempt
to create an implementation of it. http://www.w3.org/TR/svg-strokes/
This property would control the placement of path strokes. This is
better explained with an example. See this image:
http://i.imgur.com/GIqKrwj.png
The image shows the same rectangle with four different stroking modes.
The black line represents the shape path, as that you would see with the
'Edit paths by nodes' tool in Inkscape. Shown in orange is the stroke of
the path as would be seen by the user.
A issue with the previous proposal was there was no definition for open
paths. I propose to amend this in two ways:
a) Adding two new values: `left` and `right`. `left` would place the
stroke at the left of each path segment. The direction of the path is
determined by the order of the nodes, in the same manner arrow lines
work. The following image shows an example of how this would work:
http://i.imgur.com/otULloP.png
b) `inset` and `outset` would work as if the shapes were closed with a
straight line, except that line would not be rendered.
The property would be set as an style property (in CSS code). Add a few
toggle buttons would be added to the Inkscape UI in the Stroke Style tab
in order to control the value of the property.
As for the implementation:
1. The offsetting would be done only to the stroke line, which will
still be rendered as an stroked line (instead of being converted to a
polygon).
2. The property would be added to NRStyle and SPStyle classes.
3. Add buttons to the Stroke Style UI.
4. As far as I know, paths are rendered in DrawingShape::_renderItem().
This method reads style properties from a class member named _nrstyle.
(Therefore we need to add properties to both NRStyle and SPStyle).
Now, this method would read the property and stroke appropriately. At
the time of writing Cairo does not have support for a style property
like this, so we will do the offsetting in Inkscape.
a) If the value is center, the same path would be used for both stroke
and fill.
b) In other case, first fill will be applied using the original path,
then the offsetted path would be calculated and stroked.
For the stroke-alignment values 'right' and 'left' applying the offset
is as simple as offsetting by stroke-width/2, positive or negative
respectively.
'inset' and 'outset' are a bit more problematic, especially for
self-intersecting shapes. This figure shows how a self-intersecting
pentagram would approximately look with different values of
stroke-alignment if 'inset' and 'outset' are considered valid for
self-intersecting paths. http://i.imgur.com/s8sLumk.png
In this document I explain a procedure to stroke them, but there are
some required algorithms I don't know, remarked in "Issue" boxes:
https://inkscape.org/en/gallery/item/6356/stroke-alignment.pdf
As for the state of the implementation:
* After quite a bit of time I've got to understand the classes that make
Inkscape render shapes. I have been able to add the required SVG
property to Inkscape. I'll commit it soon. The controls in the UI will
be hidden under a compile time flag.
* I've written code to outline the stroke, but also...
* I've found several important bugs in half_outline() that cause it to
fail even for simple shapes. For instance, this is the result of passing
a triangle to half_outline() when it has been drawn counterclockwise:
http://i.imgur.com/3Tq9SvZ.jpg For that specific bug I have a
provisional fix, but it should be examined more closely.
Regards,
Juan Luis.
12:10 p.m.
New subject: RFC: stroke-alignment property for SVG and Inkscape
I've found rendering the outline as a stroked line is not always enough.
See for example this elephant shape: http://i.imgur.com/vEv9k5H.png
Although the outline is right, it does not produce the desired result as
a significant part of the original shape (pink) has been clipped.
Miters can partly alleviate the problem but due to being linear they
offer poor approximation: http://i.imgur.com/8xSgdnr.png
Having found this issue now I'm using fill instead of stroke.
http://i.imgur.com/7ntxkqV.png
Regards,
Juan Luis.
On 25/08/15 21:07, Juan Luis Boya García wrote:
Hi.
I'm Juan Luis Boya. As a Semester of Code project
(http://semesterofcode.com/) I've have been for some time trying to
add alternative stroke alignment options to Inkscape.
There is an in-progress W3C draft for SVG2 that attempts to introduce
a property named `stroke-alignment` for this purpose. This is an
attempt to create an implementation of it.
http://www.w3.org/TR/svg-strokes/
This property would control the placement of path strokes. This is
better explained with an example. See this image:
http://i.imgur.com/GIqKrwj.png
The image shows the same rectangle with four different stroking modes.
The black line represents the shape path, as that you would see with
the 'Edit paths by nodes' tool in Inkscape. Shown in orange is the
stroke of the path as would be seen by the user.
A issue with the previous proposal was there was no definition for
open paths. I propose to amend this in two ways:
a) Adding two new values: `left` and `right`. `left` would place the
stroke at the left of each path segment. The direction of the path is
determined by the order of the nodes, in the same manner arrow lines
work. The following image shows an example of how this would work:
http://i.imgur.com/otULloP.png
b) `inset` and `outset` would work as if the shapes were closed with a
straight line, except that line would not be rendered.
The property would be set as an style property (in CSS code). Add a
few toggle buttons would be added to the Inkscape UI in the Stroke
Style tab in order to control the value of the property.
As for the implementation:
1. The offsetting would be done only to the stroke line, which will
still be rendered as an stroked line (instead of being converted to a
polygon).
2. The property would be added to NRStyle and SPStyle classes.
3. Add buttons to the Stroke Style UI.
4. As far as I know, paths are rendered in
DrawingShape::_renderItem(). This method reads style properties from a
class member named _nrstyle. (Therefore we need to add properties to
both NRStyle and SPStyle).
Now, this method would read the property and stroke appropriately. At
the time of writing Cairo does not have support for a style property
like this, so we will do the offsetting in Inkscape.
a) If the value is center, the same path would be used for both stroke
and fill.
b) In other case, first fill will be applied using the original path,
then the offsetted path would be calculated and stroked.
For the stroke-alignment values 'right' and 'left' applying the offset
is as simple as offsetting by stroke-width/2, positive or negative
respectively.
'inset' and 'outset' are a bit more problematic, especially for
self-intersecting shapes. This figure shows how a self-intersecting
pentagram would approximately look with different values of
stroke-alignment if 'inset' and 'outset' are considered valid for
self-intersecting paths. http://i.imgur.com/s8sLumk.png
In this document I explain a procedure to stroke them, but there are
some required algorithms I don't know, remarked in "Issue" boxes:
https://inkscape.org/en/gallery/item/6356/stroke-alignment.pdf
As for the state of the implementation:
* After quite a bit of time I've got to understand the classes that
make Inkscape render shapes. I have been able to add the required SVG
property to Inkscape. I'll commit it soon. The controls in the UI will
be hidden under a compile time flag.
* I've written code to outline the stroke, but also...
* I've found several important bugs in half_outline() that cause it to
fail even for simple shapes. For instance, this is the result of
passing a triangle to half_outline() when it has been drawn
counterclockwise: http://i.imgur.com/3Tq9SvZ.jpg For that specific bug
I have a provisional fix, but it should be examined more closely.
Regards,
Juan Luis.
6:59 p.m.
On Wed, 2015-08-26 at 05:10 +0200, Juan Luis Boya García wrote:
I've found rendering the outline as a stroked line is not always
enough. See for example this elephant shape:
http://i.imgur.com/vEv9k5H.png Although the outline is right, it does
not produce the desired result as a significant part of the original
shape (pink) has been clipped.
Yes, stroking an outline doesn't work for insets. It works for outsets
except dashes will be shifted.
Miters can partly alleviate the problem but due to being linear they
offer poor approximation: http://i.imgur.com/8xSgdnr.png
Miters are not a good solution.
Having found this issue now I'm using fill instead of stroke.
http://i.imgur.com/7ntxkqV.png
This works for solid strokes but not for dashed strokes.
It seems that implementing 'stroke-alignment' isn't as easy as one
would first think!
Tav
5:04 p.m.
Hi Juan Luis. Is great to know you are on it. Maybe Martin have a
related proyect to you and I undertand to him is a paied work. The basic
goal is diferent offsets for each curve in path. This can be implemented
by your map into a Pointwise -not released yet- based LPE.
Also want to remember Liam do some work to stroke offset on JoinType LPE
and there is things can help you.
All the best, Jabier.
On mar, 2015-08-25 at 21:07 +0200, Juan Luis Boya García wrote:
Hi.
I'm Juan Luis Boya. As a Semester of Code project
(http://semesterofcode.com/) I've have been for some time trying to
add alternative stroke alignment options to Inkscape.
There is an in-progress W3C draft for SVG2 that attempts to introduce
a property named `stroke-alignment` for this purpose. This is an
attempt to create an implementation of it.
http://www.w3.org/TR/svg-strokes/
This property would control the placement of path strokes. This is
better explained with an example. See this image:
http://i.imgur.com/GIqKrwj.png
The image shows the same rectangle with four different stroking modes.
The black line represents the shape path, as that you would see with
the 'Edit paths by nodes' tool in Inkscape. Shown in orange is the
stroke of the path as would be seen by the user.
A issue with the previous proposal was there was no definition for
open paths. I propose to amend this in two ways:
a) Adding two new values: `left` and `right`. `left` would place the
stroke at the left of each path segment. The direction of the path is
determined by the order of the nodes, in the same manner arrow lines
work. The following image shows an example of how this would work:
http://i.imgur.com/otULloP.png
b) `inset` and `outset` would work as if the shapes were closed with a
straight line, except that line would not be rendered.
The property would be set as an style property (in CSS code). Add a
few toggle buttons would be added to the Inkscape UI in the Stroke
Style tab in order to control the value of the property.
As for the implementation:
1. The offsetting would be done only to the stroke line, which will
still be rendered as an stroked line (instead of being converted to a
polygon).
2. The property would be added to NRStyle and SPStyle classes.
3. Add buttons to the Stroke Style UI.
4. As far as I know, paths are rendered in
DrawingShape::_renderItem(). This method reads style properties from a
class member named _nrstyle. (Therefore we need to add properties to
both NRStyle and SPStyle).
Now, this method would read the property and stroke appropriately. At
the time of writing Cairo does not have support for a style property
like this, so we will do the offsetting in Inkscape.
a) If the value is center, the same path would be used for both stroke
and fill.
b) In other case, first fill will be applied using the original path,
then the offsetted path would be calculated and stroked.
For the stroke-alignment values 'right' and 'left' applying the offset
is as simple as offsetting by stroke-width/2, positive or negative
respectively.
'inset' and 'outset' are a bit more problematic, especially for
self-intersecting shapes. This figure shows how a self-intersecting
pentagram would approximately look with different values of
stroke-alignment if 'inset' and 'outset' are considered valid for
self-intersecting paths. http://i.imgur.com/s8sLumk.png
In this document I explain a procedure to stroke them, but there are
some required algorithms I don't know, remarked in "Issue" boxes:
https://inkscape.org/en/gallery/item/6356/stroke-alignment.pdf
As for the state of the implementation:
* After quite a bit of time I've got to understand the classes that
make Inkscape render shapes. I have been able to add the required SVG
property to Inkscape. I'll commit it soon. The controls in the UI will
be hidden under a compile time flag.
* I've written code to outline the stroke, but also...
* I've found several important bugs in half_outline() that cause it to
fail even for simple shapes. For instance, this is the result of
passing a triangle to half_outline() when it has been drawn
counterclockwise: http://i.imgur.com/3Tq9SvZ.jpg For that specific bug
I have a provisional fix, but it should be examined more closely.
Regards,
Juan Luis.
------------------------------------------------------------------------------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
7:16 p.m.
Juan, I am glad you to see you have released this to the Inkscape
developer's mailing list. Hopefully you will get some good feedback,
especially from Jabier and Krzysztof who have been working on related
things.
Just to bring others up-to-date. We discussed 'stroke-alignment'
yesterday at the SVG WG meeting (conveniently located in Paris). The
feeling was that the initial allowed values should be 'left' and
'right' as it is easy to define how these values work for paths that
contain overlapping loops. The values 'inset' and 'outset' are more
complicated and require finding path intersections, something that the
browsers don't need to do (yet) for any other purpose. The group is
definitely interested in 'inset' and 'outset' and having an
implementation of these values will help with seeing what kind of
problems can be encountered as well as seeing what kind of demand there
is for them.
We have already identified some implementation problems: for example, a
s Juan's follow email points out, stroking of a offset path doesn't
work (wrong shape for an inset path, dashes not where one expects).
Tav
On Tue, 2015-08-25 at 21:07 +0200, Juan Luis Boya García wrote:
Hi.
I'm Juan Luis Boya. As a Semester of Code project (
http://semesterofcode.com/) I've have been for some time trying to
add alternative stroke alignment options to Inkscape.
There is an in-progress W3C draft for SVG2 that attempts to introduce
a property named `stroke-alignment` for this purpose. This is an
attempt to create an implementation of it.
http://www.w3.org/TR/svg-strokes/
This property would control the placement of path strokes. This is
better explained with an example. See this image:
http://i.imgur.com/GIqKrwj.png
The image shows the same rectangle with four different stroking
modes. The black line represents the shape path, as that you would
see with the 'Edit paths by nodes' tool in Inkscape. Shown in orange
is the stroke of the path as would be seen by the user.
A issue with the previous proposal was there was no definition for
open paths. I propose to amend this in two ways:
a) Adding two new values: `left` and `right`. `left` would place the
stroke at the left of each path segment. The direction of the path is
determined by the order of the nodes, in the same manner arrow lines
work. The following image shows an example of how this would work:
http://i.imgur.com/otULloP.png
b) `inset` and `outset` would work as if the shapes were closed with
a straight line, except that line would not be rendered.
The property would be set as an style property (in CSS code). Add a
few toggle buttons would be added to the Inkscape UI in the Stroke
Style tab in order to control the value of the property.
As for the implementation:
1. The offsetting would be done only to the stroke line, which will
still be rendered as an stroked line (instead of being converted to a
polygon).
2. The property would be added to NRStyle and SPStyle classes.
3. Add buttons to the Stroke Style UI.
4. As far as I know, paths are rendered in
DrawingShape::_renderItem(). This method reads style properties from
a class member named _nrstyle. (Therefore we need to add properties
to both NRStyle and SPStyle).
Now, this method would read the property and stroke appropriately. At
the time of writing Cairo does not have support for a style property
like this, so we will do the offsetting in Inkscape.
a) If the value is center, the same path would be used for both
stroke and fill.
b) In other case, first fill will be applied using the original path,
then the offsetted path would be calculated and stroked.
For the stroke-alignment values 'right' and 'left' applying the
offset is as simple as offsetting by stroke-width/2, positive or
negative respectively.
'inset' and 'outset' are a bit more problematic, especially for self
-intersecting shapes. This figure shows how a self-intersecting
pentagram would approximately look with different values of stroke
-alignment if 'inset' and 'outset' are considered valid for self
-intersecting paths. http://i.imgur.com/s8sLumk.png
In this document I explain a procedure to stroke them, but there are
some required algorithms I don't know, remarked in "Issue" boxes:
https://inkscape.org/en/gallery/item/6356/stroke-alignment.pdf
As for the state of the implementation:
* After quite a bit of time I've got to understand the classes that
make Inkscape render shapes. I have been able to add the required SVG
property to Inkscape. I'll commit it soon. The controls in the UI
will be hidden under a compile time flag.
* I've written code to outline the stroke, but also...
* I've found several important bugs in half_outline() that cause it
to fail even for simple shapes. For instance, this is the result of
passing a triangle to half_outline() when it has been drawn
counterclockwise: http://i.imgur.com/3Tq9SvZ.jpg For that specific
bug I have a provisional fix, but it should be examined more closely.
Regards,
Juan Luis.
---------------------------------------------------------------------
---------
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:45 p.m.
New subject: RFC: stroke-alignment property for SVG and Inkscape
2015-08-26 12:16 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
Just to bring others up-to-date. We discussed
'stroke-alignment'
yesterday at the SVG WG meeting (conveniently located in Paris). The
feeling was that the initial allowed values should be 'left' and
'right' as it is easy to define how these values work for paths that
contain overlapping loops. The values 'inset' and 'outset' are more
complicated and require finding path intersections, something that the
browsers don't need to do (yet) for any other purpose.
lib2geom can currently only find intersections between distinct paths,
but adding a method to find self-intersections would be fairly easy.
Arcs, line segments and quadratic Bezier curves cannot have
self-intersections, so we only need to handle cubic and higher order
Beziers specially, e.g. by splitting them at the roots of X
derivative. The rest of the procedure would be a simple modification
of the existing path-path intersection code.
Note that there are several degenerate cases, such as paths with
overlapping segments, and something reasonable should be done for them
as well.
Regards, Krzysztof
2767
days inactive
2769
days old
inkscape-devel@lists.inkscape.org
5 comments
4 participants
participants (4)
-
Jabier Arraiza -
Juan Luis Boya García -
Krzysztof Kosiński -
Tavmjong Bah