lib2geom-devel — development discussion

Re: [Lib2geom-devel] Maximum distance between curves

[Alexander B. <Bro...@we...>]

On 30/03/15 04:25, Krzysztof Kosiński wrote:
> For the new Boolean operations algorithm, I could use a routine which
> calculates the following: Given two curves, or even better two
> sequences of curves, find a time value on one of them that maximizes
> the distance from the other. In other words, I want to find t on c1
> such that the distance from c1.poinAt(t) to the nearest point on c2 is
> maximal. It can be assumed that the endpoints of both curve sequences
> are exactly equal.
>
> Is there some clever way to calculate this?
>
> I need this to determine whether the fragments of paths between two
> intersections are sufficiently similar to one another that they can be
> considered the same.

Do I understand correctly that you don't actually need the exact
distance but instead an algorithm which always gives one of the
following two results would be sufficient?
a) The curves are guaranteed to have a maximum distance of smaller than x
b) The curves are guaranteed to have a maximum distance of greater (or
equal) than x

I have ideas:
a) If the endpoints of the bezier _segments_ are identical things get a
lot less complex. I experimented with two ideas on how to get an upper
bound for the distance and wrote them both down. The second looks
promising to me, it only involves calculating the roots of a square
polynomial and the distances of the control points and gives you upper
and lower bounds for the maximum distance.

b) Let's assume curve A is a single bezier segment and curve B composed
of two bezier segments. Find the point Z on A which minimizes the
distance between the curve A and the point on B where the first segment
ends and the second starts. If that difference is greater than x you're
finished.
Otherwise decompose A at the point Z into two bezier segments which exactly
represent A and use idea a).

c) Any two curves A and B which are exactly the same but composed
differently can be decomposed into smaller bezier segments such that
every segment in A' has an exactly equal corresponding segment in B'

https://github.com/abrock/optimization (I'll give push rights to anyone
who asks)

The second section leads to a method which should be rather easy to
implement and it gives upper and lower bounds for the maximum distance.

One problem is that different control points can parameterize similar
curves. Extreme example:
If the second and third control points lie anywhere on the straight line
between the first and fourth control point the result is always a
straight line.
If the second and third control points lie "almost" on the straight line
between the first and fourth control point you could probably change
them "a lot" without getting very different curves.

I think the ideas I wrote down might work for most cases (and fast). If
the upper and lower bounds are useless, e.g. in the extreme cases
mentioned you could fall back to converting the curves into sufficiently
accurate polygon segments and measure their distance (this is probably
slower).

Regards,
Alexander

Re: [Lib2geom-devel] Mandatory path stitching

[Johan E. <jbc...@sw...>]

That sounds even better, actually.

Good stuff,
   Johan


On 29-3-2015 20:43, Krzysztof Kosiński wrote:
> How about flipping the default, i.e. normally exceptions are raised
> just before stitching would occur, but you can disable them?
>
> This is similar to the previous behaviour, but would raise errors in
> sloppy code at the point where invalid values are inserted into the
> path, not when someone later tries to use the broken path.
>
> Regards, Krzysztof
>
> 2015-03-29 12:38 GMT+02:00 Johan Engelen <jbc...@sw...>:
>> Stitching, i.e. adding segments, is not a good solution to floating point
>> rounding problems. IIRC, most of 2geom explicitly sets end-points to the
>> same value, solving rounding problems. You have to push 2geom pretty hard to
>> have it generate non-continuous paths. When adding little segments to paths
>> that generate discontinuities for some operations, I think the problem only
>> escalates.
>> (Side point: from what I remember, many of the non-continuity exceptions
>> arise because of user code pushing NaN points to the path. That's not going
>> be solved by stitching.)
>>
>> In any case, I am simply giving my input having used 2geom a lot in
>> Inkscape, but I don't expect to be writing code with/for it in the near
>> future.
>> I don't see why stitching should be implied default behavior. Stitching is
>> useful, but isn't it really just a hack? My course of action would be to
>> remove the default Stitching value for all functions that take a Stitching
>> argument.
>>
>> - Johan
>>
>>
>>
>> On 29-3-2015 0:25, Nathan Hurst wrote:
>>> It's not sloppy code, it's inescapable floating point rounding.
>>>
>>> njh
>>>
>>> On Sat, Mar 28, 2015 at 10:29:07PM +0100, Johan Engelen wrote:
>>>> I understood what you wrote.
>>>> I argued that the default of allowing sloppy code is probably not a good
>>>> default.
>>>>
>>>> - Johan
>>>>
>>>>
>>>> On 28-3-2015 17:24, Krzysztof Kosiński wrote:
>>>>> A non-contiguous path is practically always an error, so it makes
>>>>> sense to either prevent it or report it as early as possible. Now the
>>>>> default behavior is to add those extra segments, which allows sloppily
>>>>> written code to function as expected, but you can call
>>>>> setStitchExceptions() to enable the throwing of exceptions whenever a
>>>>> stitch segment would be appended.
>>>>>
>>>>> Regards, Krzysztof
>>>>>
>>>>> 2015-03-28 13:09 GMT+01:00 Johan Engelen <jbc...@sw...>:
>>>>>> On 27-3-2015 20:48, Krzysztof Kosiński wrote:
>>>>>>> Every method that modifies a Path has an optional argument called
>>>>>>> "stitching" that determines whether additional segments are added to
>>>>>>> make the path continuous. By default, stitching is not used. If there
>>>>>>> are any discontinuities, calling some of Path will cause an exception
>>>>>>> to be thrown, which in most cases means a crash.
>>>>>>>
>>>>>>> I want to make stitching mandatory. Since in some cases you want to be
>>>>>>> sure that no stitching happens in your code, there will be an extra
>>>>>>> boolean member variable. When set to true, it will throw an exception
>>>>>>> whenever you try to insert a discontinuity into the path.
>>>>>>>
>>>>>>> Is everyone OK with this idea?
>>>>>> I am not so sure about this.
>>>>>> It may not be very helpful if 2geom automatically fixes "user errors",
>>>>>> leading to unexpected results. If you change the default behavior (from
>>>>>> not stitching to stitching), user code will suddenly behave different
>>>>>> perhaps without the user knowing (e.g. no compiler error).
>>>>>> How about making the _choice_ for stitching behavior mandatory?
>>>>>>
>>>>>> -Johan
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>>>>> sponsored
>>>>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>>>>> for all
>>>>>> things parallel software development, from weekly thought leadership
>>>>>> blogs to
>>>>>> news, videos, case studies, tutorials and more. Take a look and join
>>>>>> the
>>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>>> _______________________________________________
>>>>>> Lib2geom-devel mailing list
>>>>>> Lib...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>>> sponsored
>>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>>> for all
>>>> things parallel software development, from weekly thought leadership
>>>> blogs to
>>>> news, videos, case studies, tutorials and more. Take a look and join the
>>>> conversation now. http://goparallel.sourceforge.net/
>>>> _______________________________________________
>>>> Lib2geom-devel mailing list
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>>
>

[Lib2geom-devel] Maximum distance between curves

[Krzysztof K. <twe...@gm...>]

For the new Boolean operations algorithm, I could use a routine which
calculates the following: Given two curves, or even better two
sequences of curves, find a time value on one of them that maximizes
the distance from the other. In other words, I want to find t on c1
such that the distance from c1.poinAt(t) to the nearest point on c2 is
maximal. It can be assumed that the endpoints of both curve sequences
are exactly equal.

Is there some clever way to calculate this?

I need this to determine whether the fragments of paths between two
intersections are sufficiently similar to one another that they can be
considered the same. Or perhaps someone has a better idea on how to
resolve degeneracies in the Greiner-Hormann algorithm (now implemented
in intersection-graph.cpp)? The paper by Foster and Overfelt does not
easily generalize from polygons to paths:
http://arxiv.org/pdf/1211.3376v1.pdf

Regards, Krzysztof

Re: [Lib2geom-devel] Mandatory path stitching

[Krzysztof K. <twe...@gm...>]

How about flipping the default, i.e. normally exceptions are raised
just before stitching would occur, but you can disable them?

This is similar to the previous behaviour, but would raise errors in
sloppy code at the point where invalid values are inserted into the
path, not when someone later tries to use the broken path.

Regards, Krzysztof

2015-03-29 12:38 GMT+02:00 Johan Engelen <jbc...@sw...>:
> Stitching, i.e. adding segments, is not a good solution to floating point
> rounding problems. IIRC, most of 2geom explicitly sets end-points to the
> same value, solving rounding problems. You have to push 2geom pretty hard to
> have it generate non-continuous paths. When adding little segments to paths
> that generate discontinuities for some operations, I think the problem only
> escalates.
> (Side point: from what I remember, many of the non-continuity exceptions
> arise because of user code pushing NaN points to the path. That's not going
> be solved by stitching.)
>
> In any case, I am simply giving my input having used 2geom a lot in
> Inkscape, but I don't expect to be writing code with/for it in the near
> future.
> I don't see why stitching should be implied default behavior. Stitching is
> useful, but isn't it really just a hack? My course of action would be to
> remove the default Stitching value for all functions that take a Stitching
> argument.
>
> - Johan
>
>
>
> On 29-3-2015 0:25, Nathan Hurst wrote:
>>
>> It's not sloppy code, it's inescapable floating point rounding.
>>
>> njh
>>
>> On Sat, Mar 28, 2015 at 10:29:07PM +0100, Johan Engelen wrote:
>>>
>>> I understood what you wrote.
>>> I argued that the default of allowing sloppy code is probably not a good
>>> default.
>>>
>>> - Johan
>>>
>>>
>>> On 28-3-2015 17:24, Krzysztof Kosiński wrote:
>>>>
>>>> A non-contiguous path is practically always an error, so it makes
>>>> sense to either prevent it or report it as early as possible. Now the
>>>> default behavior is to add those extra segments, which allows sloppily
>>>> written code to function as expected, but you can call
>>>> setStitchExceptions() to enable the throwing of exceptions whenever a
>>>> stitch segment would be appended.
>>>>
>>>> Regards, Krzysztof
>>>>
>>>> 2015-03-28 13:09 GMT+01:00 Johan Engelen <jbc...@sw...>:
>>>>>
>>>>> On 27-3-2015 20:48, Krzysztof Kosiński wrote:
>>>>>>
>>>>>> Every method that modifies a Path has an optional argument called
>>>>>> "stitching" that determines whether additional segments are added to
>>>>>> make the path continuous. By default, stitching is not used. If there
>>>>>> are any discontinuities, calling some of Path will cause an exception
>>>>>> to be thrown, which in most cases means a crash.
>>>>>>
>>>>>> I want to make stitching mandatory. Since in some cases you want to be
>>>>>> sure that no stitching happens in your code, there will be an extra
>>>>>> boolean member variable. When set to true, it will throw an exception
>>>>>> whenever you try to insert a discontinuity into the path.
>>>>>>
>>>>>> Is everyone OK with this idea?
>>>>>
>>>>> I am not so sure about this.
>>>>> It may not be very helpful if 2geom automatically fixes "user errors",
>>>>> leading to unexpected results. If you change the default behavior (from
>>>>> not stitching to stitching), user code will suddenly behave different
>>>>> perhaps without the user knowing (e.g. no compiler error).
>>>>> How about making the _choice_ for stitching behavior mandatory?
>>>>>
>>>>> -Johan
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>>>> sponsored
>>>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>>>> for all
>>>>> things parallel software development, from weekly thought leadership
>>>>> blogs to
>>>>> news, videos, case studies, tutorials and more. Take a look and join
>>>>> the
>>>>> conversation now. http://goparallel.sourceforge.net/
>>>>> _______________________________________________
>>>>> Lib2geom-devel mailing list
>>>>> Lib...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Lib2geom-devel mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>
>>
>

Re: [Lib2geom-devel] Mandatory path stitching

[Johan E. <jbc...@sw...>]

Stitching, i.e. adding segments, is not a good solution to floating 
point rounding problems. IIRC, most of 2geom explicitly sets end-points 
to the same value, solving rounding problems. You have to push 2geom 
pretty hard to have it generate non-continuous paths. When adding little 
segments to paths that generate discontinuities for some operations, I 
think the problem only escalates.
(Side point: from what I remember, many of the non-continuity exceptions 
arise because of user code pushing NaN points to the path. That's not 
going be solved by stitching.)

In any case, I am simply giving my input having used 2geom a lot in 
Inkscape, but I don't expect to be writing code with/for it in the near 
future.
I don't see why stitching should be implied default behavior. Stitching 
is useful, but isn't it really just a hack? My course of action would be 
to remove the default Stitching value for all functions that take a 
Stitching argument.

- Johan


On 29-3-2015 0:25, Nathan Hurst wrote:
> It's not sloppy code, it's inescapable floating point rounding.
>
> njh
>
> On Sat, Mar 28, 2015 at 10:29:07PM +0100, Johan Engelen wrote:
>> I understood what you wrote.
>> I argued that the default of allowing sloppy code is probably not a good
>> default.
>>
>> - Johan
>>
>>
>> On 28-3-2015 17:24, Krzysztof Kosiński wrote:
>>> A non-contiguous path is practically always an error, so it makes
>>> sense to either prevent it or report it as early as possible. Now the
>>> default behavior is to add those extra segments, which allows sloppily
>>> written code to function as expected, but you can call
>>> setStitchExceptions() to enable the throwing of exceptions whenever a
>>> stitch segment would be appended.
>>>
>>> Regards, Krzysztof
>>>
>>> 2015-03-28 13:09 GMT+01:00 Johan Engelen <jbc...@sw...>:
>>>> On 27-3-2015 20:48, Krzysztof Kosiński wrote:
>>>>> Every method that modifies a Path has an optional argument called
>>>>> "stitching" that determines whether additional segments are added to
>>>>> make the path continuous. By default, stitching is not used. If there
>>>>> are any discontinuities, calling some of Path will cause an exception
>>>>> to be thrown, which in most cases means a crash.
>>>>>
>>>>> I want to make stitching mandatory. Since in some cases you want to be
>>>>> sure that no stitching happens in your code, there will be an extra
>>>>> boolean member variable. When set to true, it will throw an exception
>>>>> whenever you try to insert a discontinuity into the path.
>>>>>
>>>>> Is everyone OK with this idea?
>>>> I am not so sure about this.
>>>> It may not be very helpful if 2geom automatically fixes "user errors",
>>>> leading to unexpected results. If you change the default behavior (from
>>>> not stitching to stitching), user code will suddenly behave different
>>>> perhaps without the user knowing (e.g. no compiler error).
>>>> How about making the _choice_ for stitching behavior mandatory?
>>>>
>>>> -Johan
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>>>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>>>> things parallel software development, from weekly thought leadership blogs to
>>>> news, videos, case studies, tutorials and more. Take a look and join the
>>>> conversation now. http://goparallel.sourceforge.net/
>>>> _______________________________________________
>>>> Lib2geom-devel mailing list
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Lib2geom-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>

Re: [Lib2geom-devel] Mandatory path stitching

[Nathan H. <nj...@nj...>]

It's not sloppy code, it's inescapable floating point rounding.

njh

On Sat, Mar 28, 2015 at 10:29:07PM +0100, Johan Engelen wrote:
> I understood what you wrote.
> I argued that the default of allowing sloppy code is probably not a good 
> default.
> 
> - Johan
> 
> 
> On 28-3-2015 17:24, Krzysztof Kosiński wrote:
> > A non-contiguous path is practically always an error, so it makes
> > sense to either prevent it or report it as early as possible. Now the
> > default behavior is to add those extra segments, which allows sloppily
> > written code to function as expected, but you can call
> > setStitchExceptions() to enable the throwing of exceptions whenever a
> > stitch segment would be appended.
> >
> > Regards, Krzysztof
> >
> > 2015-03-28 13:09 GMT+01:00 Johan Engelen <jbc...@sw...>:
> >> On 27-3-2015 20:48, Krzysztof Kosiński wrote:
> >>> Every method that modifies a Path has an optional argument called
> >>> "stitching" that determines whether additional segments are added to
> >>> make the path continuous. By default, stitching is not used. If there
> >>> are any discontinuities, calling some of Path will cause an exception
> >>> to be thrown, which in most cases means a crash.
> >>>
> >>> I want to make stitching mandatory. Since in some cases you want to be
> >>> sure that no stitching happens in your code, there will be an extra
> >>> boolean member variable. When set to true, it will throw an exception
> >>> whenever you try to insert a discontinuity into the path.
> >>>
> >>> Is everyone OK with this idea?
> >> I am not so sure about this.
> >> It may not be very helpful if 2geom automatically fixes "user errors",
> >> leading to unexpected results. If you change the default behavior (from
> >> not stitching to stitching), user code will suddenly behave different
> >> perhaps without the user knowing (e.g. no compiler error).
> >> How about making the _choice_ for stitching behavior mandatory?
> >>
> >> -Johan
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> >> by Intel and developed in partnership with Slashdot Media, is your hub for all
> >> things parallel software development, from weekly thought leadership blogs to
> >> news, videos, case studies, tutorials and more. Take a look and join the
> >> conversation now. http://goparallel.sourceforge.net/
> >> _______________________________________________
> >> Lib2geom-devel mailing list
> >> Lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> >
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

Re: [Lib2geom-devel] Mandatory path stitching

[Johan E. <jbc...@sw...>]

I understood what you wrote.
I argued that the default of allowing sloppy code is probably not a good 
default.

- Johan


On 28-3-2015 17:24, Krzysztof Kosiński wrote:
> A non-contiguous path is practically always an error, so it makes
> sense to either prevent it or report it as early as possible. Now the
> default behavior is to add those extra segments, which allows sloppily
> written code to function as expected, but you can call
> setStitchExceptions() to enable the throwing of exceptions whenever a
> stitch segment would be appended.
>
> Regards, Krzysztof
>
> 2015-03-28 13:09 GMT+01:00 Johan Engelen <jbc...@sw...>:
>> On 27-3-2015 20:48, Krzysztof Kosiński wrote:
>>> Every method that modifies a Path has an optional argument called
>>> "stitching" that determines whether additional segments are added to
>>> make the path continuous. By default, stitching is not used. If there
>>> are any discontinuities, calling some of Path will cause an exception
>>> to be thrown, which in most cases means a crash.
>>>
>>> I want to make stitching mandatory. Since in some cases you want to be
>>> sure that no stitching happens in your code, there will be an extra
>>> boolean member variable. When set to true, it will throw an exception
>>> whenever you try to insert a discontinuity into the path.
>>>
>>> Is everyone OK with this idea?
>> I am not so sure about this.
>> It may not be very helpful if 2geom automatically fixes "user errors",
>> leading to unexpected results. If you change the default behavior (from
>> not stitching to stitching), user code will suddenly behave different
>> perhaps without the user knowing (e.g. no compiler error).
>> How about making the _choice_ for stitching behavior mandatory?
>>
>> -Johan
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Lib2geom-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>

Re: [Lib2geom-devel] Mandatory path stitching

[Krzysztof K. <twe...@gm...>]

A non-contiguous path is practically always an error, so it makes
sense to either prevent it or report it as early as possible. Now the
default behavior is to add those extra segments, which allows sloppily
written code to function as expected, but you can call
setStitchExceptions() to enable the throwing of exceptions whenever a
stitch segment would be appended.

Regards, Krzysztof

2015-03-28 13:09 GMT+01:00 Johan Engelen <jbc...@sw...>:
> On 27-3-2015 20:48, Krzysztof Kosiński wrote:
>> Every method that modifies a Path has an optional argument called
>> "stitching" that determines whether additional segments are added to
>> make the path continuous. By default, stitching is not used. If there
>> are any discontinuities, calling some of Path will cause an exception
>> to be thrown, which in most cases means a crash.
>>
>> I want to make stitching mandatory. Since in some cases you want to be
>> sure that no stitching happens in your code, there will be an extra
>> boolean member variable. When set to true, it will throw an exception
>> whenever you try to insert a discontinuity into the path.
>>
>> Is everyone OK with this idea?
>
> I am not so sure about this.
> It may not be very helpful if 2geom automatically fixes "user errors",
> leading to unexpected results. If you change the default behavior (from
> not stitching to stitching), user code will suddenly behave different
> perhaps without the user knowing (e.g. no compiler error).
> How about making the _choice_ for stitching behavior mandatory?
>
> -Johan
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

Re: [Lib2geom-devel] Mandatory path stitching

[Johan E. <jbc...@sw...>]

On 27-3-2015 20:48, Krzysztof Kosiński wrote:
> Every method that modifies a Path has an optional argument called
> "stitching" that determines whether additional segments are added to
> make the path continuous. By default, stitching is not used. If there
> are any discontinuities, calling some of Path will cause an exception
> to be thrown, which in most cases means a crash.
>
> I want to make stitching mandatory. Since in some cases you want to be
> sure that no stitching happens in your code, there will be an extra
> boolean member variable. When set to true, it will throw an exception
> whenever you try to insert a discontinuity into the path.
>
> Is everyone OK with this idea?

I am not so sure about this.
It may not be very helpful if 2geom automatically fixes "user errors", 
leading to unexpected results. If you change the default behavior (from 
not stitching to stitching), user code will suddenly behave different 
perhaps without the user knowing (e.g. no compiler error).
How about making the _choice_ for stitching behavior mandatory?

-Johan

Re: [Lib2geom-devel] Mandatory path stitching

[Krzysztof K. <twe...@gm...>]

2015-03-27 21:00 GMT+01:00 Nathan Hurst <nj...@nj...>:
> I'm ok with this idea (indeed I thought it was already true).  It is
> useful (as you know) to have the ability to represent a collection of
> segments for some algorithms.  But I think that would be better
> modelled as a colleciton of Path (e.g. PathVector).

boost::ptr_vector<Curve>, the underlying container of Path, would be
adequate for representing arbitrary collections of segments.

Regards, Krzysztof

Re: [Lib2geom-devel] tangent to curve

[Nathan H. <nj...@nj...>]

On Fri, Mar 27, 2015 at 01:36:14PM +0100, Tavmjong Bah wrote:
> 
> Hi,
> 
> It seems that the tangent at a beginning of a curve can flip sign with
> slight changes to the curve (as returned by unitTangentAt()). Is this a
> known problem? There is a comment that the tangent at the end of a line
> can be wrong but nothing to indicate that the tangent at the beginning
> can be wrong. This appears to be the cause of mis-drawn line joins.

I looked into this this morning, I couldn't see any obvious bugs, do
you have a unit test sized reproducing example?  The fact that it's at
the endpoints makes me suspect Piecewise rather than the differential
geometry part.

njh

Re: [Lib2geom-devel] Mandatory path stitching

[Nathan H. <nj...@nj...>]

I'm ok with this idea (indeed I thought it was already true).  It is
useful (as you know) to have the ability to represent a collection of
segments for some algorithms.  But I think that would be better
modelled as a colleciton of Path (e.g. PathVector).

njh

On Fri, Mar 27, 2015 at 08:48:15PM +0100, Krzysztof Kosiński wrote:
> Every method that modifies a Path has an optional argument called
> "stitching" that determines whether additional segments are added to
> make the path continuous. By default, stitching is not used. If there
> are any discontinuities, calling some of Path will cause an exception
> to be thrown, which in most cases means a crash.
> 
> I want to make stitching mandatory. Since in some cases you want to be
> sure that no stitching happens in your code, there will be an extra
> boolean member variable. When set to true, it will throw an exception
> whenever you try to insert a discontinuity into the path.
> 
> Is everyone OK with this idea?
> 
> Regards, Krzysztof
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

[Lib2geom-devel] Mandatory path stitching

[Krzysztof K. <twe...@gm...>]

Every method that modifies a Path has an optional argument called
"stitching" that determines whether additional segments are added to
make the path continuous. By default, stitching is not used. If there
are any discontinuities, calling some of Path will cause an exception
to be thrown, which in most cases means a crash.

I want to make stitching mandatory. Since in some cases you want to be
sure that no stitching happens in your code, there will be an extra
boolean member variable. When set to true, it will throw an exception
whenever you try to insert a discontinuity into the path.

Is everyone OK with this idea?

Regards, Krzysztof

[Lib2geom-devel] tangent to curve

[Tavmjong B. <tav...@fr...>]

Hi,

It seems that the tangent at a beginning of a curve can flip sign with
slight changes to the curve (as returned by unitTangentAt()). Is this a
known problem? There is a comment that the tangent at the end of a line
can be wrong but nothing to indicate that the tangent at the beginning
can be wrong. This appears to be the cause of mis-drawn line joins.

Tav

[Lib2geom-devel] 2Geom_trunk_unittests - Build # 10 - Still Failing!

[Jenkins (b. tester) <ink...@gm...>]

Hi developers,
  I found a problem with one of the builds:
2Geom_trunk_unittests - Build # 10 - Still Failing:

Check console output at http://jenkins.inkscape.org/job/2Geom_trunk_unittests/10/ to view the results.

Your friend,
  Jenkins
  http://jenkins.inkscape.org

[Lib2geom-devel] 2Geom_trunk_unittests - Build # 9 - Still Failing!

[Jenkins (b. tester) <ink...@gm...>]

Hi developers,
  I found a problem with one of the builds:
2Geom_trunk_unittests - Build # 9 - Still Failing:

Check console output at http://jenkins.inkscape.org/job/2Geom_trunk_unittests/9/ to view the results.

Your friend,
  Jenkins
  http://jenkins.inkscape.org

[Lib2geom-devel] 2Geom_trunk_unittests - Build # 8 - Still Failing!

[Jenkins (b. tester) <ink...@gm...>]

Hi developers,
  I found a problem with one of the builds:
2Geom_trunk_unittests - Build # 8 - Still Failing:

Check console output at http://jenkins.inkscape.org/job/2Geom_trunk_unittests/8/ to view the results.

Your friend,
  Jenkins
  http://jenkins.inkscape.org

Re: [Lib2geom-devel] 2Geom_trunk_unittests - Build # 7 - Failure!

[Krzysztof K. <twe...@gm...>]

To other developers:

This failure is because I added some Bezier intersection tests which
uncovered a bug in the Bezier clipping routine, which will sometimes
report the same intersection twice. The bug is triggered by an
intersection at exactly 0.5 for two identical radially symmetrical
curves, with one of them rotated around the symmetry point by 90
degrees - Example 2 from Dieter Lasser's paper on self-intersection of
Bezier curves:
https://archive.org/stream/calculatingselfi00lass#page/10/mode/2up

Regards, Krzysztof

2015-03-22 9:24 GMT+01:00 Jenkins (build tester) <ink...@gm...>:
> Hi developers,
>   I found a problem with one of the builds:
> 2Geom_trunk_unittests - Build # 7 - Failure:
>
> Check console output at http://jenkins.inkscape.org/job/2Geom_trunk_unittests/7/ to view the results.
>
> Your friend,
>   Jenkins
>   http://jenkins.inkscape.org
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>

[Lib2geom-devel] 2Geom_trunk_unittests - Build # 7 - Failure!

[Jenkins (b. tester) <ink...@gm...>]

Hi developers,
  I found a problem with one of the builds:
2Geom_trunk_unittests - Build # 7 - Failure:

Check console output at http://jenkins.inkscape.org/job/2Geom_trunk_unittests/7/ to view the results.

Your friend,
  Jenkins
  http://jenkins.inkscape.org

Re: [Lib2geom-devel] [Inkscape-devel] time to sync with lib2geom?

[Krzysztof K. <twe...@gm...>]

2015-03-15 3:15 GMT+01:00 Nathan Hurst <nj...@nj...>:
> Awesome Krzysztof!
>
> I'll certainly review it for you if you want.
>
> njh
>

The rough design:

1. intersect() will return a vector of structures that look like this:

struct Intersection {
   Shape const &_a;
   Shape const &_b;
   double _ta;
   double _tb;
   ...
   Point position() const;
};

It could also return a structure that contains a vector of pairs of
intersection times, but I think that would ultimately be less
convenient.

2. position() will average the results from pointAt() evaluated on both shapes.

3. New overloads of portion() will accept the intersection information
described above and adjust the endpoints of computed portions so that
they match exactly with position()

4. Optionally: A new base class called Shape will be added. Things
like Ellipse, Curve, Line and so on will derive from it. This class
will expose a function interface, with methods such as pointAt(),
domain(), intersect(). There might also be something called
BoundedShape which will have a conversion to Path.

Rect and Circle are not closed under affine transforms, so they would
probably remain primitives rather than shapes.

> On Sun, Mar 15, 2015 at 01:57:31AM +0100, Krzysztof Kosiński wrote:
>> 2Geom sync would be a good idea.
>>
>> I want to introduce a new generic intersection API (I started working
>> on it today), which may require some changes, but shouldn't cause any
>> major API breaks.
>>
>> The main thing that will have to be changed in Inkscape is the
>> renaming of nearestPoint() and similar methods to nearestTime().
>>
>> Regards, Krzysztof
>>
>> 2015-03-15 0:25 GMT+01:00 alvinpenner <pe...@va...>:
>> > there have been a number of changes made in lib2geom in the last 4 months or
>> > so, would this be a good time to sync again?
>> >
>> > Alvin
>> >
>> >
>> >
>> > --
>> > View this message in context: http://inkscape.13.x6.nabble.com/time-to-sync-with-lib2geom-tp4973183.html
>> > Sent from the Inkscape - Dev mailing list archive at Nabble.com.
>> >
>> > ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your hub for all
>> > things parallel software development, from weekly thought leadership blogs to
>> > news, videos, case studies, tutorials and more. Take a look and join the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Inkscape-devel mailing list
>> > Ink...@li...
>> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Inkscape-devel mailing list
>> Ink...@li...
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Re: [Lib2geom-devel] Trunk access

[Krzysztof K. <twe...@gm...>]

Sounds OK to me, since Inkscape is the primary user of lib2geom.

Regards, Krzysztof

2015-03-01 18:45 GMT+01:00 Johan Engelen <jbc...@sw...>:
> Hi all,
>    I have added the group "Inkscape Developers" (inkscape.dev) to the
> members group of 2geom hackers, so that they have commit access to 2geom
> too and can help improve the library
> If you do not agree with this, let me know and I will revert the change.
>
> regards,
>    Johan
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

[Lib2geom-devel] Trunk access

[Johan E. <jbc...@sw...>]

Hi all,
   I have added the group "Inkscape Developers" (inkscape.dev) to the 
members group of 2geom hackers, so that they have commit access to 2geom 
too and can help improve the library
If you do not agree with this, let me know and I will revert the change.

regards,
   Johan

[Lib2geom-devel] Fwd: [Inkscape-devel] IRC meeting: Jenkins

[Johan E. <jbc...@sw...>]

Hi guys,
   Hope one of you can join too. (see mail below)

-Johan


-------- Forwarded Message --------
Subject: 	[Inkscape-devel] IRC meeting: Jenkins
Date: 	Sat, 14 Feb 2015 17:00:20 +0100
From: 	Johan Engelen <jbc...@sw...>
To: 	Inkscape-Devel <ink...@li...>



Hi all,
   Whoever is interested in Jenkins / testing Inkscape: let's schedule a
meeting on IRC, so I can explain what I've set up and how you can use
the testing system, help improve things and maintain the testing system.

How about Wednesday at 19:00 UTC ?

cheers,
    Johan

[Lib2geom-devel] Jenkins

[Johan E. <jbc...@sw...>]

Hi all,
   jenkins.inkscape.org is up and running well.
For 2Geom trunk, it is doing a clang scanbuild for us, a doxygen, and 
unit tests.

The doxygen output is hosted here:
http://jenkins.inkscape.org/job/2Geom_trunk_doxygen/doxygen/

On any failure, I've set Jenkins to report to lib2geom-devel@...

Does anybody of you want to help out with Jenkins maintenance / job 
improvements? Sign up to Jenkins and I will give you the rights to do so.

Cheers,
   Johan

Re: [Lib2geom-devel] Arc-Bezier intersections

[Nathan H. <nj...@nj...>]

For circular arcs you can use (X-centre)**2 - r**2 = 0 to form a 1d
function and solve with roots.  For ellipses there is an equivalent
xAx=0 quadratic form (there is code to convert parametric arcs to QF
somewhere.  It's not immediately clear to me which will be faster.

njh

On Mon, Jan 19, 2015 at 02:28:18PM +0100, Krzysztof Kosiński wrote:
> Is there any clever algorithm that I can use to compute intersections
> between Beziers and arcs? Or should I just convert the arc to a high
> degree Bezier or a Bezier spline and use the standard Bezier clipping
> algorithm?
> 
> Regards, Krzysztof
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel