incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <Armin.Le.Gr...@me.com>
Subject Re: Problems with axial gradient and low color steps
Date Wed, 12 Sep 2012 07:25:09 GMT
Hi Regina,

On 08.09.2012 21:27, Regina Henschel wrote:
> 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
>>> https://issues.apache.org/ooo/attachment.cgi?id=79324 in bug
>>> https://issues.apache.org/ooo/show_bug.cgi?id=120604
>>>
>>> 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

I agree. I first thought about 9, but 10 is the exactly once mirrored 
behaviour of 'linear'. Do we have a task for 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.
>
> 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.

I see this both as errors. Start and end color should always be used. Do 
we have tasks for this?

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

Okay, so export to metafile uses OutputDevice::ImplDrawLinearGradient.

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

Good.

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

No. I appreciate and (more than) welcome when you correct the behaviour 
in OutputDevice::ImplDrawLinearGradient. This is the only (and probably 
best) short-term solution.

I just wanted to say that - if it would be a lot of work - it may be 
worth to think about fixing it by migragting more exporters to primitive 
usage. Doing so would in the optimal canse make the old gradient 
rendering (OutputDevice::ImplDrawLinearGradient) obsolete, so fixing 
that would be redundant.

When it's reasonable time effort to correct 
OutputDevice::ImplDrawLinearGradient and (as it surely is) still far 
away (unfortunately) to change other exporters to primitives, I am more 
than happy to change it.

I'm looking forward to review those changes...

> Kind regards
> Regina
>


Mime
View raw message