Not sure if this is a bug or not, but it seems like sub-optimal behavior.

When I fill an object with a pattern, I often want to modify that fill by scaling/rotating the pattern. This is done by selecting the filled object and then selecting the Node Tool, which puts the X-O-(square) handles on the drawing for the user to play with. Problem is, these handles are often placed far away from the object I want to fill, which makes it impossible to tweak them while monitoring the effect on the object.

To fix this, I move the handles closer to my object, allowing me to zoom in and manipulate the handles while viewing the object itself. Great.

Unfortunately, moving the handles spawns MULTPLE new patterns, each of which references the one before it with a patternTransform that I assume is a simple Translation. Even if the act of moving the handles closer to the object is done in one simple mouse click-and-drag, I get maybe 100-150 new patterns. Vacuuming defs doesn't remove these, so I assume Inkscape thinks they're needed.

This seems... odd I thought perhaps setting my Preference to storing optimized transformations would address this, essentially boiling all of those translation matrices down to one, but no.

Any clues about what's going on and how to avoid or fix it?

Hhhm....
Ok, I've read the tavmjong bah Guide about patterns, and it includes several special notes, warnings, etc. which lead me to think Patterns are still under development, at least to some extent. Even while testing to find out if I can replicate the problem, I noticed another one.* (http://tavmjong.free.fr/INKSCAPE/MANUAL ... s-Patterns)

Anyway, if the handles are not on the pattern, that must mean you're using one of the ready-made patterns in the Fill and Stroke dialog? The Guide indicates that patterns you create yourself have the handles on the pattern, not in the upper left corner of page. So if it's one of the simpler patterns, you might consider making it yourself (Object menu > Pattern > Object to Pattern). No guarantees it would solve the multiples though, just move the handles closer.

I do not experience any problems moving a pattern, whether it's by moving the entire object, or by the X handle. But it might be more of a display problem. I seem to recall that patterns are actually bitmaps, like filters and blurs, or at least some of them are. I could be wrong about that. But if not, please go to Inkscape Preferences > Filters, and bump up the "quality for display" settings by one step.

Also, can you replicate this behavior on a fresh new document, or does it just appear in this particular file? Have you searched Launchpad (Inkscape bug tracker) https://launchpad.net/inkscape. If it's a bug, maybe it's already been reported. And if so, workarounds might be noted.

And finally, what is your operating system and Inkscape version?

(*When I move any of the 3 pattern handles, then undo it, the change IS undone on the canvas, but the handles are not repositioned until the 2nd or 3rd consecutive undo.)

brynn wrote:(*When I move any of the 3 pattern handles, then undo it, the change IS undone on the canvas, but the handles are not repositioned until the 2nd or 3rd consecutive undo.)

Known issue:
Bug #165781 in Inkscape: “undoing pattern knot drags does not update knots”

tuomo wrote:Unfortunately, moving the handles spawns MULTPLE new patterns, each of which references the one before it with a patternTransform that I assume is a simple Translation. Even if the act of moving the handles closer to the object is done in one simple mouse click-and-drag, I get maybe 100-150 new patterns. Vacuuming defs doesn't remove these, so I assume Inkscape thinks they're needed.

Can you attach a file where there have been 100-150 new patterns 'spawned'? Or explain more detailed what you mean by 'spawn', maybe with a screenshot of before and after? Are there actually 100-150 new pattern definitions written to the <defs> section of the SVG source? Or do you call the concept of patterns (seamless repetition of a pattern the fill or stroke of an object) 'spawning' if you change the scale of the pattern or the geometry of the object?

Another question: Did you manually edit the pattern file and add custom patterns to the stock items?

Update: I took a closer look at what happens when you scale a pattern: indeed for each object whose pattern you scale or translate, a new pattern definition is created storing the transformation of the pattern for that specific object. How would you propose to store this object-specific data if not (like with gradients) in a pattern def containing the transformation and a reference to the pattern definition itself? If you want to globally use the same transformed pattern, you'd have to edit the first instance of the pattern and use the edited version as pattern fill for all objects (without further editing the pattern geometry for individual objects.

Still unclear to me though how you get 100-150 new pattern defs by simply editing the pattern of one single object...

Providing some basic info I should have done before:
Inkscape 0.48 (latest official release version, not a bleeding edge dev version)
Windows XP and Vista (occurs on both machines)

The file is a boardgame map that's rather large (at least, for me) - 2588x4345 px
The pattern is actually a ~100x100 bitmap that I've imported and embedded in the file, but placed off to the side of the map edge itself, just for sanity, next to several other imported patterns. This pattern is a thatched hut rooftop that will be used on huts all over the map - with one original hut and many clones. Unfortunately, the original hut is far from the pattern (or rather, the rect containing the pattern) itself, so when I select the Node tool on the original, the pattern transformation handles are waaaay far away. Thus, I wanted to move them closer to the original, which results in the dozens of new patterns being spawned.

I'll post a file when I can - exporting it now, which can take a while at 150 dpi

To answer suv's comment, I don't think it's wrong behavior to create new patterns when they are transformed. Seems like the correct thing to do. I do wonder, though, why Inkscape doesn't wait for me to finish moving the pattern transformation handles before it creates (many) new patterns - like I said in the original post, even a single click-drag-unclick will create dozens of new patterns, which just seems wrong. I expect Inkscape to create ONE new pattern based on what I just did with the mouse. And then,if I've got my Preferences set for storing optimized transformations, I expect Inkscape to roll multiple sequential transformations into one. (There could very well be good reasons for not doing this; I'm just telling you what this user expected from that Preference setting.)

FWIW, the patterns do seem to be mostly translations, and mostly the same size (although unfortunately not obviously related to the size of the pattern or the original filled object themselves). Makes me think that Inkscape is hitting some kind of bounding box upon pattern translation, then dumping the pattern and continuing on. Perhaps not a big deal in most instances, but in my case, the long translation distance is creating dozens-to-hundreds of new patterns that I don't want and don't seem necessary.

I'm not a coder, but the fix seems to be either removing whatever condition causes Inkscape to dump patterns in progress of transformation, or giving Inkscape the option to optimize the final transformation based on everything that happened between mouse-down and mouse-up.

Thanks for the help. If nothing else, it's good to know I'm not crazy

tuomo wrote:I'll post a file when I can - exporting it now, which can take a while at 150 dpi

A screenshot or exported bitmap won't really help to further investigate the problem you experience. Can you attach the SVG file or a small sample SVG file with just the one pattern and a few instances of it where you can reproduce this unexpected spawning of new pattern definitions while dragging one of the pattern knots?

In my tests with Inkscape 0.48 r9654 and a current development build (on Mac OS X 10.5.8) I could not reproduce this behavior when using a stock pattern nor when using a custom pattern (made from vector objects) in the same file.

Addendum: when I drag a pattern knot I can see the values of the 'transform' attribute of its referenced pattern definition live update (in the XML Editor) - i.e. it does not create (aka spawn) a new definition with every drag but updates the one it references (after the initial fork).

tuomo wrote:the original hut is far from the pattern (or rather, the rect containing the pattern) itself, so when I select the Node tool on the original, the pattern transformation handles are waaaay far away. Thus, I wanted to move them closer to the original, which results in the dozens of new patterns being spawned.

Could it be that you apply the pattern to a group and not to an individual object? If so, it's fixed with Bug #674109 in Inkscape: “Pattern spam when adjusting a pattern in text.” for Inkscape 0.48.1.

Sorry for the delay in responding. Think I've found where the problem happens. Here's how to reproduce it. All files attached.

1. Open up the PatternSpamBeforeDrag.svg file. Display mode = no filters. The Buildings layer and Huts sublayers should both be unlocked. Set the Zoom level to 20% to see the entire image and the place where the pattern selection handles will appear in the white space on the left.

2. Open up the XML editor and expand the defs4 definitions. Also expand the Buildings > Huts layer. Don't worry about the many "use####" clones for now; we'll talk about those later. Expand the BlueHutGroup.

3. Select path11425, which is a shape filled with the Thatched1 roof pattern. Select the Node Editor and the pattern selection handles (X-O-box) should appear in the white space to the left of the image, as shown in the picture in the next post below (the Forum only allows 3 attachments per post).

4. Point at the X pattern selection handle. Click and drag the three selection handles closer to the Blue Hut Group itself, as one would do when one wants to actually see what the scaled pattern looks like in the Hut shape. When I do this, defs4 is suddenly populated with patterns 22424-22488 (saved as PatternSpamAfterDrag.svg). Each of these patterns contains only a transformation from a previous pattern, eventually leading back to the Thatched1 pattern. I think this is not the way the program should behave.

In preparing these svg files for posting here, I cleaned out a lot of irrelevant map elements, including the many clones of the other kinds of huts (RedHutGroup, YellowHutGroup, etc) that also appear on the map. When I did this, though, the problem went away! To demonstrate:

5. Revert the PatternSpamBeforeDrag.svg file to its original. Select the first two groups in the XML editor (g10068 and BlueHutGroup). Invert the selection and Delete, so that only these two groups exist in the Huts layer (ie, deleting all the clones of this group and the other "colored" hut group types).

6. Repeat Step 3 above. No spam is created; all of the dragging has been rolled into one transformation (pattern 22844) (file saved as PatternSpamAfterDragNoClones.svg).

So. Wassup wit DAT?

Here's the pic of where the Pattern Selection Handles appear. Far to the left of the pattern-filled object itself. Too far away to actually see what the object looks like when you scale the pattern; that's why I want to drag the pattern selection nodes closer to the object (seen as the cluster of nodes in the center bottom of the green field of the image). The pattern itself is seen in the upper right of the image, off to the side of the map itself.

Thank you for spending time analyzing this and reporting your findings!

tuomo wrote:In preparing these svg files for posting here, I cleaned out a lot of irrelevant map elements, including the many clones of the other kinds of huts (RedHutGroup, YellowHutGroup, etc) that also appear on the map. When I did this, though, the problem went away!

Yes, the pattern spam you experience seems triggered as soon as a clone of the pattern-filled object exists in the document (see attached minimal cases: doesn't seem to matter if it is a clone referencing the parent group of the pattern-filled object or just a simple clone on the same level), reproduced with Inkscape 0.48.0 and a current build from the development branch (0.48+devel r9980 on Mac OS X 10.5.8.

I'll search the bug tracker and report it as follow-up to bug #674109 if no related report exists.

Glad to help in some small way; I greatly appreciate everything you've done for the inkscape users.

Not sure if these have been mentioned in somebody's Clone Wish List, but given the kind of stuff I'm doing with clones, I've often found myself wishing for capabilities like:
1. Select All Children - select an original, then Select All Children to show all the children (and children's children) clones of that original. Would greatly help when clones are scattered all over the drawing but you want to operate on them all at once (perhaps by grouping them into a layer or whatnot).

2. As someone else pointed out in a different thread, it would be nice if Relink to Copied would preserve the position of the clone without having to have the new original be co-located with the old.

New report: Bug #693927 in Inkscape: “pattern-spam on pattern-edit if clone of the pattern-filled object exists”

tuomo wrote:Not sure if these have been mentioned in somebody's Clone Wish List, (…)

I'll comment later… ;)