summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorArmin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de>2023-05-24 12:31:48 +0200
committerAndras Timar <andras.timar@collabora.com>2023-06-04 16:34:11 +0200
commit10f8cdb5ba93953d9efcc3959c8b886f993ddbbb (patch)
tree52842dee822ed09a9702d9addaed1b65412208c7 /include
parentc6b90b83ad6bfaf1e95ca600ef4c5559a2a864fe (diff)
MCGR: Border restoration support
Due to tdf#155362 I added code to be able in case we would need it to convert a BGradient using added tooling from having offsets in the GradientSteps and no border to adapted GradientSteps and border. This is preferrable due to our GradientStyle_RECT (and GradientStyle_ELLIPTICAL too) use that 'non- linear' paint aka move-two-pixels-inside, someone else called it 'frame-paint'. This does not bode well with the border being applied 'linear' at the same time (argh). Thus - while in principle all is correct when re-importing a GradientStyle_RECT with a border after export to pptx, it looks slightly better ('correcter') wen doing so. That is because when being able to and restoring a border at least that border part *is* applied linearly. I took the chance to further apply tooling, move it to classes involved and instead of awt::Gradient2 use more basegfx::BGradient since it can and does host tooling. This is also a preparation to be able to adapt (restore) border in case of turn- around in ODF where the importing instance is before MCGR existance and has to handle Start/EndColor. Needed to take more care with using BGradient instead of awt::Gradient2 for initialization, also better dividing/organization of tooling, already preparation to use for other purposes. Change-Id: I2d3a4240a5ac6fff9211b46642ee80366dc09e3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152194 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Diffstat (limited to 'include')
-rw-r--r--include/basegfx/utils/bgradient.hxx29
-rw-r--r--include/basegfx/utils/gradienttools.hxx21
2 files changed, 35 insertions, 15 deletions
diff --git a/include/basegfx/utils/bgradient.hxx b/include/basegfx/utils/bgradient.hxx
index 4f85ed85a407..ab70d05880de 100644
--- a/include/basegfx/utils/bgradient.hxx
+++ b/include/basegfx/utils/bgradient.hxx
@@ -40,13 +40,10 @@ namespace basegfx
Offset is defined as:
- being in the range of [0.0 .. 1.0] (unit range)
- - 0.0 being reserved for StartColor
- - 1.0 being reserved for EndColor
- - in-between offsets thus being in the range of ]0.0 .. 1.0[
- - no two equal offsets are allowed
- - this is an error
- - missing 1.0 entry (EndColor) is allowed
- - it means that EndColor == StartColor
+ - offsets outside are an error
+ - lowest/1st value equivalent to StartColor
+ - highest/last value equivalent to EndColor
+ - missing 0.0/1.0 entries are allowed
- at least one value (usually 0.0, StartColor) is required
- this allows to avoid massive testing in all places where
this data has to be accessed
@@ -263,6 +260,19 @@ public:
When also mirroring offsets a valid sort keeps valid.
*/
void reverseColorStops();
+
+ // createSpaceAtStart creates fOffset space at start by
+ // translating/scaling all entries to the right
+ void createSpaceAtStart(double fOffset);
+
+ // removeSpaceAtStart removes fOffset space from start by
+ // translating/scaling entries more or equal to fOffset
+ // to the left. Entries less than fOffset will be removed
+ void removeSpaceAtStart(double fOffset);
+
+ // try to detect if an empty/no-color-change area exists
+ // at the start and return offset to it. Returns 0.0 if not.
+ double detectPossibleOffsetAtStart() const;
};
class BASEGFX_DLLPUBLIC BGradient final
@@ -323,6 +333,11 @@ public:
/// Tooling method to fill awt::Gradient2 from data contained in the given basegfx::BGradient
css::awt::Gradient2 getAsGradient2() const;
+
+ /// Tooling to handle border correction/integration and StartStopIntensity
+ void tryToRecreateBorder(basegfx::BColorStops* pAssociatedTransparencyStops);
+ void tryToApplyBorder();
+ void tryToApplyStartEndIntensity();
};
}
diff --git a/include/basegfx/utils/gradienttools.hxx b/include/basegfx/utils/gradienttools.hxx
index 50d58e8a39c0..6fc51adc0e37 100644
--- a/include/basegfx/utils/gradienttools.hxx
+++ b/include/basegfx/utils/gradienttools.hxx
@@ -186,18 +186,23 @@ namespace basegfx
namespace utils
{
- /* Tooling method to extract data from given awt::Gradient2
- to ColorStops, doing some corrections, partitally based
+ /* Tooling method to extract data from given BGradient
+ to ColorStops, doing some corrections, partially based
on given SingleColor.
+ This is used for export preparations in case these exports
+ do neither support Start/EndIntensity nor Border settings,
+ both will be elliminated if possible (see below).
+ The BGradient rGradient and BColorStops& rColorStops
+ are both return parameters and may be changed.
This will do quite some preparations for the gradient
as follows:
- It will check for single color (resetting rSingleColor when
this is the case) and return with empty ColorStops
- It will blend ColorStops to Intensity if StartIntensity/
- EndIntensity != 100 is set in awt::Gradient2, so applying
- that value(s) to the gadient directly
+ EndIntensity != 100 is set in BGradient, so applying
+ that value(s) to the gradient directly
- It will adapt to Border if Border != 0 is set at the
- given awt::Gradient2, so applying that value to the gadient
+ given BGradient, so applying that value to the gradient
directly
*/
BASEGFX_DLLPUBLIC void prepareColorStops(
@@ -209,15 +214,15 @@ namespace basegfx
The intention is that a color GradientStops and an
alpha/transparence GradientStops gets synchronized
for export.
- Fo the corrections the single values for color and
+ For the corrections the single values for color and
alpha may be used, e.g. when ColorStops is given
and not empty, but AlphaStops is empty, it will get
- sycronized so that it will have the same number and
+ synchronized so that it will have the same number and
offsets in AlphaStops as in ColorStops, but with
the given SingleAlpha as value.
At return it guarantees that both have the same
number of entries with the same StopOffsets, so
- that synchonized pair of ColorStops can e.g. be used
+ that synchronized pair of ColorStops can e.g. be used
to export a Gradient with defined/adapted alpha
being 'coupled' indirectly using the
'FillTransparenceGradient' method (at import time).