summaryrefslogtreecommitdiff
path: root/basegfx
diff options
context:
space:
mode:
authorRegina Henschel <rb.henschel@t-online.de>2023-06-15 22:18:34 +0200
committerRegina Henschel <rb.henschel@t-online.de>2023-06-16 10:35:23 +0200
commit2b1b2a758cc4666c6cf6b147722223281dfe1f30 (patch)
treed3644e84cf4aa4fb14e7541e3cf5da7d801c6291 /basegfx
parentc66afb209de6132deac8fee9425a351391edc89e (diff)
tdf#155852 same method for StepCount in OOXML as in rendering
Rendering of stepped gradients uses a method that doesn't take the color from a cut point, but before or after respectively. For example, for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1 are used. So sections are 'start color', '1/3 color', '2/3 color' and 'end color'. The output to OOXML now uses the same method. That way rendering in a produced pptx-file is the same as in the original odp-file. Since OOXML has nothing similar to StepCount, it is an export only problem. A second problem comes from the cuddle with StepCount in Gradient struct in API and FillStepCount in shape property set. The draw:gradient-stop-count attribute in ODF belongs to the graphic style of the shape. The gradient definition itself in the <draw:gradient> element has nothing about step count. When a file is opened, it can be that the StepCount component in the Gradient struct still has the default value 0, but the FillStepCount property has the correct value of the shape. The Gradient struct in the API should not have a component StepCount to be compatible with ODF. But the API is published and changing that struct is far-reaching in the code. So the fix here is not a general solution but solves the problem for export to OOXML by reading the FillStepCount property while exporting. Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Diffstat (limited to 'basegfx')
-rw-r--r--basegfx/source/tools/bgradient.cxx14
1 files changed, 7 insertions, 7 deletions
diff --git a/basegfx/source/tools/bgradient.cxx b/basegfx/source/tools/bgradient.cxx
index d46530074787..7b62a19c9ad6 100644
--- a/basegfx/source/tools/bgradient.cxx
+++ b/basegfx/source/tools/bgradient.cxx
@@ -746,7 +746,6 @@ void BColorStops::doApplySteps(sal_uInt16 nStepCount)
// the same color as the previous one ended
aNewColorStops.push_back(*aColorL);
}
-
if (!basegfx::fTools::equalZero(fDelta))
{
// create in-between steps, always two at the same position to
@@ -757,20 +756,21 @@ void BColorStops::doApplySteps(sal_uInt16 nStepCount)
if (rStartColor != rEndColor)
{
// get relative single-step width
- const double fSingleStep(1.0 / static_cast<double>(nStepCount));
+ // tdf155852 Use same method for the color as in rendering.
+ const double fSingleStep(1.0 / static_cast<double>(nStepCount - 1));
+ const double fOffsetStep(fDelta / static_cast<double>(nStepCount));
for (sal_uInt16 a(1); a < nStepCount; a++)
{
- // calculate position since being used twice
- const double fPosition(fStart
- + (fDelta * (static_cast<double>(a) * fSingleStep)));
+ // calculate stop position since being used twice
+ const double fPosition(fStart + fOffsetStep * static_cast<double>(a));
- // add start color of sub-segment
+ // add end color of previous sub-segment
aNewColorStops.emplace_back(
fPosition, basegfx::interpolate(rStartColor, rEndColor,
static_cast<double>(a - 1) * fSingleStep));
- // add end color of sub-segment
+ // add start color of current sub-segment
aNewColorStops.emplace_back(
fPosition, basegfx::interpolate(rStartColor, rEndColor,
static_cast<double>(a) * fSingleStep));