- Inkscape Devel - Inkscape Mailman

GSoC Midterm Evaluations
by Gail Banaszkiewicz 06 Jul '07

06 Jul '07

Just wanted to give a heads up to anyone that doesn't receive these announcements, and for those that interested in the program but aren't directly involved. Gail LH wrote: > Hello everyone, > > All participants in GSoC should take a moment to peruse the newly > published midterm survey documentation. The document covers > information for students, mentors with assigned students, mentors > without assigned students and organization administrators. There are > detailed instructions for submitting the surveys, as well as a > granular survey timeline. If you have any questions after reading the > documentation, just let us know. > > Cheers, > LH > > http://groups.google.com/group/google-summer-of-code-announce/web/midterm-s…

3 2

Crashbug on fixing XML node creation.
by unknown＠example.com 05 Jul '07

05 Jul '07

Hi all, I am about to fix a bug in the code... /display/canvas-grid.cpp line 229: newnode = xml_doc->createElement("inkscape:grid"); newnode->setAttribute("type", getSVGName(gridtype)); repr->appendChild(newnode); Inkscape::GC::release(repr); <--- this line should be there but isn't When I add that GC::release line, a strange bug appears. When repeating grid creation and undoing by pressing the new button and then pressing ctrl+z, first it works fine, but after a number of repetitions Inkscape crashes (svnhead, WinXP). Can anyone shine light on this matter please? (note that i did not yet commit this 'fix') Cheers, Johan

2 1

Svg to pdf color not exported
by PICHOT ANTOINE 05 Jul '07

05 Jul '07

Hello, I'm using Inkscape 0.45.1, built Mar 21 2007 on Windows XP. The pdf produced by an export (using save a copy...) of the attached file does not include the color. Is this a known bug/behaviour ? Can someone help ? Cheers, Antoine Pichot Alcatel-Lucent Research Engineer Research & Innovation Centre de Villarceaux Room COP 2.A06F Route de Villejust 91620 Nozay antoine.pichot@...1768... Tel : +33 1 3077 2663 Fax : +33 1 3077 6177

1 0

Script Updates
by Ted Gould 05 Jul '07

05 Jul '07

Okay, I've committed some updates, which I think fix most of the minor issues. -- Effects without GUIs work now -- The working directory for scripts is the same as the working directory for Inkscape instead of a temp directory. I don't think this fixes all the win32 issues -- but it is the same as before. -- Parameters don't have extra quotes -- Removed plugin code to the SVN history --Ted

4 10

Re: [Inkscape-devel] Google Summer of Code
by Ted Gould 05 Jul '07

05 Jul '07

On Thu, 2007-06-28 at 14:42 -0500, Christopher Brown wrote: > I'm trying to find out if I can affect embedded images without writing > temporary files by using ImageMagick's blobs, so I'm implementing IM > in Inkscape via MagickCore. The problem is that after I affect an > Image, sometimes Inkscape doesn't update the image to reflect the > change (since I don't change the filename), until I save it, or copy > the image, or do something to it. I think that you need to emit the contentChanged signal from the node. But, I can't seem to figure out how this is supposed to be done. I'm CC'ing the -devel list to see if someone can help you there. > I'd run the update sp_item on every item in the selection, but that > method wants a SPCtx pointer, and I have no idea where to get that. Is > there an easier way to update the sp_image or can you tell me how to > get the SPCtx pointer? I think that you're going to have to keep things at the repr/xml level because I don't think that we currently have a way to take the data modified in the SP_ level and reencode it back into a PNG for the repr level. So, it'll be better to have IM build the PNG and place it on the XML node as data. Then Inkscape can pull it into the renderer. Not as efficient, but it should work without having to implement some crazy PNG stuff. (again, the people on -devel may correct me :) ) --Ted

1 0

back-compatibility: font name quoting
by MenTaLguY 05 Jul '07

05 Jul '07

It looks like recent trunk has begun putting single quotes around font names with spaces in them; I believe this is fine in terms of the CSS spec, except that recent released versions of Inkscape can't parse that and end up using the default font (generally bitstream vera) instead. Ideas? -mental

3 10

n00b questions
by joel＠...1709... 04 Jul '07

04 Jul '07

Hi, Given that I'm pretty new to the Inkscape developement world, I had a couple questions. The first is this: what hurdles stand between Inkscape today, and v1.0? I love using it, and I've now completely migrated over from CorelDRAW. I'm really keen to see Inkscape develop and become more and more popular, for a couple of reasons: 1. it's good for the world, and 2. more users mean more developers which means more features/innovation more quickly - which is good for me! v0.45.1 is great, and v0.46 will be even greater. I'm now happy to use Inkscape for most of my design work. It's not perfect - it's a bit rough around the edges, but in general it does the job pretty well. From my point of view, the app needs a bit of polishing here and there to improve slickness, but generally it's in pretty good shape. However, reading the roadmap it says that we're at least 11 releases away from v1.0. If you're roughly on a 6 month release cycle, that puts v1.0 at least 5 years away! Surely that's not right? I worry that until Inkscape gets to >v1.0 it will be seen as "experimental" and "unstable" by many. I worry that until 1.0, the app will languish, not attracting the user base or developer base it deserves.. Companies won't trust it, and Ubuntu probably won't bundle it for example. So to rephrase my question: how many of the tasks in the roadmap are *truly* necessary? Maybe I'm being niéve, but surely inkscape doesn't have to be all things to all men - even at 1.0. Many of the ideas seem tantalysing; I can't wait. But surely we need to sort between "must have" and "nice to have". We can add the "nice to haves" into v1.1, or v2.0 just fine, no? I'll ask my second question in a second e-mail.

4 3

Re: [Inkscape-devel] Script Updates
by joel＠...1709... 04 Jul '07

04 Jul '07

For myself I would like to see as much live updating in inkscape as possible. The more visual feedback the user gets, the more fluid the app will feel. If using an effect were like compiling a program, then: no, you wouldn't want to update every time you change a line of code. Compiling is slow, and the intermediate results are completely useless. However, we're trying to help te user be artistic. Effects generally run quite quickly, and the intermediate results are often useful in helping the user find the magic combination of parameters that create just the right effect. Live updating needn't make inkscape feel slow if: 1. script threads run at low/medium a priority so the rest of the app/system don't lock up. 2. script execution is quickly aborted if the user changes a parameter, or presses cancel. On a connected topic: would it be worth adding some kind of optional progress API to the python set? This way potentially long running scripts can give some feedback as to the percentage progress that has been made. I think this could be useful when doing live preview, or when doing the final render. Otherwise a script is rather like the Turing Machine; you never whether to give up waiting. ---------------------------------------- From: "bulia byak" <buliabyak@...400...> Sent: 03 July 2007 10:35 To: "Ted Gould" <ted@...11...> Subject: Re: [Inkscape-devel] Script Updates On 7/3/07, Ted Gould wrote: > Well, I challenged whether this is required in a previous e-mail, and > you didn't respond. So I assumed that you thought my logic was > flawless :) It's not about logic. It's about "feel" if you like, about perception and doing what is expected. If I have a dialog with several parameters, and you set them in turn, you are not interested in seeing the result after only one parameter is set. But once you set the first parameter, you see something changing on your canvas and you waste your time trying to figure out what happened. This is annoying and wasteful (although, of course, in another situation where I want to fine-tune the parameters, it's a huge time saver). -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

Re: [Inkscape-devel] n00b questions
by joel＠...1709... 03 Jul '07

03 Jul '07

A thought just occured to me: would it be useful for someone to create a wiki page that contains a list of *all* the SVG features (maybe the contents page of some SVG specification), so that we can check off the things we have, and people like me can see what remains to be completed? ---------------------------------------- From: "Joshua A. Andler" <joshua@...533...> Sent: 03 July 2007 12:21 To: joel@...1709... Subject: Re: [Inkscape-devel] n00b questions joel@...1709... wrote: > > Hi, > Given that I'm pretty new to the Inkscape developement world, I had a couple questions. > > The first is this: what hurdles stand between Inkscape today, and v1.0? Better SVG Compliance. I believe the last discussion put it at SVG Tiny 1.1 being fully supported. As great as Inkscape is in the general vector realm, we are first and foremost (specifically) an SVG editor. I also recall there being goals for falling below a certain amount of bugs or something along those lines. > If you're roughly on a 6 month release cycle, that puts v1.0 at least 5 years away! > > Surely that's not right? The above addresses this. If we had full support tomorrow (which won't happen), the next release could be targeted 1.0. > I worry that until Inkscape gets to >v1.0 it will be seen as "experimental" and "unstable" by many. I worry that until 1.0, the app will languish, not attracting the user base or developer base it deserves.. Companies won't trust it, and Ubuntu probably won't bundle it for example. Being with the project for a few years, I can tell you it's seen nothing but steady growth and adoption. It seems that once people understand why it's not "1.0", they get past the superficial numbering. Honestly, if people choose software based on version number, they're not properly evaluating all candidates. That said, if people view Inkscape as a general purpose vector editor and not an SVG editor, if we hit 1.0 without full color management support and rockstar pdf output, things would look really bad to them. Oh and as for Ubuntu bundling it... two of our core devs are Ubuntu developers, so if we will ever stand a chance, it probably lies more with their powers of persuasion (and user demand) than a superficial number. ;) For the record, the first thing that Ubuntu utilizes on your computer at startup (GRUB) is only 0.97, or rythmbox which is a default install is at 0.11, etc... so I don't think numbers matter that much. So... if you want to get things moving toward 1.0 you can either polish up the rough edges you see, or work toward SVG Tiny compliance. Either way, it moves Inkscape forward. :) -Josh P.S. I'm sure others will elaborate more and make me look like a fool. ;)

2 1

Re: [Inkscape-devel] Second n00b question: Cairoification
by joel＠...1709... 03 Jul '07

03 Jul '07

Thanks for both your answers, they're both very informative. Sorry abut th ^Ms, the "SmarterMail" web client I'm using is maybe not so smart. The problem'll go away by next week when I get back on my real mail client. ---------------------------------------- From: "Joshua A. Andler" <joshua@...533...> Sent: 03 July 2007 12:27 To: joel@...1709... Subject: Re: [Inkscape-devel] Second n00b question: Cairoification joel@...1709... wrote: > > Here's my second question: how's the cairofication coming along? Cairofication is awaiting a few fixes in Cairo. My understanding is that after that, we're golden. > For me this would be a truly killer feature: fast hardware rendering in OpenGL. What problems stand in the way of us switching over before the next release? I heard about the problem with off-centre elipse gradient fills. Is this the only sticking point? Couldn't we just cludge it by composing the gradient out of loads of bilinear filled triangles, or by a pile of ellipses? Or couldn't we put pressure on the Cairo guys to add support - wouldn't having Inkscape use their engine be a big incentive for them to grease the weels? Bulia and Carl Worth (a core Cairo dev) know what fixes we need. There are 3 or 4 of them I believe. A couple which are pretty serious. One relates to spurious lines showing up when zooming in. Another relates to Masks not rendering correctly (which you could possibly look into on our end to make it compatible with how Cairo currently wants masks, as it would be faster than waiting for the fix on Cairo's end - per Carl). And there is one or two more that I don't recall offhand. Honestly, before any faster hardware rendering, the biggest benefit we get is half the memory consumption... not to mention free renderer upgrades as Cairo improves. > Or are there other things to think about? or is it simply a work in progress for the assigned developer? If you would really like to look into making this stuff happen, please let us know. You could also drop by our jabber room or IRC to talk as well. -Josh

1 0