- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Inkscape Wiki Account
by Drini Cami 21 Aug '13

21 Aug '13

Hello, I would like an account on the Inkscape wiki. I’ve been learning how to write extensions, and would like to expand the information available. Right now, I’d like to add screenshots of the different types of INX parameters. Thank you, Drini

2 1

EMF import on Linux
by Krzysztof Kosiński 21 Aug '13

21 Aug '13

Hello I know that there is working EMF import on Linux, and you can paste things from e.g. ChemDraw. Is it possible to make this code also work on Linux, using e.g. libemf, or would it require writing a completely new input filter? Regards, Krzysztof

2 4

Re: [Inkscape-devel] Unit testing
by unknown＠example.com 20 Aug '13

20 Aug '13

Quoting Josh Andler <scislac@...400...>: > If it's already in use in 2geom and liked, I'd vote for it just > because of that alone. > > Cheers, > Josh Yes, Google Test and Boost Test are close enough that the use by 2geom might be a strong deciding factor. To summarize some of the differences: Google Test: * does not use exceptions. Among other things this means that if a function is called that might result in a test failing, the calling test will need to add an extra line to check status afterwards. * intended to be copied into the using project's source tree * needs the additional 'Google Mock' library for certain things such as comparing collections Boost Test: * uses exceptions to terminate tests * use is with pre-built libs/source that are not copied in-tree (which is an external dependency on that Boost library) * does not have an academic/artificial distinction between 'Mock' objects and general fakes/stubs So as long as it looks good to switch to Google Test, I'd suggest copying in Google Mock to our source, since it is a superset and contains a copy of the full Google Test sources. We should keep the actual gmock use to a minimum (even Google themselves warn against Mock overuse), but the collections support alone is extremely useful.

1 0

[Tracing] Kopf-Lischinski compatibility
by Vinícius dos Santos Oliveira 20 Aug '13

20 Aug '13

I reallized that something (T-junction heuristic) I thought it was the home of the bug was a false assumption. The bug was in the customized (will be replaced by lib2geom) printing function. Moving on, I initiated a poll on my blog about a matter that will impact any user of this (libdepixelize) project, with its accompanying information: http://vinipsmaker.wordpress.com/2013/08/20/should-i-really-target-kopf-lis… I'll sleep a bit and back to coding when I wake up. See ya. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

1 0

[Tracing] Report #7
by Vinícius dos Santos Oliveira 18 Aug '13

18 Aug '13

I fixed the problems with holes in libdepixelize algorithm. Now the only blocker before work on B-Splines optimization is fix the position of T-junction nodes. I small video of the "polygon with holes": https://vimeo.com/72611259 And a small post describing the last algorithmic changes: http://vinipsmaker.wordpress.com/2013/08/13/splines-extraction-on-kopf-lisc… -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

1 0

Re: [Inkscape-devel] Inkscape Website: Remaining webpage edits
by Jared Meidal 18 Aug '13

18 Aug '13

Here are some remaining edits I see on the staging website: * Community -Like the Develop parent page this need intro content to the Learn pages to welcome guest engagement * About>>Overview -I dropped some content here. I really needs reworking to form a cohesive voice. If we can formulate a vision for who the readers may be and what resources we want to highlight I think that would help. * Learn -Like the Develop parent page this need intro content to the Learn pages to welcome guest engagement * Learn>>FAQ -I cleaned up some HTML table code and added a few new items here, and need to query out here: do we want to keep the table of contents numbering system? There is a lot of legacy HTML tags associated with this content which was copied over. If this is an organization we want to maintain I can peek in further and try to keep things clean. * Screenshots - do we want this to be a gallery of entire-screen shots showing various work processes at various stages, or a highlight of latest features ordered by release versions (like the existing website), or focus on showcased types of media which can be created (such as the existing Showcase webpage http://inkscape.org/showcase/index.php?lang=en) ?? I've added a few notes in the blueprints of the pages to maintain a list of references content is being pulled from and for vision of the pages: https://blueprints.launchpad.net/inkscape-web Finally some of the "Banner Features" on the homepage require linking and content right? Such as the Features, Gallery and Learning Resources. Sorry if this perhaps addresses too many areas at once. --Jared

2 1

Inkscape Website: Translation Instructions
by Martin Owens 18 Aug '13

18 Aug '13

Hey Devs and Users, I've updated the wiki explaining the new Inkscape website's translation instructions. New translations have accidentally overwritten the English content in some places (especially the front page) so to avoid this I've put together a brief explanation of why the front page is hard to edit. http://wiki.inkscape.org/wiki/index.php/WebSite#Translations Please do copy plugins into your local language instead of editing the English versions. All editors are reminded that each language can have different plugins for the same content-location if they wish. Website: http://staging.inkscape.org If you don't have an account and would like to help get content ready, login and send me an email so I can enable staff privileges for you and have you editing the CMS. Happy Editing, Martin Owens

7 55

removing overlapping lines
by Andrew Baxter 17 Aug '13

17 Aug '13

Hi, I have an SVG file which I want to burn using a laser cutter, and I was hoping to use inkscape to remove the overlapping line segments which are causing a problem with the laser cutter. (Where two lines in different shapes overlap, the line is cut once for each shape, leaving a heavier line). See here for details of my project: http://blog.highfellow.org/?p=37 There is already an inkscape plugin for removing double lines, but it's not working for the complex shapes in this file. (Inkscape crashes). See this forum post for the plugin: http://www.inkscapeforum.com/viewtopic.php?f=5&t=9578 . I was thinking of trying to fix or rewrite the plugin, but could do with some help getting started. The plugin is implemented as a filter in python, using this inx file: <inkscape-extension> <_name>Remove redundant edges</_name> <id>org.novalis.filter.removeredundant</id> <dependency type="executable" location="extensions">removeredundant.py</dependency> <dependency type="executable" location="extensions">inkex.py</dependency> <effect> <object-type>path</object-type> <effects-menu> <submenu _name="Modify Path"/> </effects-menu> </effect> <script> <command reldir="extensions" interpreter="python">removeredundant.py</command> </script> </inkscape-extension> I was thinking it might work better to implement the plugin as a python language binding extension, rather than as a filter, so that I can use functions and methods from the native inkscape API. One question is where I would start doing it this way; another specific question is whether inkscape has a 'is point on line/curve', or 'nearest point on line/curve' function built in? If so, this would save me a lot of hassle trying to write one. Thanks, andrew baxter

3 3

[CAD] Status
by Sebastian Götte 17 Aug '13

17 Aug '13

Hi, This week I mainly squashed some bugs. The current code [0] still requires -std=c++11 in the CXXFLAGS. Connector creation is working properly now, without stray points left over afterwards. Points can be selected in groups which can be transformed (scale, shear, rotate, translate etc.). Simple orthogonal routing and straight routing work. Libavoid routing works as far as there are no objects to be avoided (I did not yet test it with objects to be avoided). Multiple connectors can be connected to the same endpoint. Remaining problems are: * When moving a connector in selection mode ([F1]), sometimes a stray point appears somewhere inside the bounding box of the original connector (strange one!). * Connector aborting does not work yet. I deactivated these 10 lines for now. * There are some open UI questions: - How to disconnect connectors? - How to re-connect connectors to different endpoints? - How to edit SPPoints as parts of groups? How to move them into groups? - Probably some more which I forgot * Libavoid routing is still untested. * Sporadically, I manage to get the UI into some infinite recursion. I am looking into these issues. Best regards, Sebastian [0] https://code.launchpad.net/~h-e-6/inkscape/connector-wip

3 2

[Templates] Report
by Jan Darowski 17 Aug '13

17 Aug '13

Hi! Now all the static templates support is ready and working. I've been working for some time now on understanding extensions. Soon first commits for this part should appear. Slagvi, Jan Darowski

2 1

[CAD] Comments and SVG Connector proposal
by Tavmjong Bah 16 Aug '13

16 Aug '13

Sebastian, Good to see you're making some progress squashing bugs. I've played around a little bit with the code. Here are a few observations: 1. Points (ports) need to be shown on the screen independent of whether or not they are attached to connectors. 2. Creating a connector should use a pre-existing point (port) if the cursor is near a point at the start or create a new point if it is not. The same thing should happen for the end point. 3. A distinction needs to be made between dragging a freely movable start/end point and moving a connector end from one port to another. 4. In your current code, drawing a simple connector creates a start point and an end point at the beginning of creating a connector. At the end, a new end point is created but doesn't seem to be actually used. 5. There needs to be one final redraw at the end of creating a connector. Since getting something out of Doug is like pulling teeth, I've put together a page on what I envision SVG 2 connectors to look like.[1] The key point (no pun intended) is that connection points can be defined using percentage values related to the objects they are part of or to the connector end points themselves. The one problem I have is how to specify a connection point inside a <symbol>. I hope to discuss this at the next SVG Working Group meeting. Your feedback (or anybody else's feedback) is welcome. Tav [1] http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml

2 1

crash revovry
by younes mesbah 16 Aug '13

16 Aug '13

Hi, I've made a dialog box in GTK,i need to knew from wich file i can call my dialog box (inkscape's code files) with "dt->_dlg_mgr->showDialog("mydialog")".thinks.

1 0

inkscape crash recovery
by younes mesbah 13 Aug '13

13 Aug '13

hey everyone , We want to create a dialog box to revover files in case of crash and we still don't know how to open the crash-recovery box at the start of inkscape . thanks for your help .

2 1

[CAD] Status
by jaseg 13 Aug '13

13 Aug '13

Hi, This week, again I feel I spent way too much time in gdb I moved the code from using SPKnot for handles to ui/tool/ControlPoint. I did this not for dragging (SPKnot has built-in dragging) but for the selection feature of SelectableControlPoint s. Connector creation by dragging or clicking both ends works now, live preview works, saving connectors works. Remaining are a couple of segfaults: One when closing inkscape without saving just after a Connector has been created while the connector tool is still active, and one when I try to drag an endpoint of the connector. This one is actually quite tricky, I have not yet been able to track down its cause properly. Another issue is that when a Connector is created with two clicks (but *not* when it is created via dragging), I have a leftover SPPoint at its start. I think I know where this comes from, but I have not yet found out how to properly delete a SVG object in inkscape without segfaulting. And finally, though I can save SPPoints and SPConnectors just fine to SVG, I can't load them yet. I would appreciate some eyes on the connector creation code in SPConnector.cpp with respect to the SPPoint dragging segfaults. I am not very confident of my work in ref/unrefing things in the connector context. The code can be found at [0]. To compile it, add -std=c++11 to your CPPFLAGS. It still needs that for a little variadic template I wrote. I will change this to a bunch of non-variadic ones for pre-C++11 before integrating. Best regards, Sebastian [0] https://code.launchpad.net/~h-e-6/inkscape/connector-wip

2 2

Gtk+ 3 test-binaries now in PPA
by Alex Valavanis 12 Aug '13

12 Aug '13

Hi All, Daily builds of Inkscape with experimental support for Gtk+ 3 are now available in the trunk PPA. I've named the package "inkscape-trunk-gtk3". So... 1. We now get early warnings about build-failures with Gtk+ 3. However, please remember to do a local test build with Gtk+ 3 support before pushing any major GUI changes to trunk. 2. It's now easy to test the Gtk+ 3 version on Ubuntu without needing to manually build from source Note that there's a bug tag "gtk3" for tracking the (numerous) runtime errors [1]. If you spot any new issues, or know how to fix anything in the tracker then please get involved! Cheers, AV [1] https://bugs.launchpad.net/inkscape/+bugs?field.tag=gtk3

2 1

Boolean ops (again!)
by Eric Greveson 09 Aug '13

09 Aug '13

Hi devs, I'm looking at Boolean operations (particularly Difference ops) on real-world SVG files again, and I've come across another bug, which I've reported here for posterity: https://bugs.launchpad.net/inkscape/+bug/1209281. This comes with a sample SVG file which might reproduce the bug. Note that I say "might" because it is reproduced on the current trunk on my x86 Ubuntu 12.04, but not on the latest Windows build I'm running (0.48.4). I aim to have a look into what's going on here and hopefully come up with a patch - I've looked through the livarot code in a bit of detail now, and I think I understand at a basic level how the various path-intersection algorithms are implemented (particularly wrt quantization of coordinates and the implications for the sweep-line method). Meanwhile, a couple of questions: 1) While I expect I'll be able to fix the current unstable behaviour (occasional copying of topmost path's coords into bottom-most path during difference operations, for too-small paths that "fall through" the quantization grid), the whole requirement for quantization in livarot is a bit unsatisfactory. Longer-term, it might be nice to switch to a path-intersection algorithm without the quantization restriction, and that deals better with degenerate cases - perhaps something like the CGAL 2D intersection methods ( http://www.cgal.org/Manual/beta/doc_html/cgal_manual/packages.html#part_VII… I believe this part of CGAL is GPL licensed, is this an issue? Thoughts? 2) I keep coming across code in Inkscape that could be improved with the RAII pattern (particularly, things like: { Thing *t = new Thing(); ... do stuff with t ... delete t; } When writing new code, I'd much prefer to use smart pointers, e.g. { std::unique_ptr<Thing> t(new Thing()); ... do stuff with t ... } Obviously things like std::unique_ptr and std::shared_ptr require (part of) C++11. I note that parts of inkscape use boost::shared_ptr - is use of boost the way to go in this case, to keep support for older (non-C++11) compilers? Thanks Eric

5 5

Pre-merge checks
by Alex Valavanis 09 Aug '13

09 Aug '13

Hi All, A minor error in yesterday's merge of the (otherwise great) unit-refactoring branch was picked up by the automated testing in the PPA. Basically, a couple of dead files were not removed from the POTFILES.in list. Can I, therefore, suggest that we always run a "make check" on branches before merging them to avoid this happening again. Thanks, AV

3 2

Staging website blueprints up
by Jared Meidal 06 Aug '13

06 Aug '13

All the current webpages are now reflected in blueprints for the staging website: https://blueprints.launchpad.net/inkscape-web I've used the nomenclature of "+" to indicate child pages, and to include the parent page in the title. There are a number of blank pages still existing: *about+overview *about+screenshots (at least not much) *community *community+gallery (limited) *learn *contribute *contribute+contributor-stats *develop (not much more than descriptions and links to the child content) What stands out to be in this review is that _many of the parent pages are blank_. I also understand that this is the staging site which has not been completed. I would prefer we not simply fill a void by adding content, or simply add links to the content on the child pages. Rather, is there a strong reason for these parent pages to exist at all, beside simply adding a category for the necessary child pages? If there is a vision for these pages I would like to see that reflected in our blueprints. Otherwise I think we may see need to consider a revision of the menu structure to keep a simple site and not loose users in the multiplicity of pages. I would love to contribute more in filling content, if suggestions can be made within these blueprints or through the mailing list! Thanks. --Jared

2 4

Re: [Inkscape-devel] display/sodipodi-ctrl.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

On 5-8-2013 23:13, Krzysztof Kosiński wrote: > 2013/8/5 Johan Engelen <jbc.engelen@...2592...>: >> Hi all, >> Hope that someone who knows a bit about /src/display/sodipodi-ctrl >> can help me with these lines: >> >> for (y = 0; y < side; y++){ >> px = reinterpret_cast<guint32*>(data + y * r); >> for (x = 0; x < side; x++) { >> *p++ = *px++; >> } >> } >> >> The "px++" is not necessary right? Should just be "px" the way I see it. > No, the increment is necesary, because this line is copying an image > row by row. Otherwise it would fill p with copies of the first pixel > in the row. > > The only thing to do here is to perhaps move the declaration of px > inside the loop. Ah, lol, getting late :-) Missed the for loop completely, doh! Thanks for paying attention better than me. Cheers, Johan

1 0

extension/internal/cairo-render-context.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

Hi all, in CairoRenderContext::renderGlyphtext, the variable 'size' is never used. Somewhere halfway, there is some error checking it seems, that sets size explicitly to some hardcoded default value of 12.0. But again this is never used in the method. Is it a bug? Or should it be removed/commented out? Thanks, Johan

1 0

[CAD] Next steps, a trivia question and discussion of the semantics for what objects a connector should avoid
by Sebastian Götte 05 Aug '13

05 Aug '13

Hi, I'm moving on refactoring the connectors code. I just changed the toolbar a little bit so every connector type has its own button. During refactoring, two questions arised: 1. What does "Ege" as in "EgeAdjustmentAction" mean? 2. What semantics do we want concerning which objects are to be avoided by a connector? A little elaboration on the second question: Currently, Inkscape uses libavoid to route object-avoiding connectors. All object which should be avoided by the router are added an "inkscape:connector-avoid" attribute. This does not, e.g., allow an object to be avoided by certain connectors and ignored by others. I can currently see three obvious solutions to that problem: * Avoid objects based on group/layer membership. E.g. avoid any objects on the same top-level layer but ignore others. * Avoid objects based on a "tag". This is not unlike the current approach, but I would really use a class instead of an own attribute for this to be easily interoperable with other implementations of this, especially a potential javascript router as discussed with Doug Schepers from w3c, who is currently working on a SVG connectors spec. Personally, I favor the second solution since I think it is less hacky and more flexible. I think it would be a sane choice to have connectors avoid objects by default and to explicitely mark objects to be ignored while routing. If you wanted a connector ignoring any objects you could just use the non-libavoid routing types I am just adding. * Any combination of the above If you have any thoughts on this, please share them with me ;) I'm now moving on to implement (somewhat minimalistic) "points" as described in [0] so I can then head towards renovating connector-context.cpp. My latest commit to launchpad breaks in an assertion when drawing a connector since it needs these changes. The commit before that should work, though. These "points" will be placed whenever one places a connector's end, except if one places a connector's end on an existing "point". When drawing a connector, all visible points will be rendered as knots. This enables template-based diagram elements which are just are groups that contain a shape and one or more points for the connector to attach. I will remove any logic from connector-context responsible for handling anything but two endpoints (if you want to draw a connector with multiple "stops", just chain together multiple connectors) and remove the "snap connector end point to connector's intersection with destination shape outline"-logic since I do not think this is too useful. Best regards, Sebastian [0] http://dev.w3.org/SVG/modules/connector/SVGConnector.html#PointElement

4 9

dom/cssreader.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

Hi all, For those who know about dom/cssreader.cpp, is this code correct? In CssReader::getPage(int p0): int p = p0; ..... XMLCh ch = get(p); if (p != '{') { error("@page requires '{' before declarations"); } Shouldn't that be if (ch != '{') ? It happens a number of times in that function and looks like a bug to me. If it is indeed correct the way it is now, please add comments to those locations, because it is quite confusing. Thanks, Johan

1 0

display/sodipodi-ctrl.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

Hi all, Hope that someone who knows a bit about /src/display/sodipodi-ctrl can help me with these lines: for (y = 0; y < side; y++){ px = reinterpret_cast<guint32*>(data + y * r); for (x = 0; x < side; x++) { *p++ = *px++; } } The "px++" is not necessary right? Should just be "px" the way I see it. (while fixing it, please also reduce the scope of px) Thanks, Johan

1 0

[CAD] Status
by Sebastian Götte 05 Aug '13

05 Aug '13

Hi, I just pushed some changes to launchpad that fix the GObject instantiation problem I had [0]. I am now explicitely initializing the members to 0. Next comes some cleanup integrating the feedback I received. The current code allows one to place SPPoints and SPConnectors in the document, the three major problems left are state handling in the ConnectorContext (dragging does not work yet), live preview (the "red curve" is not displayed/updated yet) and a missing/superfluous display->doc transform. I just finished moving into a new flat so I did not spend a lot of the last few days at my computer. Best regards, Sebastian [0] https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/files/

3 2

Re: [Inkscape-devel] GObject removal branch
by Markus Engel 04 Aug '13

04 Aug '13

Hi, I'm on vacation from now until (probably) August 21. Thus, I may be able to answer e-mails but I can't work on my branch actively. I opened a merging proposal on launchpad. Maybe any of you can have a look at it and, if no other critical bugs appear, merge it? Regards, Markus

1 0