Description: I always want to use Draw for some very basic image editing (combined with some drawings). Yes, Draw is a vector graphics drawing tool.. I know. Anyhow, cropping bit a disaster. I often only want to have a part (say the center part) of an image. It's quite a hassle doing that with the cropping tool. It's far easier to drag a selection around the part I want (and cut & paste). Except, Draw doesn't have selection tool. A basic one will really do. Put it on the image toolbar Steps to Reproduce: 1. insert an image 2. Try to crop the inner part Actual Results: Hassle with the crop tool Expected Results: Selection tool (cut/paste) Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 4501a0ba623ad61c5a4e0b807da2e96f0e4ce82c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
@Regina Any opinion on this? You do know a lot more about Draw. Or should i go to the UX department
Thanks for reporting this, Telesto. I have changed the severity of the bug report to "enhancement" to reflect the nature of the report.
(In reply to Telesto from comment #1) > @Regina > Any opinion on this? You do know a lot more about Draw. Or should i go to > the UX department I think, that is beyond an office-suite. It would require code parts for image processing. Cropping only needs to hide some parts from the view. But I can image to extend the cropping tool to something like "Crop to the dragged rectangle". Or implement contour-polygons in Draw/Impress too.
Add a shape on top of your image, select both and use Shape > Intersect to create a "special" crop. There are plenty of tutorials for these merge functions.
(In reply to Heiko Tietze from comment #4) > Add a shape on top of your image, select both and use Shape > Intersect to > create a "special" crop. There are plenty of tutorials for these merge > functions. That does not work. It sets the image as background and scales it down without keeping ratio, so that is fills the rectangle. I think it is a valid request and can be solved by my proposals in comment#3.
(In reply to Regina Henschel from comment #5) > That does not work. It sets the image as background and scales it down > without keeping ratio, so that is fills the rectangle. True, worked in the first test scenario that might have been wrong. But anyway, such an option "crop" doing the inverse of subtract would be handy and very flexible (eg circular or polygon crop). Could also imagine a z-order sensitive subtraction. What do you think?
Let's have a technical view on the problem: "crop" from a user point of view, can have three technical realizations: A) The main element is a shape. The image is set as fill-image. There exist several attributes to determine zoom and section of the image. B) The main element is an image. It has an associated crop-polygon. C) The main element is an image. It has a clip-rectangle. B) and C) can be combined. A) That is already possible in all modules. It corresponds roughly to the tool "crop to shape" in MS Office. The UI in LibreOffice is the area-dialog, its Bitmap part is terrible. When intersect a shape with an image, the current default is "stretch". I think, that a different default, which keeps the image size, would be better. B) That is currently only available in Writer. It needs a lot of points to get a rounded outline, but a rectangular outline is easy. The object has still its original size, only that parts are hidden. That conflicts with the restricted canvas in Writer when moving the object. C) That is the way "crop" is done in LibreOffice in all modules. The clip-region is always rectangular. Using the handles or entering numeric values, both require many steps. Determine the area by dragging a rectangle would indeed be a useful tool. CSS uses a clip-path, including curves, but that is not yet specified in ODF. It is worth implementing this CSS feature and bringing it to ODF, because it is needed for SVG anyway and would be better than extending B) to Draw /Impress. So I would go with the mentioned improvements for A and C.
Wrong term in B) Not "clip-polygon" but "contour-polygon"
(In reply to Regina Henschel from comment #7) > When intersect a shape with an image, the current default is "stretch". I > think, that a different default, which keeps the image size, would be better. Not possible to set in the UI, right? So we have to change the code. > CSS uses a clip-path, including curves, but that is not yet specified in > ODF. It is worth implementing this CSS feature and bringing it to ODF, > because it is needed for SVG anyway and would be better than extending B) to > Draw /Impress. Sounds like a plan :-).
We want to unify common (draw/impress/calc) svx graphic and writer-specific graphic, that has contour-polygon support. So yeah, adding contour-polygon support for common graphic would make most sense.