Issue 120539 - Gradient of type 'Square' is not always square
Gradient of type 'Square' is not always square
Status: CLOSED FIXED
Product: Draw
Classification: Application
Component: viewing
4.0.0-dev
All All
: P3 normal (vote)
: 4.0.0
Assigned To: Armin Le Grand
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-10 21:22 UTC by Regina Henschel
Modified: 2013-07-12 16:19 UTC (History)
2 users (show)

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


Attachments
The gradient palette (2.16 KB, application/octet-stream)
2012-08-10 21:22 UTC, Regina Henschel
no flags Details
The test presentation (13.24 KB, application/vnd.oasis.opendocument.presentation)
2012-08-10 21:23 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-08-10 21:22:24 UTC
Created attachment 78908 [details]
The gradient palette

Load the attached gradient file. (I'm not sure, if the error can be seen, if the gradient is not in the palette. You can try to skip this step.)

Then open the attached presentation.
The rectangles have all the same square gradient set but differ in number of steps.
First error:
In edit mode, none of them is square.

Switch to presentation mode.
The gradients with step number until 64 are squares, step number from 65 on are not square.

If you export a single rectangle with low number of steps to a png-picture, you get the correct square gradient too. If you export the whole page, you get the wrong stretched gradients for the low step gradients too.
Comment 1 Regina Henschel 2012-08-10 21:23:40 UTC
Created attachment 78909 [details]
The test presentation
Comment 2 Armin Le Grand 2012-08-13 15:14:00 UTC
ALG: The basic definition came from the VCL implementation; it calculates the outer bounds for the gradient (rectangle) and then paints from outside to inside, all this is calculated and done in pixels. Then a step width in X and Y is calculated to get the needed number of color steps (e.g. sx, sy). Rectangular just means to take min(sx, sy) for both directions (which leads to the forms seen in the edit view). Square means to use sx, sy as is.
The edit view nowadays uses a back-transformed transformation to do these gradients (very hard to do due to the old VCL directly pixel-oriented paint approach, but needed since these gradients can also be used for 3D, and there you need the transformations to map the fillings).
The presentation view uses the exported metafile (still, not primitives). I'm not sure what is done there, but to get it do the same a future presentation mode using primitives will help.
I do not have currently a very old StarOffice around, but maybe Square indeed once was square and it is an error. Who has one and could take a look? Radial and Ellipsoid are pretty much the same, except that an ellipse is painted instead of a rectangle, and Radial does use always circles, not ellipses.
Comment 3 Regina Henschel 2012-08-13 16:18:31 UTC
OOo 3.2 has real squares, OOo3.2 is not very old. Step width is equal even if the outer shape is rectangle or oval, so that some regions have no gradient.

Ellipsoid and Rectangle uses equal step width too, therefore we get the long line in the middle, because equal steps width do not lead to similarity. So the essential difference between type "Square" and "Rectangle" would be, that the blending is done with similarity in type "Square" and with equal step width in type "Rectangle".

I'm not against a change for square. It now looks like the MS Office style "Rectangular" and allows better import at least in the centric cases.

I think about, how to define such a gradient unambiguous. The help text has nothing about it and the spec is not really understandable.

So I suggest that the issue here is not to change it back to true square, but to make it work in all cases.
Comment 4 Armin Le Grand 2012-08-13 16:21:02 UTC
ALG: As a hint to myself: May be an error in initRectGradientInfo compared to initEllipticalGradientInfo with bCircular = true. Taking a look...
Comment 5 Armin Le Grand 2012-08-13 16:32:24 UTC
ALG: The current state of square is an error in transition to primitives; as said, the pair (radial/ellipsoid) is exactly the same as (square/rectangular), except that the 1st uses a unit ellipse as shape and the 2nd a unit rectangle. If we would not correct the square error, we would have to make radial look different. I also think it's unacceptable - when the error happended with OOo3.3 - to make all existing files from then on look different.
For MS compatibility I would rather add other kinds of gradients, e.g. svg ones.
The definitions are vague since they come from where I said: from simple vcl painting. It's hard to describe what vcl did, see ImplDrawLinearGradient/ImplDrawComplexGradient. It's reallx based on pixels and moving offsets to the inner until they meet. This is nearly impossible to describe mathematically, I'm so happy I got this packed into a invertible transformation. Alsi weird are the dependencies on object sizes, together with the object rotations (try a wide, tall rectangle and rotate it interactively to see what the gradients do; they keep X/Y aligned to the base coordina system and take the bound range of the object).
Comment 6 Regina Henschel 2012-08-13 19:53:47 UTC
Because it has been in OOo 3.3, LibreOffice has this change from real square to rectangle too. Thorsten Behrens has done something in addition in https://bugs.freedesktop.org/show_bug.cgi?id=49508. But he is on vacation, so I cannot ask him now.

Neither SVG nor CSS3 have a kind of rectangle gradient. So an own ODF solution is needed to import such gradients from MS Office, otherwise only the background picture solution is possible as it is currently done. But that should perhaps be discussed on the mailing list.
Comment 7 Armin Le Grand 2012-08-14 09:02:32 UTC
ALG: Reason found, somehow it was lost with aw061 on jan 20 2009. Added support again, checking...
Comment 8 Armin Le Grand 2012-08-14 09:09:45 UTC
ALG@Regina: Good they also should do something to fix this (the edit style of aw061 which caused the error is anyways not my edit style...); I did not check what they did, but what I do in AOO makes the 'square' type work as before.
As explained, when we keep 'square' with the error, we also would have to add the error to 'radial'. Also, all files saved and created (even from other sources) before this error came to OOo3.3 will look different. Also slideshow would be wrong.
When other gradients are needed, we should add them. I do not want to make use of an error because the definition is not explaining 100% what it should be. What it should be can be seen before the error, in all versions before OOo3.3.
Comment 9 SVN Robot 2012-08-14 09:20:06 UTC
"alg" committed SVN revision 1372793 into trunk:
#120539# Fixed visualisation of gradeint type 'square' which was broken in OO...
Comment 10 Armin Le Grand 2012-08-14 09:20:32 UTC
ALG: Comitted with rev 1372793, done.