Hi,
On Thursday 14 October 2010 15:40:22 Dave Crossland wrote:
On 14 October 2010 15:02, Michael Grosberg <grosberg.michael@...400...>
wrote:
Andy Fitzsimon <andrew@...360...> writes:
I had a thought after some observation and while it wouldn't look good on our already crowded toolbox, it should be fairly easy to implement a crop tool. In practice its just applying parent group to all things then a clippath and finally a resize page to contents command which we already have the code for...
Usability-wise, won't that interfere with a user's ability to edit their artwork after the crop has been applied? The "expected" result of a crop is that shapes are actually cut, not just hidden with a workaround.
Andy's suggestion includes the step of resizing the page, which is what makes this 'crop'-like and 'cuts' the shapes.
That might achieve the same result if you don't want to edit the file ever again, but if you want to continue working on it later, That just won't do.
A boolean operation would not be good, no.
As for its place ion the menu,. if you ever get to implement it, a "crop to selection" entry in a menu is enough. but if it's just a clipping path, perhaps an extension named "clip canvas to selection" would be more descriptive.
Technical more descriptive, but not what users expect. Users expect a crop tool that fits the page bounds to their selection and hides the off-page elements.
Perhaps call it "Page Crop"?
I think that crop should actually be destructive, if one is implemented. While I think clipping with rects may not be obvious for beginners, I don't think it should be called crop. At least it would not be consistent, I don't think we do want to end up with crop function and clip function that do the same.
I think that such a tool should not try to do several things at once (i.e. mix page resize and clipping).
So this is one possibility how to solve this:
1. Implement hiding (i.e. not drawing) everything that is outside of the page, that would be togglable in the toolbar and would not affect the svg (I think there exists a bug report about this anyway).
2. Implement a "Page resize tool" or otherwise allow editing page boundaries in-canvas (probably like guidelines?). So resizing the page would no longer requre the trip to Document Properties dialog. When the hiding feature (1.) is active, this would probably do what is described here as 'crop'-like.
3. Implement a function that removes everything that is outside of the page (using a boolean op?) - this could be used also in exporters. This would allow for removing "the useless stuff" when I want to reduce the file size.
4. Implement a "Masking & clipping" mode that would allow editing the clips. The workflow could look like this: a. Select the objects to be clipped (clip the whole page if no object was selected) (layer?) b. Enter the clipping/masking mode. c. Everything you draw goes to the clip/mask. What you see is the original drawing with greyed out regions that are not inside the clipping region (i.e. everything under the objects you draw is preserved and everything other is covered with for example 70% black). I'm not sure how exactly would this display masks, though. (Maybe simple masks with transparency?) In this mode, you could use every tool for which this makes sense (rectangle, ellipse, shape, gradient - for masks, and possibly others) This step could start with rectangle tool pre-selected so it will work for the common case. c. When you are done drawing the clip, you hit ENTER or click some toolbar button. Hitting ESC or clicking cancel button would just return from this mode. d. The objects drawn in clip mode are grouped together and set as clip for the objects selected in step a. The mode is returned back to normal. e. If you try to enter clip mode with already clipped object, it's clip would be shown in the clip mode.
The set/release clip/mask commands could stay where they are to allow for advanced usage.
What do you think?
Best regards, Martin Sucha