summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)Author
2024-06-27tdf#161779 DOCX import, drawingML: fix handling of translation for linesMiklos Vajna
Open the bugdoc, it has a line with a non-zero horizontal offset from the anchor paragraph, it shows up as a horizontal line, while it should be vertical. Checking how the ODT import and the DOCX import works for lines, one obvious difference is that the ODT import at SdXMLLineShapeContext::startFastElement() only considers the size / scaling for the individual points, everything else goes to the transform matrix of the containing shape, set in SdXMLShapeContext::SetTransformation(). The drawingML import is way more complex, but it effectively tries to not set any transformation on the shape and just transorms the points of the line instead. Fix the problem by changing Shape::createAndInsert() to also not put any scaling to the transform matrix, to not transform the points of the line and finally to apply the transform matrix to lines as well. Do this only for toplevel Writer lines, that's enough to fix the bugdoc and group shapes / Calc shapes need more investigation, so leave those unchanged for now. Tests which were failing while working on this change: - CppunitTest_sc_shapetest's testTdf144242_Line_noSwapWH: do this for Writer shapes only, for now - CppunitTest_sw_ooxmlimport's lineRotation: this is already broken partially, now looks perfect - CppunitTest_sw_ooxmlimport's testTdf85232 / group shape: this points out that lines in group shapes are some additional complexity, so leave that case unchanged, for now - CppunitTest_sw_ooxmlexport3's testArrowPosition: manual testing shows this is still OK - CppunitTest_sw_writerfilter_dmapper's testTdf141540GroupLinePosSize: manual testing shows this is still OK (cherry picked from commit 6c09c85ec384e88c89bff0817e7fe9889d7ed68e) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport3.cxx Change-Id: I246430148e3b3c927e010f360fa317e8429c82d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169615 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-05-10drop requirement for rtl_random_getBytes to have "Pool" argCaolán McNamara
Seeing as since: commit e9531b792ddf0cfc2db11713b574c5fc7ae09e2c Date: Tue Feb 6 14:39:47 2024 +0100 sal: rtlRandomPool: require OS random device, abort if not present Both rtl_random_createPool() and rtl_random_getBytes() first try to get random data from the OS, via /dev/urandom or rand_s() (documented to call RtlGenRandom(), see [1]). we don't use the initial arg to rtl_random_getBytes anymore, drop the requirement to have one. Then simplify our usages of that, and addtionally deprecate rtl_random_createPool and rtl_random_destroyPool. Change-Id: I13dcc067714a8a741a4e8f2bfcf2006373f832c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167335 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-04-15svx: read font and spacing scaling from oox, add bot as UNO prop.Tomaž Vajngerl
- Read spacing in oox. - Add spacing scaling as a property. - Rename property "TextFitToSizeScale" to "TextFitToSizeFontScale" - Add property "TextFitToSizeSpacingScale" Change-Id: Icde575e55a3146169d86bb538a57adcf1fa228a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165633 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit db64748f1ee771da9da857f95601b9e08b577166) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165709 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-04-15tdf#160192: fix crash when trying to overwrite file in RO dir+lock fileJulien Nabet
Bug exposed with: 5259ab8104cfba60c40748ed0cd59d93df038c5b sfx2 store: create temp files next to local files bt: 6 0x00007faac67ad9b5 in sax_fastparser::FastSaxSerializer::FastSaxSerializer(com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> const&) (this=0x559f316f0e70, xOutputStream=empty uno::Reference) at sax/source/tools/fastserializer.cxx:68 7 0x00007faac67c46e0 in sax_fastparser::FastSerializerHelper::FastSerializerHelper(com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> const&, bool) (this=0x559f31721400, xOutputStream=empty uno::Reference, bWriteHeader=true) at sax/source/tools/fshelper.cxx:30 8 0x00007fa9bfa1b4cc in std::_Construct<sax_fastparser::FastSerializerHelper, com::sun::star::uno::Reference<com::sun::star::io::XOutputStream>, bool const&>(sax_fastparser::FastSerializerHelper*, com::sun::star::uno::Reference<com::sun::star::io::XOutputStream>&&, bool const&) (__p=0x559f31721400, __args=..., __args=@0x7ffecd609207: true) at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/stl_construct.h:119 ... 15 0x00007fa9bfa04087 in oox::core::XmlFilterBase::openFragmentStreamWithSerializer(rtl::OUString const&, rtl::OUString const&) (this=0x559f318ed5f0, rStreamName="docProps/core.xml", rMediaType="application/vnd.openxmlformats-package.core-properties+xml") at oox/source/core/xmlfilterbase.cxx:511 16 0x00007fa9bfa04999 in oox::core::writeCoreProperties(oox::core::XmlFilterBase&, com::sun::star::uno::Reference<com::sun::star::document::XDocumentProperties> const&) (rSelf=..., xProperties=uno::Reference to ((anonymous namespace)::SfxDocumentMetaData *) 0x559f2d673e28) at oox/source/core/xmlfilterbase.cxx:645 17 0x00007fa9bfa047c2 in oox::core::XmlFilterBase::exportDocumentProperties(com::sun::star::uno::Reference<com::sun::star::document::XDocumentProperties> const&, bool) (this=0x559f318ed5f0, xProperties=uno::Reference to ((anonymous namespace)::SfxDocumentMetaData *) 0x559f2d673e28, bSecurityOptOpenReadOnly=false) at oox/source/core/xmlfilterbase.cxx:981 18 0x00007fa9bee21bd4 in DocxExport::WriteProperties() (this=0x7ffecd609d78) at sw/source/filter/ww8/docxexport.cxx:952 19 0x00007fa9bee24b0b in DocxExport::DocxExport(DocxExportFilter&, SwDoc&, std::shared_ptr<SwUnoCursor>&, SwPaM&, bool, bool) (this=0x7ffecd609d78, rFilter=..., rDocument=..., pCurrentPam=std::shared_ptr<SwUnoCursor> (use count 1, weak count 1) = {...}, rOriginalPam=SwPaM = {...}, bDocm=false, bTemplate=false) at sw/source/filter/ww8/docxexport.cxx:2149 20 0x00007fa9bee4438e in DocxExportFilter::exportDocument() (this=0x559f318ed5f0) at sw/source/filter/ww8/docxexportfilter.cxx:112 21 0x00007fa9bf9d6b8b in oox::core::FilterBase::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x559f318ed5f0, rMediaDescSeq=uno::Sequence of length 12 = {...}) at oox/source/core/filterbase.cxx:494 full bt here: https://bugs.documentfoundation.org/attachment.cgi?id=193113 Patch prevents LO from crashing + make LO displays error message: Error saving the document <filename>: Write Error. The file could not be written Change-Id: I41a94eeb17bb6568b586d89755bce330154d1dad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164808 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 2887ffbf240aa70330cb50bf810170cf9c896405) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164821 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-04-15cid#1546354 COPY_INSTEAD_OF_MOVECaolán McNamara
and cid#1546319 COPY_INSTEAD_OF_MOVE cid#1546286 COPY_INSTEAD_OF_MOVE cid#1546283 COPY_INSTEAD_OF_MOVE cid#1546191 COPY_INSTEAD_OF_MOVE cid#1545953 COPY_INSTEAD_OF_MOVE cid#1545874 COPY_INSTEAD_OF_MOVE cid#1545857 COPY_INSTEAD_OF_MOVE cid#1545781 COPY_INSTEAD_OF_MOVE cid#1545765 COPY_INSTEAD_OF_MOVE cid#1545546 COPY_INSTEAD_OF_MOVE cid#1545338 COPY_INSTEAD_OF_MOVE cid#1545190 COPY_INSTEAD_OF_MOVE cid#1545272 COPY_INSTEAD_OF_MOVE cid#1545242 COPY_INSTEAD_OF_MOVE cid#1545229 COPY_INSTEAD_OF_MOVE Change-Id: I88813d9dbd87ce10375db8198028f8b70e23f0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162027 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-18-Werror,-Wdeprecated-declarations (Emscripten)Stephan Bergmann
> oox/source/crypto/CryptTools.cxx:57:40: error: 'HMAC_CTX_free' is deprecated [-Werror,-Wdeprecated-declarations] > void operator()(HMAC_CTX* p) { HMAC_CTX_free(p); } > ^ > workdir/UnpackedTarball/openssl/include/openssl/hmac.h:35:1: note: 'HMAC_CTX_free' has been explicitly marked deprecated here > OSSL_DEPRECATEDIN_3_0 void HMAC_CTX_free(HMAC_CTX *ctx); > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0' > # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0) > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED' > # define OSSL_DEPRECATED(since) __attribute__((deprecated)) > ^ > oox/source/crypto/CryptTools.cxx:112:29: error: 'HMAC_CTX_new' is deprecated [-Werror,-Wdeprecated-declarations] > mpHmacContext.reset(HMAC_CTX_new()); > ^ > workdir/UnpackedTarball/openssl/include/openssl/hmac.h:33:1: note: 'HMAC_CTX_new' has been explicitly marked deprecated here > OSSL_DEPRECATEDIN_3_0 HMAC_CTX *HMAC_CTX_new(void); > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0' > # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0) > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED' > # define OSSL_DEPRECATED(since) __attribute__((deprecated)) > ^ > oox/source/crypto/CryptTools.cxx:125:9: error: 'HMAC_Init_ex' is deprecated [-Werror,-Wdeprecated-declarations] > HMAC_Init_ex(mpHmacContext.get(), rKey.data(), rKey.size(), aEvpMd, nullptr); > ^ > workdir/UnpackedTarball/openssl/include/openssl/hmac.h:43:1: note: 'HMAC_Init_ex' has been explicitly marked deprecated here > OSSL_DEPRECATEDIN_3_0 int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len, > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0' > # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0) > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED' > # define OSSL_DEPRECATED(since) __attribute__((deprecated)) > ^ > oox/source/crypto/CryptTools.cxx:499:12: error: 'HMAC_Update' is deprecated [-Werror,-Wdeprecated-declarations] > return HMAC_Update(mpImpl->mpHmacContext.get(), rInput.data(), nActualInputLength) != 0; > ^ > workdir/UnpackedTarball/openssl/include/openssl/hmac.h:45:1: note: 'HMAC_Update' has been explicitly marked deprecated here > OSSL_DEPRECATEDIN_3_0 int HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0' > # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0) > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED' > # define OSSL_DEPRECATED(since) __attribute__((deprecated)) > ^ > oox/source/crypto/CryptTools.cxx:512:12: error: 'HMAC_Final' is deprecated [-Werror,-Wdeprecated-declarations] > (void) HMAC_Final(mpImpl->mpHmacContext.get(), aHash.data(), &nSizeWritten); > ^ > workdir/UnpackedTarball/openssl/include/openssl/hmac.h:47:1: note: 'HMAC_Final' has been explicitly marked deprecated here > OSSL_DEPRECATEDIN_3_0 int HMAC_Final(HMAC_CTX *ctx, unsigned char *md, > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:182:49: note: expanded from macro 'OSSL_DEPRECATEDIN_3_0' > # define OSSL_DEPRECATEDIN_3_0 OSSL_DEPRECATED(3.0) > ^ > workdir/UnpackedTarball/openssl/include/openssl/macros.h:62:52: note: expanded from macro 'OSSL_DEPRECATED' > # define OSSL_DEPRECATED(since) __attribute__((deprecated)) > ^ Change-Id: Ia9edc299b7cd4728fe32adbca8e1212170c328ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162248 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164835 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-03-11tdf#160049 oox import: use margins with left/right HoriOrientRelationJustin Luth
I'm really surprised this wasn't found much earlier. Even DOC format isn't handling this. make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf160049_anchorMarginVML Change-Id: I92ee8eceb6c6bab5f027663bae94d7acdf01be3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164442 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164581 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-02-26related tdf#126533 tdf#159824 VML: don't export: negative anglesJustin Luth
and stop an automatic 180 reversal on import. Some documents had gradient reversals on every round trip, typically when the angle was 0-179 (mainly seen in ODT examples, since DOCX/RTF imports defaulted to be angle 180). The negative sign has special meaning, indicating that the start and end colors should be swapped. Well, swapping colors was not intentional in the export logic. Previously there was a mistaken idea that any angles > 180 needed to be swapped on import, and likely that is what prompted this overly complicated formula to try to avoid any angle > 180 during export by allowing negative angles. This tdf#126533 patchset has already eliminated import checks for angles > 180, so now a sane formula can be applied on export. In order to do that, we have to avoid emulating color swaps with 180 degree rotations at import time. So ONLY do color swapping with start/end, and leave the angle alone. That GREATLY helps unit tests (which otherwise would flip-flop the angle and the color start/stop). Very unhelpful was an undocumented, indecipherable inversion when converting to DML angle. Boy, I hope I got this right... make CppunitTest_sw_rtfexport8 \ CPPUNIT_TEST_NAME=testTdf159824_gradientAngle3 make CppunitTest_sw_rtfexport8 \ CPPUNIT_TEST_NAME=testTdf159824_gradientAngle4 make CppunitTest_sw_ooxmlexport7 \ CPPUNIT_TEST_NAME=testTdf126533_axialAngle2 Eliminating the inversion for ooxml7 test is fine since inversion does nothing to an axial. Otherwise, eliminating inversions corresponds to a color swap. Change-Id: I2aae0a7595807569ffc740689ff3840692d6159d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163798 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163871 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-26related tdf#126533 vml import: fix gradient color swappingJustin Luth
tdf#65295 already fixed one case by removing the test for degrees > 180 for the linear-equivalent gradients. Unfortunately the comment wasn't also removed, so that was confusing: removed comment. The test for degrees > 180 is not needed for the axial-equivalent case either: removed. The reason for that degrees > 180 case is likely due to negative degrees, which is a documented reason for swapping the colors: added swap if negative degrees. All the affected, existing unit tests are improved now: -tdf81345.docx: famous MS example: improved header gradient -fdo78300.docx: fontworks: hard to tell without MCGR... make CppunitTest_sw_ooxmlexport7 \ CPPUNIT_TEST_NAME=testTdf126533_negativeAxialAngle make CppunitTest_sw_ooxmlexport7 \ CPPUNIT_TEST_NAME=testTdf77219_backgroundShape Change-Id: I9f4d56375bb2cec28ffbd93df419d586da465b78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163417 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163865 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-02-26tdf#159626 vml pattern import: add color, fix back/foregroundJustin Luth
This depends on tdf#126533 which imports page style v:fill, BUT ONLY IN ORDER TO support the unit tests. The patch itself can stand alone and fixes vml import into textboxes/shapes etc. i.e. backporting could be possible by dropping the unit tests. The pattern that VML uses to indicate foreground and background is very different from what LO needs. [Fortunately LO does not use the _guess_ from vcl::bitmap::isHistorical8x8 to determine which color is the background. Instead it always uses the first pixel.] Documentation says that unspecified XML_fillcolor and XML_color should be white, but observation says it should be 25% gray (Word 2003). 25% gray == C0C0C0 == fillcolor="silver" == COL_LIGHTGRAY Currently, we simply export as a colored, tiled image, and not as a B&W type="pattern" so no corresponding export changes need to be made to export. Existing unit test documents that are affected: -chart2export's PieChartDataLabels.docx (page background) -ooxmlexport5's fdo77725.docx (minimized PieChartDataLabels.docx) * both foreground and background are set to white => solid white -sw/qa/core/data/ooxml/pass/fdo79131.docx (shape "inline") make CppunitTest_sw_tiledrendering \ CPPUNIT_TEST_NAME=testTdf159626_yellowPatternFill make CppunitTest_sw_tiledrendering \ CPPUNIT_TEST_NAME=testTdf159626_yellowPatternFillB make CppunitTest_sw_tiledrendering \ CPPUNIT_TEST_NAME=testTdf159626_blackPatternFill Change-Id: I9533ac4a7489081ffc62a10e900f5526abb906db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163106 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163864 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-26tdf#126533 docx import: page background vml fillJustin Luth
This patch imports bitmaps/tiled textures (primarily), but also somewhat for gradients (because of a gradient2 -> gradient mismatch somewhere) and somewhat for patterns (because patterns are not well imported in general). Note that the imported fill likely will NOT match MSO, because their background CHANGES BASED ON THE ZOOM LEVEL. For example, my primary testing file (A6 landscape) has a logo which is only 25% visible in Word 2003 at 100%, but shows 90% of the logo at 200%, and many tiles of logos when exported as PDF. The same is true for gradients etc. Changing background on zoom is an absolutely bizarre implementation, and naturally LO could only accidentally look identical (and should never try to do so). make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf126533_noPageBitmap make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf126533_pageGradient This is slightly ugly, but I don't know how to make a COPY of the XPropertySet UNO junk. All I have is references, and dispose deletes everything, even the references. I took some inspiration from RTF which just disposes the shape after grabbing the background color. Thus, just change the page style known to exist and be used, and then simply remove the fill if it isn't needed in the end. Any new page styles can just copy the default page style fill. Change-Id: Id3ea002c685642ff4c289982d0108247a6e9bb8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162958 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163861 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-21tdf#153761 vml export: avoid corrupt docx: don't write empty r:idJustin Luth
For the benefit of MSO, do not write r:id="", since MSO refuses to open such a document. Change-Id: I21887021c747fc9a9764befc7081e21d99e47545 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163523 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> (cherry picked from commit 5132255021aa61f8a1fa7d8de820cb3528699812) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163542 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-02-21docx import: correct redline content-controlsAshod Nakashian
When inserting and deleting content-controls with change-tracking enabled, we hit a few corner-cases that we need to handle more smartly. First, we shouldn't redline the controls themselves, just the placeholder text. Second, we have to take special care to create valid XML structure with the redline tags. Includes unit-test that reproduces the issues and verifies that both saving and loading work as expected. (cherry picked from commit 1b0f67018fa1d514ebca59e081efdd24c1d7811b) Change-Id: I6af4d0d2c3f0661e7990d5414cc93effc96f0469 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163681 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-07check that rtl_random_getBytes() was successfulMichael Stahl
... everywhere it is used to generate material for encryption. Change-Id: Id3390376bb2f3a5fa1bbfd735850fce886ef7db2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162873 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit b85c2459ced6a41915dbaf567613fb5e244a0ada) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162890 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-07sw: do not redline ContentControl itemsAshod Nakashian
When we redline the ContentControl item itself, we break docx XML. Instead, we only need to redline the placeholder, which we already do. This simply disables redlining when inserting the ContentControl item while leaving it otherwise enabled while inserting the placeholder. Before: <w:body> <w:p> <w:pPr> <w:pStyle w:val="Normal"/> <w:rPr></w:rPr> </w:pPr> ==> <w:ins w:id="-1" w:author="Unknown Author" w:date="2024-01-24T19:43:08Z"> <w:sdt> <w:sdtPr> <w12:checkbox> <w12:checked w14:val="0"/> <w12:checkedState w14:val="2612"/> <w12:uncheckedState w14:val="2610"/> </w12:checkbox> </w:sdtPr> <w:sdtContent> <w:r> <w:rPr></w:rPr> </w:r> ==> </w:ins> ==> <w:ins w:id="0" w:author="Unknown Author" w:date="2024-01-24T19:43:08Z"> <w:r> <w:rPr></w:rPr> <w:t>☐</w:t> </w:r> ==> </w:ins> <w:r> <w:rPr></w:rPr> </w:r> </w:sdtContent> </w:sdt> </w:p> </w:body> The first <w:ins> and its closing tag is not seen in the reference docx file, and we can see that it's invalid XML here. After: <w:body> <w:p> <w:pPr> <w:pStyle w:val="Normal"/> <w:rPr></w:rPr> </w:pPr> <w:sdt> <w:sdtPr> <w12:checkbox> <w12:checked w14:val="0"/> <w12:checkedState w14:val="2612"/> <w12:uncheckedState w14:val="2610"/> </w12:checkbox> </w:sdtPr> <w:sdtContent> <w:r> <w:rPr></w:rPr> </w:r> ==> <w:ins w:id="0" w:author="Unknown Author" w:date="2024-01-24T19:43:08Z"> <w:r> <w:rPr></w:rPr> <w:t>☐</w:t> </w:r> ==> </w:ins> <w:r> <w:rPr></w:rPr> </w:r> </w:sdtContent> </w:sdt> </w:p> </w:body> Only the valid <w:ins> around the placeholder exists. Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk> Change-Id: I1404e41aec3b5efdc2e4115236102ffa2733b15c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162802 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 7a3e9c66baff8554d1267bc98c9c69e763bc8bdc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163047 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2024-02-06tdf#154587: allow directory entries in ZIP packagesMike Kaganski
The problem in the bugdoc was the directory entries. These entries are valid in ZIP packages (even if not common); they may be useful to e.g. define per-directory permissions (ACLs). In normal mode, ZipFile reads central directory; there we can read if the entry has FAT file attributes; and then, if the entry is a directory. Then it is OK to skip it. In repair mode, central directory is not used, local file headers don't contain a "directory" flag. A workaround is used, checking if there are entries that represent directories of other entries. Also this change fixes some places that didn't pass the recovery flag correctly. Change-Id: I324671841a2c4d0f279b03801d95c8f2eeb99b46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162888 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 747463809e50c132557a95dcee6709a1fa82d760) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162897 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-01-29crashtesting: crash seen on import of forum-mso-en4-278652.xlsxCaolán McNamara
probably an issue since: commit 135ce256ce9e879663d828ec6e699de521fad867 Date: Mon Aug 14 15:59:18 2023 +0200 tdf#146487 Don't show generic diagram title when there is an empty title given Change-Id: I12d8d6e78a8435b998084221402b6bdfc4a1a433 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162539 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-23tdf#156718 PPTX import: fix the different formatting in table styleTibor Nagy
when the PPTX file only has table style id, but no table style content. Change-Id: Ia3416478716a50beb6837988e98697fd88e916d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162368 Tested-by: Jenkins Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de> (cherry picked from commit 27a1eccae1763b8efa17c909820f57f84361d308) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162378 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-01-23tdf#146487 Don't show generic diagram title when there is an empty title givenSamuel Mehrbrodt
Bugdoc has autoTitleDeleted set to false (so title should be visible), but then an empty title is given. In this case no default string should be added to the title, only in case of Pie Charts. Any other Chart types show the default title in MS-Office. Co-authored-by: Balazs Varga <balazs.varga.extern@allotropia.de> Change-Id: Ib445099a4a3d113cff6b1ffdfd093fe41c34716b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155681 Tested-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> (cherry picked from commit c205194b8c54011af4b2cd34fbc00f4885883643) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162270 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-20tdf#134401 SD: export to pptx: autoGrow->textWordWrapAttila Szűcs
PPTX doesn't have autoGrowWidth and autoGrowHeight, but it does have TextWordWrap which is similar. If autoGrowWidth and autoGrowHeight are set in the document, then they are exported to PPTX as TextWordWrap = "none". Without this patch, PowerPoint may wrap some texts into more lines as Impress does. This is because some text may rendered at sligtly different sizes in PowerPoint as in Impress. (maybe it is just a rounding difference) Even 1% (or less) size difference is enought, because when autoGrowthWidth and autoGrowthHeight is set, then there is a good chance, the textbox rectangle is exactly as big as the text. Change-Id: I2cdba68c66c43507c5007a9e395b87ddeeea2372 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162152 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit dc5a761df436f5d9de781d1fa6cf7d010f8be0e8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162210 Reviewed-by: Andras Timar <andras.timar@collabora.com>
2024-01-18tdf#140912, tdf#159219: fix import of graphic placeholder with custom promptMike Kaganski
Importing the text marks the object as not empty. Then, the object would behave as an outliner object. This includes showing in slide show; allowing text esiting; stretching the placeholder image, which required a workaround implemented in commit 7b3be7f6f3d800e2ad86f5a043e6e9b21ed4409f (tdf#140912 Better handling of the picture placeholders, 2021-12-01). Instead, drop the custom prompt. More correct solution would be making sure to mark the object as empty after setting the text; but this doesn't round- trip to ODF; and it crashes export to PPTX. Proper support for the sustom placeholder prompt feature should be done separately. The new workaround (dropping the text) makes previous workaround (special handling of the placeholder graphic) unnecessary. The unit test is updated. Change-Id: Ic7f42493af8d1d725ffa39ffab58f1ff033351cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162202 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162237 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-15crashtesting: null deref of xValueSeqCaolán McNamara
since: commit 0bf4338cfe406a0d527ac78ce76ff7dd3837df03 (HEAD) Date: Mon Jan 8 13:52:03 2024 -0500 tdf#137691 chart2 export: preserve NumberFormat of DataSeries make CppunitTest_chart2_export3 CPPUNIT_TEST_NAME=tdf137691 Change-Id: Ibd65207b01885961f207da04204e7e2512c20d9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162083 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> (cherry picked from commit 6da480d086a599f6a0159c5244ce8fe0ae4131b8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162103 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Justin Luth <jluth@mail.com>
2024-01-10tdf#137691 chart2 export: preserve NumberFormat of DataSeriesJustin Luth
make CppunitTest_chart2_export3 CPPUNIT_TEST_NAME=tdf137691 tdf116163.pptx is a good example if you look at the DataTable. Prior to this patch, the DataTable lost the number formatting. TODO: /chart2/qa/extras/data/docx/testSeriesIdxOrder.docx is exporting General in this case, which was unexpected. It appears to be an import problem though, not an export one. TODO: The fixme in testPPTXPercentageNumberFormats is still needed. Page 2's axis should LinkToSource and ignore the specified style. (It too is an example of this export patch working good.) Change-Id: I28730ba49ac2929bbc1c3be50f0d4819a5a205dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161806 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161846 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-01-10tdf#137691 chart2 import: provide NumberFormat to DataSeriesJustin Luth
make CppunitTest_chart2_export3 CPPUNIT_TEST_NAME=tdf137691 This patch provides some very foundational support to importing a chart. It will open up a lot of doors to improve LinkToSource - since now the Source key is defined. Likely the source key should default to -1 instead of 0, so that LinkToSource can know whether or not the source is defined. /chart2/qa/extras/data/docx/testSeriesIdxOrder.docx is an example of where this patchset SHOULD have worked, but somehow it is losing its key during import... Unfortunately I have run out of time and can not follow these rabbit trails. Well, at least not until this change is considered a regression for some particular document... Change-Id: Ieddf2103002616aca2a408bde1f86d45c08dfc85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161702 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161845 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-01-10UnoApiTest::loadFromURL -> UnoApiTest::loadFromFileMike Kaganski
The old name was misleading (it doesn't take an URL, but a filename); also, now it's easier to grep for it - doesn't get mixed with vcl::graphic::loadFromURL. Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161888 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-01-08ofz#65567 unset DiagramFontHeights on exceptionCaolán McNamara
git diff -w is your friend Change-Id: I360ebb70e710a5d435ce8153090593784e2ac603 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161684 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-12-20Related: tdf#76115 Also pass RepairPackage to FilterDetectMike Kaganski
And drop the default argument value from ZipStorage ctor. Always pass it explicitly. Change-Id: I8bcf78dc4db7763567f9d6873841d75c328ede7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160760 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160782 Tested-by: Jenkins
2023-12-20tdf#76115: pass RepairPackage property from media descriptor to ZipStorageMike Kaganski
See commit 86c682273d907c77404637c89e584047de1c1099. Change-Id: I51a3beb00f635554ac73cc9ea957e18fb8e84349 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160757 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160781
2023-12-19tdf#157740 FILESAVE PPTX: fix explosion of the number of master slidesBalazs Varga
- Export correctly the "supported" master slides with the actual slides names. - Set SlideLayout property at ODF import as well for MasterSlides layout type. - When we copy a slide with the master slide also copy the SlideLayout property value as well. Change-Id: Idb6b88ebe87a83818d8eb27a1fa087652a002c0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160290 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com> Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de> (cherry picked from commit bff76421e234df7246a7f49c71a11432f86e09d1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160869 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-12-08tdf#126084 document OOXML SVG tests and importTomaž Vajngerl
Change-Id: Ief29d04f2f0693a4cdfa44c7c100ac6164da38f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160378 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-06tdf#126084 import svg image from ooxml document that use svgBlip elem.Tomaž Vajngerl
In an OOXML document the svg image is defined in an svgBlip, which is an OOXML extension. This change checks for the svgBlip element and imports that instead the normal "blip" element that is still provided as a fallback (PNG image). Add roundtrip SVG image test for ODF and OOXML, Impress and Writer. testGraphicBlipXLSX test failed after this change, because some component was missing. Changed to enable use_rdb for all chart2 export tests, so issues like this won't happen anymore. Change-Id: Idf0e754775254d7dcfd0321dfca2ed6d00c42c09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157238 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-04cid#1545597 Using invalid iteratorJulien Nabet
and : cid#1545537 Using invalid iterator cid#1545508 Using invalid iterator cid#1545494 Using invalid iterator cid#1545478 Using invalid iterator cid#1545427 Using invalid iterator cid#1545420 Using invalid iterator cid#1545400 Using invalid iterator cid#1545300 Using invalid iterator cid#1545258 Using invalid iterator cid#1545257 Using invalid iterator cid#1545200 Using invalid iterator cid#1545183 Using invalid iterator Change-Id: Ibf3a41902f34286967195c5c3b22e337a4b06809 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160322 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04cid#1546021 Using invalid iteratorJulien Nabet
and : cid#1545983 Using invalid iterator cid#1545969 Using invalid iterator cid#1545949 Using invalid iterator cid#1545929 Using invalid iterator cid#1545911 Using invalid iterator cid#1545910 Using invalid iterator cid#1545886 Using invalid iterator cid#1545870 Using invalid iterator cid#1545813 Using invalid iterator Change-Id: I2ad10c2a9affd348050a4abe0917a90927a52547 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160317 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04tdf#126084 support writing SVG images into OOXML using the MS OOXML extensionTomaž Vajngerl
SVG files aren't supported in OOXML, but we can write it using the MS OOXML extension, which is supported in the latest MSO versions. For now this only implements the support in the exporter. Change-Id: I688180fb5772f3999c2ee3020bc234f90d57cc2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157237 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-03Split the *Bitmap::CopyPixel functionsNoel Grandin
into the two entire separate cases they want to handle, there is no reason to mix the two different cases like this. Change-Id: I38e99e7ad6168a84e7a744f61407887825158902 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160248 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-12-03oox: Refactor and simplify writing to storage with GraphicExportTomaž Vajngerl
Change-Id: I743dc99e0228b59050fb4926c8ef56bed8e82060 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160252 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-12-01Fix typoAndrea Gelmini
Change-Id: I19abea6905b36e9817de9531dafd389502034910 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160205 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-01[API CHANGE] Add OOXML way of curved connector routingRegina Henschel
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 <vmiklos@collabora.com>
2023-11-30Extended loplugin:ostr: ooxStephan Bergmann
Change-Id: Ie6db1edbad5305e4935a9fdc03dab36861bf2c8a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160112 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-28tdf#158348 Treat wordprocessing canvas like group shapeRegina Henschel
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 <rb.henschel@t-online.de>
2023-11-26tdf#96401: allow to detect a broken ZIP packageMike Kaganski
In deep detection, first check if it's a broken ZIP package. If it is, set the RepairPackage media descriptor property to true. Pass the RepairPackage value to the OOXML filter detection. Change-Id: Ic958283f3cce92ac29ce93ac330cc9e409e3eb78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159976 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-11-24tdf#158339 setFullWPGSupport to group shape in wpcRegina Henschel
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 <rb.henschel@t-online.de>
2023-11-22tdf#148000 impress: improve fontwork text placement.Attila Szűcs
Improved the calculation of positions of text characters for multi-line texts. The previous version only fitted the text to the basic outline (curve), and then scale them to the appropriate text line. This means that the text will be wider or shorter, depending on the shape of the curve, and which line it is on Now it calculates a curve for each paragraph and fits text on it. Text will be approximately the same width on each line. Except if the text is wider as the curve. Because then it shrinks the text to fit on the curve. (this can only happens on inner curves) Reused the same compat flag that was used in bug148000, now it serves as a Powerpoint compatible mode for FontWork, so no need to create new compat flag every time FontWork has improve. That means that the Fontwork in old documents has remains the same Refactored horizontal/vertical alignment, but had to keep the old hacks as well. Note: if there are too many lines of text, and the vertical alignment causes internal curves, then curves can shrink to 0 length (center point of a circle) or even to negative length, These cases are impossible to display normally, so it will be glitchy similar to how it was before this patch. MS PowerPoint avoid these cases by not allowing vertical alignments that would result internal (smaller) curves. Added unittest to check legacy-odb / new-odp / pptx file. It change the display of fontwork, so in some cases it may feel like a regression. Change-Id: Iac2d9bc751bbc2b6f747c33958f969cb3543fae5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159776 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-19Extended loplugin:ostr: ooxStephan Bergmann
Change-Id: Ic3ee80433571767dba9de1ecfb00d2d96beae4db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159690 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-18c++20: use std::erase(_if) instead of std::remove(_if)+erase (part 5)Julien Nabet
Change-Id: I373e5185e53ce88fba36d69d0fc20c29bb89d184 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159625 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-17Add getUnicodeTokenName() to StaticTokenMap and use...Regina Henschel
it in several places. Currently these places get a Sequence<sal_Int8> by call of StaticTokenMap().getUtf8TokenName() and immediately after that generate an OUString from it using reinterpret_cast<const char*> 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 <rb.henschel@t-online.de>
2023-11-15Fix typoAndrea Gelmini
Change-Id: Iab90ee3e42390d9f68a5b2ac0e4d0e2e3eb37a80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159439 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-15Fix typoAndrea Gelmini
Change-Id: Ifc1b536a003194de5271b348c363bf4bd9b9a9e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159437 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-15Fix typoAndrea Gelmini
Change-Id: I6bbf45f4aaf7412864bdb6697184616f7ef14138 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159438 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-15Fix typoAndrea Gelmini
Change-Id: I912f5e5a035d00e7640d489b1ff1c7a3c0315b9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159442 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
generated by cgit (git 2.34.1) at 2025-02-01 16:57:57 +0000