summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)Author
2023-07-06tdf#141058 oox,sw: OOXML import/export of decorative on shapesMichael Stahl
Also add a test for PPTX (using the oox filters), and add a SdrObject to the testTdf143311 for DOCX (using the writerfilter/docxsdrexport). Change-Id: Iccee46c0d30316c33c0947b117e2604c96fa0182 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154137 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-07-05oox: fix crash in lcl_GetGluePointIdXisco Fauli
See https://crashreport.libreoffice.org/stats/signature/static%20long%20oox::drawingml::lcl_GetGluePointId(const%20class%20com::sun::star::uno::Reference%3Ccom::sun::star::drawing::XShape%3E%20&%20const,%20long) Regression from b7c542b5085374f1d031183cb86ceeefcf24964d "tdf#154363 sd: fix line connectors regression of mirrored shapes" Change-Id: I926d32f5b68582df588c28a800b0ec10e7e3e19f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154021 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-07-04loplugin:constantparamNoel Grandin
Change-Id: Iee554baae7239c9bf0ac35cab6ff235a88dc29a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153973 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-29oox: convert Excel tint value into LumOff and LumModTomaž Vajngerl
tint value can be converted into LumOff and LumMod values, so we don't need a special Excel case for calculating the final color. Change-Id: I0725c06f9df6a37a309ea5d17b183e4100a228f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153716 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-28tdf155903 DOCX export: fix corrupt file with embedded mediaTünde Tóth
Regression from commit bc72514f90d90e1ab3fed8167663e835edf03508 "tdf#53970 PPTX: fix export of embedded media files". Change-Id: I04521227346817d91f720b1f6a77beb7f4a01f83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153619 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins
2023-06-28Simplify a bitMike Kaganski
Change-Id: Iad2564853a2a0d74cd526b1574e421e121fd6986 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153644 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-06-27loplugin:stringstatic look for more stringsNoel Grandin
that can be initialised at compile-time instead of runtime Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-26Fix typoAndrea Gelmini
Change-Id: Ic071259d68e0fa9d7a2541e32d30c11bb0f21d2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153612 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-26new loplugin:constexprliteralNoel Grandin
OUStringLiteral should be declared constexpr, to enforce that it is initialised at compile-time and not runtime. This seems to make a different at least on Visual Studio Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-25oox: map color transforms direct to create model::TransformTomaž Vajngerl
Change-Id: I82382f8d0936e90218fefe889ea5bfdd04c3e82b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153507 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-24cid#1532474 Uninitialized scalar fieldCaolán McNamara
Change-Id: I23bb555a8104a60f6e81954637127acf181bb9c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153551 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-06-21sc: OOXML import of theme colors for char and background colorsTomaž Vajngerl
Change-Id: I8209238927bb425e8e306352f1fa78d63378f005 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151707 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-20tdf#145651 Chart OOXML export: fix write error in exportSolidFillTünde Tóth
Don't export the background color, if the FillColor property is empty. Steps to reproduce: 1. E.g. in Impress, insert a chart (Insert > Chart...). 2. In chart editing mode, select the legend, use the "sidebar > Area > Fill" and change from "none" to "color". Notice how the default blue that is used does not correspond to the colour in the colour picker right underneath. 3. Save as > OOXML format. Change-Id: I33a060d8fc6c49708029008393e2e22e3d5335b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152951 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-06-20tdf#155827 MCGR: Axial to linear in oox export, apply...Regina Henschel
... separately for color and transparency gradient. The current solution had the change from axial to linear applied to color and transparency gradient at the same time. That resulted in wrong gradient if only one of them was axial. Because changing axial to linear changes the number of stops, it has to be applied before color and transparency gradients are synchronized. As now color and transparency are both linear already after they are synchronized, the switch can be replaced with a simple if. Change-Id: I75e6b495782bc8a9fe94504426efadec2f60b61f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153197 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-19oox: ThemeExport - add "relationship" xml:r namespaceTomaž Vajngerl
Blips are referenced by r:embed element, which needs the xmlns:r to be present, so add it at the toplevel. Change-Id: Iccc3d197bf30b428927521c6ba598d8d92fa734d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153243 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-18ooxml: import and export background and fill theme colors props.Tomaž Vajngerl
This adds support to import and export background and fill theme color properties. Change-Id: I0f40615fe2d06cdcb4f2f9752602fe2ec699c7b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152835 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-17Fix typo in codeAndrea Gelmini
Change-Id: I8f7e3b11b952b1882ca8e67619145c0dca71820a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153205 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-17oox, writerfilter, xmloff: use frozen data structures for static dataTomaž Vajngerl
Change-Id: I4a53fa57f52900104d249c84cde36c9d3b9e1300 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153175 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-16Fix typoAndrea Gelmini
Change-Id: I05a77aedfed9ea8dffed134d6748151c88dc4c7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153184 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-16tdf#155852 same method for StepCount in OOXML as in renderingRegina Henschel
Rendering of stepped gradients uses a method that doesn't take the color from a cut point, but before or after respectively. For example, for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1 are used. So sections are 'start color', '1/3 color', '2/3 color' and 'end color'. The output to OOXML now uses the same method. That way rendering in a produced pptx-file is the same as in the original odp-file. Since OOXML has nothing similar to StepCount, it is an export only problem. A second problem comes from the cuddle with StepCount in Gradient struct in API and FillStepCount in shape property set. The draw:gradient-stop-count attribute in ODF belongs to the graphic style of the shape. The gradient definition itself in the <draw:gradient> element has nothing about step count. When a file is opened, it can be that the StepCount component in the Gradient struct still has the default value 0, but the FillStepCount property has the correct value of the shape. The Gradient struct in the API should not have a component StepCount to be compatible with ODF. But the API is published and changing that struct is far-reaching in the code. So the fix here is not a general solution but solves the problem for export to OOXML by reading the FillStepCount property while exporting. Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-14tdf155825 result same size in synchronize gradientsRegina Henschel
While synchronizing color and transparency gradients two new sequences are generated. In case the last offsets where different, the remaining stops where not copied to the new sequence and thus they had different sizes which triggered an assert in oox/source/export/drawingml.cxx. Change-Id: I446f8cfafb23735f06ad4e05eee8c922141b864d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153063 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-06-14SAL_WARN->SAL_INFO in oox::ShapeContextNoel Grandin
Change-Id: Ifd5e1493a8bbe9954ca9420d03b7a2b1db3307f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153043 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-14MCGR: Use BGradient in export of Fontwork to docx tooRegina Henschel
Transparency values are not exactly like in UI because converting through rgb-color adds rounding inaccuracy. The unit tests are adjusted accordingly. With only start and end values it was possible to use the UI values directly. It would be possible to make special cases for front and back value, but I think it is not worth the effort. The previous solution had the error, that the stops were not mirrored in case of non linear gradient. That is corrected now. The unit tests are adjusted. The previous solution had assumed that our 'intensity' at start or end colors is the same as the 'lumMod' attribute in OOXML. However, this is not the case. So now the 'intensity' is incorporated into the color. Again, the unit tests are adjusted. Change-Id: Id02e455dc09d12c5b453637fcb2bdc4f8f1529d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152839 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-13sc: filter: oox: add missing tag "fillcolor"Henry Castro
To fill the positive color of the conditional format data bar: <x14:dataBar maxLength="100" minLength="0" axisPosition="automatic" direction="context" gradient="0" negativeBarBorderColorSameAsPositive="0"> <x14:cfvo type="autoMin"/> <x14:cfvo type="autoMax"/> <x14:fillColor rgb="FF638EC6"/> <x14:negativeFillColor indexed="2"/> <x14:axisColor indexed="64"/> </x14:dataBar> Signed-off-by: Henry Castro <hcastro@collabora.com> Change-Id: I17e83a01affff292ff941d92f6ae59954aa246ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149064 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152965 Tested-by: Jenkins
2023-06-13cid#1532377 Dereference before null checkCaolán McNamara
Change-Id: Ie85e81cea63578413db2c69020dae6a105466cb4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152963 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-06-12ooxml: import and export char underline theme colorsTomaž Vajngerl
This adds support to import and export char underline theme color properties. Change-Id: Ia8948ee5aacd20e0c2b7cbb1b2fdf97fc65c04e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152834 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-12ooxml: import and export border theme colors for various props.Tomaž Vajngerl
This adds support to import and export various border (lines) theme color properties. SvxBoxItem needed to be fixed, because it can happen that the BorderLine is not yet initialised and we already set the border's ComplexColor. Now there is a maTempComplexColor inside SvxBoxItem, which stores the ComplexColor until the specific BorderLine is initialized. In addition add roundtrip test for import and export cycle. Change-Id: Idd307a3adaf364745aed8fc8540bf72ef4948198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152833 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-09oox: remove code duplication and add getComplexColor to oox::ColorTomaž Vajngerl
Change-Id: I9cfbc851d4f303a5a8c92183f01cb5b6545b7984 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152800 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-09MCGR: tdf#155479 repair gradient SVG export for MCGRArmin Le Grand (allotropia)
Unfortunately SVG export is based on metafiles and thus there is (in principle) no way to get the BGradient/ColorStop/MCGR data transfered as needed. For that, using UNO API to read the model or using B2DPrimitives would help - as is better for the export respectively. Since there is not the time to re-design SVG export I added this 'compromize' as a fix. It gets the needed data transported over the metafile (that part is the compromize). It then exports the MCGR data to SVG (at least - as was already there - if it's a linear/axial gradient). This happens now with all Gradient Stops when there is a MCGR gradient. That part is/will hopefully be re-usable if SVG export gets redesigned. I also added a handling for StepCount feature, so when used (in LO, others do not have that) 'hard' color stops get generated to make the gradient look identical for SVG export. Had to make adding of that extra-information in metafiles dependent on exporting really to SVG. There are 51 cases which use 'MetaActionType::COMMENT' which would potentially have to be adapted. Also added code to solve the problem for TransparencePrimitive2D at VclMetafileProcessor2D::processTransparencePrimitive2D. This will now - also only for SVG export - directly create the needed MetaFloatTransparentAction and add additional MCGR information. This will be used on SVG export to write a 'Mask' as was done before. This is now capable of creating fill MCGR-Masks in the sense that any number of TransparencyStops will be supported. Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-08sw: remove char color GrabBag and fix export, fix tint/shade calc.Tomaž Vajngerl
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>
2023-06-01Revert "Convert XFastParser into a normal C++ interface"Noel Grandin
This reverts commit 5e68d6cfade45f40b1ad46025a81afe4cb8dd337. Reason for revert: Seems like outside users have been using this API Change-Id: I8814cf1eb4f000eeb4cbbb5db9c282d001465993 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152441 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-01Convert XFastParser into a normal C++ interfaceNoel Grandin
There is no need for it to be an UNO interface anymore (ever since we started supporting dynamic_cast on UNO objects). Which means that XImportFilter2 also needs become a C++ interface. Change-Id: Ice2db0f098271bba32b199bd083b08cb8410ce93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152388 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-30merge expwrap into sax libraryNoel Grandin
there is no need for 2 shared libs for such a small module Change-Id: Id28c9038f3e16931bfb8af3532eca172998da1aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152374 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-27xmloff: add color-type attribute to complex colorTomaž Vajngerl
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>
2023-05-26MCGR: Border restoration supportArmin Le Grand (allotropia)
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>
2023-05-25xmloff: rename theme color names and color-table to theme-colorsTomaž Vajngerl
For ODF it's not needed to abbreviate names and we prefer to use full names. The theme color names in OOXML are abbreviated and the same names were used also for ODF - this was changed now. "color-table" used in "theme" element has reused the already existing "color-table" element name in ODF, but they don't relate to each other. The name was changed to "theme-colors", which makes more sense anyway. Change-Id: I61ec91895d301ad4343f2b977d5cbcf38e360b99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152252 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-25xmloff: rename *-color-theme-reference to *-complex-colorTomaž Vajngerl
Change-Id: I63dd83522da7699162eb06a019a679d4b8750d10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152053 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-23MCGR: Check correctly for used FillTransparenceGradientArmin Le Grand (allotropia)
To correctly check using UNO API if a FillTransparence- Gradient is used it is necessary to check if a Name for it is set. This corresponds to the IsEnabled() state of the XFillFloatTransparenceItem in the core. This was not consequently done that way and e.g. was done by checking if the FTG was 'default' in the sense that the StartColor was COL_BLACK. This was never sufficient and is not with MCGRs, too. Important in this case is the UnitTest checking for file fdo66688.docx - the re-export/roundtrip goes wrong when not doing this correctly. Change-Id: Iaf14c1e4481188124f044b4b3c8bcd6689c65aad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152087 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-21tdf#155412 ooxml export typeface attribute is mandatoryRegina Henschel
The attribute 'typeface' is required for <a:ea>, <a:cs> and <a:latin> elements, see CT_TextFont in ISO/IEC 29500-1:2016. Its value may be the empty string. Change-Id: I7c9316fa40ad6d1aabccb4191fee11be553c453b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152024 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-05-21oox: convert odp documents to fodp so it is easiert to changeTomaž Vajngerl
Mainly to change the non yet fixed theme ODF format. Change-Id: Iad51de7b4f9a721e566fe12266e633534c15bb54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152052 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-19Fix typoAndrea Gelmini
Change-Id: If39ff84ec74e29fdfcd21194ef371108b591caed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151996 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-19MCGR: Adaptions to WriteGradientFill and BGradientArmin Le Grand (allotropia)
Added code to make WriteGradientFill directly use the available BGradient implementation. The goal is to never directly work on awt::Gradient2, but use BGradient & it's tooling methods. Added constructors and tooling to BGradient and BColorStops to make that easier (single line conversions between uno::Any, basesgfx classes and awt:: incarnations). Directly handle uno::Any and awt:: classes, changed stuff to make use of this. Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-18improved B2DHomMatrixNoel Grandin
since we know that this is a matrix only used for 2D transforms, we know that the last row of the matrix is always { 0, 0, 1 }. Therefore, we don't need to store that information, and we can simplify some of the computations. Also remove operations like operator+ which are not legal for such a matrix. Change-Id: I482de9a45ebbedf79e3b6033575aab590e61c2d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151909 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-16tdf#155327 Detect default color in WordArtRegina Henschel
It is possible to not set the character color explicitely in a WordArt shape. In such case MS Office uses the scheme color 'tx1' from current active scheme. The import of the character properties does not set this color in the fill properties. The patch adds it, when the character fill properties are converted to shape fill properties. Change-Id: Ic72fd9f55bac1e2874cbf701ffa692ca4fbc9435 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151851 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-05-15MCGR: consolidations/cleanups for changes so farArmin Le Grand (allotropia)
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-12use ComplexColor instead of ThemeColor for better OOXML compat.Tomaž Vajngerl
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>
2023-05-09Fix typoAndrea Gelmini
Change-Id: I38877f928fd6943afa1a6c17d8225caef8411d1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151338 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-09change model::ColorSet to be stored in a shared_ptr in model::ThemeTomaž Vajngerl
Change-Id: Ic3067f1681c047cd944e64179c568f4e972e0c95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151447 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08Do not copy decodeXString() string and analyse if there is nothing to decodeEike Rathke
... which usually isn't. Change-Id: I1cadc5a4c0072d5152173ad41e54e25c224e96db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151509 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2023-05-06Use getXWeak in ooxMike Kaganski
Change-Id: I8211a1fe19bbd900f866c46d5b7ec68a37bc38cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150859 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-10 21:20:32 +0000