Object selection messes up styles

[LucaDC]

Revision 11098, Windows XP.
Something weird happens when selecting multiple objects after a style change has been applied to an object.
In the attached file, if I select a line, change one of its property (let's say stroke width) and after I select all objects, their properties are changed. This behavior is preserved also after closing and restarting Inkscape (I have remember last style set for all objects except text).
Also, more than once it happened to me that I copied one object and it was pasted geometrically correct but with its stroke properties changed, but I still could not find a way to reproduce it.

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape r11098.
Not reproduced with 11030 and 0.48.3.1.

[su_v (suv-lp)]

On Mac OS X 10.5.8 (32bit) and OS X 10.7.2 (64bit):
- not reproduced with r11080
- reproduced with r11083

Steps done to reproduce:
0) quit all running inkscape processes and rename '~/.config/inkscape' (to ensure default settings)
1) launch inkscape and open the sample file
2) open 'Fill and Stroke > Stroke Paint
3) drag top-most color slider to the far right (-> change color to red)
4) select all objects in the current layer with 'Ctrl+A'

-> stroke width of selected object is changed unexpectedly.

Same happens when changing the stroke color by 'Shift-clicking' on a color swatch in the palette below the canvas, and selecting all objects in the current layer with 'Ctrl+A' afterwards.

Possibly a regression introduced in r11082/r11083 (replacing deprecated GtkOptionMenu with GtkComboBox, used for stroke style settings)?

[su_v (suv-lp)]

Searching for triggers and related unexpected behavior…

The layer group has a matrix() transformation added (possibly a result of importing as PDF/PS/EPS file).

-> Test:
1) load attached modified version of the sample file
    (layer group turned into normal group and moved into a newly created layer)
2) open 'Fill & Stroke' (triggers the bug apparently)
3) ungroup the group (which has the matrix() transform attribute)

-> up to r11080:
Stroke widths and styles of former group members look the same after ungrouping

-> with r11083 and later revisions:
Stroke widths appear to get reset to '0' (stroked paths without fill disappear)

[LucaDC (lucadc)]

Yes, the first attached file comes from an imported PDF. Anyway, I tried with a new blank file and the problem still exists so I decided to post that example.
Here is how it happens to me:
 - open a new inkscape window;
 - draw a path;
 - draw a second one;
 - open the fill and stroke dialog and change stroke width;
 - deselect all;
 - reselect all: bum!

[su_v (suv-lp)]

> Here is how it happens to me:
> (…)

Not reproduced with <= r11081, reproduced with >= r11082

[John Smith (john-smithi)]

This should be fixed in r11107.
It seems to work with LucaDC's simple case in comment #5.
Please update and let me know if there are any more issues.

Apologies this is a regression from r11082.

[su_v (suv-lp)]

> It seems to work with LucaDC's simple case in comment #5.

Works for me with the other mentioned testcases too (comment #3 and #4) - @John, many thanks for the quick fix!

[LucaDC (lucadc)]

It works correctly for me too.
I second ~suv's thanks for the quick fix.

Now, maybe, we could focus on the other issue I've mentioned above: if you copy-paste one of the dashed lines, its thickness is set from 0,50 mm to 0,40 mm. In this case the difference is hardly noticeable (you only see the line becoming thicker (!) and blurred) but in other cases I got bigger differences (like the whole window becoming black due to a huge thickness).
You can see that the preserving thickness option is set (the button in the toolbar is not pressed) and the problem is not present without it (button pressed).
If you duplicate the object the problem is never present.

I suppose it's due to a global transform attribute that's not taken into account when pasting, but it is when duplicating: remember that this file comes from an externally generated PDF (and this is pretty frequent in my workflow).

[su_v (suv-lp)]

> we could focus on the other issue I've mentioned above:
> (…) this file comes from an externally generated PDF

The content of PDF files opened in Inkscape (i.e. converted to an SVG structure) is scaled by 1.25 and vertically flipped, e.g. the layer group which contains the drawing content has a 'transform' attribute similar to this one (doc size in this example is 400x400 px):

 matrix(1.25,0,0,-1.25,0,400)

Testing with archived builds the unexpected down-scaling of copy&pasted stroked paths seems to have been introduced in r10623 or 10624:
- not reproduced with 0.48.x and trunk <= r10622
- reproduced with r10624

Possibly another side effect of
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10624>
which addressed a secondary issue discussed in bug #825840.

@Diederik - could you take a look at the described regression (copy&paste of stroked paths seems to ignore transform attribute of parent group)?

[Diederik van Lierop (mail-diedenrezi)]

I will, and will keep track of this using the other bug report. Thanks for the analysis, Mr. Holmes! ;-)

[su_v (suv-lp)]

@LucaDC - I'll close this report as 'Fix Released' [1] (recent regression has been fixed in r11107) - the remaining issue will be tracked in (reopened) bug #825840. Please comment/reopen if you don't agree.

[Diederik van Lierop (mail-diedenrezi)]

Should have been fixed as of rev. #11186