Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Image Cropping with jpeg preview ok but on the page wrong|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
Description Unknown 2003-11-23 13:11:23 UTC
Cropping images no longer works accurately. In 1.0.3 it worked fine with jpeg.
Comment 1 jensja 2003-11-25 23:45:55 UTC
@perelandra: Please post a step by step instructions to reproduce the problem. If possible attach sample files that can be used in conjunction with your description.
Comment 2 Unknown 2003-11-26 21:20:18 UTC
Created attachment 11576 [details] oo writer with image with wrong cropping
Comment 3 Unknown 2003-11-26 21:21:15 UTC
Added Example with wrong cropping.
Comment 4 jensja 2003-11-27 18:04:09 UTC
Tested with build 680 M13 on Win2k. Reproducible problem with the attached document: Actual cropping area differs widely from cropping preview on "Crop" page in "Graphics" dialog. Looking for duplicates.
Comment 5 jensja 2003-12-03 15:49:23 UTC
confirming. set target -> OOo 1.1.1
Comment 6 jack.warchold 2003-12-11 17:17:11 UTC
due the las comment of jensja reassigend to od regressionbug let target as 1.1.1
Comment 7 Oliver-Rainer Wittmann 2003-12-12 10:41:03 UTC
OD->THB: Please take over. Debug hint for Writer: method SwGrfNode::GetGraphicAttr(..) in /sw/source/graphic/ndgrf.cxx, and method SwNoTxtFrm::PaintPicture(..) in /sw/source/doc/notxtfrm.cxx BTW, cropping in Calc doesn't function at all.
Comment 8 thb 2003-12-15 11:46:27 UTC
Hm, looks like a problem in the (shared) crop dialog. Will have a look.
Comment 9 thb 2003-12-15 17:42:26 UTC
Hm. It now looks like the behaviour for _linked_ graphics is correct. KA once fixed a problem in SvxBrushItem::DoneHdl_Impl, forcing to load JPEGs without logical size specifically for Writer (internal bugid 106763). There are several other places in sw which call ImportGraphic without that flag, have to check that with the writer folks tomorrow. I cannot reproduce the problem with Calc, my OOo1.1 final behaves correctly.
Comment 10 thb 2003-12-16 13:29:58 UTC
THB->OS: As discussed, please have a look at the crop dialog's usage of SvxBrushItem. The behaviour of the SvxBrushItem is kinda fixed, to remain compatible with old documents.
Comment 11 stefan.baltzer 2003-12-16 14:44:09 UTC
SBA: Target set to OOo 1.1.2
Comment 12 Oliver Specht 2003-12-19 13:10:48 UTC
Comment 13 thorsten.ziehm 2004-03-12 10:26:54 UTC
Because of limited resources it is not possible to fix this problem in OOo1.1.2. We decided to set this task to OOo2.0.
Comment 14 andreas.martens 2004-06-17 15:07:11 UTC
Because of a shortage of resources we have to retarget this issue to OOo later.
Comment 15 greyham 2008-03-15 05:29:05 UTC
This problem still exists in OOo 2.3. I came across it using a different JPEG image. It only occurs when the image is inserted as a link. If the image is inserted into the document without using a link, cropping works as expected. It works correctly in both cases if the image is a GIF, and also works correctly with other JPEG images. It looks like it's related to the image dimensions or resolution being miscalculated. If you open the attached document in cropping_problem.zip, go "break link", and reopen the Picture->Crop panel, the "Original Size" and "Scale" values change, the cropping region in the preview changes, and aspect ratio of the picture in the document is all wrong; but now that the link is broken, cropping starts working sensibly. I also notice that when the document is first opened, "Read Error" appears in the document window very briefly before the image appears. Perhaps the initial attempt to read the image dimensions is mucking up somehow.
Comment 16 greyham 2008-04-06 12:41:12 UTC
I've just been having a look at this problem. It only happens with JPEG images which have an explicit resolution in them (i.e. jpeg_read_header returns with a cinfo.density_unit != 0). These JPEGs are commonly generated by scanners. It appears that when an image is inserted as a link, its dimensions are remembered in ImpGraphic::maEx in Pixels (MAP_PIXELS). When it is inserted without using a link, its dimensions are remembered in hundredths of a mm (MAP_100TH_MM). I haven't yet worked out where in the code this distinction is made, or whether this behaviour is correct. When the Picture dialogue box is opened, SvxGrfCropPage::GetGrfOrigSize is used to calculate the original image size in TWIPs. In the former case where the dimensions have been remembered in pixels, SvxGrfCropPage::GetGrfOrigSize calls OutputDevice::PixelToLogic to do the conversion; but it uses the resolution of the output device (96 DPI) rather than the original image resolution so it gets the wrong answer. The file landschaftsgartner_8.jpg in the attached .zip for example has a resolution of 200 DPI which is why it triggers the bug. The behaviour is also wrong in OpenOffice 2.0.4 on Debian GNU/Linux Etch; it's not just a Windows problem.
Comment 17 Matthias Basler 2008-12-21 21:09:24 UTC
I ran into this issue today with OOo3.0 m9 (!) on WinXP SP2. How can it be that an image cropping bug hasn't been fixed for years? Do you need more reproducable examples? What I found today were two (possibly related) effects: - Cropping an image on the left side would show a correct preview, but on the page the image would be stretched to the left into the (correctly calculated) space. Of course the image aspect ratio was NOT supposed to change. - After I set an image to "Original size" it would ignore any cropping applied, even if deleted and reinserted. Sorry to say this, but the crop function seems so buggy to me it is almost unusable for an everyday user.
Comment 18 greyham 2008-12-21 23:11:12 UTC
The original attachment shows the problem quite convincingly; in fact, any high resolution image from a scanner will do so. Digital camera images on the other hand generally will not, because they lack an explicit pixel density. What we need is someone who understands the OOo imaging model well enough to work out what's going wrong and how to fix it. A workaround in the meantime is to avoid using links when importing JPEG images from scanners.