Follow-up to 92d78c3fa385f794b63cf6b328b41222f9e4c8b2
(Table Styles: Move Calc table style generation from OOXML filter to core).
ComplexColor::applyTransformations() applies LumMod and LumOff as
two separate RGB-HSL-RGB round-trips, which can produce off-by-one
color values due to intermediate uint8 rounding. The OOXML filter's
Color::getColor() avoided this by staying in HSL between the two
transforms.
Add ColorSet::resolveOOXMLColor() which collects LumMod and LumOff
from the ComplexColor transforms and applies them in a single
ApplyLumModOff() call.
Also fixes the ComplexColor transform scale in TableStyleGenerator
from 100'000 (OOXML scale) to 10'000 (ComplexColor convention),
matching what the oox filter's createComplexColor() produces.
Change-Id: Id0173f44ffa3663893e3012d7aefbeabbe264241
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/232
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b44399314130a10698a18ffdab482a68bfdcff1a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204568
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Let it also handle a hypothetical non-UnoTheme implementation (it
is possible to create these e.g. from Basic / Python code). When
handling it, use theme name as color set name (there seems to be
no UNO API to get color set name?). And use the same code for the
creation of Theme from PropertyValue list.
The check that enumrange<ThemeColorType> does not iterate through
ThemeColorType::Unknown is redundant, since that value is outside
of [0, LAST] range.
Change-Id: Iae6770f196011deeb2a92d3b64af514fb6a53d06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186513
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
It is created e.g. in XMLThemeContext dtor.
The type of return of FromAny is changed to shared_ptr, which allows
to return the result of UnoTheme::getTheme, and which matches the
types used by all the function callers.
Change-Id: Ie223e5663843be098e2da45cb04d825c72c372fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186508
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Don't allow access to member variables of ComplexColor and makes
them private. Needs a lot of changes.
Change "scheme" to "theme" to be more consistent. In LO we usually
call the "theme color" what is usually refered to as "scheme color"
in OOXML, where it is sometimes refered to as "scheme" and other times
as theme color.
Remove ThemeColor class which was replaced with CmplexColor some
time ago.
Remove un-needed includes and un-needed components.
Use isValidThemeColor in many places where we check that the
ComplexColor is of "Theme" type and that ThemeColorType is set to
a valid value.
Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
In OOXML a color definition includes more represenations, one of
which is scheme color (which is what is implemented in ThemeColor
currently), but it supports other representations too (RGB, HSL,
System,..). ComplexColor includes all the representations, so to
have a better compatibility with OOXML, this changes all uses of
ThemeColor to ComplexColor.
In many cases the usage of ComplexColor isn't the same as the
usage of ThemeColors, but this cases will need to be changed in a
later commit.
Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
ComplexColor includes everything a ThemeColor has and in addition
also can have various other representations that are supported by
OOXML. This is important for compatibility reasons to preserve the
color information.
Change-Id: I677775a96511dc1742c75b1949e002eaa8c622e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151226
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Refactor the existing places and tests in Impress code (sd) to
use it instead.
Also keep the old property of construction and view of the theme
with a sequence of property values, but under the new property
named "ThemeUnoRepresentation". This is needed by the UI tests
currently.
Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Needed to transprt model::Theme around using throught UNO API as
xmloff can't access SdrPage directly.
Change-Id: I5931e42352186d62e7f09b112d8e8c9e4fb79440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146224
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Also move Theme from svx to model namespace so it is consistent
with other classes in docmodel.
Theme header also includes ThemeSupplementalFont, ThemeFont,
FontScheme classes that are used by the Theme and were also moved
to docmodel. These may be moved to its own file in the future when
they are used in more places.
Change-Id: Ic409bea8e5298adc2b039b529c4f7b01cf64f03e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146221
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Also move ColorSet from svx to model namespace so it is consistent
with other classes in docmodel.
Change-Id: Iacbdbdf5ece4015c628a0e45adf6a732b2d27777
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146220
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Balazs Varga