incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regina Henschel <rb.hensc...@t-online.de>
Subject Re: Problems with axial gradient and low color steps
Date Thu, 13 Sep 2012 14:43:08 GMT
Hi Armin,

comments inline.

Armin Le Grand schrieb:
> 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?


I have written https://issues.apache.org/ooo/show_bug.cgi?id=120604.


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


I think, that it can be handled together in 
https://issues.apache.org/ooo/show_bug.cgi?id=120604, because it is all 
in the same file.


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

It is now in https://issues.apache.org/ooo/show_bug.cgi?id=120957

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

I know what parts are wrong and can fix it using the methods, which are 
currently used in OutputDevice::ImplDrawLinearGradient. Some loops and 
color calculations need to be corrected. If that is OK, I can start.
I don't know, how it can be done using primitives and would need a 
little bit assistance in that case.

Kind regards
Regina




Mime
View raw message