this is just an attempt to bump the priority of https://bugs.launchpad.net/inkscape/+bug/259237 and http://sourceforge.net/mailarchive/forum.php?thread_name=op.uf6b2ds4a8nfnl%4...
as far as I can tell, the windows nightly builds have not worked since Aug 16. Using the Aug 21 download, the most recent timestamp that I can see on any files is 08/16/2008 02:49 PM 14,671,360 inkscape.exe
part of my reason for posting this is because there is a possibility that I may have caused this, since I did a commit on that day, svn 19670, for the first time, and I'm afraid I may have done it wrong.
Yesterday I compiled latest SVN on WinXP and it does not crash on start for me, although the downloaded modevia builds did crash (although on another machine)...
as far as I can tell, a patch was done on Aug 17 to solve bug 258761 https://bugs.launchpad.net/inkscape/+bug/258761 . This was a crash in rev 19671, fixed in rev 19673.
I don't think this fix is present in the nightly win32 builds, at least not according to the dates on the files, but can't figure out why not. Will try out the latest build tonight.
On Fri, Aug 22, 2008 at 1:56 PM, Alvin Penner <penner@...1856...> wrote:
as far as I can tell, a patch was done on Aug 17 to solve bug 258761 https://bugs.launchpad.net/inkscape/+bug/258761 . This was a crash in rev 19671, fixed in rev 19673.
Aha, so it didn't crash for me because I compiled 19743.
I urge the 2geom developers to please look into this and fix this "properly".
Also I'd like to remind them that we still have unsolved "non-continuous path" asserts. For example the crash when loading our own current about.svg:
glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: lib2geom exception: Non-contiguous path (2geom/path.cpp:88)
This has been broken for too long, it discourages people who try to use SVN builds for testing. Myself, I somehow put up with the unstability most of the time, but from time to time I also have to go back to an old build to finish some work. Please fix this ASAP!
Okay okay... :P I'll look into it asap when i get back, actually forgot about it...
It'll have to wait until I get back from vacation though.. (1 sept)
Cheers, Johan
________________________________
From: bulia byak [mailto:buliabyak@...400...] Sent: Fri 22/08/2008 19:10 To: Alvin Penner; Engelen, J.B.C. (Johan); MenTaLguY Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
On Fri, Aug 22, 2008 at 1:56 PM, Alvin Penner <penner@...1856...> wrote:
as far as I can tell, a patch was done on Aug 17 to solve bug 258761 https://bugs.launchpad.net/inkscape/+bug/258761 https://bugs.launchpad.net/inkscape/+bug/258761 . This was a crash in rev 19671, fixed in rev 19673.
Aha, so it didn't crash for me because I compiled 19743.
I urge the 2geom developers to please look into this and fix this "properly".
Also I'd like to remind them that we still have unsolved "non-continuous path" asserts. For example the crash when loading our own current about.svg:
glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: lib2geom exception: Non-contiguous path (2geom/path.cpp:88)
This has been broken for too long, it discourages people who try to use SVN builds for testing. Myself, I somehow put up with the unstability most of the time, but from time to time I also have to go back to an old build to finish some work. Please fix this ASAP!
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org http://www.inkscape.org/
yes!! - the file Inkscape19743-0808220239.7z starts up normally with no problems, life is good again - thanks for the update!
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: vrijdag 22 augustus 2008 19:11 To: Alvin Penner; Engelen, J.B.C. (Johan); MenTaLguY Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
On Fri, Aug 22, 2008 at 1:56 PM, Alvin Penner <penner@...1856...> wrote:
as far as I can tell, a patch was done on Aug 17 to solve bug 258761 https://bugs.launchpad.net/inkscape/+bug/258761 . This was a crash in rev 19671, fixed in rev 19673.
Aha, so it didn't crash for me because I compiled 19743.
I urge the 2geom developers to please look into this and fix this "properly".
It was fixed properly. I broke things with a somewhat strange change, then went on vacation, sorry for that.
Also I'd like to remind them that we still have unsolved "non-continuous path" asserts. For example the crash when loading our own current about.svg:
glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: lib2geom exception: Non-contiguous path (2geom/path.cpp:88)
This has been broken for too long, it discourages people who try to use SVN builds for testing. Myself, I somehow put up with the unstability most of the time, but from time to time I also have to go back to an old build to finish some work. Please fix this ASAP!
The about screen does not crash for me, can you point me to another SVG where it happens?
-Johan
J.B.C.Engelen wrote:
can you point me to another SVG where it happens?
- running Win32 Inkscape19763-0808291650.7z - the attached file crashes with the message : http://www.nabble.com/file/p19237076/about.svg about.svg
terminate called after throwing an instance of 'Geom::ContinuityError' what(): lib2geom exception: Non-contiguous path (src/2geom/path.cpp:88)
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Alvin Penner Sent: zaterdag 30 augustus 2008 22:57 To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
- running Win32 Inkscape19763-0808291650.7z
- the attached file crashes with the message :
http://www.nabble.com/file/p19237076/about.svg about.svg
terminate called after throwing an instance of 'Geom::ContinuityError' what(): lib2geom exception: Non-contiguous path (src/2geom/path.cpp:88)
Investigation showed the following inequality throws the exception:
(136.653830 , -638.496893) == (136.653830 , -638.496893)
which in hex looks like:
(406114EC2CAB84D2 , C083F3F9A32A10A6) == (406114EC2CAB84D2 , C083F3F9A32A10A7)
This stems from a difference in curvetype I think... (the last two curves in the loop before the exception being "N4Geom11BezierCurveILj1EEE" and "N4Geom11SBasisCurveE"). Apparently the endpoints and transformed slightly different for sbasiscurves.
As a temporary fix I did the following. 2geom is not able to maintain SVGElliptical arcs after a transform; they are converted to SBasisCurves. To fix the crash in the method "LoadPathVector" (converting 2geom paths to livarot paths), I now convert the 2geom path to a 2geom path with only bezier curves when a transform should be applied. Note that this is a temporary work around!!
-Johan
J.B.C.Engelen wrote:
I now convert the 2geom path to a 2geom path with only bezier curves when a transform should be applied.
thanks, I'll check it out on Tuesday night, don't have access to highspeed at the moment. Alvin
J.B.C.Engelen wrote:
Investigation showed the following inequality throws the exception:
(136.653830 , -638.496893) == (136.653830 , -638.496893)
which in hex looks like:
(406114EC2CAB84D2 , C083F3F9A32A10A6) == (406114EC2CAB84D2 , C083F3F9A32A10A7)
would it not be desirable to (instead) put some tolerance for round-off error into the 2geom routine, since the difference between these two points is clearly negligible ?
On Sun, Aug 31, 2008 at 2:24 PM, Alvin Penner <penner@...1856...> wrote:
Investigation showed the following inequality throws the exception:
(136.653830 , -638.496893) == (136.653830 , -638.496893)
which in hex looks like:
(406114EC2CAB84D2 , C083F3F9A32A10A6) == (406114EC2CAB84D2 , C083F3F9A32A10A7)
would it not be desirable to (instead) put some tolerance for round-off error into the 2geom routine, since the difference between these two points is clearly negligible ?
I second that. It's never a good idea to test two floating point numbers for equality. You should always have an epsilon to account for rounding errors.
bulia byak wrote:
On Sun, Aug 31, 2008 at 2:24 PM, Alvin Penner<penner@...1856...> wrote:
Investigation showed the following inequality throws the exception:
(136.653830 , -638.496893) == (136.653830 , -638.496893)
which in hex looks like:
(406114EC2CAB84D2 , C083F3F9A32A10A6) == (406114EC2CAB84D2 , C083F3F9A32A10A7)
would it not be desirable to (instead) put some tolerance for round-off error into the 2geom routine, since the difference between these two points is clearly negligible ?
I second that. It's never a good idea to test two floating point numbers for equality. You should always have an epsilon to account for rounding errors.
Yes, even though == works in a lot of cases, people should never trust it.
I noticed in point.h, == is overloaded like this:
inline bool operator==(Point const &a, Point const &b) { return (a[X] == b[X]) && (a[Y] == b[Y]); }
This should be "abs(a-b) < epsilon", however, maybe nathan has a faster way.
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Bob Jamison Sent: maandag 1 september 2008 6:40 To: bulia byak; inkscape Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
bulia byak wrote:
On Sun, Aug 31, 2008 at 2:24 PM, Alvin
Penner<penner@...1856...> wrote:
Investigation showed the following inequality throws the
exception:
(136.653830 , -638.496893) == (136.653830 , -638.496893)
which in hex looks like:
(406114EC2CAB84D2 , C083F3F9A32A10A6) == (406114EC2CAB84D2 , C083F3F9A32A10A7)
would it not be desirable to (instead) put some tolerance for round-off error into the 2geom routine, since the
difference between
these two points is clearly negligible ?
I second that. It's never a good idea to test two floating point numbers for equality. You should always have an epsilon to
account for
rounding errors.
I disagree. In the case of paths, the current curve's final point is exactly the same data as the next curve's initial point. 2geom has this built-in redundancy in path data because it simplifies things a lot. But it is important to maintain this data duplication. Therefore, these points should be exactly (binary) equivalent.
I noticed in point.h, == is overloaded like this:
inline bool operator==(Point const &a, Point const &b) { return (a[X] == b[X]) && (a[Y] == b[Y]); }
This should be "abs(a-b) < epsilon", however, maybe nathan has a faster way.
For this purpose we have "bool are_near(Typename a, Typename b)". So when one checks point1 == point2, one knows whether they are exactly the same.
We are working on a proper fix.
Johan
Hi Johan, obviously I agree with you :-) I think it dependends from the new Symmetric Power Basis - Bernstein Basis conversion routines I implemented the last week. I hope to have fixed the problem: now the routines leave the initial and final control points unchanged so that exact comparison can be performed. Could you syncronize the inkscape code ?
Cheers, Marco
On Mon, 01 Sep 2008 14:05:14 +0200, <J.B.C.Engelen@...1578...> wrote:
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Bob Jamison Sent: maandag 1 september 2008 6:40 To: bulia byak; inkscape Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
bulia byak wrote:
On Sun, Aug 31, 2008 at 2:24 PM, Alvin
Penner<penner@...1856...> wrote:
Investigation showed the following inequality throws the
exception:
(136.653830 , -638.496893) == (136.653830 , -638.496893)
which in hex looks like:
(406114EC2CAB84D2 , C083F3F9A32A10A6) == (406114EC2CAB84D2 , C083F3F9A32A10A7)
would it not be desirable to (instead) put some tolerance for round-off error into the 2geom routine, since the
difference between
these two points is clearly negligible ?
I second that. It's never a good idea to test two floating point numbers for equality. You should always have an epsilon to
account for
rounding errors.
I disagree. In the case of paths, the current curve's final point is exactly the same data as the next curve's initial point. 2geom has this built-in redundancy in path data because it simplifies things a lot. But it is important to maintain this data duplication. Therefore, these points should be exactly (binary) equivalent.
I noticed in point.h, == is overloaded like this:
inline bool operator==(Point const &a, Point const &b) { return (a[X] == b[X]) && (a[Y] == b[Y]); }
This should be "abs(a-b) < epsilon", however, maybe nathan has a faster way.
For this purpose we have "bool are_near(Typename a, Typename b)". So when one checks point1 == point2, one knows whether they are exactly the same.
We are working on a proper fix.
Johan
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Lib2geom-devel mailing list Lib2geom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
-----Original Message----- From: Marco [mailto:mrcekets@...400...] Sent: maandag 1 september 2008 15:26 To: Engelen, J.B.C. (Johan); rwjj@...127...; buliabyak@...400...; inkscape-devel@lists.sourceforge.net; penner@...1856... Cc: lib2geom-devel@lists.sourceforge.net Subject: Re: [Lib2geom-devel] [Inkscape-devel] Win32 nightly builds don't work since Aug 16
Hi Johan, obviously I agree with you :-) I think it dependends from the new Symmetric Power Basis - Bernstein Basis conversion routines I implemented the last week. I hope to have fixed the problem: now the routines leave the initial and final control points unchanged so that exact comparison can be performed. Could you syncronize the inkscape code ?
I just updated, but it does not solve the problem :(
On Sep 1, 2008, at 5:05 AM, J.B.C.Engelen@...1578... wrote:
I disagree. In the case of paths, the current curve's final point is exactly the same data as the next curve's initial point. 2geom has this built-in redundancy in path data because it simplifies things a lot. But it is important to maintain this data duplication. Therefore, these points should be exactly (binary) equivalent.
Yes, but the main problem with floating point values is that depending on the rounding involved on calculations to get to some value, things may be equivalent but not an exact match for all bits.
Also keep in mind that precision might vary from platform to platform.
-----Original Message----- From: lib2geom-devel-bounces@lists.sourceforge.net [mailto:lib2geom-devel-bounces@lists.sourceforge.net] On Behalf Of Jon A. Cruz Sent: maandag 1 september 2008 20:43 To: Engelen, J.B.C. (Johan) Cc: rwjj@...127...; inkscape-devel@lists.sourceforge.net; lib2geom-devel@lists.sourceforge.net; buliabyak@...400... Subject: Re: [Lib2geom-devel] [Inkscape-devel] Win32 nightly builds don'twork since Aug 16
On Sep 1, 2008, at 5:05 AM, J.B.C.Engelen@...1578... wrote:
I disagree. In the case of paths, the current curve's final point is
exactly the same data as the next curve's initial point. 2geom has this
built-in redundancy in path data because it simplifies things a lot. But
it is important to maintain this data duplication. Therefore, these
points should be exactly (binary) equivalent.
Yes, but the main problem with floating point values is that depending on the rounding involved on calculations to get to some value, things may be equivalent but not an exact match for all bits.
Also keep in mind that precision might vary from platform to platform.
The idea is to get all calculations exactly equal for the initial and final points. So this should not be a problem. If the calculations are not exactly equal, then at the end of the calculation something should be added such that it mimics the "standard" calculation for initial and final points.
Jon A. Cruz wrote:
On Sep 1, 2008, at 5:05 AM, J.B.C.Engelen@...1578... mailto:J.B.C.Engelen@...1578... wrote:
I disagree. In the case of paths, the current curve's final point is
exactly the same data as the next curve's initial point. 2geom has this
built-in redundancy in path data because it simplifies things a lot. But
it is important to maintain this data duplication. Therefore, these
points should be exactly (binary) equivalent.
Yes, but the main problem with floating point values is that depending on the rounding involved on calculations to get to some value, things may be equivalent but not an exact match for all bits.
Also keep in mind that precision might vary from platform to platform.
Jon,
I was thinking of that just now. Someone could load a perfectly valid svg file with a different opinion of floats than Inkscape, and Inkscape will abort and commit suicide because of it. Overreaction, yes, but software is irrational. :-)
bob
Bob Jamison-2 wrote:
Overreaction, yes, but software is irrational. :-)
please don't tell that to my boss
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Bob Jamison Sent: maandag 1 september 2008 23:29 To: Jon A. Cruz; inkscape Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
Jon A. Cruz wrote:
On Sep 1, 2008, at 5:05 AM, J.B.C.Engelen@...1578... mailto:J.B.C.Engelen@...1578... wrote:
I disagree. In the case of paths, the current curve's
final point is
exactly the same data as the next curve's initial point. 2geom has this
built-in redundancy in path data because it simplifies
things a lot.
But
it is important to maintain this data duplication. Therefore, these
points should be exactly (binary) equivalent.
Yes, but the main problem with floating point values is that
depending on
the rounding involved on calculations to get to some value,
things may
be equivalent but not an exact match for all bits.
Also keep in mind that precision might vary from platform
to platform. Jon,
I was thinking of that just now. Someone could load a perfectly valid svg file with a different opinion of floats than Inkscape, and Inkscape will abort and commit suicide because of it. Overreaction, yes, but software is irrational. :-)
Maybe my explanation was unclear. Let me try again :-) Loading the following SVG:
M 2.2,3.4 L 4.567,2 L 5,6
is currently stored in Inkscape/2geom as:
(start path) linesegment from (2.2 , 3.4) to (4.567, 2) linesegment from (4.567, 2 ) to ( 5 , 6)
regardless of the precision of your pc. If you have a pc with fixed point math and 1 decimal, it'd be:
linesegment from (2.2, 3.4) to (4.5, 2) linesegment from (4.5, 2 ) to ( 5, 6)
Nothing will bug as 4.5==4.5 binary equivalent.
Now a transform matrix is applied. 2geom must apply the same math to the end points. Because the start values are identical, so will the result. If not, that's a 2geom bug.
A very important 2geom principle I've come to appreciate is 'correctness' above all. And I think it is very much correct to have binary equivalent end points. (although it might be nice to have a method that smooths/corrects a wrong/discontinuous path that is generated by a user; boolops creates such paths that are stitched together now)
Hope this helps, Johan
(hope this mail discussion is read and checked by 2geom gurus!)
On Tue, 2008-09-02 at 00:31 +0200, J.B.C.Engelen@...1578... wrote:
Maybe my explanation was unclear. Let me try again :-) Loading the following SVG:
M 2.2,3.4 L 4.567,2 L 5,6
is currently stored in Inkscape/2geom as:
(start path) linesegment from (2.2 , 3.4) to (4.567, 2) linesegment from (4.567, 2 ) to ( 5 , 6)
regardless of the precision of your pc. If you have a pc with fixed point math and 1 decimal, it'd be:
linesegment from (2.2, 3.4) to (4.5, 2) linesegment from (4.5, 2 ) to ( 5, 6)
Nothing will bug as 4.5==4.5 binary equivalent.
Now a transform matrix is applied. 2geom must apply the same math to the end points. Because the start values are identical, so will the result. If not, that's a 2geom bug.
Well, the general problem here is if not everything comes through the exact same path for each and every point, then the bits representing the same string might actually be different.
Also.. for single digit precision that one value might be (4.6, 2) and not (4.5, 2)
I don't have concrete code-path examples off hand, but this was a big issue with color and I had to fix a lot of things to keep values from bouncing feedback loops, etc.
On Mon, 2008-09-01 at 15:38 -0700, Jon A. Cruz wrote:
Well, the general problem here is if not everything comes through the exact same path for each and every point, then the bits representing the same string might actually be different.
Fundamentally, the start and end points of adjacent Curves represent the *same* logical point and their binary equivalence ought to be preserved across transformations (at least those which are applied to both curves as part of a larger unit).
-mental
Hi all,
No opinions on this thread, really, .... But this thread has veered from the original subject. Can we get away from "Aug 16?" :-)
bob
MenTaLguY wrote:
On Mon, 2008-09-01 at 15:38 -0700, Jon A. Cruz wrote:
Well, the general problem here is if not everything comes through the exact same path for each and every point, then the bits representing the same string might actually be different.
Fundamentally, the start and end points of adjacent Curves represent the *same* logical point and their binary equivalence ought to be preserved across transformations (at least those which are applied to both curves as part of a larger unit).
-mental
Bob Jamison-2 wrote:
.... But this thread has veered from the original subject. Can we get away from "Aug 16?" :-)
very true, the original issue has long since been resolved ...
maybe this discussion could be restarted as a '2geom closed-path endpoint discussion'
Alvin
On Mon, 2008-09-01 at 16:28 -0500, Bob Jamison wrote:
I was thinking of that just now. Someone could load a perfectly valid svg file with a different opinion of floats than Inkscape, and Inkscape will abort and commit suicide because of it. Overreaction, yes, but software is irrational. :-)
No, it won't. Input read from svgd always preserves adjacency.
These issues crop up only when the adjacency of adjacent curves is destroyed by their being updated or computed separately in the 2geom path representation.
-mental
On Sep 3, 2008, at 1:52 PM, MenTaLguY wrote:
These issues crop up only when the adjacency of adjacent curves is destroyed by their being updated or computed separately in the 2geom path representation.
That sounds a bit like you could be saying the code that is the consumer of the 2geom lib would be doing something incorrectly, and not 2geom itself. Is that correct?
That is what the issue has been looking like to me.
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Jon A. Cruz Sent: donderdag 4 september 2008 9:22 To: MenTaLguY Cc: inkscape Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
On Sep 3, 2008, at 1:52 PM, MenTaLguY wrote:
These issues crop up only when the adjacency of adjacent curves is destroyed by their being updated or computed separately in
the 2geom
path representation.
That sounds a bit like you could be saying the code that is the consumer of the 2geom lib would be doing something incorrectly, and not 2geom itself. Is that correct?
That is what the issue has been looking like to me.
It is hard for a 2geom consumer to do this kind of thing wrong. Curves in paths are well protected and nigh impossible to change outside of 2geom. When changing or adding to a path outside of 2geom, 2geom always checks the continuity.
We had problems with all matrix transforms a while back, fixed by no longer inlining the operator*= method. I do not know the cause for the bug back then (and I think it only happened on Windows). Maybe we have a similar problem now.
Ah! just thought of something. lpe Spiro can also create non-continuous paths, although it only uses Geom::appendNew<> (through SPCurve)...
-Johan
On Thu, 2008-09-04 at 11:13 +0200, J.B.C.Engelen@...1578... wrote:
Ah! just thought of something. lpe Spiro can also create non-continuous paths, although it only uses Geom::appendNew<> (through SPCurve)...
Hmm, how is that possible? IIRC, the appendNew API was specifically designed to prevent that...
-mental
-----Original Message----- From: MenTaLguY [mailto:mental@...3...] Sent: donderdag 4 september 2008 14:52 To: Engelen, J.B.C. (Johan) Cc: jon@...18...; njh@...1927...; inkscape-devel@lists.sourceforge.net; lib2geom-devel@lists.sourceforge.net Subject: RE: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
On Thu, 2008-09-04 at 11:13 +0200, J.B.C.Engelen@...1578... wrote:
Ah! just thought of something. lpe Spiro can also create non-continuous paths, although it only uses
Geom::appendNew<> (through
SPCurve)...
Hmm, how is that possible? IIRC, the appendNew API was specifically designed to prevent that...
I know! I still don't know why it happens, I've checked the lpe spiro code over and over, really strange. It seems to happen for spiro paths that spin out of control (chaotic, creating really big paths that maybe go to inf?) The fix back then was to multiply the path with identity matrix, which would trigger the continuity error, catch it and stop spiro calculation. Note that I had to explicitly run operator* to trigger the exception. appendNew didn't.
- johan
-----Original Message----- From: lib2geom-devel-bounces@lists.sourceforge.net [mailto:lib2geom-devel-bounces@lists.sourceforge.net] On Behalf Of J.B.C.Engelen@...1578... Sent: vrijdag 5 september 2008 11:19 To: mental@...3... Cc: jon@...18...; lib2geom-devel@lists.sourceforge.net; inkscape-devel@lists.sourceforge.net Subject: Re: [Lib2geom-devel] [Inkscape-devel] Win32 nightly builds don'twork since Aug 16
-----Original Message----- From: MenTaLguY [mailto:mental@...3...] Sent: donderdag 4 september 2008 14:52 To: Engelen, J.B.C. (Johan) Cc: jon@...18...; njh@...1927...; inkscape-devel@lists.sourceforge.net; lib2geom-devel@lists.sourceforge.net Subject: RE: [Inkscape-devel] Win32 nightly builds don't work since Aug 16
On Thu, 2008-09-04 at 11:13 +0200,
J.B.C.Engelen@...1578... wrote:
Ah! just thought of something. lpe Spiro can also create non-continuous paths, although it only uses
Geom::appendNew<> (through
SPCurve)...
Hmm, how is that possible? IIRC, the appendNew API was
specifically
designed to prevent that...
I know! I still don't know why it happens, I've checked the lpe spiro code over and over, really strange. It seems to happen for spiro paths that spin out of control (chaotic, creating really big paths that maybe go to inf?) The fix back then was to multiply the path with identity matrix, which would trigger the continuity error, catch it and stop spiro calculation. Note that I had to explicitly run operator* to trigger the exception. appendNew didn't.
Okay... now *finally* I've found the cause. Adding infinite points to a 2geom path causes that non-continuity error. LPESpiro calls appendNew with infinite coordinates sometimes.
I am updating the commentary in SPCurve now, that the coordinates should be finite. Adding checks to LPESpiro, such that it skips infinite coordinates.
This should fix a looooong standing lpespiro bug. jay!
Cheers, Johan
On Sun, 2008-09-28 at 22:19 +0200, J.B.C.Engelen@...1578... wrote:
Okay... now *finally* I've found the cause. Adding infinite points to a 2geom path causes that non-continuity error. LPESpiro calls appendNew with infinite coordinates sometimes.
Good work!
Hm, so, that also sounds like the Curve constructors should maybe check that their endpoints are finite and raise a more specific (catchable) exception; "continuity error" isn't very descriptive of what's happening.
(Also, the point of appendNew is that it should never produce a discontinuity. So raising continuity error versus some more helpful exception in this case is arguably a bug.)
-mental
participants (7)
-
unknown＠example.com -
Alvin Penner -
Bob Jamison -
bulia byak -
Jon A. Cruz -
Marco -
MenTaLguY