Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Image Cropping with jpeg preview ok but on the page wrong | ||||||
---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | Unknown <non-migrated> | ||||
Component: | code | Assignee: | AOO issues mailing list <issues> | ||||
Status: | ACCEPTED --- | QA Contact: | |||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues | ||||
Version: | OOo 1.1 | Keywords: | oooqa | ||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows 2000 | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Issue Depends on: | |||||||
Issue Blocks: | 105217 | ||||||
Attachments: |
|
Description
Unknown
2003-11-23 13:11:23 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. Created attachment 11576 [details]
oo writer with image with wrong cropping
Added Example with wrong cropping. 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. confirming. set target -> OOo 1.1.1 due the las comment of jensja reassigend to od regressionbug let target as 1.1.1 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. Hm, looks like a problem in the (shared) crop dialog. Will have a look. 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. 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. SBA: Target set to OOo 1.1.2 . 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. Because of a shortage of resources we have to retarget this issue to OOo later. 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. 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. 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. 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. Reset assigne to the default "issues@openoffice.apache.org". |