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

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

1135 lines
52 KiB
C++
Raw Permalink Normal View History

tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*/
UnoApiXmlTest: add new wrapper for XmlTestTools tests Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-03 11:42:17 +01:00
#include <test/unoapixml_test.hxx>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
#include <com/sun/star/beans/XPropertySet.hpp>
#include <com/sun/star/drawing/XDrawPageSupplier.hpp>
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
#include <com/sun/star/drawing/EnhancedCustomShapeMetalType.hpp>
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
#include <com/sun/star/drawing/EnhancedCustomShapeSegment.hpp>
#include <com/sun/star/drawing/EnhancedCustomShapeSegmentCommand.hpp>
tdf#161327 Interpret angle units in dr3d:end-angle .. .. and draw:rotation in <draw:hatch> element. ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2 it is specified as double with unit "deg", "grad" or "rad", or without unit. The unit-less value is specified to be in degrees. But OOo, AOO and all LO versions had written the value unit-less in 1/10th of a degree in some cases. To fix it, LibreOffic will be enabled to read units. When then the active versions are able to read units, starting with the then actual version, LibreOffice will write angles with unit 'deg'. This has already be done for gradients, see tdf#89475. This patch starts the first step to make LibreOffice able to read units for dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO FillHatch.Angle). I have not found further cases of writing 1/10deg. The patch still writes unit-less 1/10th of a degree for export to ODF 1.3 and earlier. When it is time to write unit degree or when LibreOffice supports the next ODF versions, some places need to be adapted. They are marked. The converter convertAngle is renamed to convert10thDegAngle() to indicate, that it is special. The parts, which were specific to gradients are moved to the gradients, so that it is now usable for dr3d:angle and draw:rotation too. I intend to write next a patch that enables LibreOffice to read angle units for cases where LibreOffice already writes unit-less values in degree. That is not so urgent, but to bring LibreOffice nearer to ODF, reading angle units should be implemented nevertheless. The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc to have access to it from xmloff/source/draw. Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-06-01 19:50:47 +02:00
#include <com/sun/star/drawing/FillStyle.hpp>
#include <com/sun/star/drawing/Hatch.hpp>
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
#include <com/sun/star/drawing/XDrawPagesSupplier.hpp>
#include <com/sun/star/drawing/XMasterPageTarget.hpp>
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
#include <com/sun/star/text/XTextRange.hpp>
#include <com/sun/star/text/XTextTable.hpp>
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
#include <com/sun/star/text/GraphicCrop.hpp>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
#include <comphelper/propertyvalue.hxx>
[API CHANGE] sd pdfium: add page number when saving/loading pdf pages as images When a pdf file is opened with pdfium and then saved as odg, each page is saved as a draw:image of the pdf. But since no page number info was given, when opening the odg file, all the pages are shown as the first one. This adds a loext:page-number to the saved odg and the logic to load a specific page from an embedded pdf. Added loadGraphicAtPage to XGraphicStorageHandler. Change-Id: I398b7ad7f03cc7fb930a4e7b7620c6f238b41c0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181066 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2025-01-28 10:13:11 +01:00
#include <comphelper/scopeguard.hxx>
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/sequence.hxx>
Remove some unused includes Mostly com/sun/star/frame/Desktop.hpp is unused after inheriting from UnoApiTest. Change-Id: Ifba307353a11a14e033a230a291314bee86b51c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143190 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-23 20:22:00 +01:00
#include <comphelper/sequenceashashmap.hxx>
[API CHANGE] sd pdfium: add page number when saving/loading pdf pages as images When a pdf file is opened with pdfium and then saved as odg, each page is saved as a draw:image of the pdf. But since no page number info was given, when opening the odg file, all the pages are shown as the first one. This adds a loext:page-number to the saved odg and the logic to load a specific page from an embedded pdf. Added loadGraphicAtPage to XGraphicStorageHandler. Change-Id: I398b7ad7f03cc7fb930a4e7b7620c6f238b41c0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181066 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2025-01-28 10:13:11 +01:00
#include <osl/process.h>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
#include <unotools/tempfile.hxx>
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
#include <unotools/saveopt.hxx>
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
#include <svx/unopage.hxx>
#include <svx/svdpage.hxx>
#include <svx/svdomedia.hxx>
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
#include <docmodel/uno/UnoComplexColor.hxx>
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
#include <docmodel/uno/UnoTheme.hxx>
use shared_ptr for model::Theme instead of unique_ptr Also change other cases to use the shared_ptr so there is no need to do copies and replace some of docmodel/theme/Theme.hxximports with forward declarations. Change-Id: I4588cb25e05e5f3e535011fffb68a8075b05aecc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147691 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-02-25 19:12:23 +09:00
#include <docmodel/theme/Theme.hxx>
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
using namespace ::com::sun::star;
/// Covers xmloff/source/draw/ fixes.
UnoApiXmlTest: add new wrapper for XmlTestTools tests Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-03 11:42:17 +01:00
class XmloffDrawTest : public UnoApiXmlTest
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
{
public:
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
XmloffDrawTest();
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
uno::Reference<drawing::XShape> getShape(sal_uInt8 nShapeIndex);
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
uno::Reference<beans::XPropertySet>
getShapeTextPortion(sal_uInt32 nIndex, uno::Reference<drawing::XShape> const& xShape)
{
uno::Reference<beans::XPropertySet> xPortion;
uno::Reference<container::XEnumerationAccess> xEnumAccess(xShape, uno::UNO_QUERY);
if (!xEnumAccess->hasElements())
return xPortion;
uno::Reference<container::XEnumeration> xEnum(xEnumAccess->createEnumeration());
uno::Reference<text::XTextContent> xTextContent;
xEnum->nextElement() >>= xTextContent;
if (!xTextContent.is())
return xPortion;
uno::Reference<container::XEnumerationAccess> xParaEnumAccess(xTextContent, uno::UNO_QUERY);
uno::Reference<container::XEnumeration> xParaEnum(xParaEnumAccess->createEnumeration());
sal_uInt32 nCurrent = 0;
xPortion = uno::Reference<beans::XPropertySet>(xParaEnum->nextElement(), uno::UNO_QUERY);
while (nIndex != nCurrent)
{
++nCurrent;
xPortion
= uno::Reference<beans::XPropertySet>(xParaEnum->nextElement(), uno::UNO_QUERY);
}
return xPortion;
}
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
};
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
XmloffDrawTest::XmloffDrawTest()
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
: UnoApiXmlTest(u"/xmloff/qa/unit/data/"_ustr)
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
{
}
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
uno::Reference<drawing::XShape> XmloffDrawTest::getShape(sal_uInt8 nShapeIndex)
{
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent,
uno::UNO_QUERY_THROW);
uno::Reference<drawing::XDrawPages> xDrawPages(xDrawPagesSupplier->getDrawPages());
uno::Reference<drawing::XDrawPage> xDrawPage(xDrawPages->getByIndex(0), uno::UNO_QUERY_THROW);
uno::Reference<drawing::XShape> xShape(xDrawPage->getByIndex(nShapeIndex),
uno::UNO_QUERY_THROW);
return xShape;
}
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTextBoxLoss)
{
// Load a document that has a shape with a textbox in it. Save it to ODF and reload.
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"textbox-loss.docx");
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
saveAndReload(u"impress8"_ustr);
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;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShape->getPropertyValue(u"TextBox"_ustr) >>= bTextBox;
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
// Without the accompanying fix in place, this test would have failed, as the shape only had
Fix typo Change-Id: Ie3910ffbee6f3a80f077e1c2f3e3112daa96017a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100654 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-13 12:45:40 +02:00
// editeng text, losing the image part of the shape text.
tdf#135144 xmloff textbox: fix export style name to be consitent with import Regression from commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26), the problem was that in case the import side in SdXMLCustomShapeContext expects a fixed "Frame" parent style name, then the export side should go with that name as well. Fix the problem by simplifying XMLShapeExport::collectShapeAutoStyles(), which initially assumed that the string may be localized, so try to look it up: instead just use the fixed string that the import side will look for. This solves all problem which may stem from a parent style name which is non-empty, but other than Frame. Change-Id: I8146440c591d3dd5a904d243d85741d704711e9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100577 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-12 09:06:14 +02:00
CPPUNIT_ASSERT(bTextBox);
}
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf141301_Extrusion_Angle)
{
// Load a document that has a custom shape with extrusion direction as set by LO as its default.
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf141301_Extrusion_Skew.odg");
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
// Prepare use of XPath
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"draw8"_ustr);
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
// Without fix draw:extrusion-skew="50 -135" was not written to file although "50 -135" is not
// default in ODF, but only default inside LO.
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-skew", u"50 -135");
tdf#141301: extrusion-skew angle value -135 is not written to file... whereas it should since not default value (Regina) Hopefully in some years missing values are unlikely and bug tdf#141127 can be fixed. (Regina) I have added a unit test to Julien's patch. Change-Id: Ia2aabd8e724e3c3db9ae8a87cb27707aa7040fb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113257 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2021-03-28 18:21:04 +02:00
}
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testThemeExport)
{
// Create an Impress document which has a master page which has a theme associated with it.
UnoApiTest: rename load to loadFromURL and use it everywhere Change-Id: Ie67eebec74f783fa0c29acfb23bb83bc582812b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175724 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-10-28 14:36:38 +01:00
loadFromURL(u"private:factory/simpress"_ustr);
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 export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterPage(xDrawPage->getMasterPage(), uno::UNO_QUERY);
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
use shared_ptr for model::Theme instead of unique_ptr Also change other cases to use the shared_ptr so there is no need to do copies and replace some of docmodel/theme/Theme.hxximports with forward declarations. Change-Id: I4588cb25e05e5f3e535011fffb68a8075b05aecc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147691 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-02-25 19:12:23 +09:00
auto pTheme = std::make_shared<model::Theme>("mytheme");
change model::ColorSet to be stored in a shared_ptr in model::Theme Change-Id: Ic3067f1681c047cd944e64179c568f4e972e0c95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151447 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-03 22:58:47 +09:00
auto pColorSet = std::make_shared<model::ColorSet>("mycolorscheme");
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
pColorSet->add(model::ThemeColorType::Dark1, 0x0);
pColorSet->add(model::ThemeColorType::Light1, 0x1);
pColorSet->add(model::ThemeColorType::Dark2, 0x2);
pColorSet->add(model::ThemeColorType::Light2, 0x3);
pColorSet->add(model::ThemeColorType::Accent1, 0x4);
pColorSet->add(model::ThemeColorType::Accent2, 0x5);
pColorSet->add(model::ThemeColorType::Accent3, 0x6);
pColorSet->add(model::ThemeColorType::Accent4, 0x7);
pColorSet->add(model::ThemeColorType::Accent5, 0x8);
pColorSet->add(model::ThemeColorType::Accent6, 0x9);
pColorSet->add(model::ThemeColorType::Hyperlink, 0xa);
pColorSet->add(model::ThemeColorType::FollowedHyperlink, 0xb);
change model::ColorSet to be stored in a shared_ptr in model::Theme Change-Id: Ic3067f1681c047cd944e64179c568f4e972e0c95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151447 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-03 22:58:47 +09:00
pTheme->setColorSet(pColorSet);
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
use shared_ptr for model::Theme instead of unique_ptr Also change other cases to use the shared_ptr so there is no need to do copies and replace some of docmodel/theme/Theme.hxximports with forward declarations. Change-Id: I4588cb25e05e5f3e535011fffb68a8075b05aecc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147691 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-02-25 19:12:23 +09:00
uno::Reference<util::XTheme> xTheme = model::theme::createXTheme(pTheme);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xMasterPage->setPropertyValue(u"Theme"_ustr, uno::Any(xTheme));
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
// Export to ODP:
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"impress8"_ustr);
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:
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xmlDocUniquePtr pXmlDoc = parseExport(u"styles.xml"_ustr);
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
// Without the accompanying fix in place, this test would have failed with:
// - Expected: 12
// - Actual : 0
// - XPath '//style:master-page/loext:theme/loext:color-table/loext:color' number of nodes is incorrect
// i.e. the theme was lost on exporting to ODF.
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, "//style:master-page/loext:theme/loext:theme-colors/loext:color", 12);
ODP export: write the theme of a master page Which requires describing the schema, which is really just a new <loext:theme> element, the rest reuses the color-table markup, which wasn't used in ODF so far (but was used in our .soc files). Also make sure that we only do this in ODF extended mode (which is the default). Change-Id: I90eaad30f63946c441fe0c53caf6a47caf1714d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126466 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-07 08:32:30 +01:00
}
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testVideoSnapshot)
{
// Execute ODP import:
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"video-snapshot.odp");
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent,
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
uno::UNO_QUERY_THROW);
CPPUNIT_ASSERT(xDrawPagesSupplier.is());
uno::Reference<drawing::XDrawPages> xDrawPages(xDrawPagesSupplier->getDrawPages());
uno::Reference<drawing::XDrawPage> xDrawPage(xDrawPages->getByIndex(0), uno::UNO_QUERY_THROW);
CPPUNIT_ASSERT(xDrawPage.is());
auto pUnoPage = dynamic_cast<SvxDrawPage*>(xDrawPage.get());
SdrPage* pSdrPage = pUnoPage->GetSdrPage();
auto pMedia = dynamic_cast<SdrMediaObj*>(pSdrPage->GetObj(0));
// Check that the preview was imported:
const avmedia::MediaItem& rItem = pMedia->getMediaProperties();
const Graphic& rGraphic = rItem.getGraphic();
CPPUNIT_ASSERT(!rGraphic.IsNone());
// Check that the crop was imported:
const text::GraphicCrop& rCrop = rItem.getCrop();
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(0), rCrop.Top);
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(0), rCrop.Bottom);
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(1356), rCrop.Left);
CPPUNIT_ASSERT_EQUAL(static_cast<sal_Int32>(1356), rCrop.Right);
// Execute ODP export:
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"impress8"_ustr);
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
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
// Check that the preview was exported:
// Without the accompanying fix in place, this test would have failed with:
// - Expected: 1
// - Actual : 0
// - XPath '//draw:frame[@draw:style-name='gr1']/draw:image' number of nodes is incorrect
// i.e. the preview wasn't exported to ODP.
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, "//draw:frame[@draw:style-name='gr1']/draw:image", "href",
u"Pictures/MediaPreview1.png");
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
// Check that the crop was exported:
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, "//style:style[@style:name='gr1']/style:graphic-properties", "clip",
u"rect(0cm, 1.356cm, 0cm, 1.356cm)");
avmedia: implement video crop support in the ODP filter And also import/export the video preview as well. The naming follows the style used for table shape previews. The preview is important, since the cropping is relative to the bitmap's preferred logic size. Change-Id: I6115284c1f4cf342b3296cd0ac3beb70a809fd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138959 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-08-29 09:23:22 +02:00
}
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testThemeImport)
{
// Given a document that has a master page with a theme associated:
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"theme.fodp");
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
// Then make sure the doc model has a master page with a theme:
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterpage(xDrawPage->getMasterPage(), uno::UNO_QUERY);
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
uno::Reference<util::XTheme> xTheme;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xMasterpage->getPropertyValue(u"Theme"_ustr) >>= xTheme;
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
// We expect the theme to be set on the master page
CPPUNIT_ASSERT(xTheme.is());
auto* pUnoTheme = dynamic_cast<UnoTheme*>(xTheme.get());
CPPUNIT_ASSERT(pUnoTheme);
use shared_ptr for model::Theme instead of unique_ptr Also change other cases to use the shared_ptr so there is no need to do copies and replace some of docmodel/theme/Theme.hxximports with forward declarations. Change-Id: I4588cb25e05e5f3e535011fffb68a8075b05aecc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147691 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-02-25 19:12:23 +09:00
auto pTheme = pUnoTheme->getTheme();
CPPUNIT_ASSERT(pTheme);
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
CPPUNIT_ASSERT_EQUAL(u"Office Theme"_ustr, pTheme->GetName());
xmloff: rename theme color names and color-table to theme-colors For ODF it's not needed to abbreviate names and we prefer to use full names. The theme color names in OOXML are abbreviated and the same names were used also for ODF - this was changed now. "color-table" used in "theme" element has reused the already existing "color-table" element name in ODF, but they don't relate to each other. The name was changed to "theme-colors", which makes more sense anyway. Change-Id: I61ec91895d301ad4343f2b977d5cbcf38e360b99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152252 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-25 13:15:41 +09:00
auto pColorSet = pTheme->getColorSet();
CPPUNIT_ASSERT(pColorSet);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
CPPUNIT_ASSERT_EQUAL(u"Office"_ustr, pColorSet->getName());
sd: use XTheme to transport the theme to xmloff import/export Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-27 15:03:09 +09:00
CPPUNIT_ASSERT_EQUAL(Color(0x954F72),
xmloff: rename theme color names and color-table to theme-colors For ODF it's not needed to abbreviate names and we prefer to use full names. The theme color names in OOXML are abbreviated and the same names were used also for ODF - this was changed now. "color-table" used in "theme" element has reused the already existing "color-table" element name in ODF, but they don't relate to each other. The name was changed to "theme-colors", which makes more sense anyway. Change-Id: I61ec91895d301ad4343f2b977d5cbcf38e360b99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152252 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-25 13:15:41 +09:00
pColorSet->getColor(model::ThemeColorType::FollowedHyperlink));
ODP import: handle theme of master pages This is just the theme itself, we don't refer to this theme from e.g. shape text color yet. Change-Id: I0d8f4b06217fb491e47d775628fde742d8ff104d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126502 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-08 08:42:18 +01:00
}
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
namespace
{
void checkFillAndLineComplexColors(uno::Reference<drawing::XShape> const& xShape)
{
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
{
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProperties->getPropertyValue(u"FillComplexColor"_ustr) >>= xComplexColor;
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans1.mnValue);
auto const& rTrans2 = aComplexColor.getTransformations()[1];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans2.mnValue);
}
{
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProperties->getPropertyValue(u"LineComplexColor"_ustr) >>= xComplexColor;
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans1.mnValue);
auto const& rTrans2 = aComplexColor.getTransformations()[1];
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans2.mnValue);
}
}
} // end anonymous ns
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testFillAndLineThemeColorExportImport)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"FillAndStrokeThemeColorTest.fodp");
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
checkFillAndLineComplexColors(getShape(0));
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"impress8"_ustr);
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
UnoApiTest: rename load to loadFromURL and use it everywhere Change-Id: Ie67eebec74f783fa0c29acfb23bb83bc582812b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175724 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-10-28 14:36:38 +01:00
loadFromURL(maTempFile.GetURL());
xmloff: support stroke/line complex color import/export + test Change-Id: I4ed901fd5b23e58aafa781e2b07f460f034fbba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155685 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-14 22:52:20 +02:00
checkFillAndLineComplexColors(getShape(0));
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTextAndFillThemeColorExportImport)
ODP import/export: refer to theme from shape text color Refer to the 12 pre-defined colors by name + don't write the attribute for the case when there is no theme. Change-Id: Ib6ab5b7b34d896a36e04309bf0cb410998acce01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126566 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-09 08:43:27 +01:00
{
// Given a document that refers to a theme color:
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"Reference-ThemeColors-TextAndFill.pptx");
CppunitTest_xmloff_draw: simplify a bit Change-Id: Ic36e2c50953e99d7509c1d16ffef2f9f5f3a7bf4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173992 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-09-26 15:56:50 +02:00
saveAndReload(u"impress8"_ustr);
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:
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
sd theme: add ODP import/export for shape fill color Refer to the 12 pre-defined colors by name + don't write the attribute for the case when there is no theme. Change-Id: I37c984b3371ec878a0d733977f5c937dce27c440 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131717 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-17 20:37:39 +01:00
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
// Text color
OString aStyle1(
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"//style:style[@style:name='T2']/style:text-properties/loext:char-complex-color"_ostr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, aStyle1, "color-type", u"theme");
assertXPath(pXmlDoc, aStyle1, "theme-type", u"accent3");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[1]", "type", u"lummod");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[1]", "value", u"2000");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[2]", "type", u"lumoff");
assertXPath(pXmlDoc, aStyle1 + "/loext:transformation[2]", "value", u"8000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aStyle2(
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"//style:style[@style:name='T3']/style:text-properties/loext:char-complex-color"_ostr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, aStyle1, "color-type", u"theme");
assertXPath(pXmlDoc, aStyle2, "theme-type", u"accent3");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[1]", "type", u"lummod");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[1]", "value", u"6000");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[2]", "type", u"lumoff");
assertXPath(pXmlDoc, aStyle2 + "/loext:transformation[2]", "value", u"4000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aStyle3(
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"//style:style[@style:name='T4']/style:text-properties/loext:char-complex-color"_ostr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, aStyle1, "color-type", u"theme");
assertXPath(pXmlDoc, aStyle3, "theme-type", u"accent3");
assertXPath(pXmlDoc, aStyle3 + "/loext:transformation[1]", "type", u"lummod");
assertXPath(pXmlDoc, aStyle3 + "/loext:transformation[1]", "value", u"5000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
// Shapes fill color
OString aShape1("//style:style[@style:name='gr1']/style:graphic-properties/"
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"loext:fill-complex-color"_ostr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, aStyle1, "color-type", u"theme");
assertXPath(pXmlDoc, aShape1, "theme-type", u"accent2");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[1]", "type", u"lummod");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[1]", "value", u"2000");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[2]", "type", u"lumoff");
assertXPath(pXmlDoc, aShape1 + "/loext:transformation[2]", "value", u"8000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aShape2("//style:style[@style:name='gr2']/style:graphic-properties/"
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"loext:fill-complex-color"_ostr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, aStyle1, "color-type", u"theme");
assertXPath(pXmlDoc, aShape2, "theme-type", u"accent2");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[1]", "type", u"lummod");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[1]", "value", u"6000");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[2]", "type", u"lumoff");
assertXPath(pXmlDoc, aShape2 + "/loext:transformation[2]", "value", u"4000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
OString aShape3("//style:style[@style:name='gr3']/style:graphic-properties/"
Extended loplugin:ostr: xmloff Change-Id: I87e53216693f2d6489a1dd80e62141ca5621a87f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159662 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-19 13:21:42 +01:00
"loext:fill-complex-color"_ostr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, aStyle1, "color-type", u"theme");
assertXPath(pXmlDoc, aShape3, "theme-type", u"accent2");
assertXPath(pXmlDoc, aShape3 + "/loext:transformation[1]", "type", u"lummod");
assertXPath(pXmlDoc, aShape3 + "/loext:transformation[1]", "value", u"5000");
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
// check fill color theme
{
uno::Reference<drawing::XShape> xShape(getShape(0));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProperties->getPropertyValue(u"FillComplexColor"_ustr) >>= xComplexColor;
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent2, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(2000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
auto const& rTrans2 = aComplexColor.getTransformations()[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(8000), rTrans2.mnValue);
}
{
uno::Reference<drawing::XShape> xShape(getShape(1));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProperties->getPropertyValue(u"FillComplexColor"_ustr) >>= xComplexColor;
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent2, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(2), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
auto const& rTrans2 = aComplexColor.getTransformations()[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans2.mnValue);
}
{
uno::Reference<drawing::XShape> xShape(getShape(2));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProperties->getPropertyValue(u"FillComplexColor"_ustr) >>= xComplexColor;
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent2, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(1), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(5000), rTrans1.mnValue);
}
// Char color theme
// Shape 4
{
// Check the first text portion properties
uno::Reference<drawing::XShape> xShape(getShape(3));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xPortion = getShapeTextPortion(0, xShape);
CPPUNIT_ASSERT(xPortion.is());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xPortion->getPropertyValue(u"CharComplexColor"_ustr) >>= xComplexColor;
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
auto const& rTransforms = aComplexColor.getTransformations();
CPPUNIT_ASSERT_EQUAL(size_t(2), rTransforms.size());
auto const& rTrans1 = rTransforms[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(2000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
auto const& rTrans2 = rTransforms[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(8000), rTrans2.mnValue);
}
// Shape 5
{
// Check the first text portion properties
uno::Reference<drawing::XShape> xShape(getShape(4));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xPortion = getShapeTextPortion(0, xShape);
CPPUNIT_ASSERT(xPortion.is());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xPortion->getPropertyValue(u"CharComplexColor"_ustr) >>= xComplexColor;
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
auto const& rTransforms = aComplexColor.getTransformations();
CPPUNIT_ASSERT_EQUAL(size_t(2), rTransforms.size());
auto const& rTrans1 = rTransforms[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(6000), rTrans1.mnValue);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
auto const& rTrans2 = rTransforms[1];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumOff, rTrans2.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(4000), rTrans2.mnValue);
}
// Shape 6
{
// Check the first text portion properties
uno::Reference<drawing::XShape> xShape(getShape(5));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xPortion = getShapeTextPortion(0, xShape);
CPPUNIT_ASSERT(xPortion.is());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xPortion->getPropertyValue(u"CharComplexColor"_ustr) >>= xComplexColor;
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent3, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(1), aComplexColor.getTransformations().size());
auto const& rTrans1 = aComplexColor.getTransformations()[0];
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod, rTrans1.meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(5000), rTrans1.mnValue);
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testThemeColor_ShapeFill)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"ReferenceShapeFill.pptx");
CppunitTest_xmloff_draw: simplify a bit Change-Id: Ic36e2c50953e99d7509c1d16ffef2f9f5f3a7bf4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173992 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-09-26 15:56:50 +02:00
saveAndReload(u"impress8"_ustr);
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
// check fill color theme
uno::Reference<drawing::XShape> xShape(getShape(0));
CPPUNIT_ASSERT(xShape.is());
uno::Reference<beans::XPropertySet> xShapeProperties(xShape, uno::UNO_QUERY);
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
uno::Reference<util::XComplexColor> xComplexColor;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProperties->getPropertyValue(u"FillComplexColor"_ustr) >>= xComplexColor;
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT(xComplexColor.is());
auto aComplexColor = model::color::getFromXComplexColor(xComplexColor);
ComplexColor various clean-up and (trivial) refactorings Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-03 10:14:40 +02:00
CPPUNIT_ASSERT_EQUAL(model::ThemeColorType::Accent6, aComplexColor.getThemeColorType());
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
CPPUNIT_ASSERT_EQUAL(size_t(1), aComplexColor.getTransformations().size());
xmloff: use XThemeColor in ODF, change the format for themes Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-31 20:59:03 +09:00
CPPUNIT_ASSERT_EQUAL(model::TransformationType::LumMod,
use ComplexColor instead of ThemeColor for better OOXML compat. In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-08 14:09:00 +09:00
aComplexColor.getTransformations()[0].meType);
CPPUNIT_ASSERT_EQUAL(sal_Int16(7500), aComplexColor.getTransformations()[0].mnValue);
ODP import/export: refer to theme from shape text color Refer to the 12 pre-defined colors by name + don't write the attribute for the case when there is no theme. Change-Id: Ib6ab5b7b34d896a36e04309bf0cb410998acce01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126566 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-09 08:43:27 +01:00
}
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTableInShape)
{
// Given a document with a shape with a "FrameX" parent style (starts with Frame, but is not
// Frame):
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"table-in-shape.fodt");
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
// Then make sure the table inside the shape is not lost:
CppunitTest_xmloff_draw: inherit from UnoApiTest Change-Id: Ia6e083df4dfb6a6354f3bbe2f5eabaca559281b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141771 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-24 16:56:28 +02:00
uno::Reference<drawing::XDrawPageSupplier> xDrawPageSupplier(mxComponent, uno::UNO_QUERY);
sw ODF shape import: improve is-textbox check This builds on top of commit 28d67b792724a23015dec32fb0278b729f676736 (tdf#107776 sw ODF shape import: make is-textbox check more strict, 2019-08-26). Before that commit, any non-empty parent style name on a shape resulted in an sw textbox. After that commit, we filtered out Writer images by checking for the Frame parent style name. The problem with this approach is that in case two documents are to be merged together, then it's reasonable to rename the Frame style, but then the complex content inside the shape gets lost. Fix the problem by going with a middle ground: require Frame as a prefix, but allow other names as well. This gets e.g. FrameX to work without breaking the "reject Graphics" use-case. Change-Id: Id59ed28a64a9398f2f1620f69b5f148d65e6c95a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126828 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-12-14 13:51:14 +01:00
uno::Reference<drawing::XDrawPage> xDrawPage = xDrawPageSupplier->getDrawPage();
uno::Reference<text::XTextRange> xShape(xDrawPage->getByIndex(0), uno::UNO_QUERY);
uno::Reference<container::XEnumerationAccess> xText(xShape->getText(), uno::UNO_QUERY);
uno::Reference<container::XEnumeration> xEnum = xText->createEnumeration();
uno::Reference<text::XTextTable> xTable(xEnum->nextElement(), uno::UNO_QUERY);
// Without the accompanying fix in place, this test would have crashed, as xTable was an empty
// reference, i.e. the table inside the shape was lost.
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
uno::Reference<text::XTextRange> xCell(xTable->getCellByName(u"A1"_ustr), uno::UNO_QUERY);
CPPUNIT_ASSERT_EQUAL(u"A1"_ustr, xCell->getString());
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
}
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
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
// Since ODF 1.4 it is available as draw:extrusion-metal-type in the standard.
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
namespace
{
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
void lcl_assertMetalProperties(std::string_view sInfo, uno::Reference<drawing::XShape>& rxShape,
sal_Int16 nExpectedMetalType)
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<beans::XPropertySet> xShapeProps(rxShape, uno::UNO_QUERY);
uno::Sequence<beans::PropertyValue> aGeoPropSeq;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProps->getPropertyValue(u"CustomShapeGeometry"_ustr) >>= aGeoPropSeq;
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
comphelper::SequenceAsHashMap aGeoPropMap(aGeoPropSeq);
uno::Sequence<beans::PropertyValue> aExtrusionSeq;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
aGeoPropMap.getValue(u"Extrusion"_ustr) >>= aExtrusionSeq;
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
comphelper::SequenceAsHashMap aExtrusionPropMap(aExtrusionSeq);
bool bIsMetal(false);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
aExtrusionPropMap.getValue(u"Metal"_ustr) >>= bIsMetal;
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
OString sMsg = OString::Concat(sInfo) + " Metal";
CPPUNIT_ASSERT_MESSAGE(sMsg.getStr(), bIsMetal);
sal_Int16 nMetalType(-1);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
aExtrusionPropMap.getValue(u"MetalType"_ustr) >>= nMetalType;
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
sMsg = OString::Concat(sInfo) + " MetalType";
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
CPPUNIT_ASSERT_EQUAL_MESSAGE(sMsg.getStr(), nExpectedMetalType, nMetalType);
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
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionMetalTypeExtended)
{
qa: use SetODFDefaultVersion everywhere Change-Id: I4a08abea9a6c61a0365d238abf1021806ae6df29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174375 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-10-02 10:06:12 +02:00
Resetter resetter([]() { SetODFDefaultVersion(SvtSaveOptions::ODFVER_LATEST); });
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf145700_3D_metal_type_MSCompatible.doc");
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
// verify properties
uno::Reference<drawing::XShape> xShape(getShape(0));
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
lcl_assertMetalProperties("from doc", xShape,
css::drawing::EnhancedCustomShapeMetalType::MetalMSCompatible);
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
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
// Test, that attribute is written with 'draw' namespace in ODF version LATEST
CppunitTest_xmloff_draw: simplify a bit Change-Id: Ic36e2c50953e99d7509c1d16ffef2f9f5f3a7bf4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173992 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-09-26 15:56:50 +02:00
saveAndReload(u"writer8"_ustr);
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.
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal", u"true");
assertXPath(pXmlDoc,
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
"//draw:enhanced-geometry[@draw:extrusion-metal-type='loext:MetalMSCompatible']");
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));
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
lcl_assertMetalProperties("from LATEST", xShapeReload,
css::drawing::EnhancedCustomShapeMetalType::MetalMSCompatible);
// Test, that attribute is written with 'loext' namespace in extended version before ODF 1.4
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013_EXTENDED);
// As of Nov 2024, validating against a version other than LATEST is not implemented.
skipValidation();
saveAndReload(u"writer8"_ustr);
// assert XML.
pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal", u"true");
assertXPath(pXmlDoc,
"//draw:enhanced-geometry[@loext:extrusion-metal-type='loext:MetalMSCompatible']");
// verify properties
uno::Reference<drawing::XShape> xShapeReload2(getShape(0));
lcl_assertMetalProperties("from ODF 1.3 extended", xShapeReload2,
css::drawing::EnhancedCustomShapeMetalType::MetalMSCompatible);
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
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionMetalTypeStrict)
{
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
Resetter resetter([]() { SetODFDefaultVersion(SvtSaveOptions::ODFVER_LATEST); });
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf145700_3D_metal_type_MSCompatible.doc");
tdf#145700 Improve lighting in extruded custom shapes The fix tries to make rendering similar to MS Office. The ODF standard follows closely the extrusion in RTF and MS binary format. Rendering uses the 3D scene engine. The main problem was, that the z-component of the direction was interpreted with opposite sign. As result the maximum of a light was at false position. Especially a direction from the observer to the object has produced a light behind the shape and so looks as if light was off. The wrong z-direction has produced lighting, which was less intensive than in MS Office. To compensate that, a third light source was added as workaround. That part is removed. Second problem was wrong use of 3D-scene D3DMaterialSpecularIntensity and D3DMaterialSpecular (= UI Specular color). That was not only wrong in OOo but in my previous patch too. D3DMaterialSpecularIntensity corresponds to MS property 'c3DShininess'. Relationship is Intensity = 2^c3DShininess. D3DMaterialSpecular is calculated from MS property c3DSpecularAmt and and c3DKeyIntensity. The light source was missing, but needs to be included, because c3DSpecularAmt is 'the ratio of incident to specular light that is reflected on a shape'. The old unit tests are adapted to this change. MS gives no information how it softens a light in case of harsh=false. ODF specifies it as 'implementation-defined'. The patch uses four additional lights, which have directions in 60° angle to the original light. The light intensity is distributed. That comes near to rendering in MS Office. Changing our 3D engine to provide 'soft' lights was not doable for me. The way MS Office renders a 'metal' surface is different from ODF specification. To distinguish the kinds, I have introduced a new property MetalType. I have discussed it with the ODF TC (see minutes from 2022-02-07) and got the advise to use namespaced values. Therefore the datatype is not boolean. The 'Surface' drop-down in the extrusion bar is changed to make the two kinds of rendering 'Metal' available to the user. If a user sets surface 'Metal' in the UI of MS Office, it sets not only fc3DMetallic but reduces the value of c3DDiffuseAmt in addition. Our 3D-scene engine has the corresponding ODF attribute dr3d:diffuse-color not implemented. To get a similar rendering I change the material color of the 3D-objects as workaround. Change-Id: Ia986b9c318b4c79688e0c0e2d858215b9d612fdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128449 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-01-13 13:26:25 +01:00
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
// save in ODF 1.4 strict and test that new attribute is written.
SetODFDefaultVersion(SvtSaveOptions::ODFVER_014);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"writer8"_ustr);
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal", u"true");
assertXPath(pXmlDoc,
"//draw:enhanced-geometry[@draw:extrusion-metal-type='loext:MetalMSCompatible']");
// save in ODF 1.3 strict and test that new attribute is not written.
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013);
tdf#162691: ODF 1.4 Add support for xy and polar handle new attributes Co-author: Regina Henschel This implements the new draw:handle attributes of ODF 1.4. For reasons for new attributes see https://issues.oasis-open.org/browse/OFFICE-4110 The old attributes are deprecated but may still be written. So we keep them to be backward compatible. Change-Id: I0b3443d000b2b163363f9070e5e276af2b018cbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174966 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-10-15 11:23:39 +02:00
// As of Nov 2024, validating against a version other than LATEST is not implemented.
skipValidation();
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
save(u"writer8"_ustr);
pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal", u"true");
assertXPathNoAttribute(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal-type");
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionMetalTypeODF)
{
Resetter resetter([]() { SetODFDefaultVersion(SvtSaveOptions::ODFVER_LATEST); });
loadFromFile(u"tdf162686_3D_metal_type_ODF.fods");
// verify properties
uno::Reference<drawing::XShape> xShape(getShape(0));
lcl_assertMetalProperties("from doc", xShape,
css::drawing::EnhancedCustomShapeMetalType::MetalODF);
// Test, that attribute is written with 'draw' namespace in ODF version LATEST
saveAndReload(u"calc8"_ustr);
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.
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal", u"true");
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@draw:extrusion-metal-type='draw:MetalODF']");
// verify properties
uno::Reference<drawing::XShape> xShapeReload(getShape(0));
lcl_assertMetalProperties("from LATEST", xShapeReload,
css::drawing::EnhancedCustomShapeMetalType::MetalODF);
// Test, that export in ODFVER_014 is valid. Needs adaption, when ODF 1.5 comes out.
SetODFDefaultVersion(SvtSaveOptions::ODFVER_014);
saveAndReload(u"calc8"_ustr);
// Test, that attribute is written with 'loext' namespace in extended version before ODF 1.4
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013_EXTENDED);
// As of Nov 2024, validating against a version other than LATEST is not implemented.
skipValidation();
saveAndReload(u"calc8"_ustr);
// assert XML.
pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@loext:extrusion-metal-type='draw:MetalODF']");
// verify properties
uno::Reference<drawing::XShape> xShapeReload2(getShape(0));
lcl_assertMetalProperties("from ODF 1.3 extended", xShapeReload2,
css::drawing::EnhancedCustomShapeMetalType::MetalODF);
// Test, that attribute is not written at all in strict version before ODF 1.4
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013);
save(u"calc8"_ustr);
pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPathNoAttribute(pXmlDoc, "//draw:enhanced-geometry", "extrusion-metal-type");
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
}
tdf#162691: ODF 1.4 Add support for xy and polar handle new attributes Co-author: Regina Henschel This implements the new draw:handle attributes of ODF 1.4. For reasons for new attributes see https://issues.oasis-open.org/browse/OFFICE-4110 The old attributes are deprecated but may still be written. So we keep them to be backward compatible. Change-Id: I0b3443d000b2b163363f9070e5e276af2b018cbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174966 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-10-15 11:23:39 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testHandlePosition)
{
Resetter resetter([]() { SetODFDefaultVersion(SvtSaveOptions::ODFVER_LATEST); });
loadFromFile(u"tdf162691_handle_position.fodt");
save(u"writer8"_ustr);
static constexpr OString sXPath("/office:document-content/office:body/office:text/text:p/"
"draw:custom-shape/draw:enhanced-geometry/draw:handle"_ostr);
// assert XML.
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, sXPath, "handle-position", u"$0 10800");
assertXPath(pXmlDoc, sXPath, "handle-position-x", u"$0");
assertXPath(pXmlDoc, sXPath, "handle-position-y", u"10800");
// assert that new attributes are not written in older ODF versions and old one is written.
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013_EXTENDED);
// As of Nov 2024, validating against a version other than LATEST is not implemented.
skipValidation();
save(u"writer8"_ustr);
pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, sXPath, "handle-position", u"$0 10800");
assertXPathNoAttribute(pXmlDoc, sXPath, "handle-position-x");
assertXPathNoAttribute(pXmlDoc, sXPath, "handle-position-y");
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testHandlePolar)
{
Resetter resetter([]() { SetODFDefaultVersion(SvtSaveOptions::ODFVER_LATEST); });
loadFromFile(u"tdf162691_handle_polar.fodt");
save(u"writer8"_ustr);
// assert XML.
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
static constexpr OString sXPath("/office:document-content/office:body/office:text/text:p/"
"draw:custom-shape/draw:enhanced-geometry/draw:handle"_ostr);
assertXPath(pXmlDoc, sXPath, "handle-position", u"9000 $0");
assertXPath(pXmlDoc, sXPath, "handle-polar", u"10800 1000");
assertXPath(pXmlDoc, sXPath, "handle-polar-angle", u"$0");
assertXPath(pXmlDoc, sXPath, "handle-polar-radius", u"9000");
assertXPath(pXmlDoc, sXPath, "handle-polar-pole-x", u"10800");
assertXPath(pXmlDoc, sXPath, "handle-polar-pole-y", u"1000");
// assert that new attributes are not written in older ODF versions and old ones are written.
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013_EXTENDED);
// As of Nov 2024, validating against a version other than LATEST is not implemented.
skipValidation();
save(u"writer8"_ustr);
pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, sXPath, "handle-position", u"9000 $0");
assertXPath(pXmlDoc, sXPath, "handle-polar", u"10800 1000");
assertXPathNoAttribute(pXmlDoc, sXPath, "handle-polar-pole-x");
assertXPathNoAttribute(pXmlDoc, sXPath, "handle-polar-pole-y");
assertXPathNoAttribute(pXmlDoc, sXPath, "handle-polar-angle");
assertXPathNoAttribute(pXmlDoc, sXPath, "handle-polar-radius");
}
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;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProps->getPropertyValue(u"CustomShapeGeometry"_ustr) >>= aGeoPropSeq;
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
comphelper::SequenceAsHashMap aGeoPropMap(aGeoPropSeq);
uno::Sequence<beans::PropertyValue> aExtrusionSeq;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
aGeoPropMap.getValue(u"Extrusion"_ustr) >>= aExtrusionSeq;
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
comphelper::SequenceAsHashMap aExtrusionPropMap(aExtrusionSeq);
double fSpecularity(-1.0);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
aExtrusionPropMap.getValue(u"Specularity"_ustr) >>= fSpecularity;
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
OString sMsg = OString::Concat(sInfo) + "Specularity";
CPPUNIT_ASSERT_EQUAL_MESSAGE(sMsg.getStr(), 122.0703125, fSpecularity);
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionSpecularityExtended)
{
qa: use SetODFDefaultVersion everywhere Change-Id: I4a08abea9a6c61a0365d238abf1021806ae6df29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174375 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-10-02 10:06:12 +02:00
Resetter resetter([]() { SetODFDefaultVersion(SvtSaveOptions::ODFVER_LATEST); });
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf147580_extrusion-specularity.doc");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
// verify property
uno::Reference<drawing::XShape> xShape(getShape(0));
lcl_assertSpecularityProperty("from doc", xShape);
// Test, that attribute is written in draw namespace with value 100% and in loext namespace with
// value 122.0703125%.
Add ODF 1.3 Extended / ODF 1.4 versions to configuration and UI The new default is ODF 1.4 Extended Change-Id: I50f60cccde81b5ea320478314482cc67a7bcc2e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174343 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-10-01 13:10:49 +02:00
SetODFDefaultVersion(SvtSaveOptions::ODFVER_013_EXTENDED);
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
// As of Nov 2024, validating against a version other than LATEST is not implemented.
skipValidation();
CppunitTest_xmloff_draw: simplify a bit Change-Id: Ic36e2c50953e99d7509c1d16ffef2f9f5f3a7bf4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173992 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-09-26 15:56:50 +02:00
saveAndReload(u"writer8"_ustr);
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.
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@draw:extrusion-specularity='100%']");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
assertXPath(pXmlDoc,
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
"//draw:enhanced-geometry[@loext:extrusion-specularity-loext='122.0703125%']");
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);
tdf#162690, tdf#162687: Adapt to ODF 1.4 After this, the workaround introduced to OpenDocument-v1.4+libreoffice-schema.rng in afa4965e4df6f1f0c43c0a059f216e7f8a21ba82 "schema: update to ODF 1.4 OS" can be removed Change-Id: Iecf31cec0bf187155a97e5b6ccf8173b6aba82fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173940 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-09-25 16:04:27 +02:00
}
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionSpecularity)
tdf#162690, tdf#162687: Adapt to ODF 1.4 After this, the workaround introduced to OpenDocument-v1.4+libreoffice-schema.rng in afa4965e4df6f1f0c43c0a059f216e7f8a21ba82 "schema: update to ODF 1.4 OS" can be removed Change-Id: Iecf31cec0bf187155a97e5b6ccf8173b6aba82fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173940 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-09-25 16:04:27 +02:00
{
loadFromFile(u"tdf147580_extrusion-specularity.doc");
// verify property
uno::Reference<drawing::XShape> xShape(getShape(0));
lcl_assertSpecularityProperty("from doc", xShape);
tdf#162687: ODF 1.4: fix import Change-Id: Ic728c1c92ff5815c0780ba18e1a473d26e13e63f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173993 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-09-26 16:46:07 +02:00
saveAndReload(u"writer8"_ustr);
tdf#162690, tdf#162687: Adapt to ODF 1.4 After this, the workaround introduced to OpenDocument-v1.4+libreoffice-schema.rng in afa4965e4df6f1f0c43c0a059f216e7f8a21ba82 "schema: update to ODF 1.4 OS" can be removed Change-Id: Iecf31cec0bf187155a97e5b6ccf8173b6aba82fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173940 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-09-25 16:04:27 +02:00
// assert XML.
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@draw:extrusion-specularity='122.0703125%']");
tdf#162690, tdf#162687: Adapt to ODF 1.4 After this, the workaround introduced to OpenDocument-v1.4+libreoffice-schema.rng in afa4965e4df6f1f0c43c0a059f216e7f8a21ba82 "schema: update to ODF 1.4 OS" can be removed Change-Id: Iecf31cec0bf187155a97e5b6ccf8173b6aba82fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173940 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-09-25 16:04:27 +02:00
tdf#162687: ODF 1.4: fix import Change-Id: Ic728c1c92ff5815c0780ba18e1a473d26e13e63f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173993 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-09-26 16:46:07 +02:00
// verify properties
uno::Reference<drawing::XShape> xShapeReload(getShape(0));
lcl_assertSpecularityProperty("from ODF 1.4", xShapeReload);
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
}
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testExtrusionSpecularityStrict)
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
{
qa: use SetODFDefaultVersion everywhere Change-Id: I4a08abea9a6c61a0365d238abf1021806ae6df29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174375 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-10-02 10:06:12 +02:00
Resetter resetter([]() { SetODFDefaultVersion(SvtSaveOptions::ODFVER_LATEST); });
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf147580_extrusion-specularity.doc");
tdf#147580 use valid values for extrusion-specularity The fix for tdf#145700 has changed the internal handling so, that values larger than 100% from MS binary import are now kept und correctly used. But ODF 1.2 and 1.3 have the range restricted to zeroToHundredPercent. The patch writes values larger than 100% in extended namespace for our 'ODF 1.3 extended'. It writes draw:extrusion-specularity in any case, so that older versions get a meaninful value, but clamps it to [0,100] if necessary to get valid files. Change-Id: I98298d5c3e3367ffe4a45cdc051be23679308119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130306 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-02-21 23:08:10 +01:00
// The file has c3DSpecularAmt="80000" which results internally in specularity=122%.
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
SetODFDefaultVersion(SvtSaveOptions::ODFVER_014);
save(u"writer8"_ustr);
xmlDocUniquePtr pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@draw:extrusion-specularity='122.0703125%']");
// Save to ODF 1.3 strict and make sure draw:extrusion-specularity="100%" is written and
// loext:extrusion-specularity is not written.
// As of Nov 2024, validating against a version other than LATEST is not implemented.
skipValidation();
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(SvtSaveOptions::ODFVER_013);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"writer8"_ustr);
tdf#162686 tdf#162687 ODF 1.4 extrusion-metal-type and extrusion-specularity. In ODF strict always value 'draw:MetalODF' was written. Changed the logic to write 'loext:MetalMSCompatible' too, depending on eMetalType. Using a QName as value requires a namespace declaration for the prefix 'loext'. That is now written directly at the element, not as global declaration, to restrict its scope to the element. A global declaration would hide when attributes or elements are accidentially written in 'loext' namespace. The pattern for nonNegativePercent had missed the percent sign. The export is adapted to write the percent sign. Validation is skipped for save to ODF 1.3, because currently the implicit validation uses always latest ODF version, see tdf#163806. Tests are extended to cover ODF 1.4 and value draw:MetalODF. Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-11-07 19:24:03 +01:00
pXmlDoc = parseExport(u"content.xml"_ustr);
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@loext:extrusion-specularity]", 0);
assertXPath(pXmlDoc, "//draw:enhanced-geometry[@draw:extrusion-specularity='100%']");
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
}
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);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
uno::Any anotherAny = xShapeProps->getPropertyValue(u"CustomShapeGeometry"_ustr);
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
uno::Sequence<beans::PropertyValue> aCustomShapeGeometry;
if (!(anotherAny >>= aCustomShapeGeometry))
return false;
uno::Sequence<beans::PropertyValue> aPathProps;
Drop std::as_const from css::uno::Sequence iterations Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code, 2021-11-05). Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-27 15:42:54 +06:00
for (beans::PropertyValue const& rProp : aCustomShapeGeometry)
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
{
if (rProp.Name == "Path")
{
rProp.Value >>= aPathProps;
break;
}
}
Drop std::as_const from css::uno::Sequence iterations Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code, 2021-11-05). Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-27 15:42:54 +06:00
for (beans::PropertyValue const& rProp : aPathProps)
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
{
if (rProp.Name == "Segments")
{
rProp.Value >>= rSegments;
break;
}
}
if (rSegments.getLength() > 2)
return true;
else
return false;
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf148714_CurvedArrowsOld)
{
// Load a document with CurveArrow shapes with faulty path as written by older LO versions.
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf148714_CurvedArrowsOld.odp");
tdf#148714 Repair path in older CurvedArrow shapes The CurvedArrow shapes had an error in their enhanced-path. The error was fixed in the geometry definition with commit 4cfe4699. But the wrong path was written to file markup. This patch repairs the path in shapes in documents written before the fix of the geometry definition. Change-Id: I6d7bc3b4ec4a61f16ce5dea3d352575525850b80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133740 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-05-03 00:18:00 +02:00
// Make sure, that the error has been corrected on opening.
for (sal_Int32 nShapeIndex = 0; nShapeIndex < 4; nShapeIndex++)
{
uno::Reference<drawing::XShape> xShape(getShape(nShapeIndex));
uno::Sequence<drawing::EnhancedCustomShapeSegment> aSegments;
CPPUNIT_ASSERT(lcl_getShapeSegments(aSegments, xShape));
if (nShapeIndex == 0 || nShapeIndex == 3)
{
// curvedDownArrow or curvedLeftArrow. Segments should start with VW. Without fix it was
// V with count 2, which means VV.
CPPUNIT_ASSERT_EQUAL(
sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::CLOCKWISEARC),
aSegments[0].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[0].Count);
CPPUNIT_ASSERT_EQUAL(
sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::CLOCKWISEARCTO),
aSegments[1].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[1].Count);
}
else
{
// curvedUpArrow or curvedRightArrow. Segments should start with BA. Without fix is was
// B with count 2, which means BB.
CPPUNIT_ASSERT_EQUAL(sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::ARC),
aSegments[0].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[0].Count);
CPPUNIT_ASSERT_EQUAL(sal_Int16(drawing::EnhancedCustomShapeSegmentCommand::ARCTO),
aSegments[1].Command);
CPPUNIT_ASSERT_EQUAL(sal_Int16(1), aSegments[1].Count);
}
}
}
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTextRotationPlusPre)
{
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf149551_verticalText.pptx");
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
// The file has a shape with attribute vert="vert" in <bodyPr> element. That generates a
// TextPreRotateAngle attribute in CustomShapeGeometry.
// Add a TextRotateAngle attribute.
uno::Reference<drawing::XShape> xShape(getShape(0));
uno::Reference<beans::XPropertySet> xShapeProps(xShape, uno::UNO_QUERY);
uno::Sequence<beans::PropertyValue> aGeomSeq;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProps->getPropertyValue(u"CustomShapeGeometry"_ustr) >>= aGeomSeq;
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
auto aGeomVec(comphelper::sequenceToContainer<std::vector<beans::PropertyValue>>(aGeomSeq));
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
aGeomVec.push_back(comphelper::makePropertyValue(u"TextRotateAngle"_ustr, sal_Int32(45)));
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
aGeomSeq = comphelper::containerToSequence(aGeomVec);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xShapeProps->setPropertyValue(u"CustomShapeGeometry"_ustr, uno::Any(aGeomSeq));
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
// 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.
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
saveAndReload(u"writer8"_ustr);
tdf#149551 write draw:text-rotate-angle only once The attributes 'vert' and 'vert270' set property TextPreRotateAngle on import from OOXML. The property TextRotateAngle can be set by macro. Both were written to file as 'draw:text-rotate-angle' attribute. So we got a file format error 'duplicate attribute'. The values are now added and the sum is written. That gives the same rendering as after applying a macro. Using the sum is a workaround. We have currently no way to save the direction specified by 'vert' and 'vert270' as style:writing-mode to ODF. Change-Id: I93fd8ca42b82c1ed7f1bf6e33d932e5510615b2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135901 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-06-15 13:15:15 +02:00
}
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf156975_ThemeExport)
{
// It tests, that a theme is written to master page in Draw documents.
// Without fix for tdf#156975 it was not written at all.
// The test needs to be adapted, when themes are available in ODF.
UnoApiTest: rename load to loadFromURL and use it everywhere Change-Id: Ie67eebec74f783fa0c29acfb23bb83bc582812b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175724 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-10-28 14:36:38 +01:00
loadFromURL(u"private:factory/sdraw"_ustr);
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
// generate a theme to be sure we have got one and know the values
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterPageProps(xDrawPage->getMasterPage(),
uno::UNO_QUERY);
auto pTheme = std::make_shared<model::Theme>("Custom");
auto pColorSet = std::make_shared<model::ColorSet>("My Colors");
pColorSet->add(model::ThemeColorType::Dark1, 0x000000);
pColorSet->add(model::ThemeColorType::Light1, 0xffff11);
pColorSet->add(model::ThemeColorType::Dark2, 0x002200);
pColorSet->add(model::ThemeColorType::Light2, 0xff33ff);
pColorSet->add(model::ThemeColorType::Accent1, 0x440000);
pColorSet->add(model::ThemeColorType::Accent2, 0x005500);
pColorSet->add(model::ThemeColorType::Accent3, 0x000066);
pColorSet->add(model::ThemeColorType::Accent4, 0x777700);
pColorSet->add(model::ThemeColorType::Accent5, 0x880088);
pColorSet->add(model::ThemeColorType::Accent6, 0x009999);
pColorSet->add(model::ThemeColorType::Hyperlink, 0x0a0a0a);
pColorSet->add(model::ThemeColorType::FollowedHyperlink, 0xb0b0b0);
pTheme->setColorSet(pColorSet);
uno::Reference<util::XTheme> xTheme = model::theme::createXTheme(pTheme);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xMasterPageProps->setPropertyValue(u"Theme"_ustr, uno::Any(xTheme));
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
// save as odg
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"draw8"_ustr);
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
// and check the markup.
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xmlDocUniquePtr pXmlDoc = parseExport(u"styles.xml"_ustr);
Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: xmloff Change-Id: I2d58bbea770c4dd188cae13e11218a29f4cd5d05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158294 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-19 10:30:42 +02:00
static constexpr OString sThemePath
= "//office:master-styles/style:master-page/loext:theme"_ostr;
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
assertXPath(pXmlDoc, sThemePath, 1);
assertXPath(pXmlDoc, sThemePath + "[@loext:name='Custom']");
const OString sThemeColorsPath = sThemePath + "/loext:theme-colors";
assertXPath(pXmlDoc, sThemeColorsPath, 1);
assertXPath(pXmlDoc, sThemeColorsPath + "[@loext:name='My Colors']");
const OString sThemeColorPath = sThemeColorsPath + "/loext:color";
assertXPath(pXmlDoc, sThemeColorPath, 12);
Use good old string literals in assertXPath and friends These are only sent to an external API expecting char*-like strings, or for comparison. Having every assertXPath having three of _[ou]str is too much syntactic noise, making the unit tests almost unreadable. Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2024-10-03 11:40:13 +05:00
assertXPath(pXmlDoc, sThemeColorPath + "[3]", "name", u"dark2");
assertXPath(pXmlDoc, sThemeColorPath + "[3]", "color", u"#002200");
assertXPath(pXmlDoc, sThemeColorPath + "[9]", "name", u"accent5");
assertXPath(pXmlDoc, sThemeColorPath + "[9]", "color", u"#880088");
assertXPath(pXmlDoc, sThemeColorPath + "[12]", "name", u"followed-hyperlink");
assertXPath(pXmlDoc, sThemeColorPath + "[12]", "color", u"#b0b0b0");
tdf#156975 Save a Theme in Draw too not only in Impress Draw and Impress have many things in common and should therefore be treated equally where possible. Only if the theme colors are present in the document, colors can be recognized as theme colors during import. Change-Id: Ia1fae2aff989ae305c210efa3f925a80898880e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156267 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-29 22:18:29 +02:00
}
tdf#157018 Enable import of color theme for Draw Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-31 01:15:26 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf157018_ThemeImportDraw)
{
// Similar to testThemeImport but for Draw.
// Load document with custom color theme
UnoApiTest::loadFromURL -> UnoApiTest::loadFromFile The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-03 11:49:02 +06:00
loadFromFile(u"tdf157018_CustomTheme.fodg");
tdf#157018 Enable import of color theme for Draw Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-31 01:15:26 +02:00
// First make sure the doc model has a master page with a theme:
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
uno::Reference<drawing::XMasterPageTarget> xDrawPage(
xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xMasterpage(xDrawPage->getMasterPage(), uno::UNO_QUERY);
uno::Reference<util::XTheme> xTheme;
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
xMasterpage->getPropertyValue(u"Theme"_ustr) >>= xTheme;
tdf#157018 Enable import of color theme for Draw Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-31 01:15:26 +02:00
CPPUNIT_ASSERT(xTheme.is());
// Then make sure it is the custom color theme
auto* pUnoTheme = dynamic_cast<UnoTheme*>(xTheme.get());
CPPUNIT_ASSERT(pUnoTheme);
auto pTheme = pUnoTheme->getTheme();
CPPUNIT_ASSERT(pTheme);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
CPPUNIT_ASSERT_EQUAL(u"Custom"_ustr, pTheme->GetName());
tdf#157018 Enable import of color theme for Draw Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-31 01:15:26 +02:00
auto pColorSet = pTheme->getColorSet();
CPPUNIT_ASSERT(pColorSet);
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
CPPUNIT_ASSERT_EQUAL(u"My Colors"_ustr, pColorSet->getName());
tdf#157018 Enable import of color theme for Draw Use the color theme import in Draw too, otherwise we will not be able to detect theme colors. Change-Id: I8f01ba69848a6265193407a952144b31e3a7fdb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156313 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-31 01:15:26 +02:00
// and test some colors
CPPUNIT_ASSERT_EQUAL(Color(0xFFFF11), pColorSet->getColor(model::ThemeColorType::Light1));
CPPUNIT_ASSERT_EQUAL(Color(0x0A0A0A), pColorSet->getColor(model::ThemeColorType::Hyperlink));
CPPUNIT_ASSERT_EQUAL(Color(0x440000), pColorSet->getColor(model::ThemeColorType::Accent1));
}
Clamp extrusion light level to allowed range for ODF With import of shapes in 3D-mode from pptx files, the internal values for light level might be outside the range 0..100 and thus not allowed in ODF. These high levels are needed to get a similar rendering to MS Office. The export to ODF clamps them now to the allowed range. I do not intend to change the export to loext namespace, because the extrusion mode of custom shapes needs a totally new handling. But that will not be possible timely for version 24.8. Change-Id: I839903cbaf1b304c1e0c4374080963bc70352e61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164948 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-03-17 16:28:12 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, test_scene3d_ooxml_light)
{
// The document has a shape in 3D mode. The import of ooxml light rigs can produce light
// levels outside the 0..100 range allowed in ODF. Such high levels are needed for rendering
// similar to MS Office.
loadFromFile(u"Scene3d_LightRig_threePt.pptx");
// Without fix this would have failed with validation error.
loplugin:ostr in xmloff Change-Id: I24f5626e57e03217e4bcf77289c785e255b9f904 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167667 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-15 13:12:19 +02:00
save(u"impress8"_ustr);
Clamp extrusion light level to allowed range for ODF With import of shapes in 3D-mode from pptx files, the internal values for light level might be outside the range 0..100 and thus not allowed in ODF. These high levels are needed to get a similar rendering to MS Office. The export to ODF clamps them now to the allowed range. I do not intend to change the export to loext namespace, because the extrusion mode of custom shapes needs a totally new handling. But that will not be possible timely for version 24.8. Change-Id: I839903cbaf1b304c1e0c4374080963bc70352e61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164948 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-03-17 16:28:12 +01:00
}
tdf#161327 Interpret angle units in dr3d:end-angle .. .. and draw:rotation in <draw:hatch> element. ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2 it is specified as double with unit "deg", "grad" or "rad", or without unit. The unit-less value is specified to be in degrees. But OOo, AOO and all LO versions had written the value unit-less in 1/10th of a degree in some cases. To fix it, LibreOffic will be enabled to read units. When then the active versions are able to read units, starting with the then actual version, LibreOffice will write angles with unit 'deg'. This has already be done for gradients, see tdf#89475. This patch starts the first step to make LibreOffice able to read units for dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO FillHatch.Angle). I have not found further cases of writing 1/10deg. The patch still writes unit-less 1/10th of a degree for export to ODF 1.3 and earlier. When it is time to write unit degree or when LibreOffice supports the next ODF versions, some places need to be adapted. They are marked. The converter convertAngle is renamed to convert10thDegAngle() to indicate, that it is special. The parts, which were specific to gradients are moved to the gradients, so that it is now usable for dr3d:angle and draw:rotation too. I intend to write next a patch that enables LibreOffice to read angle units for cases where LibreOffice already writes unit-less values in degree. That is not so urgent, but to bring LibreOffice nearer to ODF, reading angle units should be implemented nevertheless. The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc to have access to it from xmloff/source/draw. Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-06-01 19:50:47 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf161327_LatheEndAngle)
{
// Load document with 3D-Scene with 4 rotation objects
loadFromFile(u"tdf161327_LatheEndAngle.fodg");
// get scene object
uno::Reference<drawing::XShape> xSceneShape(getShape(0));
new loplugin:staticconstexpr Change-Id: Ida1996dfffa106bf95fd064e8191b8033b4002f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175336 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-10-21 12:41:53 +02:00
static constexpr OUString sExpected(u"com.sun.star.drawing.Shape3DSceneObject"_ustr);
tdf#161327 Interpret angle units in dr3d:end-angle .. .. and draw:rotation in <draw:hatch> element. ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2 it is specified as double with unit "deg", "grad" or "rad", or without unit. The unit-less value is specified to be in degrees. But OOo, AOO and all LO versions had written the value unit-less in 1/10th of a degree in some cases. To fix it, LibreOffic will be enabled to read units. When then the active versions are able to read units, starting with the then actual version, LibreOffice will write angles with unit 'deg'. This has already be done for gradients, see tdf#89475. This patch starts the first step to make LibreOffice able to read units for dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO FillHatch.Angle). I have not found further cases of writing 1/10deg. The patch still writes unit-less 1/10th of a degree for export to ODF 1.3 and earlier. When it is time to write unit degree or when LibreOffice supports the next ODF versions, some places need to be adapted. They are marked. The converter convertAngle is renamed to convert10thDegAngle() to indicate, that it is special. The parts, which were specific to gradients are moved to the gradients, so that it is now usable for dr3d:angle and draw:rotation too. I intend to write next a patch that enables LibreOffice to read angle units for cases where LibreOffice already writes unit-less values in degree. That is not so urgent, but to bring LibreOffice nearer to ODF, reading angle units should be implemented nevertheless. The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc to have access to it from xmloff/source/draw. Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-06-01 19:50:47 +02:00
CPPUNIT_ASSERT_EQUAL(sExpected, xSceneShape->getShapeType());
// Examine child objects
// [0] dr3d:end-angle="1512"
// [1] dr3d:end-angle="151.2deg"
// [2] dr3d:end-angle="168.0grad"
// [3] dr3d:end-angle="2.638937829015430rad"
// All cases should result in D3DEndAngle = 1512. Without fix, cases [1], [2] and [3]
// could not be read and default 3600 was used, although the values are valid in ODF.
for (size_t i = 0; i < 4; ++i)
{
uno::Reference<container::XIndexAccess> xGroup(xSceneShape, uno::UNO_QUERY);
uno::Reference<drawing::XShape> xShape(xGroup->getByIndex(i), uno::UNO_QUERY);
uno::Reference<beans::XPropertySet> xShapeProps(xShape, uno::UNO_QUERY);
sal_Int16 nEndAngle;
xShapeProps->getPropertyValue(u"D3DEndAngle"_ustr) >>= nEndAngle;
CPPUNIT_ASSERT_EQUAL(sal_Int16(1512), nEndAngle);
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf161327_HatchAngle)
{
// Load document with four rectangles with linear hatch background fill
loadFromFile(u"tdf161327_HatchAngle.fodg");
// The hatch angle is given in file as
// [0] 585 unit less
// [1] 58.5deg,
// [2] 65grad,
// [3] 1.01201761241668rad
// The resulting angle should be 585 (meaning 1/10 of a degree) in all cases.
// Cases [1], [2] and [3] had angle 0 without fix.
for (size_t i = 0; i < 4; ++i)
{
uno::Reference<drawing::XShape> xShape(getShape(i));
uno::Reference<beans::XPropertySet> xShapeProps(xShape, uno::UNO_QUERY);
constexpr css::drawing::FillStyle eExpectedStyle = css::drawing::FillStyle_HATCH;
css::drawing::FillStyle aActualStyle;
xShapeProps->getPropertyValue(u"FillStyle"_ustr) >>= aActualStyle;
CPPUNIT_ASSERT_EQUAL(eExpectedStyle, aActualStyle);
sal_Int32 nExpectedAngle = 585; // FillHatch.Angle has data type 'long'
css::drawing::Hatch aActualHatch;
xShapeProps->getPropertyValue(u"FillHatch"_ustr) >>= aActualHatch;
CPPUNIT_ASSERT_EQUAL(nExpectedAngle, aActualHatch.Angle);
}
}
tdf#161483 enable LO to read ODF angle units ODF uses in several places data type 'angle' (18.3.1, ODF 1.3). That is a double followed by unit identifier 'deg', 'grad' or 'rad' or a unit less value in degrees. LO uses in the API angles in degrees, 1/10 of degrees and 1/100 of degrees in data types 'double', 'short' and 'long'. Without the fix LO does not interpret the units, but takes only the number part. Change-Id: Ib3f2a518a25199e3cf7a7a8572e169785f75c427 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169360 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-06-23 20:24:44 +02:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf161483_ShadowSlant)
{
// Load document with four 3D-scenes, that differ in the draw:shadow-slant value
loadFromFile(u"tdf161483_ShadowSlant.fodg");
// The shadow-slant angle is given in file as
// [0] 36 unitless
// [1] 36deg,
// [2] 40grad,
// [3] 1.628318530717959rad
// The resulting angle should be 36 in all cases.
// Cases [1], [2] and [3] had angle 0 without fix.
constexpr sal_Int16 nExpectedAngle = 36; // D3DSceneShadowSlant has data type 'short'
for (size_t i = 0; i < 4; ++i)
{
uno::Reference<drawing::XShape> xShape(getShape(i));
uno::Reference<beans::XPropertySet> xShapeProps(xShape, uno::UNO_QUERY);
sal_Int16 nActualAngle;
xShapeProps->getPropertyValue(u"D3DSceneShadowSlant"_ustr) >>= nActualAngle;
CPPUNIT_ASSERT_EQUAL(nExpectedAngle, nActualAngle);
}
}
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf161483_CircleStartEndAngle)
{
// Load document with four 'Arc' shapes, which differ in the type of start and end angles
loadFromFile(u"tdf161483_CircleStartEndAngle.fodg");
// The start and end angles are given in file as
// [0] unitless: start 337.5 end 306
// [1] deg: start 337.5deg end 306deg
// [2] grad: start 375grad end 340grad
// [3] rad: start 5.89048622548086rad end 5.34070751110265rad
// The resulting angle should be 33750 and 30600 in all cases.
// CircleStartAngle and CircleEndAngle have data type 'long', meaning Degree100
constexpr sal_Int32 nExpectedStartAngle = 33750;
constexpr sal_Int32 nExpectedEndAngle = 30600;
for (size_t i = 0; i < 4; ++i)
{
uno::Reference<drawing::XShape> xShape(getShape(i));
uno::Reference<beans::XPropertySet> xShapeProps(xShape, uno::UNO_QUERY);
sal_Int32 nActualStartAngle;
xShapeProps->getPropertyValue(u"CircleStartAngle"_ustr) >>= nActualStartAngle;
CPPUNIT_ASSERT_EQUAL(nExpectedStartAngle, nActualStartAngle);
sal_Int32 nActualEndAngle;
xShapeProps->getPropertyValue(u"CircleEndAngle"_ustr) >>= nActualEndAngle;
CPPUNIT_ASSERT_EQUAL(nExpectedEndAngle, nActualEndAngle);
}
}
[API CHANGE] sd pdfium: add page number when saving/loading pdf pages as images When a pdf file is opened with pdfium and then saved as odg, each page is saved as a draw:image of the pdf. But since no page number info was given, when opening the odg file, all the pages are shown as the first one. This adds a loext:page-number to the saved odg and the logic to load a specific page from an embedded pdf. Added loadGraphicAtPage to XGraphicStorageHandler. Change-Id: I398b7ad7f03cc7fb930a4e7b7620c6f238b41c0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181066 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2025-01-28 10:13:11 +01:00
CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testPdfExportAsOdg)
{
auto pPdfium = vcl::pdf::PDFiumLibrary::get();
if (!pPdfium)
{
return;
}
// We need to enable PDFium import (and make sure to disable after the test)
bool bResetEnvVar = false;
if (getenv("LO_IMPORT_USE_PDFIUM") == nullptr)
{
bResetEnvVar = true;
osl_setEnvironment(OUString("LO_IMPORT_USE_PDFIUM").pData, OUString("1").pData);
}
comphelper::ScopeGuard aPDFiumEnvVarGuard([&]() {
if (bResetEnvVar)
osl_clearEnvironment(OUString("LO_IMPORT_USE_PDFIUM").pData);
});
loadFromFile(u"two-pages.pdf");
// save and reload as odg
saveAndReload("draw8");
// Check that the graphic in the second page of the document is the second page of the pdf
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(mxComponent,
uno::UNO_QUERY_THROW);
CPPUNIT_ASSERT(xDrawPagesSupplier.is());
uno::Reference<drawing::XDrawPages> xDrawPages(xDrawPagesSupplier->getDrawPages());
uno::Reference<drawing::XDrawPage> xDrawPage(xDrawPages->getByIndex(1), uno::UNO_QUERY_THROW);
uno::Reference<drawing::XShape> xImage(xDrawPage->getByIndex(0), uno::UNO_QUERY_THROW);
CPPUNIT_ASSERT(xImage.is());
uno::Reference<beans::XPropertySet> xShapeProps(xImage, uno::UNO_QUERY);
uno::Reference<graphic::XGraphic> xGraphic;
CPPUNIT_ASSERT(xShapeProps->getPropertyValue("Graphic") >>= xGraphic);
Graphic aGraphic(xGraphic);
// Without the accompanying fix in place, this test would have failed with:
// - Expected: 1
// - Actual : -1
CPPUNIT_ASSERT_EQUAL(sal_Int32(1), aGraphic.getPageNumber());
}
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