Crop tool should be straight forward to implement, thoughts?
G'day everyone,
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... Also, it would be easy to have a rule that crops from the selection (if things are selected) by skipping that last resize page and only grouping the already selected stuff.. maybe attached as a mode of the default selector tool from the parent toolbar
My thinking is that right now creating clippaths is a weird concept for new-to-vector users, but almost everyone gets the idea of cropping
This could be a very achievable GSOC feature if someone is willing to mentor it..
Personally, I can see how much simpler it would be rather than drawing rects and making a weird selection every time i want to crop. to new users, this workflow is not obvious
What are the thoughts here?
a quick clarification after some conversations in chat.
this is a question of workflow and not technology.. its not that we dont expose the ability to do all this to our users already .. there is just a potentially better way for a majority of uses.
here's a brief chat with su-v. im jumping off the grid again ciao!
(12:20:56) su-v: you want a tool that takes a rectangle (or creates one with the size of the selection bbox), fits page to selection, clips contents with the rectangle - all in one step? (12:21:34) su-v: (clipping all layers) (12:21:57) andyfitz: su-v: yep. either via a parent group or only as applied to the current selection (and not resizing the page as a result) (12:22:30) andyfitz: so really just an easy way to make rectangular or square clippaths (12:22:44) su-v: hmm (12:23:21) andyfitz: not ellipsis, not pineapple shapes, just the shame of the gesture made with the mouse and instant apply with a sane default about whether or not to reduce the canvas size also (12:23:23) su-v: it's useful for beginners, but after having used the 'set clip' command from the context menu once, you'd no longer need it ;) (12:23:46) andyfitz: su-v: I've used inkscape daily since day one and can safely say I'd still use this feature. (12:23:50) andyfitz: if only to reduce clicks (12:25:07) su-v: like 'Object > Clip > Selection', and a shortcut? (12:25:15) su-v: (new) (12:25:42) andyfitz: pretty much. some immediate examples would be (12:26:22) andyfitz: 1.) composing a scene in the default a4 size then wanting an easier way to reduce the view without having to go to the documents dialog (12:28:11) andyfitz: 2.) requiring scenes to be contained within rectangles but not wanting to trim or edit individual objects before making a group of them (eg making a mock-screen for a cellphone illustration and having elements that exeed the current limits of the mock-object they are to be placed on) (12:30:16) su-v: I understand what you want - but it would need a different name imho: cropping has a known meaning (in raster and vector editing), and it is a destructive action (removing unwanted parts), unlike clipping. (same for trimming). (12:30:37) andyfitz: I use that latter feature all the time in web mockups. it means I can roughly draw something (like grass or clouds or buildings etc) in a freeform way without worrying about the limits .. and then clip them to the container they are meant to fit in for the overall mockup. if I didn't use clippath I would be doing boolean edits forever.. but at the same time this is almost always done with a rectangle and almost always follows the same procedure that is less than obvious to newcomers (12:31:16) andyfitz: su-v: well you have contributed a great idea to this discussion already... full objects outside of the crop area can be deleted to save filesize (12:31:53) andyfitz: and that would be more or less cropping (though not exact along the lines like a boolean op (12:32:30) andyfitz: as an option, that would be pretty useful for removing the scrap (12:32:36) andyfitz: and keeps the concept of cropping intact (12:33:05) su-v: how would you treat groups? (12:33:37) su-v: if a group has objects inside, overlapping and fully outside the clipping area: do you keep the group? (12:33:43) andyfitz: su-v: the default would be a parent group of all things. do you mean in the context of deleting the scrap objects ? (12:33:55) su-v: or parse the structure and test each object inside each group? (12:34:14) su-v: yes, in the context of deleting objects (12:34:43) andyfitz: suv, if those objects are in a group, they should stay. if they are at the base level they should go. some objects won't be within the crop view but overlap. wed need to use bbyaks line selection code to capture them before the group so we can delete the rest (12:35:26) andyfitz: so it's a 3 phase selection procedure (12:36:09) andyfitz: 1. bounding box 2. ) line select along the outline 3.) rect creation .. all using the same XY coords issued in the users command (12:36:34) su-v: https://bugs.launchpad.net/inkscape/+bug/168627 has an interesting discussion about cropping vector drawings (on the topic of export, but the issue is the same or close) (12:36:34) andyfitz: after 1 and 2 we perform a parent level group (12:37:00) andyfitz: then we can delete the other parent level objects that aren't part of the group (your filesave) (12:38:21) andyfitz: if an object is in a group but off-canvas, id say it should stay. things would get messy otherwise (12:38:44) andyfitz: also there are some other simple rules to follow (never delete the master object of a <use> within the group (12:39:12) andyfitz: anway I've got to go back to work (12:39:23) andyfitz: just popped in to seed the idea, not champion it
peace!
Andy
On Wed, Oct 13, 2010 at 12:10 PM, Andy Fitzsimon <andrew@...420...> wrote:
G'day everyone,
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... Also, it would be easy to have a rule that crops from the selection (if things are selected) by skipping that last resize page and only grouping the already selected stuff.. maybe attached as a mode of the default selector tool from the parent toolbar
My thinking is that right now creating clippaths is a weird concept for new-to-vector users, but almost everyone gets the idea of cropping
This could be a very achievable GSOC feature if someone is willing to mentor it..
Personally, I can see how much simpler it would be rather than drawing rects and making a weird selection every time i want to crop. to new users, this workflow is not obvious
What are the thoughts here?
-- Andy
On Wed, 2010-10-13 at 12:10 +0200, Andy Fitzsimon wrote:
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...
If you presented a crop tool to me, I would expect that after cropping, all the stuff outside the crop area is gone. So more like a boolean operation.
Why would Resize Page be part of it? You might want to confine elements to a rectangle that doesn't fill the page. In some cases, you might not care one bit that shapes extend outwards of the page; you use the page as clipping area, but stay flexible.
Currently, if a user clips something, he knows it is clipped, as that's explicit. He wouldn't with a cropping too, necessarily.
My thinking is that right now creating clippaths is a weird concept for new-to-vector users, but almost everyone gets the idea of cropping
Lots of things might seem weird if you're new to vector graphics. Initial hurdles become so insignificant further down the road, where getting stuff done in the most efficient way is what counts.
With clipping we have a flexible tool that allows all kinds of shapes, not just rectangles. Results are reversible/tweakable. It's an explicit operation with no abstraction.
In comparison, what you propose seems to me like a one-trick pony that wraps existing functionality and leads to a situation where the user either has to find out that a cropped area is clipped, thus it can be released, or where you have to wrap that, too, with an "uncrop".
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. 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.
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.
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"?
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
On 14 October 2010 18:09, Martin Sucha <martin.sucha-ml@...2313...> wrote:
- 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.
2 clicks (resize page, hide off-page) is better than the current situation, yes :)
2010/10/14 Martin Sucha <martin.sucha-ml@...2313...>:
- 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.
Definitely a good idea. I had that in mind for some time. However, we should think about this carefully so it doesn't interfere with normal editing. We could move or copy some of the page stuff from Document Properties to the toolbox that tool, e.g. fitting to selection.
Regards, Krzysztof
Well, I'm a user, and when I see a crop tool, I expect something that crops, which is defined as "cut short", not hides with a mask. You are thinking like a developer - what would be easy to implement - and not like a user - what would I use it for. What you are describing is barely a small script addon, not a tool. Its functionality can be easily reproduced using the already existing tools: pages can be resized to a selection from the document properties dialog, so just create a rectangle in the desired size and press that button. Yes, you are saving some mouse clicks - but the crop you are suggesting won't be used more than once per document - once it's done, the document would become very difficult to edit. You are saving at most a few more clicks once every few days.
Now, that doesn't mean that I think Inkscape SHOULD have a crop tool. As you yourself probably think, a Boolean operation on each and every element that intersects the border might be slow, prone to errors and will destroy (i.e. convert to path) shape and text objects. And of course there is no way to crop filters... And most importantly I just don't see it as a very necessary tool.
Nevertheless, If we look at other vector apps, you will find that a crop tool has been implemented as a boolean operation tool - in Corel Draw: http://www.insidegraphics.com/corel_learning_tools/corel_crop_tool.asp
Illustrator Crop area tool does something else entirely - it defines export areas and does not hide or drop the area outside the crop during editing. http://www.adobe.com/designcenter/video_workshop/html/vid0213.html
If you want a page resize tool, just call it a page resize tool. you can add and optional "mask everything to page" check box in the dialog, but I promise you it won't see a wide use.
I agree and disagree.
Crop means to cut - plain and simple. Anything else will be confusing.
Don't call it a crop tool if it only clips/masks. Call it "Quickmask" or "Page Mask" or some such...
However, I definitely think this sort of thing can be hugely beneficial - however, I think it's more appropriately thought of in terms of viewing a document as it should print (i.e., if you're designing for print or some other use which only uses the page, a quick way to hide stuff on the scratch space and then unhide again would be invaluable). In this way, it would make most sense to me on the main toolbar (close to the zoom functions since it's a view mode, though separate since it's a bit different).
However, the issue is whether one wants to use this as a permanent part of the document and, therefore, if it should be more than just a view mode (an actual mask, for example) and so whether the main toolbar would be the correct place.
Maybe this is a different enough concept to not really be in the same discussion, however...
JF
On 10/16/2010 08:10 AM, Michael Grosberg wrote:
Well, I'm a user, and when I see a crop tool, I expect something that crops, which is defined as "cut short", not hides with a mask. You are thinking like a developer - what would be easy to implement - and not like a user - what would I use it for. What you are describing is barely a small script addon, not a tool. Its functionality can be easily reproduced using the already existing tools: pages can be resized to a selection from the document properties dialog, so just create a rectangle in the desired size and press that button. Yes, you are saving some mouse clicks - but the crop you are suggesting won't be used more than once per document - once it's done, the document would become very difficult to edit. You are saving at most a few more clicks once every few days.
Now, that doesn't mean that I think Inkscape SHOULD have a crop tool. As you yourself probably think, a Boolean operation on each and every element that intersects the border might be slow, prone to errors and will destroy (i.e. convert to path) shape and text objects. And of course there is no way to crop filters... And most importantly I just don't see it as a very necessary tool.
Nevertheless, If we look at other vector apps, you will find that a crop tool has been implemented as a boolean operation tool - in Corel Draw: http://www.insidegraphics.com/corel_learning_tools/corel_crop_tool.asp
Illustrator Crop area tool does something else entirely - it defines export areas and does not hide or drop the area outside the crop during editing. http://www.adobe.com/designcenter/video_workshop/html/vid0213.html
If you want a page resize tool, just call it a page resize tool. you can add and optional "mask everything to page" check box in the dialog, but I promise you it won't see a wide use.
Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I think I understand this function, but not so much the purpose of it.
Trying to think about some scenarios where this functionality would be purposeful. (if you have some I am not aware of, please let me know)
1. to have a glance on the final work without the unwanted 'leftovers'. InDesign has a nice 'print view' quasi-mode, like Joshua mentioned. One keystroke (W) hides all the guides, hides everything outside the page, shows only what will be printed. Click W again, you're back 'in the workshop'. Is something like that what you had in mind? 2. a quick finalizing cleanup. In that case, a selection script would maybe be more appropriate, I think.
In both cases, I have a feeling that a function like that would not be a good candidate for a 'tool'. Moreover, If I have understood correctly the discussion above, I have some practical questions:
About the page resizing... What would be the practical purpose of having a page scaled to fit the graphics? (why not the other way around?) How is a resulting page used in the workflow? (it would be a non-standard page in most cases, right?) How would we define the parameters for the generated page? (would there be bleed, inset, outset, margins, ...?)
About the cropping... The need for this aspect is clearer to me. Especially if it allows the user to use any of the path editing/creating tools to define the crop. Is there a way to achieve the same purpose without being destructive? (the artists often go back and forth in their workflow)
Alex
On 10/17/10, Aleksandar Kovac wrote:
- to have a glance on the final work without the unwanted 'leftovers'.
InDesign has a nice 'print view' quasi-mode, like Joshua mentioned. One keystroke (W) hides all the guides, hides everything outside the page, shows only what will be printed. Click W again, you're back 'in the workshop'. Is something like that what you had in mind?
We already have two different functions with slightly different behaviors for that has are long due to be merged.
Moreover, If I have understood correctly the discussion above, I have some practical questions:
About the page resizing... What would be the practical purpose of having a page scaled to fit the graphics? (why not the other way around?)
I'm sorry if it sounds like Captain Obvious talking, but the practical purpose is to have a page where graphics fits it. You need it for both web graphics and for text documents (yes, Libre Office now is shipped with SVG importing plug-in).
Alexandre Prokoudine http://libregraphicsworld.org
On Sunday 17 October 2010 05:03:23 Aleksandar Kovac wrote:
I think I understand this function, but not so much the purpose of it.
Trying to think about some scenarios where this functionality would be purposeful. (if you have some I am not aware of, please let me know)
- to have a glance on the final work without the unwanted
'leftovers'. InDesign has a nice 'print view' quasi-mode, like Joshua mentioned. One keystroke (W) hides all the guides, hides everything outside the page, shows only what will be printed. Click W again, you're back 'in the workshop'. Is something like that what you had in mind? 2. a quick finalizing cleanup. In that case, a selection script would maybe be more appropriate, I think.
In both cases, I have a feeling that a function like that would not be a good candidate for a 'tool'. Moreover, If I have understood correctly the discussion above, I have some practical questions:
About the page resizing... What would be the practical purpose of having a page scaled to fit the graphics? (why not the other way around?) How is a resulting page used in the workflow? (it would be a non-standard page in most cases, right?) How would we define the parameters for the generated page? (would there be bleed, inset, outset, margins, ...?)
About the cropping... The need for this aspect is clearer to me. Especially if it allows the user to use any of the path editing/creating tools to define the crop. Is there a way to achieve the same purpose without being destructive? (the artists often go back and forth in their workflow)
Alex
A customer sent me a book cover that was placed on the LSI template. The LSI template is always 15 x 13 inches. The book cover proper is placed in the upper right corner offset by a fraction of an inch towards the center. To work on the cover proper (rejected by LSI) I need to cut away all the extra space and reduce the document to e.g., 13.8 in x 9.25 in, the actual dimensions of the cover. In Gimp I just click on the crop tool, draw a rectangle over the area to be kept and click on the area. The unwanted stuff goes away. The bad news is that the result, like all Gimp results, is bitmapped.
I recognize that this is simpler with bitmap as compared to vector but it should be doable.
The undo editing function should be able to restore the status quo ante if the history stack is properly maintained.
On 10/16/10, Michael Grosberg wrote:
Its functionality can be easily reproduced using the already existing tools: pages can be resized to a selection from the document properties dialog, so just create a rectangle in the desired size and press that button.
And in many cases it will lose you pixel grid alignment that you carefully constructed :)
Alexandre Prokoudine http://libregraphicsworld.org
On Mon, 2010-10-18 at 11:25 +0400, Alexandre Prokoudine wrote:
On 10/16/10, Michael Grosberg wrote:
Its functionality can be easily reproduced using the already existing tools: pages can be resized to a selection from the document properties dialog, so just create a rectangle in the desired size and press that button.
And in many cases it will lose you pixel grid alignment that you carefully constructed :)
Hmm, I usually turn the grid on and snap-to-grid, zoom in and adjust the rectangle to the grid while making sure it covers everything it should. Coordinates and width/height in the toolbar also help. Sometimes easier to use two rectangles for the top left and bottom right corner.
Though I didn't figure that out immediately and created more work for me at first :}
I wouldn't mind a "resize page to selection, but adhere to current pixel grid" feature, but the document dialog is already crowded.
Ah, I see, I see...
I'm just trying to figure what's in the heart of this function. To describe the bottom line... Is the following correct?: -We need a quick way of pointing at a part of the artwork and say: "This is what I need! Gimme that on a page!" -Sometimes we will need the stuff that's peeking inside the desired 'cropping area' included. -Sometimes we do not need the stuff that's peeking inside.... So, we need a way of telling that to Inkscape. (Question: Can these two mix?)... -The 'cropping area' is exclusively(?)/sometimes(?) rectangular. If it's rectangular, pages are easy to make, if not...
-In the future, this functionality should help other workflows, too? (i.e. meet some of the needs for print/press workflow (bleeds, slugs, etc), freehand sketches (framing, reframing, multiple frames... think: comics), technical drawings,...) ... Beh, just to be vile, or for divergent thinking's sake... A Cookie-cutter layer approach! :) A shaded, transparent overlay mode where we can punch and cut 'windows/holes' that show what's underneath. The cutting borders can overlap and, of course, are saved with the file. Punched 'windows' have various settings available for the artists. For example, whether to use or not the objects that are cut by the 'cropping' border of the window, to add the bleed, etc. Each 'window/hole' can be saved/exported as a new page/file.
... Personally, I either layout on paper first, and then define the page I need, or ignore the page completely, finish the graphics and then deal with it somewhere else. I need the pages mostly when preparing for the print, but even then, the trim marks are usually enough for the printing office... That might not be the most common approach at all, tho'... :)
participants (10)
-
Aleksandar Kovac -
Alexandre Prokoudine -
Andy Fitzsimon -
Dave Crossland -
John Culleton -
Joshua Facemyer -
Krzysztof Kosiński -
Martin Sucha -
Michael Grosberg -
Thorsten Wilms