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
