lib2geom-devel — development discussion

Re: [Lib2geom-devel] Accessing Curve elements in Path

[MenTaLguY <me...@ry...>]

On Mon, 2008-05-19 at 14:53 +0200, Marco wrote:
> Yes, I think you have to use the replace method.
> The reason is that a path has to be continuos.
> Allowing to get a non const iterator would mean bypassing
> the check on continuity preservation that is performed
> when the path is modified by the append/replace/erase methods.

Correct.  Modifying the Curve directly would bypass the invariant
checks.  For now the best procedure is to copy out the sequence of
Curves you are interested in, modify then, and then replace them.

We do need a path editing abstraction which can ensure the invariants
while providing a nicer API, however.  I still haven't come up with
anything satisfactory yet though.

-mental

Re: [Lib2geom-devel] Accessing Curve elements in Path

[MenTaLguY <me...@ry...>]

On Mon, 2008-05-19 at 14:53 +0200, Marco wrote:
> void setInitial(Point const& p)
> {
>      curves_[0].setInitial(p);
>      final_.setFinal(p);
> }
> 
> void setFinal(Point const& p)
> {
>      curves_[curves_.size()-2].setFinal(p);
>      final_.setInitial(p);
> }

This seems reasonable to me, although the second one will need be
modified to accommodate the case where curves.size() < 2.

-mental

Re: [Lib2geom-devel] Path::back()

[<J.B...@ew...>]

> -----Original Message-----
> From: lib...@li... 
> [mailto:lib...@li...] On 
> Behalf Of J.B...@ew...
> Sent: maandag 19 mei 2008 23:56
> To: lib...@li...
> Subject: [Lib2geom-devel] Path::back()
> 
> Hi all,
> 
> Should Path::back() return the last (visible) segment ?
> For closed paths this is not the case at the moment.

Another question that is a bit related:

  _pathv.back().setFinal( _pathv.back().finalPoint() + p );
  // Move handle as well when the last segment is a cubic bezier segment:
  // TODO: what to do for quadratic beziers?
  if ( Geom::CubicBezier const *lastcube = dynamic_cast<Geom::CubicBezier const *>(&_pathv.back().back()) ) {
    Geom::CubicBezier newcube( *lastcube );
//    newcube.setPoint(2, newcube[2] + p);
    _pathv.back().replace( _pathv.back().end()--, newcube );
  }

This no-op (note the 3rd comment chars), is not a no-op as it crashes Inkscape. What am I doing wrong?  (the path _pathv.back() is not closed).

Thanks for your help,
Johan

[Lib2geom-devel] Path::back()

[<J.B...@ew...>]

Hi all,

Should Path::back() return the last (visible) segment ?
For closed paths this is not the case at the moment.

Johan

Re: [Lib2geom-devel] SVN access for Max

[Maximilian A. <Anh...@gm...>]

njh schrieb:
> done
> 
> njh
> 
> On Mon, 19 May 2008 J.B...@ew... wrote:
> 
>> Hi all,
>>
>> Can we give SVN write access to lib2geom for Max ?
>> (sf name 'cilix42' if I'm not mistaken)
>> Since he is adding stuff to it in Inkscape code, it is much easier for 
>> me to have him commit things directly to lib2geom as well.

Thanks for adding me, although I think I already had write access. I 
just hadn't found the time yet to merge my changes upstream into 2geom 
directly. Johan, I just read that you did this for the latest changes. 
Thanks! I will see to updating 2geom first in the future. Sorry for the 
hassle.

Max

Re: [Lib2geom-devel] SVN access for Max

[njh <nj...@nj...>]

done

njh

On Mon, 19 May 2008 J.B...@ew... wrote:

> Hi all,
>
> Can we give SVN write access to lib2geom for Max ?
> (sf name 'cilix42' if I'm not mistaken)
> Since he is adding stuff to it in Inkscape code, it is much easier for me to have him commit things directly to lib2geom as well.
>
> Thanks!
> Johan
>

Re: [Lib2geom-devel] [Inkscape-devel] isFinite() problem again

[<J.B...@ew...>]

> -----Original Message-----
> From: Michael Wybrow [mailto:mjw...@gm...] On Behalf Of 
> Michael Wybrow
> Sent: zondag 18 mei 2008 23:29
> To: Engelen, J.B.C. (Johan)
> Cc: Anh...@gm...; ink...@li...; 
> lib...@li...
> Subject: Re: [Inkscape-devel] isFinite() problem again
> 
> 
> On 19/05/2008, at 12:09 AM, J.B...@ew... wrote:
> >
> > The problem was that 2Geom did not put its "#ifndef __ISNAN_H__ 
> > #define __ISNAN_H__"
> > in its own namespace; i.e. the defines to check whether 
> 2geom/ isnan.h 
> > was already included or not. Inkscape's isnan.h uses the 
> same defined 
> > name to check this, so...
> >
> > I updated to latest 2geom, now the problem should be solved.
> >
> > Still, one cannot include 2geom files *after* including Inkscape's 
> > isnan.h; a permanent solution is to capitalize the macros in 
> > Inkscape's isnan.h.
> 
> 
> I'm pretty sure that when lib2geom was started, it just took 
> Inkscape's current isnan.h.  Since these definitions are 
> equivalent, isn't the right thing to avoid these clashes just 
> to remove Inkscape's isnan.h completely, and just use the 
> lib2geom one everywhere?

The problem is that both files evolved a bit, and the definitions have gotten different names and such.
If the files would be exactly the same, there wouldn't be a problem :)

For me, it's okay to start using 2geom's isnan.h.  But perhaps there are good arguments not to do it.

Johan

[Lib2geom-devel] SVN access for Max

[<J.B...@ew...>]

Hi all,

Can we give SVN write access to lib2geom for Max ?
(sf name 'cilix42' if I'm not mistaken)
Since he is adding stuff to it in Inkscape code, it is much easier for me to have him commit things directly to lib2geom as well.

Thanks!
Johan

Re: [Lib2geom-devel] Accessing Curve elements in Path

[Marco <mrc...@gm...>]

On Sun, 18 May 2008 14:40:00 +0200, <J.B...@ew...> wrote:

> Hmm I just figured that writing directly to Curve is maybe not a good  
> idea.
>
> For example, what I need to do is reset the start and end points of a  
> path:
>
> (PathVector _pathv)
>     _pathv.front().setInitial( point );
>     _pathv.front().setFinal( point2 );
>
> These set methods do not yet exist.
>
> This won't work I think, because of the final_ segment in the path:
>     _pathv.front().front().setInitial( point);
>     _pathv.front().back().setFinal(  point2 );
>

Yes, if we modify front() and back() to return a Curve&
we'll introduce a breaking change because the closing segment
extremes are not updated.
So it seems sensible to make up two path methods
as you are suggesting:

void setInitial(Point const& p)
{
     curves_[0].setInitial(p);
     final_.setFinal(p);
}

void setFinal(Point const& p)
{
     curves_[curves_.size()-2].setFinal(p);
     final_.setInitial(p);
}

> Please comment!
>
> Johan
>
>

Marco

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Lib2geom-devel] Accessing Curve elements in Path

[Marco <mrc...@gm...>]

On Sat, 17 May 2008 00:04:33 +0200, <J.B...@ew...> wrote:

> Hi all,
>
> How do I access Curve elements in a Path for *writing* ?
>
> Geom::Path::iterator it = _path.end();
> (*it)  will give me a const reference to a Curve, because  
> Geom::Path::iterator is a BaseIterator that only provides const refs.
>
> Do I have to copy the curve, and then use replace method? Why is this so?
>
> Thanks,
> Johan
>

Yes, I think you have to use the replace method.
The reason is that a path has to be continuos.
Allowing to get a non const iterator would mean bypassing
the check on continuity preservation that is performed
when the path is modified by the append/replace/erase methods.
Anyway I don't know what is the rationale to have
"iterator begin()" and "iterator end()" methods.

Marco

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Lib2geom-devel] [Inkscape-devel] isFinite() problem again

[Michael W. <mic...@in...>]

On 19/05/2008, at 12:09 AM, J.B...@ew... wrote:
>
> The problem was that 2Geom did not put its
> "#ifndef __ISNAN_H__
> #define __ISNAN_H__"
> in its own namespace; i.e. the defines to check whether 2geom/ 
> isnan.h was already included or not. Inkscape's isnan.h uses the  
> same defined name to check this, so...
>
> I updated to latest 2geom, now the problem should be solved.
>
> Still, one cannot include 2geom files *after* including Inkscape's  
> isnan.h; a permanent solution is to capitalize the macros in  
> Inkscape's isnan.h.


I'm pretty sure that when lib2geom was started, it just took  
Inkscape's current isnan.h.  Since these definitions are equivalent,  
isn't the right thing to avoid these clashes just to remove Inkscape's  
isnan.h completely, and just use the lib2geom one everywhere?


Cheers,
Michael


------
Michael Wybrow
Clayton School of Information Technology
Monash University, Wellington Road, Clayton, Vic 3800, Australia
Phone: +613 9905 2479

Re: [Lib2geom-devel] Direction of rotations

[njh <nj...@nj...>]

On Sun, 18 May 2008, Maximilian Albert wrote:

> Hi,
>
> if I am not mistaken, one way to rotate a vector v by an angle alpha is
> the following:
>
>    Geom::Rotate rot(alpha);
>    v = v * rot;
>
> But this yields a rotation in the clockwise (i.e., mathematically
> negative) direction. Is this intentional or am I just using the
> constructs in the wrong way?

in 2geom the coords are defined by the direction of cross/rot90.  They 
should result in positive angles going from +x, to +y, to -x, to -y.  If 
not, this is a bug.

Things are a little screwy as inkscape (and its predecessor) use 
bottom-left-origin coords whereas svg and 2geom use top-left-origin 
coords (unless this has been fixed).

njh

Re: [Lib2geom-devel] valueAndDerivative() vs. derivative()

[njh <nj...@nj...>]

On Sun, 18 May 2008, Maximilian Albert wrote:

> Hi,
>
> shouldn't valueAndDerivatives() and derivative() do a similar job? The
> following two pieces of code [1] behave very differently for me:

Out of curiosity, do you get the right result when the 2 becomes a 3?  If 
so I think the bug is actually in
     double SBasis::valueAndDerivative(double t, double &der) const {

The problem is that the approach used for the general case in 
SBasis::valueAndDerivatives (iteratively computing the derivative sbasis 
and evaluating at the point) is correct, but relatively slow (involving 
lots of mallocing, e.g) where as the approach in 
SBasis::valueAndDerivative tried to evaluate the derivative 'for free' by 
tacking onto the calcs for the pointAt.  But apparently it is wrong :(

There is a general n derivatives algorithm for polynomials, and I see no 
strong reason that it wouldn't work for sbasis; but nobody ever did it...

I'll sit down and try and work it out now, but no promises.

njh

[Lib2geom-devel] Direction of rotations

[Maximilian A. <Anh...@gm...>]

Hi,

if I am not mistaken, one way to rotate a vector v by an angle alpha is 
the following:

    Geom::Rotate rot(alpha);
    v = v * rot;

But this yields a rotation in the clockwise (i.e., mathematically 
negative) direction. Is this intentional or am I just using the 
constructs in the wrong way?

Max

[Lib2geom-devel] valueAndDerivative() vs. derivative()

[Maximilian A. <Anh...@gm...>]

Hi,

shouldn't valueAndDerivatives() and derivative() do a similar job? The 
following two pieces of code [1] behave very differently for me:

     std::vector<Point> valDer = pwd2.valueAndDerivatives(t0, 2);
     deriv = valDer[1];

and

    deriv = derivative(pwd2).valueAt(t0)

I ran into this when writing an LPE that draws the tangent to a curve. 
In both cases, after the computation 'deriv' should contain the 
direction of the tangent, shouldn't it? With the first version, this was 
not true. The second version worked fine, however. What's the difference 
between the two?

Max


[1] Here, pwd2 is of type Piecewise<D2<SBasis> > and t0 is a double 
indicating a location on the curve.

Re: [Lib2geom-devel] [Inkscape-devel] isFinite() problem again

[<J.B...@ew...>]

> -----Original Message-----
> From: ink...@li... 
> [mailto:ink...@li...] On 
> Behalf Of Maximilian Albert
> Sent: zondag 18 mei 2008 15:45
> To: inkscape; lib...@li...
> Subject: [Inkscape-devel] isFinite() problem again
> 
> Hi all,
> 
> recently there was a discussion about name clashes involving 
> is_finite(). The problem appeared to be solved but now I ran 
> into it (or something similar?) again. Namely, adding the line
> 
>     #include "live_effects/effect.h"
> 
> to object-edit.cpp yielded the following compile error:
> 
>   object-edit.cpp: In function ‘void 
> sp_spiral_outer_set(SPItem*, const NR::Point&, const 
> NR::Point&, guint)’:
>   object-edit.cpp:1121: error: ‘isFinite’ was not declared in 
> this scope

The problem was that 2Geom did not put its
"#ifndef __ISNAN_H__
#define __ISNAN_H__"
in its own namespace; i.e. the defines to check whether 2geom/isnan.h was already included or not. Inkscape's isnan.h uses the same defined name to check this, so...

I updated to latest 2geom, now the problem should be solved.

Still, one cannot include 2geom files *after* including Inkscape's isnan.h; a permanent solution is to capitalize the macros in Inkscape's isnan.h.

Cheers,
Johan

[Lib2geom-devel] isFinite() problem again

[Maximilian A. <Anh...@gm...>]

Hi all,

recently there was a discussion about name clashes involving 
is_finite(). The problem appeared to be solved but now I ran into it (or 
something similar?) again. Namely, adding the line

    #include "live_effects/effect.h"

to object-edit.cpp yielded the following compile error:

  object-edit.cpp: In function ‘void sp_spiral_outer_set(SPItem*, const
NR::Point&, const NR::Point&, guint)’:
  object-edit.cpp:1121: error: ‘isFinite’ was not declared in this scope

When I additionally changed the line

    #include "isnan.h"

to

    #include "2geom/isnan.h"

and replaced isFinite() with IS_FINITE(), compilation worked fine again. 
Thus it seems that there is some kind of clashing between isnan.h and 
2geom/isnan.h. Has anyone else seen this and what should be done to 
avoid further difficulties in the future?

Max

Re: [Lib2geom-devel] Accessing Curve elements in Path

[<J.B...@ew...>]

Hmm I just figured that writing directly to Curve is maybe not a good idea.

For example, what I need to do is reset the start and end points of a path:

(PathVector _pathv)
    _pathv.front().setInitial( point );
    _pathv.front().setFinal( point2 );

These set methods do not yet exist.

This won't work I think, because of the final_ segment in the path:
    _pathv.front().front().setInitial( point);
    _pathv.front().back().setFinal(  point2 );

Please comment!

Johan


> -----Original Message-----
> From: lib...@li... 
> [mailto:lib...@li...] On 
> Behalf Of J.B...@ew...
> Sent: zaterdag 17 mei 2008 0:05
> To: lib...@li...
> Subject: [Lib2geom-devel] Accessing Curve elements in Path
> 
> Hi all,
> 
> How do I access Curve elements in a Path for *writing* ?
> 
> Geom::Path::iterator it = _path.end();
> (*it)  will give me a const reference to a Curve, because 
> Geom::Path::iterator is a BaseIterator that only provides const refs.
> 
> Do I have to copy the curve, and then use replace method? Why 
> is this so?
> 
> Thanks,
> Johan
> 
> 
> __________________________________________________
> ir. J.B.C. Engelen
> PhD student Micro Electromechanical Systems (MEMS) TST EWI, 
> University of Twente The NETHERLANDS
> e-mail: j.b...@ut... 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all 
> challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> 

[Lib2geom-devel] Path constructor

[<J.B...@ew...>]

Hi all,

Should this code behave the same?

Geom::Point startpoint(123.2, 456.8);
Geom::Path p( startpoint );

and

Geom::Point startpoint(123.2, 456.8);
Geom::Path p;
p.start( startpoint );

I ask because it does not behave the same in Inkscape.
(if you want to test, checkout my branch and go to /src/display/curve.cpp method "moveto(NR::Point const &p)". See the cmdline output when you change to either one of the above.

Geom::Path p( startpoint )   gives   "M 0,0" as output.

Geom::Path p;
p.start( startpoint );   I think correctly gives "M 123.2, 456.8" as output.

Thanks,
Johan

[Lib2geom-devel] Accessing Curve elements in Path

[<J.B...@ew...>]

Hi all,

How do I access Curve elements in a Path for *writing* ?

Geom::Path::iterator it = _path.end();
(*it)  will give me a const reference to a Curve, because Geom::Path::iterator is a BaseIterator that only provides const refs.

Do I have to copy the curve, and then use replace method? Why is this so?

Thanks,
Johan


__________________________________________________
ir. J.B.C. Engelen
PhD student Micro Electromechanical Systems (MEMS)
TST EWI, University of Twente
The NETHERLANDS
e-mail: j.b...@ut... 

Re: [Lib2geom-devel] Operations on "PathVector"

[<J.B...@ew...>]

I added pathvector.h/.cpp for operations on PathVector (and the definition of what a PathVector is).

I also added forward.h with forward declarations to decrease compile times. It does include STL's <vector>, so PathVector can be defined completely. In practical terms, this means that Inkscape's curve.h can include only forward.h for its member PathVector. So when I add methods to pathvector.h, I don't have to unnecessarily compile all curve.h deps. :-)

Cheers,
Johan

Re: [Lib2geom-devel] Operations on "PathVector"

[njh <nj...@nj...>]

On Thu, 15 May 2008 J.B...@ew... wrote:

> Hi all,
>
> typedef std::vector<Geom::Path> PathVector;
>
> For ease of speech and code reading pleasure :)

I think that is a good idea, especially from the point of view of 
alternative language bindings.

>
> I need to do operations (like append, transformation, reverse) on PathVector. Is it desired to put these in 2geom?
> Right now I code all these in Inkscape, for example:

Can't you just lift these from STL::Vector?

> void
> SPCurve::transform(Geom::Matrix const &m)
> {
>    PathVector new_v;
>    for(PathVector::const_iterator it = _pathv.begin(); it != _pathv.end(); ++it) {
>        new_v.push_back( (*it) * m );
>    }
>    _pathv = new_v;
> }
>
> It would be nice if I could add a pathvector.h or something to 2geom to do these operations.
> Is it okay to do that?

Of course.  We trust you Johan!

njh
k

Re: [Lib2geom-devel] Operations on "PathVector"

[Maximilian A. <Anh...@gm...>]

J.B...@ew... schrieb:
> Hi all,
> 
> typedef std::vector<Geom::Path> PathVector;
> 
> For ease of speech and code reading pleasure :)
> 
> I need to do operations (like append, transformation, reverse) on PathVector.
 > Is it desired to put these in 2geom?

Thanks for this suggestion. I was about to propose something similar, 
too, since I have already found myself recoding stuff like this a couple 
of times even with my very limited work on new LPEs. I don't exactly 
remember whether it was path vector operations or something else, but I 
for one would be glad to have it in any case and will add similar 
functionality when I need it in other places.

Max

[Lib2geom-devel] Operations on "PathVector"

[<J.B...@ew...>]

Hi all,

typedef std::vector<Geom::Path> PathVector;

For ease of speech and code reading pleasure :)

I need to do operations (like append, transformation, reverse) on PathVector. Is it desired to put these in 2geom?
Right now I code all these in Inkscape, for example:

void
SPCurve::transform(Geom::Matrix const &m)
{
    PathVector new_v;
    for(PathVector::const_iterator it = _pathv.begin(); it != _pathv.end(); ++it) {
        new_v.push_back( (*it) * m );
    }
    _pathv = new_v;
}

It would be nice if I could add a pathvector.h or something to 2geom to do these operations.
Is it okay to do that?

Cheers,
Johan

Re: [Lib2geom-devel] [Inkscape-devel] Nameclashing with is_finitemacro

[<J.B...@ew...>]

I resolved the nameclashing issue by capitalizing the macros in 2geom and updating Inkscape to the latest 2geom.

-Johan