In DRAW clicking 'Crop' icon provides crop control marks, so I believe this one is more or less INVALID.

@sasha:
If that solution is not enough for your needs, please describe more exactly what you need. A simple reference to a pixel image editor is not sufficient.

In Draw it works perfectly. Thanks for this improvement.
But in Writer I can not find this tool. And I work mainly in Writer.

(In reply to comment #1)
> In DRAW clicking 'Crop' icon provides crop control marks, so I believe this one
> is more or less INVALID.

The crop tool is working perfectly in Draw and Impress, but it is completely missing in Writer (correct me if I'm wrong). That is really annoying, because every time you want to insert an excerpt from an image into your document you first have to crop the original image using another program like Gimp.

There is in fact a crop tool in Writer if you open the image's properties. But that one is quite useless because you have to define the crop area by entering dimensions instead of simply using the mouse, which would be a much more intuitive approach. In addition, the existing tool is very inaccurate because you have to rely on a very small preview image.

Isn't there a possibility to simply transfer the crop tool from Draw and Impress to other parts of the suite?

By the way: Did you know, this feature has been requested for OOo since way back in 2002? You can find the other project's thread here:

http://openoffice.org/bugzilla/show_bug.cgi?id=3545

After almost 10 years, adding this quite basic functionality should really be targeted seriously...

*** Bug 38920 has been marked as a duplicate of this bug. ***

Is it in plans of 3.5 release?

yes, this bug still persists with the 3.5.0 beta1 or beta2
prereleases and this feature needs to be implemented.

It's a pity that this isn't implemented yet. I'm currently helping a small company on their decision what office-suite they will use from March on.

Currently the only reason why they are not able to use libreOffice is that there's no crop tool in writer. Their main procedure includes inserting a lot of images into documents and croping them a bit. Using a full image manip. program or the sliders in the dialog box would mean large decrease of efficiency.


From outside, copying the implementation from LO-Draw to LO-Writer doesn't seem to be much work. I haven't looked into the code yet. Is there someone who can really estimate, how much effort it will be to port this from LO-Draw to LO-Writer? Is it worth to create a build environment etc.?


Thanks for all the good work!

@ Cedric
Please, see on comment 12

(In reply to comment #12)
> From outside, copying the implementation from LO-Draw to LO-Writer doesn't seem
> to be much work. I haven't looked into the code yet. Is there someone who can
> really estimate, how much effort it will be to port this from LO-Draw to
> LO-Writer? Is it worth to create a build environment etc.?

I looked a bit into the code:

First of all, a crop button can be added to writer by editing 

(draw) http://cgit.freedesktop.org/libreoffice/core/tree/sw/uiconfig/swriter/toolbar/graphicobjectbar.xml

similar to

(writer) http://cgit.freedesktop.org/libreoffice/core/tree/sw/uiconfig/swriter/toolbar/graphicobjectbar.xml


The button is then always deactivated and further editing is needed.

The files

(draw) http://cgit.freedesktop.org/libreoffice/core/tree/svx/source/tbxctrls/grafctrl.cxx
and
(writer) http://cgit.freedesktop.org/libreoffice/core/tree/sw/source/ui/shells/grfsh.cxx

are quite similar.

There are blocks labeled "SID_ATTR_GRAF_CROP" in SvxGrafAttrHelper::ExecuteGrafAttr() and SvxGrafAttrHelper::GetGrafAttrState() in the first file. 

The corresponding functions SwGrfShell::ExecAttr() and SwGrfShell::GetAttrState() in the second file have quite similar structure but have different number of parameters. If I just copy the Crop-blocks from draw to writer there are a lot of errors of course.


Is there somebody who knows how to translate the draw-part into the writer-part? Is translating draw into writer the correct approach or shouldn't writer and draw use about the same functions when handling graphics?

Is there some further work to do that I missed?

@ wepmaschda@gmx.net
Thanks for investigating office internals

> Is there some further work to do that I missed?
Try ask here:    irc://chat.freenode.net/libreoffice-dev

About version: it should indicate most old version of office where bug appears for developers can more easy find source of problem (by which patch bug added)

have you ever tried the CropOOo extension?

http://aoo-extensions.sourceforge.net/en/project/cropooo

(In reply to comment #16)
> have you ever tried the CropOOo extension?
> 
> http://aoo-extensions.sourceforge.net/en/project/cropooo

Oh! It works in Writer! The description says "This extension provide an easy way to crop images in Draw or Impress." but after installing I have an icon also in writer and it works! 

It's just a bit weird that you have to press Enter for applying the crop. Do you know if it's still developed and if this can be fixed (applying the crop after mousebutton is released)?

The CropOOo extension is not a good solution and their is no development since 2007. 

The disadvantages and problems:

UNDO (ctrl-z) doesn't seem to work right. So you have only one trial to crop.
To cancel the changes I had made and close the document to undo the crop.

When cropping a picture, after pressing Enter, the left and top offset is incorrect, and CropOOo adds margin as big as the graphic's distance to the top-left corner of the current page.

Even when I move the picture to the top-left of the page (using Anchor To Page), the picture's dimension is not changed by CropOOo, leaving white space around the graphic.

I completely agree with Peter Stolz. Meanwhile plugin can be a temporary replacement but definitely not a solution.

If i had the time and skills, I would look into the code and try to fix this. Now i instead work with the swedish translation. Anyway: THIS IS IMPORTANT! Trying to convince people to switch from MSO to LO works fine until they try to crop an image, it is totally embarrassing to show them how to do it in writer.

Please update the bug if any progress is made!

Why not include it in upcoming 3.6 release?

This is an enhancement request, so improbable that it can be a MAB, I remove that relation.

We should not limit that feature to raster graphics and Writer, should also be available for vector graphics (wmf) in other applications (Calc)

@Thorsten:
Might be an EasyHack because the code already exists fro DRAW?

Yeps, and with code pointers already. Though not a trivial exercise.

*** Bug 58682 has been marked as a duplicate of this bug. ***

I am pleased with libreoffice, but I am agree with you in having a crop tool in writer. I think it would be more usefull, and a fast, easy way to crop images for people who usually add images to their texts. I hope to see this tool implemented soon. 

Thanks for help and work =)

It's useless to wait. Two years passed, many duplicate tickets have been opened, we are still there.

Hi,

I know it's not really productive to moan in bug reports, but you might want to take a look at the second paragraph in http://blogs.technet.com/b/office2010/archive/2010/02/01/office-2010-improvements-for-cropping-pictures.aspx

In particular "Cropping was overwhelmingly the most-used bit of editing used on pictures, so one of the first things we started work on was making cropping an easier-to-use and more powerful tool."

That matches my experience, but that assessment is obviously backed by tons of telemetry data from millions of users.

I'm not really advocating for the grey-out style of cropping (in my opinion it was a regression rather than an improvement), but visual cropping of any kind is a very important feature.

(In reply to comment #27)
> I know it's not really productive to moan in bug reports, but you might want
> to take a look at the second paragraph in
> http://blogs.technet.com/b/office2010/archive/2010/02/01/office-2010-
> improvements-for-cropping-pictures.aspx
> 
This is marked as an easy hack, code ptrs are available - we'd gladly mentor someone willing to tackle this. It could be you - or someone you know!

Maybe I can try this!

I believe this is more easy than solving a great issue, so if you guys could guide me, maybe I can help :)

I'm looking at code pointers now!

@Marcos Souza

there's already a guy working on this (Philippe Jung) who recently posted a message on the Dev mailing list.

I told him to get in touch. maybe you can help him

Are there any developments in getting a crop button in Writer?

adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details

*** Bug 70482 has been marked as a duplicate of this bug. ***

Restricted my LibreOffice hacking area

I have just found this one! relatively new to Linux and LO and finding things as I need to use one.
Really, I'm shocked at the lack of a cropping tool. This is busines critical functionality - try writing a training manual without it. Anyone evaluating a switch from MS office to LO will find this and it will immediately be a shop stopper. Amazed that is it taking so long to fix

(In reply to comment #35)
> ...
> Really, I'm shocked at the lack of a cropping tool. 
> ...
> Anyone evaluating a switch from MS office to LO will find this and it will immediately be a
> shop stopper. 

in the meantime you can add that missing function using the CropOOo extension which in compatible with LibO too.

http://aoo-extensions.sourceforge.net/en/project/cropooo

*** Bug 48324 has been marked as a duplicate of this bug. ***

Hi, bug #61991 seem duplicate this one

*** Bug 61991 has been marked as a duplicate of this bug. ***

Issue 61991 is only partially a duplicate of this one.  This issue has dealt exclusively with adding a cropping tool to Writer.  Issue 61991 (and 74099, which I created and which was marked as a duplicate of 61991) deal with that AND with adding the same capability to Calc. 

Because of that, and because of Bjorn's comment (in 61991) about "writing a short rationale", I decided to copy my statement from issue 74099 below.

--- copied from 74099 & 61991 ---
I have long found that when I need to print something from the computer screen, the easiest way to do it was to hit PrintScreen, then paste it into an Excel spreadsheet, then crop and resize it till I have what I want.  For instance, I frequently want to crop & overlay two Google Maps screenshots so they fit together.  Or save an entire year of cropped screenshots of payroll tax confirmation screens on the same spreadsheet page.  (For me, Excel does these things far more easily than Word or Paint.)

For years I've occasionally tried the same thing using first OpenOffice Calc 3.x and now LibreOffice 4.0.x, and found that it is much more difficult.  Calc brings up a window with measurements you can change, and its own small snapshot of the graphic that shows where you are moving the borders to.  It works, but it is hard to get it just right.  You cannot see it well, and must repeatedly invoke the tool, change the measurements, and quit the tool to see what you've really got.  It takes several iterations to get it where you want it.

Excel's cropping tool (at least as far back as Excel 97) allows the mouse to grab the handles on the graphic's edges and drag them where you want them, which is far easier both to see and to do.

PLEASE add a mouse tool that can be used directly on the image in the spreadsheet.  The cropping icon could still bring up the window (for those who prefer it), and then a button in that window could replace the window with the mouse tool.
--- end of copy ---

Thanks,
Tim

(In reply to comment #36)
> (In reply to comment #35)
> > ...
> > Really, I'm shocked at the lack of a cropping tool. 
> > ...
> > Anyone evaluating a switch from MS office to LO will find this and it will immediately be a
> > shop stopper. 
> 
> in the meantime you can add that missing function using the CropOOo
> extension which in compatible with LibO too.
> 
> http://aoo-extensions.sourceforge.net/en/project/cropooo


thanks. I tried installing this and did so successfully, but it doesn't seem to have done anything. There is no crop tool visible in the drawing tools, nor by right clicking on the image I need to crop. Am I doing something sill here?

@Wayne
you should see it's icon under "Tools/addons"

thanks - I can see it now! That will mitigate the issue I think, but I still think this should standard functionality within Writer. Thanks again.

Created attachment 107061 [details]
Image showing the crop tool on Impress and not on Writer

This bug still hasn't been corrected...

(In reply to comment #44)
> This bug still hasn't been corrected...

When you do not see activity on a bug, you can assume that it is not being worked on currently. There is no need to spam everyone with constant reminders, which will not speed up your request - unless you pay someone, of course.

If anyone is not working on this ... then can I take this issue.. ?
If possible also provide me more code pointers to add crop option in manu bar and to make it clickable..

Hi Sushil,

I only got as far as figuring out how to add a crop button to the relevent toolbar. I did not get an event to fire to run some code after the button was pressed. You will need to edit this XML file for the toolbar. It's pretty easy to understand: /core/sw/uiconfig/swriter/toolbar/graphicobjectbar.xml.

Since my son was born I don't have any free time to write code. Best of luck! I have assigned the bug to 'default' so you can take it. Cheers.

(In reply to comment #45)
> (In reply to comment #44)
> > This bug still hasn't been corrected...
> 
> When you do not see activity on a bug, you can assume that it is not being
> worked on currently. There is no need to spam everyone with constant
> reminders, which will not speed up your request - unless you pay someone, of
> course.

It appears that my comment sparked people to look at this issue. So no I am not spamming - just bringing it to attention.

*** Bug 88363 has been marked as a duplicate of this bug. ***

(In reply to wepmaschda from comment #14)
> The files
> 
> (draw)
> http://cgit.freedesktop.org/libreoffice/core/tree/svx/source/tbxctrls/
> grafctrl.cxx
> and
> (writer)
> http://cgit.freedesktop.org/libreoffice/core/tree/sw/source/ui/shells/grfsh.
> cxx
> 
> are quite similar.
> 
> There are blocks labeled "SID_ATTR_GRAF_CROP" in
> SvxGrafAttrHelper::ExecuteGrafAttr() and
> SvxGrafAttrHelper::GetGrafAttrState() in the first file. 

So I started looking into this, and I think that SID_ATTR_GRAF_CROP is used when cropping with the dialog, but I don't think it's used when doing an interactive crop. I added debug statements here and there when doing a crop in Draw, and the relevant SID is SID_OBJECT_CROP. Unfortunately this is not used in Writer. I'm able to add a new 'Crop Image' option in the context menu for inserted images in Writer, but then the problem becomes that Writer and Draw don't seem to use the same data structure to insert graphics, and it looks like only the one in Draw supports interactive crop. Details follow:

In Draw, once SID_OBJECT_CROP is sent, eventually what happens is that FuSelection::Activate() sets the drag mode SDRDRAG_CROP on mpView. SdrMarkView::SetDragMode get called. In turns, it calls SdrMarkView::SetMarkHandles(). In that method, there is to test to see if pMarkedObj is an instance of SdrGrafObj. When true, the instance of SdrGrafObj is responsible for "handling crop" (according to the comments). This is true in Draw, but not in Writer. In Writer, pMarkedObj is a SwVirtFlyDrawObj.

I'm stuck at this point. I don't know how to make the SwVirtFlyDrawObj draw the crop handles. Interestingly enough, while the handles are not drawn, the corner of an inserted image are draggable, and the cursor is changed to the cropping cursor. But there is no visible cropping taking place as in Draw.

As a side note, OpenOffice.org has a whole page devoted to an ongoing refactoring of Writer's usage of the Drawing layer at https://wiki.openoffice.org/wiki/Refactoring_of_Writer%27s_usage_of_the_Drawing_layer. I think this may be related.

I would appreciate any pointers on how to keep proceeding with this bug.

Hello,
I tried to work on this bug last year and I had something nearly working. But, during this time, the code base changed (a lot) and I have no time for the moment to rework it. So I would like to share what I found. I will attach the patch "as is" to this ticket. It is not working at all with current trunk.

Basically, you have to use a virtual NbcCrop function on a parent that is common to SwVirtDraw and SdrGraph

I am not going to detail every change I made in this ticket. Please read the patch and if you have any question feel free to ask.

The crop code was in SdrDragCrop::EndSdrDrag. You have to move this code in SdrGraphObj. Now in SdrDragCrop::EndSdrDrag call the crop virtual => getSdrDragView().CropMarkedObj

Now the problems I am facing:
1) cropping code has changed a lot in EndSdrDrag. Mine uses the old code. You will have to adapt it
2) Regarding links, you can also consider Armin Le Grand web page  https://wiki.openoffice.org/wiki/Aw080_documentation. This explains the mathematical logic using transformation matrixes (If you "git blame" the cropping code, this will point to "alg"). If I am not mistaken, these changes come from evolution of OpenOffice merged into Libre Office.
3) I tried to contact alg and his advice is "I would suggest to *not* touch SwVirtFlyDrawObj at all, it's dead code. It's a kind of proxy, try to get the original SdrObject from it and modify that instead. Or better: just tunnel your call to the original object."

Philippe

Created attachment 112751 [details]
A patch that nearly worked but cannot be applied on current trunk

This patch relates to the previous comment

Created poll at https://wiki.documentfoundation.org/Vote_for_Enhancement#tdf.2334555_-_Make_cropping_handles_for_images_.28as_in_Draw.2FImpress.29_available_for_all_LibreOffice_applications

BTW this feature was implemented in Apache OO 4.0 or 4.1, why not to port it to LO?

(In reply to Yan Pashkovsky from comment #53)

 
> BTW this feature was implemented in Apache OO 4.0 or 4.1, why not to port it
> to LO?

Just installed OpenOffice 4.1.1 to check. I have not found such a feature in *Writer*.

Just to recall the expected use case/behaviour (from my point of view):

New writer doc
Insert -> Image -> From file
The image appear in the doc
Click on the image 
-> Image selected
-> Image toolbar appears
Click on a "crop" icon in the Image toolbar.
8 cropping handles appear 
I can click on a cropping handle, drag & drop image is cropped accordingly; cropping mode remains active with visible cropping handles.
I press ESC or outside the image, cropping mode stops.

If later I resize the image, the same part remains cropped.

+1 for crop using mouse. Contrary to other's comment's, crop dialogue doesn't seem to work at all (simply resizes the image along one axis, instead of cropping as understood by e.g. Gimp). Using LO 4.2.7.2 on Ubuntu 14.04.

Sorry for dup mail, took assignation but didn't change status to ASSIGNED.

Patch pushed to gerrit
https://gerrit.libreoffice.org/15541

*** Bug 90902 has been marked as a duplicate of this bug. ***

I propose a crop mode add-on to include crop handles to crop the image using a crop rectanglelike Microsoft Office. 

As you can see in my link (https://bugs.documentfoundation.org/attachment.cgi?id=115146&action=edit), now when you move crop handles on a picture the full picture is shown with the portions outside of the crop area grayed out until dragged into new crop position.

Philippe Jung committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7db7698881f2691b7532a621c469b49830c27c4c

tdf#34555 Moving SID_OBJECT_CROP out of sd

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Philippe Jung committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=80a38d299133823e93ec5c29e8fe5c51771940d5

tdf#34555 add crop features to svx

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Philippe Jung committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b1df1ac809fd6de972a6ed4f638a1ac8d29ba40d

tdf#34555 add to scalc: crop, change img, save img, edit with ext tools

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Philippe Jung committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c4a1663f5d93380268365d35a5581d8065df897

tdf#34555 add crop features to sw

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

So we now have:
- save image
- change picture
- compress image
- edit with external tools
- crop image
in impress, writer and calc

tested under Win8x64 using LibO 5.0.0.0.alpha1+
Build ID: 4048311aae6993357c2d0be1f1968a8c57dd4e85
TinderBox: Win-x86@42, Branch:master, Time: 2015-05-08_23:52:08
Locale: en-US (it_IT)

the new feature works fine in Writer and Calc.
thanks to Philippe Jung who fixed such an old issue coming from the OOo era.

time to say farewell to the good old CroOOo extension that many of us used trough the years as a workaorund of this OOo/LibO missing feature

I's so glad to set status to VERIFIED

This bug fix is mentioned in the release notes of the coming LibreOffice 5.0 (see release notes https://wiki.documentfoundation.org/ReleaseNotes/5.0). Therefore it would be wonderful if this feature really worked well, otherwise it should not be mentioned in the release notes. In the notes it reads:

Crop, change and save an image

tdf#34555 (Philippe Jung)

It is now possible from Format ▸ Image menu, from contextual menu and from graphic toolbar, to Crop an Image with the mouse, to Save an image and to Change it by another image from disk. These functionalities behave like in Impress or Writer. Format menu has been updated accordingly: there is now 
Format ▸ Object entry with Position and Size, Line, Area, Define Text Attributes and Points, 
Format ▸ Image entry with Crop, Edit with External Tool, Change Image, Compress Image, Save Image.

@Mike what does it mean? To crop image via mouse - you should search "crop" in the labyrinth of menus? No one-click way (button on panel)?

(In reply to Yan Pashkovsky from comment #67)

> @Mike what does it mean? To crop image via mouse - you should search "crop"
> in the labyrinth of menus? No one-click way (button on panel)?

As stated in the release note, it is possible from (and it should be verified that it is possible and working from :-) ):
- the Format menu
- the graphic toolbar
- the contextual menu of the image (which is the one I guess users will use most of the time)

(In reply to Mike §chinagl from comment #66)
> Therefore it would be wonderful if this feature really worked well

(In reply to Yan Pashkovsky from comment #67)
> @Mike what does it mean?

@Yan: Don’t worry. Mike is spamming every bug report mentioned in the in-progress release notes with the same comment.

(In reply to Adolfo Jayme from comment #69)
> @Yan: Don’t worry. Mike is spamming every bug report mentioned in the
> in-progress release notes with the same comment.

Please consider my clarifying statement:
https://bugs.documentfoundation.org/show_bug.cgi?id=86138#c13

*** Bug 49676 has been marked as a duplicate of this bug. ***

Can anyone guide me on what is left to be done here? I am a newbie and am willing to take on this.