https://issues.apache.org/ooo/show_bug.cgi?id=121185
--- Comment #5 from Armin Le Grand <[email protected]> --- 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? -- You are receiving this mail because: You are the assignee for the bug.
