- Inkscape Devel - Inkscape Mailman

Modevia & Nightlies
by Josh Andler 24 Oct '11

24 Oct '11

Hey all, I got a response from JTC Inc regarding our use of the modevia server and was told that the server is no longer available for us to use. So, the bad news is that we need to find alternative hosting. However, the good news is that they didn't nuke our data apparently. They want to know what we need to be able to retrieve the data, so I left it with a response asking how much data we had on the server... once we know this we can make arrangements to recover the nightly stuff. Now is the fun part... does anyone know of any organizations that would be interested in hosting this stuff for us? I'm almost tempted to say the nightly builds might do well on sourceforge just for the sake of mirroring and having a rough idea of download stats. It's just a thought, no one is married to it. All reasonable suggestions are welcome. Cheers, Josh

6 8

how to get x y coordinate in mm ?
by perry-dev 23 Oct '11

23 Oct '11

Hi, I have one problem related to coordinates. i want to save d attributes in mm unit. for that with the help of google . i have changed default unit "mm" in Document Properties Option. After that i am going to draw 50x50 mm rectangle for that i need to change mm from px in "control tool bar " . now i got attributes like d="M 222.47117,285.53205 L 398.65476,285.53205 L 398.65476,461.71565 L 222.47117,461.71565 L 222.47117,285.53205 L 222.47117,285.53205 L 222.47117,285.53205 z" But when i changed mm to px then also got same attributes d="M 222.47117,285.53205 L 398.65476,285.53205 L 398.65476,461.71565 L 222.47117,461.71565 L 222.47117,285.53205 L 222.47117,285.53205 L 222.47117,285.53205 z" How to distinguish between mm and px . i am really stuck in this Let me know solution...!!! -- View this message in context: http://old.nabble.com/how-to-get-x-y-coordinate-in-mm---tp32704855p32704855… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 2

Regression : now unable to move primitives in Filters Editor
by Ivan Louette 21 Oct '11

21 Oct '11

Now in rev. 10674 I can not move primitives by dragging them through the Filters Editor tree ! I think this is a relatively recent regression. ivan

4 5

Re: [Inkscape-devel] Inkscape-devel Digest, Vol 65, Issue 14
by gespertino＠...400... 17 Oct '11

17 Oct '11

I'm with Felipe on this one. Not only because I endorse free software but also for practical reasons. Supporting proprietary solutions just because of technical reasons might make it harder for FLOSS alternatives to mature if there's a handy proprietary driver/API in use. I wonder who would feel attracted to code optimizations and improvements if the application already works great with that proprietary addon. I also wonder how supporting proprietary (mantaining compatibility with free) impacts on the complexity of the code and if it doesn't add more work to the few developers the project has, even if somebody comes and provides the code. I'm convinced that some short term solutions like this could have a very negative impact sooner or later. nVidia has a good damage record with its proprietary drivers in linux: They work pretty good, so having a free alternative never felt as a real need, and there we are. Intel has better free drivers but inferior hardware, so if you're planning to do serious 3D you have to buy nVIdia or ATI and deal with their non-free drivers. Technically you have the option, but in practice it becomes a hard dependency. I don't think this is a political statement by itself, but coincidentally the political statement leads to the same conclusion. I'm glad to know that FLOSS is priority anyway. :-) Just my 2 cents.

1 0

Polygon in polygon test
by Pippijn van Steenhoven 17 Oct '11

17 Oct '11

Hello Inkscape developers, I'm working on an Inkscape function that sorts paths in an order suitable for 3D rendering. For this, I need to know which polygons contain which other polygons. In my use case, partial containment does not occur, i.e. every shape is either fully contained or has no crossings. I tried to implement this "polygon in polygon" functionality by iterating over all the points of one polygon and using the 2geom function Geom::contains(Path, Point) to test them for containment. However, I found several cases where the function does not yield the expected result[1]. The current method I use is to test for partial inclusion (at least one point is included) and the number of crossings (using the Geom::crossings function) is 0. This is super slow, however, so my question is: how can I efficiently test whether a polygon is in another polygon? [1] http://xinutec.org/~pippijn/files/txt/5c595dad425061f408f82cc6553a354e.txt -- B.Sc. Pippijn van Steenhoven, Projektleiter Tel.: +49 721 486995-22, Fax: -21 (Achtung! Neue Nummern) Mobil: +49 176 78131934, E-Mail: pippijn@...2685... Open Experience GmbH, Postfach: 111014, 76060 Karlsruhe Besucher: Zirkel 2 (im Rechenzentrum, Geb. 20.20), 76131 Karlsruhe Handelsregister: Mannheim HRB 706815, Ust-IdNr.: DE264743573 Vertretungsberechtigter Geschäftsführer: Konstantin Krahtov

1 0

Nvidia accel lib?
by John Cliff 17 Oct '11

17 Oct '11

Anyone seen anything about the new nvidia path rendering extension? May have some potential, and an nvidia guy responded to a post on the forum offering help if anyones interested in looking at it. http://www.inkscapeforum.com/viewtopic.php?f=28&t=10108 Cheers Sim Sent from my iPad

8 16

Latinoware 2011
by Alexandre Prokoudine 15 Oct '11

15 Oct '11

Hi folks, Is any of our contributors going to Latinoware 2011? We might want telling our community about that, if you are :) Alexandre Prokoudine http://libregraphicsworld.org

1 0

Re: [Inkscape-devel] Inkscape style connectors - usability suggestion
by Hans-Jürgen Hay 13 Oct '11

13 Oct '11

> The main idea was to have two types of connection points: some > default > connection points (as currently only the center is) and user defined > connection points. There would be 9 default connection points: the > center (the > only one available now) and other 8 connection points that you get > when you > draw 8 imaginary lines that connect the center to the corners of the > object's > bounding box and the midpoints of the edges of the object's bounding > box and > intersect these imaginary lines with the object's edge. just as an idea, I would suggest to handle connections more generic. Instead of using default and configurable fixed connection points it would be better to attach directly to the objects outer shape using generic connection points. In this case no predefined connection points need to be shown as the shape is shown in any case. When a handle gets near the shape the shape itself might get highlighted to indicate it will catch the handle when dropped. When the handle gets dropped near the shape it should connect to the shapes outer sub element (e.g. the nearest line of an rectangle) at an offset from its center calculated from the point of dropping the handle using a calculated normal. The Object would store the connection by adding an additional connection object to its connection list. Each connection object would at least need: - a reference to the attached handle, - a reference to the shapes sub element, to which the handle is attached - a relative offset from the shapes sub elements center point. - the normal vector to be optionally used for connecting attached line with an angle normal to the outer shape ( eg. for round objects) - sharp edges and the center of an sub element could be made prefered relative positions to snap to This could allow: * to delete connections when getting disconnected. * no need to handling additional default points * scaling of objects without disturbing the arrangement of the attached handles * allow attachments without code to display additional points/crosses/circles to show the user where he can attach the handle * no need decide in advance on the placement of the default connection point * individual placement by dropping the handle where it should stay * grabbing and moving the handle to a different location along the outer shape I don't know anything of the code base nor do I have any time to work on this in any capacity but envision the idea could lead to better diagram layout and improved usability. Hans -- ---------------------------------------------------------------------- Alterras GmbH, Allersbergerstr. 185-N, D-90461 Nürnberg http://www.alterras.de/, info@...1868..., Tel: (+49) 0911-480039-0, Handelsregister: Amtsgericht Nürnberg HRB 18488 Geschäftsführer: Hans-Jürgen Hay, Helga Sivak -----------------------------------------------------------------------

6 10

End shape tool with tool switch
by Samuel Buttigieg 13 Oct '11

13 Oct '11

Hello all Users/Developers, I was wondering if anyone was effected by this small bug(if you can call it one): sourceforge.net. Basically it means that if you switch from one tool to another before pressing enter, the shape/path drawn is destroyed. Is this intentional or would you like this to be fixed? I am looking for your opinions, be it in favor or against, so that if a lot of people appose this idea I won't waste any time on it. Thanks for your time. Regards, Samuel

2 2

Re: [Inkscape-devel] Snapping to paths broken?
by Diederik van Lierop 13 Oct '11

13 Oct '11

On Thu, 13 Oct 2011 11:15:35 +0200, Tavmjong Bah wrote: > Hi, > > With trunk I am having trouble getting snapping to paths to work > consistently. I was thinking about demoing the new snapping to the > intersection of a path and guide. I can get it to work sometimes but > for > the most part my test rectangle will not snap to anything to do with > a > path. Snapping to the grid and guide lines always works as expected. > Has > anybody else seen this behavior? It seems to not work more often with > complicated drawings (many layers). There are some known issues with the related 2geom code. Nathan Hurst is working on this. I expect that's what you're running into. For more details see this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=20110923205906.GA1… I will let you know when this has been fixed. We can then see if any path-snapping bugs are remaining. > I've also gotten this error message a few times: > > ERROR:widgets/toolbox.cpp:2108:void > toggle_snap_callback(GtkToggleAction*, gpointer): assertion failed: > (ptr != NULL) That's something that I need to fix. Which tool are you using? Can you write down the exact steps leading to these warnings? Thanks, Diederik

2 1