Issue 118525 - Rotated/Sheared OLEs are not handled correctly in slideshow
Summary: Rotated/Sheared OLEs are not handled correctly in slideshow
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: 3.4.0 Beta (OOo)
Hardware: PC Windows 7
: P5 (lowest) Normal (vote)
Target Milestone: ---
Assignee: Armin Le Grand
QA Contact:
Depends on:
Reported: 2011-10-18 16:49 UTC by Armin Le Grand
Modified: 2017-05-20 10:31 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2011-10-18 16:49:19 UTC
ALG: This is a F'up to #118485#, #108221#, #67705#.
ALG: Thanks to Regina for reporting this. When starting a slideshow, the rotation/shear is not taken into account for OLEs. Also, the Line/FillStyle/Text/Shadow is ignored.

ALG: Also saw that 'convert to metafile' is missing.
ALG: Break on the OLE has some problems, too. I already did something there, need to take a closer look. Convert to Polygon/Bezier works flawlessly, though, so there has to be something which I forgot.
Comment 1 Armin Le Grand 2011-10-18 16:49:51 UTC
ALG: Assigned to me, starting...
Comment 2 Armin Le Grand 2011-10-19 08:44:41 UTC
ALG: Ignore of styles and transformation is only for Chart OLEs, there is some special form of rendering/getting Metafile in the slideshow module. Taking a look, building slideshow with debug...
Comment 3 Armin Le Grand 2011-10-19 09:33:52 UTC
ALG: Indeed, slideshow has special handling for chart content, it gets the Metafile needed for Slideshow directly from the chart, thus ignoring any styles or transformations.

This is the result of a special fix which was made to enhance the resolution charts are rendered with for presentations. This is needed when charts get resolution-dependent, e.g. 3D charts or many data points (where chart would reduce resolution-dependent).

It could be easily made working when removing that fix (see local_getMetaFile_WithSpecialChartHandling in slideshow), but would remove that chart fix.

There is nearly no way to fix this differently. What would be needed to get the metafile of the chart OLE without content (doable), the chart content as 2nd metafile and append to first, embedding the content in a transformation to place it where needed (not doable). This is not possible, since metafiles simply do not support transformations.

The middle/long term solution will be to use primitives for slideshow. This would make the chart fix superfluous and would if needed allow free embedding of sub-content to transformations.

All works well for other OLE types since the metafiles are generated based on the primitive representation anyways.

At least there is a good workaround: Convert the Chart OLEs to polygon/curve objects in the slideshow document.
Comment 4 Armin Le Grand 2011-10-19 11:58:14 UTC
ALG: No solution currently, back to new for now.
Comment 5 Armin Le Grand 2011-10-19 11:59:16 UTC
ALG: One more info: Added (and solved) #118529# ( for the other mentioned defects, this task is only about the SlideShow problems now.
Comment 6 Armin Le Grand 2011-12-22 20:44:28 UTC
ALG: Preparing to completely remove ChartPrettyPrinter stuff and use primitive representation instead.
Comment 7 Armin Le Grand 2012-01-03 13:29:40 UTC
ALG: Found a solution by directly using the primitive data from the chart model. This completely removes the ChartPrettyPrinting stuff which was an exception anyways. It means that a 3D chart is now moved as primitive (2D scene) to the rendering of whatever is intended and rendered there in the requested resolution. It also means that all vector data is now transported loss-less without the path over the metafile (converting to and from metafile with the appropriate problems). It also means more rendering speed for charts in general.

ALG: Had one remaining problem with 2D primitive 3D Scene: When getting from the chart model and embedding to an e.g. rotated/sheared/mirrored Ole it happened that the scene is transformed more than just translation/scale combination. Interestingly, this never happened before since regular 3D objects modify the 3D objects (the scene's content) and not the scene itself as 2D primitive. Adding this to the full 3D transformation pipeline was hard (due to 2D/3D coordinate systems involved having different coordinate system orientations in Y), but working now.

ALG: Preparing change, adding diff to an updated trunk version, building, testing...
Comment 8 Armin Le Grand 2012-01-04 10:11:54 UTC
ALG: Checked HC handling, Removed unused variable maOriginalMapMode in primitive processor implementations, one exception handling (was only for chart extra rendering) eliminated.

ALG: Checked in, done.