summaryrefslogtreecommitdiff
path: root/oox/qa/unit
AgeCommit message (Collapse)Author
2023-04-25oox: Harden the testTdf142605_CurveSize Test with extra checksTomaž Vajngerl
Even if it is likely that we fail, it's important that we check that we are checking thr correct shape and not some other shape. As there is only one shape we could assume that in the case that something goes wrong and we wouldn't be able to read the shape, we would end up with 0 shapes, but in case of an empty page we inject placeholder shapes into the page, so we end up comparing the size of a placeholder shape. In this case the test assert gets confusing as we obviously get wrong sizes, which suggest that something is wrong with the shape and not that the shape we expect to assert against is missing and we compare against a different (placeholder) shape. This adds more asserts, which make sure we actually have the expected shape first and also preven crashes if something would go wrong. Change-Id: I435f87d7e634c5135a376ad084373f8d5053555e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150942 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-04-08use shared_ptr for model::Theme instead of unique_ptrTomaž Vajngerl
Also change other cases to use the shared_ptr so there is no need to do copies and replace some of docmodel/theme/Theme.hxximports with forward declarations. Change-Id: I4588cb25e05e5f3e535011fffb68a8075b05aecc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147691 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-03-20tdf#154071 UI rename gradient back to 'Rectangular'...Regina Henschel
Commit e97e62a4707e09739f9c00f8fc4a943f0123a9cf had wrongly changed 'Rectangular' to 'Square' (API RECT, ODF rectangle) and 'Square' to 'Quadratic' (API SQUARE, ODF square). This patch reverts 'Square' to 'Rectangular' and 'Quadratic' to 'Square (Quadratic)'. It uses 'Square (Quadratic)' instead of simple 'Square' to help users to find the correct type. In addition, use of the wrong type names in comments is fixed. Change-Id: Ibbd90be2cceb65c9857e473cb74c39df1b9530f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149004 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-03-16XmlTestTools: factor out common codeXisco Fauli
Change-Id: Ie212c86c6c0ac20878be88d88ade5eb1c989942d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148935 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-03-14tdf#139618 Add WordArt fill types in pptx importRegina Henschel
This fix uses a similar approach as in WpsContext::onEndElement, only that here moTextOutlineProperties and maFillProperties are still available whereas in WpsContext the properties need to be collected from CharInteropGrabBag. I have adapted unit test testTdf125573_FontworkScaleX because now the gradient is imported, see comment in former version of the test. Change-Id: I989ee475867c97b9f93c7e65cd25483611eec7bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148687 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-03-11Fix typoAndrea Gelmini
Change-Id: I37f1f41b93f1ec2a428e71fbbaa64437214d565e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148542 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-09tdf#51195 add docx export of gradient fill of Fontwork shapesRegina Henschel
FillGradient, which is a awt::Gradient, has many features which cannot be represented in the <w14:textFill> element in docx. Therefore often only workarounds are possible. ELLIPTICAL and RADIAL are exported to 'circle', SQUARE and RECT to 'rect'. 'Angle' is ignored. A focus point is used instead of a focus line. LINEAR and AXIAL are exported to 'lin'. AXIAL is done be compress and mirroring the color stops. Using Words feature of reflecting a gradient would prevent detecting 'axial' in the current import filter. 'Border' is exported by introducing additional color stops. 'StepCount' is ignored. A workaround using additional color stops is possible, but would require a simultaneous change of the import filter. 'StartIntensity' and 'EndIntensity' are exported as 'lumMod'. Theme colors are considered where they can currently occur. But tdf#151882 is yet not fixed, so Word will not render them because of missing Theme folder. To allow 'lumMod' and theme color and RGB color as well, the color of a color stop is hold in a struct. In case of two color stops, the color stop at position 0% is doubled. That way Word uses the same linear color transition as LO and not its quadratic one. AXIAL too introduces two color stops at position 50%. Emulating 'StepCount' would produce two color stops at same position too. Therefore a std::multimap is used for the color stops. The implementation has a lot local parts. If they should be useful for Fontwork shapes in Impress/Draw, they can be moved and adapted later. The implementation separates the calculation of the required color stops from the generation of the markup, so using parts in Impress/Draw is likely possible. Change-Id: I1032ab8d37b6f112d66f85a30210ebda3ae54486 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148354 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-03-08tdf#141908 - CppUnittests: replace usage of sal_Int32 with colorsVinit Agarwal
modified: oox/qa/unit/drawingml.cxx Line number 168 Changed from sal_Int32 to Color which was declared on Line 162 Line number 290 Changed from sal_Int32 to Color which was declared on Line 288 Change-Id: If19b31c54639f1796d5e6375350bec91ec3f79d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148296 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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-03tdf#153246 VML export write adj attribute for FontworkRegina Henschel
The fix for tdf#153296 has introduced correct shapetype markup for Fontwork shapes so that handles are moveable in Word. But the actual adjustment value of the handle was not exported. This patch adds the missing 'adj' attribute to the <v:shape> element. The fix is restricted to the preset Fontwork types because for other shapetypes the VML export is not yet suitable in regard to handles. Change-Id: I7ecda9e63d50ab7d8c1fda3e09f7383546ddaf5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146537 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-02-02tdf#153258 VML import improve WordArt detectionRegina Henschel
There exists WordArt types whose internal name do not start with 'fontwork', e.g. mso_sptTextDeflateInflateDeflate has 'mso-spt167'. The fix uses the MSO_SPT enum directly. Change-Id: Idb32b3ef9957bef5d948e1d86507d71fef006e91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146503 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
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-31sd: use XTheme to transport the theme to xmloff import/exportTomaž Vajngerl
Refactor the existing places and tests in Impress code (sd) to use it instead. Also keep the old property of construction and view of the theme with a sequence of property values, but under the new property named "ThemeUnoRepresentation". This is needed by the UI tests currently. Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-30tdf#153260 VML export write trim value true in any caseRegina Henschel
LO renders Fontwork shapes always so as if trim=true is set. But the default value for trim attribute is 'false'. Therefore always write out 'true'. Otherwise the import will treat it as 'false' and apply the shape height reducing workaround. Change-Id: I626c5a84627f16011198a9a4e35d8fedf1fd1b3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146361 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-01-26tdf#128568 more font properties in VML Fontwork exportRegina Henschel
When export a Fontwork shape to VML then currently only font name and size is exported. The patch adds style 'italic', weight 'bold' and the special properties 'Character spacing' and 'SameLetterHeights' of Fontwork shapes. Change-Id: Ifb7b42ab6c63e12f5f672e670a3bde5bcf20b1aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146148 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-01-22tdf#128568 Improve export to docx of Fontwork with bitmap fillRegina Henschel
The modern 'abc transform' in Word is not able to use bitmap fill, but it is possible in legacy VML. Thus use VML in such cases. A WordArt shape in VML has the text not in a <txbxContent> element but as string='...' attribute in the <v:textpath> element. To detect whether a custom shape is a Fontwork in an easy way without cast, I have added the already for custom shapes existing method IsTextPath() to the basis class SdrObject. Using VML for Fontwork with bitmap fill, errors in the VML code become visible: * Using <v:imagedata> element results in Word in a picture of the shape. The shape itself was lost. A bitmap fill of a shape has to be written with the <v:fill> element. * Mode 'stretched' in LO UI becomes type='frame' attribute in VML. I have adapted the unit test NoFillAttrInImagedata in ooxmlexport2.cxx in sw. The source file has the background image in a v:fill element. If you replace the 'wps' namespace with a 'my' namespace in the file generated by LO and so force Word to use the Fallback, you will see that with v:imagedata Word does not show a background image. Thus the assumption in the test was wrong, that there has to be a v:imagedata element. Change-Id: I6b2b5b8bb19adcee3b41e536419556465e85d135 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145823 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
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-13oox: also allow tint and shade for fill colorTomaž Vajngerl
This was an obsolete limitation that is not needed anymore. Change-Id: Ie9610516996fc16197f8611843ff621b8a83ebdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145084 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-13xmloff: use XThemeColor in ODF, change the format for themesTomaž Vajngerl
Change the xmloff filter to use XThemeColor and the associated proprties (CharColorThemeReference and FillColorThemeReference). Change the ODF format for referencing a theme color - make it an element instead a series of attributes on the *-properties style element. Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-13introduce {Char,Fill}ColorThemeReference which uses XThemeColorTomaž Vajngerl
Adds a unified UNO property for theme colors *ColorTheme (CharColorTheme and FillColorTheme) which uses XThemeColor, that replaces the properties *Theme, *TintOrShade, *LumOff, *LumMod. The properties are still present for backwards compatibility and to keep ODF support working in tests as that needs a bigger change. Reactor the code and tests to accomodate for this change. Change-Id: If7983decb4ba528b49fe7b5968aa9efc696a9efc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144783 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-06tdf#152896 do not apply color shading twiceRegina Henschel
If a character theme color is shaded, Word writes this as w:themeShade attribute of the w:color element. If the character also has transparency, Word writes an additional w14:textFill element with a w14:lumMod child element. In such cases the w14:textFill element supersedes the w:color element. The initial implementation of Fontwork import in commit cbf30153a5c776e6d1ee26f2f83c8f77503eceb9 does it wrong. It replaces the color itself but not the color transformation, so that the shading was applied twice, once from w:themeShade attribute and the other time from w14:lumMod. The solution here is to reverse the order so that w:color is only evaluated if w14:textFill is not present. Another solution would have been to clear the color transformation vector before adding the values from w14:textFill. I use reverse order here because it more clearly reflects that w14:textFill supersedes w:color. Change-Id: I3e700795167a34238ea619b9c4a691c10da357f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145150 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-01-05Fix typoAndrea Gelmini
Change-Id: Icde32c862bb498af0908399b388973db4d7f8b02 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145074 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-05tdf#152840 add ST_ThemeColor values to ClrScheme::getColorRegina Henschel
... and Color::getSchemeColorIndex(). Without the fix it was not in all cases detected, that a theme color was used, so the FillColorTheme or the CharColorTheme property had got value '-1'. In case of WordArt in docx import, the color could not be determined and the text was black. Change-Id: I81cdb22d6b3c30bf9923b9069ba2e384ac5b3a1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145021 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-01-03-Werror=maybe-uninitializedStephan Bergmann
(Adding just CPPUNIT_ASSERT wasn't enough to silence the warnings at least for my GCC 13 trunk build, so also added the redundant initializations.) Change-Id: I8ec9e097d4725d22dd90e9278a37768a749e292d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144943 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-02Fix typoAndrea Gelmini
Change-Id: I06b51dc7435c1c534c9f9d9b67ea2c54c7f5f1c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144953 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>
2022-11-24Remove some unused includesMiklos Vajna
Mostly com/sun/star/frame/Desktop.hpp is unused after inheriting from UnoApiTest. Change-Id: Ifba307353a11a14e033a230a291314bee86b51c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143190 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-12tdf#125085 PPTX WordArt import: get shape font from runRegina Henschel
PPTX uses the settings at the run for the text in a WordArt shape. LO uses the settings of the shape. The patch copies the run font and language properties to the shape. In addition I have split the old method lcl_createPresetShape and renamed the parts. Now the method lcl_putCustomShapeIntoTextPathMode contains the geometry changes to put a CustomShape into text path mode and to adapt the OOXML values to the values needed for our preset Fontwork shapes, which are based on binary MS Office. MS Office has the style of the characters of a WordArt as properties of the run. LibreOffice ignores most of the properties specified in the style of a span element, when the text is displayed as Fontwork. Instead LO uses the properties defined for the shape for styling the text. Copying the text properties to the shape is now done in method lcl_copyCharPropsToShape. The values in testTdf125573_FontWorkScaleX depend on the used Font. Since on creation time wrong Fonts were used and now correct Fonts are imported, the values have to be updated. Import of fill and stroke of the characters is still missing, only a rudimentary import of color for solid fill exists. Change-Id: I6f31fe07fb0656b2ce8581e7123265fa598ac9c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142421 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-11-08UnoApiTest: simplify code by using tempfile memberXisco Fauli
SwModelTestBase does the same. this will help to make SwModelTestBase inherit from UnoApiTest Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-07tdf#141908 - CppUnittests: replace usage of sal_Int32 with colorsNalini Prasad Dash
Change-Id: Icdf2a5e7c0bd738f2cffbc0b7e99b1bd90a6dcce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141685 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2022-11-03UnoApiTest: make mbSkipValidation privateXisco Fauli
Change-Id: Icc292b40b3295e7890f81d448bb4907725f46970 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142245 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-03UnoApiXmlTest: add new wrapper for XmlTestTools testsXisco Fauli
Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-03swmodeltestbase: remove duplicated codeXisco Fauli
parseExportStream is already in MacrosTest Change-Id: Ibde88b176db1521966b6877bda90e06c278c397d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142218 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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-28tdf#54095 docx SmartArt import, apply theme text colorRegina Henschel
PPTShapeGroupContext uses method applyFontRefColor in importExtDrawings to bring the theme text color to the shape text. The patch copies this way to ShapeContextHandler, which is used for SmartArt in docx. Change-Id: Ie0c0453d6a1fd73fbd4b65246aed9570646dc6f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141992 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-10-26CppunitTest_oox_vml: Inherit from UnoApiTestXisco Fauli
Change-Id: I8c9fe639c448f1fb84449e065dfa05bd1c37ea34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141861 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-26CppunitTest_oox_mathml: inherit from UnoApiTestXisco Fauli
Change-Id: I163fd8d635a18c1dd03eaa50720d10d4fe78d4cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141857 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-26CppunitTest_oox_shape: inherit from UnoApiTestXisco Fauli
Change-Id: I2f8465713c3a2b57faea62d6022e4735d50eb950 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141858 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-25CppunitTest_oox_export: inherit from UnoApiTestXisco Fauli
Change-Id: I46ae3ce5b1fdf6ef5c9d9a22cd589ed04d08ca2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141802 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-25CppunitTest_oox_drawingml: inherit from UnoApiTestXisco Fauli
Change-Id: I1bfea3ac8f07cd5a13ee78ce94fb04bfe55fa5b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141799 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-18tdf#151518 Do not tweak text area distances in WriterRegina Henschel
The fix for tdf#148321 has introduced tweaks to the upper and lower text distances for the case, that their sum is larger than the text area height. That works well in import from PowerPoint but conflicts with import of SmartArt shapes from Word. Reason of the problem is not only the missing Twip to Hmm conversion in TextBodyProperties::readjustTextDistances(). But I have not found which detail in the tweak produces the wrong text location. For now I have disabled the tweak for import from Word. Maybe someone finds a better solution in future. Because the user cannot insert such large distances in Word and SmartArt shapes do not use such distances anyway, I think it does not harm to disable the method for text documents. Import from Excel cannot be tested because of tdf#83671. Change-Id: I2e133f6864bba4419ad96e94d88aec86fe97d0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141414 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins
2022-09-29split utl::TempFile into fast and named variantsNoel Grandin
which makes it easier to know what each variant requires to stay on it's happy path Change-Id: I3275a2543573367714bc78092e882f6535507285 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140469 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-28tdf#124333 PPTX import: fix Z-order of embedded OLE objectsTünde Tóth
Choose mc:Choice in a:graphicData element if the selected p:oleObj element has a shape id to avoid of shape duplication which created also bad layout/overlapping because of the different Z-order of the duplicated shape. Change-Id: Idecff4903c2d637bc82353f13352cac72413cec1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140041 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2022-09-19tdf#151008 adapt anchor for eaVert and mongolianVertRegina Henschel
MS Office and LibreOffice act different whether anchor positions are rotated for vertical writing modes eaVert and mongolianVert. The patch converts the position on import and export. Currently shapes are not able to render mongolianVert. Nevertheless it is included so that the text block has already the correct position and the original position is restored on export. LibreOffice has vertical anchor alignments BOTTOM, that would require a third horizontal position in MS Office, which does not exist. It is mapped to anchorCtr='1' instead. Such does not occur in pptx-LO-pptx round-trip. Change-Id: I1b0e42a39ce3aba12cdb271b2aa8023dacb9c53d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140118 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2022-07-24Fix typoAndrea Gelmini
Change-Id: Ia6c5e8615cc1438664f2208b6b1fc5f0383840ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137392 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-07-23tdf#149538 no text area rotation if upright exportedRegina Henschel
This is a followup to commit 7e23cbdb. With that commit the attribute 'upright' is correctly emulated by a rotation of the text area rectangle. But I forgot to remove this rotation when the 'upright' attribute is used on export. Change-Id: I46d0f421be8ef6b44537134c73dc1e4326ba7e1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137368 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
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-05-12tdf#148961 sd theme: add PPTX export for shape fill color effectsMiklos Vajna
Which allows taking the fill color theme index from the model even in case there are effects. Previously effects meant reading from the grab-bag, and only the no-effect case read the color theme index from the doc model. Change-Id: Ib50c3128b971a388f14ad721ed7f73043916a736 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134208 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-05-06tdf#148929 sd theme: limit PPTX import for shape fill effects to lum mod/offMiklos Vajna
Regression from 30735bdb5a0a81619000fdd24b2d0fbf45687f01 (sd theme: add PPTX import for shape fill color effects, 2022-04-27), the bugdoc's A2 cell lost its tinting (its background color is no longer lighter than A1) after saving back to PPTX + import again. The code assumed that in case a fill color has effects, it can only be luminance offset or modulation, since that's what the PowerPoint UI generates when setting a fill color explicitly. This did not take the table style case into account, which uses tinting to make a color lighter. Fix the problem by not importing the theme index / effects if tinting is used -- the current doc model is limited to theme index + lum mod/off with effects. This limitation can be removed while text color / fill color effects are not limited to lum mod/off, but also support tinting/shading. Change-Id: I382cc0067518cc262e261a462999170cb7db261b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133908 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-04-27tdf#148784 consider StretchX in OOXML exportRegina Henschel
The export to custGeom uses currently a static version of the shape. Its vertices are calculated with EnhancedCustomShape2d::GetParameter(). That has parameters to determine whether ReplaceGeoWidth and ReplaceGeoHeight has to be used. It needs to be used, in case the shape has property StretchX or StretchY. That was missing. It is added now in cases where GetParameter() returns a coordinate. Not all cases are covered by unit tests. Further files for manual testing are attached to the bug. Change-Id: Idcdd081f855ed6c4e3a84dba08f8a2148ddfe54c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133463 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
generated by cgit (git 2.34.1) at 2025-01-11 07:40:16 +0000