square/circle/polygon/spiral and linked offset misbehaviours

Bug #167419 reported by Hans Nieser on 2006-04-11
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Adonis Papaderos

Bug Description

I have noticed some weird behaviour when using linked
offsets with the Circle, Square, Polyogon/Star, Spiral
and Text tools with Inkscape SVN (checked out yesterday).

Square with linked offset:

- Linked offset responds correctly to moving the square
or resizing and adjustments to the rounding of the
corners using the special shape handles.

- Rotating or skewing the square causes the linked
offset to just move around and not match the position
of the square anymore, but the movements are parallel
because if the square is rotated/skewed back into its
original position, the linked offset will also be back
where it was.

Circle/Polygon/Spiral with linked offset (these behave

- Linked offset doesn't respond to anything
(rotating/skewing/moving) at all except to changes to
the shape itself using the special shape handles.

Text object with linked offset:

- Linked offset only responds correctly to moving the
text object or scaling with locked aspect ratio.
- Other than the above, the linked offset behaves the
same as with a square object.

Related branches

Mgsloan-users (mgsloan-users) wrote :

Actually, the bug is more with the linked offset on curves
and lines. Turns out that (at least according to mental)
linked offsets shouldn't follow the object. Makes sense.
Linked clones do not follow the object.

Hans Nieser (hnsr) wrote :

I see, yeah I suppose I can just group the original object
and the linked offset if I want to keep them together (I am
mainly using Inkscape for website work, creating buttons
with highlights/shadows using linked offsets).

I'm setting this to incomplete in accordance with <URL http://wiki.inkscape.org/wiki/index.php/BugTriageProjects>.

Changed in inkscape:
status: New → Incomplete
Hans Nieser (hnsr) wrote :

In accordance with those rules it doesn't seem this bug should have been set to incomplete. In any case I will try out the latest Inkscape from SVN and see what the situation is with this bug I filed so long ago and see if anything changed, or maybe clarify what the problem could be, taking Mgsloan's comment into account (because reading my own description, I'm not 100% sure what I was talking about in the first place.)

I agree. Why is this bug incomplete? What information is missing?

> can anyone confirm this bug? is it still an issue?

John Cliff (johncliff) wrote :

Looking at this we have inconsistant behaviour between how the linked offset responds to the movement of the original, depending upon the originals type.
Rects and text move with the original when its translated, do weird translations when rotated. Believe this is the bug.
all others i tried remain independant of the original in terms of position, which i understand is the intention.
This is tested and confirmed in SVN as of 20/12/07

Changed in inkscape:
status: Incomplete → Confirmed
prkos (prkos) wrote :

related to bug 177751

Does Inkscape Preferences > Transforms > Preserved solve the problem? I mean it does stop weird offset positioning but is that what it should be like?

I was in error to mark this as incomplete, sorry.

To me, the first two comments suggested that information was incomplete, but the problem was really that I was inexperienced.

Wow. Never noticed that, but it's there.
There's a simple workaround which is to convert the linked offset object to paths.

Anyway, it's a bug and it's confirmed in SVN Rev#21044

su_v (suv-lp) wrote :

Testing lp:~ado-papas/inkscape/bug_167419 with Inkscape 0.48+devel r9931 on OS X 10.5.8, default preferences
While I'm not sure about it being a preferred solution (linked offsets behaving like clones, see also <https://bugs.launchpad.net/inkscape/+bug/184341/comments/1>, possibly others), here's a first issue noted with the patch:

Steps to reproduce:
1) draw star
2) create linked offset
3) rotate star
-> linked offset gets rotated by the same amount
4) undo

Expected result:
both original and linked offset revert to original position

Actual result:
rotation of linked offset is not undone

5) undo back to the creation of the linked offset, now redo up to and including rotating the star

Expected result:
Redoing the rotation of the star also redoes the rotation of the linked offset

Actual result:
Only the star is rotated, but no update of the linked offset is triggered by the 'Redo' command

Affects rotating, skewing and scaling of shapes and their linked offsets (rect, ellipse, star, …).
Works as expected if transforming regular paths which have linked offsets.

Adonis Papaderos (ado-papas) wrote :

@~suv: Thanks for testing the code. I am looking into fixing this. Could you give me more info on your first comment about the behaviour because, from what I understood from the code, the intention was to make them behave as a clone. If this is not something needed there are some optimizations that could be implemented that are not possible now.

su_v (suv-lp) wrote :

> from what I understood from the code, the intention
> was to make them behave as a clone.

Yes, you are correct, AFAIU the intention for linked offsets was and still is to behave the same as clones.

My comment was just an initial reaction/opinion to the change from a user's perspective (i.e. accommodated to the current behavior and the difference to clones, and maybe under the impression that other issues (related or not) with linked offsets seem more or as important than correcting the default behavior). Sorry to not have been more clear about this.

Related reports (again from a user's perspective - I can't tell what it entails code-wise):

Bug #184341 “Linked offsets ignore clone movement preferences”

Bug #239297 “problem duplicating groups of objects with clones and linked offsets”
Only implemented for clones, but not yet for linked offsets (often seen questions about this if e.g. linked offsets had been used to style text on web buttons: the labels of duplicates of the buttons haven't been editable properly because the linked offset still linked to the old text. Current state requires the user to either redo the labels, or edit the links in the XML Editor).

Bug #239430 “linked offset ungroup issue”
needs further testing with current trunk + your patch

Bug #389887 “A linked offset does not follow its source if that source is in another group”
needs further testing with current trunk + your patch

Adonis Papaderos (ado-papas) wrote :

@~suv: thanks for taking the time to inform me in such depth. I have attached Bug #184341 and Bug #239430 to the branch.
Bug #389887 seems invalid to me, since the same behaviour applies to clones as well.
Bug #239297 is probably, as you implied, more important to fix, but would better be addressed with another patch. (I'll try to look into it next).
Thanks again, you've been really helpful.

su_v (suv-lp) wrote :

Inkscape 0.48+devel r9932 with r9932, r9933 of your branch, on OS X 10.5.8:

1) 'Undo' seems ok now
2) moving (dragging) a circle (which has a linked offset) with the mouse sometimes is erratic:
a) prefs set to 'Stay unmoved': moving the circle, the offset should stay unmoved, but moves in the opposite direction of the move of the original
b) prefs set to 'Move in parallel': the drag (translate) of the original is only applied to the linked offset when the original is dragged or moved again i.e. the two shapes are one step of 'drag' transformations apart. Can also affect stars/polygons (not seen with paths, rectangles and spirals).

The erratic behavior seems to get triggered when the preferences for clones&linked offset are changed (not sure though, seems inconsistent to reproduce). Does not happen when moving the selection with the cursor keys - only when dragging with the mouse.

su_v (suv-lp) on 2010-12-05
Changed in inkscape:
assignee: nobody → Adonis Papaderos (ado-papas)
status: Confirmed → In Progress
su_v (suv-lp) wrote :

Inkscape 0.48+devel r9936 + r9932-9935 of your branch, on OS X 10.5.8:

- All previously mentioned issues (undo, drag) are fixed (AFAICT)
- Bug #239430 “linked offset ungroup issue” no longer reproduced (tested with rect, shapes and paths)
- I will file a separate follow-up report to bug #239297 for implementing the missing feature (option to relink duplicated linked offsets when duplicating original+linked offset).

su_v (suv-lp) wrote :

> I will file a separate follow-up report to bug #239297 for implementing the missing feature

I didn't follow-up myself, but here's the report by Adonis Papaderos:
Bug #686193 “Make linked offsets respect "Relink duplicated clones" settings”
(branch was merged, now help is needed for the information displayed in the preferences panel)

jazzynico (jazzynico) on 2011-03-17
Changed in inkscape:
milestone: none → 0.49
jazzynico (jazzynico) wrote :

Fix committed in the trunk, revision 10109.
Thanks Adonis!

Would you be willing to rewrite your patch so that it also work with the 0.48.x branch?

Changed in inkscape:
status: In Progress → Fix Committed
tags: added: backport-proposed
removed: all-platforms
jazzynico (jazzynico) wrote :

(of course, I'm referring to the whole merge, not only this bug ;)

Krzysztof Kosinski (tweenk) wrote :

Backported to trunk in 9861

Changed in inkscape:
milestone: 0.49 → 0.48.3
tags: removed: backport-proposed
Ted Gould (ted) on 2012-02-15
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers