Re: Bringing "dynamic array" to ODF
Hi all, has really no one an opinion in regard to "dynamic array"? Kind regards, Regina Regina Henschel schrieb am 24.08.2024 um 16:18: Hello everyone, It's about the Excel feature “dynamic array”, bug 127808. In the section “Non-Scalar Evaluation” (3.3, part 4) [1], ODF has rules on what to do if the actual result array has a different width or height than the target range. An adjustment of the target range to the actual result array does not occur in these rules. In order to be able to describe the “dynamic array” feature of Excel in ODF, these rules would have to be extended. In the file format, the target range is defined by the attributes table:number-matrix-columns-spanned (19.683, part 3) and table:number-matrix-rows-spanned (19.684, part 3) of the element (9.1.4, part 3). My idea is to extend the attributes of the element with a Boolean attribute table:matrix-is-dynamic. Such an attribute would not only serve as a hint for applications to allow dynamic adaption while the user is working with the opened document. It would also capture situations where the size of a database range linked to an external source changes and the spreadsheet contains expressions that use that database range. For the dynamic size of a database range, the element (9.4.15, part ) has the attribute table:on-update-keep-size (19.686, part 3). What do you think? I know, that it is also necessary to extend the formula syntax so that a dynamic range can be used as a parameter. This is bug 161399. BTW: Does anyone already have concrete plans to implement something similar to the Excel feature “dynamic array” in LibreOffice? [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/ Kind regards, Regina
MS Office writes ODF 1.4
Hi together, have you seen it? Current MS Office 365 writes formally "ODF 1.4", when it exports to ODF format. I have not investigated whether it really contains any ODF 1.4 specific things. Kind regards, Regina
Bringing "dynamic array" to ODF
Hello everyone, It's about the Excel feature “dynamic array”, bug 127808. In the section “Non-Scalar Evaluation” (3.3, part 4) [1], ODF has rules on what to do if the actual result array has a different width or height than the target range. An adjustment of the target range to the actual result array does not occur in these rules. In order to be able to describe the “dynamic array” feature of Excel in ODF, these rules would have to be extended. In the file format, the target range is defined by the attributes table:number-matrix-columns-spanned (19.683, part 3) and table:number-matrix-rows-spanned (19.684, part 3) of the element (9.1.4, part 3). My idea is to extend the attributes of the element with a Boolean attribute table:matrix-is-dynamic. Such an attribute would not only serve as a hint for applications to allow dynamic adaption while the user is working with the opened document. It would also capture situations where the size of a database range linked to an external source changes and the spreadsheet contains expressions that use that database range. For the dynamic size of a database range, the element (9.4.15, part ) has the attribute table:on-update-keep-size (19.686, part 3). What do you think? I know, that it is also necessary to extend the formula syntax so that a dynamic range can be used as a parameter. This is bug 161399. BTW: Does anyone already have concrete plans to implement something similar to the Excel feature “dynamic array” in LibreOffice? [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/ Kind regards, Regina
core.git: vcl/source
vcl/source/image/ImplImageTree.cxx |6 ++
1 file changed, 6 insertions(+)
New commits:
commit fcccd6bf9feb46feb14a07aa22de5f9ea52d394c
Author: Regina Henschel
AuthorDate: Sun Aug 18 20:50:18 2024 +0200
Commit: Regina Henschel
CommitDate: Thu Aug 22 18:12:00 2024 +0200
tdf#153421 On Windows exclude cropmarkers.svg from scaling
The file cropmarkers.svg is used to create individual crop markers.
That methods expects a certain, fixed size in unit pixel. The number of
pixels was wrong on Windows, if display scale is set so large that
resulting dpi is larger than 120.
The patch excludes this special file from scaling.
For testing you need to set display scale to larger than 125% in Windows
(125%*96dpi=120dpi). And remove any existing cropmarkers.png in
cache/themename_svg/DPI/svx/res/. 'DPI' therein is not your actual dpi
but the scaling factor from CountDPIScaleFactor.
Change-Id: I6b508e28f2f3782441ad1283cfe85c4bd1588383
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172019
Tested-by: Jenkins
Reviewed-by: Patrick Luby
Reviewed-by: Regina Henschel
diff --git a/vcl/source/image/ImplImageTree.cxx
b/vcl/source/image/ImplImageTree.cxx
index f565461f8607..e2409a8475d0 100644
--- a/vcl/source/image/ImplImageTree.cxx
+++ b/vcl/source/image/ImplImageTree.cxx
@@ -179,6 +179,12 @@ void loadImageFromStream(std::shared_ptr const &
xStream, OUString con
else if (rPath.endsWith(".svg"))
{
rParameters.mbWriteImageToCache = true; // We always want to cache a
SVG image
+#ifdef _WIN32
+ // tdf#153421. Do not scale, individual crop handles are created
from it using pixel unit.
+ if (rPath.endsWith("cropmarkers.svg"))
+ vcl::bitmap::loadFromSvg(*xStream, rPath, rParameters.mrBitmap,
1.0);
+ else
+#endif
vcl::bitmap::loadFromSvg(*xStream, rPath, rParameters.mrBitmap,
aScalePercentage / 100.0);
if (bConvertToDarkTheme)
Re: looking for tester with other OS than Windows
Hi all, thank you for your help (mail, bug comment, patch comment). It turns out that it is indeed a Windows-only bug. Kind regards, Regina Regina Henschel schrieb am 18.08.2024 um 23:02: Hi all, the patch in https://gerrit.libreoffice.org/c/core/+/172019 for tdf#153421 "On windows, the picture croping tool miss the bottom left handle when scaling higher than 100%" solves the problem for me on Windows 11. But I cannot test other operating systems. Perhaps you have some time for it? (1) The bug report does not mention, whether it is a problem for other OS than Windows at all. Is the problem there too? (2) Does the patch solves the bug on other OS than Windows (if there is a bug) and does not introduce new problems? Kind regards, Regina
looking for tester with other OS than Windows
Hi all, the patch in https://gerrit.libreoffice.org/c/core/+/172019 for tdf#153421 "On windows, the picture croping tool miss the bottom left handle when scaling higher than 100%" solves the problem for me on Windows 11. But I cannot test other operating systems. Perhaps you have some time for it? (1) The bug report does not mention, whether it is a problem for other OS than Windows at all. Is the problem there too? (2) Does the patch solves the bug on other OS than Windows (if there is a bug) and does not introduce new problems? Kind regards, Regina
Re: SheetName ::= QuotedSheetName | '$'? [^\]\. #$']+
Hi Michael, Michael Stahl schrieb am 07.08.2024 um 17:55: On 07/08/2024 17:45, Regina Henschel wrote: Hi all The rule SheetName ::= QuotedSheetName | '$'? [^\]\. #$']+ is part of section 5.8 References, part 4 ODF Kann someone please explain the alternative '$'? [^\]\. #$']+ to me? I think, '$'? means one or no character $ and [^\] means one character but not character \ But the rest? hmm i think it's an escaped ] so it means: That is it. I missed the meaning of \ as escape character. any character except ] or . or ' ' or # or $ or ' You are great! That is meaningful. Kind regards, Regina
SheetName ::= QuotedSheetName | '$'? [^\]\. #$']+
Hi all The rule SheetName ::= QuotedSheetName | '$'? [^\]\. #$']+ is part of section 5.8 References, part 4 ODF Kann someone please explain the alternative '$'? [^\]\. #$']+ to me? I think, '$'? means one or no character $ and [^\] means one character but not character \ But the rest? Kind regards, Regina
Bug 162088 - Bring database-range keywords / table structured references to ODF
Hi all, the "structured-reference" in Excel works on a "Table". You define a Table in Excel by marking a cell rectangle and use "Format as Table" in tab "Home". Then you get a new tab "Table Design" for further properties of the "Table". A "structured-reference" is something like =myData[[#Totals];[Sales]]. The import maps such "Table" to a "Database range". However a in ODF has the attribute table:orientation with values "row" and "column". Thereby "row" means that a database record is a row, which is the default. The example to XLOOKUP in the help shows how a database range in column orientation would look. The "Table" in Excel has always the orientation "row". When you create a "Database range" in LibreOffic there is no option to set the attribute "table:orientation" directly. But when you sort the "Database range" and check the option "Direction:Left to right (sort columns)", then table:orientation="column" is written to file. As far as I have tested, the implementation of "structured-reference" in LibreOffice ignores the table:orientation attribute. It evaluates the expression so as if the "Database range" has orientation "row". What to do when specifying something similar to "structured references" in ODF? I see two ways to do it: (A) Specify it so that it considers table:orientation. Then we would have to bring a note to the user, that LibreOffice has it only implemented for the case of table:orientation="row". Using them with table:orientation="column" will give invalid results. (B) Specify it so that it shall only by used if has table:orientation="row". That would mean, that in case of table:orientation="column" LibreOffice would have to produce an error if such "structured reference" is used in an expression. What do you think is better. Or do you have other ideas for the ODF standard? Kind regards, Regina
core.git: sc/source
sc/source/core/tool/compiler.cxx |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
New commits:
commit 4aa2d5ede17ddf7345804deb200983367990a7e2
Author: Regina Henschel
AuthorDate: Thu Jul 25 02:34:18 2024 +0200
Commit: Eike Rathke
CommitDate: Thu Jul 25 12:57:42 2024 +0200
Related: tdf#162093 TableRef item specifier may occur standalone
also in lexical canner.
Change-Id: Ic265bbd8a0d9baa81039b8d1748c63ad6686bfc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170989
Reviewed-by: Eike Rathke
Tested-by: Jenkins
diff --git a/sc/source/core/tool/compiler.cxx b/sc/source/core/tool/compiler.cxx
index 6b3fc6555959..28aa2c73a9c5 100644
--- a/sc/source/core/tool/compiler.cxx
+++ b/sc/source/core/tool/compiler.cxx
@@ -2311,7 +2311,8 @@ Label_MaskStateMachine:
else if( nMask & ScCharFlags::CharErrConst )
{
*pSym++ = c;
-if (!maTableRefs.empty() && maTableRefs.back().mnLevel ==
2)
+sal_uInt16 nLevel;
+if (!maTableRefs.empty() && ((nLevel =
maTableRefs.back().mnLevel) == 2 || nLevel == 1))
eState = ssGetTableRefItem;
else
eState = ssGetErrorConstant;
Re: Debugging on Visual Studio (Windows)
Hi Kira, Kira Tubo schrieb am 19.07.2024 um 04:30: [..] At the breakpoints, I get error messages that say "The breakpoint will not currently be hit. No symbols have been loaded for this document." Symbols should be loaded automatically when you open a document. Kind regards, Regina
Re: draw:image vs draw:fill-image & multiple copies
Hi David, Dr. David Alan Gilbert schrieb am 18.07.2024 um 19:37: Hi, (Context: PDF importing a weird document with thousands of identical images https://bugs.documentfoundation.org/show_bug.cgi?id=88914 ) If you insert an image into a Draw document you get a draw:frame with a draw:image inside, with the image data The picture itself is only inside the draw:image element, if you use the flat format (.fodp). Otherwise there is only a link to the image that is in a separate folder. If you duplicate that image (copy/paste), you get a second draw:frame and second draw:image with the data again. The image itself is only onetime in the folder. All copies have a link to the same image. Is there any way with draw:image not to copy the data? That would be only relevant for a document in flat format. I wondered if it was doable with a draw:image xlink:href=hmmsomething but couldn't figure out if it was possible to link back to your own images? The links are set automatically all to the same image. Nothing to do for you. But the other route is a draw:custom-shape to a style with a draw:fill-image-name to a draw:fill-image and then you can have multiple draw:custom-shape's sharing the draw:fill-image - and hopefully the style. Is there any downside to that? It depends on the kind of image, what you will do with the image and in which module you use the image. The element can contains more than one child element. That is used for example for a svg-image. These child elements have different mime-types, so that a consumer can take that one it is able to render. If a consumer is not able to render the vector graphic, it can take the bitmap, for example. That is not possible with a style with image-fill. Compared to shapes, images have specialized features: * You can adjust color/contrast/brightness/gamma/transparency without actually changing the image. * The image need not be in the document itself, but can be an external resource. * You can define an "Image Map". * You can define a "Contour Wrap". * Images have events to trigger macros. On the other hand, a custom-shape with bitmap fill can be used in 3D-mode. That allows perspective and 3-dimensional rotation. Kind regards, Regina
Re: Preparing LibreOffice for ODF 1.4
Hi all, reading you comments, I thing it is best to bring the "ODF 1.4 tender" problem to the attention of the Board. I have posted https://community.documentfoundation.org/t/tenders-for-preparing-libreoffice-for-odf-1-4/12184 Kind regards, Regina
Preparing LibreOffice for ODF 1.4
Hi, Microsoft has recently published its support for ODF 1.4. https://insider.microsoft365.com/en-us/blog/microsoft-365-apps-now-support-opendocument-format-1-4 So I think it's time to do the next steps for LibreOffice to support ODF 1.4. Some time ago I have collected all the things that need to be done. https://wiki.documentfoundation.org/Development/Budget2024#Transition_to_ODF_1.4. I hope TDF will make tenders from it. But prerequisite for tenders is, that the proposals have a "CostEstimate". Unfortunately I am not able to give such values. So please have a look and add some reasonable estimates. In addition, if you find that something is missing, or the tasks should be grouped differently, or you have other improvements for the proposal, feel free to change the proposal. Kind regards, Regina
Re: GSoC: Libreoffice Theme
Hi Sahil, Sahil Gautam schrieb am 12.07.2024 um 22:51: Hi, since I cannot use `ccache` on windows, it's taking very long to compile even a single line change in a cxx file. Any solutions? Regards Sahil Gautam See section "Partial build" in https://wiki.documentfoundation.org/Development/GenericBuildingHints Kind regards, Regina
Re: Build break in /sd/source/ui/view/drawview.cxx
Hi Michael, after applying the patch the build finishes without problems. Kind regards, Regina Michael Weghorn schrieb am 10.07.2024 um 12:05: Hi Regina, On 2024-07-09 21:48, Regina Henschel wrote: I get a build break in /sd/source/ui/view/drawview.cxx with error message C:/BuildLO/core/sd/source/ui/view/drawview.cxx(394): error C2220: the following warning is treated as an error C:\BuildLO\core\sd\source\ui\view\drawview.cxx(372) : warning C6011: Dereferencing NULL pointer 'pSheet'. : Lines: 285, 287, 289, 292, 293, 294, 313, 333, 336, 339, 341, 343, 345, 347, 349, 353, 354, 355, 369, 373, 372 I can reproduce that on Windows. This change fixes it for me: https://gerrit.libreoffice.org/c/core/+/170279 Probably related: commit 1131ccd5ace26906bbb136ff2b4d4d7aa870aa60 Date: Mon Jul 8 15:55:37 2024 +0200 StyleSheetUndoAction stylesheet param should be a reference
Build break in /sd/source/ui/view/drawview.cxx
Hi all, I get a build break in /sd/source/ui/view/drawview.cxx with error message C:/BuildLO/core/sd/source/ui/view/drawview.cxx(394): error C2220: the following warning is treated as an error C:\BuildLO\core\sd\source\ui\view\drawview.cxx(372) : warning C6011: Dereferencing NULL pointer 'pSheet'. : Lines: 285, 287, 289, 292, 293, 294, 313, 333, 336, 339, 341, 343, 345, 347, 349, 353, 354, 355, 369, 373, 372 Kind regards, Regina
core.git: include/sax sax/Library_sax.mk sax/source xmloff/qa xmloff/source
include/sax/tools/converter.hxx|8
sax/Library_sax.mk |1
sax/source/tools/converter.cxx | 50 ++
xmloff/qa/unit/data/tdf161483_CircleStartEndAngle.fodg | 397
xmloff/qa/unit/data/tdf161483_ShadowSlant.fodg | 419 +
xmloff/qa/unit/draw.cxx| 52 ++
xmloff/source/draw/ximp3dscene.cxx |6
xmloff/source/draw/ximpshap.cxx|8
8 files changed, 936 insertions(+), 5 deletions(-)
New commits:
commit 9f62c7a0f2333d1b7d179a43b3b0341dba7554a1
Author: Regina Henschel
AuthorDate: Sun Jun 23 20:24:44 2024 +0200
Commit: Regina Henschel
CommitDate: Tue Jun 25 16:21:42 2024 +0200
tdf#161483 enable LO to read ODF angle units
ODF uses in several places data type 'angle' (18.3.1, ODF 1.3). That is
a double followed by unit identifier 'deg', 'grad' or 'rad' or a unit
less value in degrees. LO uses in the API angles in degrees, 1/10 of
degrees and 1/100 of degrees in data types 'double', 'short' and 'long'.
Without the fix LO does not interpret the units, but takes only the
number part.
Change-Id: Ib3f2a518a25199e3cf7a7a8572e169785f75c427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169360
Reviewed-by: Michael Stahl
Tested-by: Jenkins
Reviewed-by: Regina Henschel
diff --git a/include/sax/tools/converter.hxx b/include/sax/tools/converter.hxx
index bb97acc595ac..e6568faffbd6 100644
--- a/include/sax/tools/converter.hxx
+++ b/include/sax/tools/converter.hxx
@@ -210,6 +210,14 @@ public:
static bool convert10thDegAngle(sal_Int16& rAngle, std::string_view
rString,
bool isWrongOOo10thDegAngle);
+/** convert SVG angle to number, in 1/nFactor of degrees, range
[0..nFactor*360[ */
+static bool convertAngle(double& rAngle, std::u16string_view rString,
+ const sal_uInt16& nFactor = 1);
+
+/** convert SVG angle to number, in 1/nFactor of degrees, range
[0..nFactor*360[ */
+static bool convertAngle(double& rAngle, std::string_view rString,
+ const sal_uInt16& nFactor = 1);
+
/** convert double to XMLSchema-2 "duration" string; negative durations
allowed */
static void convertDuration(OUStringBuffer& rBuffer,
const double fTime);
diff --git a/sax/Library_sax.mk b/sax/Library_sax.mk
index f65fcf05b669..7188041f1bf4 100644
--- a/sax/Library_sax.mk
+++ b/sax/Library_sax.mk
@@ -26,6 +26,7 @@ $(eval $(call gb_Library_use_externals,sax,\
))
$(eval $(call gb_Library_use_libraries,sax,\
+basegfx \
comphelper \
cppu \
cppuhelper \
diff --git a/sax/source/tools/converter.cxx b/sax/source/tools/converter.cxx
index bc2342d5b508..204033a7e64a 100644
--- a/sax/source/tools/converter.cxx
+++ b/sax/source/tools/converter.cxx
@@ -802,6 +802,56 @@ bool Converter::convert10thDegAngle(sal_Int16& rAngle,
std::string_view rString,
return bRet;
}
+/** convert SVG angle to number, in 1/nFactor of degrees, range
[0..nFactor*360[ */
+bool Converter::convertAngle(double& rAngle, std::u16string_view rString,
const sal_uInt16& nFactor)
+{
+// ODF uses in several places angles in data type 'angle' (18.3.1, ODF
1.3). That is a double
+// followed by unit identifier deg, grad or rad or a unitless value in
degrees. LO uses angles
+// in degrees, 1/10 of degrees and 1/100 of degrees in various data types.
+// This method converts ODF 'angle' to double considering nFactor and
normalizes it to range
+// [0..nFactor*360[. Further type converting and range restriction are
done by the caller.
+bool bRet = ::sax::Converter::convertDouble(rAngle, rString);
+if (bRet)
+{
+//degrees
+if (std::u16string_view::npos != rString.find(u"grad"))
+rAngle *= 0.9; // 360deg = 400grad
+else if (std::u16string_view::npos != rString.find(u"rad"))
+rAngle = basegfx::rad2deg(rAngle);
+// 1/nFactor of degrees in range [0..nFactor*360]
+if (nFactor > 0)
+rAngle = basegfx::snapToZeroRange(rAngle * nFactor, nFactor *
360.0);
+else
+return false;
+}
+return bRet;
+}
+
+/** convert SVG angle to number, in 1/nFactor of degrees, range
[0..nFactor*360[ */
+bool Converter::convertAngle(double& rAngle, std::string_view rString, const
sal_uInt16& nFactor)
+{
+// ODF uses in several places angles in data type 'angle' (18.3.1, ODF
1.3). That is a double
+// followed by unit identifier deg, grad or rad or a unitless value in
degrees. LO uses angles
+// in degrees, 1/10
regular expressions in XMATCH and XLOOKUP
Hi all, hi Balázs, yesterday the ODF TC had a call with guests from Microsoft, Excel experts. They told us, that they are going to implement regular expression search for XMATCH and XLOOKUP in a way that they introduce a a value "3" for parameter Match_mode. The ODF TC will follow that in the specification of these functions and at the same time specify, that the host dependent properties HOST-USE-REGULAR-EXPRESSIONS and HOST-USE-WILDCARDS (file format table:use-regular-expressions and table:use-wildcards) will be ignored by these functions. I think it is a good idea to make the function results independent from global settings. I suggest to change our implementation of XLOOKUP and XMATCH immediately. In case that will not be possible for version 24.8., add a warning to the release notes, that the functions are experimental and the exact syntax and behavior might be changed in a later version. Kind regards, Regina
XMATCH, XLOOKUP: Remove dependency to 'search-criteria-must-apply-to-whole-cell'
Hi all, hi Balázs, In current implementation of XLOOKUP and XMATCH the global setting 'search-criteria-must-apply-to-whole-cell' is evaluated in Match_mode values 0 (exact match) and 2 (wildcard or regex). And the combination of Match_mode value 0 with Search_mode 2 or -2 (binary search) is possible when 'search-criteria-must-apply-to-whole-cell' has value false. (1) I see a problem with 'search-criteria-must-apply-to-whole-cell'=false together with binary search. How could that work? If you look for "foo" for example in this mode it would be the same as if you look for "*foo*" in wildcard mode and for that binary search is not possible. It there some hidden automatically switch to linear search in place? (2) As far as I know, there exists no similar setting in Excel and evaluating the setting in LibreOffice gives interoperability problems. (3) The setting is not needed, because the intended behavior of matching a part of the cell can be archived in wildcard mode with e.g. "*foo*" and in regex mode with e.g. ".*foo.*". So my suggestion is, to take the chance when defining these _new_ functions to remove the evaluation of the global setting 'search-criteria-must-apply-to-whole-cell' and act always as if its value is true. What do you think? [Background is, that the ODF TC is currently working on the specification for these functions.] Kind regards, Regina
Listen to ESC meeting
Hi all, I wanted to listen to the ESC meeting last Thursday. I had jointed the meeting, but I could not hear anything. The test "Play a test sound" in the Jitsi UI works without problems. What might be the reason for not been able to hear anything? Kind regards, Regina
Re: Build break in current master
Hi Mike, Mike Kaganski schrieb am 14.06.2024 um 21:03: On 14.06.2024 23:47, Regina Henschel wrote: I get a build failure C:/BuildLO/core/svx/source/table/tablehtmlimporter.cxx(500): error C2220: the following warning is treated as an error C:\BuildLO\core\svx\source\table\tablehtmlimporter.cxx(446) : warning C6011: Dereferencing NULL pointer 'mpActDefault'. : Lines: 428, 429, 430, 440, 441, 443, 444, 445, 446 https://gerrit.libreoffice.org/c/core/+/168894 should fix that. thank you, that fixes the problem for me. Kind regards, Regina
Build break in current master
Hi all, in a clean debug build with last commit b39b15c639960a37ed53d82cef44e64ef58c141e, I get a build failure C:/BuildLO/core/svx/source/table/tablehtmlimporter.cxx(500): error C2220: the following warning is treated as an error C:\BuildLO\core\svx\source\table\tablehtmlimporter.cxx(446) : warning C6011: Dereferencing NULL pointer 'mpActDefault'. : Lines: 428, 429, 430, 440, 441, 443, 444, 445, 446 Kind regards, Regina
core.git: include/sax sax/source sd/qa solenv/clang-format xmloff/inc xmloff/qa xmloff/source
include/sax/tools/converter.hxx | 16 sax/source/tools/converter.cxx | 117 ++ sd/qa/unit/import-tests.cxx |8 solenv/clang-format/excludelist |2 xmloff/inc/xmlsdtypes.hxx|1 xmloff/qa/unit/data/tdf161327_HatchAngle.fodg| 404 +++ xmloff/qa/unit/data/tdf161327_LatheEndAngle.fodg | 359 xmloff/qa/unit/draw.cxx | 57 +++ xmloff/source/draw/sdpropls.cxx | 64 +++ xmloff/source/style/GradientStyle.cxx| 32 + xmloff/source/style/HatchStyle.cxx | 28 + xmloff/source/style/PageMasterPropHdlFactory.cxx |2 xmloff/source/style/TransGradientStyle.cxx | 36 +- xmloff/source/style/prhdlfac.cxx |2 xmloff/source/style/xmlbahdl.cxx |2 15 files changed, 1013 insertions(+), 117 deletions(-) New commits: commit 567dbcf68711402736f65f4a0a47ef57549fe50f Author: Regina Henschel AuthorDate: Sat Jun 1 19:50:47 2024 +0200 Commit: Regina Henschel CommitDate: Tue Jun 11 10:29:17 2024 +0200 tdf#161327 Interpret angle units in dr3d:end-angle .. .. and draw:rotation in element. ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2 it is specified as double with unit "deg", "grad" or "rad", or without unit. The unit-less value is specified to be in degrees. But OOo, AOO and all LO versions had written the value unit-less in 1/10th of a degree in some cases. To fix it, LibreOffic will be enabled to read units. When then the active versions are able to read units, starting with the then actual version, LibreOffice will write angles with unit 'deg'. This has already be done for gradients, see tdf#89475. This patch starts the first step to make LibreOffice able to read units for dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO FillHatch.Angle). I have not found further cases of writing 1/10deg. The patch still writes unit-less 1/10th of a degree for export to ODF 1.3 and earlier. When it is time to write unit degree or when LibreOffice supports the next ODF versions, some places need to be adapted. They are marked. The converter convertAngle is renamed to convert10thDegAngle() to indicate, that it is special. The parts, which were specific to gradients are moved to the gradients, so that it is now usable for dr3d:angle and draw:rotation too. I intend to write next a patch that enables LibreOffice to read angle units for cases where LibreOffice already writes unit-less values in degree. That is not so urgent, but to bring LibreOffice nearer to ODF, reading angle units should be implemented nevertheless. The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc to have access to it from xmloff/source/draw. Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336 Tested-by: Jenkins Reviewed-by: Michael Stahl Reviewed-by: Regina Henschel diff --git a/include/sax/tools/converter.hxx b/include/sax/tools/converter.hxx index d797eace3042..bb97acc595ac 100644 --- a/include/sax/tools/converter.hxx +++ b/include/sax/tools/converter.hxx @@ -199,16 +199,16 @@ public: static bool convertDouble(double& rValue, std::string_view rString); /** convert number, 10th of degrees with range [0..3600] to SVG angle */ -static void convertAngle(OUStringBuffer& rBuffer, sal_Int16 nAngle, -SvtSaveOptions::ODFSaneDefaultVersion nVersion); +static void convert10thDegAngle(OUStringBuffer& rBuffer, sal_Int16 nAngle, +const bool isWrongOOo10thDegAngle); -/** convert SVG angle to number, 10th of degrees with range [0..3600] */ -static bool convertAngle(sal_Int16& rAngle, std::u16string_view rString, -bool isWrongOOo10thDegAngle); +/** convert SVG angle to number in 10th of degrees */ +static bool convert10thDegAngle(sal_Int16& rAngle, std::u16string_view rString, +bool isWrongOOo10thDegAngle); -/** convert SVG angle to number, 10th of degrees with range [0..3600] */ -static bool convertAngle(sal_Int16& rAngle, std::string_view rString, -bool isWrongOOo10thDegAngle); +/** convert SVG angle to number in 10th of degrees */ +static bool convert10thDegAngle(sal_Int16& rAngle, std::string_view rString, +bool isWrongOOo10thDegAngle); /** convert double to XMLSchema-2 "duration" string; negative durations allowed */ static void convertDuration(OUStringBuffer& rBuffer, diff --git a/sax/source/tools/
ODF problems with 3D-objects
Hi all, hi Armin,
(A)
The UI-option "Double-Sided Illumination" (= UNO property
D3DSceneTwoSidedLighting) is mapped to ODF scene attribute
dr3d:lighting-mode (19.99.3, part 3, ODF 1.3).
Its specification is, "The dr3d:lighting-mode attribute specifies
whether lighting is used in a three-dimensional scene.".
That is not implemented in LO. Lighting is always used in LibreOffice.
Not using lighting would mean, that the fill color is not modulated but
drawn as if the object is two-dimensional.
The ODF graphic property dr3d:lighting-mode(20.86, part3, ODF 1.3) fits
neither. Its values are,
"double-sided: the front and back sides of all planes are displayed if
they are visible from the viewer's perspective."
"standard: Depending on the value of the dr3d:normals-direction 20.87
attribute, only the front or only the back side sides of the plane are
displayed. The opposite sides are not displayed, whether they are
visible from the viewer's perspective or not."
That is not about lighting, but about the visibility of object faces.
(B)
The UI-option "Invert Normals" (= UNO property D3DNormalsInvert) is
mapped to ODF graphic property dr3d:normals-direction (20.87, part 3,
ODF 1.3). Thereby the value D3DNormalsInvert=true is mapped to
dr3d:normals-direction="normal" and D3DNormalsInvert=false is mapped to
dr3d:normals-direction="invert".
For dr3d:normals-direction is specified, "The dr3d:normals-direction
attribute has no effect if the dr3d:lighting-mode 20.86 attribute has
the value double-sided". But the graphic property dr3d:lighting-mode
20.86 is not implemented in LibreOffice at all. Its value is not read
and not written.
(C)
The light position is determined by Svx3DLightControl() in the UI. It is
associated with UNO properties D3DSceneLightDirection1 to
D3DSceneLightDirection8. A position in the center in front of the sphere
in the control results in D3DSceneLightDirection1 = {DirectionX=0,
DirectionY=0, DirectionZ=1}, for example. This is mapped to ODF
attribute dr3d:direction (19.95, part 3, ODF 1.3) as dr3d:direction="(0
0 1)" for the example. The attribute dr3d:direction is specified as,
"The dr3d:direction attribute specifies the direction in which light is
emitted.".
So LO uses it as position, but for ODF it is a direction, a vector.
(D)
The UI-option "Double-Sided" (=UNO property D3DDoubleSided) is mapped to
ODF graphic property dr3d:backface-culling (20.76, part3, ODF 1.3). In
my understanding, if "backface-culling" is enabled it means, that object
polygons, which are not visible to the viewer are skipped on rendering.
In case of solid filling this would have no effect on the final result,
but only reduces the time for rendering. But in LO the effect is, that
object polygons, which are not visible because the viewer looks on the
back face, become visible when backface-culling is disabled. That
behavior would more fit to ODF dr3d:lighting-mode="double-sided" (20.86).
(E)
In my understanding, a normal determines which side of an object polygon
is the front face and which is the back face. When I assume an object
polygon is not visible because the viewer looks on the back face, then
when changing the state of "Invers Normals" those polygons which were
invisible become visible and vice versa. But that is not the case in
LibreOffice.
Is my view in (D) and (E) correct?
Do you agree, that there is a mess? And if yes, how we can fix it?
Kind regards,
Regina
core.git: svx/qa svx/source
svx/qa/unit/data/tdf128433_rectanglecontourtext_CJK.fodg | 418 +++ svx/qa/unit/data/tdf84507_polygoncontourtext.fodg| 396 ++ svx/qa/unit/svdraw.cxx | 33 + svx/source/svdraw/svdotextdecomposition.cxx | 66 ++ 4 files changed, 905 insertions(+), 8 deletions(-) New commits: commit 47664e282da4999b8e471a6a916d7ec80414ac18 Author: Regina Henschel AuthorDate: Tue May 7 23:51:24 2024 +0200 Commit: Regina Henschel CommitDate: Tue May 14 00:25:13 2024 +0200 tdf#84507 move contour text to correct place in rotated... ...path objects. I first tried to change the UnitPolyPolygon in ViewContactOfSdrPathObj::createViewIndependentPrimitive2DSequence(). But it is needed in that way to draw the geometry of the object. Now the change is made in SdrTextObj::impDecomposeContourTextPrimitive(). The basic idea is to recover the original PolyPolygon and transform it so, that the transformed text is placed into the transformed PolyPolygon. The ObjectMatrix gets a translation then, which moves the transformed text to the correct position in the PolyPolygon. For East Asian writingmode tb-rl, the text start needs to be top-right. Added that, which resolves bug 128433. If the shape has a fat stroke the text reaches into the stroke currently. I have changed the code so that now a reduced area for the text is used. The polypolygon behaves now same as the legacy rectangle. Sometimes not all text is drawn although the rotated PolyPolygon would have enought place for it. Or in other cases the text spills out of the PolyPolygon. But I don't know a solution yet. As the other changes are an improvement, this problem can be solved later. Change-Id: I951024bf0d6d992587ec9cf2ed37665f322b66fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167299 Tested-by: Jenkins Reviewed-by: Regina Henschel diff --git a/svx/qa/unit/data/tdf128433_rectanglecontourtext_CJK.fodg b/svx/qa/unit/data/tdf128433_rectanglecontourtext_CJK.fodg new file mode 100644 index ..f3ee6416183d --- /dev/null +++ b/svx/qa/unit/data/tdf128433_rectanglecontourtext_CJK.fodg @@ -0,0 +1,418 @@ + + +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=&qu
behavior of new functions XLOOKUP and XMATCH
Hi UX-experts, the new function XLOOKUP and XMATCH have a Match_mode with values 0, 1, -1, 2 and a Search_mode with values 1, -1, 2, -2. The Match_mode 2 means wildcard mode, that is ? * search or regular expressions search. The Search_modes 2 and -2 mean binary search in a sorted array. Combining parameter values for wildcard mode and binary search is possible. But there exist no way to actually do it. Excel gives an error messages in such cases. LibreOffice silently switches to linear search. The ODF TC is currently working on the specification for these new functions. The TC could either follow Excel's way or LibreOffice's way. From a developer state of view it is no large effort to change the current behavior of LibreOffice. The TC does not know yet whether Microsoft would be willing to switch to LibreOffice's behavior. I write to you for to get your opinion what will be the best solution from a _user_ point of view. Some arguments so far: * No error message would make use of the functions in macros and forms easier. * No error message might be better for using the functions in automatically calculations without UI. * Using linear search can be unexpected slow on a huge Lookup_array. An error message makes the problem visible to the user. I would love to hear your opinion. Kind regards, Regina
Which fonts are available on the build bots?
Hi all, I have a build failure in a unit test, likely because a font is not available and the replacement font has a different metric. (https://ci.libreoffice.org/job/gerrit_master_ml/17954/) Which fonts are available on all build bots? Is there a font in place, which covers "CJK Unified Ideographs"? If not, can someone give me a string with CJK characters (shorter than 16 characters) and tell me a suitable font of the build bots for that string? Kind regards, Regina
Problems with ODF and LibreOffice for 3D-scenes and 3D-objects.
Hi all, this is about ODF 19.99 dr3d:lighting-mode, 20.86 dr3d:lighting-mode, 20.87 dr3d:normals-direction and 20.76 dr3d:backface-culling, and LibreOffice D3DSceneTwoSidedLighting, D3DDoubleSided and D3DNormalsInvert. If you know them, you can skip the explanation and go down to "Problems". ODF has the scene attribute 19.99 dr3d:lighting-mode (values true/false) with meaning, "The dr3d:lighting-mode attribute specifies whether lighting is used in a three-dimensional scene." ODF has the graphic property 20.86 dr3d:lighting-mode (values double-sided/standard) for 3D-objects with meaning, "double-sided: the front and back sides of all planes are displayed if they are visible from the viewer's perspective." "standard: Depending on the value of the dr3d:normals-direction 20.87 attribute, only the front or only the back side sides of the plane are displayed. The opposite sides are not displayed, whether they are visible from the viewer's perspective or not." ODF has the graphic property 20.87 dr3d:normals-direction (values inverse/normal) for 3D-objects with meaning, "inverse: only the back sides of planes are displayed." "normal: only the front sides of planes are displayed." "This graphic property is ignored in case the dr3d:lighting-mode (20.86) has the value "double-sided". The graphic property dr3d:normals-direction is mapped to the property D3DNormalsInvert. That is icon "Invert Normals" in the UI. ODF has the graphic property 20.76 dr3d:backface-culling (values disabled/enabled) for 3D-objects with meaning, "The dr3d:backface-culling attribute specifies whether backface culling is enabled." This graphic property is mapped to the LO property D3DDoubleSided. That belongs to the icon "Double-Sided" in the UI. Problems (1) LibreOffice maps the 19.99 dr3d:lighting-mode scene attribute to the property D3DSceneTwoSidedLighting. That is icon "Double-Sided Illumination" in the UI. Actually this determines whether both front and back face are affected by the directional lights or only one of them. According ODF 19.99 dr3d:lighting-mode should turn lighting in general on or off. (2) LibreOffice ignores the graphic property 20.86 dr3d:lighting-mode on import. It is lost when you open and save a document. (3) The relationship between ODF graphic properties 20.76 dr3d:backface-culling and 20.86 dr3d:lighting-mode is unclear. (4) Turning "Double-Sided" off (=backface-culling on) and inverting the normals, does not make a back face visible. So backface-culling on/off is not a replacement for the missing 20.86 dr3d:lighting-mode. (5) The current way D3DSceneTwoSidedLighting and D3DNormalsInvert work together has no corresponding attribute or graphic property in ODF. For testing you can use the "Shell" object from the predefined 3D-shapes. A cube with an image fill with some transparency is a good test candidate too. Should ODF and LibreOffice be aligned? If yes, in what steps can this be done? Kind regards, Regina
core.git: Branch 'libreoffice-24-2' - sc/qa sc/source
sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods |binary
sc/qa/unit/scshapetest.cxx | 37 +
sc/source/core/data/table3.cxx | 78 +--
3 files changed, 109 insertions(+), 6 deletions(-)
New commits:
commit 1347274fc1cb780db4c7c9b8c0272e1730b95c04
Author: Regina Henschel
AuthorDate: Sat Apr 27 19:25:32 2024 +0200
Commit: Xisco Fauli
CommitDate: Thu May 2 19:14:20 2024 +0200
tdf#160329 update objects after row sort is finished
The problem was that when the object position was updated to the anchor
values by recalcPos() method, the document did not yet have the new
state of the hidden rows. As a result, incorrect positions were
calculated. Therefore, the update of the position is moved to a place
after the update of the visibility of the rows.
Sorting rows must not change the visibility of objects. However, updating
the visibility of rows sets all objects to visible. Now the visibility
state of an object is saved and restored later so that the recalcPos()
method receives the correct state for the object.
Change-Id: Ia32698c1d45cd81702e6d00c5dfc100f6f6f399c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166799
Reviewed-by: Noel Grandin
Tested-by: Noel Grandin
(cherry picked from commit f0a2969d15e3101d7f96a7fe77bca06a5d70f57a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166903
Tested-by: Jenkins
Reviewed-by: Xisco Fauli
diff --git a/sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods
b/sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods
new file mode 100644
index ..5ba746ad7baa
Binary files /dev/null and
b/sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods differ
diff --git a/sc/qa/unit/scshapetest.cxx b/sc/qa/unit/scshapetest.cxx
index c5b4b098c80e..2e9ed6281ce7 100644
--- a/sc/qa/unit/scshapetest.cxx
+++ b/sc/qa/unit/scshapetest.cxx
@@ -66,6 +66,14 @@ static SdrObject* lcl_getSdrObjectWithAssert(ScDocument&
rDoc, sal_uInt16 nObjNu
return pObj;
}
+static SdrObject* lcl_getSdrObjectbyName(ScDocument& rDoc, std::u16string_view
rName)
+{
+ScDrawLayer* pDrawLayer = rDoc.GetDrawLayer();
+const SdrPage* pPage = pDrawLayer->GetPage(0);
+SdrObject* pObj = pPage->GetObjByName(rName);
+return pObj;
+}
+
CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf144242_OpenBezier_noSwapWH)
{
// Shapes, which have rotation incorporated in their points, got
erroneously width-height
@@ -1299,6 +1307,35 @@ CPPUNIT_TEST_FIXTURE(ScShapeTest,
testTdf160369_groupshape)
CPPUNIT_ASSERT_RECTANGLE_EQUAL_WITH_TOLERANCE(aOrigRect, aAfterRect, 1);
}
+CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf160329_sortWithHiddenRows)
+{
+// Load a document, which has images anchored to cell and rows hidden
+createScDoc("ods/tdf160329_sortWithHiddenRows.ods");
+ScDocument* pDoc = getScDoc();
+
+// Sort the rows
+uno::Sequence aArgs1
+= { comphelper::makePropertyValue("DbName", u"myRange"_ustr) };
+dispatchCommand(mxComponent, ".uno:SelectDB", aArgs1);
+uno::Sequence aArgs2
+= { comphelper::makePropertyValue("ByRows", true),
+comphelper::makePropertyValue("HasHeader", true),
+comphelper::makePropertyValue("Col1", sal_Int32(1)),
+comphelper::makePropertyValue("Ascending1", false),
+comphelper::makePropertyValue("IncludeImages", true) };
+dispatchCommand(mxComponent, ".uno:DataSort", aArgs2);
+
+// Make sure objects are on correct position
+SdrObject* pObj = lcl_getSdrObjectbyName(*pDoc,
std::u16string_view(u"ImageD"));
+Point aPos = pObj->GetSnapRect().TopLeft();
+// The position was (3000|2899) without fix.
+CPPUNIT_ASSERT_POINT_EQUAL_WITH_TOLERANCE(Point(3000, 5898), aPos, 1);
+pObj = lcl_getSdrObjectbyName(*pDoc, std::u16string_view(u"ImageE"));
+aPos = pObj->GetSnapRect().TopLeft();
+// The position was (2600|2499) without fix.
+CPPUNIT_ASSERT_POINT_EQUAL_WITH_TOLERANCE(Point(2600, 4399), aPos, 1);
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/data/table3.cxx b/sc/source/core/data/table3.cxx
index 359cc5dcc4f5..51212966615f 100644
--- a/sc/source/core/data/table3.cxx
+++ b/sc/source/core/data/table3.cxx
@@ -1084,6 +1084,50 @@ void ScTable::SortReorderByColumn(
}
}
+static void backupObjectsVisibility(const
std::vector>& rSortedCols,
+
std::vector>>& rBackup)
+{
+size_t nSortedCols = rSortedCols.size();
+for (size_t iCol = 0; iCol < nSortedCols; ++iCol)
+{
+std::vector>& rSingleColCellDrawObjects
+= rSortedCols[iCol]->maCellDrawObjects;
+size
core.git: sc/qa sc/source
sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods |binary
sc/qa/unit/scshapetest.cxx | 37 +
sc/source/core/data/table3.cxx | 78 +--
3 files changed, 109 insertions(+), 6 deletions(-)
New commits:
commit f0a2969d15e3101d7f96a7fe77bca06a5d70f57a
Author: Regina Henschel
AuthorDate: Sat Apr 27 19:25:32 2024 +0200
Commit: Noel Grandin
CommitDate: Wed May 1 09:12:59 2024 +0200
tdf#160329 update objects after row sort is finished
The problem was that when the object position was updated to the anchor
values by recalcPos() method, the document did not yet have the new
state of the hidden rows. As a result, incorrect positions were
calculated. Therefore, the update of the position is moved to a place
after the update of the visibility of the rows.
Sorting rows must not change the visibility of objects. However, updating
the visibility of rows sets all objects to visible. Now the visibility
state of an object is saved and restored later so that the recalcPos()
method receives the correct state for the object.
Change-Id: Ia32698c1d45cd81702e6d00c5dfc100f6f6f399c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166799
Reviewed-by: Noel Grandin
Tested-by: Noel Grandin
diff --git a/sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods
b/sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods
new file mode 100644
index ..5ba746ad7baa
Binary files /dev/null and
b/sc/qa/unit/data/ods/tdf160329_sortWithHiddenRows.ods differ
diff --git a/sc/qa/unit/scshapetest.cxx b/sc/qa/unit/scshapetest.cxx
index 5aa24ede6ea6..d434084519f3 100644
--- a/sc/qa/unit/scshapetest.cxx
+++ b/sc/qa/unit/scshapetest.cxx
@@ -62,6 +62,14 @@ static SdrObject* lcl_getSdrObjectWithAssert(ScDocument&
rDoc, sal_uInt16 nObjNu
return pObj;
}
+static SdrObject* lcl_getSdrObjectbyName(ScDocument& rDoc, std::u16string_view
rName)
+{
+ScDrawLayer* pDrawLayer = rDoc.GetDrawLayer();
+const SdrPage* pPage = pDrawLayer->GetPage(0);
+SdrObject* pObj = pPage->GetObjByName(rName);
+return pObj;
+}
+
CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf144242_OpenBezier_noSwapWH)
{
// Shapes, which have rotation incorporated in their points, got
erroneously width-height
@@ -1295,6 +1303,35 @@ CPPUNIT_TEST_FIXTURE(ScShapeTest,
testTdf160369_groupshape)
CPPUNIT_ASSERT_RECTANGLE_EQUAL_WITH_TOLERANCE(aOrigRect, aAfterRect, 1);
}
+CPPUNIT_TEST_FIXTURE(ScShapeTest, testTdf160329_sortWithHiddenRows)
+{
+// Load a document, which has images anchored to cell and rows hidden
+createScDoc("ods/tdf160329_sortWithHiddenRows.ods");
+ScDocument* pDoc = getScDoc();
+
+// Sort the rows
+uno::Sequence aArgs1
+= { comphelper::makePropertyValue("DbName", u"myRange"_ustr) };
+dispatchCommand(mxComponent, ".uno:SelectDB", aArgs1);
+uno::Sequence aArgs2
+= { comphelper::makePropertyValue("ByRows", true),
+comphelper::makePropertyValue("HasHeader", true),
+comphelper::makePropertyValue("Col1", sal_Int32(1)),
+comphelper::makePropertyValue("Ascending1", false),
+comphelper::makePropertyValue("IncludeImages", true) };
+dispatchCommand(mxComponent, ".uno:DataSort", aArgs2);
+
+// Make sure objects are on correct position
+SdrObject* pObj = lcl_getSdrObjectbyName(*pDoc,
std::u16string_view(u"ImageD"));
+Point aPos = pObj->GetSnapRect().TopLeft();
+// The position was (3000|2899) without fix.
+CPPUNIT_ASSERT_POINT_EQUAL_WITH_TOLERANCE(Point(3000, 5898), aPos, 1);
+pObj = lcl_getSdrObjectbyName(*pDoc, std::u16string_view(u"ImageE"));
+aPos = pObj->GetSnapRect().TopLeft();
+// The position was (2600|2499) without fix.
+CPPUNIT_ASSERT_POINT_EQUAL_WITH_TOLERANCE(Point(2600, 4399), aPos, 1);
+}
+
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/sc/source/core/data/table3.cxx b/sc/source/core/data/table3.cxx
index 4e06aca8231a..ee00f2d58161 100644
--- a/sc/source/core/data/table3.cxx
+++ b/sc/source/core/data/table3.cxx
@@ -911,6 +911,50 @@ void ScTable::SortReorderByColumn(
}
}
+static void backupObjectsVisibility(const
std::vector>& rSortedCols,
+
std::vector>>& rBackup)
+{
+size_t nSortedCols = rSortedCols.size();
+for (size_t iCol = 0; iCol < nSortedCols; ++iCol)
+{
+std::vector>& rSingleColCellDrawObjects
+= rSortedCols[iCol]->maCellDrawObjects;
+size_t nSingleColCellDrawObjects = rSingleColCellDrawObjects.size();
+std::vector> aColBackup;
+for (size_t jRow = 0; jRow < nSingleColCellDrawObjects; ++jRow)
+
core.git: Branch 'libreoffice-24-2' - sc/qa sc/source
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).
core.git: sc/qa sc/source
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
line break attribute 'clear' in other writing modes than LTR
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
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/
core.git: svx/qa svx/source
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
+// thei
Re: https://opengrok.libreoffice.org/ has no project "core"
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"
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
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
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
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
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
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
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
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 00
core.git: oox/source
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
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
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
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
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/Scene
Re: Import of lighting from MS Office for extruded shapes
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
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
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
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&paste 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
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&paste 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
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&paste 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
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
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 &
Help on toolbars
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
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
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
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
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
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
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
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
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
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
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
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
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
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
+ fals
core.git: editeng/source sw/qa
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
unit test testTdf158743 in PNGExportTests.cxx fails for me
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
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
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
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
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
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 &rLine, SwTextFormatInfo &rInf 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 &rLine, 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 &rLine, 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
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
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
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
[Libreoffice-commits] core.git: oox/qa writerfilter/source
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
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'
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'
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'
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?
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
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 &aSize );
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 = o
[Libreoffice-commits] core.git: include/oox oox/source
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
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/connectors
Re: Bringing multi-page floating tables to ODF
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
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
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
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
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
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
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
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
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++.)
