Issue 123295 - Image Clipping (JPG) lost on PDF export (images uncompressed)
Summary: Image Clipping (JPG) lost on PDF export (images uncompressed)
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: save-export (show other issues)
Version: 4.0.0
Hardware: PC Windows 7
: P3 Major (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact: zhaoshzh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-19 14:05 UTC by burninleo
Modified: 2017-05-20 10:35 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.0.1
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description burninleo 2013-09-19 14:05:12 UTC
To reproduce this problem
- import a JPG image into a page of a presentation
- clip this image (left, right, bottom in my case)
- export to PDF with lossless compression

Result: Clipping is lost, the whole image is shown

Similar to bug https://issues.apache.org/ooo/show_bug.cgi?id=74402, but for a different image file format and encountered in current release 4.0.0

As soon as some resampling is enabled in PDF export, clipping works as expected.
Comment 1 burninleo 2013-09-19 14:06:24 UTC
(the clipping is lost in the PDF, not in the original file)
Comment 2 Edwin Sharp 2013-09-19 15:11:23 UTC
Crop is indeed lost.

Rev. 1523756 Win 7
Comment 3 Armin Le Grand 2013-09-20 11:10:06 UTC
ALG: Indeed, as described. Checked the GdiMtfExporter, there is support for a GraphicLink object in PdfExtOutDevData which is used here (metafile actions with the correctly clipped graphic are ignored). That extra PDF export data is created in VclMetafileProcessor2D::processBasePrimitive2D (before primitives the stuff in svtools/source/graphic/grfmgr.cxx, see UnoControlPDFExportContact was used).
It gets processed in pdfextoutdevdata.cxx where in PDFExtOutDevDataSync::EndGroupGfxLink the extra data is read and used.
Interestingly in the preparation and in the usage a clip range is provided additionally to the original range and used to set a clip region at the PdfWriter, so this may be broken. Checking...
Comment 4 Armin Le Grand 2013-09-20 14:08:34 UTC
ALG: Problem found, it's in the VclMetafileProcessor2D, the component which converts primitives to metafiles, plus taking care of the view dozen hacks added there over time and in usage. One of these exceptions is to generate extra PDF export data, which is done, but has a twist between the fully unclipped graphic region and the clipped one. These are given in the wrong order to the PDFExtOutDevData::EndGroup call, mostly because I always forget that the graphic object's transformation *is* the clipped region, thus the clip-region while thr crop-region is the expanded one (the region the un-cropped grahic would need). Thus, the 2nd is the real 'rOutputRect' and the 1st is the 'rVisibleOutputRect' in terms of PDFExtOutDevData::EndGroup. Exchanging these in VclMetafileProcessor2D in the PRIMITIVE2D_ID_GRAPHICPRIMITIVE2D case makes all work.
BTW: It works for non-recompressed images since these do not use an extra implementation, but just rely on the metafile.
Preparing commit...
Comment 5 Armin Le Grand 2013-09-20 14:10:07 UTC
ALG: Comitted, done. Adapting owner, target, state.
Comment 6 Armin Le Grand 2013-09-20 14:11:38 UTC
ALG: One comment: Exporting the original image also means that it will not be touched and thus being written to PDF as a whole, thus no filesize win by cropping a picture in this mode...
Comment 7 SVN Robot 2013-09-20 14:24:17 UTC
"alg" committed SVN revision 1525015 into trunk:
i123295 corrected object and clip rect in PDFExtOutDevData::EndGroup call in ...
Comment 8 Mechtilde 2014-01-20 16:10:44 UTC
jpeg missing when exporting lossless to pdf.
Comment 9 Armin Le Grand 2014-01-20 20:08:10 UTC
Hi Mechthilde, you are right, I tried it and this happens due to a non-initialized B2DRange variable, indeed as a result of this former fix. Corrected that, checked functionality (now in depth), preparing commit...
Comment 10 Armin Le Grand 2014-01-20 20:21:53 UTC
Comitted, done.
Mechthilde, please have a look again at one of the next AOO versions. Thanks!
Comment 11 zhaoshzh 2014-02-27 03:14:04 UTC
verified on AOO410m1(build:9750) - rev:1566593
Comment 12 fanyuzhen 2014-02-27 08:45:03 UTC
Change status per Shao Zhi Zhao's verification