summaryrefslogtreecommitdiff
path: root/oox/inc
AgeCommit message (Collapse)Author
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-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-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-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-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-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-20Fix typoAndrea Gelmini
Change-Id: I48d719c6e911f84f1609767df4f40f6f8684a0c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163640 Tested-by: Jenkins 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-19tdf#50934: OfPie inport from OOXML, plus initial work for exportKurt Nordback
Change-Id: Ie17b583af28d274b3e7817c646dd4f5873e03fef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160733 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-01-18tdf#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>
2024-01-09tdf#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>
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-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-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: 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-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-12Make NC_ constexpr-friendlyStephan Bergmann
...by moving the char8_t -> char reinterpret_cast out of any potential constexpr paths into a new TranslateId::getId. And demonstrate constexpr'ability by making the aCategories var in OApplicationIconControl::Fill (dbaccess/source/ui/app/AppIconControl.cxx) constexpr. (And there might be more such cases that could now be made constexpr.) Change-Id: I0b4e3292faf8f6b901f9b9e934e1aa6bf0f583ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157862 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11Drop o3tl::span, can use C++20 std::span directly nowStephan Bergmann
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-08-29pptx using Wingdings didn't fallback to OpenSymbolCaolán McNamara
<a:sym typeface="Wingdings" pitchFamily="2" charset="2"/> ^ The charset indicating that it was symbol encoded wasn't applied. There are quite a few uses of GetFontData so make this an optional request and only apply it right now to the problematic case. Change-Id: Ie1c4b9ac38c2bf5f0867d64eddea853a6dd05aad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156230 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-08-16tdf#153012: import chart's c:clrMapOvr elementMike Kaganski
Otherwise, a wrong mapping could be used, e.g. from slide. Change-Id: I8b0fcebcd21ac2bab8b7f58d0c24753d2eca02c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155748 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-07-23vcl: Drop now unneeded DevicePoint typedefKhaled Hosny
It has been always typedef'd to basegfx::B2DPoint since: commit 5e218b5c51f7d9cd10bd9db832879efca41b9c75 Date: Wed Jan 12 21:19:32 2022 +0000 always use B2DPoint for DevicePoint Change-Id: I9f5202d5a71c77dd79f1759923917c26bf68a9af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154632 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-05-12use ComplexColor instead of ThemeColor for better OOXML compat.Tomaž Vajngerl
In OOXML a color definition includes more represenations, one of which is scheme color (which is what is implemented in ThemeColor currently), but it supports other representations too (RGB, HSL, System,..). ComplexColor includes all the representations, so to have a better compatibility with OOXML, this changes all uses of ThemeColor to ComplexColor. In many cases the usage of ComplexColor isn't the same as the usage of ThemeColors, but this cases will need to be changed in a later commit. Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-01docmodel: extract ColorDefinition into own file and renameTomaž Vajngerl
ColorDefinition is renamed into ComplexColor. Change-Id: I81c2d97e6b7bf9de4ce703c02b6db40636b04961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151224 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-04-12oox: add model::EffectStyle and import effect style elements of a themeTomaž Vajngerl
Extends the SwCoreThemeTest with effect style use-cases- Change-Id: Ifcb96a860fcbc0aae65e8ec276e069f7f60fb950 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149361 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-04-12oox: add model::LineStyle and import line style elements of a themeTomaž Vajngerl
Also extend the SwCoreThemeTest with asserts for the LineStyles for the example theme. Change-Id: I72aa64345d39fea84544e39b0a37a22f3e6baa5d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149360 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-04-12oox: add model::BlipFilll and import blip (graphic) fill elementsTomaž Vajngerl
Change-Id: I610b732b1fd4eebcfcc55acb6f04a8acf84f92b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147954 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-04-12oox: add model::PatternFill and import pattern fill elementsTomaž Vajngerl
Change-Id: I49ef33fd81509599f4081e6a913b05dae1e4a642 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147953 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-04-10pptx import/export: consider TextClipVerticalOverflow for vertOverflowSarper Akdemir
Also adds a unit test that tests TextClipVerticalOverflow on 4 different scenarios. Change-Id: I6232935765641c796046d90fe2207d67ae4b3eb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150107 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-03-27tdf#153466 PPTX import: fix "Custom position/size" background imageTibor Nagy
Custom sized background with the value "tile" was imported as "stretched", losing the preset size. Restore also the exported preset positions, and map the other values to the preset positions supported by OpenDocument/Impress. Follow-up to commit 11451781d4c562f506a3aae3732e35b92387b4db (tdf#153105 PPTX export: fix "Custom position/size" background image) Change-Id: Ibf9b487ecd31b3ad7b06bda668c51e6b7a98c4af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148482 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-03-26tdf#90407 Change the auto-fit alg. to match better with OOXMLTomaž Vajngerl
The auto-fit algorithm has been tweaked to be more in-line with the expectations of OOXML. This means a couple of changes to what properties are scaled by the algorithm have been made: - most properties that influence the X axis position or size (for example indent) are not scaled down or changed by scaling. - properties that influence y axis position and size are scaled by a separate parameter (like in the OOXML). This is used in the auto-fit algorithm in a different way. - if line spacing is proportional, it is now scaled with the spacing parameter. Fixed line spacing doesn't get scaled. - the main scaling X,Y parameter only scales the fonts. - trying hard to scale the fonts to the nearest pt (point) value With this change the scaling is much more stable than it was before - for example it doesn't matter what the unscaled font size is, when it is scaled down to the text box size, it (should) always look the same (for example scaling from 32pt -> 10pt or 64pt -> 10pt or even 999pt -> 10pt). The algorithm is also rewritten to be better at finding a fit and is also better at find a good fit, but it can take more iterations by doing so (there are ways to improve it however). Previous algorithm used a linear search to converge to the best fit in less iterations, but the issue with that was that it could in some cases miss a solution (especially since change to floating point scaling parameter). The new algorithm now uses a binary search - always trying the middle of the search space. OOXML export and import was also changed to take advantage of the font scaling and spacing scaling parameters. The additional scaling at export that was needed to have consistent OOXML support was removed. Change-Id: I8f3bb8d43a01931f18bd7ffdf8e0ba40caa73d8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149207 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-03-23oox: import gradient fill to model::FormatSchemeTomaž Vajngerl
Change-Id: I90bc7cf4239f08efbc7239928c34ccdbec20cb2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147575 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-03-22oox: introduce FormatScheme - use in Theme importTomaž Vajngerl
Introduces model::FormatScheme as an member of model::Theme, which is used in the theme import. As an first step it imports FillStyleList, but only SolidFill and NoFill. Change-Id: I14a75782ebabcf7ff69b0872752d411183653a47 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147573 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-03-16tdf#102261: pptx import: handle defTabSzSarper Akdemir
Introduce import of defTabSz using ParaTabStopDefaultDistance. Change-Id: Ied59c2bc5d9dfffa6254ef87849c3dbad4c48d07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148059 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-03-01oox: import directly into docmodel's Theme and ColorSetTomaž Vajngerl
This changes the import to directly fill values of a model::Theme and model::ColorSet, without filling the oox structs first. The goal is to get rid of the oox in the long run, but for now it is necessary to keep reading into both, which is a duplication. The next step is to also fill the FontScheme and FormatScheme structures. Change-Id: I488ec096cbc184bc70d24510ac9091a488540422 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147571 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-02-22Fix typoAndrea Gelmini
Change-Id: Ib61d53a7f48057a7b63d9c0f2e473ea763badaf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147470 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-22tdf#51195 Improve DML export of Fontwork shapes for docxRegina Henschel
Fontwork in Writer has fill and outline as shape properties. The 'abc transform' in Word uses character properties. Output of character properties happens in DocxAttributeOutput methods in LO. The patch modifies the character properties of the Fontwork shape, in particular the contents of the CharInteropGrabBag, so that DocxAttributeOutput produces a reasonably suitable markup. Change-Id: Ic9285d9a4d6dc21cd256e448ace058f1026a2780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146964 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-02-01tdf#153296 improved markup for VML shapetype of FontworkRegina Henschel
In the current version of 'vml-shape-types' file the markup for the Fontwork shapes is missing or is so, that Word does not accept it as WordArt markup. So Word treats it as custom geometry and saves it that way. But LO cannot import custom geometry for WordArt. The patch changes it so, that for Fontwork shapes a dedicated markup map is used with markup, that Word accepts as WordArt. Non-Fontwork shapes still use the 'vml-shape-types' file for VML export. I have added two unit tests. But a true test is not possible, because for that you would need to open and save the files with MS Word. This patch solves at the same time some of the handle problems for the special case of Fontwork shapes, see tdf#152913. Change-Id: Icc5afb88c58b644d25b3cf8d415e5aa2d6a7b19e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146311 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-01-27move Theme class to own file inside docmodelTomaž Vajngerl
Also move Theme from svx to model namespace so it is consistent with other classes in docmodel. Theme header also includes ThemeSupplementalFont, ThemeFont, FontScheme classes that are used by the Theme and were also moved to docmodel. These may be moved to its own file in the future when they are used in more places. Change-Id: Ic409bea8e5298adc2b039b529c4f7b01cf64f03e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146221 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-13support theme color for lines + oox support + testsTomaž Vajngerl
Extended XLineColor to handle model::ThemeColor which then maps to the newly added LineColorThemeData property. Extended oox import and export to map the scheme color elements to and from ThemeColor. Added a new test to check the theme line color in impress shapes. Change-Id: I23ecc18c88b5b47608c9110f5681f189d02e2f36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145071 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-12introduce docmodel comp., model::ThemeColor, use it in SvxColorItemTomaž Vajngerl
Added a new component docmodel, that has the document model types, which only depend on other basic components. This is needed so the types can be used in every relevant component - xmloff, oox, svx, editeng,... Introduces model::ThemeColor, which is a class used to store the theme color data, including transformations (svx::Transformation). For UNO use XThemeColor is added, and the implementation UnoThemeColor which wraps svx::ThemeColor, so it can be tranported around. Reactor all the code and tests to accomodate for this change. Change-Id: I7ce6752cdfaf5e4d3b8e4d90314afa469dd65cfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144847 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-05Removed executable bits from source filesAndrea Gelmini
Change-Id: Ib9fbfc8d52bfddc6af65bf62af3c49767868e032 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144952 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-02tdf#125885 Conversion WordArt to Fontwork in docx importRegina Henschel
docx has the information, that a shape is a WordArt shape, after the text content. So in import of such file there is already a frame attached to the shape, which makes it impossible to set it into text path mode. The patch detects that it should be a WordArt shape. It transfers the text from frame to shape, removes the frame and then sets the shape into text path mode. WordArt in OOXML has the same closed set of types as we have for MS binary import. But MS Word can combine them with arbitrary shapes. The patch does only convert rectangles. The text is copied from frame to the shape as string. Thus it looses all styles. But our Fontwork cannot use different styles for portions of text, so I think that is acceptable. Fontwork uses not the styles of the text but styles set at the shape. The patch copies the styles from the first not empty run. That should give sufficient results in most cases. These text styles are set at the shape, which will result in a paragraph style referenced by the draw:text-style-name attribute of the draw:custom-shape element in ODF. The patch does not yet include export to docx. The current 'restore old shape' on resave to docx is lost. ToDo: Patch for export. Change-Id: I880ee7c7616db50524032e4b1443730a2d0a7361 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143615 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-01oox: add support for importing font scheme into a svx::ThemeTomaž Vajngerl
Change-Id: I862256a17ce84c85174678f3fd03c8ef6661f2c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143995 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-26svx: rename mnPitch to mnPitchFamily, add resolvePitchFamilyTomaž Vajngerl
Rename mnPitch to mnPitchFamily as it contains both. Extract the code to resolve what is pitch and what is family into its own (static) function. Change-Id: I0c17351ea690a85decefb8d73dd07644ce5c78d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143991 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-10-31tdf#113187 exclude angle conversion from count of maGuideListRegina Henschel
The ooxml import uses the special viewBox value '0 0 0 0' to indicate that the point coordinates are relative to shape size and not to viewBox and need special treatment. To detect this case the number of guides in maGuideList was used. But that number might be larger than the guides in ooxml because each arcTo command introduces two additional guides for the conversion from 1/60000 degree in ooxml to degree in LibreOffice. The patch excludes these guides from count. Thus now a path which has no references in its points will get a viewBox with non-zero width and height in all cases and is rendered now. Change-Id: I410638a1fe02f692fd46313c88b5ea518f1d094f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142050 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-10-27tdf#149961 pptx import: fix indents for autofitted texboxesSarper Akdemir
For autofitted textboxes, Impress scales the indents with the text size while PowerPoint doesn't. Scale the indents inversely propotional to autofit font scale so that the visual appearance on import is similar to PowerPoint. Change-Id: I7876b35a1f4221789564fcf23ccbe3fe21db3d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141717 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-09-28use more string_view in ooxNoel Grandin
Change-Id: Ib0d7015a898073d51ac2638d62a19eadcba37685 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140653 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-29 16:07:36 +0000