lib2geom-devel — development discussion

[Lib2geom-devel] linux build directory size, why 4.75 GB of st* files?

[mathog <ma...@ca...>]

I just noticed today that the linux build directory is enormous, much, 
much larger than
what is seen on windows:

windows \c\progs\inkscape 552MB in 8597 files
linux   /usr/local/src/inkscape_dev4 5895 MB in 6306 files

Most of the difference is to be found in 
/usr/local/src/inkscape_dev4/src where there are
4.75 GB of storage in 31 st###### files.

Presumably from the "st" these have something to do with the STL, but 
why only on Linux?  On
both platforms it is using gcc compilers.  Is there maybe a compiler 
switch we could change
in the linux build to eliminate these?

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

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

2012/9/7 mathog <ma...@ca...>:
> On 04-Sep-2012 18:02, Krzysztof Kosiński wrote:
>> 2012/9/5 mathog <ma...@ca...>:
>
>>> Can livarot be used that way?
>>
>> Not without modifications.
>>
>> The relevant function is in splivarot.cpp, lines 115-602. You can try
>> to take everything after the input validation bits (they end around
>> line 239) and turn that into a new function that will take
>> pathvectors, then call this new function from the original.
>
> I tried that today and got it to the point where it would compile and
> create result of type "Path" (livarot Path, not Geom Path) containing
> the result.
> I can see this as
>
> std::cout << "result is: " << res->svg_dump_path() << std::endl;
>
> at that point shows a reasonable looking string for an SVG path for the
> test case:
>
>   M 135.09375 531.25 L 135.09375 799.8125 C 135.09375 799.8125 148.51709
> 791.90059 169.90625 782.96875 L 169.90625 531.25 L 135.09375 531.25 z
>
> However there seems to be no method in livarot to convert livarot Path
> to Geom::Path. So
> I went looking for methods to convert that SVG text string to
> Geom::PathVector directly
> and came up empty.  The best I have come up with so far (and this will
> not compile):
>
>      Geom::PathVector outres;
>      std::vector<Geom::Path> tpathv =
> Geom::parse_svg_path(res->svg_dump_path());
>      for (std::vector<Geom::Path>::const_iterator pit = tpathv.begin();
> pit != tpathv.end(); ++pit){
>        outres.push_back(pit);
>      }
>
> I thought Geom::PathVector was actually the same thing as
> std::vector<Geom::Path>>, but
>    outres = tpathv;
> is not accepted (it doesn't know what to do with the "=").

IIRC that's because Geom::Path is not assignable.
You are missing a dereference:

outres.push_back(*pit);

Regards, Krzysztof

Re: [Lib2geom-devel] Compilation problem

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

On 12-9-2012 23:12, Johan Engelen wrote:
> With a CMakeScript hack, I got cy2geom to build completely now.
>
> An install script is missing, so how do I test whether it actually
> works? :)  (I tried a bit, but without success).
> For an example of a "working" install script: /py2geom/CMakeLists.txt
> lines 116-...

And I've gotten it to work now (from the src dir with all the built 
files). I do get this message:
"RuntimeWarning: compiletime version 2.6 of module '_cy_primitives' does 
not match runtime version 2.7"
but that does not seem to matter :-)  I've never had Python 2.6 
installed on this PC, and I installed Cython for 2.7...

An important thing that is missing is a way to read/write SVG paths.
Can you add bindings for the read_svgd and write_svgd functions (or 
something similar?)

Let's see if we can get a very simple Python extension working with 
Inkscape (i.e. a mirror effect or something stupidly simple, but showing 
that cy2geom works)!

Cheers,
   Johan

Re: [Lib2geom-devel] Compilation problem

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

With a CMakeScript hack, I got cy2geom to build completely now.

An install script is missing, so how do I test whether it actually 
works? :)  (I tried a bit, but without success).
For an example of a "working" install script: /py2geom/CMakeLists.txt 
lines 116-...

Cheers,
   Johan


On 4-9-2012 10:46, jan pulmann wrote:
> Hi Johan,
>
> I did compile with TDM-GCC, following inkscape's instructions. Yeah, 
> manual seems a bit dated there, I guess I will fix it. I actually 
> didn't install gsl or gtk, so I don't know about that. Inkscape 
> building instructions should point to 
> http://wiki.inkscape.org/wiki/index.php/Win32Port
>
> About that error, does cython generate anything? Could you please send 
> me the _common_decl.cxx file?
> http://stackoverflow.com/questions/6985109/how-to-compile-c-code-from-cython-with-gcc 
> describes a similar problem, solution appeared to be linking the right 
> libraries, which cmake should be doing.
>
> Cheers,
> Jan Pulmann
>
>
> On Tue, Sep 4, 2012 at 12:17 AM, Johan Engelen 
> <jbc...@sw... <mailto:jbc...@sw...>> wrote:
>
>     Hi Jan,
>
>     Great that you are working on this.
>     I get the following error:
>     Linking CXX shared module _common_decl.pyd
>     c:/mingw32/bin/../lib/gcc/mingw32/4.6.1/../../../libmingw32.a(main.o):
>     In function `main':
>     C:\MinGW\msys\1.0\src\mingwrt/../mingw/main.c:73: undefined
>     reference to `WinMain@16'
>     collect2: ld returned 1 exit status
>     make[2]: *** [src/2geom/cython-bindings/cy2geom.pyd] Error 1
>
>     The README.win32 text says to download the latest mingw and
>     provides an outdated (and broken) link. For Inkscape we use
>     TDM-GCC, http://tdm-gcc.tdragon.net/ , did you try to build with
>     that one?
>
>     Cheers,
>       Johan
>
>
>
>     On 2-9-2012 17:55, jan pulmann wrote:
>>     Hi, I finally managed to build python bindings on Windows, I
>>     described the procedure in
>>     http://bazaar.launchpad.net/~lib2geom-hackers/lib2geom/trunk/view/head:/README.win32
>>     <http://bazaar.launchpad.net/%7Elib2geom-hackers/lib2geom/trunk/view/head:/README.win32>
>>
>>     Please, test and report :)
>>     Best regards
>>     Jan Pulmann
>>
>>     On Wed, Aug 22, 2012 at 10:39 PM, Johan Engelen
>>     <jbc...@sw... <mailto:jbc...@sw...>>
>>     wrote:
>>
>>         I think we are all very excited about trying the new Python
>>         bindings, so
>>         let's try to get this building on Windows !
>>
>>         Jan, can you try to build it on Windows? Or does someone else
>>         have to
>>         step up to the plate?
>>
>>         Cheers,
>>            Johan
>>
>>
>>         On 16-8-2012 22:22, Kris De Gussem wrote:
>>         > Compiles successfully now windows, with the bindings
>>         switched off.
>>         >
>>         > Regards
>>         > K.
>>         >
>>         > 2012/8/14 jan pulmann <jan...@gm...
>>         <mailto:jan...@gm...>>:
>>         >> On Mon, Aug 13, 2012 at 10:37 PM, Kris De Gussem
>>         >> <kri...@gm... <mailto:kri...@gm...>>
>>         wrote:
>>         >>>
>>         >>> Dear all
>>         >>>
>>         >>> I fail to compile lib2geom on windows (64 bit) even when
>>         Ragel and
>>         >>> cython are installed.
>>         >>> Still something is not right with cython, see output:
>>         >>>
>>         >>> ====================================
>>         >>> E:\Inkscapecode\lib2geom>cmake -G "MinGW Makefiles"
>>         >>> -- The CXX compiler identification is GNU 4.6.1
>>         >>> -- The C compiler identification is GNU 4.6.1
>>         >>> -- Check for working CXX compiler: c:/mingw/bin/g++.exe
>>         >>> -- Check for working CXX compiler: c:/mingw/bin/g++.exe
>>         -- works
>>         >>> -- Detecting CXX compiler ABI info
>>         >>> -- Detecting CXX compiler ABI info - done
>>         >>> -- Check for working C compiler: c:/mingw/bin/gcc.exe
>>         >>> -- Check for working C compiler: c:/mingw/bin/gcc.exe --
>>         works
>>         >>> -- Detecting C compiler ABI info
>>         >>> -- Detecting C compiler ABI info - done
>>         >>> -- gtk+-2.0 Includes, Compile and Link Flags: FOUND
>>         >>> -- gtkmm-2.4 Includes, Compile and Link Flags: FOUND
>>         >>> -- cairomm-1.0 Includes, Compile and Link Flags: FOUND
>>         >>> -- cairo Includes, Compile and Link Flags: FOUND
>>         >>> -- gsl Includes, Compile and Link Flags: FOUND
>>         >>> -- blas Includes, Compile and Link Flags: NOT FOUND
>>         >>> -- pycairo Includes, Compile and Link Flags: NOT FOUND
>>         >>> -- boost: FOUND  ( C:/devlibs/include )
>>         >>> -- Performing Test HAVE_SINCOS
>>         >>> -- Performing Test HAVE_SINCOS - Failed
>>         >>> -- Performing Test HAVE_ROUND
>>         >>> -- Performing Test HAVE_ROUND - Success
>>         >>> -- Performing Test HAVE_TRUNC
>>         >>> -- Performing Test HAVE_TRUNC - Success
>>         >>> CMake Warning (dev) at CMakeLists.txt:15 (LINK_DIRECTORIES):
>>         >>>    This command specifies the relative path
>>         >>>
>>         >>>      src/2geom
>>         >>>
>>         >>>    as a link directory.
>>         >>>
>>         >>>    Policy CMP0015 is not set: link_directories() treats
>>         paths relative to the
>>         >>>    source dir.  Run "cmake --help-policy CMP0015" for
>>         policy details.  Use the
>>         >>>    cmake_policy command to set the policy and suppress
>>         this warning.
>>         >>> This warning is for project developers.  Use -Wno-dev to
>>         suppress it.
>>         >>>
>>         >>> CMake Error at
>>         c:/cmake/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cm
>>         >>> ake:97 (MESSAGE):
>>         >>>    Could NOT find Cython (missing: CYTHON_EXECUTABLE)
>>         >>> Call Stack (most recent call first):
>>         >>>
>>          c:/cmake/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:288
>>         (_FPH
>>         >>> SA_FAILURE_MESSAGE)
>>         >>>  CMakeScripts/FindCython.cmake:29
>>         (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>         >>>  CMakeScripts/UseCython.cmake:76 (find_package)
>>         >>>    src/2geom/CMakeLists.txt:178 (include)
>>         >>>
>>         >>>
>>         >>> -- Configuring incomplete, errors occurred!
>>         >>> ====================================
>>         >>>
>>         >>> Is it possible that this error is resulting from the
>>         ongoing GSoc project?
>>         >>> Is something missing in my cython installation, does the
>>         cmake script
>>         >>> need some update for windows?
>>         >>> Finally, is it possible to add an option to compile
>>         without cython and
>>         >>> update both README.win32 and mingwenv.bat (with the
>>         cython and
>>         >>> possibly other missing paths)?
>>         >>>
>>         >>> Kind regards
>>         >>> K
>>         >>>
>>         >>>
>>         ------------------------------------------------------------------------------
>>         >>> Live Security Virtual Conference
>>         >>> Exclusive live event will cover all the ways today's
>>         security and
>>         >>> threat landscape has changed and how IT managers can
>>         respond. Discussions
>>         >>> will include endpoint security, mobile security and the
>>         latest in malware
>>         >>> threats.
>>         http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>         >>> _______________________________________________
>>         >>> Lib2geom-devel mailing list
>>         >>> Lib...@li...
>>         <mailto:Lib...@li...>
>>         >>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>         >>
>>         >> Hi, I added option to turn cython bindings on/off - it's
>>         off by
>>         >> default. It's pushed in the repository now, I hope it will
>>         work.
>>         >> Best regards
>>         >> Jan Pulmann
>>         >
>>         >
>>         ------------------------------------------------------------------------------
>>         > Live Security Virtual Conference
>>         > Exclusive live event will cover all the ways today's
>>         security and
>>         > threat landscape has changed and how IT managers can
>>         respond. Discussions
>>         > will include endpoint security, mobile security and the
>>         latest in malware
>>         > threats.
>>         http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>         > _______________________________________________
>>         > Lib2geom-devel mailing list
>>         > Lib...@li...
>>         <mailto:Lib...@li...>
>>         > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>         >
>>         >
>>
>>         ------------------------------------------------------------------------------
>>         Live Security Virtual Conference
>>         Exclusive live event will cover all the ways today's security and
>>         threat landscape has changed and how IT managers can respond.
>>         Discussions
>>         will include endpoint security, mobile security and the
>>         latest in malware
>>         threats.
>>         http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>         _______________________________________________
>>         Lib2geom-devel mailing list
>>         Lib...@li...
>>         <mailto:Lib...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>
>>
>
>

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

[mathog <ma...@ca...>]

On 06-Sep-2012 16:50, Shriramana Sharma wrote:
>
> The reason I ask is that I was planning on doing that myself at a
> later point in my project but since apparently you have been
> successful with it, would it be possible for you to share the
> extracted code?

Of course.  I only just got it going though so give me a day to test it 
a bit.

Regards,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

[Shriramana S. <sa...@gm...>]

On Fri, Sep 7, 2012 at 4:59 AM, mathog <ma...@ca...> wrote:
> I tried that today and got it to the point where it would compile and
> create result of type "Path"

Hi and sorry for the intermezzo, but IIUC you are trrying to extract
the boolop code from livarot (either by totally separating it from the
rest of livarot or at least by separating it from the
Inkscape-specific ("flash error message" etc) stuff)?

The reason I ask is that I was planning on doing that myself at a
later point in my project but since apparently you have been
successful with it, would it be possible for you to share the
extracted code?

Thanks!

-- 
Shriramana Sharma

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

[mathog <ma...@ca...>]

On 04-Sep-2012 18:02, Krzysztof Kosiński wrote:
> 2012/9/5 mathog <ma...@ca...>:

>> Can livarot be used that way?
>
> Not without modifications.
>
> The relevant function is in splivarot.cpp, lines 115-602. You can try
> to take everything after the input validation bits (they end around
> line 239) and turn that into a new function that will take
> pathvectors, then call this new function from the original.

I tried that today and got it to the point where it would compile and
create result of type "Path" (livarot Path, not Geom Path) containing 
the result.
I can see this as

std::cout << "result is: " << res->svg_dump_path() << std::endl;

at that point shows a reasonable looking string for an SVG path for the 
test case:

  M 135.09375 531.25 L 135.09375 799.8125 C 135.09375 799.8125 148.51709 
791.90059 169.90625 782.96875 L 169.90625 531.25 L 135.09375 531.25 z

However there seems to be no method in livarot to convert livarot Path 
to Geom::Path. So
I went looking for methods to convert that SVG text string to 
Geom::PathVector directly
and came up empty.  The best I have come up with so far (and this will 
not compile):

     Geom::PathVector outres;
     std::vector<Geom::Path> tpathv =  
Geom::parse_svg_path(res->svg_dump_path());
     for (std::vector<Geom::Path>::const_iterator pit = tpathv.begin(); 
pit != tpathv.end(); ++pit){
       outres.push_back(pit);
     }

I thought Geom::PathVector was actually the same thing as 
std::vector<Geom::Path>>, but
   outres = tpathv;
is not accepted (it doesn't know what to do with the "="). The last 
part above is also wrong and
push_back causes:

splivarot.cpp: In function ‘Geom::PathVector sp_pathvector_boolop(const 
PathVector&, const PathVector&, bool_op, fill_typ, fill_typ)’:
splivarot.cpp:319:27: error: no matching function for call to 
‘std::vector<Geom::Path>::push_back(std::vector<Geom::Path>::const_iterator&)’
splivarot.cpp:319:27: note: candidate is:
/usr/include/c++/4.6/bits/stl_vector.h:826:7: note: void 
std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = 
Geom::Path, _Alloc = std::allocator<Geom::Path>, std::vector<_Tp, 
_Alloc>::value_type = Geom::Path]
/usr/include/c++/4.6/bits/stl_vector.h:826:7: note:   no known 
conversion for argument 1 from ‘std::vector<Geom::Path>::const_iterator 
{aka __gnu_cxx::__normal_iterator<const Geom::Path*, 
std::vector<Geom::Path> >}’ to ‘const value_type& {aka const 
Geom::Path&}’

So what is the proper syntax to get from tpathv to outres???

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

[mathog <ma...@ca...>]

On 02-Sep-2012 15:03, Krzysztof Kosiński wrote:
> 2012/8/31 mathog <ma...@ca...>:

>> 1.  generate a second PathVector "pathB".  In one case this is a
>> rectangle (with corners known), and in the the other it is an 
>> elliptical
>> ring (center, inner/outer radii, minor, major unit axis vectors all
>> known).
>
> If your rectangle has corners at points a, b, c, d, do the following:
>
> Geom::Point
> Geom::Path x(a);
> x.appendNew<Geom::LineSegment>(b);
> x.appendNew<Geom::LineSegment>(c);
> x.appendNew<Geom::LineSegment>(d);
> x.close();

This one works.

>
> For an elliptical ring, do the same, but use two
> Geom::SVGEllipticalArc. The constructors are the same as for
> Geom::EllipticalArc and are documented with Doxygen comments.
>

The elliptical path is giving me conniptions.  This is what is seen 
when the "cutter" is viewed
(sorry about any line wraps):

   Geom::Path cutter;
   cutter.start(Geom::Point(250, 1000) );
// just the point
//   cutter.appendNew<Geom::SVGEllipticalArc>( 50.0, 500.0, true, true, 
M_PI,  Geom::Point(250, 1000) );
// long skinny ellipse at 1:30 on clock
//   cutter.appendNew<Geom::SVGEllipticalArc>( 50.0, 500.0, true, true, 
M_PI,  Geom::Point(250.1, 1000) );
// ditto
//   cutter.appendNew<Geom::SVGEllipticalArc>( 50.0, 500.0, true, true, 
M_PI,  Geom::Point(251.0, 1000) );
// ditto
//   cutter.appendNew<Geom::SVGEllipticalArc>( 50.0, 500.0, true, true, 
M_PI,  Geom::Point(270.0, 1000) );
// ditto
//   cutter.appendNew<Geom::SVGEllipticalArc>( 50.0, 500.0, true, true, 
M_PI/4.0,  Geom::Point(270.0, 1000) );
// long skinny elipse at 7:30 on clock
//   cutter.appendNew<Geom::SVGEllipticalArc>( 50.0, 500.0, true, true, 
0.0,  Geom::Point(270.0, 1000) );

I didn't pick these numbers arbitrarily, they were derived using the 
svg-elliptical-arc-test-toy test program. From that
I expected the first one to be a 1000 tall, 100 wide ellipse with its 
lowest point at 250,1000.  Here are
the bezier points (not the control points) for this form

   cutter.appendNew<Geom::SVGEllipticalArc>( 50.0, 500.0, true, true, 
M_PI/4.0,  Geom::Point(270.0, 1000) );

as seen when they hit the "stroke" part of my driver:

244.204    996.223
276.971    953.438
365.389    878.694
496.893    782.607
652.798    678.83
810.968    582.097
948.966    506.129
1047.23    461.692
1091.83    455.077
1076.46    487.222
1003.26    553.574
  882.61    644.735
680.347    782.252
425.566    931.384
313.999    985.863

If you plot them in Excel or gnuplot you can see the sort of ellipse 
that is coming out.  Long and skinny, but
the wrong angle.


Is there maybe a function in 2geom to convert from ellipse(center, long 
radius, short radius, rotation angle) to
this other path specification system?

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Method for "fuse two paths at a common point"

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

On 5-9-2012 17:21, mathog wrote:
>
> Geom::Piecewise<Geom::D2<Geom::SBasis> > P1; // N points assigned
> Geom::Piecewise<Geom::D2<Geom::SBasis> > P2; // M points assigned
>
> where P1's last point is the same as P2's first.  The slopes
> on both sides of that common point are correct too because P1 and P2
> are
> subpaths of a common path.  What is (pseudocode)
>
>     P1.fuse(P2);
>
> to leave P1 with N+M-1 points and the segments beginning/ending on the
> common point fused?
>
> Presumably it isn't:
>
>      P1.concat(P2);
>
> because, as I think I understand it, concat would leave two copies of
> the common point and
> would not fuse the draw operation through it.

The Piecewise class does not store points, only path segments 
(D2<SBasis> in this case). Segments are completely independent from each 
other (discontinuities are allowed, for example). So concat does what 
you wish; it only places P2 after P1, without modifying/adjusting the 
result.

Regards,
   Johan

[Lib2geom-devel] Method for "fuse two paths at a common point"

[mathog <ma...@ca...>]

Geom::Piecewise<Geom::D2<Geom::SBasis> > P1; // N points assigned
Geom::Piecewise<Geom::D2<Geom::SBasis> > P2; // M points assigned

where P1's last point is the same as P2's first.  The slopes
on both sides of that common point are correct too because P1 and P2 
are
subpaths of a common path.  What is (pseudocode)

   P1.fuse(P2);

to leave P1 with N+M-1 points and the segments beginning/ending on the 
common point fused?

Presumably it isn't:

    P1.concat(P2);

because, as I think I understand it, concat would leave two copies of 
the common point and
would not fuse the draw operation through it.

Thank you,


David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Using lib2geom for doing Stroke to Path

[Shriramana S. <sa...@gm...>]

On Tue, Sep 4, 2012 at 10:41 PM, Krzysztof Kosiński <twe...@gm...> wrote:
> 2012/9/4 Shriramana Sharma <sa...@gm...>:
>> My program is going to be GPL. I suppose that's OK? Is there some GPL
>> 2 vs GPL 3 problem involved?
>
> Most of livarot is actually public domain. The license situation of
> Inkscape is not completely clear, as currently it seems to contain
> both GPLv2-only and GPLv3-only code, but most of the files are GPLv2.

Ouch! When the GPL v2-3 transition happened, the KDE people had a
drive to convert everything to a uniform licence with people hunting
up old contributors to get them to reassign their contributions to the
new licence with the "or at your option any later version" clause.
Perhaps that should be done here.

> Yes, the unfilled parts will be included. as counterdirectional
> subpaths. 'Break apart' is equivalent to creating one Geom::PathVector
> per Geom::Path. (Note that in SVG terminology, Geom::PathVector
> corresponds to a path and Geom::Path to a subpath.)

Nice. I have some more questions but I'll tkae them to inkscape-devel
since this list is for lib2geom.

-- 
Shriramana Sharma

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

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

2012/9/5 mathog <ma...@ca...>:
> On 02-Sep-2012 15:03, Krzysztof Kosiński wrote:
>
>>> 2.  generate a third PathVector "pathC" = INTERSECTION(pathA,pathB).
>>> Just like the Intersection option on the Paths menu.
>>
>> This cannot be done with 2Geom, because the boolean operations code
>> does not work correctly. You need to use the old livarot library,
>> which is undocumented and frankly nobody understands it. Your best
>> bet
>> is copying what the Spray tool does: create an SP object containing
>> an
>> ellipse and a second SP object (SPPath) containing your path, then
>> intersecting them using the relevant function from sp-livarot.h.
>>
>
> splivarot.h functions all (or almost all) have
>
>    SPDesktop *desktop
>
> as a parameter.  That suggests  that they only operate directly on the
> drawing surface.
> This is of course just a guess, based on the parameter name.  However,
> the Spray tool you refer to is interactive,
> and it produces copies of objects on the drawing surface, and that is
> consistent with that guess.
>
> Unfortunately that is not what I need to do.  The shape intersections
> are to go to a file and must
> never be seen on the desktop.
>
> Can livarot be used that way?

Not without modifications.

The relevant function is in splivarot.cpp, lines 115-602. You can try
to take everything after the input validation bits (they end around
line 239) and turn that into a new function that will take
pathvectors, then call this new function from the original.

Regards, Krzysztof

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

[mathog <ma...@ca...>]

On 02-Sep-2012 15:03, Krzysztof Kosiński wrote:

>> 2.  generate a third PathVector "pathC" = INTERSECTION(pathA,pathB).
>> Just like the Intersection option on the Paths menu.
>
> This cannot be done with 2Geom, because the boolean operations code
> does not work correctly. You need to use the old livarot library,
> which is undocumented and frankly nobody understands it. Your best 
> bet
> is copying what the Spray tool does: create an SP object containing 
> an
> ellipse and a second SP object (SPPath) containing your path, then
> intersecting them using the relevant function from sp-livarot.h.
>

splivarot.h functions all (or almost all) have

   SPDesktop *desktop

as a parameter.  That suggests  that they only operate directly on the 
drawing surface.
This is of course just a guess, based on the parameter name.  However, 
the Spray tool you refer to is interactive,
and it produces copies of objects on the drawing surface, and that is 
consistent with that guess.

Unfortunately that is not what I need to do.  The shape intersections 
are to go to a file and must
never be seen on the desktop.

Can livarot be used that way?

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Subpath from path by length?

[mathog <ma...@ca...>]

This may not be the most efficient way to do this, but it works pretty 
well
(sorry about any wrapping that may occur when it is posted):

        // convert the path, gets its complete length, and then make a 
new path with parameter length instead of t
        Geom::Piecewise<Geom::D2<Geom::SBasis> > tmp_pathpw;  // pathv-> 
sbasis
        Geom::Piecewise<Geom::D2<Geom::SBasis> > tmp_pathpw2; // sbasis 
using arc length parameter
        Geom::Piecewise<Geom::D2<Geom::SBasis> > tmp_pathpw3; // new 
(discontinuous) path, composed of dots/dashes
        int n_dash = style->stroke_dash.n_dash;
        int i=0; //dash index
        double tlength;                                       // length 
of tmp_pathpw
        double slength=0.0;                                   // start 
of gragment
        double elength;                                       // end of 
gragment
        for (unsigned int i=0; i < pathv.size(); i++) {
           tmp_pathpw.concat(pathv[i].toPwSb());
        }
        tlength = length(tmp_pathpw,0.1);
        tmp_pathpw2 = arc_length_parametrization(tmp_pathpw);

        std::cout << "length of pathpw:"<< tlength << std::endl;
        // go around the dash array repeatedly until the entire path is 
consumed (but not beyond).
        while(slength < tlength){
           elength = slength + style->stroke_dash.dash[i++];
           if(elength > tlength)elength = tlength;
           Geom::Piecewise<Geom::D2<Geom::SBasis> > 
fragment(portion(tmp_pathpw2, slength, elength));
           slength = elength;
           slength += style->stroke_dash.dash[i++];  // the gap
           if(i>=n_dash)i=0;
           tmp_pathpw3.concat(fragment);
        }
        Geom::PathVector out_pathv = 
Geom::path_from_piecewise(tmp_pathpw3, 0.01);

The only thing it does poorly is the handling of the dash located at 
P.begin(), which is always broken into
two pieces. When viewed in inkscape it looks better, as if it was 
wrapped around that corner.  In terms of efficiency this code may not be 
so good since the portion() method presumably has to repeat position 
calculations from 0 to the previous elength, since it does not save the 
end point of the previous fragment.

Anyway, good enough.  Now on to the boolops, which is going to be 
harder since the underlying 2geom function
is apparently broken...

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Subpath from path by length?

[mathog <ma...@ca...>]

On 04-Sep-2012 13:24, Krzysztof Kosiński wrote:
> 2012/9/4 mathog <ma...@ca...>:
>> I don't see what a 0->1 "t" could be in this situation other than by
>> first calculating the length of P and then
>> making it a fraction of that length.
>
> For paths, the 't' parameter goes not from 0 to 1 but from 0 to N,
> where N is the number of curves in the path.


Ok, that makes sense.

Here is a particularly nasty typo, which compiled without even a 
warning:

        Geom::Piecewise<Geom::D2<Geom::SBasis> > tmp_pathpw;
        for (unsigned int i=0; i < pathv.size(); i++) {
           tmp_pathpw.concat(pathv[i].toPwSb());
        }
        Geom::PathVector out_pathv = 
Geom::path_from_piecewise(tmp_pathpw, 0,01);
        print_pathv(out_pathv, tf);

but exploded when it ran.  Change "0,01" to "0.01" and it works as 
expected.

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Subpath from path by length?

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

2012/9/4 mathog <ma...@ca...>:
> I don't see what a 0->1 "t" could be in this situation other than by
> first calculating the length of P and then
> making it a fraction of that length.

For paths, the 't' parameter goes not from 0 to 1 but from 0 to N,
where N is the number of curves in the path.
Regards, Krzysztof

Re: [Lib2geom-devel] Subpath from path by length?

[mathog <ma...@ca...>]

On 04-Sep-2012 12:28, Johan Engelen wrote:
> On 4-9-2012 21:14, mathog wrote:

>> subpath = make_sub_path(P,from,start,end,&trunc);


>    Have a look at Path::portion. The parameters are "time-values" 
> along
> the path I believe, not distance. To match time values with distance
> along the path, you can do an arc_length_parametrization, but I think
> that is only available for Piecewise<D2<SBasis> > paths. But it may 
> not
> be necessary to do that (expensive) operation, if you can derive your
> start/end points as time-values in a different way.

By "time-values" you mean the "t" paramter 0->1 for a Bezier curve?

Does portion() work for a path that consists of more than one Bezier 
curve? Here is a
specific example using line segments (which could be represented by 
Beziers):

P = {{0,0},{0,1},{1,1},{1,2}};

subpath = make_sub_path(P,{0,0},0.5,1.7,&trunc);

Results in subpath = {{0,0.5},{0,1},{1,1}{1,1.2}}

I don't see what a 0->1 "t" could be in this situation other than by 
first calculating the length of P and then
making it a fraction of that length.

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Subpath from path by length?

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

On Tue, Sep 04, 2012 at 12:14:05PM -0700, mathog wrote:
> How in 2geom does one do (pseudocode)
> 
> Geom::Path P;  //contains a path already, lines and/or Beziers
> 
> Geom::Point from=P.begin();
> subpath = make_sub_path(P,from,start,end,&trunc);

I think you want the portion method.  perhaps portion(max(0,s),
min(1,e)) for the clipping.

njh

Re: [Lib2geom-devel] Subpath from path by length?

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

On 4-9-2012 21:14, mathog wrote:
> How in 2geom does one do (pseudocode)
>
> Geom::Path P;  //contains a path already, lines and/or Beziers
>
> Geom::Point from=P.begin();
> subpath = make_sub_path(P,from,start,end,&trunc);
>
> where:
>
> 1. subpath is the path: from + start -> from + end, where start & end
> are distances along P
> 2. trunc is set if the subpath would have extended beyond P.end().
>
> The original path P should not be modified.

Hi David,
   Have a look at Path::portion. The parameters are "time-values" along 
the path I believe, not distance. To match time values with distance 
along the path, you can do an arc_length_parametrization, but I think 
that is only available for Piecewise<D2<SBasis> > paths. But it may not 
be necessary to do that (expensive) operation, if you can derive your 
start/end points as time-values in a different way.

Ciao,
   Johan

[Lib2geom-devel] Subpath from path by length?

[mathog <ma...@ca...>]

How in 2geom does one do (pseudocode)

Geom::Path P;  //contains a path already, lines and/or Beziers

Geom::Point from=P.begin();
subpath = make_sub_path(P,from,start,end,&trunc);

where:

1. subpath is the path: from + start -> from + end, where start & end 
are distances along P
2. trunc is set if the subpath would have extended beyond P.end().

The original path P should not be modified.

Thanks,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Compilation problem

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

Hello Jan,
   When I add "-shared" to the commandline that gives the error, it 
works. So now I have to figure out how to add that to the build...

Setting "PYTHON_ENABLE_MODULE__common_decl" and all that follow to OFF
and "PYTHON_MODULE__common_decl_BUILD_SHARED" and all that follow to ON, 
gives the following cmake error:

CMake Error at CMakeScripts/UseCython.cmake:247 (target_link_libraries):
   Cannot specify link libraries for target "_common_decl" which is not 
built
   by this project.
Call Stack (most recent call first):
   src/2geom/cython-bindings/CMakeLists.txt:55 (cython_add_module)

Thanks,
   Johan


On 4-9-2012 10:46, jan pulmann wrote:
> Hi Johan,
>
> I did compile with TDM-GCC, following inkscape's instructions. Yeah, 
> manual seems a bit dated there, I guess I will fix it. I actually 
> didn't install gsl or gtk, so I don't know about that. Inkscape 
> building instructions should point to 
> http://wiki.inkscape.org/wiki/index.php/Win32Port
>
> About that error, does cython generate anything? Could you please send 
> me the _common_decl.cxx file?
> http://stackoverflow.com/questions/6985109/how-to-compile-c-code-from-cython-with-gcc 
> describes a similar problem, solution appeared to be linking the right 
> libraries, which cmake should be doing.
>
> Cheers,
> Jan Pulmann
>
>
> On Tue, Sep 4, 2012 at 12:17 AM, Johan Engelen 
> <jbc...@sw... <mailto:jbc...@sw...>> wrote:
>
>     Hi Jan,
>
>     Great that you are working on this.
>     I get the following error:
>     Linking CXX shared module _common_decl.pyd
>     c:/mingw32/bin/../lib/gcc/mingw32/4.6.1/../../../libmingw32.a(main.o):
>     In function `main':
>     C:\MinGW\msys\1.0\src\mingwrt/../mingw/main.c:73: undefined
>     reference to `WinMain@16'
>     collect2: ld returned 1 exit status
>     make[2]: *** [src/2geom/cython-bindings/cy2geom.pyd] Error 1
>
>     The README.win32 text says to download the latest mingw and
>     provides an outdated (and broken) link. For Inkscape we use
>     TDM-GCC, http://tdm-gcc.tdragon.net/ , did you try to build with
>     that one?
>
>     Cheers,
>       Johan
>
>
>
>     On 2-9-2012 17:55, jan pulmann wrote:
>>     Hi, I finally managed to build python bindings on Windows, I
>>     described the procedure in
>>     http://bazaar.launchpad.net/~lib2geom-hackers/lib2geom/trunk/view/head:/README.win32
>>     <http://bazaar.launchpad.net/%7Elib2geom-hackers/lib2geom/trunk/view/head:/README.win32>
>>
>>     Please, test and report :)
>>     Best regards
>>     Jan Pulmann
>>
>>     On Wed, Aug 22, 2012 at 10:39 PM, Johan Engelen
>>     <jbc...@sw... <mailto:jbc...@sw...>>
>>     wrote:
>>
>>         I think we are all very excited about trying the new Python
>>         bindings, so
>>         let's try to get this building on Windows !
>>
>>         Jan, can you try to build it on Windows? Or does someone else
>>         have to
>>         step up to the plate?
>>
>>         Cheers,
>>            Johan
>>
>>
>>         On 16-8-2012 22:22, Kris De Gussem wrote:
>>         > Compiles successfully now windows, with the bindings
>>         switched off.
>>         >
>>         > Regards
>>         > K.
>>         >
>>         > 2012/8/14 jan pulmann <jan...@gm...
>>         <mailto:jan...@gm...>>:
>>         >> On Mon, Aug 13, 2012 at 10:37 PM, Kris De Gussem
>>         >> <kri...@gm... <mailto:kri...@gm...>>
>>         wrote:
>>         >>>
>>         >>> Dear all
>>         >>>
>>         >>> I fail to compile lib2geom on windows (64 bit) even when
>>         Ragel and
>>         >>> cython are installed.
>>         >>> Still something is not right with cython, see output:
>>         >>>
>>         >>> ====================================
>>         >>> E:\Inkscapecode\lib2geom>cmake -G "MinGW Makefiles"
>>         >>> -- The CXX compiler identification is GNU 4.6.1
>>         >>> -- The C compiler identification is GNU 4.6.1
>>         >>> -- Check for working CXX compiler: c:/mingw/bin/g++.exe
>>         >>> -- Check for working CXX compiler: c:/mingw/bin/g++.exe
>>         -- works
>>         >>> -- Detecting CXX compiler ABI info
>>         >>> -- Detecting CXX compiler ABI info - done
>>         >>> -- Check for working C compiler: c:/mingw/bin/gcc.exe
>>         >>> -- Check for working C compiler: c:/mingw/bin/gcc.exe --
>>         works
>>         >>> -- Detecting C compiler ABI info
>>         >>> -- Detecting C compiler ABI info - done
>>         >>> -- gtk+-2.0 Includes, Compile and Link Flags: FOUND
>>         >>> -- gtkmm-2.4 Includes, Compile and Link Flags: FOUND
>>         >>> -- cairomm-1.0 Includes, Compile and Link Flags: FOUND
>>         >>> -- cairo Includes, Compile and Link Flags: FOUND
>>         >>> -- gsl Includes, Compile and Link Flags: FOUND
>>         >>> -- blas Includes, Compile and Link Flags: NOT FOUND
>>         >>> -- pycairo Includes, Compile and Link Flags: NOT FOUND
>>         >>> -- boost: FOUND  ( C:/devlibs/include )
>>         >>> -- Performing Test HAVE_SINCOS
>>         >>> -- Performing Test HAVE_SINCOS - Failed
>>         >>> -- Performing Test HAVE_ROUND
>>         >>> -- Performing Test HAVE_ROUND - Success
>>         >>> -- Performing Test HAVE_TRUNC
>>         >>> -- Performing Test HAVE_TRUNC - Success
>>         >>> CMake Warning (dev) at CMakeLists.txt:15 (LINK_DIRECTORIES):
>>         >>>    This command specifies the relative path
>>         >>>
>>         >>>      src/2geom
>>         >>>
>>         >>>    as a link directory.
>>         >>>
>>         >>>    Policy CMP0015 is not set: link_directories() treats
>>         paths relative to the
>>         >>>    source dir.  Run "cmake --help-policy CMP0015" for
>>         policy details.  Use the
>>         >>>    cmake_policy command to set the policy and suppress
>>         this warning.
>>         >>> This warning is for project developers.  Use -Wno-dev to
>>         suppress it.
>>         >>>
>>         >>> CMake Error at
>>         c:/cmake/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cm
>>         >>> ake:97 (MESSAGE):
>>         >>>    Could NOT find Cython (missing: CYTHON_EXECUTABLE)
>>         >>> Call Stack (most recent call first):
>>         >>>
>>          c:/cmake/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:288
>>         (_FPH
>>         >>> SA_FAILURE_MESSAGE)
>>         >>>  CMakeScripts/FindCython.cmake:29
>>         (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>>         >>>  CMakeScripts/UseCython.cmake:76 (find_package)
>>         >>>    src/2geom/CMakeLists.txt:178 (include)
>>         >>>
>>         >>>
>>         >>> -- Configuring incomplete, errors occurred!
>>         >>> ====================================
>>         >>>
>>         >>> Is it possible that this error is resulting from the
>>         ongoing GSoc project?
>>         >>> Is something missing in my cython installation, does the
>>         cmake script
>>         >>> need some update for windows?
>>         >>> Finally, is it possible to add an option to compile
>>         without cython and
>>         >>> update both README.win32 and mingwenv.bat (with the
>>         cython and
>>         >>> possibly other missing paths)?
>>         >>>
>>         >>> Kind regards
>>         >>> K
>>         >>>
>>         >>>
>>         ------------------------------------------------------------------------------
>>         >>> Live Security Virtual Conference
>>         >>> Exclusive live event will cover all the ways today's
>>         security and
>>         >>> threat landscape has changed and how IT managers can
>>         respond. Discussions
>>         >>> will include endpoint security, mobile security and the
>>         latest in malware
>>         >>> threats.
>>         http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>         >>> _______________________________________________
>>         >>> Lib2geom-devel mailing list
>>         >>> Lib...@li...
>>         <mailto:Lib...@li...>
>>         >>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>         >>
>>         >> Hi, I added option to turn cython bindings on/off - it's
>>         off by
>>         >> default. It's pushed in the repository now, I hope it will
>>         work.
>>         >> Best regards
>>         >> Jan Pulmann
>>         >
>>         >
>>         ------------------------------------------------------------------------------
>>         > Live Security Virtual Conference
>>         > Exclusive live event will cover all the ways today's
>>         security and
>>         > threat landscape has changed and how IT managers can
>>         respond. Discussions
>>         > will include endpoint security, mobile security and the
>>         latest in malware
>>         > threats.
>>         http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>         > _______________________________________________
>>         > Lib2geom-devel mailing list
>>         > Lib...@li...
>>         <mailto:Lib...@li...>
>>         > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>         >
>>         >
>>
>>         ------------------------------------------------------------------------------
>>         Live Security Virtual Conference
>>         Exclusive live event will cover all the ways today's security and
>>         threat landscape has changed and how IT managers can respond.
>>         Discussions
>>         will include endpoint security, mobile security and the
>>         latest in malware
>>         threats.
>>         http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>         _______________________________________________
>>         Lib2geom-devel mailing list
>>         Lib...@li...
>>         <mailto:Lib...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>
>>
>
>

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

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

2012/9/4 mathog <ma...@ca...>:
> Both 2geom and CGAL need boost, so there's no real difference in the
> dependencies.

Looks like the Debian CGAL package needs not only the header-only part
of Boost, but also Boost.Thread, QT4 and GMP, which are not on our
dependency list. Probably some of these dependencies could be removed
in a custom build.

Regards, Krzysztof

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

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

2012/9/4 mathog <ma...@ca...>:
>   The next example computes the intersection of two general polygons bounded
> by Bézier curves read from two
>   input files respectively. The default input files our example uses
> (char_g.dat and char_m.dat) define two
>   general polygons shaped in the form of the characters g and m in the Times
> New Roman font respectively. Their
>   intersection comprises nine simple polygons, as depicted to the right.

This example splits up each Bezier curve into x-monotone fragments.
Maybe CGAL's algorithm could be modified so that these splits are only
'virtual' and when the final polygon is constructed, only the
necessary subdivisions are performed?

We could use CGAL to implement some functions of 2Geom, but direct use
of CGAL in Inkscape would be extremely tedious.

Regards, Krzysztof

Re: [Lib2geom-devel] lib2geom basics: define pathvector, define ellipse, define intersection

[mathog <ma...@ca...>]

On 04-Sep-2012 10:04, Krzysztof Kosiński wrote:
> 2012/9/4 mathog <ma...@ca...>:
>> Thanks for the reply.  The option of having to use livarot, which 
>> "nobody
>> understands" is not
>> terribly appealing, and 2geom has its own issues, notably a broken 
>> boolean
>> shape method.  Is
>> there some reason the inkscape project is creating 2geom instead of 
>> using
>> CGAL?  CGAL seems to do
>> the same things and is in a more advanced state of development.  For
>> instance, here is the documentation
>> for boolean operations:
>>
>> 
>> http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Boolean_set_operations_2/Chapter_main.html
>
> CGAL does not contain boolean operations on paths, only on linear
> polygons and polygons with circular segments.

It sure looks like it does what you say it doesn't.  See the "g"/"m" 
example about 3/4 of the way down the link
above. As near as I can tell the CGAL use of "general polygon" allows 
"traits" to be associated with each face, so that these
may be just a line, or something more complex, like a Bezier curve.

http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Arrangement_on_surface_2/Chapter_main.html#Subsection_32.6.7

So that it can do boolean operations on Bezier bounded shapes (general 
polygons in their parlance).  Quote from the first link, near the g/m 
intersection picture:

   Instantiating the arrangement-traits Arr_traits_2 above with the 
traits class that handle Bézier curves
   Arr_bezier_traits_2, results with the definition of a general-polygon 
set type that can be used to perform
   Boolean set-operations on point sets bounded by Bézier curves.

   The next example computes the intersection of two general polygons 
bounded by Bézier curves read from two
   input files respectively. The default input files our example uses 
(char_g.dat and char_m.dat) define two
   general polygons shaped in the form of the characters g and m in the 
Times New Roman font respectively. Their
   intersection comprises nine simple polygons, as depicted to the 
right.

Granted CGAL is pretty darn complex.  Also the documentation is in a 
technical jargon that I am not at all familiar with,
and where I constantly have the feeling that I am missing the point.  
For instance, they emphasize that the Bezier control points are rational 
numbers, but since floats are represented in the computer by a fixed 
number of bits, these values
could hardly be anything else.  (Well, excluding infinity and NAN.)

Regards,

David Mathog
ma...@ca...
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: [Lib2geom-devel] Compilation problem

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

2012/9/4 Shriramana Sharma <sa...@gm...>:
> On Tue, Sep 4, 2012 at 3:47 AM, Johan Engelen
> <jbc...@sw...> wrote:
>> For Inkscape we use TDM-GCC, http://tdm-gcc.tdragon.net/ , did you try to
>> build with that one?
>
> Any particular reason why TDM GCC and not the official MinGW GCC?

TDM-GCC has a version that uses the setjmp/longjmp exception handling
method, which is currently the only one that works when throwing
across DLL boundaries with a statically-linked libgcc (the default).
The official MinGW version uses Dwarf2 exception handling and caused
crashes when loading corrupted PNGs.

Regards, Krzysztof