mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
libreoffice/xmloff/qa/unit/draw.cxx

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

816 lines
38 KiB
C++
Raw Normal View History

tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*/
UnoApiXmlTest: add new wrapper for XmlTestTools tests Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-03 11:42:17 +01:00
#include <test/unoapixml_test.hxx>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
#include <com/sun/star/beans/XPropertySet.hpp>
#include <com/sun/star/drawing/XDrawPageSupplier.hpp>
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
#include <com/sun/star/drawing/EnhancedCustomShapeMetalType.hpp>
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
#include <com/sun/star/drawing/EnhancedCustomShapeSegment.hpp>
#include <com/sun/star/drawing/EnhancedCustomShapeSegmentCommand.hpp>
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
#include <com/sun/star/drawing/XDrawPagesSupplier.hpp>
#include <com/sun/star/drawing/XMasterPageTarget.hpp>
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
#include <com/sun/star/text/XTextRange.hpp>
#include <com/sun/star/text/XTextTable.hpp>
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
#include <com/sun/star/text/GraphicCrop.hpp>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
#include <comphelper/propertyvalue.hxx>
#include <comphelper/sequence.hxx>
Remove some unused includes Mostly com/sun/star/frame/Desktop.hpp is unused after inheriting from UnoApiTest. Change-Id: Ifba307353a11a14e033a230a291314bee86b51c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143190 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-23 20:22:00 +01:00
#include <comphelper/sequenceashashmap.hxx>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
#include <unotools/tempfile.hxx>
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
#include <unotools/saveopt.hxx>
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
#include <svx/unopage.hxx>
#include <svx/svdpage.hxx>
#include <svx/svdomedia.hxx>
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
#include <docmodel/uno/UnoComplexColor.hxx>
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
#include <docmodel/uno/UnoTheme.hxx>
use shared_ptr for model::Theme instead of unique_ptr 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>
2023-02-25 19:12:23 +09:00
#include <docmodel/theme/Theme.hxx>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
using namespace ::com::sun::star;
/// Covers xmloff/source/draw/ fixes.
UnoApiXmlTest: add new wrapper for XmlTestTools tests Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-03 11:42:17 +01:00
class XmloffDrawTest : public UnoApiXmlTest
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
{
public:
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
XmloffDrawTest();
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
uno::Reference<drawing::XShape> getShape(sal_uInt8 nShapeIndex);
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
uno::Reference<beans::XPropertySet>
getShapeTextPortion(sal_uInt32 nIndex, uno::Reference<drawing::XShape> const& xShape)
{
uno::Reference<beans::XPropertySet> xPortion;
uno::Reference<container::XEnumerationAccess> xEnumAccess(xShape, uno::UNO_QUERY);
if (!xEnumAccess->hasElements())
return xPortion;
uno::Reference<container::XEnumeration> xEnum(xEnumAccess->createEnumeration());
uno::Reference<text::XTextContent> xTextContent;
xEnum->nextElement() >>= xTextContent;
if (!xTextContent.is())
return xPortion;
uno::Reference<container::XEnumerationAccess> xParaEnumAccess(xTextContent, uno::UNO_QUERY);
uno::Reference<container::XEnumeration> xParaEnum(xParaEnumAccess->createEnumeration());
sal_uInt32 nCurrent = 0;
xPortion = uno::Reference<beans::XPropertySet>(xParaEnum->nextElement(), uno::UNO_QUERY);
while (nIndex != nCurrent)
{
++nCurrent;
xPortion
= uno::Reference<beans::XPropertySet>(xParaEnum->nextElement(), uno::UNO_QUERY);
}
return xPortion;
}
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
};
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
XmloffDrawTest::XmloffDrawTest()
UnoApiXmlTest: add new wrapper for XmlTestTools tests Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-03 11:42:17 +01:00
: UnoApiXmlTest("/xmloff/qa/unit/data/")
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
{
}
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
uno::Reference<drawing::XShape> XmloffDrawTest::getShape(sal_uInt8 nShapeIndex)
{
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent,
uno::UNO_QUERY_THROW);
uno::Reference<drawing::XDrawPages> xDrawPages(xDrawPagesSupplier->getDrawPages());
uno::Reference<drawing::XDrawPage> xDrawPage(xDrawPages->getByIndex(0), uno::UNO_QUERY_THROW);
uno::Reference<drawing::XShape> xShape(xDrawPage->getByIndex(nShapeIndex),
uno::UNO_QUERY_THROW);
return xShape;
}
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTextBoxLoss)
{
// Load a document that has a shape with a textbox in it. Save it to ODF and reload.
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"textbox-loss.docx");
UnoApiTest: use validate when saving files Change-Id: I0f04fae8b4ff922f5e14ae413cd63cc92a66077e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141797 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-25 10:18:11 +02:00
saveAndReload("impress8");
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
// Make sure that the shape is still a textbox.
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
uno::Reference<drawing::XDrawPageSupplier> xDrawPageSupplier(mxComponent, uno::UNO_QUERY);
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
uno::Reference<drawing::XDrawPage> xDrawPage = xDrawPageSupplier->getDrawPage();
tdf#146449 sw: fix Z-order after undoing Textbox z-order synchronization was missing in case of Undo, resulting broken text boxes. Regression from 504d78acb866495fd954fcd6db22ea68f174a5ab "tdf#143574 sw: textboxes in group shapes - part 1". Change-Id: I2632b7fb40e327f083e680e10b19c8f405df1875 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130875 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: Attila Bakos <bakos.attilakaroly@nisz.hu> Reviewed-by: László Németh <nemeth@numbertext.org>
2022-03-02 14:08:14 +01:00
uno::Reference<beans::XPropertySet> xShape(xDrawPage->getByIndex(1), uno::UNO_QUERY);
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
bool bTextBox = false;
xShape->getPropertyValue("TextBox") >>= bTextBox;
// Without the accompanying fix in place, this test would have failed, as the shape only had
Fix typo Change-Id: Ie3910ffbee6f3a80f077e1c2f3e3112daa96017a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100654 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13 12:45:40 +02:00
// editeng text, losing the image part of the shape text.
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
CPPUNIT_ASSERT(bTextBox);
}
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf141301_Extrusion_Angle)
{
// Load a document that has a custom shape with extrusion direction as set by LO as its default.
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf141301_Extrusion_Skew.odg");
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
// Prepare use of XPath
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("draw8");
xmlDocUniquePtr pXmlDoc = parseExport("content.xml");
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
// Without fix draw:extrusion-skew="50 -135" was not written to file although "50 -135" is not
// default in ODF, but only default inside LO.
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry"_ostr, "extrusion-skew"_ostr, "50 -135");
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
}
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testThemeExport)
{
// Create an Impress document which has a master page which has a theme associated with it.
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
mxComponent = loadFromDesktop("private:factory/simpress");
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterPage(xDrawPage->getMasterPage(), uno::UNO_QUERY);
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
use shared_ptr for model::Theme instead of unique_ptr 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>
2023-02-25 19:12:23 +09:00
auto pTheme = std::make_shared<model::Theme>("mytheme");
change model::ColorSet to be stored in a shared_ptr in model::Theme Change-Id: Ic3067f1681c047cd944e64179c568f4e972e0c95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151447 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-03 22:58:47 +09:00
auto pColorSet = std::make_shared<model::ColorSet>("mycolorscheme");
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
pColorSet->add(model::ThemeColorType::Dark1, 0x0);
pColorSet->add(model::ThemeColorType::Light1, 0x1);
pColorSet->add(model::ThemeColorType::Dark2, 0x2);
pColorSet->add(model::ThemeColorType::Light2, 0x3);
pColorSet->add(model::ThemeColorType::Accent1, 0x4);
pColorSet->add(model::ThemeColorType::Accent2, 0x5);
pColorSet->add(model::ThemeColorType::Accent3, 0x6);
pColorSet->add(model::ThemeColorType::Accent4, 0x7);
pColorSet->add(model::ThemeColorType::Accent5, 0x8);
pColorSet->add(model::ThemeColorType::Accent6, 0x9);
pColorSet->add(model::ThemeColorType::Hyperlink, 0xa);
pColorSet->add(model::ThemeColorType::FollowedHyperlink, 0xb);
change model::ColorSet to be stored in a shared_ptr in model::Theme Change-Id: Ic3067f1681c047cd944e64179c568f4e972e0c95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151447 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-03 22:58:47 +09:00
pTheme->setColorSet(pColorSet);
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
use shared_ptr for model::Theme instead of unique_ptr 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>
2023-02-25 19:12:23 +09:00
uno::Reference<util::XTheme> xTheme = model::theme::createXTheme(pTheme);
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
xMasterPage->setPropertyValue("Theme", uno::Any(xTheme));
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
// Export to ODP:
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("impress8");
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
// Check if the 12 colors are written in the XML:
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
xmlDocUniquePtr pXmlDoc = parseExport("styles.xml");
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
// Without the accompanying fix in place, this test would have failed with:
// - Expected: 12
// - Actual : 0
// - XPath '//style:master-page/loext:theme/loext:color-table/loext:color' number of nodes is incorrect
// i.e. the theme was lost on exporting to ODF.
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, "//style:master-page/loext:theme/loext:theme-colors/loext:color"_ostr, 12);
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
}
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testVideoSnapshot)
{
// Execute ODP import:
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"video-snapshot.odp");
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent,
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
uno::UNO_QUERY_THROW);
CPPUNIT_ASSERT(xDrawPagesSupplier.is());
uno::Reference<drawing::XDrawPages> xDrawPages(xDrawPagesSupplier->getDrawPages());
uno::Reference<drawing::XDrawPage> xDrawPage(xDrawPages->getByIndex(0), uno::UNO_QUERY_THROW);
CPPUNIT_ASSERT(xDrawPage.is());
auto pUnoPage = dynamic_cast<SvxDrawPage*>(xDrawPage.get());
SdrPage* pSdrPage = pUnoPage->GetSdrPage();
auto pMedia = dynamic_cast<SdrMediaObj*>(pSdrPage->GetObj(0));
// Check that the preview was imported:
const avmedia::MediaItem& rItem = pMedia->getMediaProperties();
const Graphic& rGraphic = rItem.getGraphic();
CPPUNIT_ASSERT(!rGraphic.IsNone());
// Check that the crop was imported:
const text::GraphicCrop& rCrop = rItem.getCrop();
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(0), rCrop.Top);
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(0), rCrop.Bottom);
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(1356), rCrop.Left);
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(1356), rCrop.Right);
// Execute ODP export:
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("impress8");
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
xmlDocUniquePtr pXmlDoc = parseExport("content.xml");
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
// Check that the preview was exported:
// Without the accompanying fix in place, this test would have failed with:
// - Expected: 1
// - Actual : 0
// - XPath '//draw:frame[@draw:style-name='gr1']/draw:image' number of nodes is incorrect
// i.e. the preview wasn't exported to ODP.
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, "//draw:frame[@draw:style-name='gr1']/draw:image"_ostr, "href"_ostr,
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
"Pictures/MediaPreview1.png");
// Check that the crop was exported:
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, "//style:style[@style:name='gr1']/style:graphic-properties"_ostr,
"clip"_ostr, "rect(0cm, 1.356cm, 0cm, 1.356cm)");
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
}
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testThemeImport)
{
// Given a document that has a master page with a theme associated:
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"theme.fodp");
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
// Then make sure the doc model has a master page with a theme:
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterpage(xDrawPage->getMasterPage(), uno::UNO_QUERY);
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
uno::Reference<util::XTheme> xTheme;
xMasterpage->getPropertyValue("Theme") >>= xTheme;
// We expect the theme to be set on the master page
CPPUNIT_ASSERT(xTheme.is());
auto* pUnoTheme = dynamic_cast<UnoTheme*>(xTheme.get());
CPPUNIT_ASSERT(pUnoTheme);
use shared_ptr for model::Theme instead of unique_ptr 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>
2023-02-25 19:12:23 +09:00
auto pTheme = pUnoTheme->getTheme();
CPPUNIT_ASSERT(pTheme);
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
use shared_ptr for model::Theme instead of unique_ptr 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>
2023-02-25 19:12:23 +09:00
CPPUNIT_ASSERT_EQUAL(OUString("Office Theme"), pTheme->GetName());
xmloff: rename theme color names and color-table to theme-colors 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-25 13:15:41 +09:00
auto pColorSet = pTheme->getColorSet();
CPPUNIT_ASSERT(pColorSet);
CPPUNIT_ASSERT_EQUAL(OUString("Office"), pColorSet->getName());
sd: use XTheme to transport the theme to xmloff import/export 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>
2023-01-27 15:03:09 +09:00
CPPUNIT_ASSERT_EQUAL(Color(0x954F72),
xmloff: rename theme color names and color-table to theme-colors 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-25 13:15:41 +09:00
pColorSet->getColor(model::ThemeColorType::FollowedHyperlink));
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
}
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
namespace
{
void checkFillAndLineComplexColors(uno::Reference<drawing::XShape> const& xShape)
{
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
{
uno::Reference<util::XComplexColor> xComplexColor;
xShapeProperties->getPropertyValue("FillComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans1.mnValue);
auto const& rTrans2 = aComplexColor.getTransformations()[1];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans2.mnValue);
}
{
uno::Reference<util::XComplexColor> xComplexColor;
xShapeProperties->getPropertyValue("LineComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans1.mnValue);
auto const& rTrans2 = aComplexColor.getTransformations()[1];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans2.mnValue);
}
}
} // end anonymous ns
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testFillAndLineThemeColorExportImport)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"FillAndStrokeThemeColorTest.fodp");
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
checkFillAndLineComplexColors(getShape(0));
save("impress8");
load(maTempFile.GetURL());
checkFillAndLineComplexColors(getShape(0));
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTextAndFillThemeColorExportImport)
ODP import/export: refer to theme from shape text color Refer to the 12 pre-defined colors by name + don't write the attribute for the case when there is no theme. Change-Id: Ib6ab5b7b34d896a36e04309bf0cb410998acce01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126566 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-09 08:43:27 +01:00
{
// Given a document that refers to a theme color:
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"Reference-ThemeColors-TextAndFill.pptx");
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("impress8");
ODP import/export: refer to theme from shape text color Refer to the 12 pre-defined colors by name + don't write the attribute for the case when there is no theme. Change-Id: Ib6ab5b7b34d896a36e04309bf0cb410998acce01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126566 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-09 08:43:27 +01:00
// Make sure the export result has the theme reference:
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
xmlDocUniquePtr pXmlDoc = parseExport("content.xml");
sd theme: add ODP import/export for shape fill color Refer to the 12 pre-defined colors by name + don't write the attribute for the case when there is no theme. Change-Id: I37c984b3371ec878a0d733977f5c937dce27c440 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131717 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-17 20:37:39 +01:00
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
// Text color
OString aStyle1(
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"//style:style[@style:name='T2']/style:text-properties/loext:char-complex-color"_ostr);
assertXPath(pXmlDoc, aStyle1, "color-type"_ostr, "theme");
assertXPath(pXmlDoc, aStyle1, "theme-type"_ostr, "accent3");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[1]", "type"_ostr, "lummod");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[1]", "value"_ostr, "2000");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[2]", "type"_ostr, "lumoff");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[2]", "value"_ostr, "8000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aStyle2(
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"//style:style[@style:name='T3']/style:text-properties/loext:char-complex-color"_ostr);
assertXPath(pXmlDoc, aStyle1, "color-type"_ostr, "theme");
assertXPath(pXmlDoc, aStyle2, "theme-type"_ostr, "accent3");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[1]", "type"_ostr, "lummod");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[1]", "value"_ostr, "6000");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[2]", "type"_ostr, "lumoff");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[2]", "value"_ostr, "4000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aStyle3(
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"//style:style[@style:name='T4']/style:text-properties/loext:char-complex-color"_ostr);
assertXPath(pXmlDoc, aStyle1, "color-type"_ostr, "theme");
assertXPath(pXmlDoc, aStyle3, "theme-type"_ostr, "accent3");
assertXPath(pXmlDoc, aStyle3 + "/loext:transformation[1]", "type"_ostr, "lummod");
assertXPath(pXmlDoc, aStyle3 + "/loext:transformation[1]", "value"_ostr, "5000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
// Shapes fill color
OString aShape1("//style:style[@style:name='gr1']/style:graphic-properties/"
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"loext:fill-complex-color"_ostr);
assertXPath(pXmlDoc, aStyle1, "color-type"_ostr, "theme");
assertXPath(pXmlDoc, aShape1, "theme-type"_ostr, "accent2");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[1]", "type"_ostr, "lummod");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[1]", "value"_ostr, "2000");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[2]", "type"_ostr, "lumoff");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[2]", "value"_ostr, "8000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aShape2("//style:style[@style:name='gr2']/style:graphic-properties/"
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"loext:fill-complex-color"_ostr);
assertXPath(pXmlDoc, aStyle1, "color-type"_ostr, "theme");
assertXPath(pXmlDoc, aShape2, "theme-type"_ostr, "accent2");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[1]", "type"_ostr, "lummod");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[1]", "value"_ostr, "6000");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[2]", "type"_ostr, "lumoff");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[2]", "value"_ostr, "4000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aShape3("//style:style[@style:name='gr3']/style:graphic-properties/"
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"loext:fill-complex-color"_ostr);
assertXPath(pXmlDoc, aStyle1, "color-type"_ostr, "theme");
assertXPath(pXmlDoc, aShape3, "theme-type"_ostr, "accent2");
assertXPath(pXmlDoc, aShape3 + "/loext:transformation[1]", "type"_ostr, "lummod");
assertXPath(pXmlDoc, aShape3 + "/loext:transformation[1]", "value"_ostr, "5000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
// reload
load(maTempFile.GetURL());
// check fill color theme
{
uno::Reference<drawing::XShape> xShape(getShape(0));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
xShapeProperties->getPropertyValue("FillComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings 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>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent2, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(2000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
auto const& rTrans2 = aComplexColor.getTransformations()[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(8000), rTrans2.mnValue);
}
{
uno::Reference<drawing::XShape> xShape(getShape(1));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
xShapeProperties->getPropertyValue("FillComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings 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>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent2, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
auto const& rTrans2 = aComplexColor.getTransformations()[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans2.mnValue);
}
{
uno::Reference<drawing::XShape> xShape(getShape(2));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
xShapeProperties->getPropertyValue("FillComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings 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>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent2, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(1), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(5000), rTrans1.mnValue);
}
// Char color theme
// Shape 4
{
// Check the first text portion properties
uno::Reference<drawing::XShape> xShape(getShape(3));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xPortion = getShapeTextPortion(0, xShape);
CPPUNIT_ASSERT(xPortion.is());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
xPortion->getPropertyValue("CharComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings 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>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
auto const& rTransforms = aComplexColor.getTransformations();
CPPUNIT_ASSERT_EQUAL(size_t(2), rTransforms.size());
auto const& rTrans1 = rTransforms[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(2000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
auto const& rTrans2 = rTransforms[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(8000), rTrans2.mnValue);
}
// Shape 5
{
// Check the first text portion properties
uno::Reference<drawing::XShape> xShape(getShape(4));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xPortion = getShapeTextPortion(0, xShape);
CPPUNIT_ASSERT(xPortion.is());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
xPortion->getPropertyValue("CharComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings 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>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
auto const& rTransforms = aComplexColor.getTransformations();
CPPUNIT_ASSERT_EQUAL(size_t(2), rTransforms.size());
auto const& rTrans1 = rTransforms[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
auto const& rTrans2 = rTransforms[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans2.mnValue);
}
// Shape 6
{
// Check the first text portion properties
uno::Reference<drawing::XShape> xShape(getShape(5));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xPortion = getShapeTextPortion(0, xShape);
CPPUNIT_ASSERT(xPortion.is());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
xPortion->getPropertyValue("CharComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings 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>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(1), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(5000), rTrans1.mnValue);
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testThemeColor_ShapeFill)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"ReferenceShapeFill.pptx");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
save("impress8");
// reload
load(maTempFile.GetURL());
// check fill color theme
uno::Reference<drawing::XShape> xShape(getShape(0));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
xShapeProperties->getPropertyValue("FillComplexColor") >>= xComplexColor;
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings 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>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent6, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(1), aComplexColor.getTransformations().size());
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod,
use ComplexColor instead of ThemeColor for better OOXML compat. 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-08 14:09:00 +09:00
aComplexColor.getTransformations()[0].meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(7500), aComplexColor.getTransformations()[0].mnValue);
ODP import/export: refer to theme from shape text color Refer to the 12 pre-defined colors by name + don't write the attribute for the case when there is no theme. Change-Id: Ib6ab5b7b34d896a36e04309bf0cb410998acce01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126566 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-09 08:43:27 +01:00
}
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTableInShape)
{
// Given a document with a shape with a "FrameX" parent style (starts with Frame, but is not
// Frame):
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"table-in-shape.fodt");
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
// Then make sure the table inside the shape is not lost:
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
uno::Reference<drawing::XDrawPageSupplier> xDrawPageSupplier(mxComponent, uno::UNO_QUERY);
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
uno::Reference<drawing::XDrawPage> xDrawPage = xDrawPageSupplier->getDrawPage();
uno::Reference<text::XTextRange> xShape(xDrawPage->getByIndex(0), uno::UNO_QUERY);
uno::Reference<container::XEnumerationAccess> xText(xShape->getText(), uno::UNO_QUERY);
uno::Reference<container::XEnumeration> xEnum = xText->createEnumeration();
uno::Reference<text::XTextTable> xTable(xEnum->nextElement(), uno::UNO_QUERY);
// Without the accompanying fix in place, this test would have crashed, as xTable was an empty
// reference, i.e. the table inside the shape was lost.
uno::Reference<text::XTextRange> xCell(xTable->getCellByName("A1"), uno::UNO_QUERY);
CPPUNIT_ASSERT_EQUAL(OUString("A1"), xCell->getString());
}
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// Tests for save/load of new (LO 7.4) attribute loext:extrusion-metal-type
namespace
{
void lcl_assertMetalProperties(std::string_view sInfo, uno::Reference<drawing::XShape>& rxShape)
{
uno::Reference<beans::XPropertySet> xShapeProps(rxShape, uno::UNO_QUERY);
uno::Sequence<beans::PropertyValue> aGeoPropSeq;
xShapeProps->getPropertyValue("CustomShapeGeometry") >>= aGeoPropSeq;
comphelper::SequenceAsHashMap aGeoPropMap(aGeoPropSeq);
uno::Sequence<beans::PropertyValue> aExtrusionSeq;
aGeoPropMap.getValue("Extrusion") >>= aExtrusionSeq;
comphelper::SequenceAsHashMap aExtrusionPropMap(aExtrusionSeq);
bool bIsMetal(false);
aExtrusionPropMap.getValue("Metal") >>= bIsMetal;
OString sMsg = OString::Concat(sInfo) + " Metal";
CPPUNIT_ASSERT_MESSAGE(sMsg.getStr(), bIsMetal);
sal_Int16 nMetalType(-1);
aExtrusionPropMap.getValue("MetalType") >>= nMetalType;
sMsg = OString::Concat(sInfo) + " MetalType";
CPPUNIT_ASSERT_EQUAL_MESSAGE(
sMsg.getStr(), css::drawing::EnhancedCustomShapeMetalType::MetalMSCompatible, nMetalType);
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionMetalTypeExtended)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf145700_3D_metal_type_MSCompatible.doc");
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// verify properties
uno::Reference<drawing::XShape> xShape(getShape(0));
lcl_assertMetalProperties("from doc", xShape);
// Test, that new attribute is written with loext namespace. Adapt when attribute is added to ODF.
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("writer8");
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// assert XML.
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
xmlDocUniquePtr pXmlDoc = parseExport("content.xml");
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry"_ostr, "extrusion-metal"_ostr, "true");
assertXPath(
pXmlDoc,
"//draw:enhanced-geometry[@loext:extrusion-metal-type='loext:MetalMSCompatible']"_ostr);
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// reload
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
mxComponent = loadFromDesktop(maTempFile.GetURL(), "com.sun.star.text.TextDocument");
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// verify properties
uno::Reference<drawing::XShape> xShapeReload(getShape(0));
lcl_assertMetalProperties("from ODF 1.3 extended", xShapeReload);
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionMetalTypeStrict)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf145700_3D_metal_type_MSCompatible.doc");
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// save ODF 1.3 strict and test, that new attribute is not written. Adapt when attribute is
// added to ODF.
const SvtSaveOptions::ODFDefaultVersion nCurrentODFVersion(GetODFDefaultVersion());
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013);
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("writer8");
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// assert XML.
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
xmlDocUniquePtr pXmlDoc = parseExport("content.xml");
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry"_ostr, "extrusion-metal"_ostr, "true");
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@loext:extrusion-metal-type]"_ostr, 0);
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
SetODFDefaultVersion(nCurrentODFVersion);
}
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
namespace
{
void lcl_assertSpecularityProperty(std::string_view sInfo, uno::Reference<drawing::XShape>& rxShape)
{
uno::Reference<beans::XPropertySet> xShapeProps(rxShape, uno::UNO_QUERY);
uno::Sequence<beans::PropertyValue> aGeoPropSeq;
xShapeProps->getPropertyValue("CustomShapeGeometry") >>= aGeoPropSeq;
comphelper::SequenceAsHashMap aGeoPropMap(aGeoPropSeq);
uno::Sequence<beans::PropertyValue> aExtrusionSeq;
aGeoPropMap.getValue("Extrusion") >>= aExtrusionSeq;
comphelper::SequenceAsHashMap aExtrusionPropMap(aExtrusionSeq);
double fSpecularity(-1.0);
aExtrusionPropMap.getValue("Specularity") >>= fSpecularity;
OString sMsg = OString::Concat(sInfo) + "Specularity";
CPPUNIT_ASSERT_EQUAL_MESSAGE(sMsg.getStr(), 122.0703125, fSpecularity);
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionSpecularityExtended)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf147580_extrusion-specularity.doc");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
// verify property
uno::Reference<drawing::XShape> xShape(getShape(0));
lcl_assertSpecularityProperty("from doc", xShape);
// Test, that attribute is written in draw namespace with value 100% and in loext namespace with
// value 122.0703125%.
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("writer8");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
// assert XML.
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
xmlDocUniquePtr pXmlDoc = parseExport("content.xml");
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@draw:extrusion-specularity='100%']"_ostr);
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
assertXPath(pXmlDoc,
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"//draw:enhanced-geometry[@loext:extrusion-specularity-loext='122.0703125%']"_ostr);
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
// reload and verify, that the loext value is used
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
mxComponent = loadFromDesktop(maTempFile.GetURL(), "com.sun.star.text.TextDocument");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
// verify properties
uno::Reference<drawing::XShape> xShapeReload(getShape(0));
lcl_assertSpecularityProperty("from ODF 1.3 extended", xShapeReload);
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionSpecularity)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf147580_extrusion-specularity.doc");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
// The file has c3DSpecularAmt="80000" which results internally in specularity=122%.
// Save to ODF 1.3 strict and make sure it does not produce a validation error.
const SvtSaveOptions::ODFDefaultVersion nCurrentODFVersion(GetODFDefaultVersion());
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013);
UnoApiTest: simplify code by using tempfile member SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-04 17:31:55 +01:00
save("writer8");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
SetODFDefaultVersion(nCurrentODFVersion);
}
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
namespace
{
bool lcl_getShapeSegments(uno::Sequence<drawing::EnhancedCustomShapeSegment>& rSegments,
const uno::Reference<drawing::XShape>& xShape)
{
uno::Reference<beans::XPropertySet> xShapeProps(xShape, uno::UNO_QUERY_THROW);
uno::Any anotherAny = xShapeProps->getPropertyValue("CustomShapeGeometry");
uno::Sequence<beans::PropertyValue> aCustomShapeGeometry;
if (!(anotherAny >>= aCustomShapeGeometry))
return false;
uno::Sequence<beans::PropertyValue> aPathProps;
Drop std::as_const from css::uno::Sequence iterations Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code, 2021-11-05). Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-27 15:42:54 +06:00
for (beans::PropertyValue const& rProp : aCustomShapeGeometry)
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
{
if (rProp.Name == "Path")
{
rProp.Value >>= aPathProps;
break;
}
}
Drop std::as_const from css::uno::Sequence iterations Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code, 2021-11-05). Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-27 15:42:54 +06:00
for (beans::PropertyValue const& rProp : aPathProps)
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
{
if (rProp.Name == "Segments")
{
rProp.Value >>= rSegments;
break;
}
}
if (rSegments.getLength() > 2)
return true;
else
return false;
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf148714_CurvedArrowsOld)
{
// Load a document with CurveArrow shapes with faulty path as written by older LO versions.
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf148714_CurvedArrowsOld.odp");
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
// Make sure, that the error has been corrected on opening.
for (sal_Int32 nShapeIndex = 0; nShapeIndex < 4; nShapeIndex++)
{
uno::Reference<drawing::XShape> xShape(getShape(nShapeIndex));
uno::Sequence<drawing::EnhancedCustomShapeSegment> aSegments;
CPPUNIT_ASSERT(lcl_getShapeSegments(aSegments, xShape));
if (nShapeIndex == 0 || nShapeIndex == 3)
{
// curvedDownArrow or curvedLeftArrow. Segments should start with VW. Without fix it was
// V with count 2, which means VV.
CPPUNIT_ASSERT_EQUAL(
sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::CLOCKWISEARC),
aSegments[0].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[0].Count);
CPPUNIT_ASSERT_EQUAL(
sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::CLOCKWISEARCTO),
aSegments[1].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[1].Count);
}
else
{
// curvedUpArrow or curvedRightArrow. Segments should start with BA. Without fix is was
// B with count 2, which means BB.
CPPUNIT_ASSERT_EQUAL(sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::ARC),
aSegments[0].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[0].Count);
CPPUNIT_ASSERT_EQUAL(sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::ARCTO),
aSegments[1].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[1].Count);
}
}
}
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTextRotationPlusPre)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf149551_verticalText.pptx");
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
// The file has a shape with attribute vert="vert" in <bodyPr> element. That generates a
// TextPreRotateAngle attribute in CustomShapeGeometry.
// Add a TextRotateAngle attribute.
uno::Reference<drawing::XShape> xShape(getShape(0));
uno::Reference<beans::XPropertySet> xShapeProps(xShape, uno::UNO_QUERY);
uno::Sequence<beans::PropertyValue> aGeomSeq;
xShapeProps->getPropertyValue("CustomShapeGeometry") >>= aGeomSeq;
auto aGeomVec(comphelper::sequenceToContainer<std::vector<beans::PropertyValue>>(aGeomSeq));
aGeomVec.push_back(comphelper::makePropertyValue("TextRotateAngle", sal_Int32(45)));
aGeomSeq = comphelper::containerToSequence(aGeomVec);
xShapeProps->setPropertyValue("CustomShapeGeometry", uno::Any(aGeomSeq));
// Save to ODF. Without the fix, a file format error was produced, because attribute
// draw:text-rotate-angle was written twice, one from TextPreRotateAngle and the other from
// TextRotateAngle.
// This should already catch the format error, but does not, see tdf#149567
// But reload catches it.
UnoApiTest: use validate when saving files Change-Id: I0f04fae8b4ff922f5e14ae413cd63cc92a66077e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141797 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-25 10:18:11 +02:00
saveAndReload("writer8");
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
}
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf156975_ThemeExport)
{
// It tests, that a theme is written to master page in Draw documents.
// Without fix for tdf#156975 it was not written at all.
// The test needs to be adapted, when themes are available in ODF.
mxComponent = loadFromDesktop("private:factory/sdraw");
// generate a theme to be sure we have got one and know the values
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterPageProps(xDrawPage->getMasterPage(),
uno::UNO_QUERY);
auto pTheme = std::make_shared<model::Theme>("Custom");
auto pColorSet = std::make_shared<model::ColorSet>("My Colors");
pColorSet->add(model::ThemeColorType::Dark1, 0x000000);
pColorSet->add(model::ThemeColorType::Light1, 0xffff11);
pColorSet->add(model::ThemeColorType::Dark2, 0x002200);
pColorSet->add(model::ThemeColorType::Light2, 0xff33ff);
pColorSet->add(model::ThemeColorType::Accent1, 0x440000);
pColorSet->add(model::ThemeColorType::Accent2, 0x005500);
pColorSet->add(model::ThemeColorType::Accent3, 0x000066);
pColorSet->add(model::ThemeColorType::Accent4, 0x777700);
pColorSet->add(model::ThemeColorType::Accent5, 0x880088);
pColorSet->add(model::ThemeColorType::Accent6, 0x009999);
pColorSet->add(model::ThemeColorType::Hyperlink, 0x0a0a0a);
pColorSet->add(model::ThemeColorType::FollowedHyperlink, 0xb0b0b0);
pTheme->setColorSet(pColorSet);
uno::Reference<util::XTheme> xTheme = model::theme::createXTheme(pTheme);
xMasterPageProps->setPropertyValue("Theme", uno::Any(xTheme));
// save as odg
save("draw8");
// and check the markup.
xmlDocUniquePtr pXmlDoc = parseExport("styles.xml");
Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: xmloff Change-Id: I2d58bbea770c4dd188cae13e11218a29f4cd5d05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158294 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-19 10:30:42 +02:00
static constexpr OString sThemePath
= "//office:master-styles/style:master-page/loext:theme"_ostr;
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
assertXPath(pXmlDoc, sThemePath, 1);
assertXPath(pXmlDoc, sThemePath + "[@loext:name='Custom']");
const OString sThemeColorsPath = sThemePath + "/loext:theme-colors";
assertXPath(pXmlDoc, sThemeColorsPath, 1);
assertXPath(pXmlDoc, sThemeColorsPath + "[@loext:name='My Colors']");
const OString sThemeColorPath = sThemeColorsPath + "/loext:color";
assertXPath(pXmlDoc, sThemeColorPath, 12);
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
assertXPath(pXmlDoc, sThemeColorPath + "[3]", "name"_ostr, "dark2");
assertXPath(pXmlDoc, sThemeColorPath + "[3]", "color"_ostr, "#002200");
assertXPath(pXmlDoc, sThemeColorPath + "[9]", "name"_ostr, "accent5");
assertXPath(pXmlDoc, sThemeColorPath + "[9]", "color"_ostr, "#880088");
assertXPath(pXmlDoc, sThemeColorPath + "[12]", "name"_ostr, "followed-hyperlink");
assertXPath(pXmlDoc, sThemeColorPath + "[12]", "color"_ostr, "#b0b0b0");
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
}
tdf#157018 Enable import of color theme for Draw Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-31 01:15:26 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf157018_ThemeImportDraw)
{
// Similar to testThemeImport but for Draw.
// Load document with custom color theme
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf157018_CustomTheme.fodg");
tdf#157018 Enable import of color theme for Draw Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-31 01:15:26 +02:00
// First make sure the doc model has a master page with a theme:
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterpage(xDrawPage->getMasterPage(), uno::UNO_QUERY);
uno::Reference<util::XTheme> xTheme;
xMasterpage->getPropertyValue("Theme") >>= xTheme;
CPPUNIT_ASSERT(xTheme.is());
// Then make sure it is the custom color theme
auto* pUnoTheme = dynamic_cast<UnoTheme*>(xTheme.get());
CPPUNIT_ASSERT(pUnoTheme);
auto pTheme = pUnoTheme->getTheme();
CPPUNIT_ASSERT(pTheme);
CPPUNIT_ASSERT_EQUAL(OUString("Custom"), pTheme->GetName());
auto pColorSet = pTheme->getColorSet();
CPPUNIT_ASSERT(pColorSet);
CPPUNIT_ASSERT_EQUAL(OUString("My Colors"), pColorSet->getName());
// and test some colors
CPPUNIT_ASSERT_EQUAL(Color(0xFFFF11), pColorSet->getColor(model::ThemeColorType::Light1));
CPPUNIT_ASSERT_EQUAL(Color(0x0A0A0A), pColorSet->getColor(model::ThemeColorType::Hyperlink));
CPPUNIT_ASSERT_EQUAL(Color(0x440000), pColorSet->getColor(model::ThemeColorType::Accent1));
}
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
Reference in New Issue Copy Permalink