- Inkscape Devel - Inkscape Mailman

"Canny edge detection" - meaning "clever" or "cautious"?
by Colin Marquardt 27 Sep '04

27 Sep '04

Hi, while updating the de.po, I wondered whether "Canny edge detection" means "Cautious edge detection" or "Clever edge detection"? Maybe a different word should be used unless it's totally unambiguous for native English speakers. Cheers, Colin

7 11

Re: [Inkscape-user] units
by MenTaLguY 25 Sep '04

25 Sep '04

On Sat, 2004-09-25 at 13:02, bulia byak wrote: > As far as I remember from our testing of various renderers, viewbox > does not have any effect on the pixel/absolute ratio. Mental, can you > please summarize what you found out by posting to the SVG list about > this? Correct; viewBox only applies a translation+scaling factor (which affects user and other units alike). [ user units (before any transformation) = pixels ] If you try to use "real world" units within a viewBoxed document, they will be distorted by the viewBox depending on the particular UA's notion of the current resolution. Conceivably, you could just avoid using a viewBox and user units altogether, except for one thing -- SVG paths can only be specified in user units. Without a viewBox, of course, the real world -> user unit relationship will still vary depending on the resolution. So that won't work either. In summary: everything but user and relative units (relative units being percent, em, and ex) are useless in SVG, except for the purpose of setting document size. In practice, the only way to do "real world units" in SVG is to set the document dimensions in some absolute real world unit, establish a viewBox, and then use nothing but user and relative units in the document proper. -mental

1 0

Re: Minor upgrade to autotracing
by Peter Selinger 25 Sep '04

25 Sep '04

Hi guys, I heard from Bob today that he had integrated my "potrace" into inkscape. That is really great! I checked out the inkscape-devel archives and I noticed that Bob was tinkering with brightness settings to prepare an image for black-and-white tracing. Did you look at the "mkbitmap" program, which comes with the potrace distribution? It is a pretty good pre-processor for potrace for certain types of images, like cartoons or photographs of handwriting. For some examples, see http://potrace.sourceforge.net/mkbitmap.html It does not do too great for Bob's venus example, I have to say. The problem (which is shared by the "canny" edge detector) seems to be that both programs look only at edges in the contrast data, and ignores edges in the hue and saturation. Therefore, there are lots of missing edges in the left part of the image. -- Peter

6 13

New Win32 build, and a gtkmm question
by Bob Jamison 24 Sep '04

24 Sep '04

I built another Win32 copy this morning, almost same as usual, but this one has several differences. If someone could test it to see if it works, I would appreciate it. This was a clean build using newer versions of MinGW's mingw-runtime, win32api, binutils, and the release candidate of their gcc-3.4.2 diffs. I think they are preparing for another complete release, which would be wonderful for our Windows-trapped developers. If this newer stuff works OK, I will upload tomorrow. In addition, this is using newer bugfix versions of Gtk and Glib from Tor Lillqvist's site. So please let me know how it works! http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0409231145… ====== (On another topic, but with that build)... Also, note the changed Trace dialog. Can someone please tell me how to pack that Preview button so it doesn't stretch? :-) I tried a lot of combinations with no success. In addition, I added an Abort button, and a callback. In a day or two I will have the tracing method launched in a thread, so that it will not lock up the gui. Now I need to get with Peter to see how to abort tracing. Maybe a kill flag? Later! Bob

4 7

gthread-2.0 in Linux link items
by Bob Jamison 24 Sep '04

24 Sep '04

Hi, all, I seem to remember us having gthread-2.0 on our link line previously. I am finally getting the trace function to run on a background thread. Does configure.in need to be adjusted? Or just a Makefile.am? The --cflags part is redundant, and is not needed: %>pkg-config --cflags gthread-2.0 -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include But this needs to be added. Didn't we have this once? %>pkg-config --libs gthread-2.0 -pthread -L/usr/local/lib -lgthread-2.0 -lglib-2.0 I need it for the following lines in trace.cpp: #if HAVE_THREADS //Ensure that thread support is running if (!Glib::thread_supported()) Glib::thread_init(); //Create our thread and run it Glib::Thread::create( sigc::mem_fun(*this, &Trace::convertImageToPathThread), false); #else convertImageToPathThread(); #endif If anyone could adjust this, I would appreciate it. Bob

2 1

RE: [Inkscape-devel] New Win32 build, and a gtkmm question
by Taraben, Adib 24 Sep '04

24 Sep '04

Hi, I can confirm that it works so far on Win2000. Adib. -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net on behalf of Bob Jamison Sent: Thu 9/23/2004 19:04 To: inkscape-devel(a)lists.sourceforge.net Subject: [Inkscape-devel] New Win32 build, and a gtkmm question I built another Win32 copy this morning, almost same as usual, but this one has several differences. If someone could test it to see if it works, I would appreciate it. This was a clean build using newer versions of MinGW's mingw-runtime, win32api, binutils, and the release candidate of their gcc-3.4.2 diffs. I think they are preparing for another complete release, which would be wonderful for our Windows-trapped developers. If this newer stuff works OK, I will upload tomorrow. In addition, this is using newer bugfix versions of Gtk and Glib from Tor Lillqvist's site. So please let me know how it works! http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0409231145… ====== (On another topic, but with that build)... Also, note the changed Trace dialog. Can someone please tell me how to pack that Preview button so it doesn't stretch? :-) I tried a lot of combinations with no success. In addition, I added an Abort button, and a callback. In a day or two I will have the tracing method launched in a thread, so that it will not lock up the gui. Now I need to get with Peter to see how to abort tracing. Maybe a kill flag? Later! Bob

1 0

arena leakage
by MenTaLguY 23 Sep '04

23 Sep '04

Ok, more on the arena leakage we were discussing last night; there are two main causes that I can see right now: 1. NRArenaItems still increment their children's refcount, even though they are now managed by the garbage collector. The resulting belt-and-suspenders situation keeps both the child and its parent from ever being collected. The fix: remove internal refcounting from arenaitems (non-gced objects still need to refcount them, of course) 2. NRObjects (like NRArenaItems) often allocate memory from the libc heap, which the collector cannot free automatically. There is an existing finalization callback for NRObjects that was used for freeing such memory, but it was no longer getting called. The fix: hook that now-unused finalization callback to the garbage collector's finalization callback. Once I get those straightened out we'll see if there's anything else left. -mental

1 0

gcc 3.3.3 supported
by Alexandre Prokoudine 23 Sep '04

23 Sep '04

Hi, I do not manage to compile Inkscape from CVS. Build log is attached. I have here: libgtkmm2-2.4.4 glib2-2.4.6 gcc-3.3.3 kernel 2.4.22 (if this helps :)) Your help would be highly appreciated. I'm pretty sure I might do somethings wrong. Alexandre

2 2

memory hogging
by bulia byak 22 Sep '04

22 Sep '04

I'm not very good at debugging memory leaks, but I thought I'd share what I found so far hoping that others may have more luck. I have a rather big and complex document (500 Kb SVG) containing many icons which I export individually. I noticed that after each export the inkscape task grabs about 5% of my total memory (512 Mb) and never releases it. This happens even if I export small bitmaps (64x64) and even if I export the same icon again and again. So, after exporting about 20 icons, all my memory and swap are eaten and the system grinds to a halt. Only killing Inkscape can revive it now. I traced the export command and found that the memory grab happens in nr_arena_group_update called on the document's root (which, obviously, calls updates of all other arena items in the document) which is called from sp_export_get_rows. I could not track it further down but I suspect it's some unfreed memory in livarot. The amount of memory eaten in one export operation does not seem to depend on the resolution of the exported area but depends on its size (though not proportionally; it grabs about 7% if I export area 16 times bigger). During normal work it does not eat memory that fast. It's not a recent thing; a build from early August has the same problem. However Inkscape 0.37 is OK, and by the way it takes 3 times less memory upon loading that document (5.5% vs 17%). So if anyone can play with things like valgrind or electric fence, this is a very annoying bug which needs to be addressed.

2 16

RE: [Inkscape-devel] Win32 build
by Joshua A. Andler 22 Sep '04

22 Sep '04

Bug report submitted (albeit poorly worded)... attaching info & xml. --- The following pertains specifically to the document uploaded. If you have objects that are grouped together and have gradient fills, and resize or move them, the gradients get distorted. With the example file all you have to do is open it and move or resize the objects and you will see it happen when you release the mouse button. It happens with both radial & linear gradients. Interesting observations: If you move the objects while they are grouped, the gradient gets distorted. However, if you ungroup the objects and still have them all selected, and move them, it does not distort them. If you use a linear gradient on the group and modify the control vector in the gradient editor, it has a "mirror" effect with the way it fills the objects (in the attached example document at least). If you use the linear gradient and the objects are ungrouped but all selected, the control vector can only affect the size of the gradient not the direction (straight up and down only, regardless of how the control vector appears). --- <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">  <svg width="210mm" height="297mm" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://web.resource.org/cc/" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xlink="http://www.w3.org/1999/xlink" id="svg1" sodipodi:version="0.32" inkscape:version="0.39cvs" sodipodi:docname="gradient issues.svg" sodipodi:docbase="C:\Documents and Settings\ja.SWARTZBIVENS\Desktop"> <defs id="defs3"> <linearGradient id="linearGradient2256"> <stop style="stop-color:#000;stop-opacity:1;" offset="0" id="stop2257" /> <stop style="stop-color:#fff;stop-opacity:1;" offset="1" id="stop2258" /> </linearGradient> <radialGradient inkscape:collect="always" xlink:href="#linearGradient2256" id="radialGradient2259" cx="0.49999955" cy="0.49999973" r="0.14165640" fx="0.49999955" fy="0.49999973" spreadMethod="repeat" gradientUnits="objectBoundingBox" /> </defs> <sodipodi:namedview id="base" pagecolor="#ffffff" bordercolor="#666666" borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="1.2279853" inkscape:cx="305.25952" inkscape:cy="417.84945" inkscape:window-width="1280" inkscape:window-height="934" inkscape:window-x="-4" inkscape:window-y="-4" inkscape:current-layer="svg1" /> <metadata id="metadata4"> <rdf:RDF id="RDF5"> <cc:Work rdf:about="" id="Work6"> <dc:format id="format7">image/svg+xml</dc:format> <dc:type id="type9" rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> </cc:Work> </rdf:RDF> </metadata> <g id="g1629" style="fill-opacity:1.0;fill:url(#radialGradient2259);fill-rule:nonzero; "> <path sodipodi:type="arc" style="fill:url(#radialGradient2259);fill-opacity:1.0;fill-rule:nonzero; stroke:#000000;stroke-width:1.0000000pt;stroke-linecap:butt;stroke-linej oin:miter;stroke-opacity:1.0000000;" id="path1000" sodipodi:cx="384.36435" sodipodi:cy="345.53485" sodipodi:rx="99.330116" sodipodi:ry="99.330116" d="M 483.69447 345.53485 A 99.330116 99.330116 0 1 0 285.03423,345.53485 A 99.330116 99.330116 0 1 0 483.69447 345.53485 z" transform="translate(-1.439554,2.842171e-14)" /> <path sodipodi:type="star" style="fill:url(#radialGradient2259);fill-opacity:1.0;fill-rule:nonzero; stroke:#000000;stroke-width:1.0000000pt;stroke-linecap:butt;stroke-linej oin:miter;stroke-opacity:1.0000000;" id="path1002" sodipodi:sides="5" sodipodi:cx="310.94644" sodipodi:cy="686.71222" sodipodi:r1="138.67744" sodipodi:r2="69.338722" sodipodi:arg1="1.5707963" sodipodi:arg2="2.1991149" inkscape:flatsided="false" inkscape:rounded="0.00000000" inkscape:randomized="0.00000000" d="M 310.94645,825.38966 L 270.19016,742.80842 L 179.05636,729.56591 L 245.00140,665.28537 L 229.43388,574.51981 L 310.94644,617.37350 L 392.45900,574.51981 L 376.89149,665.28538 L 442.83653,729.56590 L 351.70272,742.80843 L 310.94645,825.38966 z " transform="matrix(1.000000,0.000000,0.000000,-1.000000,71.97831,1414.305 )" /> <path style="fill:url(#radialGradient2259);fill-opacity:1.0;fill-rule:nonzero; stroke:#000000;stroke-width:1.0000000pt;stroke-linecap:butt;stroke-linej oin:miter;stroke-opacity:1.0000000;" d="M 247.60551,529.94241 L 518.24408,529.94241" id="path1003" /> </g> </svg> -----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Tuesday, September 21, 2004 1:20 PM To: Joshua A. Andler Subject: Re: [Inkscape-devel] Win32 build > As I said in the original post, I couldn't just post it to the list. > Most cases aren't like that, but it's the preference of my bosses. You can submit a bug report and attach it there. Or you can upload it to any server you have access to and give us the URL. Or if it's small, you can simply paste the SVG code into the message.

2 1