summaryrefslogtreecommitdiff
path: root/oox/qa/unit
AgeCommit message (Collapse)Author
5 daystdf#157019 PPTX import: Workaround for object placeholder shape presetTibor Nagy
Follow-up to commit Ic8a8ab3f6dfb7367ecd2c619ce888bf77abef460 "tdf#132557: PPTX import: Workaround for slide footer shape presets" note: This is a workaround because there is no custom shape support for placeholder shapes in LibreOffice. Change-Id: Iefb9d97e0eb10a04c39b515b11e549aeb7be8f25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169626 Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de> Tested-by: Jenkins
7 daystdf#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 Change-Id: I246430148e3b3c927e010f360fa317e8429c82d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169533 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
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-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-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-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-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-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-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-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-20docx 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. Change-Id: I6af4d0d2c3f0661e7990d5414cc93effc96f0469 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163647 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-20Remove exec bits from source fileAndrea Gelmini
Change-Id: I8ab5fc146f5787196db51fa45efd2639d8108107 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163641 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-19tdf#70039 convert 3D effects to extrusionRegina Henschel
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 <sarper.akdemir.extern@allotropia.de> Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-10tdf#141908: replace usage of sal_Int32 with colorsvarshneydevansh
Change-Id: I71d94239c155f41d4535c023ea3aa8f974fcf2da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163082 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2024-02-02sw: 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>
2024-01-17tdf#141908: replace hex colors with color keywordsLuv Sharma
Change-Id: I3d23186045c17006e50d9ef48bc26df3c79d28b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162052 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-01-17tdf#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>
2024-01-03UnoApiTest::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>
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-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-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: I912f5e5a035d00e7640d489b1ff1c7a3c0315b9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159442 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-15Import Wordprocessing Canvas, wpc:wpc elementRegina Henschel
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 <vmiklos@collabora.com>
2023-10-20Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: ooxStephan Bergmann
Change-Id: Ic5bcb44fbe56804e23bcdfd039a77c010858ca02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158206 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-14tdf#141908 change sal_Int32 to Colorkhushishikhu
Change-Id: I0f9b0bd18fd90c05de67525222be41ef6cd8723c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157935 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-10-07tdf#156902 Do not set glow on group shape in importRegina Henschel
Currently a group is not able to use glow. But in MS Office it is possible. When we try to set glow at the group, we produce an exception and no children are imported. So for now the patch prevents setting glow. Change-Id: Ifa7245ebf3c38f8685239c2b62eefccd35aab870 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157679 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-10-07loplugin:ostr: automatic rewriteStephan Bergmann
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2023-10-04tdf#157289 normalize ellipse bounding box in oox exportRegina Henschel
The predefined geometry of a circular arrow shape has bottom-right vertex first and then top-left vertex of the bounding box of the ellipse. We now use the normalized rectangle to calculate the radii of the ellipse. Before this patch the calculation had resulted in negative radii. Because the ODF standard only states, '(x1, y1) and (x2, y2) define the bounding box of an ellipse.', but not which vertices to use, the fix is not made in changing the geometry of the circular arrow. Instead the export is changed to use the normalized rectangle. That is more general and will cover other shape types too. Especially non-primivite shapes might use other vertices than top-left and bottom-right to determine the ellipse. Change-Id: Ica859c9adc508a6517e30f111cd54518ec9929a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157526 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-08-30tdf#156835 - FILEOPEN XLSX: add SHA-384 encryption support for ooxml importBalazs Varga
Password protected file with SHA-384 encryption does not open before this patch. Change-Id: I482233f788b8e9da210ad6d2a6c4ece18d05d248 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156282 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2023-08-21move BGradient to awt::Gradient2 UNO conversion into docmodelTomaž Vajngerl
This is needed because the module dependencies are an issues if the conversion is done in basegfx. The bigger issue will come when the ComplexColor conversion will be done as basegfx can't depend on docmodel because of circular dependencies. The BGradient is also more suitable for docmodel anyway as the previously it was part of the model and is not a basic (gfx) type - however this doesn't move the whole BGradient into docmodel yet. Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-21Tests with color stops to assert Color and not BColor valuesTomaž Vajngerl
For testing color stops of a gradient we don't need to assert super precise values (doubls to the n-th decimal point) as long the end results in the same (8-bit) Color value. So change the tests to convert the BColor that is in gradient color stops to Color and assert the Color value. Change-Id: Ibd7661e2f72955a0778e822df1fae568973be357 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155360 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-08-15ComplexColor various clean-up and (trivial) refactoringsTomaž Vajngerl
Don't allow access to member variables of ComplexColor and makes them private. Needs a lot of changes. Change "scheme" to "theme" to be more consistent. In LO we usually call the "theme color" what is usually refered to as "scheme color" in OOXML, where it is sometimes refered to as "scheme" and other times as theme color. Remove ThemeColor class which was replaced with CmplexColor some time ago. Remove un-needed includes and un-needed components. Use isValidThemeColor in many places where we check that the ComplexColor is of "Theme" type and that ThemeColorType is set to a valid value. Change-Id: I325595fa65b8e56a4707e9d22acc6330aac28961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155359 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-27loplugin:stringstatic look for more stringsNoel Grandin
that can be initialised at compile-time instead of runtime Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-26Fix typoAndrea Gelmini
Change-Id: Ic071259d68e0fa9d7a2541e32d30c11bb0f21d2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153612 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-20tdf#155827 MCGR: Axial to linear in oox export, apply...Regina Henschel
... separately for color and transparency gradient. The current solution had the change from axial to linear applied to color and transparency gradient at the same time. That resulted in wrong gradient if only one of them was axial. Because changing axial to linear changes the number of stops, it has to be applied before color and transparency gradients are synchronized. As now color and transparency are both linear already after they are synchronized, the switch can be replaced with a simple if. Change-Id: I75e6b495782bc8a9fe94504426efadec2f60b61f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153197 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-16Fix typoAndrea Gelmini
Change-Id: I05a77aedfed9ea8dffed134d6748151c88dc4c7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153184 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-16tdf#155852 same method for StepCount in OOXML as in renderingRegina Henschel
Rendering of stepped gradients uses a method that doesn't take the color from a cut point, but before or after respectively. For example, for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1 are used. So sections are 'start color', '1/3 color', '2/3 color' and 'end color'. The output to OOXML now uses the same method. That way rendering in a produced pptx-file is the same as in the original odp-file. Since OOXML has nothing similar to StepCount, it is an export only problem. A second problem comes from the cuddle with StepCount in Gradient struct in API and FillStepCount in shape property set. The draw:gradient-stop-count attribute in ODF belongs to the graphic style of the shape. The gradient definition itself in the <draw:gradient> element has nothing about step count. When a file is opened, it can be that the StepCount component in the Gradient struct still has the default value 0, but the FillStepCount property has the correct value of the shape. The Gradient struct in the API should not have a component StepCount to be compatible with ODF. But the API is published and changing that struct is far-reaching in the code. So the fix here is not a general solution but solves the problem for export to OOXML by reading the FillStepCount property while exporting. Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-14tdf155825 result same size in synchronize gradientsRegina Henschel
While synchronizing color and transparency gradients two new sequences are generated. In case the last offsets where different, the remaining stops where not copied to the new sequence and thus they had different sizes which triggered an assert in oox/source/export/drawingml.cxx. Change-Id: I446f8cfafb23735f06ad4e05eee8c922141b864d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153063 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-06-14MCGR: Use BGradient in export of Fontwork to docx tooRegina Henschel
Transparency values are not exactly like in UI because converting through rgb-color adds rounding inaccuracy. The unit tests are adjusted accordingly. With only start and end values it was possible to use the UI values directly. It would be possible to make special cases for front and back value, but I think it is not worth the effort. The previous solution had the error, that the stops were not mirrored in case of non linear gradient. That is corrected now. The unit tests are adjusted. The previous solution had assumed that our 'intensity' at start or end colors is the same as the 'lumMod' attribute in OOXML. However, this is not the case. So now the 'intensity' is incorporated into the color. Again, the unit tests are adjusted. Change-Id: Id02e455dc09d12c5b453637fcb2bdc4f8f1529d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152839 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-08sw: remove char color GrabBag and fix export, fix tint/shade calc.Tomaž Vajngerl
Don't store values from grab bag when exporting character theme colors and tint/shade values. The values could be wrong now and aren't needed anyway as we support the values in the model. Add proper export support for char color theme information with correct conversion of values into tint/shade values in 0-255 inverted interval. This also fixes the import of tint/shade values whcih calculation was slightly off. We divided by 256 instead of 255, which introduced an error. In addition introduce ThemeColorUsage enum, which marks if the theme color type has a specific "usage" - text or background. This is determined on import if the theme type is background{1,2} or text{1,2}. This is then taken into account on export, so the exact type is preserved. Change-Id: I0022a159397fd0c3d39a118a7149bb2488dfc149 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152705 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-27xmloff: add color-type attribute to complex colorTomaž Vajngerl
We need to identify what the color type of the complex color is. For now we mostly use "theme", but in the future we can also have other types like "rgb",... when the infrastructure for that is built. Change-Id: I38c91d294a191ca3124be4e99050977c9815d23e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152253 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-25xmloff: rename theme color names and color-table to theme-colorsTomaž Vajngerl
For ODF it's not needed to abbreviate names and we prefer to use full names. The theme color names in OOXML are abbreviated and the same names were used also for ODF - this was changed now. "color-table" used in "theme" element has reused the already existing "color-table" element name in ODF, but they don't relate to each other. The name was changed to "theme-colors", which makes more sense anyway. Change-Id: I61ec91895d301ad4343f2b977d5cbcf38e360b99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152252 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-25xmloff: rename *-color-theme-reference to *-complex-colorTomaž Vajngerl
Change-Id: I63dd83522da7699162eb06a019a679d4b8750d10 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152053 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-21tdf#155412 ooxml export typeface attribute is mandatoryRegina Henschel
The attribute 'typeface' is required for <a:ea>, <a:cs> and <a:latin> elements, see CT_TextFont in ISO/IEC 29500-1:2016. Its value may be the empty string. Change-Id: I7c9316fa40ad6d1aabccb4191fee11be553c453b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152024 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
generated by cgit (git 2.34.1) at 2024-07-03 00:41:06 +0000