lib2geom-devel — development discussion

[Lib2geom-devel] path::toPwSb for closed paths

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

Hi all,

Have a look at rev. 1175. I think I made a mistake there. Right now, the closing segment of a closed path is not added to pwd2. So LPEs do not function correctly with closed paths.
I can't remember why I did rev. 1175; it does not say which bug specifically it is supposed to fix.

Do you guys think rev 1175 should be reverted?

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] [Inkscape-devel] newSVGEllipticalArcimplementation merged intopath.h

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

> -----Original Message-----
> From: lib...@li... 
> [mailto:lib...@li...] On 
> Behalf Of Maximilian Albert
> Sent: woensdag 16 april 2008 11:40
> To: lib...@li...
> Subject: Re: [Lib2geom-devel] [Inkscape-devel] 
> newSVGEllipticalArcimplementation merged intopath.h
> 
> J.B...@ew... schrieb:
> > Hi Marco,
> > 
> > I just committed it to Inkscape trunk (did a 2geom re-sync).
> 
> I believe that every enhancement of 2geom and further 
> integration into Inkscape is a great improvement. Thanks to 
> everyone for your work on this! And just in case I haven't 
> mentioned it recently -- 2geom is simply awesome to work with. :)
> 
> However, I have noticed that drawing operations are 
> considerably slower when 2geom is used. The ellipse tool with 
> the new code always lags a bit behind the mouse pointer.

Which ellipse tool do you mean? Inkscape does not use 2geom's ellipse calculations, except for LPEs in rare cases.

> I also encountered this when working on my simplistic "tech 
> drawing circle LPE" a while ago. It's not particularly 
> annoying but clearly noticeable. Is this issue inherent? Or 
> is it just due to me using the data structures in the wrong 
> way or calling the "wrong" (i.e., computationally expensive) 
> kinds of functions?

LPE is a bit slow because of all the type conversions involved. Switching Inkscape to use 2geom types will solve this. The conversion from Inkscape to 2geom is done through an SVGD string...

Regards,
Johan

Re: [Lib2geom-devel] [Inkscape-devel] newSVGEllipticalArcimplementation merged intopath.h

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

J.B...@ew... schrieb:
> Hi Marco,
> 
> I just committed it to Inkscape trunk (did a 2geom re-sync).

I believe that every enhancement of 2geom and further integration into 
Inkscape is a great improvement. Thanks to everyone for your work on 
this! And just in case I haven't mentioned it recently -- 2geom is 
simply awesome to work with. :)

However, I have noticed that drawing operations are considerably slower 
when 2geom is used. The ellipse tool with the new code always lags a bit 
behind the mouse pointer. I also encountered this when working on my 
simplistic "tech drawing circle LPE" a while ago. It's not particularly 
annoying but clearly noticeable. Is this issue inherent? Or is it just 
due to me using the data structures in the wrong way or calling the 
"wrong" (i.e., computationally expensive) kinds of functions?

Max

Re: [Lib2geom-devel] new SVGEllipticalArc implementation merged intopath.h

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

Good work, Marco!  Has this been committed to both 2geom and inkscape?

-mental

[Lib2geom-devel] new SVGEllipticalArc implementation merged into path.h

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

I merged my implementation of the SVGEllipticalArc class into path.h
substituting the old one. Some method lacks of a native implementation,
yet and it relies on a conversion to SBasisCurve, but the class is fully
working (there isn't any not_implemented exception thrown any more).
Moreover I commit a new version of the svg-elliptic-arc-toy,
with the ability of testing the portion method too.


PAY ATTENTION !
I want to point out that I modified the src/CMakeList.txt file,
adding some line of code in order to find out which version of ragel
is installed. This is needed because starting from version 5.18
the ragel package substituted the command rlcodegen with the rlgen-cd
command as specific code generator back-end for C, C++ and D languages.
If you'll get into troubles when you build the library you'd look
that you have the ragel package installed.
Anyway in case of problem you can send me a mail or contact me on
the lib2geom channel.

Regards,
Marco

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

Re: [Lib2geom-devel] [Inkscape-devel] svg elliptic toy improvement

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

I think if your implementation works, you can remove the SVGEllipticalArc code from path.h/path.cpp because it is not working there. And then plug-in your code.
Can you move the lengthy functions from .h to .cpp?
What's also good is that you don't overload the reverse() method anymore, which at the moment causes a lot of unnecessary hiding warnings during compilation. 

Good work!
Regards,
Johan

(btw. good that you post here, because it might influence your GSoC proposal. But please also CC to lib...@li...)
 

> -----Original Message-----
> From: ink...@li... 
> [mailto:ink...@li...] On 
> Behalf Of Marco
> Sent: donderdag 3 april 2008 17:22
> To: ink...@li...
> Cc: Aaron Spike; njh
> Subject: [Inkscape-devel] svg elliptic toy improvement
> 
> 
> A new release of the svg elliptic toy is available on the 
> lib2geom svn repository (svg-elliptic-arc-toy.cpp).
> I put the SVGEllipticalArc class in a separate file 
> (src/svg-elliptical-arc.h).
> Now you can control interactively through 3 sliders the x-ray 
> length, the y-ray length and the x-axis rotation angle. 
> Moreover there are
> 2 toggle buttons for swithing on/off the the large-arc and 
> the sweep flags.
> Finally instead of the two circles, now the two valid ellipse 
> supports for the arc are drawn.
> 
> Btw I've some issue with cmake because it doesn't find any 
> ragel or rlcodegen command (they are specified in the 
> CMakeList.txt file under the src folder ). Usually I solve 
> the problem commenting out the related lines but this is 
> becoming a bit annoying to manage everytime I need to commit 
> my changes.
> Another issue regards the svg-path-parser.cpp file, because I 
> need to change the line:
> #include <glib.h>
> with:
> #include <glib-2.0/glib.h>
> but problably this is due to the fact that we're using 
> different linux distro. (I use mandriva 2008)
> 
> 
> Regards,
> Marco Cecchetti
> 
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> 
> --------------------------------------------------------------
> -----------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for just about 
> anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.n
et/marketplace
> _______________________________________________
> Inkscape-devel mailing list
> Ink...@li...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 

Re: [Lib2geom-devel] [Inkscape-devel] GSoC tag-team for lib2geomintegration

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

> -----Original Message-----
> From: lib...@li... 
> [mailto:lib...@li...] On 
> Behalf Of bulia byak
> Sent: vrijdag 21 maart 2008 20:40
> To: Engelen, J.B.C. (Johan)
> Cc: ink...@li...; 
> lib...@li...
> Subject: Re: [Lib2geom-devel] [Inkscape-devel] GSoC tag-team 
> for lib2geomintegration
> 
> On Fri, Mar 21, 2008 at 4:18 PM,  
> <J.B...@ew...> wrote:
> >  Yesterday I had a chat with mgsloan about lib2geom 
> integration for GSoC'08.
> 
> A general question: has anyone compared performance of 2geom 
> with that of livarot for those tasks where we use livarot - 
> boolops, offsets, etc?

I haven't heard of it. It's a good question :S

> 
> Also, I'd like to nominate the tweak tool as a candidate for 
> the conversion :) It uses livarot black magic and there are 
> many problems with that (precision, autoclosing of open 
> paths) that I have no idea how to fix with livarot.

I think anything is nominated! I'll make a special note to get the tweak tool early in the process ;)

-johan

Re: [Lib2geom-devel] [Inkscape-devel] GSoC tag-team for lib2geom integration

[Bryce H. <br...@ca...>]

On Fri, Mar 21, 2008 at 08:18:30PM +0100, J.B...@ew... wrote:
> Hi all,
> 
> Yesterday I had a chat with mgsloan about lib2geom integration for GSoC'08. We spoke about working together on it. He knows 2geom very well, I know Inkscape well and have worked with 2geom a lot for LPE. Because complete conversion to 2geom is a big task, where 2geom issues can become apparant, I think it is nice to have a 2geom developer working on it aswell (although I did commit some small things to 2geom, I do not count myself as a real 2geom developer). This way, we can both work and discuss things where we are uncertain. I hope to have a somewhat longer discussion with mgsloan within the next couple of days.
> 
> How do people feel about this?
> 
> Apart from having a 2-man team on lib2geom integration: I know I have been very brief in my gsoc proposal as blueprint. I am thinking about
>  1. writing test code (cxxtest)
>  2. integrating lib2geom in steps, for example per tool or per feature
>  3. switching to 2geom path representation in inkscape core is advanced task and should be tried later in the project
>  4. I'd rather *not* work in a branch, because then people that code new things will use 2geom instead of me/us having to recode new things to 2geom. (conflicts etc abound)
>  5. Release lib2geom after integration is complete. Not before integration is complete because of things that might be missing or bugged in 2geom.
> 

This all sounds good, and appropriate for fitting in with our
refactoring goals.  I hope there are also plans on doing some
pre-releases of 2geom, so that if there are any issues that come up
during linking/packaging/autoconf work, they can be addressed ahead of
time.

Bryce

Re: [Lib2geom-devel] [Inkscape-devel] GSoC tag-team for lib2geom integration

[bulia b. <bul...@gm...>]

On Fri, Mar 21, 2008 at 4:18 PM,  <J.B...@ew...> wrote:
>  Yesterday I had a chat with mgsloan about lib2geom integration for GSoC'08.

A general question: has anyone compared performance of 2geom with that
of livarot for those tasks where we use livarot - boolops, offsets,
etc?

Also, I'd like to nominate the tweak tool as a candidate for the
conversion :) It uses livarot black magic and there are many problems
with that (precision, autoclosing of open paths) that I have no idea
how to fix with livarot.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

[Lib2geom-devel] GSoC tag-team for lib2geom integration

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

Hi all,

Yesterday I had a chat with mgsloan about lib2geom integration for GSoC'08. We spoke about working together on it. He knows 2geom very well, I know Inkscape well and have worked with 2geom a lot for LPE. Because complete conversion to 2geom is a big task, where 2geom issues can become apparant, I think it is nice to have a 2geom developer working on it aswell (although I did commit some small things to 2geom, I do not count myself as a real 2geom developer). This way, we can both work and discuss things where we are uncertain. I hope to have a somewhat longer discussion with mgsloan within the next couple of days.

How do people feel about this?

Apart from having a 2-man team on lib2geom integration: I know I have been very brief in my gsoc proposal as blueprint. I am thinking about
 1. writing test code (cxxtest)
 2. integrating lib2geom in steps, for example per tool or per feature
 3. switching to 2geom path representation in inkscape core is advanced task and should be tried later in the project
 4. I'd rather *not* work in a branch, because then people that code new things will use 2geom instead of me/us having to recode new things to 2geom. (conflicts etc abound)
 5. Release lib2geom after integration is complete. Not before integration is complete because of things that might be missing or bugged in 2geom.

Thanks for your opinion,
Johan

[Lib2geom-devel] Hidden method warning

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

Hi all,

There is a small problem with the Curve class:

src/2geom/path.h:74: warning: 'virtual Geom::Curve* Geom::Curve::reverse() const' was hidden src/2geom/path.h:319: warning:   by 'Geom::Curve* Geom::SVGEllipticalArc::reverse(double, double) const'

http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9

Could someone please try to fix this warning?

Thanks a lot,
Johan

Re: [Lib2geom-devel] Impossible to correctly scale LPE stitch subcurves?

[<Jea...@ma...>]

Nice! I think Johan's solution is acceptable for 0.46.

I am still thinking about having the output in a group. This would have
some advantages. Of course, the transform would automatically go into the
tranform attribute, whatever the preferences of inkscape are... But more
importantly, some effects might want to produce distinct svg objects.

For instance, pattern-along-path a wavy pattern on a square. You obtain
a wavy square with a fancy stroke, but what if you want to fill it?
Filling the orginal square is not correct, while filling the wavy one only
modifies the pattern fill. A 'pattern-stroke' effect would produce two
objects: the stroke and the region to be filled...(any other example???
this might not be easy to implement!!!...).

I don't know if it is relevant. It might confuse users as well...


As for the transform pb, one more remark: notice that the transform
attributes wont solve the problem when dealing with several effects: a
priori an object with n effects might require to store up to n
transforms... (that was why I suggested to have simple "tranfom effects")

Anyway, all this does not concern 0.46 nor bug fixing but 0.47!
JFB.


> It is, in a way, already fixed.
>
> To clearify, the problem is not in obtaining the output, it's in editing
> it. There is no discussion about how the result should look with certain
> parameters (this is good, because it therefore will stay the same in
> future versions).
> The easy solution is setting Inkscape to transformations preserved
> (transform attribute is written to paths, instead of recalculating path
> data), this works splendid and gives visually correct scaling. I have
> this turned off, and therefore the original path data *is* recalculated
> which gives visually incorrect editing problems.
> Maybe this transform preserving should be a separate parameter for LPEs,
> with a toggle in the dialog to turn it on and off quickly.
>
> -Johan
>
>
>
>> -----Original Message-----
>> From: lib...@li...
>> [mailto:lib...@li...] On
>> Behalf Of Jea...@ma...
>> Sent: zondag 20 januari 2008 10:29
>> To: lib...@li...
>> Subject: Re: [Lib2geom-devel] Impossible to correctly scale
>> LPE stitch subcurves?
>>
>> Hi!
>> I think that when trying to apply transform to an object
>> having a path effect, the transform should go into a
>> "tranform" attribute.
>>
>> Maybe the result of a path effect could be a group containing
>> the output.
>> I think this would "solve" the problem, but this would also
>> open the way to more sophisticated outputs (?)
>>
>> This also means that the transform attribute should be
>> applied to the path before the effect is computed, and
>> removed from the output...
>>
>> A better fix would be as follows: in the future, we can dream
>> of multiple effects applied one after the other. A transform
>> is then simply a "linear effect". Applying a new transform
>> would simply mean insert a new "transform effect" at the end
>> of the list. You could navigate the list (or even better, the
>> tree as we might want to breaks things into components), and
>> the transformation would go at the current level...
>>
>>
>> > Please ignore my earlier mail because it was sent too soon. :-(
>> >
>> >
>> > Hello all,
>> >
>> > I am trying to fix transformation behavior for LPE (translation,
>> > scaling, rotation). I think I found a fundamental problem.
>> >
>> > Take Stitch Subcurves. Let's say we are stitching between a
>> straight
>> > horizontal line, and a line with a horizontal and angled part:
>> > Because stitching is equidistant, the stitch start points would be:
>> >
>> >     ____o_____________o
>> >    /
>> >   /
>> >  /
>> > o
>> >
>> > o__________o___________o
>> >
>> > Note that the distance between stitch points is constant
>> *along* the
>> > length of the line (not just the distance in the
>> x-direction as this
>> > would not work in general)
>> >
>> > Now, after scaling in the Y direction:
>> >
>> >     __________________o
>> >    /
>> >    |
>> >    |
>> >    o
>> >    |
>> >    |
>> >    |
>> >   /
>> >  |
>> >  |
>> >  |
>> >  |
>> >  |
>> >  |
>> >  /
>> > o
>> >
>> > o__________o___________o
>> >
>> > Can you spot the problem? The 2nd line has shifted position
>> along the
>> > line, because the distance along the angled part of the topline
>> > changed dramatically.
>> > For 'correct visual scaling' the result should have been:
>> >
>> >     ____o_____________o
>> >    /
>> >    |
>> >    |
>> >    |
>> >    |
>> >    |
>> >    |
>> >   /
>> >  |
>> >  |
>> >  |
>> >  |
>> >  |
>> >  |
>> >  /
>> > o
>> >
>> > o__________o___________o
>> >
>> > This however can never be the result of any stitch subpath, because
>> > the stitch start points are not equidistant (unless using
>> the variance
>> > parameters and being very very lucky).
>> >
>> > I have attached an SVG for you to try with the latest inkscape SVN.
>> > Note that this problem exists regardless of the "scale
>> width relative"
>> > setting.
>> >
>> > Thanks for any comment on how to "fix" this.
>> >
>> > kind regards,
>> > Johan
>> >
>> ----------------------------------------------------------------------
>> > --- 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
>> >
>>
>>
>> --------------------------------------------------------------
>> -----------
>> 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
>>
>
> -------------------------------------------------------------------------
> 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
>

Re: [Lib2geom-devel] Impossible to correctly scale LPE stitch subcurves?

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

Good to hear from you, JFB!

On Sun, 20 Jan 2008 Jea...@ma... wrote:

> A better fix would be as follows: in the future, we can dream of multiple
> effects applied one after the other. A transform is then simply a "linear
> effect". Applying a new transform would simply mean insert a new
> "transform effect" at the end of the list. You could navigate the list (or
> even better, the tree as we might want to breaks things into components),
> and the transformation would go at the current level...

If the transform is invertible we could even allow edits on the 
transformed output (or part way through).  I imagine there is a dag based 
propagation solver out there which would handle this...

njh

Re: [Lib2geom-devel] Impossible to correctly scale LPE stitch subcurves?

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

It is, in a way, already fixed.

To clearify, the problem is not in obtaining the output, it's in editing
it. There is no discussion about how the result should look with certain
parameters (this is good, because it therefore will stay the same in
future versions).
The easy solution is setting Inkscape to transformations preserved
(transform attribute is written to paths, instead of recalculating path
data), this works splendid and gives visually correct scaling. I have
this turned off, and therefore the original path data *is* recalculated
which gives visually incorrect editing problems.
Maybe this transform preserving should be a separate parameter for LPEs,
with a toggle in the dialog to turn it on and off quickly.

-Johan



> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of Jea...@ma...
> Sent: zondag 20 januari 2008 10:29
> To: lib...@li...
> Subject: Re: [Lib2geom-devel] Impossible to correctly scale=20
> LPE stitch subcurves?
>=20
> Hi!
> I think that when trying to apply transform to an object=20
> having a path effect, the transform should go into a=20
> "tranform" attribute.
>=20
> Maybe the result of a path effect could be a group containing=20
> the output.
> I think this would "solve" the problem, but this would also=20
> open the way to more sophisticated outputs (?)
>=20
> This also means that the transform attribute should be=20
> applied to the path before the effect is computed, and=20
> removed from the output...
>=20
> A better fix would be as follows: in the future, we can dream=20
> of multiple effects applied one after the other. A transform=20
> is then simply a "linear effect". Applying a new transform=20
> would simply mean insert a new "transform effect" at the end=20
> of the list. You could navigate the list (or even better, the=20
> tree as we might want to breaks things into components), and=20
> the transformation would go at the current level...
>=20
>=20
> > Please ignore my earlier mail because it was sent too soon. :-(
> >
> >
> > Hello all,
> >
> > I am trying to fix transformation behavior for LPE (translation,=20
> > scaling, rotation). I think I found a fundamental problem.
> >
> > Take Stitch Subcurves. Let's say we are stitching between a=20
> straight=20
> > horizontal line, and a line with a horizontal and angled part:
> > Because stitching is equidistant, the stitch start points would be:
> >
> >     ____o_____________o
> >    /
> >   /
> >  /
> > o
> >
> > o__________o___________o
> >
> > Note that the distance between stitch points is constant=20
> *along* the=20
> > length of the line (not just the distance in the=20
> x-direction as this=20
> > would not work in general)
> >
> > Now, after scaling in the Y direction:
> >
> >     __________________o
> >    /
> >    |
> >    |
> >    o
> >    |
> >    |
> >    |
> >   /
> >  |
> >  |
> >  |
> >  |
> >  |
> >  |
> >  /
> > o
> >
> > o__________o___________o
> >
> > Can you spot the problem? The 2nd line has shifted position=20
> along the=20
> > line, because the distance along the angled part of the topline=20
> > changed dramatically.
> > For 'correct visual scaling' the result should have been:
> >
> >     ____o_____________o
> >    /
> >    |
> >    |
> >    |
> >    |
> >    |
> >    |
> >   /
> >  |
> >  |
> >  |
> >  |
> >  |
> >  |
> >  /
> > o
> >
> > o__________o___________o
> >
> > This however can never be the result of any stitch subpath, because=20
> > the stitch start points are not equidistant (unless using=20
> the variance=20
> > parameters and being very very lucky).
> >
> > I have attached an SVG for you to try with the latest inkscape SVN.
> > Note that this problem exists regardless of the "scale=20
> width relative"
> > setting.
> >
> > Thanks for any comment on how to "fix" this.
> >
> > kind regards,
> > Johan
> >=20
> ----------------------------------------------------------------------
> > --- This SF.net email is sponsored by: Microsoft Defy all=20
> challenges.=20
> > Microsoft(R) Visual Studio 2008.
> >=20
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________
> > ________________________________
> > Lib2geom-devel mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> >
>=20
>=20
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all=20
> 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
>=20

Re: [Lib2geom-devel] Impossible to correctly scale LPE stitch subcurves?

[<Jea...@ma...>]

Hi!
I think that when trying to apply transform to an object having a path
effect, the transform should go into a "tranform" attribute.

Maybe the result of a path effect could be a group containing the output.
I think this would "solve" the problem, but this would also open the way
to more sophisticated outputs (?)

This also means that the transform attribute should be applied to the path
before the effect is computed, and removed from the output...

A better fix would be as follows: in the future, we can dream of multiple
effects applied one after the other. A transform is then simply a "linear
effect". Applying a new transform would simply mean insert a new
"transform effect" at the end of the list. You could navigate the list (or
even better, the tree as we might want to breaks things into components),
and the transformation would go at the current level...


> Please ignore my earlier mail because it was sent too soon. :-(
>
>
> Hello all,
>
> I am trying to fix transformation behavior for LPE (translation,
> scaling, rotation). I think I found a fundamental problem.
>
> Take Stitch Subcurves. Let's say we are stitching between a straight
> horizontal line, and a line with a horizontal and angled part:
> Because stitching is equidistant, the stitch start points would be:
>
>     ____o_____________o
>    /
>   /
>  /
> o
>
> o__________o___________o
>
> Note that the distance between stitch points is constant *along* the
> length of the line (not just the distance in the x-direction as this
> would not work in general)
>
> Now, after scaling in the Y direction:
>
>     __________________o
>    /
>    |
>    |
>    o
>    |
>    |
>    |
>   /
>  |
>  |
>  |
>  |
>  |
>  |
>  /
> o
>
> o__________o___________o
>
> Can you spot the problem? The 2nd line has shifted position along the
> line, because the distance along the angled part of the topline changed
> dramatically.
> For 'correct visual scaling' the result should have been:
>
>     ____o_____________o
>    /
>    |
>    |
>    |
>    |
>    |
>    |
>   /
>  |
>  |
>  |
>  |
>  |
>  |
>  /
> o
>
> o__________o___________o
>
> This however can never be the result of any stitch subpath, because the
> stitch start points are not equidistant (unless using the variance
> parameters and being very very lucky).
>
> I have attached an SVG for you to try with the latest inkscape SVN.
> Note that this problem exists regardless of the "scale width relative"
> setting.
>
> Thanks for any comment on how to "fix" this.
>
> kind regards,
> Johan
> -------------------------------------------------------------------------
> 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
>

Re: [Lib2geom-devel] [Inkscape-devel] Impossible to correctly scale LPE stitch subcurves?

[Josh A. <sc...@gm...>]

MenTaLguY wrote:
> On Thu, 17 Jan 2008 23:10:14 +0100, J.B...@ew... wrote:
>   
>> Please ignore my earlier mail because it was sent too soon. :-(
>>
>> Hello all,
>>
>> I am trying to fix transformation behavior for LPE (translation,
>> scaling, rotation). I think I found a fundamental problem.
>>     
>
> It seems like stitching needs to be done in un-transformed space?
>
> -mental
>  
>   

Well, the question is if it's more important to be mathematically 
correct or "visually" correct. What it does now is what I would expect 
it to do. Perhaps I'm just more technical in how I perceive things. But, 
I'd like to know what others think.

I've attached Johan's file with a changed visual example and it's an 
actual lpe this time. It looks the same as his, the difference is that I 
used the node tool to move the bottom guide path to where it should be 
and NOT changing the size or orientation of the top line. If either 
guide path of the stitched curves is changed, I expect every little 
change to be reflected visually. At this point, I probably have more 
experience with this feature than anyone else and I can tell you it's 
always done what I've expected. Then again, could be my technical mind 
and workflow.

So, imho, what he's looking for works as it should, the math is all 
correct. It's really just about how you make it happen. If I'm not 
incorrect, a similar issue would be the reason there's a toggle button 
for scaling the radii of rounded corners on rectangles (what people 
expect or need when transforming is different, it's really a convenience 
option imho). Anyone else want to chime in?

-Josh

Re: [Lib2geom-devel] [Inkscape-devel] Impossible to correctly scale LPE stitch subcurves?

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

On Thu, 17 Jan 2008 23:10:14 +0100, J.B...@ew... wrote:
> Please ignore my earlier mail because it was sent too soon. :-(
> 
> Hello all,
> 
> I am trying to fix transformation behavior for LPE (translation,
> scaling, rotation). I think I found a fundamental problem.

It seems like stitching needs to be done in un-transformed space?

-mental
 

Re: [Lib2geom-devel] [Inkscape-devel] Impossible to correctly scale LPE stitch subcurves?

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

One solution might be to add transforms to the path, instead of
transforming the path itself (the so-called "preserve transformations"
option in preferences).

[Lib2geom-devel] Impossible to correctly scale LPE stitch subcurves?

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

Please ignore my earlier mail because it was sent too soon. :-(


Hello all,

I am trying to fix transformation behavior for LPE (translation,
scaling, rotation). I think I found a fundamental problem.

Take Stitch Subcurves. Let's say we are stitching between a straight
horizontal line, and a line with a horizontal and angled part:
Because stitching is equidistant, the stitch start points would be:

    ____o_____________o
   /
  /
 /
o

o__________o___________o

Note that the distance between stitch points is constant *along* the
length of the line (not just the distance in the x-direction as this
would not work in general)

Now, after scaling in the Y direction:

    __________________o
   /
   |
   |
   o
   |
   |
   |
  /
 |
 |
 |
 |
 |
 |
 /
o

o__________o___________o

Can you spot the problem? The 2nd line has shifted position along the
line, because the distance along the angled part of the topline changed
dramatically.
For 'correct visual scaling' the result should have been:

    ____o_____________o
   /
   |
   |
   |
   |
   |
   |
  /
 |
 |
 |
 |
 |
 |
 /
o

o__________o___________o

This however can never be the result of any stitch subpath, because the
stitch start points are not equidistant (unless using the variance
parameters and being very very lucky).

I have attached an SVG for you to try with the latest inkscape SVN.
Note that this problem exists regardless of the "scale width relative"
setting.

Thanks for any comment on how to "fix" this.

kind regards,
Johan

Re: [Lib2geom-devel] FW: [Inkscape-devel] Width control in Bend Path LPE

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

On Sat, 24 Nov 2007, Maximilian Albert wrote:

> I'd like to take this opportunity to send my apologies over to Nathan
> (and the others) for never having shown up again on IRC after our first
> couple of chats.

Oh, I wouldn't worry about it too much - I gained insight into the meaning 
of vanishing point by reading your code and used it in my own work :)

njh

Re: [Lib2geom-devel] FW: [Inkscape-devel] Width control in Bend Path LPE

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

J.B...@ew... schrieb:
> Just so you guys know... 2geom rocks! :-)

This is soooooooo true!

I'd like to take this opportunity to send my apologies over to Nathan 
(and the others) for never having shown up again on IRC after our first 
couple of chats. At present I'm overburdened with studying for my final 
examinations, and at the same time I'm desperately working on giving the 
3D box tool the last polish (or rather, reworking it so that I can 
actually start giving it the last polish).

But what you showed me during our conversations is still rambling in the 
back of my mind. And one day, when all this is done and finished, I'll 
be back. :)

Really looking forward to it!

Best regards to all of you developers for doing such an awesome job!
Max

[Lib2geom-devel] FW: [Inkscape-devel] Width control in Bend Path LPE

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

Just so you guys know... 2geom rocks! :-)
=20

-----Original Message-----
From: ink...@li...
[mailto:ink...@li...] On Behalf Of
J.B...@ew...
Sent: zaterdag 24 november 2007 0:27
To: ink...@li...
Subject: [Inkscape-devel] Width control in Bend Path LPE

Hi all,

Before I leave on a trip for a couple of days, I decided to add width
control to bend path. See the picture showing bits of two screenshots.
One editing the bend path as usual, and one editing the width of the
path.
Already works quite nicely!

This is sort of a test to see how the UI should be for "1D" path
parameters (path parameters for which e.g. only the y value matters,
like functions: y =3D f(t) )

For those not convinced of 2geom power: I did this within half an
hour.......  (so probably many bugs here!)

Happy bending!
Johan

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

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

On Wed, 21 Nov 2007 22:08:31 +0100, J.B...@ew... wrote:
> This has not been tested though, so probably needs work. Static linking
> was what I started out with in LPE development, but when LPE moved to
> trunk, we chose for having our own copy of 2geom because of frequent
> 2geom updates caused by progressing LPE dev. Now the situation is
> different. (static linking would make new lib2geom releases useless for
> released Inkscape right?)

Dynamic linking wouldn't be much help either -- like many STL-style C++
libraries, a lot of stuff is inlined from headers.  Minor changes to
interface (or even simply implementation) can easily mean binary
incompatibilities.

However, one thing which I think would be very helpful to do now is if
we can disentangle Inkscape's copy of lib2geom from the Inkscape build
system.  That way, the 2geom tree can be an exact copy of a 2geom
snapshot (rather than the manually modified copy it is now), and we
have a better migration path to using an out-of-tree 2geom.

-mental

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

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

> -----Original Message-----
> From: Bryce Harrington [mailto:br...@br...]=20
>=20
> On Wed, Nov 21, 2007 at 11:43:57AM -0800, Ted Gould wrote:
> > On Wed, 2007-11-21 at 20:32 +0100,=20
> J.B...@ew... wrote:
> > > I don't think we want a release now, so we can quickly address=20
> > > issues that surface. I think it is best to keep 2geom inside=20
> > > Inkscape code for 0.46, and have a good and nice 2geom=20
> release for=20
> > > 0.47. This way we can profit from bleeding edge 2geom=20
> which atm is=20
> > > nicer than a release will be imho.
> > > I am fine by copying 2geom code to Inkscape for now :-)
> >=20
> > We can for development, but I'd prefer not to for release. =20
> Unless the=20
> > lib2geom folks are unwilling to release it, I'd prefer to=20
> go that route.
> >=20
> > The biggest advantage this gives us is that they can fix bugs=20
> > independent of Inkscape.  So, if the intersection routine=20
> turns out to=20
> > be numerically unstable in a certain situation a spin of=20
> lib2geom can=20
> > be done without having to do a release of Inkscape.  And Inkscape=20
> > users still get the benefit.
>=20
> I definitely agree with Ted.  There are several libraries=20
> copied into the tree that probably ought to be broken out=20
> where possible.  Other projects like Xorg, OpenOffice, etc.=20
> demonstrate the many downsides to monolithic applications,=20
> and the benefits to both users and developers of proper=20
> modularization.
>=20
> I also definitely agree that if there's bugs in lib2geom,=20
> rolling a new release of it would be much, much preferable to=20
> having to roll a new Inkscape.

Perhaps I thought too much from the "who is going to do it" perspective.
I think you have convinced me that is it better to dynamically link
2geom.=20
This has not been tested though, so probably needs work. Static linking
was what I started out with in LPE development, but when LPE moved to
trunk, we chose for having our own copy of 2geom because of frequent
2geom updates caused by progressing LPE dev. Now the situation is
different. (static linking would make new lib2geom releases useless for
released Inkscape right?)

However, I think there are still times when 2geom changes are so big to
require some rewrite of Inkscape's 2geom-using code.

Regards,
Johan

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

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

On Wed, 21 Nov 2007 11:43:57 -0800, Ted Gould <te...@go...> wrote:
> We can for development, but I'd prefer not to for release.  Unless the
> lib2geom folks are unwilling to release it, I'd prefer to go that route.
> 
> The biggest advantage this gives us is that they can fix bugs
> independent of Inkscape.  So, if the intersection routine turns out to
> be numerically unstable in a certain situation a spin of lib2geom can be
> done without having to do a release of Inkscape.  And Inkscape users
> still get the benefit.

The reason we favor bundling lib2geom with Inkscape for now is that
we're not willing to freeze the 2geom API yet.  We can certainly do
independent releases, but Inkscape wouldn't benefit without at least
recompilation.

-mental