Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Armin.Le.Grand@me.com
 designates 17.172.81.2 as permitted sender)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Message-id: <505296DD.7020809@me.com>
Date: Fri, 14 Sep 2012 10:30:53 +0800
From: Armin Le Grand <Armin.Le.Grand@me.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824
 Thunderbird/15.0
To: ooo-dev@incubator.apache.org
Subject: Re: Problems with axial gradient and low color steps
References: <5048FB1A.7020103@t-online.de> <504A1691.2050504@me.com>
 <504B47AA.3070504@t-online.de> <505038D5.1050003@me.com>
 <5051F0FC.7020000@t-online.de>
In-reply-to: <5051F0FC.7020000@t-online.de>

Hi Regina,

On 13.09.2012 22:43, Regina Henschel wrote:
> 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.

Okay, I can use that.

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

Okay, agreed.

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

Good. Should we add a cross-reference to the two tasks?

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

I think when you can fix it in the traditional way it would be just 
okay. If you want to fix it using primitives I can give you advice. In 
the long run it sould be used less and less, so fixing the existing 
implementation will be okay when its not too complex. Thanks for your 
assistance here!

> Kind regards
> Regina
>
>
>
>

Sincerely,
	Armin
--
ALG