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"?