Apache OpenOffice (AOO) Bugzilla – Issue 30773
crop ojects larger than the actual page to fit onto the page on import
Last modified: 2013-08-07 14:41:21 UTC
I have a word document with a graphic in it. When the word processor imports this document, the graphic is squeezed small vertically into the space the that word processor thinks the header occupies vertically. I found that I could correct this error by messing around with the header settings: I haven't quite identified which change I made fixed the problem. But the fix is not "permanent" ... each document imported has to have this change applied. Furthermore, when the document is saved back as a MS Word document, the position of the graphic in the header of the resulting document is not correct: in the original it was positioned "halfway down" the header (IE manually centred vertically) in the exported document, it ends up at the top.
(Attaching problem document)
(darn - can't see how to make an attachment now that the original moment has passed!)
Hi IssueZilla has some technical problems at the time which does not allow to attach files. See: http://qa.openoffice.org/issues/show_bug.cgi?id=23650 As soon as this is fixed, please attach a sample doc. Thank you!
I emailed an example doc to es.
Created attachment 16149 [details] Sample doc
ES->MRU: please have a look
from issue 27940: #------- Additional comments from mru Fri May 14 05:03:56 -0700 2004 ------- # #Problems with Graphics in headers has been solved for OO 2.0. Was a conceptional #rebuild in this area. Thus, I changed the summary of this issue. works in 680m45...
I downloaded the mosts recent snapshot of 680 (OOo_680m45_Win32Intel_install) In this version the problem manifests differently, but it is still there. Now, instead of being squashed flat, the graphic is stretched tall.... it actually needs to be _unchanged_ from its native size.
I see. The problem here is that the graphic has to exceed the actual page margins to be scled to the size requested. This is not possible in OOo - graphics cannot exceed page width. So the workaround/solution to your problem is to crop part of the graphic. I rewrite the summary accordingly. original summary "(MS Word Import) Graphics in headers are not sized correctly" This solution could be implemented withoug changing OOo's features. They need not to be enhanced (therefore I keep this as defect, not enhancement), it is just the import-filter that needs to be adjusted. If you think that OOo should be able to place graphics outside the actual page, then please file a seperate issue. Again in short: The document contains a graphic that is scaled. OOo correctly sets the height of the graphic, but limits the width of the graphic to that of the page. This results in a broken aspect-ratio. The import filter should detect that the graphic won't fit onto the page with the scale requested and set appropriate cropping values so the graphic will fit, keeping the desired aspect-ratio.
I forgto to add how to do this by hand: Select the graphic and choose Format|Graphic and do the following: on the crop-tab increase the scale for width to 167% (to match the scale for the height), then place the cursor in the field for the right-crop and press <page-down> (or <arrow-down>, this will set the vaule to the smalles possible value (-> so that the graphic will fit onto the page - it may be necessary to press <page-up> first or to set a value by hand to make the field update accordingly). I will attach a screenshot showing the dialog... Entering the cropping by by hand is of a bit tricky since it referes to the unscaled image, so you have to do math to find the desired value :-)
Created attachment 16263 [details] screenshot of the cropping dialog with the settings to make the graphic look good.
(the top needs cropping as well to place it in the same position as in word. If you need to edit this more often, then I suggest creating a copy of that file and crop that so it can be inserted into OOo without setting cropping values again and again)
Thanks for the feedback, including workaround instructions. I look forward to hearing when I can grab a version with this fixed!
Text frames are not allowed to leave the header/footer/cell/textframe environment of its anchor paragraph. This has been changed for OO 2.0. See issue 11371 for further information (or any other issue which has been fixed by CWS swobjpos02). *** This issue has been marked as a duplicate of 11371 ***
Closed as duplicate.
reopen issue. This is not about leaving the text-area, but leaving the acutal page (sheet). OOo 680m45 cannot do that. Furthermore this issue here is not about textframes, but graphics. Did you add your comment to the wrong issue?
No, I didn't add my comment wrongly. The positioning behaviour of textframes and graphics is based on the same code. Thus, this here has been fixed together with the changes of the frame behaviour for OO 2.0. It looks much better in 680m45 than in 1.1.2, but the graphic is still compressed (horizontally) what I didn't see at first glance.
MRU->BH: Writer does not crop graphics which are wider than the paper sheet. This makes them look compressed like in the attached sample. A cokpatibility mode is needed for this.
I don't see what a "compatibility mode" should do here. Weither OOo should be able to place the objects outside the page, then it would be a whole new feature to OOo (why would you restrict that to a compatibility mode?) or the importfilter could be enhanced to make the imported document look the same as the document in word. OOo does already get the size correctly, so it just need to compute the offset to cropping values (if upper left corner of the image is placed y cm above the page, a top crop of "y cm / scale" needs to be applied, the same for the left border. The right crop is "(image size + horizontal offset - papersize)/scale"
I don't agree that this is an enhancement request. OOo claims to be compatible with MS Word. If MS word copes, OOo should also.
*** Issue 54090 has been marked as a duplicate of this issue. ***
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".