Hi!

I have an svg file full of unclosed paths. The file was created by autotrace using the centerline trace option, and a line drawing of a plant as input.



Inkscape opens this file OK. It still sees the paths as incomplete (note the gap in this leaf's outline.)



If I click on the outline path with the "edit paths by nodes" tool, manipulation handles appear, and the path still looks unclosed (the gap is still there.)



I noticed that when I click on any line in the whole drawing with the "edit paths by nodes" tool, manipulation handles appear on all the lines:



I guessed this meant that all the paths were grouped together. I used Paths menu > Break Apart and sure enough this removed all the grouping.

But that's not all it does. It also does this:



All of the lines I carefully left open in the drawing I scanned and autotraced (and which still appeared to be open when I imported the file into Inkscape) have been closed with new segments connecting the endpoints, and the resulting shape-thingies have been filled with black.

That isn't what I want at all. I want the paths to remain unclosed so I can stroke them! What's happening to me here, please, and how can I make it stop?

Thanks very much!

If I click on the outline path with the "edit paths by nodes" tool, manipulation handles appear

Those are not handles, they are the nodes.

I noticed that when I click on any line in the whole drawing with the "edit paths by nodes" tool, manipulation handles appear on all the lines:
I guessed this meant that all the paths were grouped together.

No, it doesn't mean they're grouped, it means they are all subpaths of one single path. Break apart IS the proper function to make them all separate paths, though.

I don't know why they are all getting filled. And I can't tell from your screen shot if they are in fact being automatically closed, or if they are just getting filled. But try this: while they are all selected, go to the bottom left area of the window, where it shows Fill and Stroke. If you right-click on Fill, then choose Remove Fill, you will have only the stroked paths leftover. Then you can see if the paths have been closed. Break apart should not close the paths, and if it does, that means something else is going on. But try this first step, and we can go from there.

I want the paths to remain unclosed so I can stroke them!

They are already stroked. If they were not stroked, you would not be able to see them. So your original autotraced image shows strokes already. I'm guessing you want to use different colors, so Break Apart is still what you would need to do. But if you DO want them all the same color, then there's no need to even break them apart.

I should also say that I don't know what autotrace is -- if it's a feature of Inkscape with which I'm not familiar, or if it's done with another program. So the caveat is that I don't know what autotrace does to an image. But if I can't sort it out, plenty of others here can.

Also I notice there is an awful huge amount of nodes. Depending on what all you plan to do, it might be helpful to use Path menu > Simplify. It will reduce the number of nodes. But only do it once, because more than once will distort the paths.

Anyway, let us know what happens with my 1st suggestion to remove the fill

When I try to break apart a complex path made of lines they don't end up filled, I get exactly what you want.

Can you attach a SVG file or even one part of the file so we can see what's happening?

This kind of behavior is normal when breaking apart paths that have fill. For example create an ellipse, give it thick stroke and convert the stroke to path (Ctrl + Alt + C), then break it apart Shift + Ctrl + K, you will get 2 filled ellipses.

Are you sure you haven't done any steps in between? I guess it all depends on the path that came out of autotrace.

BTW what does the fill and stroke boxes say (bottom left of the window)? Can you simply remove fill and add stroke when all objects are selected to fix it?

The paths may just appear to be closed because they have a fill. Inkscape fills unclosed objects with a straight edge between first and last nodes; however, no actual segment exists there. With the node tool active you can hover over any path to have the entire outline of the path flash briefly; use this to see if a path is actually closed.
OR, select all, use your palette or fill and stroke dialog to set fill to none and stroke to any colour and line weight (you can do all this from the status bar bottom left, too) and see if it fixes things. Doing boolean operations (union, intersection, etc) on open paths causes them to close in strange ways but break apart should not.

I have a solution to my immediate problem (details down below.) But the fix I found required hand-editing the svg file with all the unwanted fills. Once y'all see the corrections maybe you'll know how to get the same XML outcome through the Inkscape GUI. To achieve that, find the way I could not.

First off, though, let me respond to the folks who were kind enough to offer suggestions.

brynn:

I should also say that I don't know what autotrace is -- if it's a feature of Inkscape with which I'm not familiar, or if it's done with another program.

Autotrace.exe is a separate application. It's a command line vectorizer available here: http://sourceforge.net/projects/autotrace/. It's getting old and doesn't appear to be in active development any more, but I use it because a) it works just fine in its present state, and b) it's the only vectorizing app I can find that will do a centerline trace and doesn't cost hundreds of dollars.

For the record, here's absolutely everything I did to svg file written by autotrace, together with the Inkscape Fill and Stroke info I saw after each step:

1. open file in Inkscape
2. select Edit paths by nodes tool, click on any path/subpath in the image
3. press shift-ctrl-k (Break Apart)

After opening file:




After click with Edit-paths-by-nodes tool, before Break Apart:




After Break Apart:




The result of these three steps was as I showed in my first message, all the broken-apart paths filled with black.


while they are all selected, go to the bottom left area of the window, where it shows Fill and Stroke. If you right-click on Fill, then choose Remove Fill, you will have only the stroked paths leftover. Then you can see if the paths have been closed.

Actually if I do this globally (all selected) there's nothing left over -- the whole drawing disappears and the edit-paths-by-node tool is no longer able to select anything.

Here's what happens if I remove the fill from just path3343:

1. Initial state, path selected:




2. Remove the fill from just path3343 (note the absence of anything connecting the little rectangles; I did not touch any stroke settings, just removed the fill.)




3. Now, the moment I click outside the bounding box, all those little rectangles (and the box) vanish, never to return. Or at least, no amount of clicky-clicky in this area with the edit-paths-by-node tool brings back either the box or the node rectangles.



All the other paths that are still filled, clicky with the node tool still displays their nodes and box fine.


Also I notice there is an awful huge amount of nodes. Depending on what all you plan to do, it might be helpful to use Path menu > Simplify. It will reduce the number of nodes.

Oh, absolutely, that's one of the main things I want to do to. The vector graphic has so many nodes because the raster graphic I fed to autotrace was large (drawn in technical pen as big as I could fit on 8.5" x 11" paper and scanned at 300dpi; scanner output file is 2306 x 2484 px) and autotrace itself was set to preserve every last kink and wiggle of that I drew. Hence, as you said, lots of nodes. Certainly they're not all going to be needed but some of the paths are smoother and some are wigglier, and I want to see the effect that simplify has on each one before deciding yes or no. Therefore, Break Apart before Simplify. But that's where I ran into the wall yesterday, at the Break Apart stage.



prkos:

When I try to break apart a complex path made of lines they don't end up filled, I get exactly what you want.

Can you attach a SVG file or even one part of the file so we can see what's happening?

There are what look like relevant pieces of the svg files below. And thanks for the nudge to look at the files directly, in a text editor. That's where I found my (non-Inkscape) work-around.


First off, here's the file as written by autotrace.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 2306.0 2484.0">
<rect fill="#FFFFFF" width="2306.0" height="2484.0"/>
<path fill="none" stroke="#000000" d="M938 301C937.675 299.294 937.141 297.749 937.06 295.991C936.907 292.652 937.215...

...(some of the middle passages can be skipped ...

2444L599.199 2453L596.125 2456.98L593.736 2459.72L586 2465L577 2469.45L572 2470.6L559 2473.5L550 2477.71L543 2480.61L538.602 2483.19L537 2484"/>
</svg>

As brynn said, just one huge long path.


The first thing I did was write the file back out as an Inkscape .svg with no other changes, and also another Inkscape .svg after breaking the subpaths apart.

In the otherwise unchanged Inkscape-svg version, that also has only one huge path, the start of the path data looks similar to the autotrace version.

autotrace svg:

<path fill="none" stroke="#000000" d="M938 301C937.675 299.294 937.141 297.749 937.06 295.991C936.907 292.652 937.215 289.294 936.523 286C936.089...

Inkscape svg:

<path
fill="none"
stroke="#000000"
d="M938 301C937.675 299.294 937.141 297.749 937.06 295.991C936.907 292.652 937.215 289.294 936.523 286C936.089...


In contrast, after breaking up the paths in Inkscape and writing that file out, there are many path sections (expected) and they look different (not expected):

<path
style="stroke-width:3.09906881"
d="M 938,301 C 937.675,299.294 937.141,297.749 937.06,295.991 C 936.907,292.652 937.215,289.294 936.523,286 C 936.089,...

The references to fill= and stroke= are conspicuously missing. They aren't anywhere else in the file either, and some default is being applied that isn't what I wanted.

You'll see my hand fix right away, of course. It consisted of finding the start of each path section in the file that has the unwanted black fills, taking what looked like this

<path
style="stroke-width:3.09906881"

and supplying the missing lines to make it look like this

<path
fill="none"
stroke="#000000"
style="stroke-width:3.09906881"


260 paths for this file needed the fix. And this was just the leaf outlines. The next two scans waiting to be vectorized are much larger since they have all the internal shading lines (one has the thisaway-hatching and the other has the thataway-hatching). If this kind of hand edit turns out to be something I have to do often I'll certainly write a sed filter or something to do it by robot. Unless there's a valid global setting I could use in the XML. Or I can find the right way to do it in Inkscape.



druban:

The paths may just appear to be closed because they have a fill. Inkscape fills unclosed objects with a straight edge between first and last nodes; however, no actual segment exists there.

Thanks for the correction. I did just assume they were closed because I've never used any other graphics package that could fill an unclosed path. Know better now, we does!


Thanks very much, brynn and prkos and druban, for your help and hints!

Jim

Hi Jim! it sounds as if you have found a solution to your problem, but in case you are still perusing this thread here's a couple more tips for you.

Now, the moment I click outside the bounding box, all those little rectangles (and the box) vanish, never to return. Or at least, no amount of clicky-clicky in this area with the edit-paths-by-node tool brings back either the box or the node rectangles.

All the other paths that are still filled, clicky with the node tool still displays their nodes and box fine.

If you remove both stroke and fill from an object and deselect it it becomes rather impossible to select in normal view, because to make a selection by clicking you have to click on either the fill or the stroke, and you may not want to tab and shift tab a hundred times to find it. (If you know where it is you can try to draw a rectangle selection enclosing it - this will work, but even one stray node outside your rectangle and no joy)

Instead of all this palaver go to the outline view. (View menu>display mode>outline). All paths show here and are easy to select even in a strokeless and fillless state.
I hope we can figure out a way for you to get your desired results before the other scans you mentioned because you definitely do not need to edit xml by hand for this sort of thing, Inkscape can do it much faster and more accurately...

I should also mention that I use Autotrace too and for the same reason - centerline trace! You might find the command ctrl-l (simplify i.e. reduce number of nodes) useful as the very first thing after opening an autotrace svg in Inkscape. Post back if you have any questions about this...

beriberi wrote:

prkos wrote:When I try to break apart a complex path made of lines they don't end up filled, I get exactly what you want.

Can you attach a SVG file or even one part of the file so we can see what's happening?

There are what look like relevant pieces of the svg files below.

Can you attach the SVG file itself (instead of quoting some pieces)?

Wow!
Well it sounds to me like autotrace is doing some strange things.....at least that's my best assessment, at this point. Maybe autotrace is not so stable with newer versions of Inkscape?

Once we start talking about XML, we are hopelessly over my head, so I may not be any further help. However as druban says, there should be no need to mess with that code. I don't know if prkos suggested attaching an SVG file, for some XML-related reason. But I'm guessing the reason is so that we can "take apart" your image, look at what's there, try to figure out what's happening, and try to figure out how to fix it. We do this quite often when trying to help people solve strange problems, whom might not be very familiar with Inkscape, or otherwise are just baffled. (I think you're in the baffled category )

Oh, I see that ~suv has joined the discussion while I'm typing -- awesome! Because if you've stumbled upon a bug, ~suv is our resident "bug expert"

And one last note. Suddenly it occurs to me that when we asked for the SVG file, you were thinking XML text file. But no, we want your image in SVG form, so that we can open in Inkscape, and examine it. You can upload and attach to a message right here in this forum, then we can download and open it!

brynn wrote:Suddenly it occurs to me that when we asked for the SVG file, you were thinking XML text file. But no, we want your image in SVG form, so that we can open in Inkscape, and examine it.

That's the same (SVG is an XML-based file format) - point is that providing only screenshots or partial excerpts makes it harder for others to investigate the issue at hand in Inkscape, whereas the (un-edited) SVG source file as output by autotrace could be helpful if attached to a comment here in the forum.

Autotrace has an advantage over Inkscape Trace Bitmap because it has the centerline option, which was used in this example, but I guess the code might not agree with Inkscape 100%, but we can't know until we test.

You don't have to manually add the style attribute with fill and stroke info, you can do it through the graphics interface and save time - after removing the fill that makes everything disappear, add a black stroke. That's what you can consider Inkscape to be actually, a text editor with an advanced graphical interface

This (attached) is the vectorized graphic in svg format, as written by autotrace.

I also should mention that this filled-with-black effect doesn't always happen. I've gone through the following process enough times that it's now an established workflow:

= draw pic (thin, clean ink lines) on paper
= scan paper to raster graphic. Clean up scanner output if needed
= vectorize raster graphic with autotrace, centerline trace, svg output
= read svg into Inkscape, break paths apart, simplify or otherwise tweak path nodes if needed
= write file out as .emf
= open .emf in Creature House Expression (now Microsoft Expression but the old non-MS version is still floating around. In fact at one time MS itself was giving it away free and they may still be.) This step is needed because Expression can copy to the Windows clipboard. Emf because that's the one format Inkscape and Expression have in common. But you only need one, and emf preserves and transfers the paths.
= In Expression, select/copy all the paths
= Paste paths into Photoshop, resize to fit current working image, stroke paths with one of the "pen" and/or "pencil" tools I've collected or made over time.

All this usually this goes without a hitch. Sometimes I get the filled-with-black glitch in the Inkscape phase, and this time I decided to pursue it and understand what's happening. So anyhow I do have examples of svg files from autotrace that work fine in Inkscape, and this time I was careful to preserve an example that shows the funny effect. Maybe by comparing the two kinds line by line I'll see something that offers a clue. If I do I'll certainly post about it, especially now that I know I'm not the last person on Earth still using autotrace

Awesome, thanks for the SVG file

Here's what I can report -- interesting stuff, that mostly I don't understand . But bottom line, the problem can be solved!

I selected the huge path, and did Path menu > Break Apart. And I had the same result you had. Since the Fill and Stroke info said that both were Unset, I thought, ok I'll try setting them. (Unset does not mean the same thing as having no fill or stroke. But I don't fully understand it, and will leave the explanation to those more knowledgeable.) So I right-clicked over Fill, then Remove Fill. Then I right-clicked over the black color in the Inkscape palette, then Set Stroke. This did appear to solve the problem. So that's the best news!!

But since I'm not so familiar with the details of the image, I wasn't sure if your image was fully intact. So I decided to start all over, and save a duplicate first, so I could compare the results. To do this, I chose to make a new layer, move the duplicate onto that layer, and hide it. Then I went back to the original, still in (root) layer, ready to perform the same steps. But to my surprise, when I did the Break Apart, it worked perfectly!!

I don't know why the duplicating of the path would cause the original to behave properly??? I've done this process from start to finish 3 times, to be sure I'm not missing something. And it happens the same way each time!

So that's what I have for you. Results without understanding them, lol. But I'm sure the others who are following this topic can explain at least some of it

Fill being defined as UNSET, has to do with CLONING.

If you have a LOOK at the >Edit >Clone >Create Tiled Clones... Menu there is a COLOR tab. The SOURCE (Parent) of the Clone operation has to be defined as UNSET in order for the CLONING+COLOR manipulation (inherite) to occur.

The Fill & Stroke Menu represents the UNSET definition as the Question Mark Icon, just float your mouse over the Question Mark and you will see the tool-tip message reflecting this.

You can also UNSET the COLOR of an Object by using the FILL & STROKE STYLE INDICATOR, at the bottom left corner of the Inkscape UI. To Unset RIGHT CLICK the Fill or Stroke style indicator rectangles and choose UNSET.

When UNSET is defined for an object's fill AND stroke:
The "ON CANVAS" FILL Color of the Object will default to BLACK. But when it comes to stroke the ON CANVAS color will not revert to black, it will simply remove the stroke coloring. This makes the stroke appear to NOT be part of the Tiled Clone Que when it is still actually going to inheret the Clone+Color operation. The Clone+Color feature does not have a DUAL independant Fill & Stroke setting, instead it is COLLAPSED and BOTH the Fill & Stroke will be colored the same way.

I get the same result as you when breaking the path apart, but if I simplify first the fill doesn't appear and the stroke is there as it should be. I guess the problem is somewhere in the nodes autotrace made, report a bug attaching this file so someone with more knowledge can take a look at it.

prkos wrote:I get the same result as you when breaking the path apart, but if I simplify first the fill doesn't appear and the stroke is there as it should be.

The reason it that beriberi's provided SVG file from autotrace uses presentation (XML) attributes to assign fill and stroke color:
whereas Inkscape writes the color information as CSS inline styles of the 'style' attribute:

Inkscape can read presentation attributes correctly but rewrites the style information as soon as the path is modified in Inkscape (as described in previous comments - the path had been duplicated or simplified, the same happens e.g. when moving it). The path command 'Break apart' seems to only access the 'style' attribute when assigning fill and stroke to the separated paths. Since that attribute doesn't exist in the SVG source from Autotrace, both fill and stroke color are 'Unset' for the separated paths.

'Unset' for fill and stroke attributes means 'not defined' and the resulting rendering depends on the attribute and the inheritance rules (groups, clones). It differs from 'None' which explicitly declares an object to be rendered without fill color or without stroke. Per SVG specification, unset fills are rendered black, unset strokes are not rendered at all.

What puzzles me it that all test files I created locally with autotrace 0.31.1 sofar [1] also use the 'style' attribute for stroke and fill colors, and differ in that regard from beriberi's provided file. With those files I centerline-traced with autotrace myself, I did not reproduce the same problem when breaking apart the traced path.

Several workarounds have been described in previous comments, I might add that - besides it not being a big issue (just click the 'X' in the color palette to remove the fill and shift-click a color in the color palette to assign the new stroke color, right after breaking apart the path with all parts still selected) - a simple move of the path before breaking it apart (with the select tool, select the path, move it a nudge up with the 'up' cursor key and one back down with the 'down' cursor key) changes the way the style information is stored and subsequent commands behave as expected.

I'll search the bug tracker for reports about using presentation attributes to define fill and stroke colors (as opposed to inline CSS styles), and already reported issues with SVG files / objects created by third-party applications.

[1] later added comment: my own experience with autotrace is minimal, this topic finally made me compiling and installing it locally (on my to-do list for a long time - thx for the bump ;-) ), and I also just discovered its availability online via the "RO IT Systems - Free Autotrace Web Interface"…

brynn:

Here's what I can report -- interesting stuff, that mostly I don't understand . But bottom line, the problem can be solved!

Hey, thanks for experimenting with the file and being first with a within-Inkscape fix. Editing the svg file directly was kind of an ugly work-around! bb rises, tips hat.


vwanweb:

When UNSET is defined for an object's fill AND stroke: The "ON CANVAS" FILL Color of the Object will default to BLACK. But when it comes to stroke the ON CANVAS color will not revert to black, it will simply remove the stroke coloring.

OK, another point explained. So with both fill and stroke unset, all you see in normal view is the default black fill. And if you remove that, you don't see nuffin'. I expect the devs had a reason for making the fill and stroke behaviors inconsistant like that when both are unset, but it sure can lead to an "oh wow, where did my drawing go?" moment.


~suv:

What puzzles me it that all test files I created locally with autotrace 0.31.1 sofar [1] also use the 'style' attribute for stroke and fill colors, and differ in that regard from beriberi's provided file.

I located the source of that, maybe. autotrace is strictly a command line app, but someone else has written a simple GUI interface for it called Delineate. This GUI lets you set many (but not all) of autotrace's parameters and switches with sliders and buttons. Then it invokes autotrace with those parms. But it's apparently doing other things behind the scenes also because the the traced svg files I get when using delineate always seems to have

<path fill="none" stroke="#000000"

while all the svg files I've created using autotrace straight from the command line or from a .cmd or sh file use

<path style="stroke:#000000; fill:none;"

(Not criticizing Delineate, understand, I'm still grateful it exists because its startup slider defaults gave an example of some initial settings that work. The defaults shown on the online interface site were very helpful to me for the same reason. Otherwise pretty much all the documentation you get with autotrace is the linux version man page (and the -help parameter for the win version, which just repeats the same information.) It can be a bit daunting to learn to use something like autotrace with only its man page to go on


Thanks again to everyone who contributed to this thread! I have both a fix for my immediate problem and a lot more knowledge of Inkscape now.