May 2005 - Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Memory Problems
by Richard Kowalczyk 07 May '05

07 May '05

Results of comparing zoomed out with regular zoom: regular: memory percent: 6.6% -> 23.6% buffers/cache: 224 -> 310 zoomed out: memory percent: 5% -> 12.5% buffers/cache: 217 -> 254 The zoomed out numbers are very similar to the numbers for just previewing each file. So it appears that you are correct that the memory problem is in the renderer. On Sat, 2005-05-07 at 11:32 -0300, bulia byak wrote: > Interesting, this means that normal loading is indeed different enough > from previewing, memory-wise. We had assumed it's mostly the same, so > we didn't test multiple file loading except via previews (to my > knowledge). > > It may be that the source of the leaking is the renderer, which may > leak more memory for full-screen display than for generating previews > (even though the same renderer is used in both cases). Can you please > try one more experiment: in all your files, zoom out to minimum zoom > and save them under different names with that zoom. Then, load them > all normally one after the other into the same Inkscape instance. If > the renderer is the culprit, this should have some measurable effect > on memory consumption. > > On 5/7/05, Richard Kowalczyk <richk@...805...> wrote: > > I just tried what you suggested, and it seems to use significantly less > > memory. > > > > I had some different apps open this time, so I can't compare it exactly > > with my previous tests, but here is a rough comparison: > > > > opening all files: > > memory percent: 7% -> 45% > > buffers/cache: 214 -> 435 > > > > opening and closing the previous: > > memory percent: 5.9% -> 27.9% > > buffers/cache: 231 -> 342 > > > > inkview: > > memory percent: 3.5% -> 21.9% > > buffers/cache: 226 -> 327 > > > > inkscape preview window: > > memory percent: 5% -> 13% > > buffers/cache: 337 -> 372 > > > > So just previewing the files seems to use up significantly less memory > > than even inkview. > > > > On Sat, 2005-05-07 at 10:58 -0300, bulia byak wrote: > > > Richard, can you also try this: in the Open dialog, just select these > > > files one by one, so that a preview of each one is shown, and see if > > > there's a memory difference at the end. (Each preview loads and > > > renders the entire document.) I do remember that we fixed, at least > > > partially, the memory leaking when going through previews in this way. > > > So what you describe may be explained by: 1) our not fixing the leaks > > > completely, only partially, or 2) Inkscape using a different and > > > not-yet-fixed load path when loading the document fully than when > > > doing a preview. > > > > > > Mental, can you comment? > > > > > > > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > > > I tried doing what you suggested. I went though 26 slides, since it > > > > seemed to be enough to get an indication of the behavior. > > > > > > > > (Just to clarify - I opened the next one (from within the current one), > > > > then closed the current one - if I had closed the current one first, the > > > > memory would be cleared) > > > > > > > > The memory used seems to be roughly equivalent between inkscape and > > > > inkview, although inkview does use less. Either way though, the memory > > > > keeps going up as I go through more slides. > > > > > > > > I attached three files to this email - the result of doing the command: > > > > > > > > ps aux | grep -e "inkview" >> memory.txt; free -m >> memory.txt > > > > > > > > for three cases: > > > > > > > > memory_inkview.txt: after I clicked the right arrow to advance each > > > > slide, I ran the command. > > > > > > > > memory_one_per_time.txt: I did what you suggested, and opened each file > > > > in inkscape, then closed the old one, running the command for each new > > > > file. > > > > > > > > memory_all_open.txt: I opened each file in inkscape, but didn't close > > > > the previous file, so by the end, I had 26 files open at once. I ran > > > > the command after each file was opened. > > > > > > > > Thanks for your help, > > > > Rich. > > > > > > > > On Thu, 2005-05-05 at 19:38 -0300, bulia byak wrote: > > > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > > > > > I will be glad to do anything else that anyone thinks will help explain > > > > > > the memory usage. > > > > > > > > > > Can you try loading these same files in turn (i.e. closing the > > > > > previous one when loading the next) into Inkscape instead of Inkview > > > > > and see if there is a noticeable difference? > > > > > > > > > -- > > > > Richard Kowalczyk <richk@...805...> > > > > > > > > > > > > > > > > > > > > -- > > Richard Kowalczyk <richk@...805...> > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. > > Get your fingers limbered up and give it your best shot. 4 great events, 4 > > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > -- Richard Kowalczyk <richk@...805...>

2 1

Re: [Inkscape-devel] Memory Problems
by Richard Kowalczyk 07 May '05

07 May '05

I just tried what you suggested, and it seems to use significantly less memory. I had some different apps open this time, so I can't compare it exactly with my previous tests, but here is a rough comparison: opening all files: memory percent: 7% -> 45% buffers/cache: 214 -> 435 opening and closing the previous: memory percent: 5.9% -> 27.9% buffers/cache: 231 -> 342 inkview: memory percent: 3.5% -> 21.9% buffers/cache: 226 -> 327 inkscape preview window: memory percent: 5% -> 13% buffers/cache: 337 -> 372 So just previewing the files seems to use up significantly less memory than even inkview. On Sat, 2005-05-07 at 10:58 -0300, bulia byak wrote: > Richard, can you also try this: in the Open dialog, just select these > files one by one, so that a preview of each one is shown, and see if > there's a memory difference at the end. (Each preview loads and > renders the entire document.) I do remember that we fixed, at least > partially, the memory leaking when going through previews in this way. > So what you describe may be explained by: 1) our not fixing the leaks > completely, only partially, or 2) Inkscape using a different and > not-yet-fixed load path when loading the document fully than when > doing a preview. > > Mental, can you comment? > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > I tried doing what you suggested. I went though 26 slides, since it > > seemed to be enough to get an indication of the behavior. > > > > (Just to clarify - I opened the next one (from within the current one), > > then closed the current one - if I had closed the current one first, the > > memory would be cleared) > > > > The memory used seems to be roughly equivalent between inkscape and > > inkview, although inkview does use less. Either way though, the memory > > keeps going up as I go through more slides. > > > > I attached three files to this email - the result of doing the command: > > > > ps aux | grep -e "inkview" >> memory.txt; free -m >> memory.txt > > > > for three cases: > > > > memory_inkview.txt: after I clicked the right arrow to advance each > > slide, I ran the command. > > > > memory_one_per_time.txt: I did what you suggested, and opened each file > > in inkscape, then closed the old one, running the command for each new > > file. > > > > memory_all_open.txt: I opened each file in inkscape, but didn't close > > the previous file, so by the end, I had 26 files open at once. I ran > > the command after each file was opened. > > > > Thanks for your help, > > Rich. > > > > On Thu, 2005-05-05 at 19:38 -0300, bulia byak wrote: > > > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > > > I will be glad to do anything else that anyone thinks will help explain > > > > the memory usage. > > > > > > Can you try loading these same files in turn (i.e. closing the > > > previous one when loading the next) into Inkscape instead of Inkview > > > and see if there is a noticeable difference? > > > > > -- > > Richard Kowalczyk <richk@...805...> > > > > > > > > -- Richard Kowalczyk <richk@...805...>

1 0

Re: [Inkscape-user] eps error (bad encoding)
by bulia byak 07 May '05

07 May '05

On 5/2/05, Aewyn <aewyn@...326...> wrote: > I just try to print from inkscape; as I know the only way to > produce a reasonable sized document is save as .eps > > Is is ok, but all my accent characters (őúéáűó) goes to its > unicode formats, so the result is totally unusable. Convert text to path - this is perhaps the most reliable solution. Other than that, I don't know what encoding the text in PS is supposed to be. I doubt it's Unicode. Latin-1? What about non-Western-European languages? Can any experts comment? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

listener fixes
by MenTaLguY 07 May '05

07 May '05

Ok ... I think I fixed all the bugs in CompositeNodeObserver, so I've comitted my patch. I've not gone through and verified that it fixes all the layer etc. bugs yet, but if it doesn't it should at least make the remaining work of fixing them much easier. The commit ensures that two of my "five invariants" are now observed: * a listener should not receive events that occurred before its registration * a listener should not receive any events at all once it is deregistered Hmm, and actually also that "fifth and a half" invariant: it should be safe for a listener to unregister itself. The patch also had the effect of disabling the 'is_interactive' flag for attribute changes. However, the work I'd done since it had been introduced made a (much cleaner!) replacement very easy. [ I've not actually entirely purged the is_interactive flag yet, since that will require changing a lot of files, but I will do so once we're satisfied that these changes are working out. ] I've been testing most of the night, but please test yourself and see if you turn up anything. I'm still worried that some code somewhere was written that inadvertantly depended on a violation of the first invariant above. -mental

1 0

Extensions Update?
by unknown＠example.com 07 May '05

07 May '05

I just thought I would check in and see if there is anything new going on in the extension realm. (Ted, have you found any time to start working on the interpreter property and absolute paths?) I have recently created an effect that draws microtonal and multiscale stringed instrument fretboards. Sounds very useful doesn't it :) I have also started working on an effect to do isometric path extrusions. I think may have taken this idea as far as I am able. Anyone is welcome to pick it up and improve it if they wish. Besides Multiline text boxes, here are a few other extension autogui widgets I would find useful. Any comments? - Enumerated choices (drop down list box) - File selector - Mutually exclusive parameter groups (tabs) like: <tabset> <tab> <param name="length"></param> </tab> <tab> <param name="firstlength"></param> <param name="lastlength"></param> </tab> </tabset> And lastly Inkscape crashes on startup if an *.inx file contains a string param with an empty default value like this: <param name="crasher" type="string"></param> Starting program: /usr/local/bin/inkscape [Thread debugging using libthread_db enabled] [New Thread -1223995264 (LWP 7496)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1223995264 (LWP 7496)] 0x0836725f in ParamString (this=0x85ba1e0, name=0x0, guitext=0x0, ext=0x0, xml=0x862480c) at repr.h:175 175 repr.h: No such file or directory. in repr.h (gdb) bt #0 0x0836725f in ParamString (this=0x85ba1e0, name=0x0, guitext=0x0, ext=0x0, xml=0x862480c) at repr.h:175 #1 0x08366b30 in Inkscape::Extension::Parameter::make (in_repr=0x862480c, in_ext=0x85ba070) at extension/parameter.cpp:238 #2 0x083627d4 in Extension (this=0x85ba070, in_repr=0x0, in_imp=0x85a722e) at extension/extension.cpp:92 #3 0x0836c66b in Effect (this=0x85ba070, in_repr=0x0, in_imp=0x0) at extension/effect.cpp:26 #4 0x0836a258 in build_from_reprdoc (doc=0x84a859c, in_imp=0x0) at extension/system.cpp:418 #5 0x0836a3f0 in Inkscape::Extension::build_from_file ( filename=0x859f980 "/home/aaron/.inkscape/extensions/ffss.inx") at extension/system.cpp:447 #6 0x08365d22 in build_module_from_dir (dirname=0x85a86e0 "/home/aaron/.inkscape/extensions") at extension/init.cpp:207 #7 0x08365b81 in Inkscape::Extension::init () at stl_vector.h:501 #8 0x08122acc in inkscape_application_init (argv0=0x0, use_gui=0) at inkscape.cpp:580 #9 0x08117b6a in sp_main_gui (argc=1, argv=0xbffff9c4) at main.cpp:517 #10 0x081ec4fb in Inkscape::NSApplication::Application::run (this=0x0) at application/application.cpp:132 #11 0x08117703 in main (argc=1, argv=0xbffff9c4) at main.cpp:414 Aaron Spike

1 0

Re: [Inkscape-devel] Memory Problems
by Richard Kowalczyk 06 May '05

06 May '05

I tried doing what you suggested. I went though 26 slides, since it seemed to be enough to get an indication of the behavior. (Just to clarify - I opened the next one (from within the current one), then closed the current one - if I had closed the current one first, the memory would be cleared) The memory used seems to be roughly equivalent between inkscape and inkview, although inkview does use less. Either way though, the memory keeps going up as I go through more slides. I attached three files to this email - the result of doing the command: ps aux | grep -e "inkview" >> memory.txt; free -m >> memory.txt for three cases: memory_inkview.txt: after I clicked the right arrow to advance each slide, I ran the command. memory_one_per_time.txt: I did what you suggested, and opened each file in inkscape, then closed the old one, running the command for each new file. memory_all_open.txt: I opened each file in inkscape, but didn't close the previous file, so by the end, I had 26 files open at once. I ran the command after each file was opened. Thanks for your help, Rich. On Thu, 2005-05-05 at 19:38 -0300, bulia byak wrote: > On 5/5/05, Richard Kowalczyk <richk@...805...> wrote: > > I will be glad to do anything else that anyone thinks will help explain > > the memory usage. > > Can you try loading these same files in turn (i.e. closing the > previous one when loading the next) into Inkscape instead of Inkview > and see if there is a noticeable difference? > -- Richard Kowalczyk <richk@...805...>

1 0

new debugging aid
by MenTaLguY 05 May '05

05 May '05

I've introduced a logging facility; the goodies are in the Inkscape::Debug namespace. Set the INKSCAPE_DEBUG_LOG environment variable to a filename, and Inkscape will write a structured XML outline of its activities there. You can take advantage of this when debugging your own code. For example, if you want to highlight the changes that happen during a function, you add this to the top: Debug::EventTracker<Debug::SimpleEvent> tracker("my-func"); (if the function isn't inside the ::Inkscape namespace, you'll need to fully-qualify the type names) After you recompile, any (logged) events that happen during a call to your function will appear grouped under a <my-func> tag in the log. For example: <my-func> <set-attribute node="element(0x8956a218)=svg:g(#g123)" name="foo" value="bar"/> </my-func> (How it works: the <my-func> tag is written from the EventTracker's constructor, and </my-func> is written from its destructor when it goes out of scope.) If you want to log fancier stuff (e.g. taking advantage of attributes) you'll currently need to write your own subclass of Debug::Event and use that instead of Debug::SimpleEvent. Note that EventTracker will not create a Debug::Event object unless the log is turned on, so you don't pay a performance penalty when you're not using it. See src/xml/simple-node.cpp for some examples (which are sadly probably more complicated than they need to be). -mental

1 0

[Fwd: SourceForge.net: Notice to project admin of upcoming project web and statistics changes]
by MenTaLguY 05 May '05

05 May '05

-----Forwarded Message----- From: SourceForge.net Team <noreply@...34...> To: mental@...3... Subject: SourceForge.net: Notice to project admin of upcoming project web and statistics changes Date: Thu, 05 May 2005 12:33:34 -0700 Greetings, This message provides an overview of upcoming changes to the SourceForge.net statistics system and the project web service. You are receiving this message because you are presently listed as an administrator of a project hosted on SourceForge.net, and we deem these changes to be important enough to notify all active project administrators. This is a one-time mailing. See the BOTTOM of this message if you are no longer active on SourceForge.net. A. Project Web Service A significant amount of recent work has gone in to improvements to the scalability and security of the project web service. On 2005-05-23, we will be remounting project group directories read-only on the project web servers (they will remain read-write from the shell server). This may impact existing project web applications. All projects are encouraged to review our new documentation and modify their application configuration as needed. http://sf.net/docs/E07/ This change is being made in accordance with the previous site mailings announcing project web changes, referencing the Master RFE at: http://sf.net/tracker/index.php? func=detail&aid=1109940&group_id=1&atid=350001 Additional details regarding the project web service, limitations, and the best ways to manage project content under this service, may be found in the recently-released Project Web, Shell and DB service guide, at: http://sf.net/docs/E07/ B. Statistics B0. Introduction and timeline The SourceForge.net team has been working for nearly a year to complete a total replacement of the existing project and site statistics infrastructure. It is our pleasure to announce that this work is reaching completion, and to provide some details to manage your expectations about the launch of the new statistics service. We expect to announce no later than 2005-05-16 the timeline for deployment of the new statistics system. This announcement will be made via the the Site Status page. https://sourceforge.net/docs/A04/ B1. Scalability, performance, outage reduction: The statistics system has been completely re-engineered as to cope with the growing size of the site user base, and of our service offering. With the launch of this new system, there are bound to be a few bugs (though we've performed extensive QA review of these changes and systems to try to reduce the problem set). We ask that all statistics related bugs found post-launch be submitted to us for review (even if they seem minor, or duplicative to those previously reported) at: https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 B2. Project ranking formula change: One of the changes which is expected to most impact projects is the alteration of the project ranking formula. This change may significantly alter the top project rankings, giving greater ranking to those projects who are not just frequently-downloaded, but also those projects who are active in using the Tracker and communication tools provided by the site. The OLD project ranking formula was: log (3 * # of forum posts for that week) + log (4 * # of tasks ftw) + log (3 * # bugs ftw) + log (10 * patches ftw) + log (5 * tracker items ftw) + log (# commits to CVS ftw) + log (5 * # file releases ftw) + log (.3 * # downloads ftw) -- This has been detailed in our older Site Documentation as seen at: https://sourceforge.net/docman/display_doc.php?docid=14040&group_id=1 With the new statistics system launch, we expect to provide new Site Documentation. The new documentation will include the final form of the NEW ranking formula. The new ranking formula splits project rankings in to three components: traffic, development, and communication. We expect the new ranking formulas to be: Traffic: ( (log(last 7 days download total) / log(highest project download total)) +(log(last 7 days logo hits) / log(highest project logo hits)) +(log(last 7 days site hits) / log(highest project site hits)) ) / 3 Development: ( (log(last 7 days cvs commit total) / log(highest project total)) +( (100-last file release age (days, max 100)) / 100 ) +( (100-last admin login age (days, max 100)) / 100 ) ) / 3 Communication: ( (log(last 7 days tracker artifact #) / log(highest project total)) +(log(last 7 days ML post count) / log(highest project total)) +(log(last 7 days forum post count) / log(highest project total)) ) / 3 Total: total = traffic + development + communication All of the 'highest' figures reference totals for the last 7 days. In the case of 'log(last 7 day site hits for this project) / log(last 7 day site hits for the project with the most site hits)', for example: If Project X is the busiest site this week with 10,000,000 hits and Project Y has had 200,000 hits then it's Y score = log(200,000) / log(10,000,000) We believe that this ranking method gives us the capability to better evaluate project activity, and to more directly reflect total product activity in how projects receive site exposure via the top site rankings. B3. Post-launch components and your feedback After the initial launch of the new statistics system, we will be working to complete the components to track CVS activity and mailing list activity. These components have not yet been completed, and are expected to launch at a later date (to be announced after the initial shake-out of the new system). Additional statistics system enhancements are also under consideration for implementation after the initial launch. Once the initial launch has occurred and you have had opportunity to examine the new facilities, we encourage you to contact us (via our Feature Request Tracker) regarding enhancements you would like to see. https://sourceforge.net/tracker/?func=add&group_id=1&atid=350001 B4. Documentation The release of new documentation (within the SourceForge.net Site Documentation collection) is expected to coincide with the new statistics system launch. Links will be provided to the new documentation from our Site Status page and Enhancements page. An itemized overview of the major changes carried by the new statistics system will be listed on the Enhancements page at time of launch. https://sourceforge.net/docs/A03/ https://sourceforge.net/docs/A04/ B5. Existing statistics data Existing statistics data (from the old statistics system) has been carried forward to the new statistics system. For the time period that the new system has actively been pulling real-time data from our servers, we plan to recompute project ranking data. All other project statistics should match those found in the old system. C. Conclusion Regarding Project Web: As documented here, project group directories will be remounted read-only on 2005-05-23. All writable files will need to be placed in the /tmp/persistent directory structure (create a subdirectory for your project). Additional details may be found in section A, above. Regarding Statistics: We are considering the completion of our new statistics system to be very high priority, and are taking only the time we need to ensure a highly consistent and functional system has been implemented. We expect to announce no later than 2005-05-16 the timeline for deployment of the new statistics system. Additional details may be found in section B, above. We hope that your team will find added benefit through our efforts, and encourage your continued support and feedback. Thank you, SourceForge.net staff http://sf.net/tracker/?func=add&group_id=1&atid=200001 --------------------------------------------------------- When the SF.net team sends out a site-wide email, we sometimes see replies that look like this: "Hey! I didn't ask to be on this list! You spammer. I hate you! I hate your dog! (insert other colorful phrases here)." The truth is, we've only sent this mailing to registered project administrators on SourceForge.net. If you do not believe you should have received this mailing, use the link above to submit a Support Request and we'll be glad to assist you. .

1 0

Memory Problems
by Richard Kowalczyk 05 May '05

05 May '05

I have a presentation of about 50 slides. When I go through the slides with inkview, it quickly eats up all of my memory (512 mb). I dont know a proper way to describe the memory usage, so I will list some info: Memory only goes up when I change slides. If it sit on the same slide, it is fine. If I just go back and forth between two slides, memory will increase each time I go back and forth, until it eventually levels off. Then I can flip back and forth between those two slides without any increase in memory. When I flip to more slides, memory goes up again. I can go through the whole presentation once, and memory will go to a certain value. Going backwards, or going to the start and showing slides again will continue to increase the memory. Eventually, after playing with the slides for about 15 minutes, inkview will crash, and print "Killed" to the console. I am basing my statements about memory on "ps aux" and "free -m". I will be glad to do anything else that anyone thinks will help explain the memory usage. I will be glad to send the presentation to anyone also. It is about 7 mb uncompressed. Thanks, Rich. -- Richard Kowalczyk <richk@...805...>

1 0

layer add hang
by MenTaLguY 05 May '05

05 May '05

The layer addition hang appears to be due to the failure of the "change handlers should only be called for events that happen after they are registered" invariant I mentioned. Basically what is happening is that on a layer switch, the layer selectors each register a new handler (after unregistering the old one), but those handlers immediately get called for the event that has already happened, repeating the process and creating an infinite treadmill. The obvious fix is to defer addition of new change handlers to the list until after all the existing handlers have been called. Of course that is not a sufficient guarantee for the recursive case, but hopefully there are no recursive changes involved here. -mental

1 0

Looking for autopackage maintainers (again)
by Mike Hearn 05 May '05

05 May '05

Hi, As the latest nightly build break shows, I'm not plugged into Inkscape development enough to keep the specfiles accurate. In particular the packages broke because I was still trying to copy the lib directory which no longer exists. Maintaining these specfiles is trivial. If somebody wanted to take them over I'd be happy to help and also happy to continue running the nightly build system. If anybody is interested please let me know. thanks -mike

1 0

Open Clip Art Library Release 0.13 Announcement
by Jon Phillips 04 May '05

04 May '05

May 4, 2005 UTC - Release 0.13 of the Open Clip Art Library (www.openclipart.org) is now available for download on-line as an individual package consisting of 3459 images submitted by over 200 artists from around the globe. This release also marks the start of the community-based "Planet Open Clip Art Library." Visit http://planet.openclipart.org to read about the various developers, artists, and contributors. If you would like to join the community, please submit your RSS feed URL and optional hackerogotchi link using the new feedback form on the project's main page. In preparation for the continually warming weather (in some parts of the world), the project is calling for submissions themed around "Summer" during the month of May. Use the following URLs to download the latest release of the Open Clip Art Library: http://www.openclipart.org/downloads/0.13.2/openclipart-0.13.2.tar.bz2 http://www.openclipart.org/downloads/0.13.2/openclipart-0.13.2.tar.gz http://www.openclipart.org/downloads/0.13.2/openclipart-0.13.2.zip The Open Clip Art Library (http://www.openclipart.org/) aims to create an archive of clip art that can be used freely for any use. All graphics submitted to the project are placed into the Public Domain according to the Creative Commons Public Domain Declaration.

1 0

Fresh reinstall errors?
by Kenney Phillis 04 May '05

04 May '05

i'm very new to this, and i figure the eror i got is a here: the error log i got... this isn't very helpful, but it's on windows, and it shouldn't give me these errors... i just ran the installer fresh... filename of "Inkscape-0.41-1.win32.exe". Extension "AI Input" failed to load because a dependency was not met. Dependency:: type: executable location: absolute string: /usr/bin/perl Extension "AI Output" failed to load because a dependency was not met. Dependency:: type: executable location: path string: pstoedit Extension "Dia Input" failed to load because a dependency was not met. Dependency:: type: executable location: path string: dia description: In order to import Dia files, Dia itself must be installed. You can get Dia at http://somesite.com Extension "EPSI Output" failed to load because a dependency was not met. Dependency:: type: executable location: path string: ps2epsi Extension "EPS Input" failed to load because a dependency was not met. Dependency:: type: executable location: path string: gs Extension "GIMP Gradients" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: gimpgrad Extension "Grid" failed to load because a dependency was not met. Dependency:: type: plugin location: path string: grid Extension "Postscript Input" failed to load because a dependency was not met. Dependency:: type: executable location: path string: pstoedit Extension "Sketch Input" failed to load because a dependency was not met. Dependency:: type: executable location: path string: skconvert Extension "SVGZ Output" failed to load because a dependency was not met. Dependency:: type: executable location: path string: gzip Extension "Text Input" failed to load because a dependency was not met. Dependency:: type: executable location: absolute string: /usr/bin/perl Extension "Windows Metafile Input" failed to load because a dependency was not met. Dependency:: type: executable location: path string: wmf2svg -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.2 - Release Date: 5/2/2005

2 1

Updated spanish translation
by Lucas Vieites 03 May '05

03 May '05

Hi, I'm attaching an updated spanish translation. It's not complete, but I'll finish it once it has all the new changes in it. I'm having trouble with a word: Unclump. The complete string is: "Unclump objects: try to equalize edge-to-edge distances" and several others. Can someone explain this to me or even better, send a screenshot before unclumping and after unclumping so I can see the effect. Thanks -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

3 3

Inkscape on DeviantArt
by Joshua A. Andler 02 May '05

02 May '05

This is a follow-up to a post made back in January regarding Inkscape's presence on DeviantArt (DA)... Over time, more and more artwork is being submitted to DA that was created using Inkscape. Since we had initially started the "Inkscape" group/account on DA, we quickly realized that there are two groups of people that have exclusive needs to be met. 1) The DA Inkscape artists needed a hub to share work, talk inkscape, have friendly competitions, etc. & 2) The developers and new users of Inkscape need a place to view/show a gallery of quality images made in Inkscape by the DA community. The problem with having one account is that it DA has policies such as restricting the use of favorites from members of a group, which given the mutually restrictive needs (due to their policies), we needed a separation of interests. So... onto the announcement. http://inkscapers.deviantart.com/ is now *the* place for all DA Artists that are Inkscapers to gather for all of the fun. We currently are in need of an Avatar, DevID, and website button... which is where the first contest comes into play... all the details can be found at http://inkscapers.deviantart.com/journal/4986039/. http://inkscape.deviantart.com/ is now for official use by the Inkscape project for a showcase of work from the community as well as for official announcements and such. Feel free to drop by there to see art done by fellow inkscapers in the favorites (http://inkscape.deviantart.com/favourites/). If you have previously watched the "inkscape" account, there's no need to stop watching as you'll get announcements about new releases through it. But, you will definitely want to watch "inkscapers" (http://inkscapers.deviantart.com/) to become a part of the DA Inkscape community and to join in on the fun. Happy Inkscaping and Draw Freely! -Josh/ScislaC-

1 0

plan for Postscript import
by MenTaLguY 02 May '05

02 May '05

I've been examining our options for importing postscript without requiring a bajillion evil dependencies, and I think I've arrived at a plan. 1) write a postscript to SVG converter in Postscript and use that for our Postscript importer 2) write a bare-bones standalone Postscript interpreter (doesn't need to implement any rendering, just provide a dummy postscipt device) and ship it with Inkscape Until #2 is finished, we can run the converter using Ghostscript, which is still two fewer dependencies than before. I've got prototypes for both #1 and #2 in CVS in the module 'ps3convert'. The prototype interpreter is written in Ruby and isn't really functional yet, but the converter (currently encapsulated in the ps-svg shell script) already works for the basic stuff. Running the converter: ./ps-svg blah.ps > blah.svg Caveats with the converter: * it's a proof-of-concept; hence the code is horribly ugly * it doesn't yet do text, gradients or clipping paths * the image in the output SVG appears above the top of the page, so you have to scroll up to see it Also one last caveat: I'm not promising any timetables on this stuff. So don't bug me to finish it. You'll probably find giving me patches to be the more productive alternative. -mental

2 2

Inkscape HelpWanted page
by Bryce Harrington 01 May '05

01 May '05

Hi guys, I've started a new wiki page 'HelpWanted', to list tasks where help is needed. This is similar to but different from the InkscapeJanitors page in that HelpWanted is focused on non-coding work needed. In particular, I've listed a bunch of Wiki update tasks that I think should be done. Please take a look and see if there's areas you can put in a few spare cycles. Also, don't be shy about adding other non-coding tasks needed that you know of! http://inkscape.org/cgi-bin/wiki.pl?HelpWanted Bryce

1 0

Project Stats May 1, 2005
by Bryce Harrington 01 May '05

01 May '05

Statistics Feb 15 Mar 15 Apr 15 May 1 ========== ====== ====== ====== ====== Lifetime Rank on SourceForge: * * * * * * * * Max Week's Rank on SourceForge: * * * * * * * * Total SF Page Views * * * * Total SF Downloads * * * * Total Freshmeat URL Hits 16,448 17,186 17,930 18,321 Total Freshmeat Subscriptions 169 173 177 177 Lines of Code in src/: 333,139 342,852 340,515 342,061 Code lines 234,651 241,177 238,522 239,571 Comment line 58,239 60,354 60,382 60,652 Blank 46,859 47,978 48,152 48,393 Lines of Docs in doc/: 26,848 26,848 26,848 26,848 Lines of content in website: 9,776 10,067 35,937 36,590 Size of the Inkscape wiki: 24,925 25,900 26,363 26,981 Bugs open/total: 155/972 182/1047 194/1126 209/1173 Features open/total: 370/579 397/ 619 429/ 671 437/ 699 Patches open/total: 5/167 7/ 173 5/ 186 8/ 204 CVS Commits (as per inkscape-cvs) 10,312 10,868 11,368 11,656 Inkscape-devel membership: 151 158 166 170 Inkscape-announce membership: 169 177 189 193 Inkscape-user membership: 193 220 234 235 Num Translations: 33 33 33 33 Ave Translation Ratio: 47.8 45.0 47.5 45.3 * - Statistics unavailable

1 0

Slashdotted!!!
by Jon A. Cruz 01 May '05

01 May '05

Just a quick note to let everyone know that Firefox's SVG support just got picked up on Slashdot http://developers.slashdot.org/article.pl?sid=05/05/01/1738202&tid=154&tid=…

1 0

crash: ungroup tutorial
by unknown＠example.com 01 May '05

01 May '05

While I've been working with the tutorials I've experienced a few chrashes so I've decided to start running with gdb to capture backtraces. Open tips and tricks tutorial. select everything Ctrl+A click the ungroup button a few times. segfault. Starting program: /usr/local/bin/inkscape [Thread debugging using libthread_db enabled] [New Thread -1223995264 (LWP 21644)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1223995264 (LWP 21644)] 0x0812d60d in sp_selection_ungroup () at selection-chemistry.cpp:569 569 if (strcmp(SP_OBJECT_REPR(group)->name(), "svg:g") && strcmp(SP_OBJECT_REPR(group)->name(), "svg:switch")) { (gdb) bt #0 0x0812d60d in sp_selection_ungroup () at selection-chemistry.cpp:569 #1 0x082ad6ff in sp_action_perform (action=0x863a270, data=0x0) at helper/action.cpp:135 #2 0xb75c02a6 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #3 0xb75ae736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #4 0xb75bfc5a in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #5 0xb75bee9c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #6 0xb75bf126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #7 0xb790e655 in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 #8 0xb7a73bdc in gtk_toggle_button_get_inconsistent () from /usr/lib/libgtk-x11-2.0.so.0 #9 0xb75c02a6 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #10 0xb75ae9c9 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #11 0xb75ae736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #12 0xb75bf651 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #13 0xb75bee9c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #14 0xb75bf126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #15 0xb790e5c5 in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0 #16 0xb790f383 in _gtk_button_paint () from /usr/lib/libgtk-x11-2.0.so.0 #17 0xb79d49fe in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 Aaron Spike

2 2