Issue 54144 - Ellipsoid gradiens are not "ellipsoid"
Summary: Ellipsoid gradiens are not "ellipsoid"
Status: CLOSED DUPLICATE of issue 57152
Alias: None
Product: Draw
Classification: Application
Component: viewing (show other issues)
Version: 680m125
Hardware: All All
: P4 Trivial (vote)
Target Milestone: AOO Later
Assignee: Armin Le Grand
QA Contact: issues@graphics
Depends on:
Reported: 2005-09-02 11:45 UTC by haui
Modified: 2007-04-23 12:24 UTC (History)
1 user (show)

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

Problematic rendering of "ellipsoid" gradients in OpenOffice. (12.33 KB, application/
2005-09-02 11:50 UTC, haui
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description haui 2005-09-02 11:45:41 UTC
Ellipsoid gradients have their name from ellipsoids, which are affine images of
a sphere, haven't they? They are called ellipsoid gradients, because their color
isobars (lines of equal color) correspond to the isobars of an ellipsoid (lines
of equal height), aren't they? If this is the case, ellipsoid gradients are broken. 

The color isobars of "ellipsoid" gradients do not correspond to the isobars of
ellipsoids. I ever wondered, why these gradients look so strange in
(s|ooo)office, but I never found out why, until I now had a closer look at
gradients in general in the context of SVG import (Issue 2497). The document,
which I'll attach, shows that the color isobars of "ellipsoid" gradients in
(s|ooo)office correspond to the isobars of an object, that has the contour of an
ellipse, if looking from the top, but it has the contour of a diamond when
looking from left and right, and the contour of a doubled parallelogram, when
looking from front and back. Instead, the contours of ellipsoids are ellipses,
no matter from which side one looks.

The color isobars of ellipsoid gradients currently are ellipses, but ellipses
with varying eccentricity. This is not the case for isobars of ellipsoids.
Isobars of an ellipsoid are scaled versions (with constant aspect ratio) of the
contour ellipse. There are two mistakes: in the current implementation, both
axes (!) of the color isobar ellipses (instead of the scaling factor *1) are
varied linearly with the same slope (instead of elliptically *2). In
consequence, "ellipsoid" gradients are not even affine images of radial
gradients (what I would have expected). The attached document shows how to
construct a "truly" ellipsoid gradient.

*1) Scaling the outermost contour ellipse instead of varying its axes
    with constant slope is a must to fix. It is the main reason, why
    those gradients look so strange.

*2) Varying the color elliptically instead of linearly in optional
    (IMO). When only two color stops are given in SVG, the color is
    also varied linearly there. Of cause, elliptical variation (to get
    a truly ellipsoid gradient) can be accomplished by providing
    multiple color stops that approximate the contour of the color

This problem existed from the beginning of the time (in the beginning
StarDivision created StarOffice...). It was inherited by OpenOffice 1.0 and
handed down to OpenOffice 1.1 and 2.0 beta. 

This is also an OpenDocument problem. 
1) A problem of the specification, since it does not (to the best of
   my knowledge) specify, how those "ellipsoid" gradients should look like.
2) A problem of compatibility with other OpenDocument applications.

Please, do not close this as WONTFIX, with the justification that is was so from
the beginning!
Comment 1 haui 2005-09-02 11:50:12 UTC
Created attachment 29265 [details]
Problematic rendering of "ellipsoid" gradients in OpenOffice.
Comment 2 wolframgarten 2005-09-02 12:02:49 UTC
Wow. So much text. So much (and such a nice) document.
Comment 3 haui 2005-09-12 10:03:03 UTC
Could you please correct the misspelled summary: "gradients" instead of
"gradiens"? Thanks!
Comment 4 Armin Le Grand 2005-10-18 12:59:11 UTC
AW: Haui, i know all that, but the code which draws elliptical gradients is 8-10
jears old and they did it wrong from the beginning. But: there is no way to
change the existing behaviour since all existing objects out there rely on the
current definition and how the ellipses are produced. They would lokk different
when changing the behaviour.
It's even worse: I try to migrate to something more useful slowly, but to do
that, it will be necessary to EMULATE the old behaviour in a first step.
So, at the moment, i am doing a geometric texturing class in unit coordinates
(0,0 .. 1.0) to do all the gradient, bitmap and hatch stuff in one class in the
future. It's a struggle to map that old, non-linear behaviour to such a clean
structure, but it works...
As You can see, i know that problems and it's not the only one :-)
As soon as we have achieved a more usable base system for that fill stuff which
hast to completely map the old stuff, we can start to define new stuff which
will then be offered as default. But there is no way to go that hard and stony
migration way.
So what shall i do with Your report? I can tell You that development is going in
a direction which will result in something You want to have, but there is no
time frame for that.
Comment 5 Armin Le Grand 2005-10-25 10:08:47 UTC
AW: Keeping as reminder on low prio
Comment 6 Armin Le Grand 2007-04-23 12:23:31 UTC
AW: Double to #i57152#. Since description is more common, there, i close this one.

*** This issue has been marked as a duplicate of 57152 ***
Comment 7 Armin Le Grand 2007-04-23 12:24:02 UTC
AW: Closing.