summaryrefslogtreecommitdiff
path: root/oox
AgeCommit message (Collapse)Author
2024-05-16WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara
Change-Id: I710ff75d387b2d452cb80911c9f0092948453ef8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167751 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-05-11cid#1597279 Unchecked return valueCaolán McNamara
Change-Id: I603d8269f6831c07dc48b767545180120388831d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167505 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-10loplugin:ostr in ooxNoel Grandin
Change-Id: I08124ce2da1facbe2e84aa4a7a8e25fec24fa962 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167428 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-05-08drop 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/+/167067 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-03makefile simplification: replace $(call gb_CustomTarget_get_workdir,foo)Christian Lohmaier
…by a simple/static $(gb_CustomTarget_workdir)/foo The build system has a lot of overly complicated leftovers from when it was introduced and had not only deal with split repositories but also had to coexist with another buildsystem. Along with lots of copy'n'paste along the years the makefiles became hard to grasp for newcomers with all our calls and evals. As a first step to streamline that, the macros from TargetLocations that simply prefix a static path to the argument (and similar of the same kind) are a natural pick before simplifying the rules themselves/getting rid of a bunch of eval statements. Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-05-02tdf#148616 Speed up finding custom shape guide valueAron Budea
Use a lookup hash map instead of linear search Change-Id: I54c9509740d90ca3f7479dfc16a6aeffd82a405d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166879 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Aron Budea <aron.budea@collabora.com>
2024-04-26mStyleIdMap can be static constNoel Grandin
Change-Id: I4df2b1152605c175d7959b6739ba0068539bed6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166649 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-22loplugin:constantparamNoel Grandin
Change-Id: Ic34679736973ed1f10ced8c9f0846514fa556445 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166421 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-04-18tdf#160517 - chart odf: import/export formatted chart titlesBalazs Varga
(main, sub, axis titles) texts properly to/from odf format. Fix odf export of formatted chart titles. The exported data structure will look like: <chart:title svg:x="3.304cm" svg:y="0.285cm" chart:style-name="ch2"> <text:p> <text:span text:style-name="T1">This</text:span> <text:span text:style-name="T2"> is</text:span> . . . <text:span text:style-name="T3">3</text:span> <text:span text:style-name="T2"> a </text:span> </text:p> </chart:title> Fix import of formatted chart titles. Put the properties and related texts into the chart2::XFormattedString2 uno objects. Follow-up commit of: 55e9a27afd2d6a13cf76b39641bf121c3ec4b45c Related: tdf#39052 - chart ooxml: export formatted chart titles 4f994cec388377cc5c2bddb804bd92eb4cd7dc8d tdf#39052 - Chart: make characters formatable in editable chart textshapes -- TODO: chart data point / dataseries labels are handled differently since those are not editable objects, but that is a completily different issue. -- Change-Id: I1842f2c69c132bdf578bb2d354f451cc9d49c63c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166122 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-04-15Generalize basegfx::fround for templated return typeMike Kaganski
And use it when assigning to tools::Long Change-Id: I0814d7bac9cdd48191ba69c64e3b12a4973b3417 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166071 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-04-13Use o3tl::convert in ooxMike Kaganski
Change-Id: I1cbc299e7e64eae48f0f6c896a8160bbe6e19c97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165938 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-04-09tdf#146619 Drop unused 'using namespace' in: oox/Gabor Kelemen
Change-Id: I4e8aa7443e71a7cb629f762b08d86dd1fa5b7f0b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165690 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2024-04-08tdf#50998 tdf#87892 Add sinusoid shapeRMZeroFour
In response to #50998 (as well as #87892 indirectly), regarding adding sinusoidal and coil-like shapes to the shape gallery in LibreOffice, this commit adds a sinusoid shape to the gallery. The shape is still incomplete for release, at least lacking icons for the sidebar. Further details posted on the Bugzilla thread for issue #50998. PS-2: Removed the previously added flag shape. PS-4: Moved sinusoid to the end in a new subgroup. Change-Id: Ie0f6e3948b6dce98dc2b4f87289cfd37f2d16911 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165353 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2024-04-03Base scale on 1.0, not on 100.0Mike Kaganski
Simplifies things by avoiding many repeated multiplications / divisions by 100 during calculations. Change-Id: Ib063d343549139c8d83e5b06570dc61f39ea0df6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165666 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-04-03svx: 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>
2024-04-02Related: tdf#39052 - chart ooxml: export formatted chart titlesBalazs Varga
texts properly to ooxml. Also adding "FormattedStrings" property for title objects to simplify the working of character formattings in editable chart shapes. TODO: odf import/export Change-Id: Ie27b4dee72c24fa6a2a4e2a7db8da7fa50eb8937 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165583 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-04-02tdf#78027 - Fix Chart OOXML Import with non-uniform formatted titlesBalazs Varga
Character formats are disappeared from Chart Title textobjects if they were formatted non-uniform. In this patch only the OOXML import and the chartview part will be fixed which make it visible after the import. (Note: next patch will contain the chart controller part where the characters can be formatted during title editing). Change-Id: I4fb5c3d80b7889935d198e70fb49e2c68108b235 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165500 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
2024-03-29tdf#157285 PPTX import: fix placeholder heightTibor Nagy
The "TextAutoGrowHeight" property doesn't shrink the shape automatically when its content is smaller than the current size. Change-Id: Ia7f94d7452d1a1c3f004aebd73b6ed5cbfd9b43b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165551 Tested-by: Jenkins Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
2024-03-29tdf#158237 Use C++20 contains() instead of find() and end()Aaron Bourdeaux
Change-Id: I529096d97991a89bdc68ec7f5d490ec21744fc6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165499 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-03-27Restore shape rotation on roundtrip of pptx 3D shapeRegina Henschel
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 <rb.henschel@t-online.de>
2024-03-23tdf#70039 partly enable 3D-image from pptxRegina Henschel
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 <rb.henschel@t-online.de>
2024-03-22Revert "extruded shape import: tweak threePt light rig too"Regina Henschel
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 <rb.henschel@t-online.de>
2024-03-21Drop C/C++ DEBUG macroStephan Bergmann
...(that was defined iff OSL_DEBUG_LEVEL >= 2) and replace its uses with OSL_DEBUG_LEVEL directly Change-Id: I807c15a02cc8ced9852287df0afb4808761d19d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165067 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-21Fix typoAndrea Gelmini
Change-Id: I4b017b9886713423a2b8f445ced297ddc10f6434 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165084 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-03-21Fix typoAndrea Gelmini
Change-Id: I5e1f9104405329452431ccf663f6916a6cd2036b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165085 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-03-20tdf#70039 import material of extruded shapesRegina Henschel
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 <guibomacdev@gmail.com> Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2024-03-19extruded shape import: tweak threePt light rig tooRegina Henschel
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 <rb.henschel@t-online.de>
2024-03-17loplugin:unusedmethodsNoel Grandin
Change-Id: Ib0a72355972662c6b902bca9a527be91fb3e1d17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164930 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-14tdf#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>
2024-03-14Fix typosAndrea Gelmini
Change-Id: I94df85715874013a28167d417107b09609f0293e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164831 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-03-14Fix typoAndrea Gelmini
Change-Id: Ia9e04aeda25f5a1b91950377c3eca335b443790b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164830 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-03-14Fix typoAndrea Gelmini
Change-Id: I554f8b88e0f479c4fd27fcc6231e79d77371209e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164809 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-03-14Fix typoAndrea Gelmini
Change-Id: Ifcd144b89f1d5648a3c72471b691529251d26892 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164832 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-03-14tdf#141908 - CppUnittests: replace usage of sal_Int32 with colorsRafał Dobrakowski
Conversion of hex/dec colour notation (example entry Color( 255, 255, 255), Color(0xFFFFFF) - COL_WHITE) For the other available colour definitions. Change-Id: I9eed0cd64adcbc8d25e1c22143a000906a457586 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163729 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2024-03-13tdf#70039 import lighting of extruded shapesRegina Henschel
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 <rb.henschel@t-online.de>
2024-03-11tdf#158773 reduce cost of importing binary dataNoel Grandin
no need to pass it via the internal buffer of SequenceOutputStream when we can read it directly Change-Id: I832737d73309449a1f3a26a4b451977a2a580de3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164634 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-11Use weak reference to SfxObjectShell in SfxEventHint to avoid use-after-freeMike Kaganski
The events may be processed after the shell has been destroyed. This is happening reliably after commit e2bfc34d146806a8f96be0cd2323d716f12cba4e (Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable, 2024-03-11) when controlling LibreOffice from external Java scripts; but obviously, it could happen before as well. Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase. Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-09tdf#158773 avoid some OUString constructionNoel Grandin
Change-Id: I42c6b7a8c7b0c0af17a2806c908f5a336ef206d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164599 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-06tdf#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>
2024-03-02tdf#159912 extruded shapes already rotate backgroundRegina Henschel
... 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 <rb.henschel@t-online.de>
2024-02-27address shortcoming: document why I avoided axials for transparencyJustin Luth
Hmm, I like to complain when other people don't comment on why certain situations are excluded, and yet I did the same thing here. Thanks vmiklos for pointing that out. Change-Id: I4c5ddeaeee078f036fc31149fc29bc6acb277ab3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164040 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-27cid#1592378 Logically dead codeCaolán McNamara
Change-Id: I4cab1e22f61113dd84b9ce77c639be5572ff9c77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164014 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27cid#1592381 silence Out-of-bounds readCaolán McNamara
Change-Id: I437af59b956753eaadea61db12500e5e7b45d9b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164008 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27tdf#67347 pptx import: stacked + horz/vert aligmentAttila Szűcs
In case of Stacked, PP calculates in the vertical direction with the horizontal alignment. We simulate it by setting TextVerticalAdjust at import time (from PPTX) based on the ParagraphAdjust of the 1. paragraph It is not perfect, because we have 1 TextVerticalAdjust / 1 shape, and it does not support justified, while we can have many ParagraphAdjust / 1 shape (if the shape have more paragraphs) For a better solution we should re-implement the entire stacked thing, but that is a much bigger task. Change-Id: I4011be0f118b870ab7f9e2ddc15c6dc5a21f8a89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163934 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Attila Szűcs <attila.szucs@collabora.com>
2024-02-27related tdf#126533 dml/vml import: import radials as radialsJustin Luth
... and not as symmetrical linear gradients. The benefit is that our export code will be able to intelligently export it. Apparently RTF export code does not intelligently export axials, (now fixed - tdf#159824) but VML and DML (and doc) do it well. Unfortunately charts can be badly affected, (avoided by ignoring when transparent) and unit tests are implementation-tested... This affects existing unit tests: -tdf128345_Legend_CS_TG_axial.pptx: label imports fine: lost on export (no change) -tdf128345_ChartWall_CS_TG.pptx: wall gradient now looks axial: lost on export (no change) -textframe-gradient.docx: still round-trips OK: no change -textframe-gradient.rtf: round-trips as linear: lost axial-ness (now fixed: tdf#159824) -fdo78663.docx: textbox font fill: still exports as solid: no change I ran the assert check against chart2, oox, and sw Change-Id: Ib16e9488a76b006bf335ff01a38acf7cde69cccb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163675 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-23related 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>
2024-02-23related 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>
2024-02-23Fix warning C4312 when building with MSVC without -Wv:18Mike Kaganski
Discovered by https://gerrit.libreoffice.org/c/core/+/163717 Like these: C:/lo/core/oox/qa/unit/testscene3d.cxx(1): warning C4828: The file contains a character starting at offset 0x21ac that is illegal in the current source character set (codepage 65001). Change-Id: Id1f69b2644ecb5302e15603dd5353a34757e76dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163782 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-23Fix warning C4459 when building with MSVC without -Wv:18Mike Kaganski
Discovered by https://gerrit.libreoffice.org/c/core/+/163717 Like these: C:/lo/core/oox/source/export/shapes.cxx(2411): warning C4459: declaration of 'XML_line' hides global declaration Change-Id: I74738753254ad1c468025d25bfb0bfe21787180f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163779 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-21Fix potentially uninitialized local variable 'fY' used in Windows TBJulien Nabet
Change-Id: I3849d2263de113f09fc3f4839c156c2d0458d718 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163667 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
generated by cgit (git 2.34.1) at 2025-02-02 02:15:36 +0000