lib2geom-devel — development discussion

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

[Partha B. <par...@gm...>]

What about umfpack (http://www.cise.ufl.edu/research/sparse/umfpack/ )?
Already being used in GEGL.

Thanks,
Partha



On Fri, Apr 11, 2014 at 7:34 AM, Alex Valavanis <val...@gm...>wrote:

> Well, it depends on the format of the matrix. If it can be arranged into a
> tridiagonal form, then it can be inverted much faster using [1].
>
> If it's a general sparse matrix (i.e., there is some data away from the
> three main diagonals), then unfortunately there's nothing available in GSL.
>
> Armadillo supports eigenvalue searches in sparse matrices (although you
> can only get selected eigenvalues) but doesn't support sparse matrix
> inversions yet.
>
> There are a couple of older libraries like libsparse++ and arpack++ that
> may be useful although their API is the stuff of nightmares!
>
> Let me know what the maths looks like and I'll see if I can find something
> useful :)
>
> AV
>
> [1]
> http://www.gnu.org/software/gsl/manual/html_node/Tridiagonal-Systems.html#Tridiagonal-Systems
>
> On 11 April 2014 12:18, Tavmjong Bah <tav...@fr...> wrote:
> > On Fri, 2014-04-11 at 12:02 +0100, Alex Valavanis wrote:
> >> Jabier,
> >>
> >> Can you give some information about the type of problem you're trying
> >> to solve? The LU decomposition approach is fine for general matrix
> >> inversions, but there are much faster algorithms available for sparse
> >> matrices.
> >
> > Alex,
> >
> > What would you recommend for sparse matrices? I have a long term
> > Inkscape project that needs this.
> >
> > Thanks,
> >
> > Tav
> >
> >
> >
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Inkscape-devel mailing list
> Ink...@li...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

[Alex V. <val...@gm...>]

Ok, if it's just a 3x3, it probably won't make much difference in terms of
computation time. Might be worth trying the tridiagonal solver from gsl if
you find the existing method too slow.

AV
On 11 Apr 2014 15:09, "Jabiertxo Arraiza Cenoz" <jab...@ma...>
wrote:

> Hi again:
> > Well, it depends on the format of the matrix. If it can be arranged into
> a
> > tridiagonal form, then it can be inverted much faster using [1].
> In my case is a bidimensional array:
> double* A[3][3]
> double* B[3]
> Regards.
>
>

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

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

Hi again:
> Well, it depends on the format of the matrix. If it can be arranged into a
> tridiagonal form, then it can be inverted much faster using [1].
In my case is a bidimensional array:
double* A[3][3]
double* B[3]
Regards. 

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

[Alex V. <val...@gm...>]

Well, it depends on the format of the matrix. If it can be arranged into a
tridiagonal form, then it can be inverted much faster using [1].

If it's a general sparse matrix (i.e., there is some data away from the
three main diagonals), then unfortunately there's nothing available in GSL.

Armadillo supports eigenvalue searches in sparse matrices (although you can
only get selected eigenvalues) but doesn't support sparse matrix inversions
yet.

There are a couple of older libraries like libsparse++ and arpack++ that
may be useful although their API is the stuff of nightmares!

Let me know what the maths looks like and I'll see if I can find something
useful :)

AV

[1]
http://www.gnu.org/software/gsl/manual/html_node/Tridiagonal-Systems.html#Tridiagonal-Systems

On 11 April 2014 12:18, Tavmjong Bah <tav...@fr...> wrote:
> On Fri, 2014-04-11 at 12:02 +0100, Alex Valavanis wrote:
>> Jabier,
>>
>> Can you give some information about the type of problem you're trying
>> to solve? The LU decomposition approach is fine for general matrix
>> inversions, but there are much faster algorithms available for sparse
>> matrices.
>
> Alex,
>
> What would you recommend for sparse matrices? I have a long term
> Inkscape project that needs this.
>
> Thanks,
>
> Tav
>
>
>

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

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

On Fri, 2014-04-11 at 12:02 +0100, Alex Valavanis wrote:
> Jabier,
> 
> Can you give some information about the type of problem you're trying
> to solve?  The LU decomposition approach is fine for general matrix
> inversions, but there are much faster algorithms available for sparse
> matrices.

Alex,

What would you recommend for sparse matrices? I have a long term
Inkscape project that needs this.

Thanks,

Tav

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

[Alex V. <val...@gm...>]

Jabier,

Can you give some information about the type of problem you're trying
to solve?  The LU decomposition approach is fine for general matrix
inversions, but there are much faster algorithms available for sparse
matrices.

AV

On 8 April 2014 19:47, Jabiertxo Arraiza Cenoz <jab...@ma...> wrote:
> Finaly, for the moment, i use the GSL - GNU Scientific Library whith the
> help of this link:
> http://www.gnu.org/software/gsl/manual/html_node/Linear-Algebra-Examples.html#Linear-Algebra-Examples
> Its the same library used by 2GEOM in "linear_sistem.h"
>
> Thanks very much for the help I get.
>
> Regards, Jabier.
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Inkscape-devel mailing list
> Ink...@li...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

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

Finaly, for the moment, i use the GSL - GNU Scientific Library whith the
help of this link:
http://www.gnu.org/software/gsl/manual/html_node/Linear-Algebra-Examples.html#Linear-Algebra-Examples
Its the same library used by 2GEOM in "linear_sistem.h"

Thanks very much for the help I get.

Regards, Jabier.

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

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

> Yes, though I wonder whether we would be better off using something
> like Eigen for our numerics, as this was something that someone
> (marco? jan?) stuck in for a specific problem.  There are better
> libraries for linear algebra, and we shouldn't reinvent the wheel
> there.

Hi Nathan, my knoweledge of c++ and maths is very limitted to propose
and argument a new library for Inkscape, for the moment i attemp to use
Johan way, and in the future, if another lineas algebra library is
added, i could update my code to use it.

Thanks very much for your response, best regards, Jabier.

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

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

Thanks very much Johan!
Best regards.

El lun, 07-04-2014 a las 23:08 +0200, Johan Engelen escribió:
> (copying lib2geom maillist on this)
> 
> On 7-4-2014 22:06, Jabiertxo Arraiza Cenoz wrote:
> > Is there any function in 2Geom to handle this:
> > http://www.mathsisfun.com/algebra/systems-linear-equations-matrices.html
> > or the same :python numpy.linalg.solve
> >
> > Thanks in advance, Jabier.
> 
> Hi Jabier,
>    I think there is, have a look at 2geom/numeric/linear_system.h
> I have never used it, and know nothing about it. But it's there :-)
> 
> cheers,
>    Johan
> 
> 
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Inkscape-devel mailing list
> Ink...@li...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

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

On Mon, Apr 07, 2014 at 11:08:18PM +0200, Johan Engelen wrote:
> (copying lib2geom maillist on this)
> 
> On 7-4-2014 22:06, Jabiertxo Arraiza Cenoz wrote:
> > Is there any function in 2Geom to handle this:
> > http://www.mathsisfun.com/algebra/systems-linear-equations-matrices.html
> > or the same :python numpy.linalg.solve
> >
> > Thanks in advance, Jabier.
> 
> Hi Jabier,
>    I think there is, have a look at 2geom/numeric/linear_system.h
> I have never used it, and know nothing about it. But it's there :-)

Jabier, Johan,

Yes, though I wonder whether we would be better off using something
like Eigen for our numerics, as this was something that someone
(marco? jan?) stuck in for a specific problem.  There are better
libraries for linear algebra, and we shouldn't reinvent the wheel
there.

njh

Re: [Lib2geom-devel] [Inkscape-devel] Help with numpy.linalg.solve

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

(copying lib2geom maillist on this)

On 7-4-2014 22:06, Jabiertxo Arraiza Cenoz wrote:
> Is there any function in 2Geom to handle this:
> http://www.mathsisfun.com/algebra/systems-linear-equations-matrices.html
> or the same :python numpy.linalg.solve
>
> Thanks in advance, Jabier.

Hi Jabier,
   I think there is, have a look at 2geom/numeric/linear_system.h
I have never used it, and know nothing about it. But it's there :-)

cheers,
   Johan

Re: [Lib2geom-devel] Path translations

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

2014-03-23 18:05 GMT+01:00 Nathan Hurst <nj...@nj...>:
> I agree, I've always disliked H/VLine, but on the other hand, it is
> very important that we can directly represent all svg paths.  This was
> actually one of the motivators for 2geom in the first place.
>
> Is there another way which would allow affine transforms to fail
> gracefully if one of the curves in a path were not transformable?
> This is a place where I would use exceptions in python, but C++
> exceptions are somewhat unpopular IIRC.

Throwing an exception when a H/VLine is found during a transform is a
terrible idea, and defeats the whole point of having an
operator*=(Affine const &) function. Instead, the LineSegment could
contain a flag set at construction that says whether it was
constructed as a hline or a vline.

Note that strictly speaking we cannot losslessly represent all SVG
paths, because in 2Geom all paths are in absolute coordinates and
there is no direct representation for the "S" and "T" operators.

Regards, Krzysztof

Re: [Lib2geom-devel] Path translations

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

I agree, I've always disliked H/VLine, but on the other hand, it is
very important that we can directly represent all svg paths.  This was
actually one of the motivators for 2geom in the first place.

Is there another way which would allow affine transforms to fail
gracefully if one of the curves in a path were not transformable?
This is a place where I would use exceptions in python, but C++
exceptions are somewhat unpopular IIRC.

njh

On Sun, Mar 23, 2014 at 03:07:52PM +0100, Johan Engelen wrote:
> Hi all,
>   I finally came around to finishing this (initial) work, and have
> committed it to trunk.
> After Inkscape's release, we really have to look much further into
> this. I think it is a huge burden and slowdown to not have Curves be
> closed under arbitrary Affine.
> As Krzysztof mentioned, it is probably not worth keeping HLineSeg
> and VLineSeg because of this.
> 
> regards,
>   Johan
> 
> On 13-11-2013 17:44, Johan Engelen wrote:
> >On 13-11-2013 16:50, Krzysztof Kosi??ski wrote:
> >>2013/11/12 Johan Engelen <jbc...@sw...>:
> >>>As far as I can see now, all (current) Curve types *are* closed under
> >>>translations. I think we should enforce this for Curve. I.e.,
> >>>each Curve
> >>>must implement
> >>>         virtual Curve &operator+=(Point const &);
> >>I think the method should be:
> >>virtual Curve &operator*=(Translate const &t) {
> >>     *this *= Affine(t);
> >>     return *this;
> >>}
> >>
> >>Rationale:
> >>1. It's not immediately obvious what adding a point to a curve means.
> >>For instance, for BezierCurve it might plausibly mean adding a control
> >>point.
> >
> >Ok, that makes sense.
> >
> >>2. For curves that don't implement the specialization, we just
> >>multiply by a generic affine.
> >
> >This is not possible. Because curves are not closed under Affine
> >transform, there is no operator*=(Affine). If you want to
> >transform a Curve, you have to call
> >    Curve* Curve::transformed(Affine const&)
> >
> >I'll clean up the work and commit my changes, so you can see.
> >
> >Cheers,
> >  Johan
> >
> >
> 

> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech

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

Re: [Lib2geom-devel] Path translations

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

Hi all,
   I finally came around to finishing this (initial) work, and have 
committed it to trunk.
After Inkscape's release, we really have to look much further into this. 
I think it is a huge burden and slowdown to not have Curves be closed 
under arbitrary Affine.
As Krzysztof mentioned, it is probably not worth keeping HLineSeg and 
VLineSeg because of this.

regards,
   Johan

On 13-11-2013 17:44, Johan Engelen wrote:
> On 13-11-2013 16:50, Krzysztof Kosiński wrote:
>> 2013/11/12 Johan Engelen <jbc...@sw...>:
>>> As far as I can see now, all (current) Curve types *are* closed under
>>> translations. I think we should enforce this for Curve. I.e., each 
>>> Curve
>>> must implement
>>>          virtual Curve &operator+=(Point const &);
>> I think the method should be:
>> virtual Curve &operator*=(Translate const &t) {
>>      *this *= Affine(t);
>>      return *this;
>> }
>>
>> Rationale:
>> 1. It's not immediately obvious what adding a point to a curve means.
>> For instance, for BezierCurve it might plausibly mean adding a control
>> point.
>
> Ok, that makes sense.
>
>> 2. For curves that don't implement the specialization, we just
>> multiply by a generic affine.
>
> This is not possible. Because curves are not closed under Affine 
> transform, there is no operator*=(Affine). If you want to transform a 
> Curve, you have to call
>     Curve* Curve::transformed(Affine const&)
>
> I'll clean up the work and commit my changes, so you can see.
>
> Cheers,
>   Johan
>
>

Re: [Lib2geom-devel] Path translations

[Johan E. <goe...@zo...>]

Hi all,
   I finally came around to finishing this (initial) work, and have 
committed it to trunk.
After Inkscape's release, we really have to look much further into this. 
I think it is a huge burden and slowdown to not have Curves be closed 
under arbitrary Affine.
As Krzysztof mentioned, it is probably not worth keeping HLineSeg and 
VLineSeg because of this.

regards,
   Johan

On 13-11-2013 17:44, Johan Engelen wrote:
> On 13-11-2013 16:50, Krzysztof Kosiński wrote:
>> 2013/11/12 Johan Engelen <jbc...@sw...>:
>>> As far as I can see now, all (current) Curve types *are* closed under
>>> translations. I think we should enforce this for Curve. I.e., each 
>>> Curve
>>> must implement
>>>          virtual Curve &operator+=(Point const &);
>> I think the method should be:
>> virtual Curve &operator*=(Translate const &t) {
>>      *this *= Affine(t);
>>      return *this;
>> }
>>
>> Rationale:
>> 1. It's not immediately obvious what adding a point to a curve means.
>> For instance, for BezierCurve it might plausibly mean adding a control
>> point.
>
> Ok, that makes sense.
>
>> 2. For curves that don't implement the specialization, we just
>> multiply by a generic affine.
>
> This is not possible. Because curves are not closed under Affine 
> transform, there is no operator*=(Affine). If you want to transform a 
> Curve, you have to call
>     Curve* Curve::transformed(Affine const&)
>
> I'll clean up the work and commit my changes, so you can see.
>
> Cheers,
>   Johan
>
>

Re: [Lib2geom-devel] Check for _GLIBCXX_IOSTREAM

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

2014-02-09 22:44 GMT+01:00 Vinícius dos Santos Oliveira
<vin...@gm...>:
>
> Em Dom, 2014-02-09 às 17:02 +0100, Johan Engelen escreveu:
>
> Should we separate all the iostream output functions into a separate file that people can then optionally include? I somewhat agree with not "tainting" the code to force including <iostream>...
>
>
> It's better than code that can break depending on the include order.
>
> Do it. :)

+1

I would also think for a bit whether there is a way to avoid including
every 2Geom header in this new separate file (e.g. so that it defines
operators only for things which are already included).

We could do this by adding one include guard per operator, e.g. like this:

#ifndef SEEN_LIB2GEOM_POINT_OUTPUT
#ifdef SEEN_LIB2GEOM_POINT_H
#define SEEN_LIB2GEOM_POINT_OUTPUT
... operator<< definition ...
#endif
#endif

This would still require including the new file at the end of all
2Geom includes in a given .h or .cpp file.

Regards, Krzysztof

Re: [Lib2geom-devel] Check for _GLIBCXX_IOSTREAM

[Vinícius d. S. O. <vin...@gm...>]

Em Dom, 2014-02-09 às 17:02 +0100, Johan Engelen escreveu:

> Should we separate all the iostream output functions into a separate
> file that people can then optionally include? I somewhat agree with
> not "tainting" the code to force including <iostream>...


It's better than code that can break depending on the include order.

Do it. :)


-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker

[Lib2geom-devel] Check for _GLIBCXX_IOSTREAM

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

Hi all,
  Just now Inkscape hit on a build error on Mac (clang) because _GLIBCXX_IOSTREAM is not defined in libc++'s <iostream>.
point.h defines operator<< for Point, without #ifdef guard. But generic-rect.h _does_ define it with #ifdef guard, and so operator<<(iostream, Rect) is not available. Inkscape's (new) code assumed it is available and hence fails.

Should we separate all the iostream output functions into a separate file that people can then optionally include? I somewhat agree with not "tainting" the code to force including <iostream>...

(for now, I have removed the #ifdefs in Inkscape's source)

Cheers,
  Johan

Re: [Lib2geom-devel] build on Ubuntu 12.04

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

Hi Christian,
   Thanks for your mail. I've fixed it in trunk.

Btw, I strongly recommend using trunk, instead of our 0.2.0 release!

Cheers,
   Johan


On 8-12-2013 18:29, Christian wrote:
> Hi folks,
>
> I am just new to this mailinglist and just exploring the library a bit.
>
> I tried compiling lib2geom-0.2.0 on Ubuntu 12.04 (x86_64) and got:
>
> [  1%] Building CXX object src/2geom/CMakeFiles/2geom.dir/matrix.o
> In file included from /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/matrix.cpp:15:0:
> /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:40: error: 'size_t' was not declared in this scope
> /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:40: note: suggested alternatives:
> /usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:155:26: note:   'std::size_t'
> /usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:155:26: note:   'std::size_t'
> /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:46: error: template argument 1 is invalid
> /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:46: error: template argument 2 is invalid
> /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:53: error: 'size_t' has not been declared
> make[2]: *** [src/2geom/CMakeFiles/2geom.dir/matrix.o] Error 1
> make[1]: *** [src/2geom/CMakeFiles/2geom.dir/all] Error 2
> make: *** [all] Error 2
>
> Despite all the Warning from cmake, I thought perhaps worth sharing...
>
>
> Fixes:
>    - I replaced all appearances of size_t by std::size_t in utils.h (line 85)
>           void binomial_coefficients(std::vector<std::size_t>& bc, std::size_t n);
> - utils.cpp in function
>       void binomial_coefficients()
>
>
>
> [ 36%] Built target 2geom
> [ 37%] Building CXX object src/2geom/toys/CMakeFiles/toy-2.dir/toy-framework-2.o
> In file included from /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/toys/toy-framework-2.cpp:2:0:
> /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/toys/toy-framework-2.h:9:21: fatal error: gtk/gtk.h: No such file or directory
> compilation terminated.
> make[2]: *** [src/2geom/toys/CMakeFiles/toy-2.dir/toy-framework-2.o] Error 1
> make[1]: *** [src/2geom/toys/CMakeFiles/toy-2.dir/all] Error 2
> make: *** [all] Error 2
>
> after
>       sudo aptitude install libgtk2.0-dev
>
> and another make it built!
>
> Thx
>
> Christian
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>
>

[Lib2geom-devel] build on Ubuntu 12.04

[Christian <cp...@gm...>]

Hi folks,

I am just new to this mailinglist and just exploring the library a bit.

I tried compiling lib2geom-0.2.0 on Ubuntu 12.04 (x86_64) and got:

[  1%] Building CXX object src/2geom/CMakeFiles/2geom.dir/matrix.o
In file included from /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/matrix.cpp:15:0:
/home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:40: error: 'size_t' was not declared in this scope
/home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:40: note: suggested alternatives:
/usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:155:26: note:   'std::size_t'
/usr/include/c++/4.6/x86_64-linux-gnu/./bits/c++config.h:155:26: note:   'std::size_t'
/home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:46: error: template argument 1 is invalid
/home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:46: error: template argument 2 is invalid
/home/cparg/Downloads/lib2geom-0.2.0/src/2geom/utils.h:83:53: error: 'size_t' has not been declared
make[2]: *** [src/2geom/CMakeFiles/2geom.dir/matrix.o] Error 1
make[1]: *** [src/2geom/CMakeFiles/2geom.dir/all] Error 2
make: *** [all] Error 2

Despite all the Warning from cmake, I thought perhaps worth sharing...


Fixes:
  - I replaced all appearances of size_t by std::size_t in utils.h (line 85)
         void binomial_coefficients(std::vector<std::size_t>& bc, std::size_t n);
- utils.cpp in function
     void binomial_coefficients()



[ 36%] Built target 2geom
[ 37%] Building CXX object src/2geom/toys/CMakeFiles/toy-2.dir/toy-framework-2.o
In file included from /home/cparg/Downloads/lib2geom-0.2.0/src/2geom/toys/toy-framework-2.cpp:2:0:
/home/cparg/Downloads/lib2geom-0.2.0/src/2geom/toys/toy-framework-2.h:9:21: fatal error: gtk/gtk.h: No such file or directory
compilation terminated.
make[2]: *** [src/2geom/toys/CMakeFiles/toy-2.dir/toy-framework-2.o] Error 1
make[1]: *** [src/2geom/toys/CMakeFiles/toy-2.dir/all] Error 2
make: *** [all] Error 2

after
     sudo aptitude install libgtk2.0-dev

and another make it built!

Thx

Christian

Re: [Lib2geom-devel] proposed restriction in calculation of bbox for ellipse

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

fix committed to rev 2160

Alvin Penner

[Lib2geom-devel] proposed restriction in calculation of bbox for ellipse

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

     Attached is a proposed diff for elliptical-arc.cpp, for the 
routine boundsExact(). It will refuse to expand the bbox beyond a 
point value if the initial and final points are the same. This 
expansion was occasionally causing non-zero bboxes randomly, 
encountered while looking at Bug 1247441.
     Am not entirely sure if this is the best way of dealing with 
this, so I thought I would propose it here.

Alvin Penner

Re: [Lib2geom-devel] C++11 initial performance test

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

2013/11/8 Josh Andler <sc...@gm...>:
> On Nov 8, 2013 12:05 AM, "Jasper van de Gronde" <th....@hc...>
> wrote:
>> SVG d string writing and reading is indeed relatively slow, and frankly
>> we shouldn't be doing it all the time (also leads to precision issues).
>> But good work getting some testing done and spending time on making
>> lib2geom maintainable!
>
> Writing helps with emergency saves though, right? Maybe reading it is more
> problematic? Shouldn't we write and not bother rereading unless necessary?

This will be problematic, because writing the path string causes
quantization of the coordinates related to the numeric precision. It's
true though that we should only write the path string once, when the
user releases the mouse.

Regards, Krzysztof

Re: [Lib2geom-devel] Path translations

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

2013/11/13 Johan Engelen <jbc...@sw...>:
> Wow, I didn't realize that it's only the HL and VL curve types.
> Not being able to transform Curves without creating a new copy is a very
> high price to pay for HL and VL...

I agree.

On the whole, path handling in 2Geom may require some redesign:

1. There is a hard requirement that the final point of a segment and
the initial point of the next segment in a Geom::Path must coincide
exactly, but each curve stores both the initial point and the final
point. For paths that contain many linear segments we store a lot of
duplicate points. We could think about storing the path data
separately in a more efficient representation and using the
Curve-derived objects only as an interface.

2. The copy-on-write thing currently in Path should probably be moved
to the PathVector level, and Path itself should be based on
boost::ptr_vector or some other pointer container.

3. Path needs to be renamed to Subpath and PathVector needs to become
a real object and be renamed to Path.

> What shall we do?
> I thought Inkscape wants HLineSegment / VLineSegment to be able to fully
> round-trip SVG-d, but when I manually enter H or V in the XML-editor, it is
> immediately converted to normal line segments...

SVG roundtrip does not strictly require having HLine / VLine as
separate classes. For instance, there could be a flag set in the
constructor.

Regards, Krzysztof

Re: [Lib2geom-devel] Path translations

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

On 13-11-2013 17:57, Krzysztof Kosiński wrote:
> 2013/11/13 Johan Engelen <jbc...@sw...>:
>> This is not possible. Because curves are not closed under Affine transform,
>> there is no operator*=(Affine). If you want to transform a Curve, you have
>> to call
>>      Curve* Curve::transformed(Affine const&)
>>
>> I'll clean up the work and commit my changes, so you can see.
> Oops, I forgot about HLineSegment / VLineSegment.
>
> I wonder whether keeping these as separate classes is worth breaking
> the assumption that curves are closed under arbitrary affines, not
> only translation and scaling.

Wow, I didn't realize that it's only the HL and VL curve types.
Not being able to transform Curves without creating a new copy is a very 
high price to pay for HL and VL...

What shall we do?
I thought Inkscape wants HLineSegment / VLineSegment to be able to fully 
round-trip SVG-d, but when I manually enter H or V in the XML-editor, it 
is immediately converted to normal line segments...

regards,
   Johan