incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: Problems with axial gradient and low color steps
Date Fri, 07 Sep 2012 15:45:21 GMT
	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.
> 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.

> 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.

> 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 

> 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.

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

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.

> Kind regards
> Regina


View raw message