When one is physically arranging pieces of paper or other printed material on a page or drawing board (i.e. not on a computer, not with LibreOffice) - sometimes one cuts the graphical items for the purposes of placement and combination. One kind of cut is cropping a frame around a part of the piece of print; another one is cutting up a single printed piece into multiple smaller pieces. In LibreOffice Draw, and for images, we support the first kind of cutting-up on an image, via the Crop command (on the image's context menu). But - we don't support using a single line to make a cut. I suggest we have this support. As for the UI for this - there could be multiple approaches here. * One option is to support dragging a horizontal or vertical line (or both?), so that the complexity of the operation is limited - just like with cropping, we don't support drawing an arbitrary path along which to crop. * Another possibility is to let the user freely draw a line (with Shift allowing them to make the line straight, even though users are more likely to want to cut along one of the main axes). * A third option is to require an actual line-segment object to use as the guide for cutting; but this is very much unlike how we crop.
Use the command Crop to switch into this mode and you can cut off the images from the edges.
(In reply to Heiko Tietze from comment #1) > Use the command Crop to switch into this mode and you can cut off the images > from the edges. I don't want to cut off parts of the image, I want to keep all of the image, but as two separate images.
Out of scope for an office suite and a vector drawing tool. You have to duplicate the raster graphic and crop both sides from left and right. If you often have to process images I suggest to create an extension or process the content with a specialized tool like GIMP. => WF
The slice needs to split the image into its two parts, resulting in two new objects (bmps, or even draw objects?). Horizontal or vertical would be obvious first efforts. Then a rotated slice line. But is this really in scope to do internally? Lots of utilities (GUI and CLI) for doing this already, and were we to adopt an external lib to do it internally, e.g. Imagemagick, that entails down system dependencies.
I'd like to get Armin's and Tomaž's take on its complexity and appeal. And would need some design parameters. For starters, would have to agree once we slice it the original image is destroyed and not saved to the archive! It becomes "native" BMP held in ODF at resolutions we control and convert as we need to when saving.
(In reply to Heiko Tietze from comment #3) As I can do this using the instructions you gave: > You have to > duplicate the raster graphic and crop both sides from left and right. Then surely it can't be > Out of scope for an office suite and a vector drawing tool. can it? > process the content with a specialized tool like GIMP. A tool like GIMP would not, by design, create two separate edited images from a single image. It may create layers, selections, masks etc. - and of course you can duplicate and image and cut the two complementing pieces - but it is really not the right tool for the job. A vector graphics drawing app - is. Now, one could argue about whether this merits its own command, but definitely in scope. (In reply to V Stuart Foote from comment #4) > The slice needs to split the image into its two parts, resulting in two new > objects (bmps, or even draw objects?). This is not a trivial question actually. If it's just two images, than the slicing must be along a vertical or horizontal line. If any line is allowed for the slicing, then the result would either be an image with some trapezoidal transparent region, or a drawing object which uses the image as its area fill (apologies for the use of inexact terminology). > But is this really in scope to do internally? Lots of utilities (GUI and > CLI) for doing this already, Actually - I don't think so. ImageMagick can do it, because it's scriptable and supports multiple write command, but that's more like programming that using a utility. GUI - not sure you'll find many apps/utilities which are not single-file transformers. > adopt an external lib to do it internally, For the vertical or horizontal slicing only - we don't need anything; like Heiko noted, at worst it means duplicating and cropping complementing regions.