ALG: This is a problem. The presentation is (as known) based on metafiles (still). The converted object is a graphic object containing a metafile (as graphic content).
The graphic object and it's content is handled as primitives now, thus the content of the graphic object gets rotated with the object (what is expected from my POV and correct).
When preparing the Metafile the slideshow is requesting that constellation has to be expressed as metafile (as long as slideshow is using metafile as base data). This is done, but - as you know in the meantime - there is no corresponding metafile representation to do this. This would be equivalent to leaving out step (2) of the description. Thus, the gradient would be rotated, but also applied to the bound rect of the rotated rectangle and thus look different.
The object rotation is currently not applied to the created metafile gradient; this could be done, but still leaves the problem that the gradient *will* use another base rectangle, the bound rect of the rotated rectangle.
There are even two ways prepared to get back from primitives to metafile (one based on converting the primitives back to metafile (the default currently), one using VCL method rotate on the existing metafile), for both the adaption of the object rotation angle to the gradient rotation is missing.
The best way to fix this would be to change presentation to use primitives (A). The maximum possible fix is to get the gradient's rotation adapted (B). There is no way to get the same gradient due to old gradient restrictions (you know these in the meantime).
A is too expensive, B is doable but not optimal.

ALG: Ckecked in an old version, in 5.2 this is no problem since graphic objects (after step (2)) could not be rotated. I bet that in versios where graphic objcts could be rotated but without primitives, the gradient would have not rotated with the object.

ALG: Got a OOo2.2, as expected: even after conversion to metafile the gradient does not rotate with the graphic object.

It is a deep problem, because not only presentation mode is affected, but printing and export to pdf too. Now the gradient in a metafile is rotated together with the metafile. That is a new feature. People will like it and will use it to avoid the problem, that a gradient cannot be rotated together with the shape. They will complain rightly, when the print is different from the edit view.

If I understand you correctly, solution B would result in a wrong gradient, because the bounding rectangle of the rotated shape is used. So it is no option for me. Does version A solves printing too? Then it would be the right way, but possible for 3.5? Or do we need a total new feature "rotate filling together with shape" like provided in MS Office?

Discuss on ooo-dev?

ALG: It's a deep problem.

- The old behaviour (gradient does not rotate with the object, but uses changing bound rect of it, best seen interactively) cannot be changed, at least not the usage of the rotated bound rect. (d) The metafile action for this has no flag for this. When adding one, there is no way to save/load it with wmf/emf definitions, thus not possible.

- After converting to metafile and using as graphic content of a graphic shape it is expected to rotate with the object. Would anyone expect a bitmap *not* to rotate with the object? Metafile is the same case.

(c) The concrete problem is that when converting a rotated graphic object with metafile content it is tried to create a metafile action for this containing the original gradient (for performance and filesize), but this *will* use the expanded bound rect.

You understand (b) correct; it would enhance (c) to show rotated gradients, but with wrong bound rect. It would be doable for 3.5.

Doing (a) means doing it for all remaining cases; it's the future. Doing it for presentation will fix presentation only.

Adding 'rotate with object' is no option, see (d). Besides that, you know the old VCL code and what it is doing. Adding something like 'apply to the back-rotated shape, but execute with rotation' is hard and error prone.

One possible solution is to *not* use a gradient action when doing (c) for the cases where a rotation and/or a shear is used. This could mean to (e) add a bitmap with the rendered gradient or (f) all the created polygons which would render the gradient. These alternatives have their caveats ((e) will show pixels on gradients with view steps, (f) will extend file sizes).

Maybe these caveats are acceptable when thinking that these will be used in cases where an adaption to primitives is missing. What do you think?

Created attachment 79759 [details]
Patch to solve this

ALG: Proposed patch which just does not create VCL Gradient actions for metafiles, but uses the decomposition. Note: The patch is smaller than it looks, the main part is from indention of the else part.

Created attachment 79761 [details]
odp testcases and swf export

Hi Armin, I have applied the patch to a version r1395635 and did some tests.

It looks fine now in presentation, in pdf export and in bitmap export (I have tested print to image writer and export to tiff). So I think, you choose the right way to solve it.

But swf, emf, and wmf export have errors. It seems, that somewhere clipping is missing.

The zip-file contains testcases and export results to swf. The tests have from left to right: original shape, convert to metafile, metafile rotate 30°, metafile shearX -30°, metafile shearY by dragging, metafile flip.

(In svg export the gradient is missing totally in some cases. But that is likely a different issue, because it is missing in the shape not only in the metafile.)

I have not tested yet, what happens to text in shapes.

ALG: Thanks Regina. Checked with not only a rotated GraphicObject containing a gradient, but also with a star shape filled with a bitmap (another case where the ClipRegion needs to be supported).

Emf and Wmf: Bitmap is not clipped, thus I guess ClipRegions are ignored at export
Swf: Bitmap is clipped, just the gradient polygons are not.

These are long existing errors in those export filters. It's the same question over and over again: Shall we fix these three older bugs/missing features or change these exports to use primitives instead as base for export? Lot of work, what to do...

ALG: Checked in the sources, wmf and emf both do not support ClipRegions, except MetaISectRectClipRegionAction (intersect current ClipRegion with rectangle). Same with flash export; shapes filled with bitmap only work because the Metafile-Comment-Hack "XPATHFILL_SEQ_BEGIN" is used.

ALG: I tend to ckeck this patch in, the follow-up task #121223# describes the missing clip supports for the exporters. Regina, what do you think...?

Hi Armin, I think too, that you should check in the patch. But we need a comment in the release notes, that if the user plans to export the presentation to flash, wmf or emf, he must not use metafiles but simple bitmaps. I think, that limitation is reasonable for the user, because that is the way he had to use up to now, before the patch, if he wants the same gradient in presentation mode as in edit mode.

Suggestion for https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Notes, after "But notice, that some export formats (emf, wmf, svg e.g.) are not able to handle gradients in all cases." add:

"If you plan to export your presentation to the formats swf, emf, wmf, or svg do not use conversion to metafile format but conversion to bitmap format, same as it had been necessary before these enhancements."

ALG@Regina: Okay, sounds reasonable. Let's wait with the release notes thingy, because I plan to do something for #121223#. Or is it better to add it (as suggested) and remove again when #121223# is progressing? In both cases we could forget something :-)   ...?

ALG: Preparing commit. BTW: Svg *is* working (mainly because the current exporter tries to map the gradients to an SVG gradient AFAP). Also not working is swf and met.

"alg" committed SVN revision 1401255 into trunk:
#121185# corrected handling of gradients in rotated metafiles

ALG: Okay, done.

ALG: Wrong follow-up task mentioned, wrote #121267# as follow-up task for this one.

Verifid pass on trunk r1404513.