summaryrefslogtreecommitdiff
path: root/oox/inc
AgeCommit message (Collapse)Author
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>
2022-09-20tdf#89928 pptx import: implement import of BiLevel thresholdSarper Akdemir
Implement import BiLevel effect's threshold value. If threshold isn't exactly 50%, we can't map it to the doc model. Therefore as a workaround apply the BiLevel (Black/White) effect with specified threshold directly to the graphic. Change-Id: Ib24d149d74b103d926560708c68bb937b02c4cfe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140136 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-09-15Add documentation for data table added classes and functionsTomaž Vajngerl
Change-Id: Idc9756bf5b468d8ed0d11e6a75703d96350e1273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139960 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-09-14tdf#149551 use 'WritingMode' instead of TextPreRotateAngleRegina Henschel
Commit 7e23cbdbb6ec0247a29ed8a8f744c01e10963ea0 changed the code so, that TextPreRotateAngle is used to track ooxml vert attribute. This patch changes it so, that the style attribute WritingMode is used. Now text direction can be written in 'writing-mode' attribute in the graphic properties in ODF, same for shapes as for frames. The needed conversion from WritingMode BT-LR and TB_LR90 to TextPreRotateAngle for rendering of text in custom shapes is now in one place in class SdrObjectCustomshape. The shape edit engine cannot yet render it itself. Some unit tests are adapted to use WritingMode property instead of TextPreRotateAngle. The value text::WritingMode2::TB_RL90 is introduced, corresponding to vert='vert' and textDirection='tbRl' or ='rl' in OOXML. It is used for frames too, so that the original text direction is preserved and vert='eaVert' can be distinguished from vert='vert'. TextPreRotateAngle is currently still used in SmartArt import for 'upr' and 'grav' and in emulating 'upright' but no longer to emulate text direction. Change-Id: Idc4339bbfc3592fe90b154d75e2c404a1fa30856 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138813 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann
...so that its TOOLS_WARN_EXCEPTION can be used in comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it, rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The comphelper module is sufficiently low-level for this immediate use case, so use that at least for now; o3tl might be even more suitable but doesn't have a Library until now. Also, for the immediate use case it would have sufficed to only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION, TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of include/tools/diagnose_ex.h into an additional new include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move the complete include file as is.) Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-02clang-tidy modernize-pass-by-value in ooxNoel Grandin
Change-Id: Ia553a24693f2ffc0f580c9869b82f0d01a1a0ffb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137693 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-20tdf#149551 separate TextRotateAngle from TextPreRotateAngleRegina Henschel
The import filter had only one member for both and had it mapped to TextPreRotateAngle. That resulted in lost text area rotation when a shape had both types of rotations, and sheared text when only text area rotation existed. The patch introduces a new 'moTextAreaRotation' member for the 'rot' attribute of the <bodyPr> element. It is mapped to 'TextRotateAngle' property. It becomes the 'draw:text-rotate-angle' attribute of the <draw:enhanced-geometry> element for a shape and 'style:rotate-angle' for chart elements in ODF. It must also be used to simulate 'upright' and is used for the 'rot' attribute in <txXfrm> of diagram shapes. The 'moRotation' member is now only used for the 'TextPreRotateAngle' property. That angle describes a rotation of the text without changing the text area. Valid values are multiples of 90deg. It is used for simulating vertical writing modes that are not yet implemented. It has no corresponding attribute in ODF. To make the meaning clear in code, the member is renamed to 'moTextPreRotation'. MS Office recalutes a diagram on file opening from layout.xml and data.xml. That is not yet implemented in LO, but we use drawing.xml, which gives the state of the diagram at time of saving. The patch handles the 'rot' attribute of <txXfrm> element as well. It has to be mapped to moTextAreaRotation, because it might contain angles, which are not multiples of 90deg, for example diagram 'Gear'. The <off> and <ext> child elements of <txXfrm> describe the actual used text area rectangle. The existing import calculates the difference of the actual used text area rectangle to the predefined one and incorporates it into the TextArea*Distance attributes. The patch adds calculating the current values of the text area rectangle as it would be using the preset markup. At that time in import there is no SdrObjCustomShape object, thus we cannot use its GetTextBounds() method. So it is down manually, covering most of those types, which are used in diagrams of MS Office. Remarks to unit tests: Now the rotation introduced by txXfrm is no longer in TextPreRotateAngle, but in TextRotateAngle. According changes are in SdImportTest::testN86510_2 Test, testFdo87488 Now the correct preset text area rectangles are used. That requires adaption of the needed distances. Done in SdImportTest::testBnc870237() SdImportTest::testTdf93830() SdImportTestSmartArt::testTdf134221() The buggy 'upright' export is fixed. Adaption in ScExportTest2::testTdf137000_handle_upright() Change-Id: I79df1559f88b76e96988fe745304dc4162de6316 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136447 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-07-17oox: support reading text and shape properties for a data tableTomaž Vajngerl
Change-Id: I740d3bd6af11457ecb54878be648ad1e22b9d4b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137153 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-07-17cid#1506711 Uncaught exceptionCaolán McNamara
and cid#1506712 Uncaught exception cid#1506713 Uncaught exception Change-Id: I8f9753369cb3c85e5f6b910b00aaf553db62750b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137144 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-06-27replace oox::OptValue with std::optionalNoel Grandin
Change-Id: I16e7179b2851640b4d73665685dcc1e84042ddaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136270 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-23 20:29:48 +0000