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>
ComplexColor is a replacement for oox::drawingml::Color, so both
share a lot in common, but oox::drawingml::Color is only used to
resolve the colors inside oox. The idea is to replace step by step
oox::drawingml::Color with ComplexColor. In this step a lot of
ComplexColor types are used instead in oox::drawingml::Color types.
Additionally oox::drawingml::Color is not mandatory anymore for
a lot of contexts, so depending on the need ComplexColor can be
used or oox::drawingml::Color.
Change-Id: I6613a0f63cc9b7d070841d4f667363b03e6cbaa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194645
Code-Style: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Follow-up to earlier commit for this bug, improving the handling of
cs:ST_StyleColorVal and adding CI testing for FontReference and StyleReference
Change-Id: If8c86b780de07c38dfd67e4ba6c7739935698a27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191416
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Chart style import/export was not handling a:ST_FontCollectionIndex
correctly. Despite the name, its value is not an integer index,
but one of three strings (major, minor, none). Separate the
FontReference and StyleReference code better in order to handle
this OOXML value correctly.
Change-Id: I1638f6484ecfe5a9bd8c1adab8d854cff47ce14f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191195
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
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>
and
cid#1665282 Variable copied when it could be moved
cid#1665279 Variable copied when it could be moved
cid#1665278 Variable copied when it could be moved
cid#1665276 Variable copied when it could be moved
cid#1665275 Variable copied when it could be moved
cid#1665257 Variable copied when it could be moved
Change-Id: I222860c6385693610b95f4d674d4d0da59e75a5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190635
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.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>
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
Most of changes are a results of code reviews.
Added comments and clarifications, removed unneeded methods,
renamed variables to be more clear, protection against nullptr
dereference,...
Change-Id: Iae2b6abfa90b3bbd3f28328ca7fcf429765cbe9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156203
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
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>
Somehow I overlooked completely, that there already is a non-static
setRGB. Thanks Miklos and Tomaž for the heads up!
Change-Id: If20018a317d90e0a6297950dff201671316aacad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155353
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This changes Sparkline colors to use complex colors instead and
adds Sparkline theme color import and export support for ODF and
OOXML.
Change-Id: I58edd525d50f95199bd4fe7825afb51aaa7fc091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155113
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Don't store values from grab bag when exporting character theme
colors and tint/shade values. The values could be wrong now and
aren't needed anyway as we support the values in the model.
Add proper export support for char color theme information with
correct conversion of values into tint/shade values in 0-255
inverted interval.
This also fixes the import of tint/shade values whcih calculation
was slightly off. We divided by 256 instead of 255, which
introduced an error.
In addition introduce ThemeColorUsage enum, which marks if the
theme color type has a specific "usage" - text or background. This
is determined on import if the theme type is background{1,2} or
text{1,2}. This is then taken into account on export, so the
exact type is preserved.
Change-Id: I0022a159397fd0c3d39a118a7149bb2488dfc149
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152705
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
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>
We need to identify what the color type of the complex color is.
For now we mostly use "theme", but in the future we can also have
other types like "rgb",... when the infrastructure for that is
built.
Change-Id: I38c91d294a191ca3124be4e99050977c9815d23e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152253
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>
In addition to editing of theme colors, this also changes the
way how theme colors are represented in the theme dialog and the
behaviour when changing applying a theme color change.
Previously a theme colors were applied with double-click, now a
double-click still applies, but automatically exits the dialog.
The selected theme is applied also when OK button is pressed.
Change-Id: Ic0f8399ede180d6ab0001a7f8b5dda0e7c49fa3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150975
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This adds support for (most) blip effects import, export and
the document model.
Change-Id: Iec15f4de22c31268019fa1a60432e40ae8f03635
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150262
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Also use the ThemeExport when exporting PPTX documents and remove
all the hard-coded theme bits.
Change-Id: I03791e23d6ac4023748b5a553e4824b72ed63a93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149363
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Introduces RectangleAlignmentItem that holds a value of the enum
model::RectangleAlignment.
Introduces SDRATTR_SHADOWALIGNMENT that holds alignment for a shadow.
Implements import of algn for outerShdw.
Makes the alignment considered while the shadow is being scaled.
Also adds a unit test that covers this.
Change-Id: I8f4eaed5f0d9428a7f405c65f19237f9e70ca151
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148934
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@collabora.com>
Also extend the SwCoreThemeTest with asserts for the LineStyles
for the example theme.
Change-Id: I72aa64345d39fea84544e39b0a37a22f3e6baa5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149360
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Extends ThemeTest in sw with the use cases relevant for import of
FormatScheme into the model::Theme (as much as it is implemented
currently).
Change-Id: I888f64c24ba455913d688be256f095d9c298dc2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147693
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>
Tomaž Vajngerl