Sometimes it doesn't change the shape by much at all but other times, depending on the shape, it changes it by quite a bit. Why is this?

I`ve noticed similar thing today (not sure if I`ve ever seen it before).
Small ellipse shape of 10 x 15px with 3px stroke. After removing the fill and when I changed stroke to path, some deformations occurred.

Yeah, that is exactly it. I'm wondering if it is a settings problem or a problem with the program itself.
I need for the shape to remain the same because I'm using Path tools like Difference a lot and the inconsistent shapes are causing me problems.

Hhhm....I cannot reproduce that. The original ellipse, was it just converted to a path from an ellipse shape? Just 4 nodes in the original? What versions for you 2?

I have seen paths distorted, for example where the original path had a sharp corner. After Stroke to Path is applied, the sharp corner has become a sharp curve. And I've also seen paths distorted similar to that. But with that exact ellipse in Maestral's example, I get a perfectly acceptable result.

In Maestral's example, it looks like the nodes are all cusp/corner nodes, with handles askew. When I perform the Stroke to path, I get all smooth nodes. And actually, I should say that it's really the first time I've used Stroke to path, and gotten all smooth nodes. Usually it is some illogical combination of smooth and cusp nodes.

I tried a 2nd test. After converting the ellipse to path, I then changed the smooth nodes to cusp, and then performed the Stroke to path. But I got the same, perfectly acceptable result, with all smooth nodes. Even if I first adjusted the handles, the result was still good.

I'm on Win7, 64-bit, Inkscape 0.48.1 stable.

Wait, something about this is starting to sound familiar.....Let me search through my files, I might know more than I think I do

Edit
Hhhmmm, no luck, but something about this is really familiar.....

Small addition...
I`m on Win7 / 32 and Inkscape is 0.48.2 r9819 (which is also claimed as stable one). Which reminded me that I`ve d/l one of the latest builds - r10947, but it`s on secondary drive and it runs without installation. However, it`s my first time to use builds and maybe that could cause this odd behavior of stable version? Perhaps some conflict occurs while both present? As you may see, distortions happen on fonts also, when converted to paths. At first I thought it might be related to imperfect font ... but after these few posts and zooming out, I realized this is helvetica ,)



I work in stable one, example is from that file (there are bit more of duplicates/clones but not much more than I usually make) so just out of curiosity I made the same thing in build version, and...



...it works as expected?! Last two on the right are the same, jsut duplicated, cause I thought it would be easier for you to see that there is no deformations. Should I remove build? Could that be a solution for restoring correct behavior of the stable one?

Well, let's find out what ShadowRoyale is using. And then maybe ~suv will comment -- or someone who knows more about using dev builds? Or I don't know, maybe removing it could be a test, to find out if the problem still happens?

ShadowRoyale is using the latest stable version 0.48.2 r9819.

Although the shape change doesn't usually happen when converting from simple shapes like circles and squares, it does happen when I use something like the Stars & Polygon tool.

Removal doesn`t solve a thing... but result is kind of more predictable and now ellipse looks more like tsuba / part of the katana`s handle - which is nice ,)

Could you please attach the SVG files together with screenshots? The screenshots by themselves - while useful to convey the basic problem - do not help to further investigate what kind of path data and transforms can trigger this. Only the SVG source with access to the original object (before converting its stroke to path) allows to repeat the tests consistently with different versions.

Sure thing...

Ellipse and that part of the text are here (with the font description / if needed)
0.48.2 r9819
Same content, just opened and saved in different version
0.48+ r10990

* might be useful to mention that I had to add those two .dll`s (libintl-8.dll & libiconv-2.dll) in order to make r10990 working.
** I`ve deleted the rest of my "drawings", but nothin special was there / plain graphic design, no filters, extensions etc. and couple of reference images imported as links.

Thx for the files:

• The stroke of the ellipse in 'PathDeform_r9819_sample.svg' converts correctly to path for me with stable Inkscape 0.48.2 r9819 as well as with Inkscape 0.48+devel r10996 (both 64bit builds on OS X 10.7.2)
• Unfortunately I can't really test the text as text:
  1. I do not have precisely the same font styles of 'Helvetica Neue' installed (works fine with what Inkscape lists as 'Helvetica Neue Light' (the installed font style is 'Ultralight', even if Inkscape lists it as 'Light'), the UltraLight Extended font style however is not available), but
  2. more important: AFAIU the font backends used by Inkscape differ too much between the two platforms (Windows and OS X/Linux)

Could you also share a file with the text converted to path (Note: _not_ 'Stroke to Path', but 'Object to Path')?
Also, have you tested with default preferences (quit Inkscape, rename or move "%APPDATA%\inkscape\preferences.xml" and restart Inkscape to repeat the test), just to make sure you didn't accidentally reduce the numeric precision (number of significant digits)?

Attaching a version of 'PathDeform_r9819_sample.svg' with the stroke of text and ellipse converted to path (Ctrl+Alt+C), using stable Inkscape 0.48.2 (on OS X Lion):

Maestral-PathDeform_r9819_sample-0482-osx.svg

(23.37 KiB) Downloaded 178 times

NOTE: Inkscape 0.48.2 (IIRC only on osx/linux) does not really close the paths when converting the text stroke to path (Ctrl+Alt+C) (internally: text -> path -> stroke to path) (resulting in odd corners of the outlined stroke), but the development version does it correctly:

Maestral-PathDeform_r9819_sample-r10996-osx.svg

(21.32 KiB) Downloaded 179 times

Based on the screenshots, the problem might be related to bug reports like e.g. this one:
Bug #820425 “Stroke to Path on thin strokes results in random segment widths”

It's odd though that I fail to reproduce the example with the ellipse (text/fonts might be a different issue, also depending on how the font outline is defined in the original font file (font format (?)), and passed on to Inkscape by platform-specific backends of font-handling libraries).

Well, it took me some time (and unfortunately I drag you into this) but after reading the text about the Bug and after you mentioned reduction of numeric precision I recalled a few things...

I`ve made a lot of duplicates of that ellipse but I forgot to mention that original one was slightly opened. Most certainly I did that while grabbing it before moving (involuntary, of course,) It was a micro gap, but it was a gap. Still, it does not explain similar behavior of text (which is .otf / even due to differences, I think it`s pretty much the same font in ~suv`s and mine example files / if not as file type at least it is in the appearance). On the other hand, once I`ve noticed that gap I`ve closed it and as closed I converted it to shape and later to path.

Also, I remember changing numeric precision but in r10947 (not in r9819 / which by default opens .svg). I can`t say exactly how much I changed it but let`s say from 4 to 2. Still, I did it while only r10947 was active. As you suggested, I deleted this version but the thing with ellipse happened again in the stable one, during the another tryout.

Later on, I downloaded r10990, and now most interesting part... bot files which ~suv had posted here, r9819 opened and it all worked just fine. Even when I opened a fresh new file in both version and reproduced the whole process (from creating the ellipse and text to converting) it all went well

Maestral wrote:Also, I remember changing numeric precision but in r10947 (not in r9819 / which by default opens .svg). I can`t say exactly how much I changed it but let`s say from 4 to 2. Still, I did it while only r10947 was active.

I would strongly recommend to revert to the default value (8), specially if you work on mostly small or tiny object dimensions.

Also note the both stable and development versions do share the same preferences file.

^ Thanks for the tip about precision. Will do.

Just one more thing. As I mentioned, now I can make it all (and in both versions) but deformations still occur in the original file / where I noticed them. I didn`t know about that sharing of preferences, which I believe explains odd behavior of that single file.

Many thanks ~suv for your consideration.

* edit
@ ShadowRoyale
Hope some or all of this could help you too.