- Inkscape Devel - Inkscape Mailman

libgdl issue
by Jon Cruz 29 Jun '11

29 Jun '11

Hi, in clearing up some warnings, I (as somewhat expected) spotted a potential issue hiding amongst the others. libgdl/gdl-dock-item-grip.c: In function 'gdl_dock_item_grip_expose': libgdl/gdl-dock-item-grip.c:143: warning: assignment from incompatible pointer type libgdl/gdl-dock-item-grip.c:146: warning: passing argument 2 of 'gdk_draw_rectangle' from incompatible pointer type If anyone wants something to poke at a bit, checking this might be good.

3 3

Inkscape CSS class handling
by Abhishek Sharma 29 Jun '11

29 Jun '11

Hello everyone, I just wanted to make sure, that does inkscape handle classes in CSS <style> element inside an SVG. In other words if a <text> element has <text class="one">, then does this text element inherit the properties in class="one" ?? if it does it, may someone tell me where in the codebase could this be found(although I'll be happy with the answer to first question also :) ) -- Regards, Abhishek Sharma

1 0

problems in compiling on windows
by Abhinav Vishwa 28 Jun '11

28 Jun '11

>> I have compiled Inkscape completely according to instructions given on >> this link >> http://wiki.inkscape.org/wiki/index.php/Win32Port >> >> but as given there is no executable in the inkscape directory. >> >> That's why nsis installer is also giving error in creating installer. > > Just a few more details could help. What exactly did you do, and what > was the result? In particular, where there any errors during > compilation? (Compilation should end with a whole lot of things being > copied and then showing the total amount of time spent on the > compilation.) Did you make sure that you have both devlibs and trunk, > and that the paths in mingwenv.bat point to the right locations? Are you > using TDM's gcc? Have you built buildtool? Do you get a build directory? > If so, what does it contain? Etc., etc. I did each and every step as given on the link , I've provided. There weren't any error's in the compilation. yes, I've both devlibs and trunk and here is the mingwenv.bat @echo Setting environment variables for MinGw build of Inkscape IF "%DEVLIBS_PATH%"=="" set DEVLIBS_PATH=c:\devlibs IF "%MINGW_PATH%"=="" set MINGW_PATH=c:\MinGW set MINGW_BIN=%MINGW_PATH%\bin set PKG_CONFIG_PATH=%DEVLIBS_PATH%\lib\pkgconfig set PATH=%MINGW_BIN%;%PATH%;%DEVLIBS_PATH%\bin;%DEVLIBS_PATH%\pytho which points to the right locations.

2 1

Inkscape license + potential problem
by Krzysztof Kosiński 28 Jun '11

28 Jun '11

Hello I am wondering under what license Inkscape actually is. Most source files don't have the full GPL copyright notice which specifies the version, they only say "released under GNU GPL". This would suggest that most of the code is GPLv2+. There are also several files dual-licensed under MPL and GPL. Our Launchpad website states that Inkscape is under GPLv2. However, I encountered a file which is GPLv3 only, apparently copied from GIMP (src/util/expression-evaluator.cpp). If we really are GPLv2, then including this file is not legal, as GPLv2 is not compatible with GPLv3. We would need to change our license to GPLv3 or GPLv3+ to include this file, or contact the original authors for a GPLv2 or BSD license. PS: our Windows devlibs also seem to be in a "gray area", because most of the copyright information is not present, which might break the license terms of the libraries. I'll try to remediate this by adding the license files from each package, once I have some spare time (i.e. not very soon). Regards, Krzysztof

6 5

Any blockers for 0.48.2?
by Josh Andler 27 Jun '11

27 Jun '11

Subject asks the important stuff. :) Cheers, Josh

3 3

problems in compiling on windows
by Abhinav Vishwa 27 Jun '11

27 Jun '11

I have compiled Inkscape completely according to instructions given on this link http://wiki.inkscape.org/wiki/index.php/Win32Port but as given there is no executable in the inkscape directory. That's why nsis installer is also giving error in creating installer.

2 1

New rendering bug with blur filter
by Ivan Louette 27 Jun '11

27 Jun '11

(Sorry, my bitmap was too big at first time) This bug doesn't exist in 0.48.1 I saw it this morning in rev 10355 on Kubuntu Couls someone confirm it before I fill it on Launchpad ? When blur is combined with a Composite "in" some vertical dark lines are shown on rendering and exporting to bitmap. If vertical blur is set to zero the lines change to dots. If a little amount of black is added they disappear (here I decrease luminance and that works too). ivan

3 2

Code cleanup and minor tweaks
by Jon Cruz 27 Jun '11

27 Jun '11

Hi Campbell, I just wanted to thank you for the recent improvement to our codebase, such as in revision 10359. Getting things fixed such as not passing 'false' in to pointers helps in many ways, including reducing the number of odd, hard to reproduce bugs. I also just wanted to point out a few minor style points that could help. One is with the use of "NULL". That is more of a C macro that in C++ has be replaced with the simple use of "0". I've looked into this point with coworkers and others at various points, and can try to dig up more details if you need them. The other point is in using whitespace. I realize that in your recent changes you have been preserving what already existed, but it is helpful if "cleanup" that touched lines left them with nicer spacing also. We have some info on our coding style page, but the gist is to put spaces between things, but not in the middle of things. :-) That is, space around keywords, operators, etc, but not between a function name and its opening paren. For example, this line you touched could be improved by spacing it thusly &&((l!=NULL&&!edge->isEnd(l->id))||l==NULL) && ((l != NULL && !edge->isEnd(l->id)) || l == NULL) Suddenly that makes the logic and the referencing easier to read and follow. It also gives more visibility to areas that could be made clearer with more parenthesis: && (((l != NULL) && !edge->isEnd(l->id)) || (l == 0) ) if I compare those right on top of each other, the legibility change should show up: &&((l!=NULL&&!edge->isEnd(l->id))||l==NULL) && (((l != NULL) && !edge->isEnd(l->id)) || (l == 0) ) Depending on the font, that might even reveal another problem. In general I strongly dislike single-letter literals (except for the common 'i' in for loops, etc). And even worse is the single letter variable 'l'. In fact, in the font I'm typing with at the moment I can not tell the difference between the lower-case-letter-el, the capital-letter-eye and the vertical-bar-pipe-| (lI|). What is worse is some fonts even make the numeral -one indistinguishable. But this is a side rant on a given bad variable. If you happen to be touching enough lines, consider giving it a better name. Anyway, thanks for the help in this area and the opportunity for me to point out to some of the other newer people on the list what sort of tweaks can help our codebase be more legible and maintainable.

3 5

Extensions and Warnings
by Martin Owens 26 Jun '11

26 Jun '11

I'm trying to solve a bug with my deviantArt stash extension. It produces warnings because poxy webkit with bleedin java and god aweful html decide that it's a great idea to shout out to the world a whole bunch of version information, including any javascript errors that happen in the loaded pages. What cute is that I told the inx to load a bash shell which loaded the python script and to dev/null everything. That didn't hack fix it. I tried redirecting sys.stderr to a file, somehow it still manages to come through. Please tell me there is a way to stop inkscape from reporting warnings from python extensions? There is no reason to report warnings to users unless they can be formatted in a nice way and these can't be. Martin,

2 1

New rendering bug with blur filter
by Ivan Louette 25 Jun '11

25 Jun '11

This bug doesn't exist in 0.48.1 I saw it this morning in rev 10355 on Kubuntu Couls someone confirm it before I fill it on Launchpad ? When blur is combined with a Composite "in" some vertical dark lines are shown on rendering and exporting to bitmap. If vertical blur is set to zero the lines change to dots. If a little amount of black is added they disappear (here I decrease luminance and that works too). ivan

1 0

Build and Devlibs
by Yann Papouin 25 Jun '11

25 Jun '11

Hi, It seems that 3 DLLs are not copied from the mingw/bin directory for the dist target, I had to copy them myself : libgcc_s_dw2-1.dll libpthread-2.dll libstdc++-6.dll Yann.

3 4

Typo/Bug in sp-attribute-widget.cpp
by Campbell Barton 25 Jun '11

25 Jun '11

In function: sp_attribute_widget_object_modified if (flags && SP_OBJECT_MODIFIED_FLAG) { Shouldn't this be '&' not '&&' ? -- - Campbell

2 2

Now the cairo branch is merged...
by Joel Holdsworth 24 Jun '11

24 Jun '11

...would a release be in order? I remember we were longing for Cairo back in 2006! This branch merge is a very big deal! Joel

6 7

Font fall back support for inkscape
by Abhishek Sharma 24 Jun '11

24 Jun '11

Hello everybody, I am a selected candidate for GSoC 2011 and contributed to inkscape in GSoC 2010 as well. I am looking to start the development of font fall back support in inkscape. As discussed with my mentor Tavmjong its a required item and shall be very helpful to inkscape. And as all the readers of this mail might have guessed, I am writing this mail to have the inputs of inskcape developers on this. I would love to have your comments which can help me answer questions like - Where to look into the code, What to change, What to add should it be anew class or an added functionality to a pre-existing class, questions of these sort. Waiting earnestly for all of your responses :) -- Regards, Abhishek Sharma

6 10

Removing dead Inkboard code
by Krzysztof Kosiński 24 Jun '11

24 Jun '11

Hello As part of the general theme for the current development cycle, which appears to be "in-tree forks & cruft must die", I have completely removed Inkboard. Here are the reasons. 1. This code is seriously bitrotted and was disabled for a long time, with no one stepping up to put it back into shape. 2. It is behind times. A modern implementation would use something like Telepathy instead of a homegrown XMPP library. 3. Even if it worked, there is a very good chance it would have several remote execution vulnerabilities. 4. I'm not even sure Inkscape is the proper place for such functionality. It's cool, but it looks very much like feature bloat to me. People can do this much better using Google Docs drawings, which can be exported as SVG. 5. The fact that there were no loud complaints about the disappearance of Inkboard around version 0.47 indicates that few people were using it. Regards, Krzysztof

4 4

Re: [Inkscape-devel] Now the cairo branch is merged...
by Joel Holdsworth 24 Jun '11

24 Jun '11

On 23 June 2011 at 10:06 Jasper van de Gronde <th.v.d.gronde@...528...> wrote: > On 23-06-11 10:43, Joel Holdsworth wrote: > > ...would a release be in order? I remember we were longing for Cairo > > back in 2006! > > I wouldn't recommend it. People have of course had some time already to > test the branch, but I doubt many people did. Now that it is in trunk > anyone working on Inkscape will be using it and it's not exactly > unrealistic to assume that at least one or two issues will come up. > > > This branch merge is a very big deal! > > Yes it is! And I'm very, very glad that it has finally happened, but > doing a quick release after just having merged it might not be the best > thing to do. I do agree that we probably don't want to wait too long, > but I'd at least give it a month or two. I completely agree with you. If we move in that direction, then we'll be ready quite soon. I wouldn't necessarily advocate having a new about screen and trying to create a huge media circus around such a release, I'm just keen to get this into the hands of distros sooner rather than later. Joel

5 5

Cairo branch ready
by Krzysztof Kosiński 23 Jun '11

23 Jun '11

Hello The Cairo rendering branch should be ready for merging. I fixed the rendering of controls, which was apparently the last blocker, and merged from trunk to fix conflicts. Do we wait for Cairo 1.12 or put the experimental 1.11.2 in devlibs? Regards, Krzysztof

11 32

Read XY cordinate from .SVG files
by Mahendra Gajera 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

2 1

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