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

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

510 lines
23 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/.
*/
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
#include <test/unoapi_test.hxx>
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
#include <test/xmltesttools.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>
#include <com/sun/star/frame/Desktop.hpp>
#include <com/sun/star/frame/XStorable.hpp>
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
#include <com/sun/star/packages/zip/ZipFileAccess.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>
#include <com/sun/star/util/Color.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>
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/mediadescriptor.hxx>
#include <unotools/tempfile.hxx>
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
#include <unotools/ucbstreamhelper.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>
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.
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
class XmloffDrawTest : public UnoApiTest, public XmlTestTools
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#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
void registerNamespaces(xmlXPathContextPtr& pXmlXpathCtx) override;
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);
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()
: UnoApiTest("/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#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
void XmloffDrawTest::registerNamespaces(xmlXPathContextPtr& pXmlXpathCtx)
{
XmlTestTools::registerODFNamespaces(pXmlXpathCtx);
}
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.
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
loadFromURL(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.
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
loadFromURL(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
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
utl::TempFileNamed aTempFile = save("draw8");
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
uno::Reference<packages::zip::XZipFileAccess2> xNameAccess
= packages::zip::ZipFileAccess::createWithURL(mxComponentContext, aTempFile.GetURL());
uno::Reference<io::XInputStream> xInputStream(xNameAccess->getByName("content.xml"),
uno::UNO_QUERY);
std::unique_ptr<SvStream> pStream(utl::UcbStreamHelper::CreateStream(xInputStream, true));
xmlDocUniquePtr pXmlDoc = parseXmlStream(pStream.get());
// 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.
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-skew", "50 -135");
}
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);
comphelper::SequenceAsHashMap aMap;
aMap["Name"] <<= OUString("mytheme");
aMap["ColorSchemeName"] <<= OUString("mycolorscheme");
uno::Sequence<util::Color> aColorScheme
= { 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb };
aMap["ColorScheme"] <<= aColorScheme;
Just use Any ctor instead of makeAny in xmloff Change-Id: Ibefb18e5b798ccf1f9d7a5ba1524c9fb1e9bee32 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133700 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-02 14:25:43 +02:00
uno::Any aTheme(aMap.getAsConstPropertyValueList());
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
xMasterPage->setPropertyValue("Theme", aTheme);
// Export to 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
utl::TempFileNamed aTempFile = 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:
std::unique_ptr<SvStream> pStream = parseExportStream(aTempFile, "styles.xml");
xmlDocUniquePtr pXmlDoc = parseXmlStream(pStream.get());
// 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.
assertXPath(pXmlDoc, "//style:master-page/loext:theme/loext:color-table/loext:color", 12);
}
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:
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
loadFromURL(u"video-snapshot.odp");
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:
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
utl::TempFileNamed aTempFile = 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
std::unique_ptr<SvStream> pStream = parseExportStream(aTempFile, "content.xml");
xmlDocUniquePtr pXmlDoc = parseXmlStream(pStream.get());
// 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.
assertXPath(pXmlDoc, "//draw:frame[@draw:style-name='gr1']/draw:image", "href",
"Pictures/MediaPreview1.png");
// Check that the crop was exported:
assertXPath(pXmlDoc, "//style:style[@style:name='gr1']/style:graphic-properties", "clip",
"rect(0cm, 1.356cm, 0cm, 1.356cm)");
}
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:
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
loadFromURL(u"theme.odp");
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);
comphelper::SequenceAsHashMap aMap(xMasterpage->getPropertyValue("Theme"));
// Without the accompanying fix in place, this test would have failed with:
// Cannot extract an Any(void) to string!
// i.e. the master page had no theme.
CPPUNIT_ASSERT_EQUAL(OUString("Office Theme"), aMap["Name"].get<OUString>());
CPPUNIT_ASSERT_EQUAL(OUString("Office"), aMap["ColorSchemeName"].get<OUString>());
auto aColorScheme = aMap["ColorScheme"].get<uno::Sequence<util::Color>>();
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(12), aColorScheme.getLength());
CPPUNIT_ASSERT_EQUAL(static_cast<util::Color>(0x954F72), aColorScheme[11]);
}
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
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testReferToTheme)
{
// Given a document that refers to a theme color:
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
loadFromURL(u"refer-to-theme.odp");
utl::TempFileNamed aTempFile = 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:
std::unique_ptr<SvStream> pStream = parseExportStream(aTempFile, "content.xml");
xmlDocUniquePtr pXmlDoc = parseXmlStream(pStream.get());
// Without the accompanying fix in place, this test would have failed with:
// - XPath '//style:style[@style:name='T1']/style:text-properties' no attribute 'theme-color' exist
// i.e. only the direct color was written, but not the theme reference.
assertXPath(pXmlDoc, "//style:style[@style:name='T1']/style:text-properties", "theme-color",
"accent1");
ODP import/export: refer to theme from shape text color with effects Handle luminance modulation and offset (i.e. lighter and darker colors). Change-Id: I536bbca1ed994e991c7ceac153d6a47cb6ef35f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126722 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-13 08:41:10 +01:00
assertXPathNoAttribute(pXmlDoc, "//style:style[@style:name='T1']/style:text-properties",
"color-lum-mod");
assertXPathNoAttribute(pXmlDoc, "//style:style[@style:name='T1']/style:text-properties",
"color-lum-off");
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
assertXPath(pXmlDoc, "//style:style[@style:name='T2']/style:text-properties", "theme-color",
"accent1");
ODP import/export: refer to theme from shape text color with effects Handle luminance modulation and offset (i.e. lighter and darker colors). Change-Id: I536bbca1ed994e991c7ceac153d6a47cb6ef35f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126722 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-13 08:41:10 +01:00
// Without the accompanying fix in place, this test would have failed with:
// - XPath '//style:style[@style:name='T2']/style:text-properties' no attribute 'color-lum-mod' exist
// i.e. effects on a referenced theme color were lost.
assertXPath(pXmlDoc, "//style:style[@style:name='T2']/style:text-properties", "color-lum-mod",
"40%");
assertXPath(pXmlDoc, "//style:style[@style:name='T2']/style:text-properties", "color-lum-off",
"60%");
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
assertXPath(pXmlDoc, "//style:style[@style:name='T3']/style:text-properties", "theme-color",
"accent1");
ODP import/export: refer to theme from shape text color with effects Handle luminance modulation and offset (i.e. lighter and darker colors). Change-Id: I536bbca1ed994e991c7ceac153d6a47cb6ef35f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126722 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-13 08:41:10 +01:00
assertXPath(pXmlDoc, "//style:style[@style:name='T3']/style:text-properties", "color-lum-mod",
"75%");
assertXPathNoAttribute(pXmlDoc, "//style:style[@style:name='T3']/style:text-properties",
"color-lum-off");
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
// Without the accompanying fix in place, this test would have failed with:
// - XPath '//style:style[@style:name='gr2']/style:graphic-properties' no attribute 'fill-theme-color' exist
// i.e. only the direct color was written, but not the theme reference.
assertXPath(pXmlDoc, "//style:style[@style:name='gr2']/style:graphic-properties",
"fill-theme-color", "accent1");
sd theme: add ODP import/export for shape fill color effects Map a themed color with effects to: <style:graphic-properties draw:fill-color="..." loext:fill-theme-color="..." loext:fill-color-lum-mod="..." loext:fill-color-lum-off="..."> Change-Id: I18d8ddf8d6050ef468a8d67a9e797a576f682e85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133843 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-05-04 20:23:16 +02:00
// Shape fill, 60% lighter.
assertXPath(pXmlDoc, "//style:style[@style:name='gr3']/style:graphic-properties",
"fill-theme-color", "accent1");
// Without the accompanying fix in place, this test would have failed with:
// - XPath '//style:style[@style:name='gr3']/style:graphic-properties' no attribute 'fill-color-lum-mod' exist
// i.e. the themed color was fine, but its effects were lost.
assertXPath(pXmlDoc, "//style:style[@style:name='gr3']/style:graphic-properties",
"fill-color-lum-mod", "40%");
assertXPath(pXmlDoc, "//style:style[@style:name='gr3']/style:graphic-properties",
"fill-color-lum-off", "60%");
// Shape fill, 25% darker.
assertXPath(pXmlDoc, "//style:style[@style:name='gr4']/style:graphic-properties",
"fill-theme-color", "accent1");
assertXPath(pXmlDoc, "//style:style[@style:name='gr4']/style:graphic-properties",
"fill-color-lum-mod", "75%");
assertXPathNoAttribute(pXmlDoc, "//style:style[@style:name='gr4']/style:graphic-properties",
"fill-color-lum-off");
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):
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
loadFromURL(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)
{
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
loadFromURL(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.
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
utl::TempFileNamed aTempFile = 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.
std::unique_ptr<SvStream> pStream = parseExportStream(aTempFile, "content.xml");
xmlDocUniquePtr pXmlDoc = parseXmlStream(pStream.get());
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal", "true");
assertXPath(pXmlDoc,
"//draw:enhanced-geometry[@loext:extrusion-metal-type='loext:MetalMSCompatible']");
// reload
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(aTempFile.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)
{
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
loadFromURL(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);
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
utl::TempFileNamed aTempFile = 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.
std::unique_ptr<SvStream> pStream = parseExportStream(aTempFile, "content.xml");
xmlDocUniquePtr pXmlDoc = parseXmlStream(pStream.get());
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal", "true");
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@loext:extrusion-metal-type]", 0);
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)
{
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
loadFromURL(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%.
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
utl::TempFileNamed aTempFile = 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.
std::unique_ptr<SvStream> pStream = parseExportStream(aTempFile, "content.xml");
xmlDocUniquePtr pXmlDoc = parseXmlStream(pStream.get());
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@draw:extrusion-specularity='100%']");
assertXPath(pXmlDoc,
"//draw:enhanced-geometry[@loext:extrusion-specularity-loext='122.0703125%']");
// reload and verify, that the loext value is used
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(aTempFile.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)
{
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
loadFromURL(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);
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
utl::TempFileNamed aTempFile = 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;
for (beans::PropertyValue const& rProp : std::as_const(aCustomShapeGeometry))
{
if (rProp.Name == "Path")
{
rProp.Value >>= aPathProps;
break;
}
}
for (beans::PropertyValue const& rProp : std::as_const(aPathProps))
{
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.
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
loadFromURL(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)
{
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
loadFromURL(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#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