To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=22753
------- Additional comments from [EMAIL PROTECTED] Sun Apr 6 11:41:12 +0000 2008 ------- 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. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
