- Inkscape Devel - Inkscape Mailman

Re ad XY cordinate from .SVG files
by mahendra1 23 Jun '11

23 Jun '11

Hi All Here i upload save file of two separate line. Now I want read the position each line via programmatically, which are as BOLD in following .svg file. Please suggest the way get the position.Is other any document or example for that ,Please suggest me. <g inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1"> <path style="fill:none;stroke:#000000;stroke-width:0.40383452px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" d="m 157.14285,315.21933 397.14286,-0.46595" id="path12" inkscape:connector-curvature="0" /> <path style="fill:none;stroke:#000000;stroke-width:0.88473207px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" d="m 162.85714,327.26862 385.71428,2.23643" id="path14" inkscape:connector-curvature="0" /> </g> Thanks -- View this message in context: http://old.nabble.com/Read-XY-cordinate-from-.SVG-files-tp31909411p31909411… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

Modevia Win32 builds
by Josh Andler 22 Jun '11

22 Jun '11

It looks like there haven't been any new builds since the cairo merge, who is the point of contact for getting that all working again? Cheers, Josh

1 0

versioning scheme, take 2
by Josh Andler 22 Jun '11

22 Jun '11

Hey all, Almost two years later and there has been no consensus. It is being brought up again due to a brief discussion with JonCruz via IRC. So, does anyone want to change from the leading 0 scheme at this point? Jon mentioned potential of 4.9 as opposed to 0.49, or the year/month method as Ubuntu uses for example, if 0.49 is released in Aug/Sept it would be 11.08/11.09. Bryce had also suggested a year/current system hybrid a couple years ago when last discussed, such as 2011.0.49 (which I guess I'd rather see something like that go more like 11.49). So... thoughts on if we should do this? My vote? Yes... we need to have a solid leading number because that matters (psychologically) to a number of users. Besides, with Google & Mozilla incrementing version numbers in their software so quickly, it makes me feel less like we need to hold to a very developer oriented version numbering scheme. (come on, Thunderbird even flat out gets to skip a major digit, so that lessens the blow if we did do decimal bump for a 4.9 or whatever else imho) Cheers, Josh

13 30

Re: [Inkscape-devel] [Inkscape-user] force relative coordinates
by Jasper van de Gronde 21 Jun '11

21 Jun '11

In response to the original question (forcing Inkscape to use relative coordinates): if anyone wants to change Inkscape's behaviour, the relevant code is in src/svg/path-string.cpp, if you need help changing it, just mail me. (Otherwise, I *may* get around to adding an option myself, but it could take quite a while.) On 21-06-11 13:13, A. da Mek wrote: >>> What would be the best way of forcing the path to (always) relative >>> coordinates? > >> The current behaviour is that Inkscape minimizes the length >> of the path data. > > How can the choice of absolute or relative coordinates affect the length of > the path data? Suppose you have a line from 10,10 to 12,13 then "M 10,10 L 12,13" is longer than "m 10,10 l 2,3". When you have very complex paths this can matter quite a bit. In addition Inkscape leaves out the commands whenever it can, to save even more. It could save still more by doing things like removing white space where possible and such, but that makes the path data really a lot less "readable" and offers relatively little in terms of size reduction. > It is so that the absolute coordinates are used when the node is nearer to > the origin than to the previous node? It is actually a bit more complicated. It uses a technique called dynamic programming to decide on a GLOBALLY optimal strategy. So it can pick the longer alternative locally if that means the complete string will get smaller. > Then maybe translate the layer at least of one page width to left and page > height to top, and all coordinates should be relative. > But when I tried to test this idea, I found that the coordinates are allways > relative if the > preference"allow relative coordinates" is checked. > I thought that this behavior maybe changed in a newer version, so I upgraded > from 0.47 to 0.48.1, but still all coordinates are allways relative. I'm not entirely sure what you mean. If you think you have found a case where Inkscape makes the "wrong" decision (that is, it outputs a longer string than necessary), that would be a bug and I'd love to hear about it. If you're seeing it mostly choose relative coordinates, that is because it favors relative coordinates when all things are equal (this tends to avoid switching between the two, as relative coordinates are hardly ever worse than absolute coordinates). > (BTW, the the length of the path data would be better minimized were the > coordinates smartly rounded instead of such values as -113.000006 > or -12.99999) If you see things like that there can be a number of things going on. One problem is that Inkscape (currently) has to write out values in the decimal number system while internally it uses binary numbers (of course). This leads to a whole host of problems, not the least of which is cases like the ones you give (although generally integers aren't a big problem, so that's a bit weird). Then there is the problem that as you move things around (or even place things) Inkscape works with limited precision and errors might accumulate. When the error gets large enough you can get numbers like the ones you give. Inkscape does round the numbers it writes out though, and you can control that through the preferences. Making numbers "snap" to integers when they deviate from an integer by more than the allowed tolerance is problematic at best. Now, unfortunately you do not give the full path in which you see these numbers appearing, but if these are from relative coordinates then there is a good chance that it is a bug. Suppose that you have set Inkscape to use only 4 digits, and you have a line from 1200.2,0 to 1210.4,0. Using absolute coordinates this would be "M 1200,0 L 1210,0". Using relative coordinates this SHOULD become "m 1200,0 l 10,0", and NOT "m 1200,0 l 10.4,0", and Inkscape does have code to deal with this. So if it does not act like this, then you have found a bug and I'd love to know about it. Especially the -113.000006 has me worried a bit, is it from an actual path? If so, can you please send me the full path data? There is a chance that it is legitimate (again, Inkscape can make a locally suboptimal choice if that ultimately leads to a smaller string), but it does not happen that often, so I'd like to see what happened here.

1 0

New video: Improvements to the new Measurement Tool in Inkscape
by Felipe Sanches 21 Jun '11

21 Jun '11

A new screencast showing the improvements to the Measurement Tool implemented this week: http://www.youtube.com/watch?v=LjfVyGbHsdc Happy hacking, Felipe Sanches On Mon, Jun 13, 2011 at 5:39 PM, Felipe Sanches <juca@...2270...>wrote: > Hello, > I'd like to let you all know that I have been working on a new tool for > measuring objects in Inkscape. Here is a screencast of the tool: > http://www.youtube.com/watch?v=CZKnxTO11xE > > But if you checkout the development code from Bazaar , then you'll see some > new things that were implemented in the tool after recording the screencast > (i.e. the tool now displays angle info also). > > Happy Hacking, > Felipe Sanches > > PS: If you find bugs prease report them and assign the bugs to me at > Lauchpad bug tracker. >

9 11

CSS in SVG tests
by Tavmjong Bah 20 Jun '11

20 Jun '11

Hi, I've been slowly adapting some of the CSS 2.1 test suite to SVG. You can find the tests at: http://tavmjong.free.fr/SVG/SVG_CSS_TESTS/2.1/HTML/index.html The tests have been given the same names as the CSS tests they were inspired from. The tests are not guaranteed to be correct. Each page displays the SVG file next to PNG rendered by Inkscape. Tav

2 1

Using xpath in Inkscape code?
by unknown＠example.com 19 Jun '11

19 Jun '11

I would like to be able to select nodes using XPath: https://bugs.launchpad.net/inkscape/+bug/798640 I naively assumed this would be trivial but when I dig in the code it doesn't seem like it is. In particular it is not immediately obvious how to convert between Inkscapes DOM model and libxml2:she model. The simplest way I can think about now is a workaround involving loading the file with libxml2, and find the nodes in that tree instead. I can't be the only one wanting to do things like this. I'm obviously missing something, right? -- Joakim Verona

4 5

Code Walk Through
by Jeremy Villalobos 19 Jun '11

19 Jun '11

Hello: I am a new developer. I have dowloaded Inkscape source, compiled it, and have browsed the code with Eclipse (my favorite IDE). My end goal is to collaborate to add open_cl to Inkscape to make it superfast ! For now, I would like some guidence about the code. Is there a code walk-through either presentation style on youtube or a guide (link) ?

5 5

Re: [Inkscape-devel] Font fall back support for inkscape
by gespertino＠...400... 18 Jun '11

18 Jun '11

>> Instead, the list should be parsed and each character in the text should be displayed using the first font in the list which is >> a) available >> b) has a glyph for that character > > Interesting. I doubt that Inkscape will ever implement the correct > behavior as it would require that Inkscape be able to do all the book > keeping to know which characters are available in which font. At the > moment we use Pango to come up with the best match for a given font > specification. Getting Inkscape to use the first available font in the > list will be a small step forward (right now it treats a font list as a > single font name and thus won't match anything). I'm not sure if this is completely related to this discussion, but I'd like to leave my 2 cents. Currently inkscape does a rather weird font substitution (at least I, as a user, can't tell how and when it works) and there's no clear indicator of that substitution except the warning icon in the font selector once the text element is edited. In my experience (both with libre and proprietary applications) automatic font fallback has never been completely succesful and frequently it's more problematic than helpful. Manual selection of the replacement is always annoying but at least less dangerous. To make it worse, there's no visual indication that fonts have been replaced in Inkscape, so things can look fine at a first glance when in reality they are very wrong when you sent the artwork to print, exported, etc. Automatic font fallback can be useful for document accessibility, but from a graphic designer perspective it's too dangerous to be considered as a viable option. Since I consider Inkscape a design application I'd say it's more important to actually KNOW that the original font isn't available than finding a quick replacement (which potentially could completely destroy the original design because the character set isn't complete, metrics don't match or simply its style is different). IMO the ideal solution would be the use of embeddable fonts as it was stated before, but meanwhile a safer choice would be to replace the missing fonts using the default (or yes, using some font replacement technique) but making it visually clear the the fonts used in the document aren't the originally assigned, using some highlight or visual cue of some kind. But anyway, before speaking about how fonts have to be replaced, Bug #168658 should be addressed since it's too dangerous for artwork integrity.

1 0

Show/Hide objects to export in command-line
by Thibaut Girka 17 Jun '11

17 Jun '11

Hi, I'm using inkscape for various projects, and I'm now concerned about automatically rendering graphics for my game project. However, several images are rendered from the same SVG file, with different layers/objects visibles. While --export-id (and --export-id-only) is helpful in some cases, it's not always sufficient. Therefore, I think hiding certain objects with a new command-line option such as --hide-id would be a worthy improvement. Allowing multiple --export-id might be useful too. Regards, Thibaut Girka.

3 4