diff options
author | Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de> | 2023-05-24 12:31:48 +0200 |
---|---|---|
committer | Andras Timar <andras.timar@collabora.com> | 2023-06-04 16:34:11 +0200 |
commit | 10f8cdb5ba93953d9efcc3959c8b886f993ddbbb (patch) | |
tree | 52842dee822ed09a9702d9addaed1b65412208c7 /include | |
parent | c6b90b83ad6bfaf1e95ca600ef4c5559a2a864fe (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.hxx | 29 | ||||
-rw-r--r-- | include/basegfx/utils/gradienttools.hxx | 21 |
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). |