Create a circle while holding down the control key.  If you drag the mouse in a diagonal while doing so you get a "perfect circle".whose width and height are equal.

There's a problem though.  If you rotate the resulting circle by a relatively small number of degrees the width and height of the circle increase rather than staying constant, meaning the "circle" is not perfect but actually bulges out a bit.

To make this grounded, the first image shows a 100mm x 100mm circle sitting at (0,0) (and thus centered at (50,50)).  It has 0 stroke width and is being displayed in outline mode.  The second image is the identical circle but after taking the single action of rotating it by 25 degrees clockwise - it still has 0 stroke width and is displayed in outline mode.  The resulting "circle" is 100.027mm x 100.027mm and, to try to keep it centered at (50,50), inkscape now places it at (-0.014,-0.014).

It's a very small difference, but it's real.  What's up with this?  Is this because Inkscape represents circles by splines and thus has no true circles but only close approximations to them?

(This reminds me of another question I've been meaning to figure out.  To truly keep the rotated circle centered on (50,50) its position should be at (-0.0135,-0.0135), but due to rounding you get -0.014.  Does inkscape actually place it at -0.0135 and the reason we see -0.014 is because it only displays numbers with at most 3 significant digits after the decimal, or does inkscape round the actual number so that it truly is sitting at -0.014?  Either way, can the number of significant digits be changed?)

Not reproduced here.

Circle objects are precise, but if converted to path objects, they are quadratic b-splines and not precise arc segments.

To set decimal precision: Preferences> Input/Output>SVG output.

Then maybe I’m confused about an element of how Inkscape works.  If I create a circle using the circle action on the left side of the screen, doesn’t that create a circle object?  If I didn’t explicitly convert the resulting object to a path why would it have been converted to a path (resulting in its quadratic spline approximation)?  I’m doing the rotation via the Transform action in the Object pull down menu, so I’d have thought it was created as an object and rotated as an object.

Thanks for the pointer to the precision setting.  It’s nice to know that the 3 digits that are shown were just a UI choice.

It sounds like your clear on the distinction, many new users are not. Similarly, unreliable narrators are more common than not in forums.

If you can share an example Inkscape file, that would be interesting to look at.

Not able to reproduce here either. However, I do see a width still being applied by the stroke if a stroke is still applied if the stroke is enabled and its width is set to 0.

If you really want it to act like there's no stroke width in terms of geometry, either:

• Turn the stroke off entirely
• Select a "hairline" stroke (available as "units" for the stroke width)
• Select Preferences > Tools, and then for Bounding box, select geometric

The [ and ] key are the rotate shortcut keys.

A simple test for circle symmetry is to hold the key down and watch the bounding box of the object. 

From my basic experiments, 5 nodes is the minimum to eliminate 'Bounding Box Jiggle'

Jiggle should not be seen with a circle object.

Yes, I meant the conversion. 

However I think I may have confused myself now. I've just noticed that with bounding box set to geometric the jiggle is gone even for the 3 node circles ? However it is there in visual mode.

Sorry to take things a bit off topic - I have attached an example or just simple circles made form paths, using normal Arcs.

Testing on UM22.04 Inkscape 1.2 (1:1.2.1+202207142221+cd75a1ee6d)

3" circle with .005" stroke (same with various other strokes) seems to go off by .001 while rotating and no change with no stroke.

If then reset from 3.001 back to 3.00 it changes but to 2.999.

Just confirming.

@mendy, please share the Inkscape file.

NVM... stroke issue reproduced here.

Well saw your comment and created requested file from scratch.

Just posting anyway as when I came back you posted that you saw issue. Thanks for looking.

I tested a clean install of .92.5 and see the same issue. Not sure yet if it's an svg thing or an Inkscape thing.

Hi

Created two test files and exported / plotted as svg's.

One in FreeCad and it exhibits the behavior while rotating (fcc.svg) opened in Inkscape

Other in KiCad and doesn't seem to change diameter (kcc.svg) opened in Inkscape

Note: KiCad was just using an exsisting circle symbol which happens to be around 1.5". Didn't feel like creating a new symbol at 3:.

Looks like the circle stroke is calculated in the same fashion as a 4-node path. Both show the same issue.

Whereas a 72-node smooth path (made from a 72 point polygon) does not show the stroke issue.

So it sounds like a 72-gon with a smooth path (@TylerDurden great idea) is a more accurate circle than creating an actual circle object?  (And it may or may not be Inkscape that’s causing this, as opposed to something inherent with SVGs, but either way if I want a more accurate "circle" that isn't off by 0.027% I now have an option....)

[A badly timed laptop problem has me online only by iPhone for now - so at the moment I can’t actually run Inkscape to follow along with the examples that people have been posting 😢]

Yes. Long ago, @Lazur pointed out the lack of precision for circles converted to paths due to beziers, and the improved behavior of smoothed n-gons.

I did not realize that the strokes on legit circles had the issue baked in.

Updated a report from 3/2020: https://gitlab.com/inkscape/inkscape/-/issues/1208

No; a circle-shaped 72-gon is not remotely as precise as an actual circle in Inkscape.

An SVG circle is handled as a mathematically defined object with zero inaccuracy. However, a circle itself is defined with a single radius; it is not on its own an object that has any stroke width.  

If you add a stroke, that is fundamentally *style* information, where you ask Inkscape (or any other SVG renderer) to draw a path around the outline of the object that has a stroke. A stroke is always a type of path; it is no more the case that two circles (as in, inner boundary and outer boundary) are used to define the stroke around a circle, than it would be for an arbitrary polygon. Style information will never be as precise as the geometry of the circle. Once you start with that defined path, then the number of vertices in that path can begin to matter.

If you want a mathematically accurate circle, Inkscape provides an option for that: the geometric bounding box, as I mentioned earlier. If you use the geometric bounding box, the sizes shown will be the size of the actual object, not of the actual object plus its path-based stroke. 

If you want an approximate bounding box for your circle that includes the width and imprecision of the stroke styling, then keep doing what you are doing. But, please understand that you are now making an intentional choice to do so, rather than using the full precision that is available to you.

A more precise stroked shape is achieved with the smoothed polygon.

As @mendy already pointed out in #14. The increased drawing precision in kcc.svg (10000 user units per inch) works fine with both visual bounding box and geometric bounding box.

oskay

No; a circle-shaped 72-gon is not remotely as precise as an actual circle in Inkscape. An SVG circle is handled as a mathematically defined object with zero inaccuracy. However, a circle itself is defined with a single radius; it is not on its own an object that has any stroke width.

Would argue with that. That statement may be correct without the context of a drawing. 

Once there are booleans involved or you just want to construct with circular segments the circle/ellipse will be converted to cubic Béziers.

With 8 nodes at best. Then it's how well a Bézier path can represent a circle. 

Nodes can be precise, with the error getting larger in between the segment. 

A 72gon is way more precise than a 8gon. 

I know, theoretically paths can have circular arcs  just as polylines, but there are no gui options for editing those nor would they work well with Booleans.

Worth noting it's best to adjust the number of nodes to the use case. If working with 45° steps/tangents in a design, a 16gon is more useful than a 12gon. 

A 72gon is an extreme example. 

If you want that kind of accuracy, using circle elements in a cad environment is probably a better choice.

@Lazur If you've got an actual argument against what I said, let's hear it. My statement was correct in the context of an SVG drawing; circles are a valid type of SVG object. 

If you just want to assert that it's possible to convert a circle into a less precise representation (like a polyline or a composite cubeic Bézier curve), that also does not contradict what I said.

Before we devolve into the minutae of geometry, I'll note that precision issues were not seen in an unstroked circle object; but as noted above, strokes being styles had the precision issues identical to a 4-node cubic bezier path, which was the crux of the OP's post.  If there is a way for strokes to use more precise Bezier calculation (as if there were more nodes), that could improve things.

I don't think that there's any disagreement on the geometry here.

My reading of the original post is that (1) there was a question whether or circles were represented by Bezier curves or something more precise and (2) that the original problem -- one that I've bumped up against many times -- would be solved by using the geometric bounding box.

I'd try a different drawing precision (also works with default preferences).

Attached, Less_Precision.svg (circle converts to 4 nodes path).
Attached, More_Precicion.svg (circle converts to 16 nodes path).

TylerDurden

Before we devolve into the minutae of geometry, I'll note that precision issues were not seen in an unstroked circle object; but as noted above, strokes being styles had the precision issues identical to a 4-node cubic bezier path, which was the crux of the OP's post.  If there is a way for strokes to use more precise Bezier calculation (as if there were more nodes), that could improve things.

My guessing is that the stroke added doesn't change the geometry in itself BUT the rounded cap is represented by/as a path of  4 nodes. 

That is, on each position along the original geometry a 4 noded path shape is rendered with the same horizontal/vertical alignment. 

Unlike with a pattern along path effect which would thicken the core stroke proportionally.

Interesting.

That has potential. Changing the precision for the entire document may have issues (try pattern fill), but if it could be internally applied to conversion of arcs to paths, a much greater level of precision could be possible for stroked objects and boolean operations.

Earlier, I did try changing the cap and joins and didn't see much difference in behavior.

@oskay

My point is it doesn't really matter how precise the theoretical circle is in the context of drawing because if you are using Booleans all that is gone.

The result will be a path with Bézier segments and not circular arcs. 

More than that, Booleans create other issues.

Example case:

1. draw a circle
2. duplicate it and rotate the duplicant
3. select both and perform a Boolean union

Count the new nodes appearing from nowhere. 

If they were both the same geometry after the rotation, there wouldn't be any new nodes added.

This experiment can also be recreated using the polygon tool,

however if in the drawing context the goal is to create a shape with "circular" segments,

it gives better results if the target path is built up by combining circular segments created from polygons, with fitting node positioning. 

Better than relying on Booleans using circles or better than combining circular arcs-converted to  Béziers.

TylerDurden

Earlier, I did try changing the cap and joins and didn't see much difference in behavior.

Attaching an example which boiles down to the exact issue. 

The right column has the objects rotated by 30°. 

First row - circles

second row - objects converted to paths

third row - path split to 4 segments, and a tagment segment drawn atop

fourth row - stroke converted to path.

Note the linear stroke segment on the right and how it changes in size of the visual bounding box if the stroke is converted to a path. 

Issue is not really related to circles at all but how the stroke width is rendered/or rather calculated internally for the visual bounding box.

Edit: put a duplicant of the stroked path and one where the stroke is converted to a path atop eachother. 

Seems they both look the same, only the visual bounding box size varying. 

Which renders the question in the original post in a different light. Both objects, rotated  or  not are "precise" (as they can be, see arguments above) it's just the bounding box size is calculated sloppy.

Meaning for practical purposes no stroke or using geometric bounding box is a must because otherwise those values in the spinboxes are unreliable.

Ah.  That sheds more light.

TylerDurden

greater level of precision could be possible for stroked objects and boolean operations.

or maybe not...

Another test file.

Would still suggest the polygon method even if the path with the stroke is rendered more precise. 

Because the stroke/circle converted to path is definitely more inaccurate than that.

(For drawing tangents, snapping to tangent points at given angles, aligning horizontally/vertically etc.)