- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Convolve Matrix Divisor slider range
by Felipe Sanches 24 Aug '09

24 Aug '09

ok. You convinced me. Lets see if we can get it into 0.47... Maybe it is too late. I hope not. ScislaC, can we commit this change to trunk? Juca On Mon, Aug 24, 2009 at 10:21 AM, Tavmjong Bah<tavmjong@...8...> wrote: > > Hi, > > I was wondering if there was some special reason you decreased the > range for the Convolve Matrix Divisor from 1000 to 20 in commit 17056? > If one constructs, for example, a 5x5 gaussian blur matrix using integer > values in the kernel, one needs a divisor of 159. (I noticed because it > broke this example in my book.) In general, I think it is better that > ranges are a bit too large than too small as you never know what > possible uses people will come up with or what values one might inherit > from other drawing packages. What do you think about changing it back to > 1000 or to 200? > > Tav > > > >

2 1

GSoC Final Evaluation Survey
by Aaron Spike 24 Aug '09

24 Aug '09

Hello GSoCers and mentors, Thanks again for all your work. Once again I would like to remind you that I can't see who has completed the surveys in Melange. Would you please shoot me an email when you've completed the surveys so that I know you are alive and well. Thanks! Surveys are open now, go get 'em done! Aaron Spike

6 5

inkscape nsi
by the Adib 24 Aug '09

24 Aug '09

Hi Chris, I saw your svn commit 22142 where you changed the inkscape.nsi. But you (however) changed in inkscape/inkscape.nsi and not in inkscape/packaging/win32/inkscape.nsi inkscape.nsi is just a placejolder an can be removed in my opinion. please check. HTH, Adib.

2 1

[SPAM] Libre Graphics Meeting 2010 in Brussels Announced
by Jon Phillips 22 Aug '09

22 Aug '09

GLOBAL - August 22, 2009 - Cutting edge graphics software meets free culture at Libre Graphics Meeting 2010 in Brussels Users and developers of Free, Libre and Open Source graphics software will meet in Brussels, Belgium on May 26-29, 2010 at the fifth annual Libre Graphics Meeting (LGM). Held in a historical piano factory, newly renovated into a lively exhibition and work space near Brussels' city center, LGM 2010 offers software developers, artists, designers and other graphics professionals the chance to collaborate and learn from each other. LGM emphasizes the sharing of collective creativity, innovation and ideas and is free for everyone to attend. The LGM community is excited for the opportunity to bring this event to the European capital. About the Libre Graphics Meeting The Libre Graphics Meeting exists to unite and accelerate the efforts behind Free, Libre and Open Source creative software. Since 2006, this annual meeting is the premiere conference for developers, users and supporters of projects such as GIMP, Inkscape, Blender, Krita, Scribus, Hugin, the Open Clipart Library, and the Open Font Library gather to work on interoperability, shared standards, and new ideas. Work at prior LGMs has pushed the state of the art in important areas such as color management, cross-application sharing of assets, and common formats. Face-to-face meetings and opportunities for collaboration are important to users and developers alike; in the form of tutorials, talks, workshops, and birds-of-a-feather (BOF) the event offers many formal and informal opportunities to interact. Highlights from LGM 2009 The last Libre Graphics Meeting took place in Montreal, Canada. It involved 150+ participants from around the world working together for four days to give presentations, demos, and meet informally. Through support from the Ãcole Polytechnique MontrÃ©al, the LGM user community (raising money on pledgie.com), Sourceforge, River Valley Technologies, Intel Communities, Open Candy, QT, sK1, GIMP, Python Software Foundation, Gnome foundation and Group Eyrolles, the conference funded travel for many international developers whom otherwise would not be able to work face to face. Highlights included contributions by companies building on Open Source such as AscenderCorp and Open Source Publishing, and presentations of Jeff Fortinâs PiTiVi Video Editor, FontMatrix, Phatch and Michael Terryâs work on In-Gimp user-experience analysis and kinetic templates. All major projects in attendance, Scribus, Gimp, Inkscape, and Open Font Library, spent time planning activities for the next year. New projects like the panorama stitcher NONA, Lighttwist, a system for running multi-projector immersive video displays, and Markus Weiland's FacetZoom widget, set the stage for new exciting software developments leading into LGM 2010 in Brussels. A Preview of LGM 2010 For Libre Graphics Meeting 2010, the conference promoters challenge all participating projects and people to set goals and plan creative projects. First, each major project is requested to have set three solid priorities before the conference to work towards. Second, one or more collaborative projects is to be developed, beyond just the tools used, such as a book or animation. And third, the conference hopes to involve an increasing number of artists and academics to show novel uses libre graphics software, and to discuss, analyse and provide inspiration. In the coming months, Libre Graphics Meeting 2010 organizers will release more information about the upcoming conference, raising funds to enable the event, and release the official call for participation for 2010. Immediately, the conference organizers invite all interested in participating to watch the http://libregraphicsmeeting.org website and join the Create Project (http://create.freedesktop.org) mailing list and get involved. LGM 2010 is hosted by the Libre Graphics Community and Constant in collaboration with De Pianofabriek, Master Networked Media and Research programme Communication in a Digital Age (Piet Zwart Institute, Willem de Kooning Academy, Rotterdam) and the Bruxelles Linux User Group (BXLUG). For more information, visit http://www.libregraphicsmeeting.org Press Contact * Sponsoring Organization: Create Project and Libre Graphics Meeting * Contact: Jon Phillips * Contact email: jon@...235... * Phone (USA): +1.415.830.3884 * Website: http://libregraphicsmeeting.org/ * Press Release in other languages: http://ur1.ca/a33b * Press Photos: http://ur1.ca/a34y ###

1 0

PNG Export directory
by Tavmjong Bah 22 Aug '09

22 Aug '09

Hi, Prior to recent changes if one exported a PNG without specifying a path it would be saved in the same directory as the SVG. Now it gets saved in the home directory (in Linux). I don't think that this is desired. I would almost never want the PNG to end up in my home directory. This is causing a significant interruption in my work flow as I have hundreds of SVG's that have the PNG export name set without a path (inkscape:export-filename). Can we have the original behavior back (without breaking, of course, the new support of relative paths)? Thanks, Tav

5 7

Important information about 0.47
by Joshua A. Andler 22 Aug '09

22 Aug '09

Hey All, As you are aware, I am the release warden for 0.47. Unfortunately, I have some major things going on in my personal life that will prevent me from contributing much, if at all, over the next couple of weeks. Given these circumstances, please CC both Jon Cruz and bulia byak with any patches/concerns you are sending my way so we can ensure they will be reviewed and handled in a timely fashion. When things have settled a bit, I will return and resume my duties as normal. I am sorry for any inconvenience this may cause anyone. Thanks for your understanding. Cheers, Josh

1 0

Current 7z version of inkscape for windows
by Render 21 Aug '09

21 Aug '09

I notice on the website http://inkscape.modevia.com/win32/?M=D the current windows version is 22040 but it is an exe file but creates temp files that I cannot use to overwrite my current development version. Is there one around that is in zip formant so that I could extract the contents into my current inkscape development version?

4 5

translation warden?
by Alexandre Prokoudine 19 Aug '09

19 Aug '09

Hi, So who is translation warden for 0.47? Alexandre

1 0

proposed patch for Spiro spline LPE
by Alvin Penner 19 Aug '09

19 Aug '09

this is a follow-up to LP Bug 415079. https://bugs.launchpad.net/inkscape/+bug/415079 I'd like to propose a patch to deal with occasional (multiple) circular loops in the Spiro Spline LPE. The patch consists of a re-application of a common clamp which is normally applied to the angles, but which appears to need to be re-applied at the final stage of the calculation. I've tested this offline in a standalone calculation to confirm that it works. I wonder if someone would be willing to test this directly in Inkscape. http://www.nabble.com/file/p25015469/spiro.diff spiro.diff -- View this message in context: http://www.nabble.com/proposed-patch-for-Spiro-spline-LPE-tp25015469p250154… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 1

matrix isScale and isRotation do not work
by bulia byak 18 Aug '09

18 Aug '09

This seems to be a cosmetic bug but it's not: https://bugs.launchpad.net/inkscape/+bug/415168 because the undo comment depends on 2geom matrix functions: if (_current_relative_affine.isTranslation()) { sp_document_done(sp_desktop_document(_desktop), SP_VERB_CONTEXT_SELECT, _("Move")); } else if (_current_relative_affine.isScale()) { sp_document_done(sp_desktop_document(_desktop), SP_VERB_CONTEXT_SELECT, _("Scale")); } else if (_current_relative_affine.isRotation()) { sp_document_done(sp_desktop_document(_desktop), SP_VERB_CONTEXT_SELECT, _("Rotate")); } else { sp_document_done(sp_desktop_document(_desktop), SP_VERB_CONTEXT_SELECT, _("Skew")); } and these are quite fundamental to Inkscape operation - if they are broken I'm afraid to think what else might be broken. Can someone with a good grasp of 2geom or just geometry please look into this? I think this must be fixed before the release. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 7

The case of the empty status bar/notification region...
by Tavmjong Bah 18 Aug '09

18 Aug '09

Hi, I just noticed that the status bar, aka notification region is often empty. I click on the Rectangle tool and see the text "Drag to create a r". I then move the cursor over the text, expecting to see a tool tip with the full text of how to use the Rectangle tool but all the text disappears. After doing this a few times I realized that passing over the swatches causes the status bar to show the name of a swatch (new feature in 0.47); when the cursor leaves the swatch area, the Rectangle text doesn't reappear. This makes it impossible to read the full text in the status bar for any tool (except the Tweak tool, where the text is restored) unless one make an end-around the swatches (difficult in full-screen mode). Can this be easily fixed? Tav

1 0

Re: [Inkscape-devel] Re : Re : Re : Extracting a saturation map with SVG filters ?
by Jasper van de Gronde 18 Aug '09

18 Aug '09

Ivan Louette wrote: > What do you think about placing your filters into Inkscape Samples files > with some comment ? I think they should be shared ! Myself I learned a > lot from Niko Kiirala's files which sit in Inkscape Samples directory. Excellent idea. I'm not very familiar with the guidelines for doing so though (I usually just work on the code). Anything I should be aware of? I assume the file should go into share/examples? > Otherwise I could also include them with your comment inside my > experiments repository file on OpenClipart (when I will be able to > upload it again because OpenClipart has some problems at the moment), or > perhaps in a separate dedicated file, or perhaps could you open a page > yourself for this kind of things ? I was thinking of creating a wiki page or something on the general techniques, as I think they can be of broader interest. I'll have a look this weekend if I can write up something.

1 0

Nodetool problem?
by Thomas Holder 18 Aug '09

18 Aug '09

Hi, with svn rev 22105 (and 22073) I get unexpected node selecting behavior. So far I can reproduce: * draw first path * draw second path * switch to node tool * click on first path * click on some node Result: two nodes instead of one get selected and the mouse cursor does not switch to normal arrow when hovering to toolbar. Inkscape also froze (100% CPU for some minutes until I killed it) twice after such incident. rev 22044 is fine, so the fix for bug 168780 might have broke this. Thomas

3 3

Question about file opening function
by Mat 18 Aug '09

18 Aug '09

Hi, I want to call a funtion to open a file. I find the three function: sp_file_open_dialog(*parent, NULL, NULL); sp_file_new_default(); sp_file_open( path, NULL)； But when I call these funtions in another thread, it crash inkscape. Is there any required initialization before I call these this function? My program block is like to : ==== bool InkDBus::openFile(const string& path){ bool result = true; bool create_new = true; list< SPDesktop* > desktops; list< SPDesktop* >::iterator iter; inkscape_get_all_desktops(desktops); iter = desktops.begin(); SPDesktop* desktop = *iter; Gtk::Window *parent = desktop->getToplevel(); sp_file_open_dialog(*parent, NULL, NULL); return result; } ==== Thanks first for reading this letter :-) sincerely, Mat.

2 3

Inkscape scripting API (Draft)
by Glimmer Labs 18 Aug '09

18 Aug '09

Here is the first draft of a Dbus based Inkscape scripting API: http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html (Many thanks to the ConsoleKit team for the scripts and build system I used to generate this documentation.) I would welcome any comments or criticisms, the interface is very much still up in the air so any suggestions, from small changes to major issues, would be welcome. I would particularly like to hear if people think that this would potentially support the ways in which they use Inkscape, or whether there are use cases this doesn't address. If there are lots of uses that this interface does not support, additional interfaces geared towards different users could be added. (In fact there was originally one more interface than there is now, see document_new() for details.) If you like the current API (in general) feel free to suggest additional functions or functionality. Finally, how would you like to see this extended? Dbus has proven to be quite responsive and robust for this application. How would you build off the basic platform of the Inkscape application interface? I will keep the posted link updated as I make changes based on peoples feedback. -Soren

11 34

Cross software User Interface
by Brian Vidal 17 Aug '09

17 Aug '09

Hi there, we are starting a huge project in order to take advantage of some applications UI re-design: we want to make a huge UI redesign in the best opensource design, authoring and media creation/edition software. The need to do this is essentially, to provide a cross UI between all major media-related software. This way we can make all media-related software in the open source world to have the same and effective User Interface, so the user can work more tightly between applications and we can collaborate to each other. The project is just starting, and we want to put all of our effort to design, develop and migrate to a efficient, fast and beautiful User Interface. Please, think on it. As a starting point https://launchpad.net/linux+design+studio<http://www.launchpad.com/linux+design+studio> Hoping to make the big jump in the community. Best regards. dael99 (Brian Vidal) -- Brian Vidal

2 1

GSoC 2009 - Time to wrap things up
by Joshua A. Andler 17 Aug '09

17 Aug '09

Hey GSoC students and mentors, I just wanted to give a reminder of the schedule for GSoC. Students, today is the pencils down date. Please make sure that your mentor has access to your work today. You do have one week (until the 24th) to do any tweaks or code cleanup, but you should effectively be done at this point. Please be respectful of your mentors and don't force them into doing a last second evaluation. Also, if you are planning to use the additional time for more work, please do communicate that with your mentor. Mentors, evaluations can begin starting today and are due on August 24th. No need to rush as I'm sure we'll see some changes trickling in still. That's all for now. Cheers, Josh CCing dev list so everyone know where we're at.

1 0

SPEventContext stops receiving button1 press/release events
by Arcadie M. Cracan 17 Aug '09

17 Aug '09

Hello, I don't really understand what I am doing wrong. I have a button on the toolbar of the connector tool (InkAction) that, when gets pressed, basically creates a new knot that follows the mouse pointer. At this point (after the button is pressed) SPEventContext (for the connector tool) stops receiving any button1 press/release events. Other buttons press/release, pointer motion events are received. I don't even have a clue for where to start debugging, please help. Thank you. Following are some code exerpts: from toolbox.cpp: =========== ... g_signal_connect_after( G_OBJECT(inky), "activate", G_CALLBACK(sp_connector_new_connection_point), holder ); ... static void sp_connector_new_connection_point(GtkWidget *widget, GObject *tbl) { SPDesktop *desktop = (SPDesktop *) g_object_get_data( tbl, "desktop" ); SPConnectorContext* cc = SP_CONNECTOR_CONTEXT(desktop->event_context); if (cc->mode == SP_CONNECTOR_CONTEXT_EDITING_MODE) cc_create_connection_point(cc); std::cout<<"Done new connection point."<<std::endl; } ... from connector-context.cpp ================== ... void cc_create_connection_point(SPConnectorContext* cc) { if (cc->active_shape && cc->state == SP_CONNECTOR_CONTEXT_IDLE) { if (cc->selected_handle) { cc_deselect_handle( cc->selected_handle ); } SPKnot *knot = sp_knot_new(cc->desktop, 0); cc_select_handle( knot ); cc->selected_handle = knot; cc->state = SP_CONNECTOR_CONTEXT_NEWCONNPOINT; } } ... Regards, Arcadie Cracan

2 4

Re: [Inkscape-devel] Re : Re : Extracting a saturation map with SVG filters ?
by Jasper van de Gronde 16 Aug '09

16 Aug '09

I've attached two files which show how to replace the hue of an image with a "hard-coded" hue and the hue from a different image (a gradient in this case), respectively. Ivan Louette wrote: > Sorry for no replying earlier ! > > Thanks for the link and the explanations ! However at the moment I lack > a lot of technical skills I am afraid... I would have time to learn > programming but I must concentrate on my main project - writing a novel > - which progresses too slowly these months. This week end I was very > busy at cleaning the code of filters.svg ; the result (already > spectacular this evening) will be commited on SVN probably tomorrow in > the evening when I will have finished. Then I would concentrate on the > french filters doc (this is my mother language) I began some weeks ago > on Floss Manuals. > > Have a nice week, > > ivan

1 0

Preparing for Feature Freeze
by Joshua A. Andler 15 Aug '09

15 Aug '09

Hey All, It appears that the Frost is nearing completion, and the Feature Freeze will be setting in soon. Given this, it's probably a good time to start putting together a list of release blocker bugs, as well as discuss if any features need to be pruned due to them being incomplete. For reference, here are the bugs that are still milestoned for 0.47: https://edge.launchpad.net/inkscape/+milestone/0.47 Is anyone aware if there currently any major platform specific bugs like we had around 0.46? (win32 printing issue is what I speak of) Also, JonCruz, should we hold back the "Auto" swatch palette from this release? At this point I want to again remind people to ensure that the release notes are as up-to-date as possible! Please take a moment to ensure that your improvements/enhancements/new features are all mentioned with a brief explanation where necessary. Thanks to everyone for your contributions! Cheers, Josh

9 12

Better hrefs
by Krzysztof Kosiński 15 Aug '09

15 Aug '09

Hello all Currently we have some handling for hrefs (in the form of Inkscape::URIReference). It provides some signals and callbacks, but doesn't do everything that I would like it to. To be specific, there are several places when solving the following problems efficiently would be a great thing: 1. Given an object, iterate over all references to it. 2. Given an object, iterate over all objects it refers to. Point 1 is useful for all sorts of things: marking objects for update, compensating clones, deletion, vacuum defs, etc. Point 2 would allow to remove 80% of clipboard code, and implement robust ID changing and clash prevention (which means, one that doesn't have to be updated whenever a new href-like attribute is added). Here is my idea. We define a three-way smartpointer that looks like this: class ObjectRefBase { ... SPObject *obj; ObjectRefBase *next; ObjectRefBase *next_ref; }; template <typename T> class ObjectRef : public ObjectRefBase { ... }; template <typename T> ObjectRef<T> const &getRef(T *obj) { return static_cast<ObjectRef<T> const &>(*obj); } The 'next' and 'next_ref' pointers form a singly-linked cyclic lists. Each SPObject contains such a smartpointer (by protected inheritance: 'class SPObject: protected ObjectRefBase, ... {') that can be accessed using the getRef function, which is a templated friend of SPObject and returns an ObjectRef of correct type. The header of both lists is the pointer contained in the referenced object; it has 'obj' set to itself. 'next' allows us to iterate over references to this object, while 'next_ref' - over references contained in this object. The constructor might look like this: ObjectRefBase(SPObject *owner) { if (owner == this) { obj = this; next = this; next_ref = this; } else { next_ref = owner->next_ref; owner->next_ref = this; obj = NULL; next = NULL; } } If this is the embedded instance from protected inheritance, the the first test will be true and both lists will be initialized as empty (an empty cyclic list is represented by the header node having a next pointer pointing to itself). The assignment operator is as follows: ObjectRefBase &operator=(ObjectRefBase const &other) { if (obj != NULL) { ObjectRefBase *cur = this; while (cur->next != this) cur = cur->next; cur->next = obj->next; } next = other.next; other.next = this; } If the reference pointed to some object, the function walks the list and removes the reference from the linked list of the previous object; it then inserts itself into the linked list of the new object. The destructor works similarly: ~ObjectRefBase() { ObjectRefBase *cur = this; while (cur->next != this) cur = cur->next; cur->next = obj->next; cur = next_ref; while (cur->next_ref != this) cur = cur->next_ref; cur->next_ref = next_ref; } Now we can iterate over the references to an object like this: for (ObjectRefBase *cur = this->next; cur != this; cur = cur->next) { // do something with each reference to this object } And over references contained in an object like this: for (ObjectRefBase *cur = this->next_ref; cur != this; cur = cur->next_ref) { // do something with each reference stored in this object } Testing whether the object has any indirect references is dead simple: this == next. Same for checking whether this object refers to anything: this == next_ref. The owner of a reference can be retrieved in linear time (by walking next_ref until we encounter next_ref == obj). All this of course can be encapsulated into a nice STL-like iterator interface which provides some extra type safety not present in ObjectRefBase (for example, we know that all ObjectRefs which we can reach via 'next' point to the same type). Handling CSS properties with URI references that are not members of the object is easy as well: ObjectRef doesn't need to be a member of the owner for all this to work. There are no boilerplate attach() / release() methods: the assignment operator of ObjectRef takes care of everything. If walking the lists during reassignment and destruction turns out to be a performance problem, we can make both lists doubly-linked rather than singly-linked, where a node can be removed in constant time, at the price of 2 more pointers stored in each reference. Fast owner retrieval additionally requires storing the owner pointer. This gives 5 pointers of overhead, so for 10000 references on a 64-bit machine we get 390KB of overhead - should be manageable. I thought about a trick that can be used to implement constant-time erase on a cyclic single list (the iterator actually points one node before and we use cur->next->value to get the value), but it can't be applied here. Why this is better than keeping pointers to the references in std::list or std::vector? - no memory allocations when adding a reference = better performance. - removing a reference is much simpler, because finding it in the list is not needed. - signals can be put in the ObjectRef class. - simple and elegant implementation. What do you think? Improvements and discussion welcome. Regards, Krzysztof -- View this message in context: http://www.nabble.com/Better-hrefs-tp24939304p24939304.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 10

Live path effects - better XML representation
by Krzysztof Kosiński 14 Aug '09

14 Aug '09

While rewriting the node tool I necessarily had to look into path effects. Live path effects are currently seem to be represented by a single svg:path that has information on what the original path looked like in the inkscape:original-d atribute, the applied effects in another attribute, and additional. I think this is not very flexible, because it does not allow for example nondestructive boolean operations where both operands are other path effects. What do you think about this representation: 1. A live path effect is represented by an svg:switch element. An Inkscape-specific attribute can be added to it to simplify implementation, but it is not really necessary. 2. The first element in that svg:switch is an inkscape:path-effect element that contains all the information about objects it was generated from. Shape parameters are represented as inkscape:path-effect-param elements that can contain anything including svg:use, svg:rect, svg:path, another inkscape:path-effect etc. This could allow very nifty things like live boolean operations. It would also simplify the node editor, because it could just operate on the invisible children of inkscape:path-effect while being completely unaware of path effects. As bonus points, path effects created from rectangles, circles, spirals, etc. could preserve the editing capabilities of those shapes. 3. The second element would be an svg:path that contains the result of the path effect, style properties, etc. 4. When opening the file in Inkscape, it would only look at inkscape:path-effect and recompute the fallback svg:path whenever something changes. When opening in another SVG viewer, it would only display the svg:path. 5. To handle live boolean operations, there would be an additional parameter for shapes that says whether they are 'live'. If a shape is 'live', all boolean, offset, etc. operations would create path effects instead of paths, similar to how linked offset works now. In fact, the destructive versions could be implemented as a combination of creating a path effect and an object-to-path conversion. 6. Path parameters would accept any SPShape. There would be a separate type of parameter that accepts a group of shapes. To convince an effect to accept an object group as a parameter, a special effect called Flatten Group would be provided - it would convert a group into a path effect suitable for use as a parameter for another one, and could optionally use a clone rather than the original for flattening. Now some use cases: 1. To create an outline of some collection of objects, we create clones of them, group them, apply Flatten Group and then Offset. Result: whenever any of those objects is moved or modified, the outline updates. 2. The sun and cloud example in http://wiki.inkscape.org/wiki/index.php/Lpe-blueprint would be dead simple: create the circle and the sun ray, use pattern along path; create a clone of the cloud, make it 'live', create an offset; then apply a live subtraction between the sun and the clone. Updating any of the original shapes will now change the appearance. (As a related note, compensation on moving should not be a global property, but a property of the clone! As demonstrated here, we want the invisible clone used for the path effect to move with the cloud, but we want other visible clones to stay where they are when the original is moved) UI changes: The LPE stack would need to be changed into an LPE tree like the layer dialog. The path effect tool would allow the editing of various parameters using control points and the node editor; selecting an item in the tree would cause its editing controls and toolbar to appear. Live path effects would be created from a menu rather than from the tool, like dynamic offset. Internal changes: SPLPEItem would be removed, and SPShape would be used as the type of object that can be used as a path parameter. What do you think? I think when done this way, path effects (or maybe they should be called Vector Effects, because they're not really limited to paths?) provide a generic vector equivalent to filtering. This means they could become super-powerful, and in fact the main method of editing complex drawings. There would be some problems with legacy live path effects, but it can be dealt with at document load. PS I just noticed this is somewhat similar to the vector effects proposal in SVG 1.2. It might be wise to plan ahead and make it easy to optionally store some path effects as an SVG 1.2 vector effect. Regards, Krzysztof -- View this message in context: http://www.nabble.com/Live-path-effects---better-XML-representation-tp24778… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 20

Bug Hunt passes 500!
by Tavmjong Bah 14 Aug '09

14 Aug '09

The current bug hunt tally is now 507/500. We have reached the mark! Newly fixed bugs: 6 379977 buliabyak Imagemagick Raster extensions not working 3 308183 JazzyNico Measure Path text shifted when used with a copied object 6 168780 Papouin 0.45 on winxp: Mouse not properly captured.. 6 373309 A. Johnson Print has offset on page 12 166678 A. Johnson Paper size or orientation are not used when printing 9 304018 buliabyak Crash when using LPE with node tool selected 3 407893 buliabyak Text Tool attributes messed up. 9 376068 buliabyak Inkscape 0.46_5 Segmentation fault on gradient edit Top Bug Hunters (With 30 or more points): 120 van Lierop 57 theAdib 45 Bulia Byak 36 JazzyNico 33 T. Holder 30 Jon A. Cruz Special Mention for most active bug reviewing: ~suv Tracked at: http://wiki.inkscape.org/wiki/index.php/Release_Info_for_0.47 Tav

2 2

Quick File Import Test
by Tavmjong Bah 13 Aug '09

13 Aug '09

Hi, I just did a quick File Import Test. I did not test all possibilities. Here are a couple problems: 1. .wmf There are two options. One via Uniconverter and the other from GDK. Do we need both? 2. Images in PDF appear to be imported upside down. Tav

1 0

From *.o compilation to Inkscape.exe
by Yann Papouin 12 Aug '09

12 Aug '09

Hi, In Build.xml there is three main steps: 1. Compiling *.cpp into objects 2. Linking *.o into static libinkscape.a 3. Compiling and Linking "Main" with libinkscape.a Actually I'm using the IDE Code::Blocks (with the same mingw compiler) to debug inkscape and I'm able to do the same things that the Build.xml does. My problem are these three steps, I would like to create Inkscape.exe without having to create a static library because with the -g parameter linking in (2) and (3) took so long !!! So I tried to bypass the "libinkscape.a" creation but it's not working. Someone already did this before ? Yann.

2 2