Issue 121185 - Rotated metafile looses rotation of gradient in presentation mode and in export
Rotated metafile looses rotation of gradient in presentation mode and in export
Status: CLOSED FIXED
Product: Impress
Classification: Application
Component: save-export
4.0.0-dev
All All
: P3 normal (vote)
: 4.0.0
Assigned To: AOO issues mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-08 13:05 UTC by Regina Henschel
Modified: 2013-07-12 16:25 UTC (History)
3 users (show)

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


Attachments
Original with gradient, metafile, and rotated metafile (12.09 KB, application/vnd.oasis.opendocument.presentation)
2012-10-08 13:05 UTC, Regina Henschel
no flags Details
Patch to solve this (9.46 KB, patch)
2012-10-10 16:36 UTC, Armin Le Grand
no flags Details | Diff
odp testcases and swf export (280.11 KB, application/zip)
2012-10-10 21:57 UTC, Regina Henschel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2012-10-08 13:05:02 UTC
Created attachment 79747 [details]
Original with gradient, metafile, and rotated metafile

1. Create a shape in a presentation and fill it with a linear gradient.
2. Convert the shape to metafile.
3. Rotate the metafile. Notice, that the gradient is rotated too.
4. Switch to presentation mode. Notice, that the gradient is not rotated.

The same error can be seen with export to pdf or export to a picture format.

Rotation if filling together with shape rotation works for hatching.

Corresponding issue for LO is https://bugs.freedesktop.org/show_bug.cgi?id=55029
Comment 1 Armin Le Grand 2012-10-09 10:11:33 UTC
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.
Comment 2 Armin Le Grand 2012-10-09 10:32:27 UTC
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.
Comment 3 Armin Le Grand 2012-10-09 11:01:38 UTC
ALG: Got a OOo2.2, as expected: even after conversion to metafile the gradient does not rotate with the graphic object.
Comment 4 Regina Henschel 2012-10-09 12:38:13 UTC
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?
Comment 5 Armin Le Grand 2012-10-10 09:12:03 UTC
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?
Comment 6 Armin Le Grand 2012-10-10 16:36:26 UTC
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.
Comment 7 Regina Henschel 2012-10-10 21:57:57 UTC
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.
Comment 8 Armin Le Grand 2012-10-11 08:57:04 UTC
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...
Comment 9 Armin Le Grand 2012-10-11 11:34:17 UTC
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.
Comment 10 Armin Le Grand 2012-10-22 15:20:00 UTC
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...?
Comment 11 Regina Henschel 2012-10-22 15:46:04 UTC
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."
Comment 12 Armin Le Grand 2012-10-22 16:19:01 UTC
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 :-)   ...?
Comment 13 Armin Le Grand 2012-10-23 11:43:16 UTC
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.
Comment 14 SVN Robot 2012-10-23 11:49:51 UTC
"alg" committed SVN revision 1401255 into trunk:
#121185# corrected handling of gradients in rotated metafiles
Comment 15 Armin Le Grand 2012-10-23 11:50:07 UTC
ALG: Okay, done.
Comment 16 Armin Le Grand 2012-10-24 12:03:12 UTC
ALG: Wrong follow-up task mentioned, wrote #121267# as follow-up task for this one.
Comment 17 Li Feng Wang 2012-11-08 07:00:44 UTC
Verifid pass on trunk r1404513.