core.git: Branch 'libreoffice-24-2' - sc/qa sc/source

[Regina Henschel (via logerrit)]

 sc/qa/unit/data/ods/tdf160369_groupshape.ods |binary
 sc/qa/unit/scshapetest.cxx   |   68 +++
 sc/source/core/data/drwlayer.cxx |4 +
 sc/source/filter/xml/xmlexprt.cxx|   41 +++-
 4 files changed, 100 insertions(+), 13 deletions(-)

New commits:
commit 4e04b442e037a2f679b4cfe26c3e6b1c66ee8642
Author: Regina Henschel 
AuthorDate: Sat Apr 6 14:59:38 2024 +0200
Commit: Xisco Fauli 
CommitDate: Mon Apr 8 17:31:42 2024 +0200

tdf#160369 Do not broadcast temporarily group change

The position and size of a group needs to be temporarily changed when
saving because ODF does not treat hidden rows/cols as zero, but LO does.
After saving, these changes have to be undone. The error was that the
restore was performed with GetGeoDate/SetGeoData. But SetGeoData
includes a broadcast that triggeres recalculations that should not be
performed here. Now the change and restore are both done with NbcMove
and NbcResize.

The import had set a 'logical rectangle', but that is nonsense for a
group, because a group does not have a 'logical rectangle'.
For a group, none of the special corrections in
ScDrawLayer::InitializeCellAnchoredObj are needed.

Change-Id: I00adf39e8302492822d2900e41242d188e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165872
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit 1e1b1d46155163380252093d9d2868351236ce0e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165839
Reviewed-by: Xisco Fauli 

diff --git a/sc/qa/unit/data/ods/tdf160369_groupshape.ods 
b/sc/qa/unit/data/ods/tdf160369_groupshape.ods
new file mode 100644
index ..8c26fe8ce582
Binary files /dev/null and b/sc/qa/unit/data/ods/tdf160369_groupshape.ods differ
diff --git a/sc/qa/unit/scshapetest.cxx b/sc/qa/unit/scshapetest.cxx
index 5e4827005388..c5b4b098c80e 100644
--- a/sc/qa/unit/scshapetest.cxx
+++ b/sc/qa/unit/scshapetest.cxx
@@ -1231,6 +1231,74 @@ CPPUNIT_TEST_FIXTURE(ScShapeTest, 
testTdf160003_copy_page_anchored)
 CPPUNIT_ASSERT_EQUAL(size_t(1), pPage->GetObjCount());
 }
 
+CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf160369_groupshape)
+{
+// The document contains a group spanning range C5:F12. It is currently 
anchored to page to
+// make sure its position does not change. When the group was anchored 'To 
Cell' and rows or
+// columns were hidden before the group, saving changed the anchor 
position and anchor
+// offset. This happened both with using 'resize with cell' and not.
+createScDoc("ods/tdf160369_groupshape.ods");
+
+// Get document and group object
+ScDocument* pDoc = getScDoc();
+SdrObject* pObj = lcl_getSdrObjectWithAssert(*pDoc, 0);
+
+// Anchor group 'To Cell (resize with cell)' to prepare the test.
+ScDrawLayer::SetCellAnchoredFromPosition(*pObj, *pDoc, 0 /*SCTAB*/, true 
/*bResizeWithCell*/);
+
+// Hide rows 3 and 4 (UI number), which are before the group
+// Hide column D, which is inside the group
+pDoc->SetRowHidden(2, 3, 0, true);
+pDoc->SetDrawPageSize(0); // trigger recalcpos, otherwise shapes are not 
changed
+pDoc->SetColHidden(3, 3, 0, true);
+pDoc->SetDrawPageSize(0);
+
+// Get geometry of the group
+ScDrawObjData* pObjData = ScDrawLayer::GetObjData(pObj);
+ScAddress aOrigStart = (*pObjData).maStart;
+ScAddress aOrigEnd = (*pObjData).maEnd;
+tools::Rectangle aOrigRect = pObj->GetSnapRect();
+
+// Save document but do not reload. Saving alone had already caused the 
error.
+save("calc8");
+
+// Get geometry of the group again
+ScDrawObjData* pAfterObjData = ScDrawLayer::GetObjData(pObj);
+ScAddress aAfterStart = (*pAfterObjData).maStart;
+ScAddress aAfterEnd = (*pAfterObjData).maEnd;
+tools::Rectangle aAfterRect = pObj->GetSnapRect();
+
+// verify Orig equals After
+CPPUNIT_ASSERT_EQUAL(aOrigStart, aAfterStart);
+CPPUNIT_ASSERT_EQUAL(aOrigEnd, aAfterEnd);
+CPPUNIT_ASSERT_RECTANGLE_EQUAL_WITH_TOLERANCE(aOrigRect, aAfterRect, 1);
+
+// The same but with saveAndReload.
+createScDoc("ods/tdf160369_groupshape.ods");
+pDoc = getScDoc();
+pObj = lcl_getSdrObjectWithAssert(*pDoc, 0);
+ScDrawLayer::SetCellAnchoredFromPosition(*pObj, *pDoc, 0 /*SCTAB*/, true 
/*bResizeWithCell*/);
+pDoc->SetRowHidden(2, 3, 0, true);
+pDoc->SetDrawPageSize(0); // trigger recalcpos, otherwise shapes are not 
changed
+pDoc->SetColHidden(3, 3, 0, true);
+pDoc->SetDrawPageSize(0);
+
+saveAndReload("calc8");
+
+// Verify geometry is same as before save
+pDoc = getScDoc();
+pObj = lcl_getSdrObjectWithAssert(*pDoc, 0);
+pAfterObjData = ScDrawLayer::GetObjData(pObj);
+aAfterStart = (*pAfterObjData).maStart;
+aAfterEnd = (*pAfterObjData).maEnd;

core.git: sc/qa sc/source

[Regina Henschel (via logerrit)]

 sc/qa/unit/data/ods/tdf160369_groupshape.ods |binary
 sc/qa/unit/scshapetest.cxx   |   68 +++
 sc/source/core/data/drwlayer.cxx |4 +
 sc/source/filter/xml/xmlexprt.cxx|   41 +++-
 4 files changed, 100 insertions(+), 13 deletions(-)

New commits:
commit 1e1b1d46155163380252093d9d2868351236ce0e
Author: Regina Henschel 
AuthorDate: Sat Apr 6 14:59:38 2024 +0200
Commit: Regina Henschel 
CommitDate: Mon Apr 8 15:50:40 2024 +0200

tdf#160369 Do not broadcast temporarily group change

The position and size of a group needs to be temporarily changed when
saving because ODF does not treat hidden rows/cols as zero, but LO does.
After saving, these changes have to be undone. The error was that the
restore was performed with GetGeoDate/SetGeoData. But SetGeoData
includes a broadcast that triggeres recalculations that should not be
performed here. Now the change and restore are both done with NbcMove
and NbcResize.

The import had set a 'logical rectangle', but that is nonsense for a
group, because a group does not have a 'logical rectangle'.
For a group, none of the special corrections in
ScDrawLayer::InitializeCellAnchoredObj are needed.

Change-Id: I00adf39e8302492822d2900e41242d188e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165872
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/sc/qa/unit/data/ods/tdf160369_groupshape.ods 
b/sc/qa/unit/data/ods/tdf160369_groupshape.ods
new file mode 100644
index ..8c26fe8ce582
Binary files /dev/null and b/sc/qa/unit/data/ods/tdf160369_groupshape.ods differ
diff --git a/sc/qa/unit/scshapetest.cxx b/sc/qa/unit/scshapetest.cxx
index 98e98aee54f7..5aa24ede6ea6 100644
--- a/sc/qa/unit/scshapetest.cxx
+++ b/sc/qa/unit/scshapetest.cxx
@@ -1227,6 +1227,74 @@ CPPUNIT_TEST_FIXTURE(ScShapeTest, 
testTdf160003_copy_page_anchored)
 CPPUNIT_ASSERT_EQUAL(size_t(1), pPage->GetObjCount());
 }
 
+CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf160369_groupshape)
+{
+// The document contains a group spanning range C5:F12. It is currently 
anchored to page to
+// make sure its position does not change. When the group was anchored 'To 
Cell' and rows or
+// columns were hidden before the group, saving changed the anchor 
position and anchor
+// offset. This happened both with using 'resize with cell' and not.
+createScDoc("ods/tdf160369_groupshape.ods");
+
+// Get document and group object
+ScDocument* pDoc = getScDoc();
+SdrObject* pObj = lcl_getSdrObjectWithAssert(*pDoc, 0);
+
+// Anchor group 'To Cell (resize with cell)' to prepare the test.
+ScDrawLayer::SetCellAnchoredFromPosition(*pObj, *pDoc, 0 /*SCTAB*/, true 
/*bResizeWithCell*/);
+
+// Hide rows 3 and 4 (UI number), which are before the group
+// Hide column D, which is inside the group
+pDoc->SetRowHidden(2, 3, 0, true);
+pDoc->SetDrawPageSize(0); // trigger recalcpos, otherwise shapes are not 
changed
+pDoc->SetColHidden(3, 3, 0, true);
+pDoc->SetDrawPageSize(0);
+
+// Get geometry of the group
+ScDrawObjData* pObjData = ScDrawLayer::GetObjData(pObj);
+ScAddress aOrigStart = (*pObjData).maStart;
+ScAddress aOrigEnd = (*pObjData).maEnd;
+tools::Rectangle aOrigRect = pObj->GetSnapRect();
+
+// Save document but do not reload. Saving alone had already caused the 
error.
+save("calc8");
+
+// Get geometry of the group again
+ScDrawObjData* pAfterObjData = ScDrawLayer::GetObjData(pObj);
+ScAddress aAfterStart = (*pAfterObjData).maStart;
+ScAddress aAfterEnd = (*pAfterObjData).maEnd;
+tools::Rectangle aAfterRect = pObj->GetSnapRect();
+
+// verify Orig equals After
+CPPUNIT_ASSERT_EQUAL(aOrigStart, aAfterStart);
+CPPUNIT_ASSERT_EQUAL(aOrigEnd, aAfterEnd);
+CPPUNIT_ASSERT_RECTANGLE_EQUAL_WITH_TOLERANCE(aOrigRect, aAfterRect, 1);
+
+// The same but with saveAndReload.
+createScDoc("ods/tdf160369_groupshape.ods");
+pDoc = getScDoc();
+pObj = lcl_getSdrObjectWithAssert(*pDoc, 0);
+ScDrawLayer::SetCellAnchoredFromPosition(*pObj, *pDoc, 0 /*SCTAB*/, true 
/*bResizeWithCell*/);
+pDoc->SetRowHidden(2, 3, 0, true);
+pDoc->SetDrawPageSize(0); // trigger recalcpos, otherwise shapes are not 
changed
+pDoc->SetColHidden(3, 3, 0, true);
+pDoc->SetDrawPageSize(0);
+
+saveAndReload("calc8");
+
+// Verify geometry is same as before save
+pDoc = getScDoc();
+pObj = lcl_getSdrObjectWithAssert(*pDoc, 0);
+pAfterObjData = ScDrawLayer::GetObjData(pObj);
+aAfterStart = (*pAfterObjData).maStart;
+aAfterEnd = (*pAfterObjData).maEnd;
+aAfterRect = pObj->GetSnapRect();
+
+// verify Orig equals After
+CPPUNIT_ASSERT_EQUAL(aOrigStart, aAfterStart);
+CPPUNIT_ASSERT_EQUAL(aOrigEnd, aAfterEnd);

line break attribute 'clear' in other writing modes than LTR

[Regina Henschel]

Hi all,

the ODF TC is working on issue OFFICE-4124 'clear' attribute for line 
breaks [1]. This attribute has been introduced by Miklos for LibreOffice 
7.6.


The question arises in the TC, how this attribute is supposed to work in 
other writing modes than LTR.


The corresponding attribute in CSS seems to work so, that clear:left 
uses the physical meaning of 'left' and not the meaning of 'start'. But 
without knowledge of an RTL language nor a CJK language, I cannot really 
test it.


So perhaps someone with knowledge in such languages can examine how 
LibreOffice interprets clear:left and clear:right. (Hossein? Jonathan?)

And Miklos can tell how it is intended to work?

The command is located in the UI in menu Insert > More breaks > Manual 
Break. That opens the 'Insert Break' dialog. Chose the option 'Line 
break' there and then one of the items in drop-down list 'Restart Location'.


It would be helpful, if you not only test it, but when you could provide 
suitable test documents too; and in case LibreOffice has a proper export 
of this attribute to docx (I don't know), then test documents in docx 
format too.


[1] https://issues.oasis-open.org/projects/OFFICE/issues/OFFICE-4124

Kind regards,
Regina







[1] https://issues.oasis-open.org/projects/OFFICE/issues/OFFICE-4124

core.git: Branch 'libreoffice-24-2' - 2 commits - download.lst external/lcms2 svx/qa svx/source

[Regina Henschel (via logerrit)]

 download.lst  |4 +-
 external/lcms2/0001-Added-missing-export.patch.1  |   25 +
 external/lcms2/ExternalPackage_lcms2.mk   |2 -
 external/lcms2/UnpackedTarball_lcms2.mk   |4 +-
 external/lcms2/c++17.patch.1  |   13 --
 svx/qa/unit/customshapes.cxx  |   42 ++
 svx/qa/unit/data/tdf160421_3D_FlipLight.odp   |binary
 svx/source/customshapes/EnhancedCustomShape3d.cxx |8 
 8 files changed, 81 insertions(+), 17 deletions(-)

New commits:
commit 9ae95bbdfe6494fb87a6e368de8ea3070c5241fb
Author: Regina Henschel 
AuthorDate: Fri Mar 29 22:44:45 2024 +0100
Commit: Xisco Fauli 
CommitDate: Tue Apr 2 17:53:16 2024 +0200

tdf#160421 flip lights too for flipped extruded shapes

If an extruded custom shape is mirrored, the lights in the scene are
also mirrored. This should not happen. MS Office keeps the light
direction in relation to the camera direction for binary files and pptx
files with legacy camera. We should do the same, especially since the UI
does not allow the user to set the light directions at arbitrary angles.
Otherwise the shape receives only ambient light.

Change-Id: I091d78c581b3d247f8b0680cd57654e3df330cdd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165562
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit 9761d4239de6398d4f6ecf08356f2ce18e502a04)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165614
Reviewed-by: Xisco Fauli 

diff --git a/svx/qa/unit/customshapes.cxx b/svx/qa/unit/customshapes.cxx
index 6ae5cc819c73..fcc68aacf413 100644
--- a/svx/qa/unit/customshapes.cxx
+++ b/svx/qa/unit/customshapes.cxx
@@ -63,6 +63,9 @@ protected:
 // get shape nShapeIndex from page 0
 uno::Reference getShape(sal_uInt8 nShapeIndex);
 sal_uInt8 countShapes();
+// fX and fY are positions relative to the size of the bitmap of the shape
+// Thus the position is indepedent from DPI
+Color getColor(uno::Reference xShape, const double& fX, 
const double& fY);
 };
 
 uno::Reference CustomshapesTest::getShape(sal_uInt8 
nShapeIndex)
@@ -89,6 +92,18 @@ sal_uInt8 CustomshapesTest::countShapes()
 return xDrawPage->getCount();
 }
 
+Color CustomshapesTest::getColor(uno::Reference xShape, const 
double& fX,
+ const double& fY)
+{
+GraphicHelper::SaveShapeAsGraphicToPath(mxComponent, xShape, "image/png", 
maTempFile.GetURL());
+SvFileStream aFileStream(maTempFile.GetURL(), StreamMode::READ);
+vcl::PngImageReader aPNGReader(aFileStream);
+Bitmap aBMP = aPNGReader.read().GetBitmap();
+Size aSize = aBMP.GetSizePixel();
+BitmapScopedReadAccess pRead(aBMP);
+return pRead->GetColor(aSize.Height() * fY, aSize.Width() * fX);
+}
+
 CPPUNIT_TEST_FIXTURE(CustomshapesTest, testTdf150302)
 {
 loadFromFile(u"FontworkSameLetterHeights.fodg");
@@ -1381,6 +1396,33 @@ CPPUNIT_TEST_FIXTURE(CustomshapesTest, 
testTdf153000_MS0_SPT_25_31)
 CPPUNIT_ASSERT_EQUAL(aExpected[i], aCoordinates.getLength());
 }
 }
+
+CPPUNIT_TEST_FIXTURE(CustomshapesTest, testTdf160421_3D_FlipLight)
+{
+// The document contains (0)an extruded 'rectangle' custom shape which is 
illuminated with front
+// light, (1) this shape vertically flipped and (2) this shape 
horizontally flipped.
+// When the shape is flipped vertically or horizontally, the light 
direction should not
+// change. MS Office behaves in this way for ppt and pptx and it is 
meaningful as flipping is
+// applied to the shape, not to the scene.
+
+// Load document.
+loadFromFile(u"tdf160421_3D_FlipLight.odp");
+
+// Get color from untransformed shape (0).
+uno::Reference xShape = getShape(0);
+Color aNormalColor = getColor(xShape, 0.6, 0.6);
+
+// Test that color from vertically flipped shape (1) is same as normal 
color. Without the fix
+// it was only build from ambient light and thus much darker.
+xShape = getShape(1);
+sal_uInt16 nColorDistance = aNormalColor.GetColorError(getColor(xShape, 
0.6, 0.6));
+CPPUNIT_ASSERT_LESS(sal_uInt16(6), nColorDistance);
+
+// Same for horizontally flipped shape (2)
+xShape = getShape(2);
+nColorDistance = aNormalColor.GetColorError(getColor(xShape, 0.6, 0.6));
+CPPUNIT_ASSERT_LESS(sal_uInt16(6), nColorDistance);
+}
 }
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/svx/qa/unit/data/tdf160421_3D_FlipLight.odp 
b/svx/qa/unit/data/tdf160421_3D_FlipLight.odp
new file mode 100644
index ..2decc51e3e6d
Binary files /dev/null and b/svx/qa/unit/data/tdf160421_3D_FlipLight.odp differ
diff --git a/svx/source/customshapes/EnhancedCustomShape3d.cxx 
b/svx/source/customshapes/EnhancedCustomShape3d.cxx
index a401246277cc..2a2d049e184a 100644
--- a/svx/source/cus

core.git: svx/qa svx/source

[Regina Henschel (via logerrit)]

 svx/qa/unit/customshapes.cxx  |   42 ++
 svx/qa/unit/data/tdf160421_3D_FlipLight.odp   |binary
 svx/source/customshapes/EnhancedCustomShape3d.cxx |8 
 3 files changed, 50 insertions(+)

New commits:
commit 9761d4239de6398d4f6ecf08356f2ce18e502a04
Author: Regina Henschel 
AuthorDate: Fri Mar 29 22:44:45 2024 +0100
Commit: Regina Henschel 
CommitDate: Sat Mar 30 21:19:25 2024 +0100

tdf#160421 flip lights too for flipped extruded shapes

If an extruded custom shape is mirrored, the lights in the scene are
also mirrored. This should not happen. MS Office keeps the light
direction in relation to the camera direction for binary files and pptx
files with legacy camera. We should do the same, especially since the UI
does not allow the user to set the light directions at arbitrary angles.
Otherwise the shape receives only ambient light.

Change-Id: I091d78c581b3d247f8b0680cd57654e3df330cdd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165562
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/svx/qa/unit/customshapes.cxx b/svx/qa/unit/customshapes.cxx
index 617c97300c43..92770e9f2320 100644
--- a/svx/qa/unit/customshapes.cxx
+++ b/svx/qa/unit/customshapes.cxx
@@ -58,6 +58,9 @@ protected:
 // get shape nShapeIndex from page 0
 uno::Reference getShape(sal_uInt8 nShapeIndex);
 sal_uInt8 countShapes();
+// fX and fY are positions relative to the size of the bitmap of the shape
+// Thus the position is indepedent from DPI
+Color getColor(uno::Reference xShape, const double& fX, 
const double& fY);
 };
 
 uno::Reference CustomshapesTest::getShape(sal_uInt8 
nShapeIndex)
@@ -84,6 +87,18 @@ sal_uInt8 CustomshapesTest::countShapes()
 return xDrawPage->getCount();
 }
 
+Color CustomshapesTest::getColor(uno::Reference xShape, const 
double& fX,
+ const double& fY)
+{
+GraphicHelper::SaveShapeAsGraphicToPath(mxComponent, xShape, "image/png", 
maTempFile.GetURL());
+SvFileStream aFileStream(maTempFile.GetURL(), StreamMode::READ);
+vcl::PngImageReader aPNGReader(aFileStream);
+Bitmap aBMP = aPNGReader.read().GetBitmap();
+Size aSize = aBMP.GetSizePixel();
+BitmapScopedReadAccess pRead(aBMP);
+return pRead->GetColor(aSize.Height() * fY, aSize.Width() * fX);
+}
+
 CPPUNIT_TEST_FIXTURE(CustomshapesTest, testTdf150302)
 {
 loadFromFile(u"FontworkSameLetterHeights.fodg");
@@ -1376,6 +1391,33 @@ CPPUNIT_TEST_FIXTURE(CustomshapesTest, 
testTdf153000_MS0_SPT_25_31)
 CPPUNIT_ASSERT_EQUAL(aExpected[i], aCoordinates.getLength());
 }
 }
+
+CPPUNIT_TEST_FIXTURE(CustomshapesTest, testTdf160421_3D_FlipLight)
+{
+// The document contains (0)an extruded 'rectangle' custom shape which is 
illuminated with front
+// light, (1) this shape vertically flipped and (2) this shape 
horizontally flipped.
+// When the shape is flipped vertically or horizontally, the light 
direction should not
+// change. MS Office behaves in this way for ppt and pptx and it is 
meaningful as flipping is
+// applied to the shape, not to the scene.
+
+// Load document.
+loadFromFile(u"tdf160421_3D_FlipLight.odp");
+
+// Get color from untransformed shape (0).
+uno::Reference xShape = getShape(0);
+Color aNormalColor = getColor(xShape, 0.6, 0.6);
+
+// Test that color from vertically flipped shape (1) is same as normal 
color. Without the fix
+// it was only build from ambient light and thus much darker.
+xShape = getShape(1);
+sal_uInt16 nColorDistance = aNormalColor.GetColorError(getColor(xShape, 
0.6, 0.6));
+CPPUNIT_ASSERT_LESS(sal_uInt16(6), nColorDistance);
+
+// Same for horizontally flipped shape (2)
+xShape = getShape(2);
+nColorDistance = aNormalColor.GetColorError(getColor(xShape, 0.6, 0.6));
+CPPUNIT_ASSERT_LESS(sal_uInt16(6), nColorDistance);
+}
 }
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/svx/qa/unit/data/tdf160421_3D_FlipLight.odp 
b/svx/qa/unit/data/tdf160421_3D_FlipLight.odp
new file mode 100644
index ..2decc51e3e6d
Binary files /dev/null and b/svx/qa/unit/data/tdf160421_3D_FlipLight.odp differ
diff --git a/svx/source/customshapes/EnhancedCustomShape3d.cxx 
b/svx/source/customshapes/EnhancedCustomShape3d.cxx
index 2763c9e47e00..d2f9de215f65 100644
--- a/svx/source/customshapes/EnhancedCustomShape3d.cxx
+++ b/svx/source/customshapes/EnhancedCustomShape3d.cxx
@@ -838,6 +838,14 @@ rtl::Reference 
EnhancedCustomShape3d::Create3DObject(
 basegfx::B3DVector aLight2Vector(aSecondLightDirection.DirectionX, 
-aSecondLightDirection.DirectionY, aSecondLightDirection.DirectionZ);
 aLight2Vector.normalize();
 
+// tdf#160421 a single flip inverts the light directions currently 
(March 2024). So invert
+// their directio

Re: https://opengrok.libreoffice.org/ has no project "core"

[Regina Henschel]

Hi all,
I have written https://redmine.documentfoundation.org/issues/3727

Kind regards,
Regina

Mike Kaganski schrieb am 29.03.2024 um 20:11:

On 29.03.2024 23:31, Regina Henschel wrote:
https://opengrok.libreoffice.org/ has neither in 'Projects' nor in the 
'Repository' list a project 'core'.


Same here.

https://opengrok.libreoffice.org/ has no project "core"

[Regina Henschel]

Hi all,

https://opengrok.libreoffice.org/ has neither in 'Projects' nor in the 
'Repository' list a project 'core'.


The direct link https://opengrok.libreoffice.org/xref/core/ works. But 
that does not allow search.


Is it only for me or do you have the same problem?

I have tested Firefox, Chrome and Edge.


Kind regards,
Regina

core.git: oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/Scene3d_shape_rotation.pptx |binary
 oox/qa/unit/testscene3d.cxx  |   12 +
 oox/source/export/drawingml.cxx  |   57 +++
 3 files changed, 54 insertions(+), 15 deletions(-)

New commits:
commit 207876cdcd7a4c19940d769a52d118751059dfe0
Author: Regina Henschel 
AuthorDate: Tue Mar 26 23:52:34 2024 +0100
Commit: Regina Henschel 
CommitDate: Wed Mar 27 16:48:20 2024 +0100

Restore shape rotation on roundtrip of pptx 3D shape

As long as our support for extruded custom shapes from MS Office is
rudimentary, we should restore the original values in case of saving
to pptx.

The patch uses the angle out of the interopGrabBag even if the user
has changed the shape rotation. Considering a different angle would
require to calculate camera, light rig and shape rotations. The effort
for that is too large.

Change-Id: Ib0549acc4ae13badd44fe9ae221a56ad21d28e1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165359
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/qa/unit/data/Scene3d_shape_rotation.pptx 
b/oox/qa/unit/data/Scene3d_shape_rotation.pptx
new file mode 100644
index ..c8645e8a3780
Binary files /dev/null and b/oox/qa/unit/data/Scene3d_shape_rotation.pptx differ
diff --git a/oox/qa/unit/testscene3d.cxx b/oox/qa/unit/testscene3d.cxx
index 4b6415424515..fdad25be2cea 100644
--- a/oox/qa/unit/testscene3d.cxx
+++ b/oox/qa/unit/testscene3d.cxx
@@ -623,6 +623,18 @@ CPPUNIT_TEST_FIXTURE(TestScene3d, test_pureImage)
 CPPUNIT_ASSERT_EQUAL(sal_Int32(27000), nZRotate);
 }
 
+CPPUNIT_TEST_FIXTURE(TestScene3d, test_shape_rotation)
+{
+// Given a document with a shape in 3D mode with shape rotation 
rot="30".
+loadFromFile(u"Scene3d_shape_rotation.pptx");
+uno::Reference xShape(getShape(0, 0));
+
+// Make sure that the immediate export to pptx has the same shape rotation
+save("Impress Office Open XML");
+xmlDocUniquePtr pXmlDoc = parseExport("ppt/slides/slide1.xml");
+assertXPath(pXmlDoc, "//p:spPr/a:xfrm"_ostr, "rot"_ostr, "30");
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/oox/source/export/drawingml.cxx b/oox/source/export/drawingml.cxx
index 20dba5b60de9..59b32eb2df4e 100644
--- a/oox/source/export/drawingml.cxx
+++ b/oox/source/export/drawingml.cxx
@@ -2354,35 +2354,62 @@ void DrawingML::WriteShapeTransformation( const 
Reference< XShape >& rXShape, sa
 if (xPropertySet->getPropertyValue("RotateAngle") >>= nTmp)
 nRotation = Degree100(nTmp);
 }
-// tdf#133037: restore original rotate angle before output
-if (nRotation && 
xPropertySetInfo->hasPropertyByName(UNO_NAME_MISC_OBJ_INTEROPGRABBAG))
+
+// As long as the support of MS Office 3D-features is rudimentary, we 
restore the original
+// values from InteropGrabBag. This affects images and custom shapes.
+if 
(xPropertySetInfo->hasPropertyByName(UNO_NAME_MISC_OBJ_INTEROPGRABBAG))
 {
 uno::Sequence aGrabBagProps;
 xPropertySet->getPropertyValue(UNO_NAME_MISC_OBJ_INTEROPGRABBAG) 
>>= aGrabBagProps;
-auto p3DEffectProps = std::find_if(std::cbegin(aGrabBagProps), 
std::cend(aGrabBagProps),
+auto p3DEffectProps = std::find_if(
+std::cbegin(aGrabBagProps), std::cend(aGrabBagProps),
 [](const PropertyValue& rProp) { return rProp.Name == 
"3DEffectProperties"; });
 if (p3DEffectProps != std::cend(aGrabBagProps))
 {
 uno::Sequence a3DEffectProps;
 p3DEffectProps->Value >>= a3DEffectProps;
-auto pCameraProps = std::find_if(std::cbegin(a3DEffectProps), 
std::cend(a3DEffectProps),
-[](const PropertyValue& rProp) { return rProp.Name == 
"Camera"; });
-if (pCameraProps != std::cend(a3DEffectProps))
+// We have imported a scene3d.
+if (rXShape->getShapeType() == 
"com.sun.star.drawing.CustomShape")
+{
+auto pMSORotation
+= std::find_if(std::cbegin(aGrabBagProps), 
std::cend(aGrabBagProps),
+   [](const PropertyValue& rProp) {
+   return rProp.Name == 
"mso-rotation-angle";
+   });
+sal_Int32 nMSORotation = 0;
+if (pMSORotation != std::cend(aGrabBagProps))
+pMSORotation->Value >>= nMSORotation;
+WriteTransformation(
+rXShape,
+

Re: Import of 3D-Image from pptx

[Regina Henschel]

Hi Miklos,

sorry for not answering, but I haven't got your mail. Only Mike notified 
me just, that there is an answer from you. I have read your mail now 
from the archive.



I think in both cases the ideal would be to extend SdrGrafObj, to
support cropping and 3D properties if PPTX supports that. Of course,
it's good to share code with SdrObjCustomShape in the implementation if
possible.



If that's not possible (takes too much time, too complex), then it's an
option to map the images to custom shapes in our side, but sooner or
later these workarounds cause some problems. So at least some TODO /
FIXME comment would be nice, if you go this way.


I have used a minimal solution for now that only extends the already 
existing way of representing a "crop to shape" image by a custom shape. 
That does not prevent to map images to custom shapes in case such 
workaround is wanted.


Currently I work on adapting the export. This has priority. I want to 
keep the current behavior for version 24.8, that the 3D-scene is 
recreated on export in case of round-trip, that means in case there is a 
InteropGrabBag.


It would be a large change to extend SdrGrafObj with 3D-abilities. I 
think, that we first need a general plan about what we need to do and in 
what order, to bring LO nearer to the 3D features of MS Office. The 
rendering of extruded custom shape as 3D uses a temporary 3D-Scene. But 
that lacks so much, that I do not like to implement a similar solution 
for SdrGrafObj, especially as the standard would also need to be 
extended. I think the latter should only be done, when we have already 
defined the final goal.


I plan to meet Armin in Hamburg end of April. Are you interested in 
joining the discussion?


Kind regards,
Regina

Re: Import of 3D-Image from pptx

[Regina Henschel]

Hi all,

as no one has an opinion on this topic, I have now decided to continue 
to import a 3D image, which is not cropped to a shape, as pure image.

https://gerrit.libreoffice.org/c/core/+/165194

For further improvements in 3D import we first need a general plan, 
because deeper changes in code are needed.


Kind regards,
Regina

Regina Henschel schrieb am 21.03.2024 um 23:41:

Hi all,

at the moment, a 3D image is imported as an image and displayed in 
Impress without 3D. The 3D properties are in the InteropGrabBag and are 
written out again on export, in addition to a rotation or mirroring that 
the user has made with the image in LO.


The 3D image could be treated in the same way as an image that has been 
cropped to a shape in PowerPoint. Such an image is imported as a custom 
shape with bitmap filling. Such a custom shape can then be displayed in 
3D mode. When saving, however, as with the cropped image, the result 
would not be a pure image but a shape with a bitmap fill.


What do you think? Should I implement this or should I continue to 
import a 3D image as a pure image?


Kind regards,
Regina

core.git: oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/Scene3d_cropped_image.pptx |binary
 oox/qa/unit/data/Scene3d_pureImage.pptx |binary
 oox/qa/unit/testscene3d.cxx |   68 
 oox/source/drawingml/scene3dhelper.cxx  |   20 +---
 oox/source/drawingml/shape.cxx  |8 +--
 5 files changed, 85 insertions(+), 11 deletions(-)

New commits:
commit 15e43d9679773efcf869ff8272c7932b59fe1c68
Author: Regina Henschel 
AuthorDate: Fri Mar 22 10:43:48 2024 +0100
Commit: Regina Henschel 
CommitDate: Sat Mar 23 10:20:25 2024 +0100

tdf#70039 partly enable 3D-image from pptx

This enables 3D for those images, that have been cropped to a shape.
Those images are imported as custom shapes anyway and thus can use the
now possible rendering as 3D-scene.

The patch does not change the import of pure images with 3D properties.
(Such is possible in OOXML.) Using a custom shape here too, would
restrict the user. Exchange of the image or using color corrections
and filters on the image, for example, would be no longer possible.

It also fixes the error, that a z-rotation of a pure image was no
longer considered.

Change-Id: I626b1687c5aed1cac6f35388a3b25941673b5513
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165194
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/qa/unit/data/Scene3d_cropped_image.pptx 
b/oox/qa/unit/data/Scene3d_cropped_image.pptx
new file mode 100644
index ..d97a7afae42b
Binary files /dev/null and b/oox/qa/unit/data/Scene3d_cropped_image.pptx differ
diff --git a/oox/qa/unit/data/Scene3d_pureImage.pptx 
b/oox/qa/unit/data/Scene3d_pureImage.pptx
new file mode 100644
index ..463d4b886760
Binary files /dev/null and b/oox/qa/unit/data/Scene3d_pureImage.pptx differ
diff --git a/oox/qa/unit/testscene3d.cxx b/oox/qa/unit/testscene3d.cxx
index ee60eb24c614..4b6415424515 100644
--- a/oox/qa/unit/testscene3d.cxx
+++ b/oox/qa/unit/testscene3d.cxx
@@ -555,6 +555,74 @@ CPPUNIT_TEST_FIXTURE(TestScene3d, test_material_wireframe)
 "shade-mode"_ostr, "draft");
 }
 
+CPPUNIT_TEST_FIXTURE(TestScene3d, test_cropped_image)
+{
+// The file contains an image that has been cropped to shape in 
PowerPoint. The image is in 3D
+// mode with perspective camera perspectiveContrastingRightFacing and 
perspective angle 120°. The
+// extrusion is 76200 EMU deep with extrusion color #00B050. As a cropped 
image, it was imported
+// in earlier LO versions as custom shape with bitmap fill, but without 
any 3D.
+loadFromFile(u"Scene3d_cropped_image.pptx");
+uno::Reference xShape(getShape(0, 0)); // shape 0 on page 0
+
+// Prepare property maps
+uno::Reference xShapeProps(xShape, uno::UNO_QUERY);
+uno::Sequence aGeoPropSeq;
+xShapeProps->getPropertyValue(u"CustomShapeGeometry"_ustr) >>= aGeoPropSeq;
+comphelper::SequenceAsHashMap aGeoPropMap(aGeoPropSeq);
+uno::Sequence aExtrusionSeq;
+aGeoPropMap.getValue(u"Extrusion"_ustr) >>= aExtrusionSeq;
+comphelper::SequenceAsHashMap aExtrusionPropMap(aExtrusionSeq);
+
+// Check that extrusion is on and has the correct geometry.
+bool bIsExtruded(false);
+aExtrusionPropMap.getValue(u"Extrusion"_ustr) >>= bIsExtruded;
+CPPUNIT_ASSERT_MESSAGE("error: Extrusion is disabled", bIsExtruded);
+
+drawing::ProjectionMode eProjectionMode = drawing::ProjectionMode_PARALLEL;
+aExtrusionPropMap.getValue(u"ProjectionMode"_ustr) >>= eProjectionMode;
+CPPUNIT_ASSERT_EQUAL(drawing::ProjectionMode_PERSPECTIVE, eProjectionMode);
+
+drawing::Position3D aViewPoint;
+aExtrusionPropMap.getValue(u"ViewPoint"_ustr) >>= aViewPoint;
+CPPUNIT_ASSERT_DOUBLES_EQUAL(0.0, aViewPoint.PositionX, 1E-12);
+CPPUNIT_ASSERT_DOUBLES_EQUAL(0.0, aViewPoint.PositionY, 1E-12);
+CPPUNIT_ASSERT_DOUBLES_EQUAL(9223.7479, aViewPoint.PositionZ, 1E-5);
+
+// Check shape rotation angles
+drawing::EnhancedCustomShapeParameterPair aParaPair;
+aExtrusionPropMap.getValue(UNO_NAME_MISC_OBJ_ROTATEANGLE) >>= aParaPair;
+CPPUNIT_ASSERT_DOUBLES_EQUAL(-6.94093344831102, 
aParaPair.First.Value.get(), 1E-12);
+CPPUNIT_ASSERT_DOUBLES_EQUAL(-44.4431265782766, 
aParaPair.Second.Value.get(), 1E-12);
+sal_Int32 nZRotate; // unit 1/100 degree
+xShapeProps->getPropertyValue(UNO_NAME_MISC_OBJ_ROTATEANGLE) >>= nZRotate;
+CPPUNIT_ASSERT_EQUAL(sal_Int32(496), nZRotate);
+
+// Check extrusion depth and color
+aExtrusionPropMap.getValue(u"Depth"_ustr) >>= aParaPair;
+CPPUNIT_ASSERT_DOUBLES_EQUAL(212.0, aParaPair.First.Value.get(), 
1E-12);
+Color nColor;
+xShapeProps->getPropertyValue(UNO_NAME_FILLCOLOR_2) >>= nColor;
+CPPUNIT_ASSERT_EQUAL(Color(0x00b050), nColor);
+}
+
+CPPUNIT_TEST_FIXTURE(

core.git: oox/source

[Regina Henschel (via logerrit)]

 oox/source/drawingml/scene3dhelper.cxx |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

New commits:
commit 9556504b213519e2900e72c81aa26a470dc6353c
Author: Regina Henschel 
AuthorDate: Fri Mar 22 00:52:25 2024 +0100
Commit: Regina Henschel 
CommitDate: Fri Mar 22 10:21:32 2024 +0100

Revert "extruded shape import: tweak threePt light rig too"

This reverts commit aa341e79ee241fec0b5afe159b0c674cf85a52c0.

Reason for revert: The front faces become too light. A similar front face 
is more important than lighter extrusion faces.

Change-Id: I7e58d19b7e6264358d46f172f23bbfea74936250
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165121
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/source/drawingml/scene3dhelper.cxx 
b/oox/source/drawingml/scene3dhelper.cxx
index cb0a85eb7ed0..acddea7643c4 100644
--- a/oox/source/drawingml/scene3dhelper.cxx
+++ b/oox/source/drawingml/scene3dhelper.cxx
@@ -840,10 +840,10 @@ void lcl_tweakLightRig(std::vector& 
rLightDirVec, PrstLightR
 rLightRig.fAmbient = 0.35; // instead 0.11 resp. 0.13
 }
 else if (rLightRig.sLightRigName == u"freezing" || rLightRig.sLightRigName 
== u"morning"
- || rLightRig.sLightRigName == u"sunrise" || 
rLightRig.sLightRigName == u"threePt")
+ || rLightRig.sLightRigName == u"sunrise")
 {
-// These rigs have no ambient color but three or four lights. The 
objects are too dark with
-// only two lights.
+// These rigs have no ambient color but four lights. The objects are 
too dark with only
+// two lights.
 rLightRig.fAmbient = 0.4;
 }
 else if (rLightRig.sLightRigName == u"sunset")

Import of 3D-Image from pptx

[Regina Henschel]

Hi all,

at the moment, a 3D image is imported as an image and displayed in 
Impress without 3D. The 3D properties are in the InteropGrabBag and are 
written out again on export, in addition to a rotation or mirroring that 
the user has made with the image in LO.


The 3D image could be treated in the same way as an image that has been 
cropped to a shape in PowerPoint. Such an image is imported as a custom 
shape with bitmap filling. Such a custom shape can then be displayed in 
3D mode. When saving, however, as with the cropped image, the result 
would not be a pure image but a shape with a bitmap fill.


What do you think? Should I implement this or should I continue to 
import a 3D image as a pure image?


Kind regards,
Regina

core.git: oox/inc oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/inc/drawingml/scene3dhelper.hxx  |   13 +
 oox/qa/unit/data/Scene3d_material_highlight.pptx |binary
 oox/qa/unit/data/Scene3d_material_wireframe.pptx |binary
 oox/qa/unit/testscene3d.cxx  |  168 +++
 oox/source/drawingml/scene3dhelper.cxx   |   93 
 oox/source/drawingml/shape.cxx   |4 
 6 files changed, 223 insertions(+), 55 deletions(-)

New commits:
commit 2eabd56ff5f65733c6fa1bcef14d4a39c21dddc7
Author: Regina Henschel 
AuthorDate: Fri Mar 15 00:00:51 2024 +0100
Commit: Regina Henschel 
CommitDate: Wed Mar 20 18:06:35 2024 +0100

tdf#70039 import material of extruded shapes

This patch continues the tdf#70039 related commits 98b06ed3 and 6e5529d7.
It adds further property-value pairs to the property map which is later
used in CustomShapeProperties.pushToPropSet() for property Extrusion.

OOXML defines a set of 15 material presets in section 20.1.10.50
ST_PresetMaterialType. The specification lists some values and it has
example pictures. The example shape uses Bevel. That is not implemented,
thus the examples are not really usable. Microsoft specifies the values
it uses in section 2.1.1331 in MS-OI29500] - v20231113. The values used
in the patch are based on these resources.

MS Office defines the material by the properties 'Specular-',
'Diffuse-', 'Ambient-' and 'Emissive-Color, 'Specular Power', 'Blinn
Hightlight', 'Diffuse-' and 'Alpha-Fresnel', and 'Metal'. But ODF, API
and current implementation have for material only the properties
'Diffusion', 'Specularity', 'Shininess', 'Metal' and 'MetalType'. The
patch tries to map the values as well as possible.

The mapping works well for the legacy-foo materials which reflect the
material in binary MS Office and is base of ODF and our implementation.
But the preset has also material where transparency is added to the
reflected light or the reflected light is blended or brightened with
White. That is not possible currently and such shapes look different
than in MS Office. These are especially the materials in the
'Translucent' section in the UI of MS Office. The material type 'flat'
uses 'Emissive Color'. Such is not available at all. So material 'flat'
looks noticable different too.

More details about the used values is contained in the attachment in
the bug report.

Change-Id: I16a242446cbe98efcbdf5452058e1a3bd88dcf56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164853
Tested-by: Jenkins
Reviewed-by: Patrick Luby 
Reviewed-by: Regina Henschel 

diff --git a/oox/inc/drawingml/scene3dhelper.hxx 
b/oox/inc/drawingml/scene3dhelper.hxx
index af72a0e0cf2a..0f79825b13ca 100644
--- a/oox/inc/drawingml/scene3dhelper.hxx
+++ b/oox/inc/drawingml/scene3dhelper.hxx
@@ -50,6 +50,19 @@ public:
 void setLightingProperties(const oox::drawingml::Shape3DPropertiesPtr 
p3DProperties,
const double& rRotZ, oox::PropertyMap& 
rPropertyMap);
 
+/** Puts the material properties of the 3D-shape into the property map
+@details OOXML and MSO describe the material properties using Specular 
Color (RGBA), Diffuse
+Color (RGBA), Ambient Color (RGBA), Emissive Color (RGBA), 
Specular Power (positive int),
+Diffuse Fresnel (int), Alpha Fresnel (int), Metal (bool) and Blinn 
Highlight (bool). ODF
+and API have Diffusion (double), Specularity (double), Shininess 
(double), Metal (bool),
+MetalType (enum). Thus a directly use of the MSO values is not 
possible and some material
+types cannot be rendered. The method uses workarounds and 
approximations.
+@param [in] p3DProperties contains besides other properties the 
material preset name
+@param [in, out] rPropertyMap has properties directly usable in
+CustomShapeProperties.pushToPropSet() for property Extrusion.*/
+static void setMaterialProperties(const 
oox::drawingml::Shape3DPropertiesPtr p3DProperties,
+  oox::PropertyMap& rPropertyMap);
+
 private:
 /** Calculates angles suitable for API from OOXML scene3d angles.
 @param [in] nLat, nLon, nRev in unit 1/6 deg with same orientation 
as the attributes lat,
diff --git a/oox/qa/unit/data/Scene3d_material_highlight.pptx 
b/oox/qa/unit/data/Scene3d_material_highlight.pptx
new file mode 100644
index ..c299c21bc68c
Binary files /dev/null and b/oox/qa/unit/data/Scene3d_material_highlight.pptx 
differ
diff --git a/oox/qa/unit/data/Scene3d_material_wireframe.pptx 
b/oox/qa/unit/data/Scene3d_material_wireframe.pptx
new file mode 100644
index ..f72baeb25178
Binary files /dev/null and b/oox/qa/unit/data/Scene3d_material_wireframe.pptx 
differ
diff --git a/oox/qa/unit/testscene3d.cxx b/oox/qa/unit/testscene

core.git: oox/source

[Regina Henschel (via logerrit)]

 oox/source/drawingml/scene3dhelper.cxx |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

New commits:
commit aa341e79ee241fec0b5afe159b0c674cf85a52c0
Author: Regina Henschel 
AuthorDate: Mon Mar 18 19:52:02 2024 +0100
Commit: Regina Henschel 
CommitDate: Tue Mar 19 12:13:19 2024 +0100

extruded shape import: tweak threePt light rig too

This is an addition to commit 98b06ed3. The light rig 'threePt' has the
same problem that with only two lights the shapes are too dark.
I simply overlooked this rig.

Change-Id: Ib71088f24245da912cf0886e75841ffd6cec786f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164975
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/source/drawingml/scene3dhelper.cxx 
b/oox/source/drawingml/scene3dhelper.cxx
index cfea2e93613b..d2b03ae97485 100644
--- a/oox/source/drawingml/scene3dhelper.cxx
+++ b/oox/source/drawingml/scene3dhelper.cxx
@@ -837,10 +837,10 @@ void lcl_tweakLightRig(std::vector& 
rLightDirVec, PrstLightR
 rLightRig.fAmbient = 0.35; // instead 0.11 resp. 0.13
 }
 else if (rLightRig.sLightRigName == u"freezing" || rLightRig.sLightRigName 
== u"morning"
- || rLightRig.sLightRigName == u"sunrise")
+ || rLightRig.sLightRigName == u"sunrise" || 
rLightRig.sLightRigName == u"threePt")
 {
-// These rigs have no ambient color but four lights. The objects are 
too dark with only
-// two lights.
+// These rigs have no ambient color but three or four lights. The 
objects are too dark with
+// only two lights.
 rLightRig.fAmbient = 0.4;
 }
 else if (rLightRig.sLightRigName == u"sunset")

core.git: xmloff/qa xmloff/source

[Regina Henschel (via logerrit)]

 xmloff/qa/unit/data/Scene3d_LightRig_threePt.pptx |binary
 xmloff/qa/unit/draw.cxx   |   12 
 xmloff/source/draw/shapeexport.cxx|5 +
 3 files changed, 17 insertions(+)

New commits:
commit 21d39b5a8c36203d18c5d67c9d2f2bb8d89a53de
Author: Regina Henschel 
AuthorDate: Sun Mar 17 16:28:12 2024 +0100
Commit: Regina Henschel 
CommitDate: Mon Mar 18 15:58:53 2024 +0100

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 

diff --git a/xmloff/qa/unit/data/Scene3d_LightRig_threePt.pptx 
b/xmloff/qa/unit/data/Scene3d_LightRig_threePt.pptx
new file mode 100644
index ..33121f2590e4
Binary files /dev/null and b/xmloff/qa/unit/data/Scene3d_LightRig_threePt.pptx 
differ
diff --git a/xmloff/qa/unit/draw.cxx b/xmloff/qa/unit/draw.cxx
index eea4e1362425..985af4f1ad5e 100644
--- a/xmloff/qa/unit/draw.cxx
+++ b/xmloff/qa/unit/draw.cxx
@@ -810,6 +810,18 @@ CPPUNIT_TEST_FIXTURE(XmloffDrawTest, 
testTdf157018_ThemeImportDraw)
 CPPUNIT_ASSERT_EQUAL(Color(0x0A0A0A), 
pColorSet->getColor(model::ThemeColorType::Hyperlink));
 CPPUNIT_ASSERT_EQUAL(Color(0x44), 
pColorSet->getColor(model::ThemeColorType::Accent1));
 }
+
+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.
+save("impress8");
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/xmloff/source/draw/shapeexport.cxx 
b/xmloff/source/draw/shapeexport.cxx
index 2322e6be63d5..01a97c5be666 100644
--- a/xmloff/source/draw/shapeexport.cxx
+++ b/xmloff/source/draw/shapeexport.cxx
@@ -125,6 +125,7 @@
 #include 
 #include 
 #include 
+#include 
 
 using namespace ::com::sun::star;
 using namespace ::xmloff::EnhancedCustomShapeToken;
@@ -4523,6 +4524,8 @@ static void ImpExportEnhancedGeometry( SvXMLExport& 
rExport, const uno::Referenc
 double fExtrusionFirstLightLevel = 0;
 if ( rProp.Value >>= 
fExtrusionFirstLightLevel )
 {
+fExtrusionFirstLightLevel =
+
std::clamp(fExtrusionFirstLightLevel, 0.0, 100.0);
 ::sax::Converter::convertDouble(
 aStrBuffer,
 fExtrusionFirstLightLevel,
@@ -4540,6 +4543,8 @@ static void ImpExportEnhancedGeometry( SvXMLExport& 
rExport, const uno::Referenc
 double fExtrusionSecondLightLevel = 0;
 if ( rProp.Value >>= 
fExtrusionSecondLightLevel )
 {
+fExtrusionSecondLightLevel =
+
std::clamp(fExtrusionSecondLightLevel, 0.0, 100.0);
 ::sax::Converter::convertDouble(
 aStrBuffer,
 fExtrusionSecondLightLevel,

Import of material presets for extruded shapes in pptx

[Regina Henschel]

Hi all,

the patch for importing the material presets for extruded shapes in pptx 
is now ready for review. Please notify my, when you intend to look at it.

https://gerrit.libreoffice.org/c/core/+/164853

Kind regards,
Regina

New implementation for extruded custom shapes

[Regina Henschel]

Hi all,

The current solution for extruded custom shapes is only suitable for 
shapes from binary MS Office files. Even not all features of ODF are 
implemented. And there are no ways at all to display modern 3D objects 
from OOXML.


Would anyone like to implement a new version for extruded custom shapes 
together with me?


Kind regards,
Regina

core.git: oox/CppunitTest_oox_testscene3d.mk oox/inc oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/CppunitTest_oox_testscene3d.mk  |6 
 oox/inc/drawingml/scene3dhelper.hxx |8 
 oox/qa/unit/data/Scene3d_lightRig_default.pptx  |binary
 oox/qa/unit/data/Scene3d_lightRig_dir_rotation.pptx |binary
 oox/qa/unit/data/Scene3d_lightRig_legacyCamera.pptx |binary
 oox/qa/unit/data/Scene3d_lightRig_modernCamera.pptx |binary
 oox/qa/unit/data/Scene3d_lightRig_rot_rotation.pptx |binary
 oox/qa/unit/testscene3d.cxx |  188 +++
 oox/source/drawingml/scene3dhelper.cxx  |  504 +++-
 oox/source/drawingml/shape.cxx  |   34 +
 10 files changed, 729 insertions(+), 11 deletions(-)

New commits:
commit 98b06ed3583fcc1f720ceb919cdd57ede7952a71
Author: Regina Henschel 
AuthorDate: Wed Mar 6 21:52:39 2024 +0100
Commit: Regina Henschel 
CommitDate: Wed Mar 13 21:43:58 2024 +0100

tdf#70039 import lighting of extruded shapes

The patch it a continuation of commit 6e5529d7, that handles import of
the 3D-scene camera. This patch handles lighting of the 3D-scene. But
lighting in MS Office has features which we cannot yet render, address
in API or store in ODF. More than two lights, softing with Scale and
and Offset, or Specular/Diffuse for all lights are not implemented for
extruded shapes, for example. Thus the rendering results cannot be
equal to MS Office.

This patch contains a lot of workarounds and compromises to get a
rendering which looks somewhat similar. Unit tests are not really
meaningful in this situation. The included tests focus on the principle
aspects modern/legacy lightRigs and lightRig rotation.

The light rig values are taken from sections 2.1.1274 and 2.1.1321 in
[MS-OI29500] - v20231113.
https://learn.microsoft.com/en-us/openspecs/office_standards/ms-oi29500

That version does not specify the used coordinate system for the
light directions. Find the discussion about that in
https://learn.microsoft.com/en-us/answers/questions/1551836
topic: LightDirection on shape with 3D effect is rendered different
than specified.

That version does not specify the values 'Specular' and 'Diffuse'
for legacy* light rigs. Find the discussion about that in
https://learn.microsoft.com/en-us/answers/questions/1608333
topic: What is 'Specular' and 'Diffuse' in the lightRig table in
section 2.1.1274 in [MS-OI29500]?

Change-Id: I91750dc231d0ea09115424d896d3a1260ba766ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164510
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/CppunitTest_oox_testscene3d.mk 
b/oox/CppunitTest_oox_testscene3d.mk
index 23b08eee6fed..f19943a3cfe3 100644
--- a/oox/CppunitTest_oox_testscene3d.mk
+++ b/oox/CppunitTest_oox_testscene3d.mk
@@ -26,11 +26,15 @@ $(eval $(call gb_CppunitTest_use_libraries,oox_testscene3d, 
\
 cppuhelper \
 oox \
 sal \
+sfx \
 subsequenttest \
+svx \
+svxcore \
 test \
+tl \
 unotest \
 utl \
-tl \
+vcl \
 ))
 
 $(eval $(call gb_CppunitTest_use_sdk_api,oox_testscene3d))
diff --git a/oox/inc/drawingml/scene3dhelper.hxx 
b/oox/inc/drawingml/scene3dhelper.hxx
index 8dd62186d895..af72a0e0cf2a 100644
--- a/oox/inc/drawingml/scene3dhelper.hxx
+++ b/oox/inc/drawingml/scene3dhelper.hxx
@@ -42,6 +42,14 @@ public:
 double& rRotZ, oox::drawingml::Color& 
rExtrusionColor,
 const bool bBlockExtrusion = false);
 
+/** Creates lighting properties in rPropertyMap from MSO preset and shape 
rotation
+@param [in] p3DProperties a pointer to Shape3DProperties
+@param [in] rRotZ the shape rotation inclusive camera z-rotation as 
calculated by
+setExtrusionProperties()
+@param [in, out] rPropertyMap the map, that was already filled by 
setExtrusionProperties()*/
+void setLightingProperties(const oox::drawingml::Shape3DPropertiesPtr 
p3DProperties,
+   const double& rRotZ, oox::PropertyMap& 
rPropertyMap);
+
 private:
 /** Calculates angles suitable for API from OOXML scene3d angles.
 @param [in] nLat, nLon, nRev in unit 1/6 deg with same orientation 
as the attributes lat,
diff --git a/oox/qa/unit/data/Scene3d_lightRig_default.pptx 
b/oox/qa/unit/data/Scene3d_lightRig_default.pptx
new file mode 100644
index ..a2d82f984e44
Binary files /dev/null and b/oox/qa/unit/data/Scene3d_lightRig_default.pptx 
differ
diff --git a/oox/qa/unit/data/Scene3d_lightRig_dir_rotation.pptx 
b/oox/qa/unit/data/Scene3d_lightRig_dir_rotation.pptx
new file mode 100644
index ..14b4486a15d1
Binary files /dev/null and 
b/oox/qa/unit/data/Scene3d_lightRig_dir_rotation.pptx differ
diff --git a/oox/qa/unit/data/Scene3d_lightRig_legacyCamera.pptx 
b/oox/qa/unit/data/Scene3d_lightRig_legacyCamera.pptx
new file m

Re: Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi all,

I have finished my patch in 
https://gerrit.libreoffice.org/c/core/+/164510, including some unit 
tests. It would be nice if someone has some time to review it. If you 
will do it, please add you their or notify my here. If no one wants to 
look at it, I'll commit it as it is.


Kind regards,
Regina

Re: ESC meeting agenda: 2024-03-06 16:00 CET

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 06.03.2024 um 16:28:

Hi,

The prototype agenda is below. Extra items are appreciated either in
this document or as a reply to this mail:

[..]


* What’s cooking (Miklos)
     + A11y update (Michael W)
     + importing 3D scenes from MSO (Regina)


I cannot attend tomorrow. Anyone interested in this topic can find the 
current state in https://gerrit.libreoffice.org/c/core/+/164510.


Kind regards,
Regina

Re: Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi all,

Regina Henschel schrieb am 22.02.2024 um 19:47:

Hi all,

I have started work on import of lighting. But there are several 
problems which make it impossible to get a 1:1 match to our capabilities.

[..]


Any ideas/wishes for a reasonably usable import?


I have uploaded the current state to Gerrit
https://gerrit.libreoffice.org/c/core/+/164510

Please notify me, if there is something which I should change.

The meaning of 'Specular' and 'Diffuse' in the specification of MS 
Office is not clear. I posted a question to the forum

https://learn.microsoft.com/en-us/answers/questions/1608333/what-is-specular-and-diffuse-in-the-lightrig-table

Besides the mentioned principle problems, this is missing: MS Office 
uses 'Gouraud' as default render mode. That is currently not used but 
the default 'Flat' mode. In some cases MSO uses Phong render mode. The 
information about that is contained in the material presets and those 
are not yet evaluated.


Kind regards,
Regina

core.git: Branch 'libreoffice-7-6' - sc/qa sc/source

[Regina Henschel (via logerrit)]

 sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods |binary
 sc/qa/unit/scshapetest.cxx |   24 +
 sc/source/core/data/drwlayer.cxx   |2 -
 3 files changed, 25 insertions(+), 1 deletion(-)

New commits:
commit 45fb563b6e93833a4dbe31bf0b0cc0a51e83f791
Author: Regina Henschel 
AuthorDate: Sun Mar 3 17:19:49 2024 +0100
Commit: Xisco Fauli 
CommitDate: Mon Mar 4 22:02:49 2024 +0100

tdf#160003 use correct sheet in clipboard for test

..whether a page anchored object is contained in the to be copied area.

Change-Id: I816e342770332e6d751b57a38e5ebabe33feb16a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164307
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit 199523b553957936dc31b8c3556ef2e47c6bc3a1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164374
Reviewed-by: Xisco Fauli 

diff --git a/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods 
b/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods
new file mode 100644
index ..565eb1bf6a26
Binary files /dev/null and 
b/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods differ
diff --git a/sc/qa/unit/scshapetest.cxx b/sc/qa/unit/scshapetest.cxx
index b5083544f114..5e4827005388 100644
--- a/sc/qa/unit/scshapetest.cxx
+++ b/sc/qa/unit/scshapetest.cxx
@@ -1207,6 +1207,30 @@ CPPUNIT_TEST_FIXTURE(ScShapeTest, 
testTdf154821_shape_in_group)
 CPPUNIT_ASSERT_RECTANGLE_EQUAL_WITH_TOLERANCE(aRectOrig, aRectReload, 1);
 }
 
+CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf160003_copy_page_anchored)
+{
+// Load a document, which has a chart anchored to page on sheet2. 
Copy to other document
+// had lost the chart object.
+createScDoc("ods/tdf160003_page_anchored_object.ods");
+
+// copy range with chart
+goToCell("$Sheet2.$A$1:$L$24");
+dispatchCommand(mxComponent, ".uno:Copy", {});
+
+// close document and create new one
+createScDoc();
+
+// paste clipboard
+goToCell("$Sheet1.$A$1");
+dispatchCommand(mxComponent, ".uno:Paste", {});
+
+// Make sure the chart object exists.
+ScDocument* pDoc = getScDoc();
+ScDrawLayer* pDrawLayer = pDoc->GetDrawLayer();
+const SdrPage* pPage = pDrawLayer->GetPage(0);
+CPPUNIT_ASSERT_EQUAL(size_t(1), pPage->GetObjCount());
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/data/drwlayer.cxx b/sc/source/core/data/drwlayer.cxx
index 8e989012b4e8..23837e357203 100644
--- a/sc/source/core/data/drwlayer.cxx
+++ b/sc/source/core/data/drwlayer.cxx
@@ -1993,7 +1993,7 @@ void ScDrawLayer::CopyFromClip(ScDrawLayer* pClipModel, 
SCTAB nSourceTab,
 }
 else // Object is anchored to page.
 {
-aSrcObjStart = pClipDoc->GetRange(nClipTab, 
pOldObject->GetCurrentBoundRect()).aStart;
+aSrcObjStart = pClipDoc->GetRange(nSourceTab, 
pOldObject->GetCurrentBoundRect()).aStart;
 }
 if (!rSourceRange.Contains(aSrcObjStart))
 {

core.git: Branch 'libreoffice-24-2' - sc/qa sc/source

[Regina Henschel (via logerrit)]

 sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods |binary
 sc/qa/unit/scshapetest.cxx |   24 +
 sc/source/core/data/drwlayer.cxx   |2 -
 3 files changed, 25 insertions(+), 1 deletion(-)

New commits:
commit 5ad993b4167fb93f565dc1bce6eb1057e60f62f3
Author: Regina Henschel 
AuthorDate: Sun Mar 3 17:19:49 2024 +0100
Commit: Xisco Fauli 
CommitDate: Mon Mar 4 22:02:55 2024 +0100

tdf#160003 use correct sheet in clipboard for test

..whether a page anchored object is contained in the to be copied area.

Change-Id: I816e342770332e6d751b57a38e5ebabe33feb16a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164307
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit 199523b553957936dc31b8c3556ef2e47c6bc3a1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164373
Reviewed-by: Xisco Fauli 

diff --git a/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods 
b/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods
new file mode 100644
index ..565eb1bf6a26
Binary files /dev/null and 
b/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods differ
diff --git a/sc/qa/unit/scshapetest.cxx b/sc/qa/unit/scshapetest.cxx
index b5083544f114..5e4827005388 100644
--- a/sc/qa/unit/scshapetest.cxx
+++ b/sc/qa/unit/scshapetest.cxx
@@ -1207,6 +1207,30 @@ CPPUNIT_TEST_FIXTURE(ScShapeTest, 
testTdf154821_shape_in_group)
 CPPUNIT_ASSERT_RECTANGLE_EQUAL_WITH_TOLERANCE(aRectOrig, aRectReload, 1);
 }
 
+CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf160003_copy_page_anchored)
+{
+// Load a document, which has a chart anchored to page on sheet2. 
Copy to other document
+// had lost the chart object.
+createScDoc("ods/tdf160003_page_anchored_object.ods");
+
+// copy range with chart
+goToCell("$Sheet2.$A$1:$L$24");
+dispatchCommand(mxComponent, ".uno:Copy", {});
+
+// close document and create new one
+createScDoc();
+
+// paste clipboard
+goToCell("$Sheet1.$A$1");
+dispatchCommand(mxComponent, ".uno:Paste", {});
+
+// Make sure the chart object exists.
+ScDocument* pDoc = getScDoc();
+ScDrawLayer* pDrawLayer = pDoc->GetDrawLayer();
+const SdrPage* pPage = pDrawLayer->GetPage(0);
+CPPUNIT_ASSERT_EQUAL(size_t(1), pPage->GetObjCount());
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/data/drwlayer.cxx b/sc/source/core/data/drwlayer.cxx
index 3f98fc770a6b..25dfc5c7d6cc 100644
--- a/sc/source/core/data/drwlayer.cxx
+++ b/sc/source/core/data/drwlayer.cxx
@@ -1990,7 +1990,7 @@ void ScDrawLayer::CopyFromClip(ScDrawLayer* pClipModel, 
SCTAB nSourceTab,
 }
 else // Object is anchored to page.
 {
-aSrcObjStart = pClipDoc->GetRange(nClipTab, 
pOldObject->GetCurrentBoundRect()).aStart;
+aSrcObjStart = pClipDoc->GetRange(nSourceTab, 
pOldObject->GetCurrentBoundRect()).aStart;
 }
 if (!rSourceRange.Contains(aSrcObjStart))
 {

core.git: sc/qa sc/source

[Regina Henschel (via logerrit)]

 sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods |binary
 sc/qa/unit/scshapetest.cxx |   24 +
 sc/source/core/data/drwlayer.cxx   |2 -
 3 files changed, 25 insertions(+), 1 deletion(-)

New commits:
commit 199523b553957936dc31b8c3556ef2e47c6bc3a1
Author: Regina Henschel 
AuthorDate: Sun Mar 3 17:19:49 2024 +0100
Commit: Regina Henschel 
CommitDate: Mon Mar 4 14:30:21 2024 +0100

tdf#160003 use correct sheet in clipboard for test

..whether a page anchored object is contained in the to be copied area.

Change-Id: I816e342770332e6d751b57a38e5ebabe33feb16a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164307
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods 
b/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods
new file mode 100644
index ..565eb1bf6a26
Binary files /dev/null and 
b/sc/qa/unit/data/ods/tdf160003_page_anchored_object.ods differ
diff --git a/sc/qa/unit/scshapetest.cxx b/sc/qa/unit/scshapetest.cxx
index b5083544f114..5e4827005388 100644
--- a/sc/qa/unit/scshapetest.cxx
+++ b/sc/qa/unit/scshapetest.cxx
@@ -1207,6 +1207,30 @@ CPPUNIT_TEST_FIXTURE(ScShapeTest, 
testTdf154821_shape_in_group)
 CPPUNIT_ASSERT_RECTANGLE_EQUAL_WITH_TOLERANCE(aRectOrig, aRectReload, 1);
 }
 
+CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf160003_copy_page_anchored)
+{
+// Load a document, which has a chart anchored to page on sheet2. 
Copy to other document
+// had lost the chart object.
+createScDoc("ods/tdf160003_page_anchored_object.ods");
+
+// copy range with chart
+goToCell("$Sheet2.$A$1:$L$24");
+dispatchCommand(mxComponent, ".uno:Copy", {});
+
+// close document and create new one
+createScDoc();
+
+// paste clipboard
+goToCell("$Sheet1.$A$1");
+dispatchCommand(mxComponent, ".uno:Paste", {});
+
+// Make sure the chart object exists.
+ScDocument* pDoc = getScDoc();
+ScDrawLayer* pDrawLayer = pDoc->GetDrawLayer();
+const SdrPage* pPage = pDrawLayer->GetPage(0);
+CPPUNIT_ASSERT_EQUAL(size_t(1), pPage->GetObjCount());
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/data/drwlayer.cxx b/sc/source/core/data/drwlayer.cxx
index ed4f4ff4076c..4fac946caf1d 100644
--- a/sc/source/core/data/drwlayer.cxx
+++ b/sc/source/core/data/drwlayer.cxx
@@ -1996,7 +1996,7 @@ void ScDrawLayer::CopyFromClip(ScDrawLayer* pClipModel, 
SCTAB nSourceTab,
 }
 else // Object is anchored to page.
 {
-aSrcObjStart = pClipDoc->GetRange(nClipTab, 
pOldObject->GetCurrentBoundRect()).aStart;
+aSrcObjStart = pClipDoc->GetRange(nSourceTab, 
pOldObject->GetCurrentBoundRect()).aStart;
 }
 if (!rSourceRange.Contains(aSrcObjStart))
 continue;

core.git: 2 commits - config_host/config_options.h.in include/comphelper include/svtools include/toolkit include/vcl oox/inc oox/source

[Regina Henschel (via logerrit)]

 config_host/config_options.h.in   |   12 
 include/comphelper/accessibletexthelper.hxx   |3 ++-
 include/comphelper/accessiblewrapper.hxx  |6 +++---
 include/comphelper/proxyaggregation.hxx   |3 ++-
 include/svtools/DocumentToGraphicRenderer.hxx |3 ++-
 include/toolkit/awt/vclxfont.hxx  |3 ++-
 include/toolkit/awt/vclxwindows.hxx   |   19 ++-
 include/vcl/opengl/OpenGLHelper.hxx   |3 ++-
 include/vcl/tabctrl.hxx   |2 +-
 include/vcl/toolkit/ivctrl.hxx|3 ++-
 include/vcl/toolkit/scrbar.hxx|3 ++-
 include/vcl/toolkit/svtabbx.hxx   |5 +++--
 include/vcl/toolkit/treelist.hxx  |5 +++--
 include/vcl/toolkit/treelistbox.hxx   |3 ++-
 include/vcl/toolkit/treelistentry.hxx |3 ++-
 include/vcl/toolkit/vclmedit.hxx  |3 ++-
 include/vcl/txtattr.hxx   |3 ++-
 oox/inc/drawingml/graphicproperties.hxx   |1 +
 oox/inc/drawingml/scene3dhelper.hxx   |5 -
 oox/source/drawingml/fillproperties.cxx   |5 +++--
 oox/source/drawingml/scene3dhelper.cxx|5 +++--
 oox/source/drawingml/shape.cxx|   25 +
 22 files changed, 74 insertions(+), 49 deletions(-)

New commits:
commit d8079e980e3e5947df9430089444a5f31e0c5de6
Author: Regina Henschel 
AuthorDate: Wed Feb 28 18:37:00 2024 +0100
Commit: Regina Henschel 
CommitDate: Sat Mar 2 10:01:52 2024 +0100

tdf#159912 extruded shapes already rotate background

... so do not rotate the background image again. But because of
tdf#159515 the patch blocks extrusion for images that are imported as
background fill of a custom shape. To test that the fix works, you need
to change the code in shape.cxx. Remove the parameter bBlockExtrusion in
call of setExtrusionProperties() method and comment out the definition
of bBlockExtrusion variable.

Because of the blocked extrusion a unit test for tdf#159912 is currently
not possible.

Find more details about the patch in comment 4 in the bug report.

Change-Id: Ifa13988b18fbd5d63604ab0d0f3006e7ff480c02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164107
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/inc/drawingml/graphicproperties.hxx 
b/oox/inc/drawingml/graphicproperties.hxx
index 48d1acf61931..15ccedb99a2e 100644
--- a/oox/inc/drawingml/graphicproperties.hxx
+++ b/oox/inc/drawingml/graphicproperties.hxx
@@ -38,6 +38,7 @@ struct GraphicProperties
 BlipFillProperties  maBlipProps;///< Properties for the 
graphic.
 OUStringm_sMediaPackageURL; ///< Audio/Video URL.
 boolmbIsCustomShape = false;
+boolmbIsExtruded = false;
 css::uno::Reference m_xMediaStream; ///< 
Audio/Video input stream.
 
 /** Writes the properties to the passed property map. */
diff --git a/oox/inc/drawingml/scene3dhelper.hxx 
b/oox/inc/drawingml/scene3dhelper.hxx
index 95ee6889907d..8dd62186d895 100644
--- a/oox/inc/drawingml/scene3dhelper.hxx
+++ b/oox/inc/drawingml/scene3dhelper.hxx
@@ -32,12 +32,15 @@ public:
 be created. The extrusion color is not handled as extrusion 
property but as secondary
 color in the style of the shape. If no 3D exist or the camera is 
invalid, the parameter
 value is unchanged.
+@param [in] This optional parameter bBlockExtrusion can be removed 
when tdf#159912 is
+fixed. For details see the bugreport.
 @return Returns true if extrusion properties are generated. Returns 
false if there is no 3D
 or if rendering without 3D is currently better. rPropertyMap is 
unchanged in such case.
 */
 bool setExtrusionProperties(const oox::drawingml::Shape3DPropertiesPtr 
p3DProperties,
 const sal_Int32& rnMSOShapeRotation, 
oox::PropertyMap& rPropertyMap,
-double& rRotZ, oox::drawingml::Color& 
rExtrusionColor);
+double& rRotZ, oox::drawingml::Color& 
rExtrusionColor,
+const bool bBlockExtrusion = false);
 
 private:
 /** Calculates angles suitable for API from OOXML scene3d angles.
diff --git a/oox/source/drawingml/fillproperties.cxx 
b/oox/source/drawingml/fillproperties.cxx
index 596e18f2176e..73563c5c333a 100644
--- a/oox/source/drawingml/fillproperties.cxx
+++ b/oox/source/drawingml/fillproperties.cxx
@@ -855,7 +855,8 @@ void GraphicProperties::pushToPropMap( PropertyMap& 
rPropMap, const GraphicHelpe
 
 // It is a bitmap filled and rotated graphic.
 // When custom shape is rotated, bitmap have to be rotated too.
-if(rPropMap.hasProperty(PR

Re: Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi Armin,

Armin Le Grand schrieb am 28.02.2024 um 20:20:

Hi,

On 2/24/24 22:00, Regina Henschel wrote:

Hi Thorsten,

Thorsten Behrens schrieb am 24.02.2024 um 17:29:

Hi Regina,

Regina Henschel wrote:

Unfortunately, our 3d engine does not support all needed features. Most
important problem is, that in our 3d engine only the first light is
specular.


I suspect that might be quick to add - Armin, what do you think?


There is a member mbSpecular in class ImpSdr3DLightAttribute but 
ViewContactOfE3d::impCreateWithGivenPrimitive3DContainer() evaluates 
only the first light. But I don't know whether that is the correct 
area at all.
I also would have to search, but can say that all 8 lights are the same. 
I also remember that it is done for Chart since Ingrid did not want the 
1st light to be specular (our default), so 1st light is specular 
switched off, 2nd is on AFAIR.


As far as I see she simply used 2nd light instead of 1st light.

 No idea where that would have to be done
in import and if there is tooling for it, but it just needs to be set 
correctly.


Mmh, I see D3DFoo properties for the shape how a material reacts on the 
light, but a light itself has only on/off, color and direction in the 
D3DFoo properties.







Further problem with our 3d engine is, that we cannot render the
"Bevel" of MS Office. Not only the fancy ones, but the simple round
bevel is missing too. Our "Rounded edges" are in fact straight. In
MS Office you can use the bevel to create a sphere, for example.


Got it. Might also need some experimentation, such that we get the exact
same look. Let me play with this features a little bit.


I have attached a file with examples using "Bevel". Note that these 
are no "true" 3D-objects, but they are all custom shapes. We are far 
away from what MS Office can do with custom shapes.


Will have to compare with MSOffice, but sure we are far away - Sven did 
implement by creating SdrShapes (WITHOUT being inserrted to 
SdrPage/SdrModel, that caused many problems). Primitives were available, 
but hey. It would be much better to create the visualization for 
CustomShapes with Primitives directly (these get 'collected' from the 
created SdrObjects currently). That would allow e.g. to just have a 
primitive for the CustomShape that then gets decomposed to the needed 
Primitives (also would think about not doing all of that all the time 
and over the UNO API btw).


That would also be the way to do for 3D stuff - 3D primitives could just 
create all that needed stuff, tesselating down to triangles (as is done 
now for 'fat' 3D lines as already mentioned).


As long as CustomShape geometry processing uses SdrObjects I see no good 
way to do more/the needed stuff, hence this is filed as Tender (since a 
looong time). Unfortunately this is not simple for all cases - we also 
have the FontWork to be adapted and quite some complicated stuff for 
some CustomShapes, esp. the 3D stuff (creating 3D scenes with 3d 
SdrObjects), but definitely worth it.


We should reserve some hours on the next LibreOffice conference and 
discuss especially 3D things. The problem is not only the extrusion of 
custom shapes, but also 3D scene for text and the new feature of MS 
Office to render 3D-Models (.glb files) including changes to camera and 
lighting properties.




Urgently needed change. I see NO way to do what you need here - with the 
curent way of doing it you would have to create new SdrObjects (3D 
Sdrobjects) that could do that - argh - or use that already mentioned 
simple 3D SdrObjects that can represent 3D PolyPolygons, using just 
trianges and doing the tesselation there. But why when that could be 
done much smoother and simpler with 3D primitives.


Currently, the 3D-scene and the objects in it for an extruded custom 
shape are created in EnhancedCustomShape3d::Create3DObject().




Did i mention that that would also make things much easier? AFAIR for 
some of those geometry creations SdrObjects get created and in 
follow--up steps get used as geometry input and other SdrObjects get 
created based on that - oh my...




So it is obvious, going that way is not feasible until the feature 
freeze of version 24.8. I will therefore try to emulate the lighting 
rendering as well as possible with the existing old properties.


Unfortunately, there are not only problems with the lighting. In 
addition to the bevel property already mentioned, the contour property 
is also missing. The material, handling of extrusion color, stroke and 
text are also different. And I haven't even looked at 3D-fontwork yet.







The question is more whether to start that immediately or first
implement some ersatz lighting so that the shapes are approximately
as light as in MS Office. When you use the current import (in daily
build which has the 3d geometry) you can see, that our default
lighting gives bad results.


I guess the specular light & API changes for it are relati

Help on toolbars

[Regina Henschel]

Hi Olivier,

I have tested what happens, when you go to an icon in the toolbar via F6 
and then tabs. When you are on an icon and then press F1, the help 
system gets e.g. .HelpId:textobjectbar or .HelpId:standardbar. But there 
exists no corresponding page and a 404 is shown.


Kind regards,
Regina

Re: Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi Armin,

Armin Le Grand schrieb am 28.02.2024 um 11:16:

Further problem with our 3d engine is, that we cannot render the 
"Bevel" of MS Office. Not only the fancy ones, but the simple round 
bevel is missing too. Our "Rounded edges" are in fact straight. In MS 
Office you can use the bevel to create a sphere, for example.

I would need an example for this,


The previous mail from me to this topic has an attachment with bevel 
examples. You should have got that mail directly.


Kind regards
Regina

Re: Build problem with climaker

[Regina Henschel]

Hello Kevin, hello Mike,

going back to VS 17.9.0 solves the problem.
Thank you for your help.

Kind regards,
Regina

Mike Kaganski schrieb am 25.02.2024 um 03:21:

Hi Regina,

On 2/25/2024 7:37 AM, Kevin Suo wrote:
I think that is exactly the regression in VS 17.9.1 which Mike 
Kaganski has warned earlier in his email to this list, titled "VS 2022 
version 17.9.1 has a bug preventing building cli_ure", Sat, 24 Feb 
2024 16:50:24 UTC.


FTR, this is 
https://lists.freedesktop.org/archives/libreoffice/2024-February/091609.html. 



For now, you may use VS Installer's Rollback feature [1] to get back to 
normally working 17.9.0. Click "More" button in the installer, to see 
the option.


[1] 
https://devblogs.microsoft.com/visualstudio/introducing-visual-studio-rollback/ 

Build problem with climaker

[Regina Henschel]

Hi all,

with a clean build from current master I get the failure

LINK : error LNK2034: metadata inconsistent with COFF symbol table: 
symbol '?rtl_ustr_asciil_reverseEquals_WithLength@@$$J0YAEPEB_SPEBDJ@Z' 
(06000579) has inconsistent metadata with (0A000A1A) in climaker_emit.o
climaker_emit.o : error LNK2020: unresolved token (0A000A1A) "extern "C" 
unsigned char __cdecl rtl_ustr_asciil_reverseEquals_WithLength(char16_t 
const *,char const *,long)" 
(?rtl_ustr_asciil_reverseEquals_WithLength@@$$J0YAEPEB_SPEBDJ@Z)
C:\buildLO\core\instdir\sdk\bin\climaker.exe : fatal error LNK1120: 1 
unresolved externals


My autogen parameters are
c:/BuildLO/core/autogen.sh \
--with-external-tar=c:/BuildLO/externalsrc \
--with-junit=c:/cygwin64/junit/junit-4.10.jar \
--with-ant-home=c:/cygwin64/ant/apache-ant-1.9.5 \
--disable-ccache \
--with-visual-studio=2022 \
--enable-dbgutil \
--enable-werror \
--enable-odk \
--disable-cve-tests \
--disable-online-update \
--disable-skia \
--without-fonts \
--with-jdk-home=c:/Program\ Files/Microsoft/jdk-21.0.1.12-hotspot

Microsoft Visual Studio Community 2022 (64-bit) - Current
Version 17.9.1

Kind regards,
Regina

Re: Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi Thorsten,

Thorsten Behrens schrieb am 24.02.2024 um 17:29:

Hi Regina,

Regina Henschel wrote:

Unfortunately, our 3d engine does not support all needed features. Most
important problem is, that in our 3d engine only the first light is
specular.


I suspect that might be quick to add - Armin, what do you think?


There is a member mbSpecular in class ImpSdr3DLightAttribute but 
ViewContactOfE3d::impCreateWithGivenPrimitive3DContainer() evaluates 
only the first light. But I don't know whether that is the correct area 
at all.





Further problem with our 3d engine is, that we cannot render the
"Bevel" of MS Office. Not only the fancy ones, but the simple round
bevel is missing too. Our "Rounded edges" are in fact straight. In
MS Office you can use the bevel to create a sphere, for example.


Got it. Might also need some experimentation, such that we get the exact
same look. Let me play with this features a little bit.


I have attached a file with examples using "Bevel". Note that these are 
no "true" 3D-objects, but they are all custom shapes. We are far away 
from what MS Office can do with custom shapes.





The question is more whether to start that immediately or first
implement some ersatz lighting so that the shapes are approximately
as light as in MS Office. When you use the current import (in daily
build which has the 3d geometry) you can see, that our default
lighting gives bad results.


I guess the specular light & API changes for it are relatively
straight-forward.


Perhaps. A solution might be to give the 'dr3d:foo' attributes 
precedence over the 'extrusion-foo' attributes and use 'loext:foo' until 
they available in ODF.


The 'extrusion-foo' attributes are available in API as properties in 
service EnhancedCustomShapeExtrusion.


The use of the 'D3DFoo' properties is strange. They are not mentioned in 
an idl file. And trying to get the properties of an object in a scene in 
the Development Tools crashes LibreOffice.


 Then again, getting the code merged as-is would

perhaps be quite satisfying, and I take it you would need some sort of
quick emulation for that, since it looks just too bad?


Yes, till August we need some sort of better lighting.

Kind regards,
Regina



Bevel examples.pptx
Description: MS-Powerpoint 2007 presentation

Re: Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi Thorsten,

Thorsten Behrens schrieb am 22.02.2024 um 21:04:

Hi Regina,

Regina Henschel wrote:

Any ideas/wishes for a reasonably usable import?


Our 3d engine already supports all this FWICT (I see e.g.
SDRATTR_3DSCENE_LIGHTCOLOR_1 - 8) - so why not extend ODF here, when
it's obviously lacking?


Unfortunately, our 3d engine does not support all needed features. Most 
important problem is, that in our 3d engine only the first light is 
specular. We need three specular lights for MS Office light rigs. 
"Specular" means, that the light produces a bright spot on the shape.


Further problem with our 3d engine is, that we cannot render the "Bevel" 
of MS Office. Not only the fancy ones, but the simple round bevel is 
missing too. Our "Rounded edges" are in fact straight. In MS Office you 
can use the bevel to create a sphere, for example.


Nevertheless, extending ODF is likely needed anyway. That would include 
extending our API because the import goes via API properties. The 
question is more whether to start that immediately or first implement 
some ersatz lighting so that the shapes are approximately as light as in 
MS Office. When you use the current import (in daily build which has the 
3d geometry) you can see, that our default lighting gives bad results.


Kind regards,
Regina

core.git: Branch 'libreoffice-24-2-1' - svx/source

[Regina Henschel (via logerrit)]

 svx/source/sdr/contact/viewcontactofsdrpage.cxx |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

New commits:
commit f09fbbd8ae57d59c6ca264b042927330249ce163
Author: Regina Henschel 
AuthorDate: Fri Feb 9 15:02:41 2024 +0100
Commit: Xisco Fauli 
CommitDate: Thu Feb 22 21:22:21 2024 +0100

tdf#156993 use correct count for ViewContactOfSdrPage

The count is used as upper limit in a for-loop in
ViewObjectContact::getPrimitive2DSequenceSubHierarchy().
That calls ViewContactOfSdrPage::GetViewContact().
With the wrong count the case 10 was not reached and thus the helplines
were not drawn.

Change-Id: If606bbb718b1f78a874862217d1e03b02287e848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163192
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit 56517d8a38459f5a9e67327c1ac0dc8bcd07bcb8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163180
Reviewed-by: Xisco Fauli 
(cherry picked from commit 0f6e36496a1b398c5df1c8eb0570d5945d024e78)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163183
Reviewed-by: Michael Stahl 
Tested-by: Hossein 
Reviewed-by: Hossein 
Reviewed-by: Ilmari Lauhakangas 
Tested-by: Xisco Fauli 

diff --git a/svx/source/sdr/contact/viewcontactofsdrpage.cxx 
b/svx/source/sdr/contact/viewcontactofsdrpage.cxx
index 43ca1fd5c06f..dfef01d30410 100644
--- a/svx/source/sdr/contact/viewcontactofsdrpage.cxx
+++ b/svx/source/sdr/contact/viewcontactofsdrpage.cxx
@@ -515,10 +515,10 @@ sal_uInt32 ViewContactOfSdrPage::GetObjectCount() const
 {
 // Fixed count of content. It contains PageBackground (Wiese), PageShadow, 
PageFill,
 // then - depending on if the page has a MasterPage - either MasterPage 
Hierarchy
-// or MPBGO. Also OuterPageBorder, InnerPageBorder and two pairs of Grid 
and Helplines
-// (for front and back) which internally are visible or not depending on 
the current
+// or MPBGO. Also OuterPageBorder, InnerPageBorder, PageHierarchy and two 
pairs of Grid and
+// Helplines (for front and back) which internally are visible or not 
depending on the current
 // front/back setting for those.
-return 10;
+return 11;
 }
 
 ViewContact& ViewContactOfSdrPage::GetViewContact(sal_uInt32 nIndex) const

Import of lighting from MS Office for extruded shapes

[Regina Henschel]

Hi all,

I have started work on import of lighting. But there are several 
problems which make it impossible to get a 1:1 match to our capabilities.


Some of these problems are:

(1)
A lightRig in MS Office uses up to 4 lights. But ODF and our API have 
only two lights.


(2)
The MS Office lightRigs 'chilly', 'flat', 'freezing', 'morning', 
'sunrise' and 'sunset' use colored light. ODF and our API have no color 
for a light but only an intensity (='level'), which means our lights are 
Gray.


(3)
There are lightRigs in MS Office with more than one specular light. Our 
3D rendering engine has maximal one specular light. A 'specular' light 
makes a bright spot on the shape in case the shape material is 'shiny'.


(4)
Our dialog '3D-settings' fits to shape extrusion of binary MS Office and 
the 'legacy*' lightRigs. But these 'legacy*' lightRigs are not available 
in the UI of modern MS Office. So we import lightRigs for which the user 
has no UI.


Any ideas/wishes for a reasonably usable import?

Kind regards,
Regina

core.git: oox/CppunitTest_oox_testscene3d.mk oox/inc oox/Library_oox.mk oox/Module_oox.mk oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/CppunitTest_oox_testscene3d.mk   |   53 +
 oox/Library_oox.mk   |1 
 oox/Module_oox.mk|1 
 oox/inc/drawingml/customshapeproperties.hxx  |2 
 oox/inc/drawingml/scene3dhelper.hxx  |   96 +++
 oox/qa/unit/data/Scene3d_isometricRightUp.pptx   |binary
 oox/qa/unit/data/Scene3d_legacyObliqueBottomRight.pptx   |binary
 oox/qa/unit/data/Scene3d_legacyPerspectiveTopRight.pptx  |binary
 oox/qa/unit/data/Scene3d_obliqueTopRight.pptx|binary
 oox/qa/unit/data/Scene3d_orthographicFront.pptx  |binary
 oox/qa/unit/data/Scene3d_perspectiveContrastingLeft.pptx |binary
 oox/qa/unit/testscene3d.cxx  |  320 ++
 oox/source/drawingml/customshapeproperties.cxx   |   10 
 oox/source/drawingml/scene3dhelper.cxx   |  442 +++
 oox/source/drawingml/shape.cxx   |   74 ++
 oox/source/token/properties.txt  |   23 
 16 files changed, 1008 insertions(+), 14 deletions(-)

New commits:
commit 6e5529d7382558a38e547074e2f674e85e11e66e
Author: Regina Henschel 
AuthorDate: Tue Jan 23 20:18:48 2024 +0100
Commit: Miklos Vajna 
CommitDate: Mon Feb 19 13:57:14 2024 +0100

tdf#70039 convert 3D effects to extrusion

ODF allows a 3D mode for custom shapes. That can be used to render
some of the 3D effects possible in MS Office.

MS Office has not published, how they calculate the 3D-scenes. Thus
most principles and values are found by experiments. My assumptions
are contained as comments.

This current solution does not work well for perspectiveFront camera
with rotation on only y-axis or on only x-axis. If someone has an idea,
what is wrong in my solution or what MS Office might specially do,
please tell me.

The tests do not cover whether the rendering in LO is the same as in
MS Office. I have no idea how to write such tests. To test manually:
In Powerpoint: Copy the shape and set the copy to wireframe. Cut the
copy and insert it as svg image. Move the image so that the lines cover
the original shape. Save it. In LibreOffice: Open the file and set the
shape to wireframe. Now you can easily compare the rendering of
PowerPoint and LibreOffice.

Extrusion can be used for images, that have a 3D-scene applied like in
tdf#45495. That would work with this patch, but the related places are
commented out because of tdf#159515.

This patch does not cover lighting and material and it does not
contain export.

3D-text is not contained in the patch. There are principle problems
with 3D-text. Thus a solution requieres a lot, including additions to
the ODF standard.

The comments in tdf#70039 contain more about aspects, where MS Office
and ODF are in principle incompatible in regard to 3D-effects.

Change-Id: I8a5da536ade2a4b67630af221ea47e0288450188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162594
Reviewed-by: Sarper Akdemir 
Tested-by: Jenkins
Reviewed-by: Miklos Vajna 

diff --git a/oox/CppunitTest_oox_testscene3d.mk 
b/oox/CppunitTest_oox_testscene3d.mk
new file mode 100644
index ..23b08eee6fed
--- /dev/null
+++ b/oox/CppunitTest_oox_testscene3d.mk
@@ -0,0 +1,53 @@
+# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
+#*
+#
+# 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/.
+#
+#*
+
+$(eval $(call gb_CppunitTest_CppunitTest,oox_testscene3d))
+
+$(eval $(call gb_CppunitTest_use_externals,oox_testscene3d,\
+   boost_headers \
+   libxml2 \
+))
+
+$(eval $(call gb_CppunitTest_add_exception_objects,oox_testscene3d, \
+oox/qa/unit/testscene3d \
+))
+
+$(eval $(call gb_CppunitTest_use_libraries,oox_testscene3d, \
+comphelper \
+cppu \
+cppuhelper \
+oox \
+sal \
+subsequenttest \
+test \
+unotest \
+utl \
+tl \
+))
+
+$(eval $(call gb_CppunitTest_use_sdk_api,oox_testscene3d))
+
+$(eval $(call gb_CppunitTest_use_ure,oox_testscene3d))
+$(eval $(call gb_CppunitTest_use_vcl,oox_testscene3d))
+
+$(eval $(call gb_CppunitTest_use_rdb,oox_testscene3d,services))
+
+$(eval $(call gb_CppunitTest_use_custom_headers,oox_testscene3d,\
+   officecfg/registry \
+))
+
+$(eval $(call gb_CppunitTest_use_configuration,oox_testscene3d))
+
+$(eval $(call gb_CppunitTest_add_arguments,oox_testscene3d, \
+
-env:arg-env=$(gb_Helper_LIBRARY_PATH_VAR)"{$(gb_Helper_LIBRARY_PAT

core.git: Branch 'libreoffice-24-2' - svx/source

[Regina Henschel (via logerrit)]

 svx/source/sdr/contact/viewcontactofsdrpage.cxx |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

New commits:
commit f05bc0cf6c9fdba682a0aee4e3a06b093ae345da
Author: Regina Henschel 
AuthorDate: Fri Feb 9 15:02:41 2024 +0100
Commit: Xisco Fauli 
CommitDate: Mon Feb 12 11:48:37 2024 +0100

tdf#156993 use correct count for ViewContactOfSdrPage

The count is used as upper limit in a for-loop in
ViewObjectContact::getPrimitive2DSequenceSubHierarchy().
That calls ViewContactOfSdrPage::GetViewContact().
With the wrong count the case 10 was not reached and thus the helplines
were not drawn.

Change-Id: If606bbb718b1f78a874862217d1e03b02287e848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163192
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit 56517d8a38459f5a9e67327c1ac0dc8bcd07bcb8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163180
Reviewed-by: Xisco Fauli 

diff --git a/svx/source/sdr/contact/viewcontactofsdrpage.cxx 
b/svx/source/sdr/contact/viewcontactofsdrpage.cxx
index 43ca1fd5c06f..dfef01d30410 100644
--- a/svx/source/sdr/contact/viewcontactofsdrpage.cxx
+++ b/svx/source/sdr/contact/viewcontactofsdrpage.cxx
@@ -515,10 +515,10 @@ sal_uInt32 ViewContactOfSdrPage::GetObjectCount() const
 {
 // Fixed count of content. It contains PageBackground (Wiese), PageShadow, 
PageFill,
 // then - depending on if the page has a MasterPage - either MasterPage 
Hierarchy
-// or MPBGO. Also OuterPageBorder, InnerPageBorder and two pairs of Grid 
and Helplines
-// (for front and back) which internally are visible or not depending on 
the current
+// or MPBGO. Also OuterPageBorder, InnerPageBorder, PageHierarchy and two 
pairs of Grid and
+// Helplines (for front and back) which internally are visible or not 
depending on the current
 // front/back setting for those.
-return 10;
+return 11;
 }
 
 ViewContact& ViewContactOfSdrPage::GetViewContact(sal_uInt32 nIndex) const

core.git: svx/source

[Regina Henschel (via logerrit)]

 svx/source/sdr/contact/viewcontactofsdrpage.cxx |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

New commits:
commit 56517d8a38459f5a9e67327c1ac0dc8bcd07bcb8
Author: Regina Henschel 
AuthorDate: Fri Feb 9 15:02:41 2024 +0100
Commit: Regina Henschel 
CommitDate: Sat Feb 10 15:32:30 2024 +0100

tdf#156993 use correct count for ViewContactOfSdrPage

The count is used as upper limit in a for-loop in
ViewObjectContact::getPrimitive2DSequenceSubHierarchy().
That calls ViewContactOfSdrPage::GetViewContact().
With the wrong count the case 10 was not reached and thus the helplines
were not drawn.

Change-Id: If606bbb718b1f78a874862217d1e03b02287e848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163192
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/svx/source/sdr/contact/viewcontactofsdrpage.cxx 
b/svx/source/sdr/contact/viewcontactofsdrpage.cxx
index 05b045ec473a..c07bcffe762d 100644
--- a/svx/source/sdr/contact/viewcontactofsdrpage.cxx
+++ b/svx/source/sdr/contact/viewcontactofsdrpage.cxx
@@ -515,10 +515,10 @@ sal_uInt32 ViewContactOfSdrPage::GetObjectCount() const
 {
 // Fixed count of content. It contains PageBackground (Wiese), PageShadow, 
PageFill,
 // then - depending on if the page has a MasterPage - either MasterPage 
Hierarchy
-// or MPBGO. Also OuterPageBorder, InnerPageBorder and two pairs of Grid 
and Helplines
-// (for front and back) which internally are visible or not depending on 
the current
+// or MPBGO. Also OuterPageBorder, InnerPageBorder, PageHierarchy and two 
pairs of Grid and
+// Helplines (for front and back) which internally are visible or not 
depending on the current
 // front/back setting for those.
-return 10;
+return 11;
 }
 
 ViewContact& ViewContactOfSdrPage::GetViewContact(sal_uInt32 nIndex) const

Import MS Office 3D effects

[Regina Henschel]

Hello,

you might have noticed, that I have started to implement the import of 
3D effects from MS Office. The commit in 
https://gerrit.libreoffice.org/c/core/+/162594 is in a state now, that 
you can make tests. Still missing is material, lighting and use of 
predefined camera. So when testing, change the rotation angles in MS 
Office, so that the values are written to file.


Some questions in regard to this:

Do you agree in general with my approach to import the 3D effects as 
extrusion of custom shapes?


The current solution uses a collection of methods. Is it possible to use 
a class instead? And if yes, should I do that?


I need a table with the properties of the camera types. This table has 
62 rows and about 12 columns with several data types. A row could be 
identified by the token of the camera type. The content will not change 
and is known at compile time. What is the best way to implement such table?


Kind regards,
Regina

Problem with RTFSprms::equals() method in RTF import

[Regina Henschel]

Hi Miklos, hi all,

I see a problem with the RTFSprms::equals() method. The problem is 
described in Bug 158950 - Paste as Rich Text Format loses character 
color and paragraph alignment from styles

https://bugs.documentfoundation.org/show_bug.cgi?id=158950#c8

Miklos, as far as I see you have implemented the RTF import. Could you 
please have a look at that problem and comment?


Kind regards,
Regina

core.git: Branch 'libreoffice-24-2' - editeng/source sw/qa

[Regina Henschel (via logerrit)]

 editeng/source/editeng/impedit4.cxx |2 
 sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt |  300 
++
 sw/qa/extras/uiwriter/uiwriter9.cxx |   35 +
 3 files changed, 336 insertions(+), 1 deletion(-)

New commits:
commit f5431af083eb1cde85505dddf19600a7b8f52020
Author: Regina Henschel 
AuthorDate: Tue Jan 9 21:41:40 2024 +0100
Commit: Xisco Fauli 
CommitDate: Fri Jan 12 10:34:23 2024 +0100

tdf#159049 use RTF_LINE for EE_FEATURE_LINEBR for copy

Copy of simple text uses ImpEditEngine::WriteItemAsRTF() method.
Error was, that in case of a line break ('
') the string
OOO_STRING_SVTOOLS_RTF_SL was written, but it needs to be the string
OOO_STRING_SVTOOLS_RTF_LINE.

Change-Id: I1c2ff2087c563b26e26d8768dfcfd1645be91d2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161842
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161954

diff --git a/editeng/source/editeng/impedit4.cxx 
b/editeng/source/editeng/impedit4.cxx
index 57b3d65c54b4..3bf44cdb9174 100644
--- a/editeng/source/editeng/impedit4.cxx
+++ b/editeng/source/editeng/impedit4.cxx
@@ -905,7 +905,7 @@ void ImpEditEngine::WriteItemAsRTF( const SfxPoolItem& 
rItem, SvStream& rOutput,
 break;
 case EE_FEATURE_LINEBR:
 {
-rOutput.WriteOString( OOO_STRING_SVTOOLS_RTF_SL );
+rOutput.WriteOString( OOO_STRING_SVTOOLS_RTF_LINE );
 }
 break;
 case EE_CHAR_KERNING:
diff --git a/sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt 
b/sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt
new file mode 100644
index ..22472c197053
--- /dev/null
+++ b/sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt
@@ -0,0 +1,300 @@
+
+
+http://openoffice.org/2004/office; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:ooow="http://openoffice.org/200
 4/writer" xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:css3t="http://www.w3.org/TR/css3-text/; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.text">
+ Regina 
Henschel2024-01-08T23:25:06.849002024-01-09T20:51:07.36300Regina
 
HenschelPT18M48S8LOmyBuild/24.8.0.0.alpha0$Windows_X86_64
 
LibreOffice_project/00eae23267bf64e07cf057f828cd85f3c38ac669
+ 
+  
+   0
+   0
+   21338
+   14543
+   true
+   false
+   
+
+ view2
+ 11003
+ 1000
+ 0
+ 0
+ 21336
+ 14542
+ 0
+ 1
+ false
+ 100
+ false
+ false
+ false
+ false
+ false
+ false
+
+   
+  
+  
+   true
+   
+   false
+   false
+   false
+   false
+   true
+   1
+   true
+   false
+   false
+   false
+   
+   false
+   
+   false
+   false
+   false
+   Person
+   0
+   false
+   true
+   true
+   false
+   false
+   false
+   IDAnredeVornameNachname
+   0
+   
+   true
+   high-resolution
+   false
+   false
+   true
+   true
+   true
+   false
+   false
+   true
+   true
+   false
+   true
+   true
+   false
+   false
+   false
+   true
+   false
+   true
+   false
+   false
+   true
+   false
+   false
+   false
+   false
+   false
+   false
+   757206
+   303919
+   false
+   false
+   true
+   true
+  

core.git: editeng/source sw/qa

[Regina Henschel (via logerrit)]

 editeng/source/editeng/impedit4.cxx |2 
 sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt |  300 
++
 sw/qa/extras/uiwriter/uiwriter9.cxx |   35 +
 3 files changed, 336 insertions(+), 1 deletion(-)

New commits:
commit c994f2491dd4e977f726f53de1953feff17c2227
Author: Regina Henschel 
AuthorDate: Tue Jan 9 21:41:40 2024 +0100
Commit: Regina Henschel 
CommitDate: Fri Jan 12 00:13:21 2024 +0100

tdf#159049 use RTF_LINE for EE_FEATURE_LINEBR for copy

Copy of simple text uses ImpEditEngine::WriteItemAsRTF() method.
Error was, that in case of a line break ('
') the string
OOO_STRING_SVTOOLS_RTF_SL was written, but it needs to be the string
OOO_STRING_SVTOOLS_RTF_LINE.

Change-Id: I1c2ff2087c563b26e26d8768dfcfd1645be91d2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161842
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/editeng/source/editeng/impedit4.cxx 
b/editeng/source/editeng/impedit4.cxx
index b5151467079a..d63522a555c1 100644
--- a/editeng/source/editeng/impedit4.cxx
+++ b/editeng/source/editeng/impedit4.cxx
@@ -905,7 +905,7 @@ void ImpEditEngine::WriteItemAsRTF( const SfxPoolItem& 
rItem, SvStream& rOutput,
 break;
 case EE_FEATURE_LINEBR:
 {
-rOutput.WriteOString( OOO_STRING_SVTOOLS_RTF_SL );
+rOutput.WriteOString( OOO_STRING_SVTOOLS_RTF_LINE );
 }
 break;
 case EE_CHAR_KERNING:
diff --git a/sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt 
b/sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt
new file mode 100644
index ..22472c197053
--- /dev/null
+++ b/sw/qa/extras/uiwriter/data/tdf159049_LineBreakRTFClipboard.fodt
@@ -0,0 +1,300 @@
+
+
+http://openoffice.org/2004/office; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:ooow="http://openoffice.org/200
 4/writer" xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:css3t="http://www.w3.org/TR/css3-text/; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.text">
+ Regina 
Henschel2024-01-08T23:25:06.849002024-01-09T20:51:07.36300Regina
 
HenschelPT18M48S8LOmyBuild/24.8.0.0.alpha0$Windows_X86_64
 
LibreOffice_project/00eae23267bf64e07cf057f828cd85f3c38ac669
+ 
+  
+   0
+   0
+   21338
+   14543
+   true
+   false
+   
+
+ view2
+ 11003
+ 1000
+ 0
+ 0
+ 21336
+ 14542
+ 0
+ 1
+ false
+ 100
+ false
+ false
+ false
+ false
+ false
+ false
+
+   
+  
+  
+   true
+   
+   false
+   false
+   false
+   false
+   true
+   1
+   true
+   false
+   false
+   false
+   
+   false
+   
+   false
+   false
+   false
+   Person
+   0
+   false
+   true
+   true
+   false
+   false
+   false
+   IDAnredeVornameNachname
+   0
+   
+   true
+   high-resolution
+   false
+   false
+   true
+   true
+   true
+   false
+   false
+   true
+   true
+   false
+   true
+   true
+   false
+   false
+   false
+   true
+   false
+   true
+   false
+   false
+   true
+   false
+   false
+   false
+   false
+   false
+   false
+   757206
+   303919
+   false
+   false
+   true
+   true
+   false
+   true
+   true
+   false
+   true
+   true
+   true
+   false
+   false
+   false

unit test testTdf158743 in PNGExportTests.cxx fails for me

[Regina Henschel]

Hi all,

the unit test testTdf158743 fails for me.
https://opengrok.libreoffice.org/xref/core/sd/qa/unit/PNGExportTests.cxx?r=25276df1#304

I get Actual 855 instead of the mentioned expected 842 (tested as less 
than 850). I have build with --disable-skia because building Skia fails 
for me.


Might it be, that the result in the unit test depends on whether Skia is 
used or not?


Kind regards,
Regina

How to copy text from shape to body text in a unit test

[Regina Henschel]

Hi all,

please have a look at the unit test in 
https://gerrit.libreoffice.org/c/core/+/161842. It works but it looks 
strange to me.

The task is this:
Copy the text content of a shape and paste it in rich text format to the 
body text. Make sure, that a line break (shift enter) in the original 
text is preserved in the pasted text.


It there a better way for this task in a unit test?

Kind regards,
Regina

Re: master build broken on macOS due to Firebird update

[Regina Henschel]

Hi all,

it breaks for me too. VS2022 on Win11 with --enable-dbgutil. So not only 
macOS.


Kind regards,
Regina

Patrick Luby schrieb am 06.01.2024 um 16:20:

All,

I am not sure how this update built successfully on macOS on Jenkins, 
but the Firebird update is filled with hundreds of sprintf calls like 
the following. Xcode has marked sprintf as deprecated since a couple of 
versions ago:


/Volumes/LOBuilds/lode/dev/core/workdir/UnpackedTarball/firebird/temp/Debug/isql/show.cpp:6986:5: 
warning: 'sprintf' is deprecated: This function is provided for 
compatibility reasons only.  Due to security concerns inherent in the 
design of sprintf(3), it is highly recommended that you use snprintf(3) 
instead. [-Wdeprecated-declarations]
     sprintf(info, "Number of DB pages free 
= %" SQUADFORMAT"%s", value_out, separator);


So how do we suppress these "en masse" when doing debug builds?

Thanks,

Patrick

Cannot build Skia

[Regina Henschel]

Hi all,

I cannot build Skia because somewhere a wrong path is created.

Example of the problem
   external/skia/source/SkMemory_malloc.cxx
has the line
   "include/core/SkTypes.h"
The compiler tries to open
'C:/BuildLO/core/include\include/core/SkTypes.h'
That obviously fails. Actually the file is in
C:\BuildLO\core\workdir\UnpackedTarball\skia\include\core\SkTypes.h

Any idea how to fix that? Do I need to change/add/remove something in 
Cygwin or in the configuration files or in Visual Studio?


My PC has Windows 11 and Visual Studio 2022.

Kind regards,
Regina

Re: Need help for bug 158451

[Regina Henschel]

Hi Michael,

Michael Stahl schrieb am 21.12.2023 um 20:19:

hi Regina,

[..]


the problem is that the type of anchor of the inner shape changes during 
text formatting, which is not supposed to happen.


hope https://gerrit.libreoffice.org/c/core/+/161137 should fix the crash.




Yes it solves the crash and the groups are rendered as expected. Excellent!

How do you find the root cause?

Kind regards,
Regina

Re: Need help for bug 158451

[Regina Henschel]

Hi all,

I can now narrow down the error somewhat.

Look at method SwTextFrame::FormatImpl() in
https://opengrok.libreoffice.org/xref/core/sw/source/core/text/frmform.cxx?r=7d7ca347#1832
It creates
   SwTextFormatInfo aInf( pRenderContext, this );
Later down in the for-loop, aInf is used. The for-loop iterates over
   pObj = aInf.GetTextFly().GetAnchoredObjList()
and performs
   aInf.GetTextFly().AnchoredObjToRect(pObj, aRect)
AnchoredObjToRect crashes then because of an invalid pObj.

You see the AnchoredObjList with these steps:
aInf > SwTextPaintInfo > m_aTextFly > mpAnchoredObjList

When aInf is created, mpAnchoredObjList is empty.
After line #1863
Format_( aLine, aInf );
you can see the invalid item in that list.

This happens not always. When you use the example file of the bug 
report, first the text of the shape inside the group is handled. That 
works. Then the line where the group is anchored is handled. And there 
it happens.
If the inline anchored object is not a group but a simple shape with 
text, first the line is handled and then the text of the shape.



Next I have examined Format_( aLine, aInf ) for the crash case. It is
void SwTextFrame::Format_( SwTextFormatter , SwTextFormatInfo 
 const bool bAdjust )

in
https://opengrok.libreoffice.org/xref/core/sw/source/core/text/frmform.cxx?r=7d7ca347#1431
Here watch parameter rInf.
It is OK till #1671. After line #1672
bFormat = FormatLine( rLine, bPrev );
rInf has the invalid object. That is surprising. The method does no have 
rInf as parameter.



This method is
bool SwTextFrame::FormatLine( SwTextFormatter , const bool bPrev )
in
https://opengrok.libreoffice.org/xref/core/sw/source/core/text/frmform.cxx?r=7d7ca347#1296
The adding of the faulty object happens there in #1672
in bFormat = FormatLine( rLine, bPrev );

That method is
bool SwTextFrame::FormatLine( SwTextFormatter , const bool 
bPrev )

in
https://opengrok.libreoffice.org/xref/core/sw/source/core/text/frmform.cxx?r=7d7ca347#1296


And there I'm now. I have no idea, how something there changes the 
parameter rInfo of SwTextFrame::Format_().
And I still do not know, which object is really needed in the above 
mentioned for-loop.
And I still don't know, whether the problem would be solved, when 
somehow first the line and then the group would be handled.


I appreciate any help.

Kind regards,
Regina

Regina Henschel schrieb am 11.12.2023 um 03:15:

Hi all,

I need help for bug 158451. Problem: A group or a drawing canvas in a 
docx file crashes Writer, in case it is anchored 'inline' and has a 
child shape with text. The crash happens in 
SwAnchoredObject::GetObjRectWithSpaces(). There is no crash, if such 
group is in an odt file.


It is not a new problem, but it will effect more users now, because the 
drawing canvas and not the VML fallback is imported now and the drawing 
canvas is anchored 'inline' as default in Word.


Steps before the crash are
     SwTextFormatter::NewPortion()
     SwTextFormatter::CalcFlyWidth()
     SwTextFly::GetFrame()
     SwTextFly::ForEach()
     SwAnchoredObject::GetObjRectWithSpaces()

I think the crash should be fixed till release, but I'm not familiar 
with these frames. Do you have tips for me?
Do you have an idea why a group from docx is different from a group from 
odt, for example?


Attila Bakos had worked in that area, but NISZ does no longer exist.

Kind regards,
Regina

Need help for bug 158451

[Regina Henschel]

Hi all,

I need help for bug 158451. Problem: A group or a drawing canvas in a 
docx file crashes Writer, in case it is anchored 'inline' and has a 
child shape with text. The crash happens in 
SwAnchoredObject::GetObjRectWithSpaces(). There is no crash, if such 
group is in an odt file.


It is not a new problem, but it will effect more users now, because the 
drawing canvas and not the VML fallback is imported now and the drawing 
canvas is anchored 'inline' as default in Word.


Steps before the crash are
SwTextFormatter::NewPortion()
SwTextFormatter::CalcFlyWidth()
SwTextFly::GetFrame()
SwTextFly::ForEach()
SwAnchoredObject::GetObjRectWithSpaces()

I think the crash should be fixed till release, but I'm not familiar 
with these frames. Do you have tips for me?
Do you have an idea why a group from docx is different from a group from 
odt, for example?


Attila Bakos had worked in that area, but NISZ does no longer exist.

Kind regards,
Regina

Build problems with Skia

[Regina Henschel]

Hi all,

I get a build problem with Skia in a clean build.

My autogen.sh parameters are
/cygdrive/c/BuildLO/core/autogen.sh \
--with-external-tar=/cygdrive/c/BuildLO/externalsrc \
--with-junit=/cygdrive/c/cygwin64/junit/junit-4.10.jar \
--with-ant-home=/cygdrive/c/cygwin64/ant/apache-ant-1.9.5 \
--disable-ccache \
--with-visual-studio=2022 \
--enable-debug \
--enable-werror \
--enable-odk \
--disable-cve-tests \
--disable-online-update \
--without-fonts \
--with-jdk-home=/cygdrive/c/Program\ Files/Microsoft/jdk-21.0.1.12-hotspot

The error messages are:

C:/BuildLO/core/external/skia/source/SkMemory_malloc.cxx(6,10): fatal 
error: cannot open file 
'C:/BuildLO/core/include\include/core/SkTypes.h': The file cannot

  be accessed by the system.
#include "include/core/SkTypes.h"
 ^
In file included from 
C:/BuildLO/core/external/skia/source/skia_compiler.cxx:6:
C:/BuildLO/core/external/skia/inc\skia_compiler.hxx(9,10): fatal error: 
cannot open file 'C:/BuildLO/core/include\include/core/SkTypes.h': The 
file cannot[build CXX] workdir/UnpackedTarball/skia/src/base/SkMalloc.cpp be


  accessed by the system.
#include 
 ^
In file included from C:/BuildLO/core/external/skia/source/skia_opts.cxx:6:
C:/BuildLO/core/external/skia/inc\skia_opts.hxx(9,10): fatal error: 
cannot open file 'C:/BuildLO/core/include\include/core/SkTypes.h': The 
file cannot be

  accessed by the system.
#include 
 ^
[build CXX] workdir/UnpackedTarball/skia/src/base/SkMathPriv.cpp
[build CXX] workdir/UnpackedTarball/skia/src/base/SkQuads.cpp
1 error generated.
[build CXX] workdir/UnpackedTarball/skia/src/base/SkSafeMath.cpp
[build CXX] workdir/UnpackedTarball/skia/src/base/SkSemaphore.cpp
[build CXX] workdir/UnpackedTarball/skia/src/base/SkSharedMutex.cpp
[build CXX] workdir/UnpackedTarball/skia/src/base/SkSpinlock.cpp
In file included from 
C:/buildLO/core/workdir/UnpackedTarball/skia/src/base/SkArenaAlloc.cpp:8:
C:/buildLO/core/workdir/UnpackedTarball/skia\src/base/SkArenaAlloc.h(11,10): 
fatal error: cannot open file
  'C:/BuildLO/core/include\include/private/base/SkAssert.h': The 
file cannot be accessed by the system.

#include "include/private/base/SkAssert.h"
 ^
make[1]: *** [C:/BuildLO/core/solenv/gbuild/LinkTarget.mk:340: 
C:/buildLO/core/workdir/CxxObject/external/skia/source/skia_compiler.o] 
Error 1

make[1]: *** Waiting for unfinished jobs
In file included from 
C:/buildLO/core/workdir/UnpackedTarball/skia/src/base/SkBezierCurves.cpp:8:
In file included from 
C:/buildLO/core/workdir/UnpackedTarball/skia/src/base/SkBlockAllocator.cpp:8:
C:/buildLO/core/workdir/UnpackedTarball/skia\src/base/SkBlockAllocator.h(11,10)C:/buildLO/core/workdir/UnpackedTarball/skia\src/base/SkBezierCurves.h: 
fatal error: cannot open (file
  'C:/BuildLO/core/include\include/private/base/SkAlign.h': The 
file cannot be accessed by the system.10

,#include "include/private/base/SkAlign.h"10
): ^

and so on.

Kind regards
Regina

[Libreoffice-commits] core.git: include/editeng include/svx offapi/com oox/inc oox/qa oox/source svx/source xmloff/source

[Regina Henschel (via logerrit)]

 include/editeng/unoprnms.hxx|1 
 include/svx/svddef.hxx  |6 +
 include/svx/svdoedge.hxx|8 +
 include/svx/unoshprp.hxx|3 
 offapi/com/sun/star/drawing/ConnectorProperties.idl |7 +
 oox/inc/drawingml/connectorhelper.hxx   |   33 ++-
 oox/qa/unit/data/WPC_CurvedConnector2.docx  |binary
 oox/qa/unit/data/WPC_CurvedConnector5.docx  |binary
 oox/qa/unit/wpc_drawing_canvas.cxx  |   32 ++-
 oox/source/drawingml/connectorhelper.cxx|   89 +++-
 oox/source/export/shapes.cxx|   52 +++
 oox/source/shape/ShapeContextHandler.cxx|   13 +-
 svx/source/sdr/properties/connectorproperties.cxx   |1 
 svx/source/svdraw/svdattr.cxx   |1 
 svx/source/svdraw/svdoedge.cxx  |   83 +++---
 xmloff/source/draw/ximpshap.cxx |   54 +++-
 xmloff/source/draw/ximpshap.hxx |5 +
 17 files changed, 338 insertions(+), 50 deletions(-)

New commits:
commit 44ee19c99bfb3bf0f550d9656e87bca3e20e5ca0
Author: Regina Henschel 
AuthorDate: Sun Nov 19 00:26:16 2023 +0100
Commit: Miklos Vajna 
CommitDate: Fri Dec 1 08:44:01 2023 +0100

[API CHANGE] Add OOXML way of curved connector routing

The paths generated for curved connectors are basically incompatible
between LibreOffice and OOXML. Thus it was not possible to render curved
connectors the same way as MS Office. The patch adds an OOXML compatible
method for calculating the path. The new method results in a different
svg:d attribute when saved in ODF, but needs no change to ODF.

The patch introduces the boolean connector property 'EdgeOOXMLCurve' to
switch between the two methods. The property value is determined from
the svg:d attribute in case of import from ODF. In case of missing
svg:d attribute the property value is set to 'true', because Word
currently does not write a svg:d attribute when it exports to ODF.
The property value is set to 'true' for import of connectors on a
drawing canvas in docx. Default value for new connectors is 'false'.

The new property has no UI, but can be used via macro.

Currently the new method is used for import of curved connectors on
drawing canvas in docx documents.

Change-Id: I53d99f44febe4d74c2b611f5fdb9de86628c4519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159708
Tested-by: Jenkins
Reviewed-by: Miklos Vajna 

diff --git a/include/editeng/unoprnms.hxx b/include/editeng/unoprnms.hxx
index 1300effe179f..7f742f549833 100644
--- a/include/editeng/unoprnms.hxx
+++ b/include/editeng/unoprnms.hxx
@@ -56,6 +56,7 @@ inline constexpr OUString UNO_NAME_EDGENODE1HORZDIST = 
u"EdgeNode1HorzDist"_ustr
 inline constexpr OUString UNO_NAME_EDGENODE1VERTDIST = 
u"EdgeNode1VertDist"_ustr;
 inline constexpr OUString UNO_NAME_EDGENODE2HORZDIST = 
u"EdgeNode2HorzDist"_ustr;
 inline constexpr OUString UNO_NAME_EDGENODE2VERTDIST = 
u"EdgeNode2VertDist"_ustr;
+inline constexpr OUString UNO_NAME_EDGEOOXMLCURVE = u"EdgeOOXMLCurve"_ustr;
 
 inline constexpr OUString UNO_NAME_FILLBMP_OFFSET_X = 
u"FillBitmapOffsetX"_ustr;
 inline constexpr OUString UNO_NAME_FILLBMP_OFFSET_Y = 
u"FillBitmapOffsetY"_ustr;
diff --git a/include/svx/svddef.hxx b/include/svx/svddef.hxx
index fa57a8aa0bfc..500d68fc3916 100644
--- a/include/svx/svddef.hxx
+++ b/include/svx/svddef.hxx
@@ -441,7 +441,11 @@ constexpr sal_uInt16  
SDRATTR_WRITINGMODE2_FIRST(SDRATTR
 constexpr TypedWhichId 
SDRATTR_WRITINGMODE2(SDRATTR_WRITINGMODE2_FIRST+0);// 1248
 constexpr sal_uInt16  
SDRATTR_WRITINGMODE2_LAST(SDRATTR_WRITINGMODE2);   // 1248
 
-constexpr sal_uInt16 SDRATTR_END (SDRATTR_WRITINGMODE2_LAST);  // 1248
+constexpr sal_uInt16  
SDRATTR_EDGEOOXMLCURVE_FIRST(SDRATTR_WRITINGMODE2_LAST+1);// 1249
+constexpr TypedWhichId   
SDRATTR_EDGEOOXMLCURVE(SDRATTR_EDGEOOXMLCURVE_FIRST+0);   // 1249
+constexpr sal_uInt16  
SDRATTR_EDGEOOXMLCURVE_LAST(SDRATTR_EDGEOOXMLCURVE);  // 1249
+
+constexpr sal_uInt16 SDRATTR_END (SDRATTR_EDGEOOXMLCURVE_LAST);  // 1249
 
 #endif // INCLUDED_SVX_SVDDEF_HXX
 
diff --git a/include/svx/svdoedge.hxx b/include/svx/svdoedge.hxx
index 94bb89a00a3e..9c987e259ea3 100644
--- a/include/svx/svdoedge.hxx
+++ b/include/svx/svdoedge.hxx
@@ -91,13 +91,19 @@ public:
 sal_uInt16  m_nObj2Lines;// 1..3
 sal_uInt16  m_nMiddleLine;   // 0x=none, otherwise 
point number of the beginning of the line
 
+// The value determines how curved connectors are routed. With value 
'true' it is routed
+// compati

[Libreoffice-commits] core.git: oox/qa writerfilter/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/WPC_tdf158348_shape_text_in_table_cell.docx |binary
 oox/qa/unit/wpc_drawing_canvas.cxx   |   32 ++-
 writerfilter/source/ooxml/OOXMLFastContextHandler.cxx|4 -
 3 files changed, 33 insertions(+), 3 deletions(-)

New commits:
commit bf6350ef7f9856abc4d6a085bd2d2f95d6b0c84e
Author: Regina Henschel 
AuthorDate: Mon Nov 27 02:22:29 2023 +0100
Commit: Regina Henschel 
CommitDate: Tue Nov 28 14:07:30 2023 +0100

tdf#158348 Treat wordprocessing canvas like group shape

getFullWPGSupport() is always false for mrShapeContext in case of a
shape on wordprocessing canvas in table cell. On the other hand we do
not need the test, because a wordprocessing canvas only occurs in docx
and thus the replacement group always has FullWPGSupport.

Change-Id: I0e7a9cf1c1c91a893ad7411fda7607947f053e05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159979
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/qa/unit/data/WPC_tdf158348_shape_text_in_table_cell.docx 
b/oox/qa/unit/data/WPC_tdf158348_shape_text_in_table_cell.docx
new file mode 100644
index ..e8f2cf73d3d5
Binary files /dev/null and 
b/oox/qa/unit/data/WPC_tdf158348_shape_text_in_table_cell.docx differ
diff --git a/oox/qa/unit/wpc_drawing_canvas.cxx 
b/oox/qa/unit/wpc_drawing_canvas.cxx
index 1d00123e14a1..d1fde534034c 100644
--- a/oox/qa/unit/wpc_drawing_canvas.cxx
+++ b/oox/qa/unit/wpc_drawing_canvas.cxx
@@ -20,9 +20,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
-#include 
 #include 
 
 using namespace ::com::sun::star;
@@ -276,6 +278,34 @@ CPPUNIT_TEST_FIXTURE(TestWPC, 
WPC_tdf158339_shape_text_in_group)
 CPPUNIT_ASSERT(xTextFrame.is());
 CPPUNIT_ASSERT_EQUAL(OUString("Group"), 
xTextFrame->getText()->getString());
 }
+
+CPPUNIT_TEST_FIXTURE(TestWPC, WPC_tdf158348_shape_text_in_table_cell)
+{
+// The document has a shape with text on a drawing canvas in a table cell.
+// Without fix the text of the shape becomes part of the paragraph of the 
table cell.
+loadFromURL(u"WPC_tdf158348_shape_text_in_table_cell.docx");
+
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference 
xDrawPage(xDrawPagesSupplier->getDrawPages()->getByIndex(0),
+ uno::UNO_QUERY);
+
+// Get the shape and make sure it has text.
+uno::Reference xCanvas(xDrawPage->getByIndex(0), 
uno::UNO_QUERY);
+uno::Reference xShapeProps(xCanvas->getByIndex(1), 
uno::UNO_QUERY);
+uno::Reference xTextFrame;
+xShapeProps->getPropertyValue(u"TextBoxContent"_ustr) >>= xTextFrame;
+CPPUNIT_ASSERT(xTextFrame.is());
+// The string was empty without fix.
+CPPUNIT_ASSERT_EQUAL(u"Inside shape"_ustr, 
xTextFrame->getText()->getString());
+
+// Get the table and make sure the cell has only its own text.
+uno::Reference xTablesSupplier(mxComponent, 
uno::UNO_QUERY);
+uno::Reference xTextTable(
+xTablesSupplier->getTextTables()->getByName(u"Table1"_ustr), 
uno::UNO_QUERY);
+uno::Reference xCellA1(xTextTable->getCellByName("A1"), 
uno::UNO_QUERY);
+// The string had started with "Inside shape" without fix.
+CPPUNIT_ASSERT(xCellA1->getString().startsWith("Inside table"));
+}
 }
 
 CPPUNIT_PLUGIN_IMPLEMENT();
diff --git a/writerfilter/source/ooxml/OOXMLFastContextHandler.cxx 
b/writerfilter/source/ooxml/OOXMLFastContextHandler.cxx
index 30ed3a70e63c..cbc75c14070a 100644
--- a/writerfilter/source/ooxml/OOXMLFastContextHandler.cxx
+++ b/writerfilter/source/ooxml/OOXMLFastContextHandler.cxx
@@ -1840,8 +1840,8 @@ void OOXMLFastContextHandlerShape::sendShape( Token_t 
Element )
 
 bool OOXMLFastContextHandlerShape::isDMLGroupShape() const
 {
-return (mrShapeContext->getFullWPGSupport()
-   && (mrShapeContext->isWordProcessingGroupShape() || 
mrShapeContext->isWordprocessingCanvas()));
+return (mrShapeContext->getFullWPGSupport() && 
mrShapeContext->isWordProcessingGroupShape())
+|| mrShapeContext->isWordprocessingCanvas();
 };
 
 void OOXMLFastContextHandlerShape::lcl_endFastElement

[Libreoffice-commits] core.git: oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/WPC_tdf158339_shape_text_in_group.docx |binary
 oox/qa/unit/wpc_drawing_canvas.cxx  |   24 
 oox/source/shape/WordprocessingCanvasContext.cxx|6 +++-
 3 files changed, 29 insertions(+), 1 deletion(-)

New commits:
commit 63ecd577f5fe95feda0d1d8577a7d3b493999d78
Author: Regina Henschel 
AuthorDate: Fri Nov 24 01:18:22 2023 +0100
Commit: Regina Henschel 
CommitDate: Fri Nov 24 15:15:41 2023 +0100

tdf#158339 setFullWPGSupport to group shape in wpc

otherwise the group will create no wps shapes but draw shapes and those
cannot be connected to text frames. The text frames were then located
separate outside the drawing canvas instead of being bound to the shape.

Change-Id: I525fac157c08c60d43ff9420775e2cbb9d891d23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159885
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/qa/unit/data/WPC_tdf158339_shape_text_in_group.docx 
b/oox/qa/unit/data/WPC_tdf158339_shape_text_in_group.docx
new file mode 100644
index ..b34071cd99d2
Binary files /dev/null and 
b/oox/qa/unit/data/WPC_tdf158339_shape_text_in_group.docx differ
diff --git a/oox/qa/unit/wpc_drawing_canvas.cxx 
b/oox/qa/unit/wpc_drawing_canvas.cxx
index 0857eb8099cf..1d00123e14a1 100644
--- a/oox/qa/unit/wpc_drawing_canvas.cxx
+++ b/oox/qa/unit/wpc_drawing_canvas.cxx
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -252,6 +253,29 @@ CPPUNIT_TEST_FIXTURE(TestWPC, WPC_Shadow)
 xShapeProps->getPropertyValue(UNO_NAME_SHADOWCOLOR) >>= nColor;
 CPPUNIT_ASSERT_EQUAL(Color(0x808080), nColor);
 }
+
+CPPUNIT_TEST_FIXTURE(TestWPC, WPC_tdf158339_shape_text_in_group)
+{
+// The document has a group of two shapes with text. This group is child 
of a drawing canvas.
+// Without fix the text of the shapes were imported as separate text boxes.
+loadFromURL(u"WPC_tdf158339_shape_text_in_group.docx");
+
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference 
xDrawPage(xDrawPagesSupplier->getDrawPages()->getByIndex(0),
+ uno::UNO_QUERY);
+// Make sure there is only one object on that page. Without fix there were 
three objects.
+CPPUNIT_ASSERT_EQUAL(sal_Int32(1), xDrawPage->getCount());
+// Get the group which represents the drawing canvas and the group object 
inside.
+uno::Reference xCanvas(xDrawPage->getByIndex(0), 
uno::UNO_QUERY);
+uno::Reference xGroup(xCanvas->getByIndex(1), 
uno::UNO_QUERY);
+// Get the properties of the second shape inside the group
+uno::Reference xShapeProps(xGroup->getByIndex(1), 
uno::UNO_QUERY);
+// and make sure the shape has text.
+uno::Reference xTextFrame;
+xShapeProps->getPropertyValue(u"TextBoxContent"_ustr) >>= xTextFrame;
+CPPUNIT_ASSERT(xTextFrame.is());
+CPPUNIT_ASSERT_EQUAL(OUString("Group"), 
xTextFrame->getText()->getString());
+}
 }
 
 CPPUNIT_PLUGIN_IMPLEMENT();
diff --git a/oox/source/shape/WordprocessingCanvasContext.cxx 
b/oox/source/shape/WordprocessingCanvasContext.cxx
index 7273a8d23ea6..9365e387f5e3 100644
--- a/oox/source/shape/WordprocessingCanvasContext.cxx
+++ b/oox/source/shape/WordprocessingCanvasContext.cxx
@@ -88,7 +88,11 @@ WordprocessingCanvasContext::onCreateContext(sal_Int32 
nElementToken,
  << getBaseToken(nElementToken));
 break;
 case XML_wgp: // CT_WordprocessingGroup
-return new oox::shape::WpgContext(*this, mpShapePtr);
+{
+rtl::Reference pWPGContext = new 
oox::shape::WpgContext(*this, mpShapePtr);
+pWPGContext->setFullWPGSupport(m_bFullWPGSupport);
+return pWPGContext;
+}
 default:
 // includes case XML_contentPart
 // Word uses this for Ink, as  for 
example. Thereby rId4 is

Re: LINK : fatal error LNK1181: cannot open input file 'ixo.lib'

[Regina Henschel]

Hi Kohei, hi Michael,

thank you for looking at it.

I'll try to change my solution to use a property.

Kind regards,
Regina

Michael Stahl schrieb am 22.11.2023 um 09:59:

hi Regina,

On 22/11/2023 00:35, Regina Henschel wrote:

Hi Kohei,

Kohei Yoshida schrieb am 22.11.2023 um 00:10:

Hi Regina,

On 11/21/23 17:43, Regina Henschel wrote:

Hi all,

I have no idea, what is wrong with
https://gerrit.libreoffice.org/c/core/+/159708


 From what I can see, you have added svxcore as a new dependency of 
xo, but svxcore itself already depends on xo.  So you now have xo and 
svxcore depending on each other... 


I have added it to be able to use object and functions of class 
SdrEdgeObj (svdoedge.hxx) in xmloff/source/draw/ximpshap.cxx.


Is there a different way to allow use of the functions?


i'm afraid not, you have to use UNO API to set shape properties.

What do I need to change to MS Visual Studio or to autogen.sh so that 
such problem becomes already visible locally?


probably it works by accident because you already had a full build where 
both libraries exist before adding the cyclic dependency.

Re: LINK : fatal error LNK1181: cannot open input file 'ixo.lib'

[Regina Henschel]

Hi Kohei,

Kohei Yoshida schrieb am 22.11.2023 um 00:10:

Hi Regina,

On 11/21/23 17:43, Regina Henschel wrote:

Hi all,

I have no idea, what is wrong with
https://gerrit.libreoffice.org/c/core/+/159708


 From what I can see, you have added svxcore as a new dependency of xo, 
but svxcore itself already depends on xo.  So you now have xo and 
svxcore depending on each other... 


I have added it to be able to use object and functions of class 
SdrEdgeObj (svdoedge.hxx) in xmloff/source/draw/ximpshap.cxx.


Is there a different way to allow use of the functions?

What do I need to change to MS Visual Studio or to autogen.sh so that 
such problem becomes already visible locally?

Currently my autogen.sh is
/cygdrive/d/Build_forCommit/core/autogen.sh \
--with-external-tar=/cygdrive/d/Build_forCommit/externalsrc \
--with-junit=/cygdrive/c/cygwin64/junit/junit-4.10.jar \
--with-ant-home=/cygdrive/c/cygwin64/ant199 \
--disable-ccache \
--with-visual-studio=2022 \
--without-fonts \
--enable-debug \
--enable-werror \
--enable-odk \
--disable-cve-tests \
--with-parallelism=4 \
--disable-online-update \
--with-jdk-home=/cygdrive/c/Program\ Files/Microsoft/jdk-17.0.8.101-hotspot

Kind regards,
Regina

LINK : fatal error LNK1181: cannot open input file 'ixo.lib'

[Regina Henschel]

Hi all,

I have no idea, what is wrong with
https://gerrit.libreoffice.org/c/core/+/159708

Can you please help?

Kind regards,
Regina

How to add new attribute?

[Regina Henschel]

Hi all,

I'm going to implement a routing of curved connector shapes, that is 
compatible with OOXML. The information, that the OOXML way has to be 
used, will become a boolean member in class SdrEdgeInfoRec.


For testing I have added a method to class SdrEdgeObj to set the value. 
But I think, using an attribute would be better, same as e.g. 
"EdgeLine1Delta".


When I add the attribute to /core/include/svx/svddef.hxx
can I add it directly after
constexpr TypedWhichId SDRATTR_EDGELINE3DELTA 
(SDRATTR_EDGE_FIRST +10);   // 1106
or do I need to add it at the end, using _first and _last surround as 
can be seen for writingmode2?



Do you have a suggestion for a term for such attribute? I would like to 
start with "Edge", so that it will be listed near the other "Edge.." 
attributes in the UI. "EdgeOOXMLCurve" or "EdgeCompatibleCurveRouting" 
or ...?


Kind regards,
Regina

[Libreoffice-commits] core.git: include/oox oox/inc oox/qa oox/source

[Regina Henschel (via logerrit)]

 include/oox/token/tokenmap.hxx |   11 +++
 oox/inc/drawingml/connectorhelper.hxx  |8 
 oox/inc/drawingml/customshapeproperties.hxx|2 +-
 oox/qa/token/tokenmap-test.cxx |   13 +
 oox/source/drawingml/connectorhelper.cxx   |   13 ++---
 oox/source/drawingml/customshapeproperties.cxx |4 ++--
 oox/source/drawingml/shape.cxx |   13 ++---
 oox/source/drawingml/table/tablecell.cxx   |5 +
 8 files changed, 32 insertions(+), 37 deletions(-)

New commits:
commit 270b7efe92751a46c3d85e856b932a365c5f5b73
Author: Regina Henschel 
AuthorDate: Thu Nov 16 15:19:08 2023 +0100
Commit: Regina Henschel 
CommitDate: Fri Nov 17 15:33:41 2023 +0100

Add getUnicodeTokenName() to StaticTokenMap and use...

it in several places. Currently these places get a Sequence
by call of StaticTokenMap().getUtf8TokenName() and immediately after
that generate an OUString from it using reinterpret_cast
and the OUString ctor with 8-Bit character buffer array. The patch
moves this conversion to StaticTokenMap.

Change-Id: Ia2af110e2a0f1708e0685115d325c1c12cab3857
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159514
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/include/oox/token/tokenmap.hxx b/include/oox/token/tokenmap.hxx
index db71c24c2371..4358822c360f 100644
--- a/include/oox/token/tokenmap.hxx
+++ b/include/oox/token/tokenmap.hxx
@@ -76,6 +76,17 @@ public:
 return getTokenPerfectHash( pToken, nLength );
 }
 
+/** Returns the name of the passed token identifier as OUString. */
+OUString getUnicodeTokenName(sal_Int32 nToken) const
+{
+SAL_WARN_IF(nToken < 0 || nToken >= XML_TOKEN_COUNT, "oox", "Wrong 
nToken parameter");
+OUString const ret((0 <= nToken && nToken < XML_TOKEN_COUNT)
+? rtl::OUString(reinterpret_cast(maTokenNames[nToken].getConstArray()),
+maTokenNames[nToken].getLength(), 
RTL_TEXTENCODING_UTF8)
+: OUString());
+return ret;
+}
+
 private:
 static sal_Int32 getTokenPerfectHash( const char *pToken, sal_Int32 
nLength );
 static const css::uno::Sequence< sal_Int8 > EMPTY_BYTE_SEQ;
diff --git a/oox/inc/drawingml/connectorhelper.hxx 
b/oox/inc/drawingml/connectorhelper.hxx
index 1e875ab8ee95..f5409d635270 100644
--- a/oox/inc/drawingml/connectorhelper.hxx
+++ b/oox/inc/drawingml/connectorhelper.hxx
@@ -24,14 +24,6 @@
 
 namespace ConnectorHelper
 {
-/* ToDo: Other place? It uses getShapePresetTypeName() and that is only used 
in shape.cxx in
-   Shape::createAndInsert() for "mso-orig-shape-type" property in GrabBag and 
for msConnectorName.
-   In both cases it is immediately converted to OUString. So perhaps let
-   getShapePresetTypeName() return an OUString directly?
-*/
-rtl::OUString getShapePresetTypeNameOUString(
-const oox::drawingml::CustomShapePropertiesPtr& pCustomShapePropertiesPtr);
-
 /**
  * Some preset shapes use the default connector site but in order right, 
bottom, left, top.
  * The function detects this.
diff --git a/oox/inc/drawingml/customshapeproperties.hxx 
b/oox/inc/drawingml/customshapeproperties.hxx
index 61a151d9aa09..c699ffddcce7 100644
--- a/oox/inc/drawingml/customshapeproperties.hxx
+++ b/oox/inc/drawingml/customshapeproperties.hxx
@@ -101,7 +101,7 @@ public:
 const css::awt::Size  );
 
 sal_Int32 getShapePresetType() const { return mnShapePresetType; }
-css::uno::Sequence< sal_Int8 > const & getShapePresetTypeName() const;
+OUString getShapePresetTypeName() const;
 void setShapePresetType( sal_Int32 nShapePresetType ){ mnShapePresetType = 
nShapePresetType; };
 boolgetShapeTypeOverride() const { return 
mbShapeTypeOverride; };
 voidsetShapeTypeOverride( bool 
bShapeTypeOverride ) { mbShapeTypeOverride = bShapeTypeOverride; };
diff --git a/oox/qa/token/tokenmap-test.cxx b/oox/qa/token/tokenmap-test.cxx
index 058f7c16ebbf..e30b6aef806b 100644
--- a/oox/qa/token/tokenmap-test.cxx
+++ b/oox/qa/token/tokenmap-test.cxx
@@ -23,10 +23,12 @@ class TokenmapTest: public CppUnit::TestFixture
 {
 public:
 void test_roundTrip();
+void test_roundTripUnicode();
 
 CPPUNIT_TEST_SUITE(TokenmapTest);
 
 CPPUNIT_TEST(test_roundTrip);
+CPPUNIT_TEST(test_roundTripUnicode);
 CPPUNIT_TEST_SUITE_END();
 
 private:
@@ -46,6 +48,17 @@ void TokenmapTest::test_roundTrip()
 }
 }
 
+void TokenmapTest::test_roundTripUnicode()
+{
+for (sal_Int32 nToken = 0; nToken < XML_TOKEN_COUNT; ++nToken)
+{
+// check that the getIdentifier <-> getToken roundtrip works for 
OUString
+OUString sName = tokenMap.getUnicodeTokenName(nToken);
+sal_Int32 ret = oox::

[Libreoffice-commits] core.git: include/oox oox/source

[Regina Henschel (via logerrit)]

 include/oox/drawingml/connectorshapecontext.hxx  |1 +
 oox/source/shape/WordprocessingCanvasContext.hxx |1 +
 2 files changed, 2 insertions(+)

New commits:
commit 6550c248521b65a367b33ba8db95d17a9a350800
Author: Regina Henschel 
AuthorDate: Wed Nov 15 19:24:59 2023 +0100
Commit: Regina Henschel 
CommitDate: Wed Nov 15 22:38:39 2023 +0100

Add comments to import of Wordprocessing Canvas

Change-Id: I09af78b08fed886e36beca1770db6fc54a72b707
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159473
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/include/oox/drawingml/connectorshapecontext.hxx 
b/include/oox/drawingml/connectorshapecontext.hxx
index 9911ce84de53..2b95ff4f3d4c 100644
--- a/include/oox/drawingml/connectorshapecontext.hxx
+++ b/include/oox/drawingml/connectorshapecontext.hxx
@@ -39,6 +39,7 @@ namespace oox::drawingml {
 sal_Int32 mnDestGlueId;
 };
 
+/// Handles CT_NonVisualConnectorProperties, used for cNvCnPr (Word) and 
cNvCxnSpPr (PP) elements.
 class ConnectorShapePropertiesContext : public ::oox::core::ContextHandler2
 {
 std::vector& mrConnectorShapePropertiesList;
diff --git a/oox/source/shape/WordprocessingCanvasContext.hxx 
b/oox/source/shape/WordprocessingCanvasContext.hxx
index dbb2148967e8..d4cc67f6a9ba 100644
--- a/oox/source/shape/WordprocessingCanvasContext.hxx
+++ b/oox/source/shape/WordprocessingCanvasContext.hxx
@@ -14,6 +14,7 @@
 
 namespace oox::shape
 {
+/// Handles CT_WordprocessingCanvas, used for wpc element, which is a drawing 
canvas for Word.
 class WordprocessingCanvasContext final : public oox::core::FragmentHandler2
 {
 public:

[Libreoffice-commits] core.git: include/oox oox/CppunitTest_oox_wpc_drawing_canvas.mk oox/inc oox/Library_oox.mk oox/Module_oox.mk oox/qa oox/source sw/qa writerfilter/source

[Regina Henschel (via logerrit)]

 include/oox/drawingml/connectorshapecontext.hxx  |   14 
 include/oox/drawingml/shape.hxx  |3 
 include/oox/shape/ShapeContextHandler.hxx|4 
 oox/CppunitTest_oox_wpc_drawing_canvas.mk|   54 +
 oox/Library_oox.mk   |2 
 oox/Module_oox.mk|1 
 oox/inc/drawingml/connectorhelper.hxx|  108 +++
 oox/qa/unit/data/WPC_BentConnector.docx  |binary
 oox/qa/unit/data/WPC_CanvasBackground.docx   |binary
 oox/qa/unit/data/WPC_Glow.docx   |binary
 oox/qa/unit/data/WPC_MulticolorGradient.docx |binary
 oox/qa/unit/data/WPC_Shadow.docx |binary
 oox/qa/unit/data/WPC_Textwrap_in_ellipse.docx|binary
 oox/qa/unit/data/WPC_ThemeColor.docx |binary
 oox/qa/unit/data/WPC_tdf104671_Cloud.docx|binary
 oox/qa/unit/data/WPC_tdf48610_Textbox_with_table_inside.docx |binary
 oox/qa/unit/wpc_drawing_canvas.cxx   |  259 +++
 oox/source/drawingml/connectorhelper.cxx |  368 +++
 oox/source/drawingml/connectorshapecontext.cxx   |   17 
 oox/source/drawingml/shape.cxx   |   44 +
 oox/source/drawingml/shapegroupcontext.cxx   |1 
 oox/source/shape/ShapeContextHandler.cxx |   88 ++
 oox/source/shape/WordprocessingCanvasContext.cxx |  106 +++
 oox/source/shape/WordprocessingCanvasContext.hxx |   38 +
 oox/source/shape/WpsContext.cxx  |   32 
 oox/source/token/namespaces-strict.txt   |1 
 oox/source/token/namespaces.hxx.tail |2 
 oox/source/token/namespaces.txt  |1 
 oox/source/token/tokens.txt  |1 
 sw/qa/extras/ooxmlexport/ooxmlexport14.cxx   |4 
 sw/qa/extras/ooxmlexport/ooxmlexport3.cxx|5 
 sw/qa/extras/ooxmlimport/ooxmlimport2.cxx|   20 
 writerfilter/source/dmapper/GraphicImport.cxx|   20 
 writerfilter/source/ooxml/OOXMLFastContextHandler.cxx|8 
 writerfilter/source/ooxml/model.xml  |   47 +
 35 files changed, 1209 insertions(+), 39 deletions(-)

New commits:
commit 0430adb42bc38f037b907984e71c144d863796cb
Author: Regina Henschel 
AuthorDate: Wed Sep 6 23:03:39 2023 +0200
Commit: Miklos Vajna 
CommitDate: Wed Nov 15 11:13:31 2023 +0100

Import Wordprocessing Canvas, wpc:wpc element

Currently LibreOffice uses the VML fallback, when a docx document has a
wpc:wpc element. This patch implements to use the choice part with the
wpc:wpc element. That is often called 'drawing canvas'.

The patch uses a similar approach as for SmartArt. The drawing canvas is
imported as group shape and for the background an additional rectangular
shape is inserted as first in the children vector.

Not using VML has the advantage, that the custom shape import is used
for preset shapes. VML import produces problems because some properties
are not available in VML or the current VML import has deficits. The
test suite shows examples, what is better without using the VML
fallback. Affected bug reports are e.g. tdf#104671 or tdf#154828.

A drawing canvas must be used in Word for connector shapes. A connector
in Word on the drawing canvas is not written as cxnSp element, but as
ordinary wsp element with additional wps:cNvCnPr child element. The patch
generates a connector in such case.

Unsolved problems:

The path of a curved connector in OOXML is basically incompatible to
the path which LibreOffice generates. This patch uses the default
path for a curved connector. Same is done in import in Impress. Using
the VML fallback had generated a custom shape with the current path
and handles, but the connections to the target shapes were lost.

Export to docx is missing. The drawing canvas is not recreated,
instead a group with the additional background shape is exported. That
is no regression, using VML has produced a group too on export.

I don't know whether XML_graphicFrame can occur in
WordprocessingCanvasContext. At least charts and math equations are
not possible on the drawing canvas in Word.

Import of WordArt shapes does not work. That is not regression. It
works neither in the VML import.

Change-Id: I04bf8407efd1939cdf3137775f8afad420b74014
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156629
Tested-by: Jenkins
Reviewed-by: Miklos Vajna 

diff --git a/include/oox/drawingml/connectorshapecontext.hxx

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

I have now at least started. Sorry for the delay.
https://issues.oasis-open.org/browse/OFFICE-4150

I hope I have got it so that it fits to your intentions. Better 
attribute names and wording can still be discussed.


Kind regards,
Regina

Miklos Vajna schrieb am 12.10.2023 um 08:33:

Hi Regina,

On Wed, Oct 11, 2023 at 04:01:43PM +0200, Regina Henschel 
 wrote:

Thanks a lot. Please let me know when there is a proposal, I would like
to link to it from our extension schema.


Yes, of cause. However, the task has moved further down on my ToDo list,
because at the moment the things needed for the upcoming ODF 1.4 have
priority.


Makes sense.


Something else: do you have a preferred name for the XML attribute that
decides if the wrap should be only on the last page or on all pages?
Something like text:wrap-on-all-pages="", defaulting to false?


No, I have no preferred name. However, I would prefer a "style" prefix to
have it similar to the existing attribute "style:number-wrapped-paragraphs"
(20.326 ODF 1.3) and other wrap related attributes. So I suggest
"style:wrap-on-all-pages".


Fine, I don't yet have code for this, so any sensible namespace works
for me.

Thanks,

Miklos

Import of drawing canvas in docx documents

[Regina Henschel]

Hi all,

my patch https://gerrit.libreoffice.org/c/core/+/156629 is ready for 
review. Please have a look.


It has unit tests that show what is now possible compared to the import 
of the VML fallback.


I'm unsure about writing conventions, e.g. when start with lower or 
upper case. Please advise me.


Kind regards,
Regina

Re: Import of curved connectors from OOXML

[Regina Henschel]

Hi Miklos,

I have thought about it again. I think, we need nothing new in ODF. We 
can decide whether to use our routing or the OOXML routing from the 
svg:d attribute.
If the svg:d attribute is missing, we use OOXML routing. MS Office does 
not write the svg:d attribute, when it exports to odp. But we have 
written it always.


And when there is a svg:d attribute we can count the number of Bezier 
curve segments and look whether first and last control vectors are 
parallel or orthogonal. See the table below. Only in case of a curved 
connector without handle, we need to look in addition how long the first 
control vector is.


 |parallel  | orthogonal
-+--+
1 Bezier | LO one handle| LO no handle, vector 2/3 width/height
 | OOX NA   | OOX curvedConnector2, vector 1/2 w/h
-+--+-
2 Bezier | LO NA| LO two handles
 | OOX curvedConnector3 | OOX NA
-+--+
3 Bezier | LO three handles | LO NA
 | OOX NA   | OOX curvedConnector4
-+--+
4 Bezier | LO NA| LO NA
 | OOX curvedConnector5 | OOX NA
-+--+

So a solution could be to add an additional member to SdrEdgeObj and its 
SdrEdgeObjGeoData and set it on import. Bringing this to UI and API 
would be a second step.


I know, that it needs an additional case in 
SdrEdgeObj::ImpCalcEdgeTrack() around line 1504 in svdoedge.cxx. But I 
don't know yet, which other places beside import and export have to be 
changed.


Kind regards,
Regina



Miklos Vajna schrieb am 09.11.2023 um 09:17:

Hi Regina,

On Wed, Nov 08, 2023 at 02:38:03AM +0100, Regina Henschel 
 wrote:

If we are in running LibreOffice we could distinguish two ways by a new
constant in enum class SdrCompatibilityFlag, for example. But how to save
such information to ODF?
Keep path definition as vague as it is now and put the information into
settings.xml?
Add a new value "curveOOXML" to draw:type (19.229.2) to specify a path as in
OOXML?


I expect the settings.xml way would work if we know you won't have both
curve and curveOOXML shapes at the same time in a document. I assume
that can happen, so that's not a good fit here.

Adding a new value to draw:type sounds better, though possibly
"curveOOXML" is a poor name, it would be better to have a
"curveSomething" name that actually describes the new behavior, without
explicitly referring to OOXML.

But quite probably you know this already. :-)

Regards,

Miklos

Re: Import of curved connectors from OOXML

[Regina Henschel]

Hi Thorsten, hi Tibor, hi all,

Thorsten Behrens schrieb am 04.11.2023 um 13:52:

Hi Regina,

Regina Henschel wrote:

It is not an ODF problem.


Oh ok - then what I implied, was instead of trying to emulate the
curvedConnector3 connector by mapping it to our existing ones, why not
implement the missing drawingml ones natively?


I have tried some more days to get at least for curvedConnector3 a 
satisfactory approximation, but without success. So it seems we really 
need to have a second way to render curved connectors.


I do not want to replace the current way of the connector path, because 
our path is nicer than the OOOXML way. Our path uses symmetric 
transitions in the Bézier-curve, that is not the case in OOXML.


If we are in running LibreOffice we could distinguish two ways by a new 
constant in enum class SdrCompatibilityFlag, for example. But how to 
save such information to ODF?
Keep path definition as vague as it is now and put the information into 
settings.xml?
Add a new value "curveOOXML" to draw:type (19.229.2) to specify a path 
as in OOXML?


Tibor, you have assigned some connector related bugs to you. Do you have 
already started the work?


Another question is, whether I should continue with my work on 
https://gerrit.libreoffice.org/c/core/+/156629 or postpone it until the 
connector problems are solved? In current state of my patch import uses 
them with default routing.


Kind regards,
Regina

Re: Import of curved connectors from OOXML

[Regina Henschel]

Hi Thorsten,

Thorsten Behrens schrieb am 03.11.2023 um 20:07:

Hi Regina,

Regina Henschel wrote:

I could try to approximate the OOXML curve by defining ersatz adjustment
values. What criteria should be used for such an approximation? Anyway, it
is mathematically complex, especially for cases with two or three handles.


Sounds like a good reason then to extend ODF's connector types?


The relevant section [1] in ODF is:

10.3.10 

The  element represents a connected set of one or more 
lines that visually connects a start and an end point.


Start and/or end points can be defined by references to glue points 
10.3.16 or as absolute positions.  The connector's geometric path is 
defined by the svg:d 19.530 attribute. Consumers may also compute the 
connector's geometric path considering the draw:type 19.229.2 and 
draw:line-skew 19.190 attributes, and the formatting properties defined 
for connectors.


If the svg:d attribute is not present, the connector's geometric path is 
implementation-dependent. Producers should export the connector's 
geometric path using the svg:d attribute.



ODF has no rule at all, how to generate the path for a curve connector 
and a producer need not even define his way to do it. That is different 
in OOXML. There the connector path is specified and it is only up to the 
producer which type of connector and which adjustment values he uses.


It is not an ODF problem.

[1] 
https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#element-draw_connector


Kind regards,
Regina

Import of curved connectors from OOXML

[Regina Henschel]

Hi all,

I'm still working on import of the "drawing canvas" of docx. I have 
stumbled across problems with curved connectors.


Curved connectors in OOXML use different Bézier-curve segments than 
LibreOffice. For example, a curvedConnector3 has two Bèzier-curve 
segments with the handle on their common anchor point, whereas 
LibreOffice has one Bézier-curve segment with the handle outside the 
curve. These ways of creating a curve are basically incompatible.


The current import of "drawing canvas" uses the VML fallback. That 
results in a custom shape, e.g. of type "mso-spt39" (= 
msosptCurvedConnector4). It has the curve as it is shaped in Word and 
its handles, but is no longer a connector, but a custom shape.


It would be possible, to set the curve as "user defined" EdgeTrackPath 
to a connector, but for that the connector needs to be disconnected and 
handles would not be usable.


I could try to approximate the OOXML curve by defining ersatz adjustment 
values. What criteria should be used for such an approximation? Anyway, 
it is mathematically complex, especially for cases with two or three 
handles.


Impress does not attempt to approximate, but imports curved connectors 
to the default curved connector of LibreOffice, losing all adjustment 
values.


What to do?

Kind regards,
Regina

[Libreoffice-commits] core.git: Branch 'libreoffice-7-6' - cui/uiconfig

[Regina Henschel (via logerrit)]

 cui/uiconfig/ui/connectortabpage.ui |3 +++
 1 file changed, 3 insertions(+)

New commits:
commit 5c89f10495b34fccff1509ec96593dfa4f4532c9
Author: Regina Henschel 
AuthorDate: Mon Oct 9 13:31:06 2023 +0200
Commit: Xisco Fauli 
CommitDate: Thu Oct 19 13:15:21 2023 +0200

tdf#132605 Negative skew values in connector dialog

The skew values of a standard connector can have negative values.
Those are possible in ODF, rendered in LO and produced by dragging the
handles. Only the dialog restricts the metric field to non negative
values. The patch allows negative values now.

Change-Id: I5174dccc1ed0ed8644e0f62a5d599eea4d5cdbaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157700
Tested-by: Jenkins
Reviewed-by: Heiko Tietze 
(cherry picked from commit 6c32d052011132e891dab3254bf2a2ea6f31e888)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158153
Reviewed-by: Michael Stahl 

diff --git a/cui/uiconfig/ui/connectortabpage.ui 
b/cui/uiconfig/ui/connectortabpage.ui
index a2f6aadf3e03..d82e643f4629 100644
--- a/cui/uiconfig/ui/connectortabpage.ui
+++ b/cui/uiconfig/ui/connectortabpage.ui
@@ -3,16 +3,19 @@
 
   
   
+-100
 100
 1
 10
   
   
+-100
 100
 1
 10
   
   
+-100
 100
 1
 10

[Libreoffice-commits] core.git: cui/uiconfig

[Regina Henschel (via logerrit)]

 cui/uiconfig/ui/connectortabpage.ui |3 +++
 1 file changed, 3 insertions(+)

New commits:
commit 6c32d052011132e891dab3254bf2a2ea6f31e888
Author: Regina Henschel 
AuthorDate: Mon Oct 9 13:31:06 2023 +0200
Commit: Regina Henschel 
CommitDate: Wed Oct 18 14:36:55 2023 +0200

tdf#132605 Negative skew values in connector dialog

The skew values of a standard connector can have negative values.
Those are possible in ODF, rendered in LO and produced by dragging the
handles. Only the dialog restricts the metric field to non negative
values. The patch allows negative values now.

Change-Id: I5174dccc1ed0ed8644e0f62a5d599eea4d5cdbaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157700
Tested-by: Jenkins
Reviewed-by: Heiko Tietze 

diff --git a/cui/uiconfig/ui/connectortabpage.ui 
b/cui/uiconfig/ui/connectortabpage.ui
index a2f6aadf3e03..d82e643f4629 100644
--- a/cui/uiconfig/ui/connectortabpage.ui
+++ b/cui/uiconfig/ui/connectortabpage.ui
@@ -3,16 +3,19 @@
 
   
   
+-100
 100
 1
 10
   
   
+-100
 100
 1
 10
   
   
+-100
 100
 1
 10

Re: How to use string constants with std::map

[Regina Henschel]

Hi Stephan,

thank you for the quick answer. Generating the longer u"cd4"_ustr for 
example is no problem in XSLT. So I will likely go with that.


The hint about "not constexpr-ready" is helpful too. I have indeed 
thought about whether to use it.


Kind regards,
Regina

Stephan Bergmann schrieb am 11.10.2023 um 20:14:

On 10/11/23 19:24, Regina Henschel wrote:
How to write the map? In the past it would have been something like 
the following:


static const std::map> 
aConnectionSiteAngleMap{

 {"accentBorderCallout1",{"0","cd4","cd2","3cd4"}},
...
 {"wedgeRoundRectCallout",{"3cd4","cd2","cd4","0","cd4"}}
};

All strings are constants and neither the map nor the strings will 
ever change.


How do I have to write it now?


You can keep writing it as above, or your could write it as


static const std::map>
aConnectionSiteAngleMap{
 
{u"accentBorderCallout1"_ustr,{u"0"_ustr,u"cd4"_ustr,u"cd2"_ustr,u"3cd4"_ustr}}, 


...
 
{u"wedgeRoundRectCallout"_ustr,{u"3cd4"_ustr,u"cd2"_ustr,u"cd4"_ustr,u"0"_ustr,u"cd4"_ustr}} 


};


which is a bit more efficient as it doesn't need to construct the 
OUString instances it runtime (but it still needs to construct the 
std::vector and std::map instances at runtime).


(You can't write it as


static constexpr std::map>
aConnectionSiteAngleMap{
 
{u"accentBorderCallout1"_ustr,{u"0"_ustr,u"cd4"_ustr,u"cd2"_ustr,u"3cd4"_ustr}}, 


...
 
{u"wedgeRoundRectCallout"_ustr,{u"3cd4"_ustr,u"cd2"_ustr,u"cd4"_ustr,u"0"_ustr,u"cd4"_ustr}} 


};


as std::map is not constexpr-ready in C++20, and neither is std::vector 
in some standard library implementations, like in debug-mode libstdc++.)

How to use string constants with std::map

[Regina Henschel]

Hi all,

For import from OOXML, I need a map which has the shape preset type 
string as key and a vector of the angle strings of the cxn elements of 
that shape as value. I will extract this information from 
presetShapeDefinitions.xml file using XSLT. The map has total 187 rows.


How to write the map? In the past it would have been something like the 
following:


static const std::map> 
aConnectionSiteAngleMap{

{"accentBorderCallout1",{"0","cd4","cd2","3cd4"}},
...
{"wedgeRoundRectCallout",{"3cd4","cd2","cd4","0","cd4"}}
};

All strings are constants and neither the map nor the strings will ever 
change.


How do I have to write it now?

Kind regards,
Regina

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 04.10.2023 um 10:04:

Hi Regina,

On Mon, Jul 31, 2023 at 06:09:31PM +0200, Regina Henschel 
 wrote:

I think it is all clear now. But I'll need some time to put it into a
proposal.


Thanks a lot. Please let me know when there is a proposal, I would like
to link to it from our extension schema.


Yes, of cause. However, the task has moved further down on my ToDo list, 
because at the moment the things needed for the upcoming ODF 1.4 have 
priority.




Something else: do you have a preferred name for the XML attribute that
decides if the wrap should be only on the last page or on all pages?
Something like text:wrap-on-all-pages="", defaulting to false?


No, I have no preferred name. However, I would prefer a "style" prefix 
to have it similar to the existing attribute 
"style:number-wrapped-paragraphs" (20.326 ODF 1.3) and other wrap 
related attributes. So I suggest "style:wrap-on-all-pages".


Kind regards,
Regina

[Libreoffice-commits] core.git: Branch 'libreoffice-7-5' - oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/tdf156902_GlowOnGroup.docx |binary
 oox/qa/unit/shape.cxx   |   12 
 oox/source/drawingml/shape.cxx  |3 ++-
 3 files changed, 14 insertions(+), 1 deletion(-)

New commits:
commit db0d583237a58becd245ee7e715827ecd6f72091
Author: Regina Henschel 
AuthorDate: Sat Oct 7 17:37:46 2023 +0200
Commit: Xisco Fauli 
CommitDate: Mon Oct 9 16:40:43 2023 +0200

tdf#156902 Do not set glow on group shape in import

Currently a group is not able to use glow. But in MS Office it is
possible. When we try to set glow at the group, we produce an
exception and no children are imported. So for now the patch prevents
setting glow.

Change-Id: Ifa7245ebf3c38f8685239c2b62eefccd35aab870
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157679
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit e84ae94270f0f0037fa2662a5f2765b37a50c33e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157711
Reviewed-by: Michael Stahl 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157702

diff --git a/oox/qa/unit/data/tdf156902_GlowOnGroup.docx 
b/oox/qa/unit/data/tdf156902_GlowOnGroup.docx
new file mode 100644
index ..0c176eefa025
Binary files /dev/null and b/oox/qa/unit/data/tdf156902_GlowOnGroup.docx differ
diff --git a/oox/qa/unit/shape.cxx b/oox/qa/unit/shape.cxx
index 21261dc39930..147e0ac88c99 100644
--- a/oox/qa/unit/shape.cxx
+++ b/oox/qa/unit/shape.cxx
@@ -313,6 +313,18 @@ CPPUNIT_TEST_FIXTURE(OoxShapeTest, 
testTdf54095_SmartArtThemeTextColor)
 }
 }
 
+CPPUNIT_TEST_FIXTURE(OoxShapeTest, testGlowOnGroup)
+{
+// The document contains a group of two shapes. A glow-effect is set on 
the group.
+// Without the fix, the children of the group were not imported at all.
+loadFromURL(u"tdf156902_GlowOnGroup.docx");
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference 
xDrawPage(xDrawPagesSupplier->getDrawPages()->getByIndex(0),
+ uno::UNO_QUERY);
+uno::Reference xGroup(xDrawPage->getByIndex(0), 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(2), xGroup->getCount());
+}
+
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/oox/source/drawingml/shape.cxx b/oox/source/drawingml/shape.cxx
index 4e4836fdf8b4..632b24d59c42 100644
--- a/oox/source/drawingml/shape.cxx
+++ b/oox/source/drawingml/shape.cxx
@@ -2026,7 +2026,8 @@ Reference< XShape > const & Shape::createAndInsert(
 }
 
 // Set glow effect properties
-if ( aEffectProperties.maGlow.moGlowRad.has_value() )
+if (aEffectProperties.maGlow.moGlowRad.has_value()
+&& aServiceName != "com.sun.star.drawing.GroupShape")
 {
 uno::Reference propertySet (mxShape, 
uno::UNO_QUERY);
 propertySet->setPropertyValue("GlowEffectRadius", 
Any(convertEmuToHmm(aEffectProperties.maGlow.moGlowRad.value(;

[Libreoffice-commits] core.git: Branch 'libreoffice-7-6' - oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/tdf156902_GlowOnGroup.docx |binary
 oox/qa/unit/shape.cxx   |   12 
 oox/source/drawingml/shape.cxx  |3 ++-
 3 files changed, 14 insertions(+), 1 deletion(-)

New commits:
commit 18beb9a0bb64ba79f65eb67637b0f3750299d705
Author: Regina Henschel 
AuthorDate: Sat Oct 7 17:37:46 2023 +0200
Commit: Xisco Fauli 
CommitDate: Mon Oct 9 13:55:57 2023 +0200

tdf#156902 Do not set glow on group shape in import

Currently a group is not able to use glow. But in MS Office it is
possible. When we try to set glow at the group, we produce an
exception and no children are imported. So for now the patch prevents
setting glow.

Change-Id: Ifa7245ebf3c38f8685239c2b62eefccd35aab870
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157679
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit e84ae94270f0f0037fa2662a5f2765b37a50c33e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157711
Reviewed-by: Michael Stahl 

diff --git a/oox/qa/unit/data/tdf156902_GlowOnGroup.docx 
b/oox/qa/unit/data/tdf156902_GlowOnGroup.docx
new file mode 100644
index ..0c176eefa025
Binary files /dev/null and b/oox/qa/unit/data/tdf156902_GlowOnGroup.docx differ
diff --git a/oox/qa/unit/shape.cxx b/oox/qa/unit/shape.cxx
index 54c19b7aeee5..4db45f7451be 100644
--- a/oox/qa/unit/shape.cxx
+++ b/oox/qa/unit/shape.cxx
@@ -819,6 +819,18 @@ CPPUNIT_TEST_FIXTURE(OoxShapeTest, testWordArtDefaultColor)
 
 CPPUNIT_ASSERT_EQUAL(uno::Any(Color(3, 74, 144)), 
xShapeProps->getPropertyValue(u"FillColor"));
 }
+
+CPPUNIT_TEST_FIXTURE(OoxShapeTest, testGlowOnGroup)
+{
+// The document contains a group of two shapes. A glow-effect is set on 
the group.
+// Without the fix, the children of the group were not imported at all.
+loadFromURL(u"tdf156902_GlowOnGroup.docx");
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference 
xDrawPage(xDrawPagesSupplier->getDrawPages()->getByIndex(0),
+ uno::UNO_QUERY);
+uno::Reference xGroup(xDrawPage->getByIndex(0), 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(2), xGroup->getCount());
+}
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/oox/source/drawingml/shape.cxx b/oox/source/drawingml/shape.cxx
index bf87841a2c9b..78b50294d356 100644
--- a/oox/source/drawingml/shape.cxx
+++ b/oox/source/drawingml/shape.cxx
@@ -1914,7 +1914,8 @@ Reference< XShape > const & Shape::createAndInsert(
 }
 
 // Set glow effect properties
-if ( aEffectProperties.maGlow.moGlowRad.has_value() )
+if (aEffectProperties.maGlow.moGlowRad.has_value()
+&& aServiceName != "com.sun.star.drawing.GroupShape")
 {
 uno::Reference propertySet (mxShape, 
uno::UNO_QUERY);
 propertySet->setPropertyValue("GlowEffectRadius", 
Any(convertEmuToHmm(aEffectProperties.maGlow.moGlowRad.value(;

[Libreoffice-commits] core.git: oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/tdf156902_GlowOnGroup.docx |binary
 oox/qa/unit/shape.cxx   |   12 
 oox/source/drawingml/shape.cxx  |3 ++-
 3 files changed, 14 insertions(+), 1 deletion(-)

New commits:
commit e84ae94270f0f0037fa2662a5f2765b37a50c33e
Author: Regina Henschel 
AuthorDate: Sat Oct 7 17:37:46 2023 +0200
Commit: Regina Henschel 
CommitDate: Sat Oct 7 21:52:48 2023 +0200

tdf#156902 Do not set glow on group shape in import

Currently a group is not able to use glow. But in MS Office it is
possible. When we try to set glow at the group, we produce an
exception and no children are imported. So for now the patch prevents
setting glow.

Change-Id: Ifa7245ebf3c38f8685239c2b62eefccd35aab870
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157679
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/qa/unit/data/tdf156902_GlowOnGroup.docx 
b/oox/qa/unit/data/tdf156902_GlowOnGroup.docx
new file mode 100644
index ..0c176eefa025
Binary files /dev/null and b/oox/qa/unit/data/tdf156902_GlowOnGroup.docx differ
diff --git a/oox/qa/unit/shape.cxx b/oox/qa/unit/shape.cxx
index 565ac39b52ad..5033ed660e30 100644
--- a/oox/qa/unit/shape.cxx
+++ b/oox/qa/unit/shape.cxx
@@ -817,6 +817,18 @@ CPPUNIT_TEST_FIXTURE(OoxShapeTest, testWordArtDefaultColor)
 CPPUNIT_ASSERT_EQUAL(uno::Any(Color(3, 74, 144)),
  xShapeProps->getPropertyValue(u"FillColor"_ustr));
 }
+
+CPPUNIT_TEST_FIXTURE(OoxShapeTest, testGlowOnGroup)
+{
+// The document contains a group of two shapes. A glow-effect is set on 
the group.
+// Without the fix, the children of the group were not imported at all.
+loadFromURL(u"tdf156902_GlowOnGroup.docx");
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference 
xDrawPage(xDrawPagesSupplier->getDrawPages()->getByIndex(0),
+ uno::UNO_QUERY);
+uno::Reference xGroup(xDrawPage->getByIndex(0), 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_EQUAL(sal_Int32(2), xGroup->getCount());
+}
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/oox/source/drawingml/shape.cxx b/oox/source/drawingml/shape.cxx
index 03a22dc441b4..f48b4d856a4a 100644
--- a/oox/source/drawingml/shape.cxx
+++ b/oox/source/drawingml/shape.cxx
@@ -1914,7 +1914,8 @@ Reference< XShape > const & Shape::createAndInsert(
 }
 
 // Set glow effect properties
-if ( aEffectProperties.maGlow.moGlowRad.has_value() )
+if (aEffectProperties.maGlow.moGlowRad.has_value()
+&& aServiceName != "com.sun.star.drawing.GroupShape")
 {
 uno::Reference propertySet (mxShape, 
uno::UNO_QUERY);
 propertySet->setPropertyValue("GlowEffectRadius", 
Any(convertEmuToHmm(aEffectProperties.maGlow.moGlowRad.value(;

[Libreoffice-commits] core.git: Branch 'libreoffice-7-5' - oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/tdf157289_circularArrow_export.fodp |  816 +++
 oox/qa/unit/export.cxx   |   14 
 oox/source/export/drawingml.cxx  |4 
 3 files changed, 832 insertions(+), 2 deletions(-)

New commits:
commit bd17f560a4262c064464cf0b649f537a36bbf2f5
Author: Regina Henschel 
AuthorDate: Tue Oct 3 21:16:59 2023 +0200
Commit: Xisco Fauli 
CommitDate: Thu Oct 5 12:55:13 2023 +0200

tdf#157289 normalize ellipse bounding box in oox export

The predefined geometry of a circular arrow shape has bottom-right
vertex first and then top-left vertex of the bounding box of the
ellipse. We now use the normalized rectangle to calculate the radii of
the ellipse. Before this patch the calculation had resulted in negative
radii.

Because the ODF standard only states, '(x1, y1) and (x2, y2) define the
bounding box of an ellipse.', but not which vertices to use, the fix is
not made in changing the geometry of the circular arrow. Instead the
export is changed to use the normalized rectangle. That is more general
and will cover other shape types too. Especially non-primivite shapes
might use other vertices than top-left and bottom-right to determine
the ellipse.

Change-Id: Ica859c9adc508a6517e30f111cd54518ec9929a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157526
Tested-by: Jenkins
Reviewed-by: Regina Henschel 
(cherry picked from commit 10c7bc0c824697b92c22bddacd739de9127dc80e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157534
Reviewed-by: Xisco Fauli 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157586

diff --git a/oox/qa/unit/data/tdf157289_circularArrow_export.fodp 
b/oox/qa/unit/data/tdf157289_circularArrow_export.fodp
new file mode 100644
index ..5a60c12f0d51
--- /dev/null
+++ b/oox/qa/unit/data/tdf157289_circularArrow_export.fodp
@@ -0,0 +1,816 @@
+
+
+http://openoffice.org/2004/office; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:ooow="http://openoffice.org/200
 4/writer" xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; xmlns
 :css3t="http://www.w3.org/TR/css3-text/; 
xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" 
xmlns:smil="urn:oasis:names:tc:opendocument:xmlns:smil-compatible:1.0" 
xmlns:anim="urn:oasis:names:tc:opendocument:xmlns:animation:1.0" 
xmlns:officeooo="http://openoffice.org/2009/office; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.presentation">
+ Regina 
Henschel2023-10-03T19:35:53.891002023-10-03T19:51:14.40300Regina
 
HenschelPT8M25S2LODev_27_Sep/24.2.0.0.alpha0$Windows_X86_64
 
LibreOffice_project/2902ab24ecc5ffbf4907ea83b2028508b9de6364
+ 
+  
+   -7708
+   -7628
+   25739
+   15092
+   
+
+ view1
+ false
+ false
+ false
+ tru

[Libreoffice-commits] core.git: oox/qa oox/source

[Regina Henschel (via logerrit)]

 oox/qa/unit/data/tdf157289_circularArrow_export.fodp |  816 +++
 oox/qa/unit/export.cxx   |   14 
 oox/source/export/drawingml.cxx  |4 
 3 files changed, 832 insertions(+), 2 deletions(-)

New commits:
commit 10c7bc0c824697b92c22bddacd739de9127dc80e
Author: Regina Henschel 
AuthorDate: Tue Oct 3 21:16:59 2023 +0200
Commit: Regina Henschel 
CommitDate: Wed Oct 4 09:56:18 2023 +0200

tdf#157289 normalize ellipse bounding box in oox export

The predefined geometry of a circular arrow shape has bottom-right
vertex first and then top-left vertex of the bounding box of the
ellipse. We now use the normalized rectangle to calculate the radii of
the ellipse. Before this patch the calculation had resulted in negative
radii.

Because the ODF standard only states, '(x1, y1) and (x2, y2) define the
bounding box of an ellipse.', but not which vertices to use, the fix is
not made in changing the geometry of the circular arrow. Instead the
export is changed to use the normalized rectangle. That is more general
and will cover other shape types too. Especially non-primivite shapes
might use other vertices than top-left and bottom-right to determine
the ellipse.

Change-Id: Ica859c9adc508a6517e30f111cd54518ec9929a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157526
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/oox/qa/unit/data/tdf157289_circularArrow_export.fodp 
b/oox/qa/unit/data/tdf157289_circularArrow_export.fodp
new file mode 100644
index ..5a60c12f0d51
--- /dev/null
+++ b/oox/qa/unit/data/tdf157289_circularArrow_export.fodp
@@ -0,0 +1,816 @@
+
+
+http://openoffice.org/2004/office; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:ooow="http://openoffice.org/200
 4/writer" xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; xmlns
 :css3t="http://www.w3.org/TR/css3-text/; 
xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" 
xmlns:smil="urn:oasis:names:tc:opendocument:xmlns:smil-compatible:1.0" 
xmlns:anim="urn:oasis:names:tc:opendocument:xmlns:animation:1.0" 
xmlns:officeooo="http://openoffice.org/2009/office; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.presentation">
+ Regina 
Henschel2023-10-03T19:35:53.891002023-10-03T19:51:14.40300Regina
 
HenschelPT8M25S2LODev_27_Sep/24.2.0.0.alpha0$Windows_X86_64
 
LibreOffice_project/2902ab24ecc5ffbf4907ea83b2028508b9de6364
+ 
+  
+   -7708
+   -7628
+   25739
+   15092
+   
+
+ view1
+ false
+ false
+ false
+ true
+ true
+ true
+ false
+ true
+ true
+ 1500
+ false
+ Hw==
+ Hw==
+ 
+ false
+ true
+ true
+ 0
+ 0
+ false
+ tr

[Libreoffice-commits] core.git: sd/qa svx/CppunitTest_svx_unit.mk svx/qa svx/source

[Regina Henschel (via logerrit)]

 sd/qa/unit/data/xml/shapes-test_page1.xml   |1 
 svx/CppunitTest_svx_unit.mk |1 
 svx/qa/unit/data/tdf157543_5PointStar.ppt   |binary
 svx/qa/unit/gluepointTest.cxx   |  110 
 svx/source/customshapes/EnhancedCustomShapeGeometry.cxx |7 -
 5 files changed, 118 insertions(+), 1 deletion(-)

New commits:
commit dd7fc07f83416a3d8a444947b7d28f7347520d6a
Author: Regina Henschel 
AuthorDate: Sun Oct 1 14:47:09 2023 +0200
Commit: Regina Henschel 
CommitDate: Mon Oct 2 16:23:26 2023 +0200

tdf#157543 Add glue points to binary 5-point star

The patch adds the glue points defined in 'Microsoft Office Drawing
97-2007 Binary Format Specification' to our corresponding preset
'msoStar'.

This star shape is contained on page 1 in odp/shapes-test.odp. It had
previously no glue points, but now it has five glue points. Thus I have
updated the xml dump.

Import from pptx is still broken, tracked in tdf#157216.

Change-Id: Ifc9f28118fe23a3d37af0357b72bb23eeef6b894
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157446
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/sd/qa/unit/data/xml/shapes-test_page1.xml 
b/sd/qa/unit/data/xml/shapes-test_page1.xml
index b5d97b55888a..344342bc4ac4 100644
--- a/sd/qa/unit/data/xml/shapes-test_page1.xml
+++ b/sd/qa/unit/data/xml/shapes-test_page1.xml
@@ -314,6 +314,7 @@

   
  
+ 
 


diff --git a/svx/CppunitTest_svx_unit.mk b/svx/CppunitTest_svx_unit.mk
index a46aa5b0d583..95c76b2d0733 100644
--- a/svx/CppunitTest_svx_unit.mk
+++ b/svx/CppunitTest_svx_unit.mk
@@ -26,6 +26,7 @@ $(eval $(call gb_CppunitTest_add_exception_objects,svx_unit, \
svx/qa/unit/svdraw/test_SdrTextObject \
svx/qa/unit/customshapes \
 svx/qa/unit/classicshapes \
+svx/qa/unit/gluepointTest \
svx/qa/unit/sdr \
svx/qa/unit/svdraw \
svx/qa/unit/table \
diff --git a/svx/qa/unit/data/tdf157543_5PointStar.ppt 
b/svx/qa/unit/data/tdf157543_5PointStar.ppt
new file mode 100644
index ..f39b24e06599
Binary files /dev/null and b/svx/qa/unit/data/tdf157543_5PointStar.ppt differ
diff --git a/svx/qa/unit/gluepointTest.cxx b/svx/qa/unit/gluepointTest.cxx
new file mode 100644
index ..647f555b8095
--- /dev/null
+++ b/svx/qa/unit/gluepointTest.cxx
@@ -0,0 +1,110 @@
+/* -*- 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 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using namespace ::com::sun::star;
+
+namespace
+{
+/// Tests related to glue points defined in the custom shape geometry.
+class GluePointTest : public UnoApiTest
+{
+public:
+GluePointTest()
+: UnoApiTest("svx/qa/unit/data/")
+{
+}
+
+protected:
+// get shape nShapeIndex from page 0
+uno::Reference getShape(sal_uInt8 nShapeIndex);
+};
+
+uno::Reference GluePointTest::getShape(sal_uInt8 nShapeIndex)
+{
+uno::Reference xDrawPagesSupplier(mxComponent,
+   
uno::UNO_QUERY_THROW);
+CPPUNIT_ASSERT_MESSAGE("Could not get XDrawPagesSupplier", 
xDrawPagesSupplier.is());
+uno::Reference 
xDrawPages(xDrawPagesSupplier->getDrawPages());
+uno::Reference xDrawPage(xDrawPages->getByIndex(0), 
uno::UNO_QUERY_THROW);
+CPPUNIT_ASSERT_MESSAGE("Could not get xDrawPage", xDrawPage.is());
+uno::Reference xShape(xDrawPage->getByIndex(nShapeIndex), 
uno::UNO_QUERY);
+CPPUNIT_ASSERT_MESSAGE("Could not get xShape", xShape.is());
+return xShape;
+}
+
+// Glue points from custom shape geometry. Values are relative to viewBox.
+// Usable if values are constant and not calculated by formula.
+bool lcl_getGeometryGluePoints(
+uno::Sequence& rGluePoints,
+const uno::Reference& xShape)
+{
+uno::Reference xShapeProps(xShape, 
uno::UNO_QUERY_THROW);
+uno::Any anotherAny = xShapeProps->getPropertyValue("CustomShapeGeometry");
+uno::Sequence aCustomShapeGeometry;
+if (!(anotherAny >>= aCustomShapeGeometry))
+return false;
+uno::Sequence aPathProps;
+for (beans::PropertyValue const& rProp : 
std::as_const(aCustomShapeGeometry))
+{
+if (rProp.Name == "Path")
+{
+rProp.Value >>= aPathProps;
+break;
+}
+}
+
+for (beans::PropertyValue const& rProp : std::as_const(aPathProps))
+{
+if (rProp.Name == "GluePoints")
+{
+ 

Re: [Libreoffice-qa] ESC meeting agenda: 2023-09-28 16:00 CEST

[Regina Henschel]

Hi Eyal,

Eyal Rozenberg schrieb am 27.09.2023 um 19:31:

Hello ESC,

I would like to ask you to discuss the situation with the recent CVE:
https://bugs.documentfoundation.org/show_bug.cgi?id=157231


I'm not the ESC, but please notice
https://listarchives.documentfoundation.org/www/announce/msg00392.html

Kind regards,
Regina

Import of wordprocessing canvas

[Regina Henschel]

Hello,

this is about https://gerrit.libreoffice.org/c/core/+/156629

The patch is in a state now, that you can look, what I plan to do. 
Although there are still some parts to do.
With my DML import you will get theme colors, multicolor gradients, true 
connectors and background of the canvas.


But I see principle problems:

Ink objects:
The Ink objects in MS Office use area fill of lines. Such does not exist 
in LibreOffice. The VML fallback has images for these kind of objects. 
The images are not available in DML import. Even when I import these 
freeform lines, the artistic filling is not possible.


Rotated shapes with rotated text:
The VML import uses the draw object label text and thus the text is 
rotated. My DML import uses the same import as in Writer. That means 
that text is in an associated frame and therefore cannot rotate.


So what to do? Go that way nevertheless? Give the user an option what 
kind of import he wants? Or?


Kind regards,
Regina

Suspicious element

[Regina Henschel]

Hi all,

When you have a
  draw:style-name="dp1"> ...

element,
then LibreOffice writes e.g. an element
  
   draw:fill-color="#d5ffd5">
loext:color-type="theme">

 
 

   
   
  

and an element
  
   draw:fill="solid" draw:fill-color="#d5ffd5"/>

  

LibreOffice uses only the fill properties from the "Default-background" 
element although this style is nowhere referenced. PowerPoint, 
OnlyOffice and Scribus e.g. use correctly the "dp1" style, which is 
referenced in the master-page element. (Set the fill-color to a 
different value than in "Default-background" style to test it.)


Such element "Default-background" should not exist at all for documents 
in ODF. The background of a master-page is described in the drawing-page 
style which is referenced in the draw:style-name attribute.


So a correct markup would be

  
   draw:fill="solid" draw:fill-color="#d5ffd5" draw:stroke="none">
 loext:color-type="theme">

  
  

   

The currently included style:letter-kerning="true"/> element is meaningless for backgrounds. It 
should be in a parent style element of the styles of all the placeholder 
objects on the master page, in case such default is intended.


Shouldn't we get rid of this "Default-background" style? That means, as 
first step implement to use the fill and stroke properties of the 
drawing-page-properties instead of those from the "Default-background" 
style.


Kind regards,
Regina

[Libreoffice-commits] core.git: Branch 'libreoffice-7-6' - xmloff/qa xmloff/source

[Regina Henschel (via logerrit)]

 xmloff/qa/unit/data/tdf157018_CustomTheme.fodg |  338 +
 xmloff/qa/unit/draw.cxx|   33 ++
 xmloff/source/draw/ximpstyl.cxx|7 
 3 files changed, 373 insertions(+), 5 deletions(-)

New commits:
commit f6004caf2c1f6b4935d6cb49284303ee34744919
Author: Regina Henschel 
AuthorDate: Thu Aug 31 01:15:26 2023 +0200
Commit: Xisco Fauli 
CommitDate: Fri Sep 1 14:40:05 2023 +0200

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 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156394

diff --git a/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg 
b/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg
new file mode 100644
index ..49673ca66793
--- /dev/null
+++ b/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg
@@ -0,0 +1,338 @@
+
+http://openoffice.org/2004/office; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:ooow="http://openoffice.org/200
 4/writer" xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; xmlns
 :css3t="http://www.w3.org/TR/css3-text/; 
xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" 
xmlns:smil="urn:oasis:names:tc:opendocument:xmlns:smil-compatible:1.0" 
xmlns:anim="urn:oasis:names:tc:opendocument:xmlns:animation:1.0" 
xmlns:officeooo="http://openoffice.org/2009/office; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.graphics">
+
+2023-08-29T21:49:18.19200
+PT1S
+1
+B2020/24.2.0.0.alpha0$Windows_X86_64 
LibreOffice_project/aa3eea21fcf302ef4ddbba5841037378945f9d5e
+
+
+
+
+13970
+10795
+0
+0
+
+
+view1
+false
+false
+true
+true
+false
+false
+false
+false
+true
+1500
+false
+Hw==
+Hw==
+
+false
+true
+true
+0
+0
+true
+true
+true
+4
+0
+-407
+-9321
+40625
+29064
+1270
+1270
+317
+317
+1270
+ 

[Libreoffice-commits] core.git: Branch 'libreoffice-7-6' - xmloff/qa xmloff/source

[Regina Henschel (via logerrit)]

 xmloff/qa/unit/draw.cxx |   57 
 xmloff/source/draw/sdxmlexp.cxx |5 ---
 2 files changed, 58 insertions(+), 4 deletions(-)

New commits:
commit 332c37dc19e0c0dc01258c09d2c1cfbf51840301
Author: Regina Henschel 
AuthorDate: Tue Aug 29 22:18:29 2023 +0200
Commit: Xisco Fauli 
CommitDate: Fri Sep 1 13:33:33 2023 +0200

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 
Signed-off-by: Xisco Fauli 
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156393

diff --git a/xmloff/qa/unit/draw.cxx b/xmloff/qa/unit/draw.cxx
index d71b41722783..cfb68ed0a109 100644
--- a/xmloff/qa/unit/draw.cxx
+++ b/xmloff/qa/unit/draw.cxx
@@ -668,6 +668,63 @@ CPPUNIT_TEST_FIXTURE(XmloffDrawTest, 
testTextRotationPlusPre)
 // But reload catches it.
 saveAndReload("writer8");
 }
+
+CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf156975_ThemeExport)
+{
+// It tests, that a theme is written to master page in Draw documents.
+// Without fix for tdf#156975 it was not written at all.
+// The test needs to be adapted, when themes are available in ODF.
+
+mxComponent = loadFromDesktop("private:factory/sdraw");
+// generate a theme to be sure we have got one and know the values
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference xDrawPage(
+xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
+uno::Reference 
xMasterPageProps(xDrawPage->getMasterPage(),
+ uno::UNO_QUERY);
+
+auto pTheme = std::make_shared("Custom");
+auto pColorSet = std::make_shared("My Colors");
+pColorSet->add(model::ThemeColorType::Dark1, 0x00);
+pColorSet->add(model::ThemeColorType::Light1, 0x11);
+pColorSet->add(model::ThemeColorType::Dark2, 0x002200);
+pColorSet->add(model::ThemeColorType::Light2, 0xff33ff);
+pColorSet->add(model::ThemeColorType::Accent1, 0x44);
+pColorSet->add(model::ThemeColorType::Accent2, 0x005500);
+pColorSet->add(model::ThemeColorType::Accent3, 0x66);
+pColorSet->add(model::ThemeColorType::Accent4, 0x00);
+pColorSet->add(model::ThemeColorType::Accent5, 0x880088);
+pColorSet->add(model::ThemeColorType::Accent6, 0x00);
+pColorSet->add(model::ThemeColorType::Hyperlink, 0x0a0a0a);
+pColorSet->add(model::ThemeColorType::FollowedHyperlink, 0xb0b0b0);
+pTheme->setColorSet(pColorSet);
+
+uno::Reference xTheme = model::theme::createXTheme(pTheme);
+xMasterPageProps->setPropertyValue("Theme", uno::Any(xTheme));
+
+// save as odg
+save("draw8");
+
+// and check the markup.
+xmlDocUniquePtr pXmlDoc = parseExport("styles.xml");
+static constexpr OStringLiteral sThemePath
+= "//office:master-styles/style:master-page/loext:theme";
+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);
+assertXPath(pXmlDoc, sThemeColorPath + "[3]", "name", "dark2");
+assertXPath(pXmlDoc, sThemeColorPath + "[3]", "color", "#002200");
+assertXPath(pXmlDoc, sThemeColorPath + "[9]", "name", "accent5");
+assertXPath(pXmlDoc, sThemeColorPath + "[9]", "color", "#880088");
+assertXPath(pXmlDoc, sThemeColorPath + "[12]", "name", 
"followed-hyperlink");
+assertXPath(pXmlDoc, sThemeColorPath + "[12]", "color", "#b0b0b0");
+}
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/xmloff/source/draw/sdxmlexp.cxx b/xmloff/source/draw/sdxmlexp.cxx
index 915c3e9360c0..6df6ade09d61 100644
--- a/xmloff/source/draw/sdxmlexp.cxx
+++ b/xmloff/source/draw/sdxmlexp.cxx
@@ -2301,10 +2301,7 @@ void SdXMLExport::ExportMasterStyles_()
 exportFormsElement( xMasterPage );
 
 // write optional loext:theme
-if (IsImpress())
-{
-ExportThemeElement(xMasterPage);
-}
+ExportThemeElement(xMasterPage);
 
 // write graphic objects on this master page (if any)
 if(xMasterPage.is() && xMasterPage->getCount())

[Libreoffice-commits] core.git: Branch 'distro/collabora/co-23.05' - xmloff/qa xmloff/source

[Regina Henschel (via logerrit)]

 xmloff/qa/unit/data/tdf157018_CustomTheme.fodg |  338 +
 xmloff/qa/unit/draw.cxx|   33 ++
 xmloff/source/draw/ximpstyl.cxx|7 
 3 files changed, 373 insertions(+), 5 deletions(-)

New commits:
commit 117a391d871d94070b67b3c61e8cfcd5a156f9ae
Author: Regina Henschel 
AuthorDate: Thu Aug 31 01:15:26 2023 +0200
Commit: Tomaž Vajngerl 
CommitDate: Thu Aug 31 21:59:07 2023 +0200

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 
(cherry picked from commit b8eebad5c7d9311b3007f6717e72e96634e57c05)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156370
Tested-by: Jenkins CollaboraOffice 

diff --git a/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg 
b/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg
new file mode 100644
index ..49673ca66793
--- /dev/null
+++ b/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg
@@ -0,0 +1,338 @@
+
+http://openoffice.org/2004/office; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:ooow="http://openoffice.org/200
 4/writer" xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; xmlns
 :css3t="http://www.w3.org/TR/css3-text/; 
xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" 
xmlns:smil="urn:oasis:names:tc:opendocument:xmlns:smil-compatible:1.0" 
xmlns:anim="urn:oasis:names:tc:opendocument:xmlns:animation:1.0" 
xmlns:officeooo="http://openoffice.org/2009/office; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.graphics">
+
+2023-08-29T21:49:18.19200
+PT1S
+1
+B2020/24.2.0.0.alpha0$Windows_X86_64 
LibreOffice_project/aa3eea21fcf302ef4ddbba5841037378945f9d5e
+
+
+
+
+13970
+10795
+0
+0
+
+
+view1
+false
+false
+true
+true
+false
+false
+false
+false
+true
+1500
+false
+Hw==
+Hw==
+
+false
+true
+true
+0
+0
+true
+true
+true
+4
+0
+-407
+-9321
+40625
+29064
+1270
+  

[Libreoffice-commits] core.git: xmloff/qa xmloff/source

[Regina Henschel (via logerrit)]

 xmloff/qa/unit/data/tdf157018_CustomTheme.fodg |  338 +
 xmloff/qa/unit/draw.cxx|   33 ++
 xmloff/source/draw/ximpstyl.cxx|7 
 3 files changed, 373 insertions(+), 5 deletions(-)

New commits:
commit be53bf55c44dedd9a94c74b8f7c1c222746ed23f
Author: Regina Henschel 
AuthorDate: Thu Aug 31 01:15:26 2023 +0200
Commit: Tomaž Vajngerl 
CommitDate: Thu Aug 31 18:36:47 2023 +0200

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 

diff --git a/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg 
b/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg
new file mode 100644
index ..49673ca66793
--- /dev/null
+++ b/xmloff/qa/unit/data/tdf157018_CustomTheme.fodg
@@ -0,0 +1,338 @@
+
+http://openoffice.org/2004/office; 
xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" 
xmlns:xlink="http://www.w3.org/1999/xlink; 
xmlns:config="urn:oasis:names:tc:opendocument:xmlns:config:1.0" 
xmlns:dc="http://purl.org/dc/elements/1.1/; 
xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" 
xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" 
xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" 
xmlns:rpt="http://openoffice.org/2005/report; 
xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" 
xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" 
xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" 
xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" 
xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" 
xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" 
xmlns:ooow="http://openoffice.org/200
 4/writer" xmlns:oooc="http://openoffice.org/2004/calc; 
xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" 
xmlns:xforms="http://www.w3.org/2002/xforms; 
xmlns:tableooo="http://openoffice.org/2009/table; 
xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
 xmlns:drawooo="http://openoffice.org/2010/draw; 
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0"
 xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" 
xmlns:math="http://www.w3.org/1998/Math/MathML; 
xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" 
xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" 
xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0"
 xmlns:dom="http://www.w3.org/2001/xml-events; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xmlns:xhtml="http://www.w3.org/1999/xhtml; 
xmlns:grddl="http://www.w3.org/2003/g/data-view#; xmlns
 :css3t="http://www.w3.org/TR/css3-text/; 
xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" 
xmlns:smil="urn:oasis:names:tc:opendocument:xmlns:smil-compatible:1.0" 
xmlns:anim="urn:oasis:names:tc:opendocument:xmlns:animation:1.0" 
xmlns:officeooo="http://openoffice.org/2009/office; office:version="1.3" 
office:mimetype="application/vnd.oasis.opendocument.graphics">
+
+2023-08-29T21:49:18.19200
+PT1S
+1
+B2020/24.2.0.0.alpha0$Windows_X86_64 
LibreOffice_project/aa3eea21fcf302ef4ddbba5841037378945f9d5e
+
+
+
+
+13970
+10795
+0
+0
+
+
+view1
+false
+false
+true
+true
+false
+false
+false
+false
+true
+1500
+false
+Hw==
+Hw==
+
+false
+true
+true
+0
+0
+true
+true
+true
+4
+0
+-407
+-9321
+40625
+29064
+1270
+1270
+317
+317
+1270
+4
+1270
+4
+  

[Libreoffice-commits] core.git: Branch 'distro/collabora/co-23.05' - xmloff/qa xmloff/source

[Regina Henschel (via logerrit)]

 xmloff/qa/unit/draw.cxx |   57 
 xmloff/source/draw/sdxmlexp.cxx |5 ---
 2 files changed, 58 insertions(+), 4 deletions(-)

New commits:
commit dfea87d635863251bac02183294d3bf75fa45820
Author: Regina Henschel 
AuthorDate: Tue Aug 29 22:18:29 2023 +0200
Commit: Tomaž Vajngerl 
CommitDate: Thu Aug 31 07:58:05 2023 +0200

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 
(cherry picked from commit 6cdafbe4043ac98f94feda87318db44ffebba7d2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156224
Tested-by: Jenkins CollaboraOffice 

diff --git a/xmloff/qa/unit/draw.cxx b/xmloff/qa/unit/draw.cxx
index d09f2a236156..7091cea1a8b7 100644
--- a/xmloff/qa/unit/draw.cxx
+++ b/xmloff/qa/unit/draw.cxx
@@ -726,6 +726,63 @@ CPPUNIT_TEST_FIXTURE(XmloffDrawTest, 
testTextRotationPlusPre)
 // But reload catches it.
 saveAndReload("writer8");
 }
+
+CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf156975_ThemeExport)
+{
+// It tests, that a theme is written to master page in Draw documents.
+// Without fix for tdf#156975 it was not written at all.
+// The test needs to be adapted, when themes are available in ODF.
+
+mxComponent = loadFromDesktop("private:factory/sdraw");
+// generate a theme to be sure we have got one and know the values
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference xDrawPage(
+xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
+uno::Reference 
xMasterPageProps(xDrawPage->getMasterPage(),
+ uno::UNO_QUERY);
+
+auto pTheme = std::make_shared("Custom");
+auto pColorSet = std::make_shared("My Colors");
+pColorSet->add(model::ThemeColorType::Dark1, 0x00);
+pColorSet->add(model::ThemeColorType::Light1, 0x11);
+pColorSet->add(model::ThemeColorType::Dark2, 0x002200);
+pColorSet->add(model::ThemeColorType::Light2, 0xff33ff);
+pColorSet->add(model::ThemeColorType::Accent1, 0x44);
+pColorSet->add(model::ThemeColorType::Accent2, 0x005500);
+pColorSet->add(model::ThemeColorType::Accent3, 0x66);
+pColorSet->add(model::ThemeColorType::Accent4, 0x00);
+pColorSet->add(model::ThemeColorType::Accent5, 0x880088);
+pColorSet->add(model::ThemeColorType::Accent6, 0x00);
+pColorSet->add(model::ThemeColorType::Hyperlink, 0x0a0a0a);
+pColorSet->add(model::ThemeColorType::FollowedHyperlink, 0xb0b0b0);
+pTheme->setColorSet(pColorSet);
+
+uno::Reference xTheme = model::theme::createXTheme(pTheme);
+xMasterPageProps->setPropertyValue("Theme", uno::Any(xTheme));
+
+// save as odg
+save("draw8");
+
+// and check the markup.
+xmlDocUniquePtr pXmlDoc = parseExport("styles.xml");
+static constexpr OStringLiteral sThemePath
+= "//office:master-styles/style:master-page/loext:theme";
+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);
+assertXPath(pXmlDoc, sThemeColorPath + "[3]", "name", "dark2");
+assertXPath(pXmlDoc, sThemeColorPath + "[3]", "color", "#002200");
+assertXPath(pXmlDoc, sThemeColorPath + "[9]", "name", "accent5");
+assertXPath(pXmlDoc, sThemeColorPath + "[9]", "color", "#880088");
+assertXPath(pXmlDoc, sThemeColorPath + "[12]", "name", 
"followed-hyperlink");
+assertXPath(pXmlDoc, sThemeColorPath + "[12]", "color", "#b0b0b0");
+}
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/xmloff/source/draw/sdxmlexp.cxx b/xmloff/source/draw/sdxmlexp.cxx
index a8f2deb0fcd3..4dfd2195bc49 100644
--- a/xmloff/source/draw/sdxmlexp.cxx
+++ b/xmloff/source/draw/sdxmlexp.cxx
@@ -2306,10 +2306,7 @@ void SdXMLExport::ExportMasterStyles_()
 exportFormsElement( xMasterPage );
 
 // write optional loext:theme
-if (IsImpress())
-{
-ExportThemeElement(xMasterPage);
-}
+ExportThemeElement(xMasterPage);
 
 // write graphic objects on this master page (if any)
 if(xMasterPage.is() && xMasterPage->getCount())

[Libreoffice-commits] core.git: xmloff/qa xmloff/source

[Regina Henschel (via logerrit)]

 xmloff/qa/unit/draw.cxx |   57 
 xmloff/source/draw/sdxmlexp.cxx |5 ---
 2 files changed, 58 insertions(+), 4 deletions(-)

New commits:
commit cf1cdc00e1e2d2684cfe57ac002a37c5f3d100c5
Author: Regina Henschel 
AuthorDate: Tue Aug 29 22:18:29 2023 +0200
Commit: Tomaž Vajngerl 
CommitDate: Wed Aug 30 16:02:51 2023 +0200

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 

diff --git a/xmloff/qa/unit/draw.cxx b/xmloff/qa/unit/draw.cxx
index 4daef2603a9f..18e5137307f6 100644
--- a/xmloff/qa/unit/draw.cxx
+++ b/xmloff/qa/unit/draw.cxx
@@ -719,6 +719,63 @@ CPPUNIT_TEST_FIXTURE(XmloffDrawTest, 
testTextRotationPlusPre)
 // But reload catches it.
 saveAndReload("writer8");
 }
+
+CPPUNIT_TEST_FIXTURE(XmloffDrawTest, testTdf156975_ThemeExport)
+{
+// It tests, that a theme is written to master page in Draw documents.
+// Without fix for tdf#156975 it was not written at all.
+// The test needs to be adapted, when themes are available in ODF.
+
+mxComponent = loadFromDesktop("private:factory/sdraw");
+// generate a theme to be sure we have got one and know the values
+uno::Reference 
xDrawPagesSupplier(mxComponent, uno::UNO_QUERY);
+uno::Reference xDrawPage(
+xDrawPagesSupplier->getDrawPages()->getByIndex(0), uno::UNO_QUERY);
+uno::Reference 
xMasterPageProps(xDrawPage->getMasterPage(),
+ uno::UNO_QUERY);
+
+auto pTheme = std::make_shared("Custom");
+auto pColorSet = std::make_shared("My Colors");
+pColorSet->add(model::ThemeColorType::Dark1, 0x00);
+pColorSet->add(model::ThemeColorType::Light1, 0x11);
+pColorSet->add(model::ThemeColorType::Dark2, 0x002200);
+pColorSet->add(model::ThemeColorType::Light2, 0xff33ff);
+pColorSet->add(model::ThemeColorType::Accent1, 0x44);
+pColorSet->add(model::ThemeColorType::Accent2, 0x005500);
+pColorSet->add(model::ThemeColorType::Accent3, 0x66);
+pColorSet->add(model::ThemeColorType::Accent4, 0x00);
+pColorSet->add(model::ThemeColorType::Accent5, 0x880088);
+pColorSet->add(model::ThemeColorType::Accent6, 0x00);
+pColorSet->add(model::ThemeColorType::Hyperlink, 0x0a0a0a);
+pColorSet->add(model::ThemeColorType::FollowedHyperlink, 0xb0b0b0);
+pTheme->setColorSet(pColorSet);
+
+uno::Reference xTheme = model::theme::createXTheme(pTheme);
+xMasterPageProps->setPropertyValue("Theme", uno::Any(xTheme));
+
+// save as odg
+save("draw8");
+
+// and check the markup.
+xmlDocUniquePtr pXmlDoc = parseExport("styles.xml");
+static constexpr OStringLiteral sThemePath
+= "//office:master-styles/style:master-page/loext:theme";
+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);
+assertXPath(pXmlDoc, sThemeColorPath + "[3]", "name", "dark2");
+assertXPath(pXmlDoc, sThemeColorPath + "[3]", "color", "#002200");
+assertXPath(pXmlDoc, sThemeColorPath + "[9]", "name", "accent5");
+assertXPath(pXmlDoc, sThemeColorPath + "[9]", "color", "#880088");
+assertXPath(pXmlDoc, sThemeColorPath + "[12]", "name", 
"followed-hyperlink");
+assertXPath(pXmlDoc, sThemeColorPath + "[12]", "color", "#b0b0b0");
+}
 CPPUNIT_PLUGIN_IMPLEMENT();
 
 /* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/xmloff/source/draw/sdxmlexp.cxx b/xmloff/source/draw/sdxmlexp.cxx
index 6384f8bec396..f0d7fc6c220f 100644
--- a/xmloff/source/draw/sdxmlexp.cxx
+++ b/xmloff/source/draw/sdxmlexp.cxx
@@ -2301,10 +2301,7 @@ void SdXMLExport::ExportMasterStyles_()
 exportFormsElement( xMasterPage );
 
 // write optional loext:theme
-if (IsImpress())
-{
-ExportThemeElement(xMasterPage);
-}
+ExportThemeElement(xMasterPage);
 
 // write graphic objects on this master page (if any)
 if(xMasterPage.is() && xMasterPage->getCount())

[Libreoffice-commits] core.git: basegfx/source include/basegfx slideshow/source

[Regina Henschel (via logerrit)]

 basegfx/source/polygon/b2dpolygontools.cxx  |  100 
 include/basegfx/polygon/b2dpolygontools.hxx |   19 +
 slideshow/source/engine/slideshowimpl.cxx   |   38 +++---
 3 files changed, 144 insertions(+), 13 deletions(-)

New commits:
commit 44c0f2da567b49ef8a539958a834f1bc841c2003
Author: Regina Henschel 
AuthorDate: Thu Aug 17 19:30:56 2023 +0200
Commit: Regina Henschel 
CommitDate: Thu Aug 24 17:54:46 2023 +0200

tdf#112687 Simplify polylines from slideshow annotations

Drawing with 'mouse as pen' in a slideshow creates hundreds of points.
By commit 631964a2ce1da3fbbeb53a5550c0e6728ba644aa they are at least
already combines to a polyline. The patch here now reduces the amount
of points in such polyline to a reasonable number. If at some point the
drawings in the slideshow are improved, this can be removed.

The reduction is performed using the Douglas-Peucker algorithm. I have
added the method to b2dpolygontools because I think it could be useful in
other contexts.

Change-Id: I9224ec3546d4442da8bc348aea8ce7b88fcc46dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155811
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/basegfx/source/polygon/b2dpolygontools.cxx 
b/basegfx/source/polygon/b2dpolygontools.cxx
index 900ab735a1e0..04a22df578a6 100644
--- a/basegfx/source/polygon/b2dpolygontools.cxx
+++ b/basegfx/source/polygon/b2dpolygontools.cxx
@@ -18,6 +18,7 @@
  */
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -3574,6 +3575,105 @@ namespace basegfx::utils
 }
 }
 
+B2DPolygon createSimplifiedPolygon(const B2DPolygon& rCandidate, const double 
fTolerance)
+{
+const sal_uInt32 nPointCount(rCandidate.count());
+if (nPointCount < 3 || rCandidate.areControlPointsUsed())
+return rCandidate;
+
+// The solution does not use recursion directly, since this could lead to 
a stack overflow if
+// nPointCount is very large. Instead, an own stack is used. This does not 
contain points, but
+// pairs of low and high index of a range in rCandidate. A parallel 
boolean vector is used to note
+// whether a point of rCandidate belongs to the output polygon or not.
+std::vector bIsKeptVec(nPointCount, false);
+bIsKeptVec[0] = true;
+bIsKeptVec[nPointCount - 1] = true;
+sal_uInt32 nKept = 2;
+std::stack> aUnfinishedRangesStack;
+
+// The RDP algorithm draws a straight line from the first point to the 
last point of a range.
+// Then, from the inner points of the range, the point that has the 
largest distance to the line
+// is determined. If the distance is greater than the tolerance, this 
point is kept and the lower
+// and upper sub-segments of the range are treated in the same way. If the 
distance is smaller
+// than the tolerance, none of the inner points will be kept.
+sal_uInt32 nLowIndex = 0;
+sal_uInt32 nHighIndex = nPointCount - 1;
+bool bContinue = true;
+do
+{
+bContinue = false;
+if (nHighIndex - nLowIndex < 2) // maximal two points, range is 
finished.
+{
+// continue with sibling upper range if any
+if (!aUnfinishedRangesStack.empty())
+{
+std::pair aIndexPair = 
aUnfinishedRangesStack.top();
+aUnfinishedRangesStack.pop();
+nLowIndex = aIndexPair.first;
+nHighIndex = aIndexPair.second;
+bContinue = true;
+}
+}
+else // the range needs examine the max distance
+{
+// Get maximal distance of inner points of the range to the 
straight line from start to
+// end point of the range.
+// For calculation of the distance we use the Hesse normal form of 
the straight line.
+B2DPoint aLowPoint = rCandidate.getB2DPoint(nLowIndex);
+B2DPoint aHighPoint = rCandidate.getB2DPoint(nHighIndex);
+B2DVector aNormalVec
+= basegfx::getNormalizedPerpendicular(B2DVector(aHighPoint) - 
B2DVector(aLowPoint));
+double fLineOriginDistance = 
aNormalVec.scalar(B2DVector(aLowPoint));
+double fMaxDist = 0;
+sal_uInt32 nMaxPointIndex = nLowIndex;
+for (sal_uInt32 i = nLowIndex + 1; i < nHighIndex; i++)
+{
+double fDistance
+= aNormalVec.scalar(B2DVector(rCandidate.getB2DPoint(i))) 
- fLineOriginDistance;
+if (std::fabs(fDistance) > fMaxDist)
+{
+fMaxDist = std::fabs(fDistance);
+nMaxPointIndex = i;
+}
+}
+
+if (fMaxDist >= fTolerance)
+{
+// We need to divide the current range into two sub ranges.
+bIsKeptVec[nMaxPointIndex] = true;

[Libreoffice-commits] core.git: slideshow/source

[Regina Henschel (via logerrit)]

 slideshow/source/engine/slideshowimpl.cxx |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

New commits:
commit 64121a303b5ceb3dd149215529ef8346b6d00dcd
Author: Regina Henschel 
AuthorDate: Tue Aug 15 01:09:25 2023 +0200
Commit: Caolán McNamara 
CommitDate: Tue Aug 15 09:52:30 2023 +0200

CID 1539919:  Null pointer dereferences

The problem was introduced in 631964a2ce1da3fbbeb53a5550c0e6728ba644aa
tfd#112687 Combine adjacent lines into one shape

Change-Id: I4c064a22e5fcc0040e249dbde09ee591ac2693c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155686
Tested-by: Jenkins
Tested-by: Caolán McNamara 
Reviewed-by: Caolán McNamara 

diff --git a/slideshow/source/engine/slideshowimpl.cxx 
b/slideshow/source/engine/slideshowimpl.cxx
index 33a9825e544a..81661fab215a 100644
--- a/slideshow/source/engine/slideshowimpl.cxx
+++ b/slideshow/source/engine/slideshowimpl.cxx
@@ -1445,14 +1445,16 @@ void lcl_setPropertiesToShape(const 
drawing::PointSequenceSequence& rPoints,
 aXPropSet->setPropertyValue("LineCap", uno::Any(eLC));
 
 //LineColor
-sal_uInt32 nLineColor;
-nLineColor = pCanvasPolyPoly->getRGBALineColor();
+sal_uInt32 nLineColor = 0;
+if (pCanvasPolyPoly)
+nLineColor = pCanvasPolyPoly->getRGBALineColor();
 //Transform polygon color from RRGGBBAA to AARRGGBB
 aXPropSet->setPropertyValue("LineColor", 
uno::Any(RGBAColor2UnoColor(nLineColor)));
 
 //LineWidth
-double  fLineWidth;
-fLineWidth = pCanvasPolyPoly->getStrokeWidth();
+double  fLineWidth = 0;
+if (pCanvasPolyPoly)
+fLineWidth = pCanvasPolyPoly->getStrokeWidth();
 aXPropSet->setPropertyValue("LineWidth", 
uno::Any(static_cast(fLineWidth)));
 }
 
@@ -1509,7 +1511,7 @@ void SlideShowImpl::registerUserPaintPolygons( const 
uno::Reference< lang::XMult
 // We collect these points into one B2DPolygon and use that to 
generate the shape on the
 // slide.
 ::basegfx::B2DPolygon aDrawingPoints;
-cppcanvas::PolyPolygonSharedPtr pFirstPolyPoly; // for style properties
+cppcanvas::PolyPolygonSharedPtr pFirstPolyPoly = aPolygons.front(); // 
for style properties
 for( const auto& pPolyPoly : aPolygons )
 {
 // Actually, each item in aPolygons has two points, but wrapped in 
a cppcanvas::PopyPolygon.

Re: Enhancement request for Bugzilla

[Regina Henschel]

Hi Xisco,

Xisco Fauli schrieb am 14.08.2023 um 12:07:

Hello Regina,

I downloaded the attachment from one of your reports 
 with 
mimetype "application/zip" and created a new ticket attaching the same 
document without modifying it 
 and the 
document is identified as 
application/vnd.openxmlformats-officedocument.presentationml.presentation)


I'm wondering whether it's related to the browser used, in my case it's 
Firefox 102


I have tested it on your new created ticket. And indeed, it depends on 
browser. With Seamonkey the attachment is "application/zip", with Chrome 
it is the correct 
"application/vnd.openxmlformats-officedocument.presentationml.presentation"


Kind regards,
Regina

[Libreoffice-commits] core.git: slideshow/source

[Regina Henschel (via logerrit)]

 slideshow/source/engine/slideshowimpl.cxx |  148 --
 1 file changed, 103 insertions(+), 45 deletions(-)

New commits:
commit 631964a2ce1da3fbbeb53a5550c0e6728ba644aa
Author: Regina Henschel 
AuthorDate: Sat Aug 12 22:57:31 2023 +0200
Commit: Regina Henschel 
CommitDate: Sun Aug 13 14:57:02 2023 +0200

tfd#112687 Combine adjacent lines into one shape

When the user makes a 'mouse as pen' drawing in slideshow, then each
mouse drag step generates a separate, very short two-point line. When
the drawings were made persistent, from each of this mini lines an
individual shape was created.

Now lines, were the end point of one line equals the start point of
the next line, were combined to a polyline. That way a drawing, which
was drawn with one mouse drag, becomes one shape now.

This does not solve, that too many of such mini lines were generated.
But it makes it easier to handle them in edit mode.

Change-Id: I8662831f309b201c049844a613877190ca0da5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155643
Tested-by: Jenkins
Reviewed-by: Regina Henschel 

diff --git a/slideshow/source/engine/slideshowimpl.cxx 
b/slideshow/source/engine/slideshowimpl.cxx
index f02647097ea8..f681dc2a9559 100644
--- a/slideshow/source/engine/slideshowimpl.cxx
+++ b/slideshow/source/engine/slideshowimpl.cxx
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1398,6 +1399,59 @@ sal_Bool SlideShowImpl::removeView(
 return true;
 }
 
+drawing::PointSequenceSequence
+lcl_createPointSequenceSequenceFromB2DPolygon(const basegfx::B2DPolygon& rPoly)
+{
+drawing::PointSequenceSequence aRetval;
+//Create only one sequence for one pen drawing.
+aRetval.realloc(1);
+// Retrieve the sequence of points from aRetval
+drawing::PointSequence* pOuterSequence = aRetval.getArray();
+// Create points in this sequence from rPoly
+pOuterSequence->realloc(rPoly.count());
+// Get these points which are in an array
+awt::Point* pInnerSequence = pOuterSequence->getArray();
+for( sal_uInt32 n = 0; n < rPoly.count(); n++ )
+{
+//Create a point from the polygon
+*pInnerSequence++ = 
awt::Point(basegfx::fround(rPoly.getB2DPoint(n).getX()),
+   
basegfx::fround(rPoly.getB2DPoint(n).getY()));
+}
+return aRetval;
+}
+
+void lcl_setPropertiesToShape(const drawing::PointSequenceSequence& rPoints,
+  const cppcanvas::PolyPolygonSharedPtr 
pCanvasPolyPoly,
+  uno::Reference< drawing::XShape >& rPolyShape)
+{
+uno::Reference< beans::XPropertySet > aXPropSet(rPolyShape, 
uno::UNO_QUERY);
+//Give the built PointSequenceSequence.
+uno::Any aParam;
+aParam <<= rPoints;
+aXPropSet->setPropertyValue("PolyPolygon", aParam);
+
+//LineStyle : SOLID by default
+drawing::LineStyle eLS;
+eLS = drawing::LineStyle_SOLID;
+aXPropSet->setPropertyValue("LineStyle", uno::Any(eLS));
+
+//LineCap : ROUND by default, same as in show mode
+drawing::LineCap eLC;
+eLC = drawing::LineCap_ROUND;
+aXPropSet->setPropertyValue("LineCap", uno::Any(eLC));
+
+//LineColor
+sal_uInt32 nLineColor;
+nLineColor = pCanvasPolyPoly->getRGBALineColor();
+//Transform polygon color from RRGGBBAA to AARRGGBB
+aXPropSet->setPropertyValue("LineColor", 
uno::Any(RGBAColor2UnoColor(nLineColor)));
+
+//LineWidth
+double  fLineWidth;
+fLineWidth = pCanvasPolyPoly->getStrokeWidth();
+aXPropSet->setPropertyValue("LineWidth", 
uno::Any(static_cast(fLineWidth)));
+}
+
 void SlideShowImpl::registerUserPaintPolygons( const uno::Reference< 
lang::XMultiServiceFactory >& xDocFactory )
 {
 //Retrieve Polygons if user ends presentation by context menu
@@ -1444,74 +1498,78 @@ void SlideShowImpl::registerUserPaintPolygons( const 
uno::Reference< lang::XMult
 PolyPolygonVector aPolygons = rPoly.second;
 //Get shapes for the slide
 css::uno::Reference< css::drawing::XShapes > Shapes = rPoly.first;
+
 //Retrieve polygons for one slide
+// #tdf112687 A pen drawing in slideshow is actually a chain of 
individual line shapes, where
+// the end point of one line shape equals the start point of the next 
line shape.
+// We collect these points into one B2DPolygon and use that to 
generate the shape on the
+// slide.
+::basegfx::B2DPolygon aDrawingPoints;
+cppcanvas::PolyPolygonSharedPtr pFirstPolyPoly; // for style properties
 for( const auto& pPolyPoly : aPolygons )
 {
+// Actually, each item in aPolygons has two points, but wrapped in 
a cppcanvas::PopyPolygon.
   

Re: Enhancement request for Bugzilla

[Regina Henschel]

Hi Xisco,

Xisco Fauli schrieb am 11.08.2023 um 23:41:

Hi Regina,

it seems to work for me. For instance, in 
https://bugs.documentfoundation.org/show_bug.cgi?id=154074 I uploaded a 
.pptx file and Bugzilla detected it as 
application/vnd.openxmlformats-officedocument.presentationml.presentation.


Could you please point to the ticket where you saw the problem you 
mentioned?


It seems to work sometimes and fails sometimes.

https://bugs.documentfoundation.org/buglist.cgi?f1=attachments.mimetype_id=1636496=changedfrom=LibreOffice_format=advanced=application%2Fzip

That means in section "Custom Search" search for "Attachment mime type" 
"changed from" "application/zip".


Kind regards,
Regina



On 10/8/23 19:33, Regina Henschel wrote:

Hi all,

I want to make an enhancement request for our Bugzilla, but where? 
Neither Bugzilla nor Redmine seem to have a suitable category.


This is my problem:
If I attach a pptx, docx, or xlsx file, the option 'auto-detect' in 
section 'Content Type' does not work. So I try option 'select from 
list', but that list has no items for the OOXML formats.


So my request is to make the 'auto-detect' able to detect OOXML 
formats or extend the list with these formats.


Kind regards,
Regina


--
Xisco Faulí
LibreOffice QA Team
IRC: x1sc0

Enhancement request for Bugzilla

[Regina Henschel]

Hi all,

I want to make an enhancement request for our Bugzilla, but where? 
Neither Bugzilla nor Redmine seem to have a suitable category.


This is my problem:
If I attach a pptx, docx, or xlsx file, the option 'auto-detect' in 
section 'Content Type' does not work. So I try option 'select from 
list', but that list has no items for the OOXML formats.


So my request is to make the 'auto-detect' able to detect OOXML formats 
or extend the list with these formats.


Kind regards,
Regina

Making gradients able to use theme colors

[Regina Henschel]

Hi Tomaž,

you have started to replace css.rendering.RGBColor by 
css.util.XComplexColor in struct ColorStop in API. I don't see how I can 
then generate a gradient as it is done in the macro example below. How 
does the macro then need to be changed?


Kind regards,
Regina

function getLongColorFromDecColor(aDecColor as 
com.sun.star.rendering.RGBColor) as long

dim nRed as integer: nRed = CInt(aDecColor.Red * 255.0)
dim nGreen as integer: nGreen = CInt(aDecColor.Green * 255.0)
dim nBlue as integer: nBlue = CInt(aDecColor.Blue * 255.0)
getLongColorFromDecColor = RGB(nRed,nGreen,nBlue)
end function

function createDecColor(nRed as integer, nGreen as integer, nBlue as 
integer) _

as com.sun.star.rendering.RGBColor
dim aNewColor as new com.sun.star.rendering.RGBColor
aNewColor.Red = nRed / 255.0
aNewColor.Green = nGreen / 255.0
aNewColor.Blue = nBlue / 255.0
createDecColor = aNewColor
end function

sub createExampleGradient _
(oGradient as com.sun.star.awt.Gradient2)
rem Creates a Gradient with three colors
'Define the colors
dim aDecStartColor as new com.sun.star.rendering.RGBColor
aDecStartColor = createDecColor(0, 192, 0)
dim aDecBetweenColor as new com.sun.star.rendering.RGBColor
aDecBetweenColor = createDecColor(255, 255, 0)
dim aDecEndColor as new com.sun.star.rendering.RGBColor
aDecEndColor = createDecColor(255, 0, 0)

'Create ColorStops array
dim aColorStops(2) as new com.sun.star.awt.ColorStop
dim aStop as new com.sun.star.awt.ColorStop
aStop.StopColor = aDecStartColor
aStop.StopOffset = 0
aColorStops(0) = aStop
aStop.StopColor = aDecBetweenColor
aStop.StopOffset = 0.6
aColorStops(1) = aStop
aStop.StopColor = aDecEndColor
aStop.StopOffset = 1
aColorStops(2) = aStop

'For start and end we need the 'long' data type in addition
dim nStartColor as long
nStartColor = getLongColorFromDecColor(aDecStartColor)
dim nEndColor as long
nEndColor = getLongColorFromDecColor(aDecEndColor)

'Create gradient
With oGradient
.ColorStops = aColorStops
.Style = com.sun.star.awt.GradientStyle.LINEAR
.StartColor = nStartColor: 'long
.EndColor = nEndColor: 'long
.Angle = 0: '1/10 degree
.Border = 0: 'percent
.XOffset = 0: 'percent
.YOffset = 0: 'percent
.StartIntensity = 100: 'percent
.EndIntensity = 100: 'percent
.StepCount = 0: '0=automatic, otherwise in range 3..255
End With
end sub

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 31.07.2023 um 09:49:
[..]

Yes, I think that's a good compromise. Do you need anything else from me
to file an OASIS proposal for these 2 attributes?


I think it is all clear now. But I'll need some time to put it into a 
proposal.


Kind regards,
Regina

How to write tender proposals

[Regina Henschel]

Hi all,

it has been discussed that the proposals for tenders need to be detailed 
enough for other developers to estimate the effort.


I have started a new section "Transition to ODF 1.4" on 
https://wiki.documentfoundation.org/Development/Budget2024.


Please have a look, whether these descriptions are OK or what I need to 
change or add.


Kind regards,
Regina

Re: tdf#156333: Implementing Text Effects

[Regina Henschel]

Hi,

sorry that you haven't got any answer so far. Please be patient, we have 
weekend and summertime with lots of vacations.


Unfortunately this is not my area, but this is, what I would do:

We have already character effects "embossed", "engrave", "outline" and 
"shadow" in the Font Effects tab of the character properties.
I would search for these terms. Besides the .ui and token-files, you 
will find some related .cxx files. I would look there, how these effects 
are implemented. "Implemented" includes model, rendering, load-save in 
ODF, import-export filter OOXML, UI. You will find then involved classes 
and methods and other relevant terms you can search.



Do you have already looked at core/README.md? It gives an overview about 
most important modules and tips for further information.


Kind regards,
Regina

владислав тараканов schrieb am 20.07.2023 um 13:52:

Hello
We, together with irgalie...@mail.ru, want to try adding support for 
various text styles (glow, tint, shadow, etc.) in Writer. But we are 
still only beginner developers, so we would like to ask where exactly in 
the code should we start fixing this problem? We've previously looked at 
the oox and sfx2 modules but didn't find anything relevant.

--
Vladislav Tarakanov

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos, hi Michael,

Miklos Vajna schrieb am 19.07.2023 um 16:15:

Hi Regina,

On Wed, Jul 19, 2023 at 02:40:26PM +0200, Regina Henschel 
 wrote:

Given that, I suggest to not use a boolean attribute in ODF, but use an
attribute with keyword values, so that all three ways can be represented.
This does not mean, that all three values need to be implemented in
LibreOffice immediately. But when there is some time later on, the missing
mode can be implemented without change to ODF.


That's certainly a possibility. I wonder if there is a use-case where
this wrapping mode would be different for different tables in the
document?


I don't know.



If you're interested in a setting similar to OOXML's
allowTextAfterFloatingTableBreak option, that would be rather
per-document, not per-table. And there is some benefit if ODF's matching
setting would be also per-document, it simplifies the job of ODF ->
OOXML filters. If that direction makes sense, then I guess this would be
rather a second boolean in settings.xml, not a 3rd value for the
proposed text:may-break-between-pages attribute.


I dislike to put such information which is essential for the layout of 
the document into the settings.xml. The settings.xml contains only 
implementation-dependent settings. I don't know whether other 
application even read it.


Perhaps we can make a compromise? Keep the text:may-break-between-pages 
as boolean attribute at the  element and add a second 
attribute to the style to describe how the text wraps around a 
 element, which spans several pages?


Thus way the "how-to-wrap" attribute can be stored in the top element of 
the styles hierarchy to have a document wide default which can be used 
for export to OOXML, but still be overwritten by the style of an 
individual frame for ODF.


I am an advocate of ODF and don't like limiting ODF to the capabilities 
of OOXML.


Kind regard,
Regina

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 19.07.2023 um 08:26:

Hi Regina,

On Tue, Jul 18, 2023 at 10:18:53PM +0200, Regina Henschel 
 wrote:

I see an additional problem with this new feature:
The text which wraps around the table leaves a large gap on the first page,
when the table increases so that it extends to the second page. I see, that
Word has this strange behavior. I have only found [*]. The answer there is a
workaround, only suitable in a final layout.
I'm afraid users will also complain to us that the text doesn't stay on the
first page. I consider the layout in Word as bug in Word.

[*] 
https://answers.microsoft.com/en-us/msoffice/forum/all/text-wrapping-around-a-tabe-in-word/eb6fa861-7c3e-4765-9405-f247f03781d3


Reading <https://bugs.documentfoundation.org/show_bug.cgi?id=61594#c33>,
there is an allowTextAfterFloatingTableBreak compat flag on the Word
side that would allow wrapping on all pages. At the moment Writer layout
assumes that this flag is off all the time. I don't see UI in Word to
enable this flag, but if I edit a DOCX file by hand, then it indeed
seems to do what you want.


Indeed, that works in Word.

Given that, I suggest to not use a boolean attribute in ODF, but use an 
attribute with keyword values, so that all three ways can be 
represented. This does not mean, that all three values need to be 
implemented in LibreOffice immediately. But when there is some time 
later on, the missing mode can be implemented without change to ODF.


Kind regards,
Regina

Re: Bringing multi-page floating tables to ODF

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 17.07.2023 um 08:51:

Hi Regina,

On Sun, Jul 16, 2023 at 07:31:22PM +0200, Regina Henschel 
 wrote:

(1) Should all types of  elements get this property?
 elements can not only contain a  child element
but also a  child element (e.g. Math, Chart) or a
 child element (OLE),  child element,
 child element (e.g. sound) or a  child element.


This is ineed interesting only for ; I could move down
the proposed attribute from  to  if you would
like that.


No, please do not move the attribute to . Such break is 
surely useful in case of a  child element too.





(2) If this new attribute is intended to be used only for floating tables,
couldn't a  child element be used instead of the very generic
 child element? That way it would be independent of any
special rules and handling for text frames and text boxes.


The tension is that on one hand, this is really about split frames, the
content is not necessarily limited to just tables. On the other hand,
I'm working on this feature mainly to be able to represent OOXML's
floating tables in ODF, so it makes sense to limit the feature set to
just table content.

I suggest that the ODF markup marks the frame/text-box as "allowed to be
split", but I keep the UI on the libreoffice side limited to table
content. I guess artifically limiting the ODF markup is not ideal.


I agree, for other content types it could be useful too, e.g. for 
 and .





(3) In the proposal, a new attribute of the  element is used.
This means that the attribute belongs to the geometry of an individual
 element. An alternative could be to put this attribute to the
style of the frame. For example, the style:overflow-behavior attribute with
its values "clip" and "auto-create-new-frame" also belongs to the style of a
text box.


My thinking was that it's unlikely somebody would want this in a frame
style, similar to e.g. "decorative".


Having it as attribute of  means, that you cannot make a 
document template that has this break enabled so that a user can enable 
"continue to next page" by simple applying a style. But not to be 
misunderstood, I am not against an attribute solution in principle.


 Also, if the attribute is moved

down to , then that doesn't seem to have a
draw:style-name attribute, so that would be always direct formatting.


(4) The interaction with the fo:max-height frame-attribute, the
draw:auto-grow-height style-attribute and the style:overflow-behavior
style-attribute is missing.


- the intention is that these frames don't limit their height (you can
   always create a next page and split), so fo:max-height is not meant to
   be used if it's OK to split

- draw:auto-grow-height=false is not meant to be used if it's OK to
   split, because the idea is to try to grow, then split if you can't
   grow further

- style:overflow-behavior: oh, I was not aware of this attribute. This
   is quite close to the one I propose, though the small (but important)
   difference is that style:overflow-behavior would create a text frame
   on the next page with the same position as the original; while a split
   frame would start at the top of the next page, to minimize the amount
   of frames necessary to present the text. Also, the dimension can be
   different on a next page, e.g. 10cm height on current page, then
   split, then 5cm height (minimum necessary) on the next page.


OK, that has to go into the description.



To sum up, I think there are some 3 options to improve the proposed
markup:

1) Move this to a frame style. This would still keep the confusing
behavior for non-text-box frames.

2) Move this to a text-box attribute (keep it as direct formatting).

3) Use style:overflow-behavior=auto-create-new-frame instead of the
proposed new attribute. This would lead to some problems regarding the
position and size of the new frame. (The split frame is intentionally
not created the way style:overflow-behavior=auto-create-new-frame wants
it.)

Do you have any preference which improvement to pick? Are you OK to go
with 2) and drop 1) & 3)?


For 3) the currently described behavior of that attribute is not usable 
and I don't like its restriction to text-box.

For 2) I don't like the restriction to text-box.

So I would go with a (A) style attribute or with (B) your original 
proposal as attribute of . Restrictions to special kind of 
child elements could be done in the descriptions in both cases.


Michael, what do you think? From the point of view of workload for 
Miklos, it would of course be best to stick with the solution with an 
attribute of .



I see an additional problem with this new feature:
The text which wraps around the table leaves a large gap on the first 
page, when the table increases so that it extends to the second page. I 
see, that Word has this strange behavior. I have only found [*]. The 
answer there is a workaround, only suitable in a final layout.
I'm afraid use

Transition of already implemented features to ODF 1.4

[Regina Henschel]

Hi all,

I'm going to add the topic "Transition of already implemented features 
to ODF 1.4" to https://wiki.documentfoundation.org/Development/Budget2024


For that the RNG schemas have to be adapted to ODF 1.4 before. Should I 
include that in the above item or should that become a separate item or 
will that be done by TDF stuff?


Kind regards,
Regina