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
Mainly useful for debugging and to see the content with develop.
tools. For now it just outputs the JSON string, but this might
change to something more concise.
Change-Id: I5641d20f292495f5474755ab9c3b651f67aa6f6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195617
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Support import, storage, and export of OOXML chart color styles
(color sequence). In OOXML, chart color styles are in files such
as colors1.xml, and conform to the chartStyle schema. This commit
supports I/O of color styles, and provides supports storing them
in the chart document model. It does not include any features for
using or modifying the color styles, so at this point it has no
appreciable effect on users.
Change-Id: I5c02137ebf9c25e11951eea55c4c77fda35b0e80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194998
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Implement chart style file export, beginning to use the document
model data rather than hard-coded text. Also add a simple test
that style data round-trips OOXML -> LO -> OOXML properly.
This uses oox structures in docmodel. That will be fixed in a
subsequent commit.
Change-Id: Icc0ef5b212cc32c8c84b51529bc4cf05ab54636c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190586
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Parse the style*.xml file in the OOXML package, and store the imported
styles in XChartDocument via a new XChartStyle. Some areas are yet to be
fleshed out, but the intent here is to get a review of the general approach
and architecture. This includes no work on the export side (or the UI and
application of styles to a chart, which is a separate but related project).
Change-Id: I9d5b9f5aa44fb7944b2d971edc26e04dc2256c7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189531
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
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
This is needed because the module dependencies are an issues if
the conversion is done in basegfx. The bigger issue will come when
the ComplexColor conversion will be done as basegfx can't depend on
docmodel because of circular dependencies.
The BGradient is also more suitable for docmodel anyway as the
previously it was part of the model and is not a basic (gfx)
type - however this doesn't move the whole BGradient into docmodel
yet.
Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
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>
also fix theme export - change scheme enum type name "hlink" to
"hyperlink" and "folHlink" to "followedHyperlink"
Change-Id: Id5435d59cd51352efc4a4a8e333ec1ff45847a6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152782
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
The callback sends the updated theme color palette when the theme
changes or initially when the view is registered, so the client
should always have the up-to-date theme color palette stored, so
it can just show the color picker with the theme at any time without
the need to call the server.
Change-Id: I7cceccc46c2fad23ba89e6d3f3643e37f8dab292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152589
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>
Also change other cases to use the shared_ptr so there is no need
to do copies and replace some of docmodel/theme/Theme.hxximports
with forward declarations.
Change-Id: I4588cb25e05e5f3e535011fffb68a8075b05aecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147691
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>
Added a new component docmodel, that has the document model types,
which only depend on other basic components. This is needed so the
types can be used in every relevant component - xmloff, oox, svx,
editeng,...
Introduces model::ThemeColor, which is a class used to store the
theme color data, including transformations (svx::Transformation).
For UNO use XThemeColor is added, and the implementation UnoThemeColor
which wraps svx::ThemeColor, so it can be tranported around.
Reactor all the code and tests to accomodate for this change.
Change-Id: I7ce6752cdfaf5e4d3b8e4d90314afa469dd65cfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144847
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Andrea Gelmini