summaryrefslogtreecommitdiff
path: root/sw/source/filter/ww8/docxattributeoutput.cxx
AgeCommit message (Collapse)AuthorFilesLines
2024-03-26tdf#158237 Use contains instead of find-endRMZeroFour1-1/+1
As part of the efforts in #158237 to replace older parts of the codebase using find() and end() methods, with contains(), this commit does the needed changes for a few files in the sc and sw modulues. Change-Id: Ibf0a432c537879f5bec8e8912d11150733366689 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165223 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-02-23related tdf#126533 tdf#159824 VML: don't export: negative anglesJustin Luth1-13/+10
and stop an automatic 180 reversal on import. Some documents had gradient reversals on every round trip, typically when the angle was 0-179 (mainly seen in ODT examples, since DOCX/RTF imports defaulted to be angle 180). The negative sign has special meaning, indicating that the start and end colors should be swapped. Well, swapping colors was not intentional in the export logic. Previously there was a mistaken idea that any angles > 180 needed to be swapped on import, and likely that is what prompted this overly complicated formula to try to avoid any angle > 180 during export by allowing negative angles. This tdf#126533 patchset has already eliminated import checks for angles > 180, so now a sane formula can be applied on export. In order to do that, we have to avoid emulating color swaps with 180 degree rotations at import time. So ONLY do color swapping with start/end, and leave the angle alone. That GREATLY helps unit tests (which otherwise would flip-flop the angle and the color start/stop). Very unhelpful was an undocumented, indecipherable inversion when converting to DML angle. Boy, I hope I got this right... make CppunitTest_sw_rtfexport8 \ CPPUNIT_TEST_NAME=testTdf159824_gradientAngle3 make CppunitTest_sw_rtfexport8 \ CPPUNIT_TEST_NAME=testTdf159824_gradientAngle4 make CppunitTest_sw_ooxmlexport7 \ CPPUNIT_TEST_NAME=testTdf126533_axialAngle2 Eliminating the inversion for ooxml7 test is fine since inversion does nothing to an axial. Otherwise, eliminating inversions corresponds to a color swap. Change-Id: I2aae0a7595807569ffc740689ff3840692d6159d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163798 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-23tdf#159793 Save printer paper tray in RTF and DOCXOliver Specht1-2/+10
Saves the paper tray id as w:paperSrc w:first and w:other in docx and \binfsxn and \binsxn in RTF Change-Id: I79004f54aba3b6609d7921afacf815726f7f2678 Change-Id: Ie3c11fffa6a133250b7db69b4e845bccaa8e2280 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163654 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-23related tdf#126533 vml export: fix axial colorsJustin Luth1-7/+25
This is a follow-up from the earlier tdf#65295 clone which removed swapping colors on IMport for axials. Well, tdf#65295 had also removed EXport swap for the linear case, so, now that import doesn't swap, remove the axial export swap too. Additionally, some linear gradients are actually axials, so identify those symmetrical gradients that have identical start/end colors to avoid exporting as a "solid" color. [I tried changing the import to detect it was an axial, but got RTF export failures, chart2 false positives, and unit-test-the-implementation failures.] make CppunitTest_sw_ooxmlexport7 \ CPPUNIT_TEST_NAME=testTdf126533_negativeAxialAngle The only other unit test that hit this code was textframe-gradient.docx - which is dominated by DML import/export. I can see with Word 2003 that this patch fixes the VML export for this unit test file also. Change-Id: I75e993c7c127a861617b14072a98778ddde03a08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163676 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-23related tdf#126533 DOCX: vml export gradientRadial instead of gradientJustin Luth1-7/+11
... for everything except the linear gradients (linear/axial) Interestingly, there was nothing in make sw.check that hit this. make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf126533_pageGradient Change-Id: Id58ed8b312ec29a10ce461ff0e032838b745b11b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163470 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-20docx import: correct redline content-controlsAshod Nakashian1-5/+23
When inserting and deleting content-controls with change-tracking enabled, we hit a few corner-cases that we need to handle more smartly. First, we shouldn't redline the controls themselves, just the placeholder text. Second, we have to take special care to create valid XML structure with the redline tags. Includes unit-test that reproduces the issues and verifies that both saving and loading work as expected. Change-Id: I6af4d0d2c3f0661e7990d5414cc93effc96f0469 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163647 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-16docxattributeoutput.cxx: unnecessary check for GetGraphicJustin Luth1-2/+0
If GetGraphicObject is not null, then bMustWrite. const Graphic* SvxBrushItem::GetGraphic() const const GraphicObject* pGrafObj = GetGraphicObject(); return( pGrafObj ? &( pGrafObj->GetGraphic() ) : nullptr ); Therefore there is no need to check GetGraphic(), since a GraphicObject is guaranteed to have a Graphic. Change-Id: Ie4bbcdc9642afcef85934fa2d4f213099ab23bae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163105 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2024-01-27Drop std::as_const from css::uno::Sequence iterationsMike Kaganski1-10/+10
Obsoleted by commit 2484de6728bd11bb7949003d112f1ece2223c7a1 (Remove non-const Sequence::begin()/end() in internal code, 2021-10-15) and commit fb3c04bd1930eedacd406874e1a285d62bbf27d9 (Drop non-const Sequence::operator[] in internal code, 2021-11-05). Change-Id: Idbafef5d34c0d4771cbbf75b9db9712e504164cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162640 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-15sw: search for alternative weights when embeding on docxJaume Pujantell1-11/+18
Sometimes a docx document might come whith a font with niether normal or bold weight embedded as regular, so when embedding a font in docx search for alternative weights if neither a normal or bold matching font has been found. Change-Id: I95cf2634c392cec6e97e5dd12a90de6e50228ac1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161596 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Ashod Nakashian <ash@collabora.com> (cherry picked from commit 96d52b9e6879df3ab9697a7c0322cda5e08eb9af) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161942 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2024-01-08cid#1545370 COPY_INSTEAD_OF_MOVECaolán McNamara1-2/+2
and cid#1545364 COPY_INSTEAD_OF_MOVE cid#1545363 COPY_INSTEAD_OF_MOVE cid#1545344 COPY_INSTEAD_OF_MOVE cid#1545299 COPY_INSTEAD_OF_MOVE cid#1545287 COPY_INSTEAD_OF_MOVE cid#1545267 COPY_INSTEAD_OF_MOVE cid#1545256 COPY_INSTEAD_OF_MOVE cid#1545226 COPY_INSTEAD_OF_MOVE cid#1545500 COPY_INSTEAD_OF_MOVE cid#1545538 COPY_INSTEAD_OF_MOVE cid#1545618 COPY_INSTEAD_OF_MOVE cid#1545681 COPY_INSTEAD_OF_MOVE cid#1545750 COPY_INSTEAD_OF_MOVE cid#1545778 COPY_INSTEAD_OF_MOVE cid#1545785 COPY_INSTEAD_OF_MOVE cid#1545799 COPY_INSTEAD_OF_MOVE cid#1545847 COPY_INSTEAD_OF_MOVE cid#1545958 COPY_INSTEAD_OF_MOVE cid#1545963 COPY_INSTEAD_OF_MOVE cid#1545990 COPY_INSTEAD_OF_MOVE cid#1546013 COPY_INSTEAD_OF_MOVE cid#1546029 COPY_INSTEAD_OF_MOVE cid#1546079 COPY_INSTEAD_OF_MOVE cid#1546104 COPY_INSTEAD_OF_MOVE cid#1546127 COPY_INSTEAD_OF_MOVE cid#1546133 COPY_INSTEAD_OF_MOVE cid#1546155 COPY_INSTEAD_OF_MOVE cid#1546190 COPY_INSTEAD_OF_MOVE cid#1546216 COPY_INSTEAD_OF_MOVE cid#1546273 COPY_INSTEAD_OF_MOVE cid#1546315 COPY_INSTEAD_OF_MOVE cid#1546326 COPY_INSTEAD_OF_MOVE cid#1546387 COPY_INSTEAD_OF_MOVE accept some reasonable suggestions Change-Id: I7b004086d490c7618d8fe7a21a53cfa8ac1f8408 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161748 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-28Use emplace_back instead of push_back (sw)Julien Nabet1-1/+1
Change-Id: I0a7f70ca0e5cc022425bee3661495cf1104f6521 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161384 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-20cid#1545835 COPY_INSTEAD_OF_MOVECaolán McNamara1-3/+2
and cid#1545830 COPY_INSTEAD_OF_MOVE cid#1545798 COPY_INSTEAD_OF_MOVE cid#1545784 COPY_INSTEAD_OF_MOVE cid#1545753 COPY_INSTEAD_OF_MOVE cid#1545752 COPY_INSTEAD_OF_MOVE cid#1545672 COPY_INSTEAD_OF_MOVE Change-Id: Iaf2f77cb27ae0ea1585416a0c500f7c50d04e3fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161007 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-10cid#1545789 COPY_INSTEAD_OF_MOVECaolán McNamara1-4/+2
and cid#1545791 COPY_INSTEAD_OF_MOVE cid#1545800 COPY_INSTEAD_OF_MOVE cid#1545806 COPY_INSTEAD_OF_MOVE cid#1545817 COPY_INSTEAD_OF_MOVE cid#1545832 COPY_INSTEAD_OF_MOVE cid#1545834 COPY_INSTEAD_OF_MOVE cid#1545841 COPY_INSTEAD_OF_MOVE cid#1545848 COPY_INSTEAD_OF_MOVE cid#1545852 COPY_INSTEAD_OF_MOVE cid#1545854 COPY_INSTEAD_OF_MOVE cid#1545864 COPY_INSTEAD_OF_MOVE cid#1545875 COPY_INSTEAD_OF_MOVE cid#1545882 COPY_INSTEAD_OF_MOVE cid#1545900 COPY_INSTEAD_OF_MOVE cid#1545901 COPY_INSTEAD_OF_MOVE cid#1545908 COPY_INSTEAD_OF_MOVE cid#1545921 COPY_INSTEAD_OF_MOVE cid#1546054 COPY_INSTEAD_OF_MOVE cid#1546145 COPY_INSTEAD_OF_MOVE cid#1546146 COPY_INSTEAD_OF_MOVE Change-Id: I8b23d0457cb293aa0e33593131224c1cdd1d8eb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160545 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-04cid#1546275 Using invalid iteratorJulien Nabet1-1/+3
and : cid#1546219 Using invalid iterator cid#1546088 Using invalid iterator cid#1546070 Using invalid iterator cid#1546061 Using invalid iterator cid#1546055 Using invalid iterator cid#1546049 Using invalid iterator Change-Id: I6f3a786852b5c262d60c3195e446a37967ed9b59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160311 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-12-04tdf#126084 support writing SVG images into OOXML using the MS OOXML extensionTomaž Vajngerl1-1/+15
SVG files aren't supported in OOXML, but we can write it using the MS OOXML extension, which is supported in the latest MSO versions. For now this only implements the support in the exporter. Change-Id: I688180fb5772f3999c2ee3020bc234f90d57cc2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157237 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-11-29Extended loplugin:ostr: swStephan Bergmann1-53/+53
Change-Id: Ie3ceb8d4b939a652d09cc9cf02b78e65093c8fcf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160099 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-19Extended loplugin:ostr: swStephan Bergmann1-82/+82
Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-15avoid double map lookupNoel Grandin1-2/+3
Change-Id: I02018eaaf220c7835756eba6215425bac9cbc6f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159432 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-10-19tdf#157484 UI: Add UI controls for personal information to be keptBalazs Varga1-4/+8
or removed upon save. With the new options button we can keep the security infos upon save such as (even if we set the remove personal infos): - RedLine Info - Document User Info - Author and date of notes - Document version infos Also on the infobar, if we have a warning, clicking on the infobar button the security option dialog will open where we can set/modify these options. follow-up of: 1f440348eb0892fd2c9597806d87b5fe9d60d49a (tdf#157482 UI: Turn Security Warnings popup windows into infobars) Change-Id: I8d5d944d76dbdd31653401246113de097ca6d57b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158112 Tested-by: Jenkins Tested-by: Gabor Kelemen <kelemeng@ubuntu.com> Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-10-18Simplify a bitMike Kaganski1-1/+1
Change-Id: I594b3317f8298966d59f8674b71bddd89998b9f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158092 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-10-11writerfilter: use content controls for text in block SDTsJaume Pujantell1-1/+5
Text inside block SDTs was shown as Text Fields wich ignored properties such as alias and formatting. Now those texts are imported as content controls like in the case of run SDTs. Added the ability for content controls to remember and export the "multiline" property of block SDT text. Some existing tests have been changed due to some different export results. Change-Id: Ice1eb4ca6dd53c99d5abb239371f8ac896c3b6e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156867 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-10-05Revert "tdf#155470 DOCX export: fix RTL numbers changed to LTR"Hossein1-3/+0
This reverts commit 40ed8dd3a5a16f21f2e98440c62efa0fa6ec60ff. Reason for revert: tdf#157598 problem with LTR documents Change-Id: I6f25913df4e308be660070e1eeca81f08c0547ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157547 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-10-04related tdf#157572 docx export framePr: no w:x if zero or xAlignJustin Luth1-2/+2
xAlign has none of the complexities of yAlign. if xAlign is defined, it takes priority over w:x. So simply don't write out an unnecessary w:x if it is the default value (0) or if there is a xAlign. This change is just made to keep the code somewhat consistent between w:x and w:y. Change-Id: I5ef1da309e35e25660247675ba9ab6e336becd41 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157566 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-10-04related tdf#157572 writerfilter framePr: no vAlign if vAnchor=textJustin Luth1-5/+4
See bug 157572 for the documentation. This can be seen in MS Word's UI. Have the vertical position be centered, and then change to "para": -> the vertical position changes to a numbered distance. make CppunitTest_sw_ooxmlexport5 \ CPPUNIT_TEST_NAME=testTdf157572_noVAlignAsText make CppunitTest_sw_ooxmlexport5 \ CPPUNIT_TEST_NAME=testTdf157572_insidiousCombination Change-Id: I6c00a34f14633e16178c1504a37e644a30cf4cd7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157529 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-10-04related tdf#157572 writerfilter framePr: no vAlign if w:y definedJustin Luth1-1/+2
Documentation suggests that vAlign overrides w:y (as long as vAnchor is not equal to text). However, testing proves the opposite. Only when w:y is not defined does vAlign take effect. make CppunitTest_sw_ooxmlexport5 \ CPPUNIT_TEST_NAME=testTdf157572_defaultVAnchor make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf154703_framePr2 Change-Id: I8a5366d9b6bde0ad838f9584836a85fe79ce8b1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157528 Tested-by: Justin Luth <jluth@mail.com> Reviewed-by: Justin Luth <jluth@mail.com>
2023-09-28cid#1545341 Dereference after null checkCaolán McNamara1-4/+4
Change-Id: I58fc2f00667f6e3c12ab5a2d37b6ce923a996817 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157355 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-09-25oox: remove returning sRelId and rename WriteImageTomaž Vajngerl1-3/+3
Rename WriteImage -> writeGraphicToStorage to make it more clear what the method does. Remove returning the rel ID string in some methods that write the graphic into the stream (or the call chain), as it is never used later on, so it is better to not return it if it is not used (it could be abused). Change-Id: I78558671b82aedb34bd0f37bf7781c47ebf1cf5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157235 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-09-18use more concrete UNO types in swNoel Grandin1-4/+3
Change-Id: I04d790ff9247f4a810da975128e91073e285f267 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157014 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-09-14Related: tdf#55160 sw floattable, nested DOCX exp: fix inner tbl at cell startMiklos Vajna1-7/+9
A cut-down bugdoc had an inline table, and an inner floating table, anchored in the start of the C1 cell. Exporting to DOCX resulted in a layout that looks like the floating table is not anchored inside the outer table anymore. Checking the markup, the floating table was written between row 1 & row 2, which is not a valid position for a floating table. Probably the intention was to write the floating table before the first paragraph in C1. Fix the problem by still writing the floating table in DocxAttributeOutput::StartParagraph(), before opening <w:p>, but do this after opening table/row/cell, which is late enough to have a correct anchor but is early enough to be still outside the paragraph. The import side of this still needs fixing. Change-Id: I1827b2def1faaf53312522f5a8415fbe697fcb8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156904 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-09-13tdf#157187 sw tracked table column: fix DOCX exportLászló Németh1-2/+12
DOCX export of tracked table column changes could result dummy content boxes and missing tracked table column changes in MSO, i.e. lost interoperability. As a workaround, skip exporting content boxes within tracked table cells. Note: bad 0x01 characters and incomplete w:sdt export in table cells since commit b5c616d10bff3213840d4893d13b4493de71fa56 "tdf#104823: support for sdt plain text fields". See also commit 4697d2bda1b37f9cf8b301f5bf044c2390f56333 "tdf#157011 sw tracked table column: fix DOCX import of empty cell". Change-Id: I32f77c7532a9cc6bf5d88a626ac3c62a5c02a34a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156895 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-09-12sw floattable, nesting: fix DOCX exportMiklos Vajna1-1/+4
There were two problems here: 1) DocxAttributeOutput::StartParagraph() didn't try to export an inner floating table as a floating table, resulting in writing a shape that can't span over multiple pages. Dropping the !pTextNodeInfo check should be OK, we'll just now clear the m_aFloatingTablesOfParagraph list at the end of the outer table. 2) Once we tried to export the inner fly, the actual table/row/cell start was missing, because m_tableReference.m_nTableDepth wasn't reset, so DocxAttributeOutput::StartParagraph() didn't know it has to emit a table definition before the first para of the table. Fix this by stashing away the table state before the inner fly's export and restoring it after the inner fly export, similar to how this is done in e.g. DocxExport::WriteHeaderFooter(). This is related to tdf#55160. Change-Id: Ib860283d32e392e2906aa12bc9eb61b5af5ca8de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156833 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-08-21tdf#155470 DOCX export: fix RTL numbers changed to LTRHossein1-0/+3
When using numerals in "context" mode in "Tools > Options", in "Language Settings > Complext Text Layout > General Options > Numerals", the actual display of the numbers is dependant on the direction and the language of those numbers. Previously, when exporting the DOCX in LO the RTL direction was lost, and because of that, the numerals were shown incorrectly after saving in LibreOffice, and loading again. This patch adds <w:rtl/> where <w:lang> contains an RTL language. For example, before <w:lang w:bidi="fa-IR"/> inside <w:rPr>, it always adds <w:rtl/>. It is worth noting that this is not always the case, as there are situations that <w:rtl/> is not present in <w:rPr> with an RTL language like <w:lang w:bidi="fa-IR"/> and <w:rtl/> should not be in the output. This patch does not handle that case, because currently loading such a text is not done correctly in LO, and the LTR numbers inside RTL environment are shown just like RTL numbers. To fix it, first loading and displaying of that should be fixed. A test is added to check the export of the sample file, which can be invoked with: make CppunitTest_sw_ooxmlexport CPPUNIT_TEST_NAME=testTdf155470 Change-Id: I8fc54916fcd3295010c5c81ccb632bc6082ffaa2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155721 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-08-20tdf#148834 docxexport: also write suppressLineNumbers = falseJustin Luth1-0/+2
This code also affects DOC export, but shouldn't be detrimental. It just means that some unnecessary sprms will not be added to DOC files. RTF - similar to old DOCX - only outputs if !IsCount, but I didn't find a corresponding "enable" to offset \noline. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf148834_lineNumbering Change-Id: Ib5369c2f2c24f75dab7d02e3591a4ddefa335ebf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155858 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-08-15ComplexColor various clean-up and (trivial) refactoringsTomaž Vajngerl1-9/+8
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-08-01tdf#156548: make truncated long bookmark name unique, and use it in hyperlinksMike Kaganski1-15/+17
Change-Id: I156359339ff8be85fe90cb6612eafdc6030c851f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155092 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-07-13use more frozenNoel Grandin1-3/+6
Change-Id: Ie3e6e7e947d9322f3999cf3274a6c10ea717afe2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154276 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-11tdf#150408: Implement "Legal" numbering (all levels using Arabic numbers)Mike Kaganski1-1/+6
Enabling this feature on a list level makes all numbered sublevels, that constitute the number of this level, to use Arabic numerals. This doesn't change the labels of other levels: e.g., if level 1 uses A,B,C; level 2 uses i,ii,iii; level 3 uses a,b,c, and is "Legal"; and level 4 uses 1,2,3; then a list may look like A. Something A.i. Some subitem A.ii. Another subitem 1.2.1. This is a "Legal" sub-subitem A.ii.a.1. And its child This improves interoperability with Word. This change introduces document model, ODF and OOXML import and export. In ODF, a new boolean attribute of 'text:outline-level-style' element, 'loext:is-legal', is introduced; its default value is "false". Change-Id: I5ae9f970864854c7e84c4b2f7ce46634b3ef104e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154288 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-07-06tdf#141058 oox,sw: OOXML import/export of decorative on shapesMichael Stahl1-14/+1
Also add a test for PPTX (using the oox filters), and add a SdrObject to the testTdf143311 for DOCX (using the writerfilter/docxsdrexport). Change-Id: Iccee46c0d30316c33c0947b117e2604c96fa0182 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154137 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-06-18ooxml: import and export background and fill theme colors props.Tomaž Vajngerl1-7/+21
This adds support to import and export background and fill theme color properties. Change-Id: I0f40615fe2d06cdcb4f2f9752602fe2ec699c7b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152835 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-13DOCX filter: improve handling of negative <w:position> in paragraph stylesMiklos Vajna1-1/+7
The bugdoc has a <w:position w:val="-1"> in its Normal paragraph style, which is almost not visible in Word, but we mapped this to default subscript text in Writer, leading to very visible bad font height in practice. The root of the problem is that <w:position> works with an absolute offset in half-points, while Writer works in percentages, so the import/export code can only do a correct mapping in case the font size is known. This initial mapping was added in commit e70df84352d3670508a4666c97df44f82c1ce934 (try somewhat harder to read w:position (bnc#773061), 2012-08-07), and later commit d71cf6390a89ea6a4fab724e3a7996f28ca33661 (tdf#99602 writerfilter: import subscript into character style, 2019-10-04) gave up on this for character styles. Fix the problem by working with paragraph styles similar to what the binary DOC filter already does, just assuming that the font height from the style won't be overwritten, or will be overwritten together with a matching <w:position>. Do this only for negative <w:position> for now, as that's good enough for our needs. Do the opposite of this at export time. It would be still possible in the future to add native handling for absolute escapements, and then this mapping would not be needed at all. Change-Id: I771c7bed27fa2596153aa77c472c91b819fa4cb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152962 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-06-12ooxml: import and export char underline theme colorsTomaž Vajngerl1-3/+7
This adds support to import and export char underline theme color properties. Change-Id: Ia8948ee5aacd20e0c2b7cbb1b2fdf97fc65c04e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152834 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-12ooxml: import and export border theme colors for various props.Tomaž Vajngerl1-85/+95
This adds support to import and export various border (lines) theme color properties. SvxBoxItem needed to be fixed, because it can happen that the BorderLine is not yet initialised and we already set the border's ComplexColor. Now there is a maTempComplexColor inside SvxBoxItem, which stores the ComplexColor until the specific BorderLine is initialized. In addition add roundtrip test for import and export cycle. Change-Id: Idd307a3adaf364745aed8fc8540bf72ef4948198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152833 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-09fix wrong transform type, error handling when JSON parsingTomaž Vajngerl1-2/+2
also fix theme export - change scheme enum type name "hlink" to "hyperlink" and "folHlink" to "followedHyperlink" Change-Id: Id5435d59cd51352efc4a4a8e333ec1ff45847a6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152782 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-08sw: remove char color GrabBag and fix export, fix tint/shade calc.Tomaž Vajngerl1-27/+92
Don't store values from grab bag when exporting character theme colors and tint/shade values. The values could be wrong now and aren't needed anyway as we support the values in the model. Add proper export support for char color theme information with correct conversion of values into tint/shade values in 0-255 inverted interval. This also fixes the import of tint/shade values whcih calculation was slightly off. We divided by 256 instead of 255, which introduced an error. In addition introduce ThemeColorUsage enum, which marks if the theme color type has a specific "usage" - text or background. This is determined on import if the theme type is background{1,2} or text{1,2}. This is then taken into account on export, so the exact type is preserved. Change-Id: I0022a159397fd0c3d39a118a7149bb2488dfc149 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152705 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-05-15MCGR: consolidations/cleanups for changes so farArmin Le Grand (allotropia)1-1/+1
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-23Fix typoAndrea Gelmini1-1/+1
Change-Id: Ie8c702436d3efbaf2ca1573193100974a42f93a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150459 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-23tdf#97128 tdf#154703 docx export framePr: export frame textDirectionJustin Luth1-0/+25
textDirection attributes were lost on framePr round-tripping No existing unit tests were affected by/matched the change. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf154703_framePrTextDirection Change-Id: I2184b9350391f510c7a2e77096b080e05d3d62da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150820 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-04-22tdf#154703 sw framePr: export knowing import wrap spacing limitationsJustin Luth1-7/+14
I noticed that the wrap margin spacing was being cut in half each round-trip. That is because MS Word ignores the spacing on LEFT or RIGHT alignment, while LO doesn't. Rather than monkey with layout, import just ignored the spacing. Sounds like a good idea - but needed to do the same on export. make CppunitTest_sw_ooxmlexport18 \ CPPUNIT_TEST_NAME=testTdf154703_framePrWrapSpacing Change-Id: I3878d1bdb98cf027fe95137939caf6901c7188a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150796 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-04-21tdf#154703 NFC sw framePr: flatten TextBoxIsFramePr and fix typoJustin Luth1-21/+21
Change-Id: I0fd30cb62c3676a1c7088636798bd4e6d3a18c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150071 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2023-04-21NFC rename: const table::BorderLine2* rStyleProps (is not a reference)Justin Luth1-6/+9
Added with commit ae61569eea0719a882010cfbb260a1a0d690d974 Author: Jacobo Aragunde Pérez on Thu Apr 3 16:27:37 2014 +0200 oox: Do not overwrite table style properties Change-Id: I8140e3a084f3f1e2d304a4ffc62897afa6427c4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150771 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-26 04:45:30 +0000