Circle resizing do not preserve stroke width

[LucaDC]

When a circle is scaled, its stroke gets scaled too also if the option to rescale stroke is disabled.
Draw an ellipse of 1:10 ratio, (e.g. 1 mm x 10 mm) then using the input fields (that now work!) make it a circle (e.g. 10 mm x 10 mm) and notice the stroke (set it for example to 1 mm).
The same happens when resizing with the selector tool.
This does not happen with rectangles or paths.
Using geometric bounding box, Windows XP SP3.

[ScislaC (scislac)]

And so the confusion is officially reported! :)

This is actually the correct behaviour according to the SVG spec. When you transform an object via the selector tool, it is actually supposed to do this. It's a departure from previous behaviour, but it actually is the correct behaviour. For the record, I just tried with both rectangles and paths, and surely it does happen as expected. The easiest test it to create a small shape and with the selector tool stretch it really wide.

Marking as triaged rather than "won't fix" because we may need to add another toggle to the commands bar for the selector tool to change behaviour.

WHY AM I USING PROPER ENGLISH SPELLING INSTEAD OF AMERICAN ENGLISH?!?! YOU PEOPLE ARE RUINING ME!!! ;)

[su_v (suv-lp)]

> This does not happen with rectangles or paths.

It depends on whether an object has preserved transforms or not [1]. If the transformation is stored as preserved transform (always - for Inkscape shapes like ellipse, star/polygon, spiral, for groups, for clones, for filtered objects), the SVG specification determines that the stroke is applied before the transformation. With the old renderer, Inkscape applied the stroke after the transformation (bug #165715), but not when e.g. converting the (scaled) stroke to path or in cairo-based export formats. With the changes in the new renderer, the behavior in Inkscape is consistent with the specification, consistent when converting stroke to path and with cairo-based exports.

[1] Stretching a path or rectangle (basic SVG shape) will update the path data immediately (without a preserved transformation - i.e.edit the geometry of the object itself, like the shape tools do when dragging a shape handle), whereas stretching e.g. a circle or a polygon always adds a preserved transform [2].

[2] <http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Shapes.html>

[su_v (suv-lp)]

> Marking as triaged rather than "won't fix" because (…)

… the selection cue of the visual bounding box still uses the old (not transformed) visual boundaries of the stroke: this needs to be adapted to the new renderer.

[LucaDC (lucadc)]

Surely there is confusion.

If SVG says that transforming after applying a stroke should transform the stroke too, that's fine. But then there should be a _clear_ way of specifying if the stroke is to be applied first or before the transform.
Now it seems that this is done with different strategies to (not so) different objects (like rectangles or circles), and partially out of the user's control.
And I couldn't find a way to reset a transformed stroke (i.e. applying after).
Anyway, either all strokes are always transformed with the selector tool, or none of them should. It's not a matter of compliance, it's a matter of consistency.
This, to me, is still a bug.

[su_v (suv-lp)]

> Anyway, either all strokes are always transformed with the selector
> tool, or none of them should. It's not a matter of compliance, it's
> a matter of consistency.
> This, to me, is still a bug.

IMHO the ramifications of this specific SVG compliance ( & consistency with all other SVG renderers, with Inkscape's own cairo-based exports, with Inkscape's own 'Stroke to Path') and OTOH Inkscape's handling of transformations (select tool, 'Object > Transforms…' dialog) of Inkscape's parametrized shapes (they always use a preserved transform attribute) as well as the lack of an often requested command to flatten transforms of selected objects (≠ simply deleting the transform attribute, for which a verb exists) [1] should be discussed on the mailing list, not in a bug report.

[1] flatten a transformation of a shape:
> And I couldn't find a way to reset a transformed
> stroke (i.e. applying after).

You can flatten the transform by converting a shape into path (menu 'Path > Object to Path') and trigger a path data rewrite (e.g. by nudging it with the arrows keys up and back down again). The known drawback is to lose the parametrized features of the Inkscape shapes (ellipse, star/polygon, spiral).

[su_v (suv-lp)]

Setting bug importance to 'High' since the (hidden) preserved transforms of shapes will affect all Inkscape users, and is a major change how Inkscape behaves compared to older versions - this does not mean that the new renderer is technically incorrect though (AFAIU bug #165715 was valid, and SVG compliance is still a major goal of Inkscape).

> it's a matter of consistency.

Central issues to be discussed/considered might be whether a 'transform' attribute will be easily accessible and resettable in the GUI for all objects (on the select tool controls bar?) or whether regular paths keep the preserved transformations as well (change default preferences for 'Transforms' to 'Preserved'?) while enhancing and promoting the shape tools and the node tool to edit the actual geometry of individual objects.

The calculation and handling of the visual bounding box needs to be adapted too, to match the new renderer (bug #805793).

[LucaDC (lucadc)]

>IMHO the ramifications of this specific SVG compliance ( & consistency with
>all other SVG renderers, with Inkscape's own cairo-based exports, with
>Inkscape's own 'Stroke to Path') and OTOH Inkscape's handling of transformations
>(select tool, 'Object > Transforms…' dialog) of Inkscape's parametrized shapes
>(they always use a preserved transform attribute) as well as the lack of an often
>requested command to flatten transforms of selected objects (≠ simply deleting
>the transform attribute, for which a verb exists) [1] should be discussed on the
>mailing list, not in a bug report.

It's not true that Inkscape's parametrized shapes always use a preserved transform attribute: rectangles do not!
Again, I don't care (here) which behavior will be chosen (I agree that this is not the right place for such a discussion) but I can't see any reason for having rectangles' and circles' strokes behave differently when resized with the selector tool.
This is the real bug (maybe we could change the title in "Inconsistencies in resize of stroke for rectangles and circles", or even "Rectangles do not always use a preserved transform attribute").

Also I can't see any valid reason for not having paths share the same rule. As a user I expect the same results when using the same transformation tool on different objects (and, well, they are not so different, aren't they?).
When I first realized the new behavior on circles, I immediately tried with a rectangle and with a path. Seeing different results made me report the bug, considering the problem was with circles only (I never use stars or spirals or polygons, so I didn't even try).
This is the real inconsistency.

>You can flatten the transform by converting a shape into path (menu 'Path >
>Object to Path') and trigger a path data rewrite (e.g. by nudging it with the
>arrows keys up and back down again). The known drawback is to lose the
>parametrized features of the Inkscape shapes (ellipse, star/polygon, spiral).
You mean that if I convert a circle to a path I lose the transformed stroke? And why? IMHO this is another bug!
More than this, if, after converting into path, you don't trigger the redrawing and save and reopen the file, you see no difference. Then you move the object and voilà, it changes (!). I don't dare trying but what if I now open a drawing in which I transformed some shapes without knowing that one day their rendering could become different? Equally looking drawings are suddenly becoming different dependently on each object's history (often hidden from the user).
This is a huge inconsistency bug! Maybe it deserves a new report opened.

>[...] while enhancing and promoting the shape tools and the node tool to edit
>the actual geometry of individual objects.
Shape and node tools are much less powerful: for example you can't skew an object.

[LucaDC (lucadc)]

Also, boolean operators automatically change parametrized shapes into paths.
This is not going to be a painless operation anymore.
To be correct, I think that either the automatic conversion shouldn't be done and the boolean operation rejected because "one of the two objects is not a path", or paths should behave like circles (and rectangles) so the starting looking is preserved.
But this is a bit off-topic, indeed.

[su_v (suv-lp)]

> It's not true that Inkscape's parametrized shapes always use
> a preserved transform attribute: rectangles do not!

See my earlier comments: I explicitly listed 'ellipse, star/polygon, spiral' as affected shapes when stretching and stated that paths and rectangles are differently handled. (The main difference between rectangles and the other Inkscape shapes I'm aware of: the rectangles created in Inkscape (<rect>) are not special Inkscape shapes, they are basic SVG shapes - stretching a rectangle can be directly done by changing the width or height attribute/parameter).

Note that it also depends on the type of the transformation: skew a rectangle and it requires a preserved 'matrix' transform attribute too (or it would need to get converted to a path automatically, or possibly into a polygon - without parameters for rounded corners (polygon as in the basic SVG shape <polygon>, not written by Inkscape up to now): rectangles by definition have 90° corners).

> You mean that if I convert a circle to a path I lose the
> transformed stroke? And why? IMHO this is another bug!

Please read the SVG specification or bug #165715 (+duplicates) and try to understand the underlying issue. You don't "lose the transformed stroke", you flatten or apply the explicit (preserved) transformation of the object into the path data (the geometry itself is changed) - assuming you didn't change the default preferences for 'Transforms' to be stored optimized - thus no transform is applied after initial rendering of the stroked path and the result is a uniform width of the stroke. The old renderer simply had the reverse effect: convert the stroke to path of an object with a preserved matrix transform (stretch, skew), and you 'lose' the uniformly scaled stroke and get a 'squashed' outline of the stroke.

IMHO there's no point in fighting about related issues (e.g. what actually triggers a rewrite of the path data, and what users might assume) here in the bug tracker - your report has been acknowledged and answered on a technical level; the merge of the new renderer is work-in-progress. Please address issues about the user interface (and its inconsistencies) on the 'inkscape-devel' mailing list: What consequences with regard to the user interaction does the correct rendering of the stroke of transformed objects (in accordance with the SVG specification) imply in relation to manipulating Inkscape shapes (ellipse, star/polygon, spiral) as well as regular paths and SVG basic shapes (like the <rect>).

[LucaDC (lucadc)]

Ok, I understand that my knowledge of both SVG and Inkscape's internals is not enough to deal with selector tool's transformations. I really misunderstood your explanation about preserved transforms and which shapes are involved.
Sorry for insisting but I was really unaware that all those "unconsistencies" were intended and due to so many not-for-dummy-users (it's me) underlying issues.
I'll wait for the work in progress to finish; and no selector's tool transformations for me, only guides, snap (as usual) and "don't touch anything after".

[pRototype (regeir)]

I understand that technically this isn't a "bug".

But for me, it's like a bug. If I ever intended to having strokes width changing while resizing circles, I would have made the circle to a path first.

Also I find it very difficult to accurately placing an elipse by alternating between node tool and rotation/move/selection tool. That make it a bug to mee.

[Matt Pharoah (mpharoah)]

I'm not sure if this is the same bug or not, but when I resize ellipses in inkscape, it looks correct (ie. the path is not stretched), but when I export to .pdf, it suddenly becomes stretched along the ellipse's major axis, which is definitely a bug.

[Matt Pharoah (mpharoah)]

I should mention that Eye of Gnome also renders it stretched along the major axis. Inkscape itself is the only thing that doesn't render it this way

[Johan Engelen (johanengelen)]

The SVG spec does not say how a circle in Inkscape should behave when someone is dragging the scale handles on-canvas...

When we apply some transform or change a parameter somewhere in the UI, we are free to change other parts of the SVG to make the result look like what the user would have meant by the change he did.

[su_v (suv-lp)]

The situation in trunk (rev >= 12554) has much improved with regard to the originally reported problem: circle/ellipses now have transforms optimized if possible, and the problem as originally reported can no longer be reproduced unless the user has changed the preferences to enforce preserved transforms.

@LucaDC - can this be closed?

[LucaDC (lucadc)]

~suv, I'm not sure I'm able to say if the issue is resolved or not.
My understanding is that the argument is deeper than the mere technical visual result and, as Johan pointed out, it regards user expectation.
My concern was the inconsistency between the results of the same transformation on different objects.
As you have already said, this is probably not the right place for discussing if Inkscape's behavior is what users expect. And, also, it deals with how other programs may render Inkscape's documents.
From my point of view, I've stopped using select-transform when resizing objects, and I teach everyone to always use the node tool for changing shapes, as it's the only way to have consistent results. Using the select-transform tool has hidden implications that make successive operations results not so obvious and sometimes so unexpected that they may be considered bugs from the casual user.
Probably this is not simply a bug, but a design decision that people could agree or not on; so, again, this is not the right place to discuss about it, hence the report could be closed also if the problem is not.
This is only my opinion, feel free to do whatever you think is right.

[su_v (suv-lp)]

Closing as 'Fix released' without milestone - the reported issue occurred with earlier development builds (after the merge of the cairo renderer) and was never part of a stable release version.

The originally reported issue no longer reproduces (see comment #15) - formerly preserved transforms on shapes are now optimized as much as is possible i.e. by what can be expressed by the shape's parameters.

Discussions on how to improve the handling of remaining (necessary) preserved transforms which affect the rendering of the stroke of transformed objects, and whether or how to expose these transforms to the user should be moved to the inkscape-devel mailing list.