mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
65e2ef43f186164729e1cc071b805bc1a7125cfe
libreoffice/svx/qa/unit/sdr.cxx

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

124 lines
4.9 KiB
C++
Raw Normal View History

tdf#129916 svx: fix origin of scaled shadow We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11 16:38:12 +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/.
*/
#include <test/bootstrapfixture.hxx>
#include <unotest/macros_test.hxx>
#include <test/xmltesttools.hxx>
#include <com/sun/star/drawing/XDrawPagesSupplier.hpp>
#include <com/sun/star/drawing/XDrawPage.hpp>
#include <com/sun/star/frame/Desktop.hpp>
#include <drawinglayer/tools/primitive2dxmldump.hxx>
#include <rtl/ustring.hxx>
#include <svx/sdr/contact/displayinfo.hxx>
#include <svx/sdr/contact/viewcontact.hxx>
#include <svx/sdr/contact/viewobjectcontact.hxx>
#include <svx/svdpage.hxx>
#include <svx/unopage.hxx>
#include <vcl/virdev.hxx>
#include <sdr/contact/objectcontactofobjlistpainter.hxx>
using namespace ::com::sun::star;
namespace
{
/// Tests for svx/source/sdr/ code.
class SdrTest : public test::BootstrapFixture, public unotest::MacrosTest, public XmlTestTools
{
protected:
uno::Reference<lang::XComponent> mxComponent;
public:
virtual void setUp() override
{
test::BootstrapFixture::setUp();
mxDesktop.set(frame::Desktop::create(m_xContext));
}
virtual void tearDown() override
{
if (mxComponent.is())
{
mxComponent->dispose();
}
test::BootstrapFixture::tearDown();
}
uno::Reference<lang::XComponent>& getComponent() { return mxComponent; }
tdf#134288 svx: fix rendering of text on a zero-width shape We have conflicting requirements here: on one hand, the shape is zero width, so the text area is also zero. On the other hand, we put some text on the shape, which should be visible. The result was that the left/right text margin (2x250 mm100) was counted as part of the text area, so we put a few (but not 1) characters / line for zero width. Fix this to be PowerPoint-compatible: as the width decreases, we break the text up to more and more lines, but if the width is 0, then we don't break it up at all. An alternative would be to do this later in SdrTextObj::impDecomposeBlockTextPrimitive(), but there we no longer know the width is really 0, because the text margins and some small increase (+1 to be an inclusive range, +1 to have a non-zero scale) is already added to the original width. Change-Id: Ieaa3e726bc5d37983b6221452e14f01db315f790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108835 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-01-06 10:23:44 +01:00
drawinglayer::primitive2d::Primitive2DContainer
renderPageToPrimitives(const uno::Reference<drawing::XDrawPage>& xDrawPage);
tdf#129916 svx: fix origin of scaled shadow We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11 16:38:12 +02:00
};
tdf#134288 svx: fix rendering of text on a zero-width shape We have conflicting requirements here: on one hand, the shape is zero width, so the text area is also zero. On the other hand, we put some text on the shape, which should be visible. The result was that the left/right text margin (2x250 mm100) was counted as part of the text area, so we put a few (but not 1) characters / line for zero width. Fix this to be PowerPoint-compatible: as the width decreases, we break the text up to more and more lines, but if the width is 0, then we don't break it up at all. An alternative would be to do this later in SdrTextObj::impDecomposeBlockTextPrimitive(), but there we no longer know the width is really 0, because the text margins and some small increase (+1 to be an inclusive range, +1 to have a non-zero scale) is already added to the original width. Change-Id: Ieaa3e726bc5d37983b6221452e14f01db315f790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108835 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-01-06 10:23:44 +01:00
drawinglayer::primitive2d::Primitive2DContainer
SdrTest::renderPageToPrimitives(const uno::Reference<drawing::XDrawPage>& xDrawPage)
tdf#129916 svx: fix origin of scaled shadow We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11 16:38:12 +02:00
{
auto pDrawPage = dynamic_cast<SvxDrawPage*>(xDrawPage.get());
CPPUNIT_ASSERT(pDrawPage);
SdrPage* pSdrPage = pDrawPage->GetSdrPage();
ScopedVclPtrInstance<VirtualDevice> aVirtualDevice;
sdr::contact::ObjectContactOfObjListPainter aObjectContact(*aVirtualDevice,
{ pSdrPage->GetObj(0) }, nullptr);
const sdr::contact::ViewObjectContact& rDrawPageVOContact
= pSdrPage->GetViewContact().GetViewObjectContact(aObjectContact);
sdr::contact::DisplayInfo aDisplayInfo;
tdf#134288 svx: fix rendering of text on a zero-width shape We have conflicting requirements here: on one hand, the shape is zero width, so the text area is also zero. On the other hand, we put some text on the shape, which should be visible. The result was that the left/right text margin (2x250 mm100) was counted as part of the text area, so we put a few (but not 1) characters / line for zero width. Fix this to be PowerPoint-compatible: as the width decreases, we break the text up to more and more lines, but if the width is 0, then we don't break it up at all. An alternative would be to do this later in SdrTextObj::impDecomposeBlockTextPrimitive(), but there we no longer know the width is really 0, because the text margins and some small increase (+1 to be an inclusive range, +1 to have a non-zero scale) is already added to the original width. Change-Id: Ieaa3e726bc5d37983b6221452e14f01db315f790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108835 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-01-06 10:23:44 +01:00
return rDrawPageVOContact.getPrimitive2DSequenceHierarchy(aDisplayInfo);
}
CPPUNIT_TEST_FIXTURE(SdrTest, testShadowScaleOrigin)
{
// Load a document containing a custom shape.
test::Directories aDirectories;
OUString aURL = aDirectories.getURLFromSrc(u"svx/qa/unit/data/shadow-scale-origin.pptx");
getComponent() = loadFromDesktop(aURL);
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(getComponent(), uno::UNO_QUERY);
uno::Reference<drawing::XDrawPage> xDrawPage(xDrawPagesSupplier->getDrawPages()->getByIndex(0),
uno::UNO_QUERY);
tdf#129916 svx: fix origin of scaled shadow We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11 16:38:12 +02:00
drawinglayer::primitive2d::Primitive2DContainer xPrimitiveSequence
tdf#134288 svx: fix rendering of text on a zero-width shape We have conflicting requirements here: on one hand, the shape is zero width, so the text area is also zero. On the other hand, we put some text on the shape, which should be visible. The result was that the left/right text margin (2x250 mm100) was counted as part of the text area, so we put a few (but not 1) characters / line for zero width. Fix this to be PowerPoint-compatible: as the width decreases, we break the text up to more and more lines, but if the width is 0, then we don't break it up at all. An alternative would be to do this later in SdrTextObj::impDecomposeBlockTextPrimitive(), but there we no longer know the width is really 0, because the text margins and some small increase (+1 to be an inclusive range, +1 to have a non-zero scale) is already added to the original width. Change-Id: Ieaa3e726bc5d37983b6221452e14f01db315f790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108835 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-01-06 10:23:44 +01:00
= renderPageToPrimitives(xDrawPage);
tdf#129916 svx: fix origin of scaled shadow We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11 16:38:12 +02:00
// Examine the created primitives.
move Primitive2dXmlDump from drawinglayer::tools to drawinglayer NS drawinglayer::tools causes conflicts with ::tools namespace, so better to move Primitive2dXmlDump out from this namespace as for inspecting purposes it ccan be injected into existing code which could break make it conflict and break compilation. Change-Id: I5f9e594b2b8b1dd24067fa5f5ca3cfc4eefb85cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98627 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-07-07 23:09:57 +02:00
drawinglayer::Primitive2dXmlDump aDumper;
tdf#129916 svx: fix origin of scaled shadow We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11 16:38:12 +02:00
xmlDocUniquePtr pDocument = aDumper.dumpAndParse(xPrimitiveSequence);
double fShadowX = getXPath(pDocument, "//shadow/transform", "xy13").toDouble();
double fShadowY = getXPath(pDocument, "//shadow/transform", "xy23").toDouble();
// Without the accompanying fix in place, this test would have failed with:
// - Expected: -705
// - Actual : -158
// i.e. the shadow origin was not the top right corner for scaling (larger x position, so it was
// visible on the right of the shape as well).
CPPUNIT_ASSERT_EQUAL(-705., std::round(fShadowX));
CPPUNIT_ASSERT_EQUAL(-685., std::round(fShadowY));
}
tdf#134288 svx: fix rendering of text on a zero-width shape We have conflicting requirements here: on one hand, the shape is zero width, so the text area is also zero. On the other hand, we put some text on the shape, which should be visible. The result was that the left/right text margin (2x250 mm100) was counted as part of the text area, so we put a few (but not 1) characters / line for zero width. Fix this to be PowerPoint-compatible: as the width decreases, we break the text up to more and more lines, but if the width is 0, then we don't break it up at all. An alternative would be to do this later in SdrTextObj::impDecomposeBlockTextPrimitive(), but there we no longer know the width is really 0, because the text margins and some small increase (+1 to be an inclusive range, +1 to have a non-zero scale) is already added to the original width. Change-Id: Ieaa3e726bc5d37983b6221452e14f01db315f790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108835 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-01-06 10:23:44 +01:00
CPPUNIT_TEST_FIXTURE(SdrTest, testZeroWidthTextWrap)
{
// Load a document containing a 0-width shape with text.
test::Directories aDirectories;
OUString aURL = aDirectories.getURLFromSrc(u"svx/qa/unit/data/0-width-text-wrap.pptx");
getComponent() = loadFromDesktop(aURL);
uno::Reference<drawing::XDrawPagesSupplier> xDrawPagesSupplier(getComponent(), uno::UNO_QUERY);
uno::Reference<drawing::XDrawPage> xDrawPage(xDrawPagesSupplier->getDrawPages()->getByIndex(0),
uno::UNO_QUERY);
drawinglayer::primitive2d::Primitive2DContainer xPrimitiveSequence
= renderPageToPrimitives(xDrawPage);
// Examine the created primitives.
drawinglayer::Primitive2dXmlDump aDumper;
xmlDocUniquePtr pDocument = aDumper.dumpAndParse(xPrimitiveSequence);
// Without the accompanying fix in place, this test would have failed with:
// - Expected: 1
// - Actual : 12
// i.e. the text on the only shape on the slide had 12 lines, not a single one.
assertXPath(pDocument, "//textsimpleportion", 1);
}
tdf#129916 svx: fix origin of scaled shadow We assumed that the top left corner is the origin for scaling, but that is not necessarily the case. The intention is that the shadow direction can be determined from its x and y offset, and the origin is the opposite corner of the shape. Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5 (cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-11 16:38:12 +02:00
}
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
Reference in New Issue Copy Permalink