incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regina Henschel <>
Subject Re: Problems with axial gradient and low color steps
Date Sat, 08 Sep 2012 13:27:06 GMT
Hi Armin,

Armin Le Grand schrieb:
>      Hi Regina,
> On 06.09.2012 21:35, Regina Henschel wrote:
>> Hi all,
>> I see a lot of problems with axial gradients, but I'm not sure about the
>> desired behavior.
>> Please have look at attachment
>> in bug
>> Problem (1): How many color steps has an axial gradient, if the user set
>> it to n steps in the UI? Old versions (SO5.2 to at least OOo2.4.3) make
>> it in n steps, with n/2 steps blending color "up" and n/2 steps blending
>> color "down". Around OOo3.2.1 this behavior was changed so that (n-1)
>> steps "up", 1 step in the middle and (n-1) steps down. In AOO we have
>> now (n-1) steps "up" and (n-1) steps "down". The ODF does not specify it.

How many stripes should the shape show, if the user sets the step count 
to 5 ?
5 -> old behavior, does not fit at all
8 -> behavior in 3.4.1 and 3.5
9 -> behavior in 3.2.1, only one middle strip
10 -> I would prefer this; as in 3.2.1, but with double middle strip

>> Problem (2): What colors should the steps have? In the old version the
>> colors for "up" and "down" where different, what I think has been a bug.
> Yes. Also the step count was wrongly interpreted. There are numerous
> errors in the old, VCL-based gradient painters.
>> In AOO 3.4.1 version neither the start not the end color is used, only
>> values between.
> Start and end color should be used (if visible). In the Yellow/Green
> example this seems to be okay.

Compare it with pure color green and pure color yellow and compare it 
with a linear gradient with green -> yellow and linear gradient with 
yellow -> green.

The linear gradient includes the start color and excludes the end color. 
(I think that it would be better the other way round, because the start 
color can be included via border. But that is a different problem.)

The axial gradient has neither start nor end color.

>> Problem (3): The old gradients are still used for presentation mode,
> AFAIK presentation has its own gradient rendering, targeted at
> system-specific canvases. If redoing this, it sould use the primitives
> directly (one day). It's an export.
>> converting to bitmap,
> Should use primitives nowadays. If not, should be changed to do so.

Indeed, that is fixed in AOO3.5. It is correct for export to png and jpg 
too in AOO3.5.

Copy and Save as "GDI metafile" is better in AOO3.5 than in AOO3.4.1. 
The gradient is the same as for the shape and the gradient rotates 
together with the shape, as expected for a picture. But 'Break' and 
'Convert to bitmap' are wrong. 'Convert to bitmap' looses the rotation 
which comes from the shape rotation and 'Break' looses the step count in 
addition. But that is not specific for axial gradient.

>> export to pdf
> Yes, is based on and 'paints' metafiles (but not with the VCL
> mechanisms). It's an export and should be changed to primitive usage one
> day.

Mh. If I export it to pdf using my build with my changes in 
OutputDevice::ImplDrawLinearGradient, I can see exact this changes.

>> and flash.
> Not sure about this, also an export.
>> I think, that needs to be
>> fixed. I have looked around, and think, that it is in
>> OutputDevice::ImplDrawLinearGradient in
>> \main\vcl\source\gdi\outdev4.cxx. Is that right? If yes, are other
>> places effected as well? Should it be fixed or is someone working on a
>> more general solution?
> It *could* be fixed there if really used. Have You tried to set breaks
> (pr fprintfs) to check this? Most usages should not use it.

No. I have changed the colors and steps in 
OutputDevice::ImplDrawLinearGradient and can see those changes using the 
resulting build.

> If it is used, it could be made to work using temp primitives internally
> to ensure equal rendering.

As far as I have tested, OutputDevice::ImplDrawLinearGradient is used in 
presentation mode, export to pdf, swf, emf, and wmf. The exports to png 
and jgp are OK in AOO3.5. I havn't tested other formats.

> For all exports which are nowadays still based on metafiles the solution
> should be to rewrite/modify these exports to be based on primitives in
> the future.

Do I understand you correct, that you think, it is not worth to correct
OutputDevice::ImplDrawLinearGradient? But the effort should be to make 
it totally superfluous?

Kind regards

View raw message