lib2geom-devel — development discussion

Re: [Lib2geom-devel] Dropping invalid arc segments in parser

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

On Tue, 2014-08-05 at 20:46 +0200, Johan Engelen wrote:
> Hi all,
>   Liam just committed a bug fix to Inkscape trunk, regarding our SVG
> parser.
> 
> SVG spec says:
> "If the endpoints (x1, y1) and (x2, y2) are identical, then this is
> equivalent to omitting the elliptical arc segment entirely." [1]
> 
> Liam changed the parser so that it will simply drop such segments:
> 
>     void _arcTo(double rx, double ry, double angle,
>                 bool large_arc, bool sweep, Point p)
>     {
> +        if (_current == p) {  // sic, probably should be
> are_near(_current, p)
> 
> +            return;
> +        }
>         _quad_tangent = _cubic_tangent = _current = p;
>         _sink.arcTo(rx, ry, angle, large_arc, sweep, p);
>     }


> I am not sure about this change. We are not dropping any degenerate
> bezier segments in our parser.

I think this is not the same as a degenerate bezier. This describes an
ellipse with given major and minor axis but there is no way to figure
out where along the ellipse one should start drawing. The following path
consists of four very different (almost complete) ellipses where the
final points are just a little bit different from the starting points:

    <path d="m 50,50
	     a 20 30 45 1 0 1,1
	       20 30 45 1 0 -1,-1
	       20 30 45 1 0 -1,1
	       20 30 45 1 0 1,-1"
	  style="fill:none;stroke:black"/>

Tav

[Lib2geom-devel] Dropping invalid arc segments in parser

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

Hi all,
   Liam just committed a bug fix to Inkscape trunk, regarding our SVG 
parser.

SVG spec says:
"If the endpoints (x1, y1) and (x2, y2) are identical, then this is 
equivalent to omitting the elliptical arc segment entirely." [1]

Liam changed the parser so that it will simply drop such segments:

     void _arcTo(double rx, double ry, double angle,
bool large_arc, bool sweep, Point p)
     {
+        if (_current == p) {  // sic, probably should be 
are_near(_current, p)
+            return;
+        }
_quad_tangent = _cubic_tangent = _current = p;
_sink.arcTo(rx, ry, angle, large_arc, sweep, p);
     }

I am not sure about this change. We are not dropping any degenerate 
bezier segments in our parser.

Thanks for input,
   Johan





[1] http://www.w3.org/TR/SVG/implnote.html#ArcImplementationNotes 
<http://www.w3.org/TR/SVG/implnote.html#ArcImplementationNotes>

Re: [Lib2geom-devel] allNearestTimes()

[Diederik v. L. <ma...@di...>]

Hi guys,

Sorry for not responding earlier, but I've been a bit too busy lately.

The snapping mechanism only relies on one nearest point being returned for
every path in a pathvector. I believe that allNearestPoints() in
pathVector.cpp is mine. Other than that, I believe that Krzysztof's
proposal makes sense, but admittedly I've never looked at the other
allNearestPoints() methods. Those are the ones that Krzysztof is reffering
to.

Diederik


On Sat, Jul 19, 2014 at 4:42 PM, Johan Engelen <jbc...@sw...>
wrote:

> Hi Krzysz, Diederik,
> Seems to make sense.
> You may want to discuss this with someone who (I think) uses this method a
> lot for snapping: Diederik.
>
> Any objections Diederik?
>
> -Johan
>
>
> On 19-7-2014 2:40, Krzysztof Kosiński wrote:
>
>> This method is a little pointless, because it will return more than
>> one point only if they are at exactly the same distance. Due to
>> limited precision of doubles, this will only happen in very specific
>> circumstances - basically only if someone deliberately constructs the
>> object and the point with carefully chosen values. It's nearly
>> impossible to get more than one result by manipulating shapes on the
>> screen. Therefore arbitrarily picking one of the points doesn't change
>> much.
>>
>> It would be more useful if the method accepted a tolerance parameter
>> and returned the local minima of each subset of the shape not further
>> than this tolerance from the true nearest time. The attached image
>> explains this.
>>
>> Regards, Krzysztof
>>
>

Re: [Lib2geom-devel] Using std::auto_ptr in Curve

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

On 26-7-2014 20:33, Nathan Hurst wrote:
> Sounds great, I presume we are waiting on inkscape to switch to C++11?

I think so. After 0.91 is released, I will push hard for requiring C++11.

I think when 0.91 is released, we should also release 2Geom (the version 
that Inkscape is using, not the one with Krzysztof's recent changes). 
That will then be the last 2geom release that does not require C++11.

regards,
   Johan

Re: [Lib2geom-devel] Using std::auto_ptr in Curve

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

Hi Krzysz,
One thing I thought about with these virtual methods that return a 
Curve* is that they can return a DerivedCurve* type (covariant return 
types), so one would can use stronger type information. It's not a large 
gain. But we would lose this with unique_ptr<Curve>.
I think it is good to explicitly express memory ownership in the API 
like you propose. It's a good idea I think, at the minor cost of 
covariant return types.

cheers,
Johan



On 26-7-2014 9:10, Krzysztof Kosiński wrote:
> Hello
>
> There are several virtual methods in Curve which return Curve * (a raw
> pointer). They must return a pointer, because they are defined in the
> base class but return an object of a derived class.
>
> I propose replacing all these returns with std::auto_ptr<Curve>, and
> once we switch to C++11 - with std::unique_ptr<Curve>. This will allow
> us to write things such as curve->portion(0.1, 0.9)->boundsExact(),
> which are currently provided as redundant methods such as
> boundsLocal(). Similarly, the parametrized version of nearestTime()
> could be reimplemented as:
>
> Coord nearest_time_local(Curve const &c, Interval const &i, Point const &p) {
>      return i.nearestTime(c.portion(i)->nearestTime(p));
> }
>
> where Interval::nearestTime() is something I added just now, and defined as:
>
> Coord nearestTime(Coord t) const {
>      if (t < min()) return 0;
>      if (t > max()) return 1;
>      return (t - min()) / extent();
> }
>
> Any objections?
>
> Regards, Krzysztof
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>
>

Re: [Lib2geom-devel] Using std::auto_ptr in Curve

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

Sounds great, I presume we are waiting on inkscape to switch to C++11?

njh

On Sat, Jul 26, 2014 at 09:10:36AM +0200, Krzysztof Kosiński wrote:
> Hello
> 
> There are several virtual methods in Curve which return Curve * (a raw
> pointer). They must return a pointer, because they are defined in the
> base class but return an object of a derived class.
> 
> I propose replacing all these returns with std::auto_ptr<Curve>, and
> once we switch to C++11 - with std::unique_ptr<Curve>. This will allow
> us to write things such as curve->portion(0.1, 0.9)->boundsExact(),
> which are currently provided as redundant methods such as
> boundsLocal(). Similarly, the parametrized version of nearestTime()
> could be reimplemented as:
> 
> Coord nearest_time_local(Curve const &c, Interval const &i, Point const &p) {
>     return i.nearestTime(c.portion(i)->nearestTime(p));
> }
> 
> where Interval::nearestTime() is something I added just now, and defined as:
> 
> Coord nearestTime(Coord t) const {
>     if (t < min()) return 0;
>     if (t > max()) return 1;
>     return (t - min()) / extent();
> }
> 
> Any objections?
> 
> Regards, Krzysztof
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

[Lib2geom-devel] Using std::auto_ptr in Curve

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

Hello

There are several virtual methods in Curve which return Curve * (a raw
pointer). They must return a pointer, because they are defined in the
base class but return an object of a derived class.

I propose replacing all these returns with std::auto_ptr<Curve>, and
once we switch to C++11 - with std::unique_ptr<Curve>. This will allow
us to write things such as curve->portion(0.1, 0.9)->boundsExact(),
which are currently provided as redundant methods such as
boundsLocal(). Similarly, the parametrized version of nearestTime()
could be reimplemented as:

Coord nearest_time_local(Curve const &c, Interval const &i, Point const &p) {
    return i.nearestTime(c.portion(i)->nearestTime(p));
}

where Interval::nearestTime() is something I added just now, and defined as:

Coord nearestTime(Coord t) const {
    if (t < min()) return 0;
    if (t > max()) return 1;
    return (t - min()) / extent();
}

Any objections?

Regards, Krzysztof

Re: [Lib2geom-devel] libdouble-conversion - dependency or in-tree?

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

2014-07-22 6:14 GMT+02:00 Nathan Hurst <nj...@nj...>:
> I think just embed and prune it.  If you note where it came from and
> remove all the unnecessary stuff it should be pretty lightweight - the
> algorithm itself is pretty simple.  I presume the licences are
> compatible?

OK.

The library is under the 3-clause BSD license, so the code can be
incorporated directly.

Regards, Krzysztof

Re: [Lib2geom-devel] size comparison in Affine::inverse()

[Alvin P. <pe...@va...>]

thanks, the change has been committed to rev 2215.

Alvin

Re: [Lib2geom-devel] libdouble-conversion - dependency or in-tree?

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

I think just embed and prune it.  If you note where it came from and
remove all the unnecessary stuff it should be pretty lightweight - the
algorithm itself is pretty simple.  I presume the licences are
compatible?

njh

On Tue, Jul 22, 2014 at 04:54:21AM +0200, Krzysztof Kosiński wrote:
> Hello
> 
> To implement a reasonably good SVG path writer, we need a function
> that converts a double to the shortest string that will parse back to
> the original value. g_ascii_strtod() does not do this. The
> state-of-the-art library for this task is libdouble-conversion; the
> sources take up around 320 kB.
> 
> Can I use this library as dependency, or should I include its sources
> in the 2Geom tree?
> 
> By opting for the latter approach, I could make some tweaks to the
> source, e.g. remove unnecessary functions, change it to work with
> std::string instead of some strange one-off class and correct some
> configuration mistakes; for example, the library always assumes that
> 32-bit Linux suffers from double rounding, aka GCC bug 323, whereas
> it's sufficient to compile with -mfpmath=sse and the problem goes
> away. On the other hand, in-tree libraries are not a good practice in
> general.
> 
> Regards, Krzysztof
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

[Lib2geom-devel] libdouble-conversion - dependency or in-tree?

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

Hello

To implement a reasonably good SVG path writer, we need a function
that converts a double to the shortest string that will parse back to
the original value. g_ascii_strtod() does not do this. The
state-of-the-art library for this task is libdouble-conversion; the
sources take up around 320 kB.

Can I use this library as dependency, or should I include its sources
in the 2Geom tree?

By opting for the latter approach, I could make some tweaks to the
source, e.g. remove unnecessary functions, change it to work with
std::string instead of some strange one-off class and correct some
configuration mistakes; for example, the library always assumes that
32-bit Linux suffers from double rounding, aka GCC bug 323, whereas
it's sufficient to compile with -mfpmath=sse and the problem goes
away. On the other hand, in-tree libraries are not a good practice in
general.

Regards, Krzysztof

Re: [Lib2geom-devel] size comparison in Affine::inverse()

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

Oh right, yeah, Alvin's absolutely(relatively?) right.  You get a
ship-it/lgtm from me.

njh

On Mon, Jul 21, 2014 at 11:22:49PM +0200, Johan Engelen wrote:
> Hi Nathan, Alvin,
>    I was also confused a bit at first, but:
> inline bool rel_error_bound(Coord a, Coord b, double eps=EPSILON) { return a <= eps*b && a >= -eps*b; }
> 
> So the fix with sqrt does do a different check.
> 
> hth
> regards,
>    Johan
> 
> On 21-7-2014 23:08, Nathan Hurst wrote:
> > Does it fix the bug?  I don't understand because those two algorithms
> > are almost equivalent (there is a slight shift in the bounds due to
> > nonlinearity).  In this case det should be 0.150, which is a long way
> > from singular.  What is mx in this case?
> >
> > njh
> >
> > On Mon, Jul 21, 2014 at 03:56:48PM -0400, Alvin Penner wrote:
> >> while investigating LP Bug 1231990,
> >> https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that
> >> the routine Affine::inverse() in the file affine.cpp is apparently
> >> refusing to calculate the inverse of the following matrix:
> >>
> >> 0.001,    0.0
> >> 0.0,    150.0
> >>
> >> The refusal is coming from the line:
> >> if (!rel_error_bound(determ, mx*mx))
> >>
> >> I would like to propose that this be changed to:
> >> if (!rel_error_bound(std::sqrt(fabs(determ)), mx))
> >> so that we would be comparing two numbers which both have units of
> >> length. This would be similar to a change was made in rev 2183, where
> >> a similar size comparison problem was encountered (LP Bug 1309225).
> >>
> >> Any comments?
> >>
> >> Cheers,
> >> Alvin
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Want fast and easy access to all the code in your enterprise? Index and
> >> search up to 200,000 lines of code with a free copy of Black Duck
> >> Code Sight - the same software that powers the world's largest code
> >> search on Ohloh, the Black Duck Open Hub! Try it now.
> >> http://p.sf.net/sfu/bds
> >> _______________________________________________
> >> Lib2geom-devel mailing list
> >> Lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> > ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > Lib2geom-devel mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> >
> >
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

Re: [Lib2geom-devel] size comparison in Affine::inverse()

[Alvin P. <pe...@va...>]

yes, I guess I should have specified. Originally we had mx = 150, 
determ = 0.15, mx*mx/determ = 150,000, which is larger than 1E5, so 
it fails. After taking the square root, it will pass.

Alvin

Re: [Lib2geom-devel] size comparison in Affine::inverse()

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

Hi Nathan, Alvin,
   I was also confused a bit at first, but:
inline bool rel_error_bound(Coord a, Coord b, double eps=EPSILON) { return a <= eps*b && a >= -eps*b; }

So the fix with sqrt does do a different check.

hth
regards,
   Johan

On 21-7-2014 23:08, Nathan Hurst wrote:
> Does it fix the bug?  I don't understand because those two algorithms
> are almost equivalent (there is a slight shift in the bounds due to
> nonlinearity).  In this case det should be 0.150, which is a long way
> from singular.  What is mx in this case?
>
> njh
>
> On Mon, Jul 21, 2014 at 03:56:48PM -0400, Alvin Penner wrote:
>> while investigating LP Bug 1231990,
>> https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that
>> the routine Affine::inverse() in the file affine.cpp is apparently
>> refusing to calculate the inverse of the following matrix:
>>
>> 0.001,    0.0
>> 0.0,    150.0
>>
>> The refusal is coming from the line:
>> if (!rel_error_bound(determ, mx*mx))
>>
>> I would like to propose that this be changed to:
>> if (!rel_error_bound(std::sqrt(fabs(determ)), mx))
>> so that we would be comparing two numbers which both have units of
>> length. This would be similar to a change was made in rev 2183, where
>> a similar size comparison problem was encountered (LP Bug 1309225).
>>
>> Any comments?
>>
>> Cheers,
>> Alvin
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Lib2geom-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>
>

Re: [Lib2geom-devel] size comparison in Affine::inverse()

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

Does it fix the bug?  I don't understand because those two algorithms
are almost equivalent (there is a slight shift in the bounds due to
nonlinearity).  In this case det should be 0.150, which is a long way
from singular.  What is mx in this case?

njh

On Mon, Jul 21, 2014 at 03:56:48PM -0400, Alvin Penner wrote:
> while investigating LP Bug 1231990, 
> https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that 
> the routine Affine::inverse() in the file affine.cpp is apparently 
> refusing to calculate the inverse of the following matrix:
> 
> 0.001,    0.0
> 0.0,    150.0
> 
> The refusal is coming from the line:
> if (!rel_error_bound(determ, mx*mx))
> 
> I would like to propose that this be changed to:
> if (!rel_error_bound(std::sqrt(fabs(determ)), mx))
> so that we would be comparing two numbers which both have units of 
> length. This would be similar to a change was made in rev 2183, where 
> a similar size comparison problem was encountered (LP Bug 1309225).
> 
> Any comments?
> 
> Cheers,
> Alvin
> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

[Lib2geom-devel] size comparison in Affine::inverse()

[Alvin P. <pe...@va...>]

while investigating LP Bug 1231990, 
https://bugs.launchpad.net/inkscape/+bug/1231990, it was found that 
the routine Affine::inverse() in the file affine.cpp is apparently 
refusing to calculate the inverse of the following matrix:

0.001,    0.0
0.0,    150.0

The refusal is coming from the line:
if (!rel_error_bound(determ, mx*mx))

I would like to propose that this be changed to:
if (!rel_error_bound(std::sqrt(fabs(determ)), mx))
so that we would be comparing two numbers which both have units of 
length. This would be similar to a change was made in rev 2183, where 
a similar size comparison problem was encountered (LP Bug 1309225).

Any comments?

Cheers,
Alvin

Re: [Lib2geom-devel] Path and Curve API cleanups

[Jabiertxo A. C. <jab...@ma...>]

OK, Is what i undertand.
Thanks for the reply.
Jabier.

El dom, 20-07-2014 a las 06:15 +0200, Krzysztof Kosiński escribió:
> 2014-07-19 23:17 GMT+02:00 Jabiertxo Arraiza Cenoz <jab...@ma...>:
> >
> >> 2. I will also remove the last two parameters from
> >> Curve::nearestTime() that specify the minimum and maximum considered
> >> time values. Code that requires this should just use portion(), and it
> >> seems this isn't used anywhere in Inkscape. The only place that uses
> >> this functionality is the HVLineSegment toy.
> >
> > Hi, Im using portion in my fillet-chamfer LPE.
> 
> My post was about removing the extra parameters in nearestTime(),
> formerly nearestPoint(). portion() will not be removed.
> 
> Regards, Krzysztof

Re: [Lib2geom-devel] Path and Curve API cleanups

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

2014-07-19 23:17 GMT+02:00 Jabiertxo Arraiza Cenoz <jab...@ma...>:
>
>> 2. I will also remove the last two parameters from
>> Curve::nearestTime() that specify the minimum and maximum considered
>> time values. Code that requires this should just use portion(), and it
>> seems this isn't used anywhere in Inkscape. The only place that uses
>> this functionality is the HVLineSegment toy.
>
> Hi, Im using portion in my fillet-chamfer LPE.

My post was about removing the extra parameters in nearestTime(),
formerly nearestPoint(). portion() will not be removed.

Regards, Krzysztof

Re: [Lib2geom-devel] Closing segment in Path

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

2014-07-20 2:33 GMT+02:00 Nathan Hurst <nj...@nj...>:
> Sounds good, does it close the closed path bug you found earlier?

It will, once I write a new path data writer that closes the path
exactly regardless of precision. I have committed a basic
implementation, but it makes no effort to optimize the length of the
resulting string. It also turns out that the C++ standard library and
Glib's g_ascii_dtostr() routines are not very good and often write out
far more digits than necessary for a correct roundtrip, so I'll
probably have to write our own double-formatting code that implements
the Grisu2 algorithm.

Regards, Krzysztof

Re: [Lib2geom-devel] Closing segment in Path

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

Sounds good, does it close the closed path bug you found earlier?

njh

On Fri, Jul 18, 2014 at 10:43:40PM +0200, Krzysztof Kosiński wrote:
> Hello
> 
> Right now, methods such as end_closed() and end_open() determine which
> segments to include only by looking at the closed flag. However, this
> makes little sense - if the path contains a closing segment which is
> degenerate, i.e. has exactly zero length, because the last real
> segment is a Bezier curve, the iteration will needlessly include it.
> 
> In order to be able to faithfully represent closed paths where the
> last segment is not linear, the closing segment should be included in
> the range returned by [begin(), end_default()] only when: 1. the path
> is closed, 2. the closing segment is non-degenerate (initialPoint() !=
> finalPoint(), tested with exact comparison).
> 
> By doing this and using an SVG path data writer that writes out the
> last non-linear segment in absolute coordinates when it closes the
> path, we can have perfect roundtrip between 2Geom paths and SVG.
> 
> What do you think of this change?
> 
> Regards, Krzysztof
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

Re: [Lib2geom-devel] allNearestTimes()

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

Hi Krzysztof,
I agree with everything you've said.  For the epsilon version you
pretty much just need to call multiroots on the distance polynomial to
get the intervals once you've identified a global minimum, then solve
for each separately:

best = roots(dd);
...
lsqr = dd(best)
sqr = dot(c-p, c-p)-(lsqr+2*eps);  // slightly inaccurate hack to
avoid sqrt of polynomial

portions = roots(sqr) // is there a ranged version of roots?

// minimise inside each portion.

nearest_point(c.portion(portions[i]));


There may be a more efficient way to do this, let's implement a simple
and clean version and reassess if it comes up in profiling.

njh

On Sat, Jul 19, 2014 at 02:40:30AM +0200, Krzysztof Kosiński wrote:
> This method is a little pointless, because it will return more than
> one point only if they are at exactly the same distance. Due to
> limited precision of doubles, this will only happen in very specific
> circumstances - basically only if someone deliberately constructs the
> object and the point with carefully chosen values. It's nearly
> impossible to get more than one result by manipulating shapes on the
> screen. Therefore arbitrarily picking one of the points doesn't change
> much.
> 
> It would be more useful if the method accepted a tolerance parameter
> and returned the local minima of each subset of the shape not further
> than this tolerance from the true nearest time. The attached image
> explains this.
> 
> Regards, Krzysztof


> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds

> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

[Lib2geom-devel] Path and Curve API cleanups

[Jabiertxo A. C. <jab...@ma...>]

> 2. I will also remove the last two parameters from
> Curve::nearestTime() that specify the minimum and maximum considered
> time values. Code that requires this should just use portion(), and it
> seems this isn't used anywhere in Inkscape. The only place that uses
> this functionality is the HVLineSegment toy.

Hi, Im using portion in my fillet-chamfer LPE.

Regards, Jabier.

Re: [Lib2geom-devel] allNearestTimes()

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

Hi Krzysz, Diederik,
Seems to make sense.
You may want to discuss this with someone who (I think) uses this method 
a lot for snapping: Diederik.

Any objections Diederik?

-Johan


On 19-7-2014 2:40, Krzysztof Kosiński wrote:
> This method is a little pointless, because it will return more than
> one point only if they are at exactly the same distance. Due to
> limited precision of doubles, this will only happen in very specific
> circumstances - basically only if someone deliberately constructs the
> object and the point with carefully chosen values. It's nearly
> impossible to get more than one result by manipulating shapes on the
> screen. Therefore arbitrarily picking one of the points doesn't change
> much.
>
> It would be more useful if the method accepted a tolerance parameter
> and returned the local minima of each subset of the shape not further
> than this tolerance from the true nearest time. The attached image
> explains this.
>
> Regards, Krzysztof

Re: [Lib2geom-devel] Closing segment in Path

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

Hi Krzysz,
This sounds like a good idea, simplifying the user's life.

regards,
Johan

On 18-7-2014 22:43, Krzysztof Kosiński wrote:
> Hello
>
> Right now, methods such as end_closed() and end_open() determine which
> segments to include only by looking at the closed flag. However, this
> makes little sense - if the path contains a closing segment which is
> degenerate, i.e. has exactly zero length, because the last real
> segment is a Bezier curve, the iteration will needlessly include it.
>
> In order to be able to faithfully represent closed paths where the
> last segment is not linear, the closing segment should be included in
> the range returned by [begin(), end_default()] only when: 1. the path
> is closed, 2. the closing segment is non-degenerate (initialPoint() !=
> finalPoint(), tested with exact comparison).
>
> By doing this and using an SVG path data writer that writes out the
> last non-linear segment in absolute coordinates when it closes the
> path, we can have perfect roundtrip between 2Geom paths and SVG.
>
> What do you think of this change?
>
> Regards, Krzysztof

[Lib2geom-devel] allNearestTimes()

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

This method is a little pointless, because it will return more than
one point only if they are at exactly the same distance. Due to
limited precision of doubles, this will only happen in very specific
circumstances - basically only if someone deliberately constructs the
object and the point with carefully chosen values. It's nearly
impossible to get more than one result by manipulating shapes on the
screen. Therefore arbitrarily picking one of the points doesn't change
much.

It would be more useful if the method accepted a tolerance parameter
and returned the local minima of each subset of the shape not further
than this tolerance from the true nearest time. The attached image
explains this.

Regards, Krzysztof