Drawing a circle sounds pretty easy, I thought. However, I experienced that many of the possible ways to define a circle in Inkscape seem to be rather complicated and not straightforward.

Let me explain:
A circle can be defined by the user via several parameter sets:
a) 1 center point (C) and a radius (R) or a diameter (D) or a point on the circumference (P1)
b) 2 points (P1,P2) on the circumference + a center point (C) to be chosen
c) 2 end points (P1,P2) on the diameter (as a special case of b) )
d) 3 points (P1,P2,P3) on the circumference
e) Well, Inkscape also uses a corner point of a surrounding square (S) (not necessarily bounding box, since it depends on the stroke).
Have I forgotten one?

Let's call these coordinates/parameters as follows:
Center (C), Radius (R), Diameter (D), Point 1, 2, 3 (P1,P2,P3), Square (S)

All these parameters can be defined either by
- a mouse click placement or
- a numerical entry or
- snapping to existing points
Let's call these modes of entry: mouse (m), numeric (n), snap (s)

This gives a lot of different possibilities to draw a circle. If you take the 1st out of 5 parameters with 3 methods and the 2nd parameter out of 5 with again 3 methods that's already 225 different procedures (in theory )

The most obvious procedure is: CmRm: Center mouse, Radius mouse
1. Ellipse tool (F6)
2. click for the center point
3. hold Shift+Ctrl
4. mouse drag the radius to the desired distance and release
So, these are 4 actions to get a circle with some radius placed somewhere with the mouse. I think that's about the minimum you can get.

If you want CnRn, i.e. numerical input of center point and radius, it's already getting more complicated:
You cannot use the Tools Controls Bar directly, since
a) the x,y coordinates are the lower left corner of the bounding box
b) the x,y position depends on the stroke width

CnRn-procedure:
1.-4. CmRm-procedure to place a circle with some radius somewhere
5. Shift+Click on the color palette: color none (to temporarily remove the stroke)
6. lock width/height
7. in width field enter your radius*2, e.g. for 50mm radius enter 50*2 (good to know, Inkscape can do simple calculations in the numeric fields)
8. Enter your x coordinates minus the radius, e.g. for xy-position 100,200 enter 100-50
9. Enter your y coordinates minus the radius, e.g. for xy-position 100,200 enter 200-50
10. Shift+Click on the color palette: reset your original stroke color/width
You could also use the Transform tool (Shift+Ctrl+M) (then it would be 16 actions!)
I do not find it very convenient that the user has to do ancillary calculations or copy&paste some numeric values from somewhere to somewhere else.

How would this compare to a not-(yet?)-existing "advanced" ellipse tool?
1. "Future" ellipse tool (F6)
2. enter center x coordinate
3. enter center y coordinate
4. check equal radii
5. enter radius
Done!

If you want your radius snap to another point it's getting even more complicated. As far as I can tell, you need additional helpers like guides or temporary lines, etc. and an largely increased number of actions.
I am curious and challenge yourself:
How many actions would you need to draw a circle with numerical center and snapping the circumference to an existing point , i.e. "Procedure CnRs" according to above nomenclature?

Don't even start about drawing squares, rectangles, ellipses which can be additionally rotated...

Don't get me wrong, the Inkscape developers are doing great work, really! It's about the effectiveness in drawing just simple geometric patterns.
Just thinking loud...

There is also the extension Draw from Triangle that allows you to define a circle using medians and tangents, which might be quicker, and the path effect Ellipse from five points which admittedly might not give you a circle if you don't know what you are doing

Thanks, @druban, did not know about this extension...
Pretty much hidden... Menubar | Extensions | Render | Draw From Triangle

After some initial strange results and some time to understand how it works, I now indeed get some simplifications in drawing special circles. With this, basically all P1xP2xP3x (x=m,n,s) procedures are now rather easy... only still ~216 procedures left ...

Depending on the case, I now have to use the ellipse tool (F6) and/or the Transform Dialog (Shift+Ctrl+M) and/or the XML-Editor (Shift+Ctrl+X) and/or several extensions. Phew!
Nevertheless, it would be great to have ONE SINGLE dedicated circle(,ellipse,arc) tool.

A tiny bit offtopic, but there's also the Ellipse by 5 points LPE in 0.92: http://wiki.inkscape.org/wiki/index.php ... y_5_Points

Thanks, @Moini and @druban, pointing to the Five-point-ellipse-LPE. Now, I tried it. It looks flexible and fast (compared to the extension "Draw from triangle"). But as @druban said, you need to know what you are doing in order to really get a circle. I still need to find out what's the best way. Maybe snapping of the nodes to an additional helper structure?
Some drawbacks I noticed:
- you will not have a circle but a circular path (so how to control whether you really have a circle?)
- be careful: I crashed Inkscape by dragging one node on top of another (but could not reproduce it again so far)

...just for the records...

Another possibility for "Circle procedure CnRn":
1. drag a guide to somewhere
2. double click on the guide
3. enter x-coordinate of guide origin
4. enter y-coordinate of guide origin
5. Press OK
6. enable snap to handles
7. use ellipse tool (F6)
8. snap to guide origin, hold Shift+Ctrl and drag the radius somewhere
9. Use XML-Editor (Shift+Ctrl+X)
10. select parameter r
11. enter new value for radius
12. press SET
13. delete guide

Although it needs more actions than the procedure above, but you directly can type in the numerical values you want. Actually, some actions (like enable snapping) might not be needed to be carried out again for the next circle you want to draw.
Entering the xy-coordinates of the circle center point in the XML-Editor would not be so easy because the XML-Editor uses a different coordinate system (argh!).
It embarrasses me that you need guides and XML-Editor in order to draw a simple circle.

I don't generally expect illustration tools to have the same kind of parametric tools that CAD has (but there's no reason why they can't).

I typically just drag a proportional circle and use the proportional transform (in control bar).

Would a circle method that involves just two clicks be nice? Sure, but trust me, users can get confused when one method involves drag and another involves click-move-click.

I can envision a toolbar that has flyouts for the different methods: one for illustration style, one for cad style, but that would probably be preceded by a cad-style extension that proves handy and reliable.

I don't understand why dragging out a circle with the Ellipse tool and Ctrl key, isn't sufficient. Do you mean that you want some way to draw the circle on some particular spot (center, radius, circumference, or other)? And/or draw it some particular size, yet in the same step while you draw it?

There have been many, many, many requests for more CAD-like features for Inkscape. Search the forum for more info. Search Launchpad to find the requests and add your support, or more details.

tylerdurden wrote:I don't generally expect illustration tools to have the same kind of parametric tools that CAD has (but there's no reason why they can't).

That's exactly what I wanted to say. Especially, if all the components are already there.

tylerdurden wrote:I typically just drag a proportional circle and use the proportional transform (in control bar).

What about the stroke?

tylerdurden wrote:Would a circle method that involves just two clicks be nice? Sure, but trust me, users can get confused when one method involves drag and another involves click-move-click.

That's why am hoping for a meaningful Circle/Ellipse/Arc-Tool.

brynn wrote:I don't understand why dragging out a circle with the Ellipse tool and Ctrl key, isn't sufficient. Do you mean that you want some way to draw the circle on some particular spot (center, radius, circumference, or other)? And/or draw it some particular size, yet in the same step while you draw it?

Just look at the number of steps for achieving a certain position and size of a circle. I can't believe that this is a sufficient and an efficient way. I might get more understanding for the missing feature if a programmer tells me that this really hard to realize. Look at all the other features in inkscape which are certainly much more complex than a simple center point and a radius of a circle. As you stated several times in this forum, developers would like to develop what they find interesting. Well, such a basic function might not be so interesting...

brynn wrote:There have been many, many, many requests for more CAD-like features for Inkscape. Search the forum for more info. Search Launchpad to find the requests and add your support, or more details.

Well, drawing a circle at a defined position with a defined radius is not really too CADish.

There is an 'LPE tool' that hasn't been included in the release, because it was too buggy. I think that one allowed for a couple of geometrical constructions. Do you have a development version installed?

While the discussion is somewhat academic at this point, here's a practical workaround that may speed some workflows...



Not perfect from an efficiency standpoint, but maybe an improvement and the circle is perhaps better than the 4-node conversion from ellipse.

(H/T to Lazur.)

@tylerdurden, interesting approximative workaround!
Actually, that may simplify all procedures where you want to snap the radius to somewhere.
As you show, you can drag the handle and snap it to an existing point/path, that's what I am missing for the circle.
It looks like all the components seem to be there to also do it for the circle.

By the way, you get the approximative circle right away if you enter a number >0 in the Rounded field:
~0.445 for a triangle
~0.39 for a tetragon
~0.37 for a pentagon
~0.36 for a hexagon
~0.35 for a heptagon
~0.345 for an octagon and polygons n>8

Can you expect a beginner to find such and the earlier mentioned workarounds?
Well, a heterical question: does a beginner need a circle with precise location and radius and an easy way do do it?
Besides Inkscape's motto "Draw freely" shouldn't it also be "Draw simply" or "Simply draw"?

I see, some of the most active forum members are not completely convinced that such a feature is necessary, but good that they have plenty of ideas for workarounds .
Anway, I still would be interested in a developers opinion why the most obvious way to create a circle, i.e. entering xy-coordinates for the center point and a value for the radius was/is not worth implementing? I will check on launchpad.

brynn wrote:I don't understand why dragging out a circle with the Ellipse tool and Ctrl key, isn't sufficient.

Because if it CAN be done precise easily, I WANT it precise (as precise as 1..16 digits are...)

brynn wrote: Do you mean that you want some way to draw the circle on some particular spot (center, radius, circumference, or other)?

Yes! You got it!

brynn wrote: And/or draw it some particular size, yet in the same step while you draw it?

If possible, yes! See GIF-Demo with a rounded tetragon as a (pretty well) approximated circle.



And for academic completeness:
using a tetragon (e.g. with rounded=0) with additional object to path and some rotation and snapping steps you can snap a "real" circle on top .

If we want to refine our language, we can make a distinction between drawing and drafting... illustration programs and CAD, respectively.

Inkscape being considered one of the former, I think the devs rightfully place efforts into making Inkscape improved in that direction. It's worth noting that most illustration programs function in the same basic way as Inkscape. Some, (e.g. Affinity Designer) have some handy CAD-like functionality, but mostly, they operate in the same way.

Beginners would certainly benefit from precise tools, provided they are easy, consistent and optional. I'm not kidding when I say they can get confused when switching between CAD and illustration... lotta dragging instead of clicking, and vice-versa. Even the Inkscape bezier pen tool confuses some beginners who drag the tool, when instructed to click-move-click-move for straight segment path creation.

If all the Inkscape shape tools functioned with click-move-click, it would be more like cad, and adding real-time dimensioning, mode-choice, etc. would be less of a departure from SOP. But it would be a departure from most other illustration programs, and user expectation is big part of acceptance ("different" is frequently regarded as "bad").

In one sense, open-source is like closed; in that given enough demand, developers will pursue a particular feature. OTOH, open architecture provides an opportunity for the community to add features (i.e. extensions) independently. Plus, there might be ways to financially sponsor development of particular features (like CAD tools) in the future.

WRT smooth polygon precision, more nodes are better.

It is the Bézier curve, the segment of the path that cannot be exactly circular.
Basically the ellipse and circle objects are made up of 4 nodes and segments if you convert them to paths.
As far as I know development builds add more nodes, to make a higher precision.
The polar grid extension could make you a good image, however that draws ellipses -four nodes only-.

Nodes can be computed with high accuracy.
With the * tool you can draw poligons, convert it to paths, and make the nodes smooth to have a more accurate cirle.

You may try the interpolate extension or lpe too later on -to draw the parallel circles-, and maybe other things like the envelope extension, if really necessary to be more precise.

viewtopic.php?f=22&t=17507&p=64387&#p64387

Here is a good source on Bézier curves.

The thing is inkscape works mostly with paths which are Béziers, however there is an option in the specs of circular path segments. As far as I know it doesn't have a gui, saw an svg only containing such circular paths shared by S_uv, for an extension to render iso 3098 fonts as Hershey text.
For practical use doubt that would work out well -probably once you'd make a Boolean operation they will be converted to Béziers.

(Tags for future reference -circle, Bézier, quadratic, cubic, radii, primer, approximate, approximating, arcs.)

tylerdurden wrote:WRT smooth polygon precision, more nodes are better.

Well, not necessarily. What I find is that with a tetragon, pentagon or hexagon you also get good (or even better) results than with higher n-gons.

Since I like to experiment (not just with Inkscape), I was interested in the difference of the approximated circles with respect to the "perfect" circle. So, I used the Boolean operation "Exclusion" to create the area which deviates from the circle.
I measured this remaining area with the Extension | Visiualize Path | Measure Path... | Area
Maybe a mathematician can do this on a theoretical or analytical level...

If we believe in the precision of Inkscape and in this extension, I get the following plot (left: linear scale, right: log scale).
So what we see from this:
With an appropriate rounding parameter we can reach an area mismatch of less than 0.001% (Minimum 0.00028% with a hexagon and rounding 0.357), which should be good enough for most practical purposes.

Thanks, @Lazur for the link to the interesting Bézier-Curve-Page. There, you really can dive in very deep.

Nice work!

Fascinating that the hexagon is the winner... any thoughts on why? (that a layman can follow?)

Interesting.

For the record I wouldn't use a Boolean operation as the basic of the comparing, as it definitely has its own rounding errors, especially when the objects are close to matching.
Like, draw a circle, convert it to path, duplicate it, rotate the duplicant a bit and make a union of them.
Nodes will be placed randomly here and there.
The rounding error (due to anti-aliasing(?)) is not consistent between versions -it got improved in 0.92 compared to 0.48.

What I'd check instead is the distance from the origo, and the largest differences between a "constant" radius and what's rendered on screen at the curved paths from the circle shape along the circumference.
From that point of view you shouldn't get any closer than with the * tool, where the nodes are laid.
("However" if you use a path to measure the distances after the rotating -rotation centre snapped to the circle's origo- and the transformation are set optimised, then how can you be sure you still have the exact same length once you performed a simple rotating. After repeated individual rotating, there will be definitely some rounding errors adding up, even if not noticeable in a compare.)

So how many nodes would be the best to use?
Depends on what you are after. I usually go by 12 because with 6 you wouldn't get the same errors on the top extremities as on the sides.
If you want to snap it for a construction, 16 may work better for snapping 45° as well.
More than that is quite impractical for regular use. If you are not designing a mandala with a 16 fold symmetry etc.

(Had constructed golden spirals with tiles of 1 gon turns but that's hardly regular use.)

Also a related relic from the past: Re: I request more CAD-like features -with my very first drawing at openclipart.

Leaving OCL?

Sorry, I missed the meaning of the video. Since I don't have anything worth sharing, I don't use it, so I don't understand a lot of the features. Is that something unfair about the rankings? Doesn't it still work as a host for your Inkscape work, even if statistics are weird?

Lazur wrote:For the record I wouldn't use a Boolean operation as the basic of the comparing, as it definitely has its own rounding errors, especially when the objects are close to matching. ...

You are right, @Lazur, I didn't do some basic pre-tests
Well, and before you can measure the area of a circle you need to convert it to a path. What is this path? Already a rounded polygon? Since a circle converted to a path gets four nodes, it might just be a rounded tetragon. And if the "Extension Measure Area" worked absolutely correct you should get somehow the minimum for the tetragon.

Furthermore, draw a circle with the radius r, convert it into a path (Shift+Ctrl+C) because otherwise you cannot measure the area Pi*r^2 with the Extension and from this extract Pi:
We all know what Pi should be, but with different radii you get different Pi
3.14159265358979323846 (Pi)
3.14160646504181 (r=0.1mm)
3.1416063714328484 (r=1mm)
3.141606371414406453 (r=10mm)
3.14182286172491549223 (r=100mm)
3.1418228617249149829149 (r=1000mm)
It differs already from the 4th digit. Ouch!

Well, I'd better stop now, otherwise I will be completely loosing confidence in Inkscape precision .
viewtopic.php?f=22&t=32160

tylerdurden wrote:Fascinating that the hexagon is the winner... any thoughts on why? (that a layman can follow?)

Then, well, it's probably just rounding errors and numerical artefacts .

theozh wrote:Furthermore, if you draw a circle with the radius of Pi*r^2, convert it into a path (Shift+Ctrl+C) because otherwise you cannot measure the area with the Extension and then extract Pi.

Then the error is on ^2 as well?

Inkscape adds in 8 nodes if the radii is larger than a certain value, not sure what is that value hard coded in.
Somewhere around 800 mm for the diameter?
Testing... wow it produced 7 nodes instead of 4 or 8 for 800 mm width.

Anyway. 0,1-10 mm is not the scale where you can effectively produce "mathematically precise" matches -thinking of regular implementations.
Like, if you are not using cnc but regular printing on paper, the paper size spec -iso 216- lists the tolerances amongst the height&width.

±1.5 mm (0.06 in) for dimensions up to 150 mm (5.9 in)
±2 mm (0.08 in) for lengths in the range 150 to 600 mm (5.9 to 23.6 in)
±3 mm (0.12 in) for any dimension above 600 mm (23.6 in)

I remember an art printer told me before that even the printers can leave out lines of inkblots -and if you are after printing on canvas, who knows how the final print will be stretched on the frame and how it reacts to humidity&temperature.

It differs already from the 4th digit. Ouch!

0,1 mm error on an 1000 mm scale shouldn't be that bad although I also feel annoyed by it and the unforeseeable randomization of the typed in values mentioned in that other topic.