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...

+1 for adding a mouse operated image crop functionality in writer.
thanks

+1. I need either. Would be perfect to see it in next release.

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

+1. Please, do it in the next release. Often necessary function, but the present implementation is very-very inconvenient.

Is it in plans of 3.5 release?

[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

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] [review]
A patch that nearly worked but cannot be applied on current trunk

This patch relates to the previous comment