- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] [cairo] Fwd: cairo path rendering bug with inkscape
by Carl Worth 14 Apr '08

14 Apr '08

On Sat, 05 Apr 2008 06:26:30 -0700, Carl Worth wrote: > So Bulia, I'm throwing the ball back into your court. It appears > there's a bug in inkscape that is converting some C path elements into > cairo_move_to instead of cairo_curve_to. > > I haven't tried chasing this down into inkscape yet. It was easy enough to see where inkscape is using cairo_move_to instead of cairo_curve_to: In inkscape-cairo.cpp:112: if (!optimize_stroke || swept.intersects(view)) cairo_curve_to (ct, tm1[NR::X], tm1[NR::Y], tm2[NR::X], tm2[NR::Y], tm3[NR::X], tm3[NR::Y]); else cairo_move_to(ct, tm3[NR::X], tm3[NR::Y]); And sure enough, eliminating that optimization, (as with the below patch), does make the bug go away. But that's just a band-aid really, and doesn't tell us what's wrong with the optimization, (since it should be a reasonable thing to discard curves that are not visible). I'll look a little closer now. -Carl PS. I guess since we're in inkscape's code now, I'll move the discussion to the inkscape-devel list. Followups need not include the cairo list anymore. >From ea87c392609cf6ad931bf64b0be35ac6a7233977 Mon Sep 17 00:00:00 2001 From: Carl Worth <cworth@...573...> Date: Sat, 5 Apr 2008 06:48:45 -0700 Subject: [PATCH] Bandaid to avoid incorrect curve optimization I'm not sure what's wrong with the optimization here, but removing it definitely clears up bugs. Look at this file with the cairo-based outline mode both with and without the optimization to see: http://cairographics.org/~cworth/images/cairobug.svg (You may need to zoom in a bit to see the bug appear.) --- src/display/inkscape-cairo.cpp | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/src/display/inkscape-cairo.cpp b/src/display/inkscape-cairo.cpp index 5d87d39..a32cd13 100644 --- a/src/display/inkscape-cairo.cpp +++ b/src/display/inkscape-cairo.cpp @@ -109,10 +109,7 @@ feed_curve_to_cairo (cairo_t *ct, NArtBpath *bpath, NR::Matrix trans, NR::Maybe< tm1 -= shift; tm2 -= shift; tm3 -= shift; - if (!optimize_stroke || swept.intersects(view)) - cairo_curve_to (ct, tm1[NR::X], tm1[NR::Y], tm2[NR::X], tm2[NR::Y], tm3[NR::X], tm3[NR::Y]); - else - cairo_move_to(ct, tm3[NR::X], tm3[NR::Y]); + cairo_curve_to (ct, tm1[NR::X], tm1[NR::Y], tm2[NR::X], tm2[NR::Y], tm3[NR::X], tm3[NR::Y]); break; } -- 1.5.5.rc0.24.g86c30

4 8

i18n: GTK Input Methods
by Marcin Floryan 14 Apr '08

14 Apr '08

Hi! Recently looking into: https://bugs.launchpad.net/inkscape/+bug/215574 I started looking into how it is handled in Windows and was wandering if some of you have more experience in the area or could provide some pointers. Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

1 0

compile broken rev 18323
by bulia byak 14 Apr '08

14 Apr '08

1 please don't forget to update Makefile_insert files - I did this for the moved n-art-bpath-2geom.cpp/h 2 even then, linking fails: libnr/libnr.a(n-art-bpath-2geom.o): In function `SVGEllipticalArc':./2geom/path.h:287: undefined reference to `vtable for Geom::SVGEllipticalArc' libnr/libnr.a(n-art-bpath-2geom.o): In function `Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path, std::allocator<Geom::Path> > > >::arcTo(double, double, double, bool, bool, Geom::Point)':./2geom/path.h:297: undefined reference to `Geom::SVGEllipticalArc::calculate_center_and_extreme_angles()' collect2: ld returned 1 exit status please fix asap -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 1

Inkscape GSoC: Ranking Proposals
by Aaron Spike 14 Apr '08

14 Apr '08

Mentors, now is the time to log in to the GSoC web interface and read and rank proposals. We have until April 18 to complete this work. If as you are reading proposals you think "so-and-so would be a great mentor for this proposal" and so-and-so isn't signed up as a mentor, please contact and encourage them (or suggest them to me and I will make contact). Fellow developers, if you haven't yet signed up as a mentor but are willing and able, please do so now. Aaron Spike

2 3

Architectural question about libgc
by Krzysztof Kosiński 13 Apr '08

13 Apr '08

The main usage pattern for garbage-collected classes I see is: Inkscape::XML::Node *foo = doc->createElement("foo"); parent->appendChild(foo); Inkscape::GC::release(foo); This looks very malloc-free-ish. Why not, instead of deriving from the GC-managed classes, derive from Glib::ObjectBase and then use Glib::RefPtr everywhere? During the migration period, SPObjects etc. can be derived from both Inkscape::GC::Managed etc. and Glib::ObjectBase, and overload the reference() and unreference() virtual methods to call Inkscape::GC::anchor() and Inkscape::GC::release(). However, I don't know the codebase too well, so probably there's some more fundamental reason to using libgc other than managing objects which have multiple references - please enlighten me :). Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Architectural-question-about-libgc-tp16620985p1662098… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

Re: [Inkscape-devel] Proposal for new 'Edit | Paste Path' option
by Alvin Penner 13 Apr '08

13 Apr '08

perhaps I should clarify, in the path node you can have a 'd' attribute either with or without a 'transform' attribute. - if the 'transform' attribute does not exist, then it does not need to be transferred as part of a paste - if the 'transform' attribute does exist, then it should be transferred as part of a paste

1 0

Re: [Inkscape-devel] Proposal for new 'Edit | Paste Path' option
by Alvin Penner 13 Apr '08

13 Apr '08

At 02:00 PM 4/13/2008 -0400, you wrote: >On Sun, Apr 13, 2008 at 12:50 PM, Alvin Penner <penner@...1856...> wrote: >> 1. paste using absolute coordinates, not relative to mouse. >> 2. transfer only 'path' node info, and within the path node transfer only >> the 'd' attribute, and the 'transform' attribute, not the 'style' attribute. > >No, for a typical user there's no separate "transform". Any command >that treats path data separately from transform will give >unexplainably weird results for such a user. It's a very specialized >functionality. actually, I was proposing that both the 'd' attribute and the 'transform' attribute be modified at the same time, not separately. The reason for this is that most users cannot visually distinguish between them, so if you are going to modify one, then you should modify both. The only way to distinguish between them is to open the XML editor which most people won't do. > >> 3. if the path id already exists, then overwrite it, but only 'd' and >> 'transform', not 'style'. > >That is very specialized too. Users don't care and don't know about >ids. For them, this command will just act weird and unpredictable. in this case I was referring to the 'd' attribute to be overwritten, not the 'id' attribute, which is quite different. > >So, I don't think it's a good idea overall. However, there's another >command that needs to be implemented and that will give you, more or >less, the functionality you need. It's copy/pasting nodes: in Node >tool, pressing ctrl+c with some nodes selected, these nodes must be >copied to some special storage; and when you press ctrl+v with some >nodes selected, these nodes must be replaced with pasted nodes, >correspondingly moved and probably rotated to fit the path in the new >place. If you're replacing all nodes of an object, no such >move/rotation is necessary. Then, pasting path data from another >application would be done like this: select target object, switch to >node tool, select all nodes and press ctrl+v. > >-- >bulia byak >Inkscape. Draw Freely. >http://www.inkscape.org > >

1 0

Support the Libre Graphics Meeting - Inkscape website
by Louis Desjardins 13 Apr '08

13 Apr '08

Hello Inkscapers! As you probably already know — but in case you don’t! — we have a fundraising campaign going on to help Libre Graphics Meeting 2008 help developers get to the conference. We have already gathered over $7000 USD thanks to an overwhelming response from the community and, yes, 179 generous donators so far! WOW! http://pledgie.com/campaigns/613 But we need lots more... and we’re now trying to get some more noise around this campaign. We would appreciate that the campaign be posted on the Inkscape website. If anyone can do that quick, it would be great. Please include the Pledgie logo! Also, more on Dave Neary’s post on the Create list for all the details. Cheers! Louis For the organisation of LGM 2008 - Wroclaw

1 0

Win32 Builds with Cairo-1.6.2
by Bob Jamison 11 Apr '08

11 Apr '08

Hi, all, I don't know if everyone noticed, but Carl Worth and his troupe have released Cairo-1.6.2. (Yaay!) I've gotten out of the habit of posting every new thing in the Inkscape/win32 world, but I think that this version of Cairo is a notable milestone. I uploaded another lib bundle with it here: http://inkscape.modevia.com/win32libs/devlibs-2.12-080411.7z ...and started making builds with it already. Here is the first: http://inkscape.modevia.com/win32/Inkscape0804111855.7z Also, note that there is a new "fulldbg" build there. These are the builds I make separately with -g turned on for everything. Thanks , Carl! ishmal (bob)

4 3

Autopackage for 0.46
by Jan Niklas Hasse 10 Apr '08

10 Apr '08

Hi everyone, Some guys have asked in the forum about an autopackage for 0.46. I think the developer mailing list seems to be a better place to ask that. As I think no one has done it yet, I'm trying to ask now, because I'm interested in an autopackage for 0.46, too. :) Here are the forum threads: http://www.inkscapeforum.com/viewtopic.php?f=22&t=799 http://www.inkscapeforum.com/viewtopic.php?f=22&t=784 http://www.inkscapeforum.com/viewtopic.php?f=22&t=766

2 1