10:50 p.m.
Hi,
The current Inkscape code converts an elliptical arc to a Bezier curve
via converting it first to an SBasic curve. This leads to some loss of
accuracy to the curve (noticeable now that we are using SVG <circle> and
<ellipse> elements where possible) and control over where the resulting
nodes will be placed. lib2geom has been patched (r2122) to fix the
accuracy problem. Is there a reason this patch hasn't been applied to
the copy of lib2geom in Inkscape? (If no, I can apply the patch.)
Even with this patch, it might be better to provide a direct route to go
from an elliptical arc to a Bezier curve bypassing the SBasic step to
have better control over where nodes are placed. I have made a first
pass at providing a direct route. At the moment, one Bezier curve is
created if the arc is less than pi/2 in length. If it is longer, extra
nodes are placed on the major and minor ellipse axes. Can the lib2geom
experts have a look? I am sure I have not done things in a lib2geom
sanctioned way. The branch is available at:
lp:~inkscape.dev/inkscape/elliptical_arc
I've attached a test file where the red ellipses/arcs are drawn using an
"ideal" conversion to Bezier curves (with four per circle/ellipse) and
the blue curves are test arcs. (The Cairo routines convert the arcs to
Beziers for display as Cairo/PostScript/PDF do not have a native
elliptical arc path segment so just rendering arcs on screen tests the
code.)
One obvious bug is that the flash path when using the node tool is
wrong.
Thanks,
Tav
10:52 p.m.
Here is the attachment. My Internet provider would not accept the
original email with the attachment, flagging it as spam.
5:28 a.m.
just a couple of quick comments, hopefully not betraying my biases too
obviously.
1. it seems that this would be at least a partial reversion of the work that
was very recently done in rev 12594. Before rev 12594, the conversion from
arc to Bezier was done in sp-ellipse.cpp using a formula that appears to be
identical to the one being used in rev 12833 of the proposed branch
inkscape/elliptical_arc. This bypassed the sbasis representation entirely,
afaict. After rev 12594, the arc form was kept as long as possible, the
explicit conversion from arc to Bezier is no longer performed, and is
instead done indirectly through sbasis. (The sbasis conversion from arc to
Bezier in lib2geom is, I think, closely equivalent to the result obtained
before rev 12594.) The purpose of this change in rev 12594, I assume, was to
postpone the conversion to Bezier as long as possible, which I would agree
with in principle. In Inkscape 0.48.4, if you do a Path->Object to Path
operation on a circle, you get a Bezier, which is both lossy and
unnecessary. In current trunk, this does not happen.
2. there is an undesirable practical side effect of rev 12594, however:
namely it is not clear how many Beziers will actually be produced from an
arc. There are two reasons for this. First, the formula that determines the
error in the fit appears to be unnecessarily pessimistic as discussed
previously:
http://inkscape.13.x6.nabble.com/Recent-change-to-ellipse-to-path-convers...
3. second, the number of Beziers you get from an arc depends on the size of
the object, which seems unexpected, given that svg is a scalable format.
imho it would be preferable to have a dimensionless measure of the goodness
of fit, independent of the size of the object. This would need to be done in
the routine build_from_sbasis() in sbasis-to-bezier.cpp. The problem of
course would be in defining what the size of the object is, which can be
difficult, witness the case of filters where some properties of filters are
in dimensionless units while other properties are in absolute units, leading
to confusion when the shape changes drastically.
cheers,
Alvin
--
View this message in context:
http://inkscape.13.x6.nabble.com/Elliptical-arc-branch-tp4968816p4968818....
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
2:38 a.m.
On 29-Nov-2013 12:28, alvinpenner wrote:
3. second, the number of Beziers you get from an arc depends on the
size of
the object, which seems unexpected, given that svg is a scalable
format.
Assuming the arc is defined with respect to an ellipse with major axis A
then I would
assume that the proper step to take is to translate the center of that
ellipse to the origin and divide all coordinate positions by A, reducing
the specific ellipse to its "unit ellipse" form. When done with the
calculation, apply the inverse scale and offset to the bezier
coordinates.
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
3:41 a.m.
> Assuming the arc is defined with respect to an ellipse with major
axis A
unfortunately I did not express myself very clearly in that comment. My
comment made it sound as though the problem at hand is conversion of an arc
to a Bezier. But of course that is not true, the problem at hand is the
conversion of an arbitrary sbasis curve to a Bezier without having any
knowledge at all of what the original function was that led to the sbasis in
the first place. That function may have been an elliptical arc or it may
have been something else like a Hypotrochoid, not very likely but still
conceivable.
So one needs a measure of size that does not presuppose anything, and it
needs to behave well in the case that one dimension disappears entirely,
like when you convert a square to a straight line. One possibility might be
to borrow an idea from the filter code where a blur % is converted to an
absolute size in pixels. The way this is done, roughly, is to first get the
bbox, then calculate the perimeter of the bbox, then divide it by 4, and
then think of that length as being the length of a side of a square which
represents the "normalized" object. This is a bit "quick and dirty"
but it
works well for an object that actually is square and it does not behave
pathologically in the case where one dimension goes to zero. It might serve
as a measure of size so that the absolute tolerance could be converted into
a dimensionless tolerance.
Alvin
--
View this message in context:
http://inkscape.13.x6.nabble.com/Elliptical-arc-branch-tp4968816p4968873....
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
4:34 a.m.
On 02-Dec-2013 10:41, alvinpenner wrote:
>> Assuming the arc is defined with respect to an ellipse with
major
>> axis A
unfortunately I did not express myself very clearly in that comment. My
comment made it sound as though the problem at hand is conversion of an
arc
to a Bezier. But of course that is not true, the problem at hand is the
conversion of an arbitrary sbasis curve to a Bezier without having any
knowledge at all of what the original function was that led to the
sbasis in
the first place. That function may have been an elliptical arc or it
may
have been something else like a Hypotrochoid, not very likely but still
conceivable.
Would a close approximation to normalization suffice? If so, find a
convenient number
of standard points on the curve, perhaps the 6 points at
t=0,0.2,0.4,0.6,0.8,and 1.0.
Project these onto a set of standard lines every 15 degrees between 0
and 180 degrees, and find the distance between the other points on each
projection. Use the maximum of those distances as the extent value.
(Alternatively calculate a principal component, but I suspect that using
the standard projections would be faster.)
There are two sources of error:
1. The maximum extent points might not be included in the set. I
cannot estimate this error, it depends on what sorts of cusps and so
forth that the s-basis allows, and I know nothing about s-basis curves.
2. The arbitrarily scaled and rotated curve may have its true extent
vector rotated from one of the standard vectors by at most 7.5 degrees,
so the extent can only be off by at most a factor of 1.0 - cos(7.5deg)
== .0086.
Since the issue you are correcting for sounds like it only shows up when
there are large differences in scale, these very small differences in
the normalized curve should not be a problem.
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
midnight
Hi Tav,
As you are working on elliptical arc code, I hope you can find the
time to look into the following issue (lib2geom maillist 7-11-2013):
Is there a bug perhaps in this piece of code:
elliptical-arc.cpp, lines 608-632
double dsq1 = distanceSq(p, pointAt(from));
double dsq2 = distanceSq(p, pointAt(to));
if ( second_sol )
{
if ( mindistsq2 > dsq1 )
{
result.clear();
result.push_back(from);
mindistsq2 = dsq1;
}
else if ( are_near(mindistsq2, dsq) ) <--------- BUG ?
{
result.push_back(from);
}
if ( mindistsq2 > dsq2 )
{
result.clear();
result.push_back(to);
}
else if ( are_near(mindistsq2, dsq2) )
{
result.push_back(to);
}
}
From symmetry of the code, shouldn't "dsq" be "dsq1" in that
line? The
code compiles because earlier, "dsq" was defined. If this is not a bug,
please add a comment in the code, saying that it is indeed correct.
If it*is* a bug, please correct it, and also reduce the scope of the
"dsq" variable defined earlier.
Thanks a lot,
Johan
On 29-11-2013 14:50, Tavmjong Bah wrote:
Hi,
The current Inkscape code converts an elliptical arc to a Bezier curve
via converting it first to an SBasic curve. This leads to some loss of
accuracy to the curve (noticeable now that we are using SVG <circle> and
<ellipse> elements where possible) and control over where the resulting
nodes will be placed. lib2geom has been patched (r2122) to fix the
accuracy problem. Is there a reason this patch hasn't been applied to
the copy of lib2geom in Inkscape? (If no, I can apply the patch.)
Even with this patch, it might be better to provide a direct route to go
from an elliptical arc to a Bezier curve bypassing the SBasic step to
have better control over where nodes are placed. I have made a first
pass at providing a direct route. At the moment, one Bezier curve is
created if the arc is less than pi/2 in length. If it is longer, extra
nodes are placed on the major and minor ellipse axes. Can the lib2geom
experts have a look? I am sure I have not done things in a lib2geom
sanctioned way. The branch is available at:
lp:~inkscape.dev/inkscape/elliptical_arc
I've attached a test file where the red ellipses/arcs are drawn using an
"ideal" conversion to Bezier curves (with four per circle/ellipse) and
the blue curves are test arcs. (The Cairo routines convert the arcs to
Beziers for display as Cairo/PostScript/PDF do not have a native
elliptical arc path segment so just rendering arcs on screen tests the
code.)
One obvious bug is that the flash path when using the node tool is
wrong.
Thanks,
Tav
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg....
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
4:41 a.m.
On Sun, 2013-12-01 at 16:00 +0100, Johan Engelen wrote:
Hi Tav,
As you are working on elliptical arc code, I hope you can find the
time to look into the following issue (lib2geom maillist 7-11-2013):
I will certainly take a look at it when I get a chance. I am by no means
a lib2geom expert... in fact, one of the reasons I put my work out there
was to get feedback from the real experts.
Tav
Is there a bug perhaps in this piece of code:
elliptical-arc.cpp, lines 608-632
double dsq1 = distanceSq(p, pointAt(from));
double dsq2 = distanceSq(p, pointAt(to));
if ( second_sol )
{
if ( mindistsq2 > dsq1 )
{
result.clear();
result.push_back(from);
mindistsq2 = dsq1;
}
else if ( are_near(mindistsq2, dsq) ) <--------- BUG ?
{
result.push_back(from);
}
if ( mindistsq2 > dsq2 )
{
result.clear();
result.push_back(to);
}
else if ( are_near(mindistsq2, dsq2) )
{
result.push_back(to);
}
}
From symmetry of the code, shouldn't "dsq" be "dsq1" in that
line? The
code compiles because earlier, "dsq" was defined. If this is not a bug,
please add a comment in the code, saying that it is indeed correct.
If it *is* a bug, please correct it, and also reduce the scope of the
"dsq" variable defined earlier.
Thanks a lot,
Johan
On 29-11-2013 14:50, Tavmjong Bah wrote:
> Hi,
>
> The current Inkscape code converts an elliptical arc to a Bezier curve
> via converting it first to an SBasic curve. This leads to some loss of
> accuracy to the curve (noticeable now that we are using SVG <circle> and
> <ellipse> elements where possible) and control over where the resulting
> nodes will be placed. lib2geom has been patched (r2122) to fix the
> accuracy problem. Is there a reason this patch hasn't been applied to
> the copy of lib2geom in Inkscape? (If no, I can apply the patch.)
>
> Even with this patch, it might be better to provide a direct route to go
> from an elliptical arc to a Bezier curve bypassing the SBasic step to
> have better control over where nodes are placed. I have made a first
> pass at providing a direct route. At the moment, one Bezier curve is
> created if the arc is less than pi/2 in length. If it is longer, extra
> nodes are placed on the major and minor ellipse axes. Can the lib2geom
> experts have a look? I am sure I have not done things in a lib2geom
> sanctioned way. The branch is available at:
>
> lp:~inkscape.dev/inkscape/elliptical_arc
>
> I've attached a test file where the red ellipses/arcs are drawn using an
> "ideal" conversion to Bezier curves (with four per circle/ellipse) and
> the blue curves are test arcs. (The Cairo routines convert the arcs to
> Beziers for display as Cairo/PostScript/PDF do not have a native
> elliptical arc path segment so just rendering arcs on screen tests the
> code.)
>
> One obvious bug is that the flash path when using the node tool is
> wrong.
>
> Thanks,
>
> Tav
>
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg....
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg....
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
3402
days inactive
3405
days old
inkscape-devel@lists.inkscape.org
7 comments
4 participants
participants (4)
-
alvinpenner -
Johan Engelen -
mathog -
Tavmjong Bah