Issue 125300 - cropping + scaling image in writer results in a blue rectangle
Summary: cropping + scaling image in writer results in a blue rectangle
Status: VERIFIED FIXED
Alias: None
Product: Writer
Classification: Application
Component: printing (show other issues)
Version: 4.2.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.1.1
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-23 07:53 UTC by aooqa
Modified: 2014-08-05 16:10 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.1.1_release_blocker+


Attachments
example of the problem (33.35 KB, application/vnd.oasis.opendocument.text)
2014-07-23 07:53 UTC, aooqa
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description aooqa 2014-07-23 07:53:55 UTC
Created attachment 83725 [details]
example of the problem

open attachment, file->print and in the preview (and output) the scaled + cropped image is just a blue rectangle
Comment 1 Armin Le Grand 2014-07-23 12:38:42 UTC
The embedded image is SVM, a StarViewMetafile. Extracting it and creating an example file shows print well.
Using crop/original size button changes scale from 106%/126% to 100%/100% (image size does not change?) and makes print wor as expected -> has to do somehow with crop scaling
Comment 2 Armin Le Grand 2014-07-23 12:55:59 UTC
Also happens in AOO410, does not happen in AOO401.
The blue is the background fill of the graphic, Area is set to 'Color'.

I could only reproduce
- with the original graphic
- with setting crop to Left=2 and Top=4 (does not happen when setting only one)
- Area to color (any) to make visible

The other way around: Could avoid error with orig doc by either deleting Left=2 or Top=4.

Same happens in Draw/Impress when inserting orig graphic and setting both crop values. Also only goes wrong when setting both. Strange...
Comment 3 Armin Le Grand 2014-07-23 16:05:34 UTC
Problem happens in the print/PDF preparation when a metafile is prepared (primitive stuff is okay). The metafile is clipped and the cropped part also gets clipped. When these clip PolyPolygons are processed by the MetaFileProcessor (and thus in logic coordinates) an already set VCL ClipRegion collides with a 2nd VCL ClipRegion. To do this, these are clipped against each other to AND them (basegfx::tools::clipPolyPolygonOnPolyPolygon).
In this special case the numerical nifties of double precision lead to an empty result. The same works on pixel targets due to a different clipping mechanism.
It would be wrong to render the content when the result of clipping is empty; this may be a valid result under various situations. But it is possible to check both PolyPolygons being ranges (rectangles) and simplify execution. This is anyways faster than the clipping and the default case.
Adding code to do this and checking...
Comment 4 Armin Le Grand 2014-07-23 16:32:05 UTC
Okay, my changes do what they should do, preparing commit...
Comment 5 SVN Robot 2014-07-23 16:43:28 UTC
"alg" committed SVN revision 1612866 into trunk:
125300 enhanced handling of multiple ClipRegions in MetafileProcessor
Comment 6 Armin Le Grand 2014-07-24 08:59:36 UTC
Fixed and asking for release blocker - it's a safe change.
Comment 7 jsc 2014-07-24 09:37:49 UTC
grant showstopper flag
Comment 8 SVN Robot 2014-07-24 11:28:30 UTC
"alg" committed SVN revision 1613069 into branches/AOO410:
i125300 enhanced handling of multiple ClipRegions in MetafileProcessor
Comment 9 Armin Le Grand 2014-07-24 11:29:01 UTC
Okay, added to AOO410 branch, checked, works, committed. Changed target milestone.
Comment 10 jolatt 2014-08-01 07:22:49 UTC
Verified

AOO411m4(Build:9774)  -  Rev. 1614049
2014-07-28 17:55 - Linux x86_64
Comment 11 fanyuzhen 2014-08-04 07:34:35 UTC
Marking it as verified fixed based on jolatt's verification in comment 10
Comment 12 Armin Le Grand 2014-08-05 16:10:39 UTC
Decided that the better place to do this is in the basic clipping, moved code to basegfx (see issue 125349)