Apache OpenOffice (AOO) Bugzilla – Issue 120607
Rotated gradient is scaled, but should not
Last modified: 2012-08-21 11:13:53 UTC
Created attachment 78996 [details] Illustration of wrong scaling for rotated gradients. Open the attached document, where the problem is illustrated. The squares with the light yellow are pictures, otherwise were not able to rotate then. Problem: When a gradient is rotated, it is not only rotated but scaled too. This should not happen, because the object itself is not rotated. This scaling leads to the error, that the percentage values cx and cy, which refer to the object size, do no longer work as expected. Especially the cx=0% and cy=0% position is no longer in the top left corner of the object.
ALG: I fear I have to tell you that it is not an error, it is just how the old gradients were made/layouted. I do not know who initially did them, but when you look at the code in VCL you can see that it is pretty 'hand-crafted' and just there to show gradients at all. Look for OutputDevice::DrawGradient and ImplDrawLinearGradient/ImplDrawComplexGradient to see what I'm talking about. This is still there and used, except for edit views where I use primitives now. I already fixed some bugs for the primitive visualisation e.g. the number of steps for linear produce unequal numbers for that vcl methods. I spent a *lot* of work to get that pixel-based, hand-crafted stuff to work with primitive gradients, one of the hardest parts was that 'expansion' to the object bound rect when the gradient is rotated. No, the vcl gradients do not smoothly rotate with the objects, see the code I pointed to above. The problem is always the same; it was there before UNO API and ODF were done (and most definitions were just copied without thinking about it). The point is that the visualisation of existing files is not allowed to change. This was the argument before ODF and UNO API and is now, too. Thus, the cx and cy were never designed (if it was designed at all) to correspond to the object's size (even when it is rotated). We can and will do it better with other gradients, but we should not change the visualisation/definition of the old ones, how crude they may seem to be from today's view. Don't forget that these were implemented when 640K were standard (not an excuse, but an explanation that it's old).
It is very old. I can see this "wrong" behavior already in StarOffice 5.2. That was no problem as long as the own formats were written. But now AOO claims to write ODF1.2 and the problem exists to get specification and implementation aligned. I don't like the idea to suggest to specify all of the old strange StarOffice solutions as standard in ODF1.3.
ALG->Regina: I understand what you mean, but that's the way it happened and was defined originally. This more or less makes the old versions define the ODF behaviour. Not nice. but fact. 'Wrong' behaviour in SO5.2 -> no, it's the root of ODF definitions. As I said, for ODF1.3 changes may be made, but there must be a transition path. It is not acceptable to change the ODF definitions and then let all old ODFs look different after loading. I *have* seen examples where people used gradients, their step width and other stuff to create someting like lines wvere other objects are placed (!). Whoever wrote in ODF1.2 that e.g. angles are degrees (and even the same as in SVG) may have done so in good purpose, but had (obviously) nit the manpower to do these changes in all existing ODF munchers. Let's not do something similar - just changing the def to what we *want* it to be is not a good choice (unfortunately..)