summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2020-10-09cid#1467971 Uninitialized scalar fieldCaolán McNamara
Change-Id: I3995a0113046591c136b4b2d2945416e41fe4f0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104102 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-06loplugin:const* make some params and methods constNoel
Change-Id: I97c5bbb929a2a4a029af4e6cb0fd571bbc2b698b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104030 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-06tdf#97128 DOCX import: fix frame directionDaniel Arato (NISZ)
Frames used to be imported with zero rotation even if a w:textDirection tag explicitly called for a non-default orientation. I found no other solution to pass the incoming frame direction property on to the SwXFrame about to be created. 1. If you put the property into the GetSectionContext(), it gets overwritten when the next w:pPr tag is parsed, so all three frames will end up having the same direction. 2. If you put the property into the GetTopContextOfType(CONTEXT_PARAGRAPH) that context gets popped off the stack before control even gets to CheckUnregisteredFrameConversion(). 3. If you use PushStyleSheetProperties (which is bad in and of itself), the order will be messed up because the frames are not necessarily created in the same order as they are described in the file, so each frame gets a wrong frame direction in the end. Follow-up of commit 5a5597655a4bf12e4ca07c9c2b6f6221e217f080 (tentative fix for fdo#30474# [DOCX rotated text import failure]). Change-Id: I6e3d68fe60c6e2a5b6684c65a964dd86d0168181 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103553 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-10-05loplugin:reducevarscope in writerfilterNoel
Change-Id: I19f12959a04be07cdd2083a6aa519943d069fae6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103947 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02tdf#136850 DOCX: fix change tracking in floating tablesLászló Németh
Deleted text still reappeared as normal text in floating tables in the case of combination with tracked paragraph property changes. Follow-up of commit 288db6eb47fbbd2b3ca34ffea0686d8ed8ed9be9 (tdf#132271 DOCX: import change tracking in floating tables) and commit 464a7b0631335a8f8729512b8c27f864747f56a7 (tdf#136667 DOCX import: fix crash of floating tables). Change-Id: I2c8f63054520ce28306c063ef638756f7d8342e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103832 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-25fix Graphic duplication in import and add GraphicMapperTomaž Vajngerl
When importing writerfilter, we change to oox when importing images. This transition doesn't store any previous contexts and all instances are reset. The problem occurs when we have identical images because the transition erases all caches we have to determine if an image has already been imported or not, which causes that we import the same image multiple times which create unnecessary copies. This introduces the XGraphicMapper, which can be used to store the XGraphic for a key and can be transferred between writerfilter to oox. With this we can remember which images were already imported and don't create unnecessary internal copies which decreases memory. This also includes a test which checks that the import and export doesn't produce unnecessary copies of identical images. The test checks that for OOXML, ODF and MS Binary formats. Change-Id: I33dc19218c565937fab77e132b3a996c51358b6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103283 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-24tdf#134782 sw: split AddParaSpacingToTableCells flag in 2Michael Stahl
commit 3cccdabf19a99fd3f657985c1822436d7679df2b "extend AddParaSpacingToTableCells with line spacing" changed how the ADD_PARA_SPACING_TO_TABLE_CELLS compat flag works, to improve interop with Word. This commit splits out the change as a separate new compat flag ADD_PARA_LINE_SPACING_TO_TABLE_CELLS ("AddParaLineSpacingToTableCells"), to preserve compatibility with ODT documents that were produced by LO < 6.4 (via SwXMLImport::SetConfigurationSettings()). New documents and WW8/RTF/DOCX import have both flags enabled. The combination false/true is invalid, and treated as equivalent to false/false. Change-Id: Ida20df8fe4a8192a714f91da95345f9726fd7d98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103317 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-22tdf#136706 writerfilter: revert my info-gathering assertJustin Luth
The assert was failing in crashTesting for: wget http://bugs.documentfoundation.org/attachment.cgi?id=68205 -O tdf55725-1.docx ./instdir/program/soffice.bin --headless --convert-to docx ./tdf55725-1.docx and also for wget https://bugs.documentfoundation.org/attachment.cgi?id=127288 -O tdf102131-1.docx Both of these documents have SAX errors when loading. Running these interactively, saying "no, do not continue loading" parses a bit more to give the specific error and that is what was running into the assert. Actually importing the document itself does not hit the assert, nor does round-tripping it. Since this is a stupid enough situation, and because I can't think of a good way to word a SAL_WARN, and because I can't say that I have detailed knowledge about this area, I'll just remove the whole thing instead of leaving a warning. Change-Id: If50b06f0103adca348ca314ebc92e7e4045967dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103133 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21tdf#136855 writerfilter: RTF import: buffer annotations inside tablesMichael Stahl
The problem is that one of the annotations is inside a table that happens to start with a covered cell (vertically merged). The table row is buffered, but the annotation is not, so it is inserted before any of the text of the table cells is inserted, so it ends up in the covered cell. The strucuture of annotations is a bit icky; to fix this, buffer both the \annotation destination and \atrfstart \atrfend start and end destinations. Change-Id: Ie955a75a2d254f8d7e965259698b688eece7cbd6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103016 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-18tdf#122648 DOCX import: fix table formula in all tablesLászló Németh
Table formula import worked only in the first table, because of using bad fallback table for cell references without table names during formula conversion to internal formula. Set table of the text field as the correct fallback table. Follow-up of commit 68e74bdf63e992666016c790e8e4cfd5b28d6abe (tdf133647 tdf123386 tdf123389 Improved .docx table formula import). Change-Id: Ib080f12426c57c8c74fe919eb45637a655875d1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102989 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-18tdf#123382 DOCX import: fix range IDs in column ALászló Németh
Range IDs ABOVE, BELOW, LEFT and RIGHT weren't recognized in the first table column. Also the original formula was not grab-bagged in the first table cell (A1), according to the limitation of isInTable(). Follow-up of commit 436cf6d31deb7f9594a5da52ec7883d7e3d34344 (tdf#123355 DOCX import: fix cell range ABOVE, BELOW) and commit 82189fdc93ac337e1de3379d678eca6b7654e6fc (tdf133647 tdf123386 tdf123389 fix DOCX table formula export). Change-Id: Ic7d9c63a5ca989328f7ed33e25e1eda45296b3a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102849 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16tdf#136706 writerfilter: don't create page style for footnoteJustin Luth
Each time CloseSectionGroup is called for a non-continuous break, it wants to create a new page style. Each footnote calls CloseSectionGroup twice, so two unused ConvertedX page styles were created for each footnote. A quick glance through the code makes me wonder whether footnotes can skip CloseSectionGroup altogether, (unit tests suggest that it can...) but it might be necessary for a floating table that should be in-lined, or setting relative width (although tables aren't really supported in footnotes). In any case, the safest approach is to change as little as possible, so that is what I have done. HandleMargins...() only seems to add the margin information into the page style, so it should be safe to avoid that function, even though relative width stuff checks the margins. Comments are already excluded, and the function is not even called for isInIndexContext() || isInBibliographyContext(). I thought header/footers were also considered sections, but that does not appear to be the case. I'm not aware of any other types of non-text sections, but if there are, they may need similar treatment. Change-Id: I4325604c286ca1132e5765a56627be4b7e64ba4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102723 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-16tdf#134784 DOCX import: fix shape paragraph marginsLászló Németh
based on bad style inheritance. Regression from commit dc0300eac3b755bc207cd1fe87217f4ebaeb9f58 (tdf#118521 DOCX import: fix paragraph margin from paragraph style), revealing the problematic m_sCurrentParaStyleName, see also commit 8920d865ee148518bf71f71ce1866b24cc17c07e for more information. Change-Id: Icc7f70452d946d56dc840d39545d850f74f97ebc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102774 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-15tdf#136667 DOCX import: fix crash of floating tablesLászló Németh
with tracked changes of table structure (not only cell text content), where text ranges of redlines aren't connected to a cell. Support also different table names of redline text ranges for sure. Regression from commit 288db6eb47fbbd2b3ca34ffea0686d8ed8ed9be9 (tdf#132271 DOCX: import change tracking in floating tables). Change-Id: I58b1b21c8016d682a292409165991dec2f8cfa3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102655 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-12Replace remaining uses of sal_CharJulien Nabet
+ remove sal_Char check on compilerplugins Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9 Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11tdf#135660 DOCX import: fix OLE icon wrap distanceDaniel Arato (NISZ)
The text wrap distance (also sometimes called "margin") of OLE VML icons used to be thrown away when a .docx file is opened. Change-Id: I79837421470dde5e68e916f87924b170ebf1d734 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102159 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-11tdf#136587 rtf writerfilter: don't deduplicate yourselfJustin Luth
The default style was not being imported because it was based on itself, and therefore deduplicated itself away, or something like that. Probably this is the only scenario that truly would end up deduplicating itself, but I made it generic just in case. Why not? Change-Id: I621092bf2e067933b5d23d27689a5d3a7f8cf2bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102328 Tested-by: Jenkins Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-09-10tdf#123355 DOCX import: fix cell range ABOVE, BELOW,László Németh
LEFT and RIGHT by converting them to Writer cell ranges. These ranges start at the first cell above/below/right/left (including empty cells or cells with text content!) and end at the end of the first value cell range. If there is no value cell range, they end at the table border. Note: In MSO, table functions COUNT(), AVERAGE() etc. use non-value cells, as zero with ABOVE, BELOW, LEFT and RIGHT, but skip them using A1:A10 like range names. Change-Id: I906f27ecccaa8ded5460cd861ef8808000722860 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102320 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-10Remove some unused includesMiklos Vajna
Change-Id: I296597faa21c995c02f68726abd507d0d46c7f86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102335 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-10tdf#135943 writerfilter: ignore compat LayoutInCell for txbxJustin Luth
... until such a time when the underlying problem of textbox position not syncing with the moved frame is fixed. Bug 77794 moved the frame to the correct position, but the text only followed when going to the frame property, looking at the values, and pressing OK. So, it seems like the layout is re-positioning the frame, but that frame change is not being synchronized back to the paired up textbox. Since I couldn't figure out how to resolve that, I'm just temporarily avoiding the problem that my 7.1 change for tdf#77794 has exposed. That means that the textbox/frame is in the wrong position (same as in previous LO versions), but at least the text is inside of the frame. Change-Id: I7dc712c613b164317bc4adf19ac231488d610c95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102258 Tested-by: Justin Luth <justin_luth@sil.org> Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-09-10tdf#136587 writerfilter: prevent exception in applyStyleSheetsJustin Luth
The only thing that a style needs to be valid is a name. In this case, there was no name imported, so the exception killed the import of the rest of the styles. As a test, I forced the empty name to "junk" and that also worked, so I am fairly confident that this is all that is necessary to prevent an exception. This improves on 7.1 commit for tdf#68326. NOTE: this unit test does prove that LO is not importing the Normal style at all. It should import with fontsize 32. So a proper reading of the RTF file would also have solved the bug. Change-Id: I9258bf985a501952dcd5aa52e54f920c99e509f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102315 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-09-09tdf#136589 writerfilter: reset ParaHadFieldJustin Luth
::finishParagraph normally resets this, but it exited early because of m_bDiscardHeaderFooter, so the setting spilled over into the following paragraph. This is a bit of a bandaid - likely stacks of paragraphs and sections need to be used so each can hold its own settings and not worry about them being clobbered. But this particular case seems to a single level problem, isolated to headers/footers, so the change should both be enough and regression-safe. Change-Id: I84c9a5d6bf95c35c4996a9b31e53f18c05ade727 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102314 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-07tdf#135949 writerfilter: don't bRemove if anchoredObjectsJustin Luth
Surprised it took so long to find an example of an anchored object on the empty paragraph. I considered making a more useful function, but I didn't want to return a pointer, and my skills and understanding aren't good enough to intelligently return an empty vector reference, so I just left it as I first created it. It seems a bit silly to make a bool function just for this, but nothing returns anything that I wanted to use. So I just made a perfect-fit function for my unique need here. I would have preferred to create a potentially re-useable and flexible function... Change-Id: I8c2527403cd8059223d4bc610b10243656b1db3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102060 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-07tdf#132271 DOCX: import change tracking in floating tablesLászló Németh
Change-Id: If892a16875ef16015639aacf8359d15c953fb1d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102149 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-07tdf#135665 DOCX: import tight wrap setting of VML shapesDaniel Arato (NISZ)
The wrap setting that OOXML calls "tight" and LibreOffice calls "contour" (== true) was not supported by the import code, only the export. Change-Id: I48739ffaad48e28df05fd87a9b51a14238dc47e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101932 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-04tdf#136354 DOCX import: fix vertical mirrored alignment on bottom marginTibor Nagy
The relative mirrored vertical alignment (INSIDE and OUTSIDE) of bottom page margin wasn't handled. Note: this fix doesn't check mirroring (if it's possible to mirror vertically either, for example, by mixing portrait and landscape mode in a document), only support INSIDE as OUTSIDE as alternative names of TOP and BOTTOM in case of alignment to bottom margins. Follow-up of commit d54264e34c1ccc0eaf4178ab165a843028500223 (tdf#133071 DOCX import: fix vertical alignment to bottom page margin) Co-authored-by: Attila Szűcs (NISZ) Change-Id: I6d844f57505bcda1faa7dd6112d1cda666c3ac07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101934 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-03tdf#131537 DOCX export: fix OLE "Display as icon"Daniel Arato (NISZ)
for example to avoid converting OLE icons of an ODF document to an icon-size embedded spreadsheet. When creating a new OLE object in Writer the user has an option called "Display as icon" which causes the actual contents of the OLE to be hidden when rendered in the document. This setting, referred to internally as the DrawAspect of the object, was imported fine, but when exported to a .docx it always had the value "Content" (corresponding to "Display as icon" being unchecked). Now OLE objects with "Display as icon" checked are saved with DrawAspect="Icon". A grab bag entry was previously used to let the DrawAspect setting flow through Writer from OOXML import to export. Now this workaround is no longer needed and is removed by the present commit. Change-Id: I46ea4fc95a26bcd1f85e19a506c0965f73d4257a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101711 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-29Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I22682416e5a842406afd5bfbfa62d8b8797af01c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101602 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29ofz#25268 Null-dereferenceCaolán McNamara
Change-Id: I1b5a738bb1dfccb64b8d0520ffa4ba2cbff00026 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101583 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-28tdf#131801: sw: support of style references in ListAutoFormatVasily Melenchuk
ListAutoFormat property did support char attributes, but not style references ("CharStyleName"). It is important for correct formatting of pilcrow symbol or list format in some DOCX scenarios. Export to DOCX already works, but not to RTF/DOC. Change-Id: I1bf23d1e45fcc213adcf9aa6f404be803919fbee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100893 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-27remove some unused includes and update pchesCaolán McNamara
Change-Id: I786548bef39fa711aabcff32b592b3fdc4a6f9fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-27Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I0fd9d72214c2826b8240ce7629d6e6ca72fb2fad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101477 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-08-27tdf#135653 OOXML import: fix OLE background colorAttila Bakos
When importing a .docx file Writer used to ignore the 'filled' and 'fillcolor' attributes in the 'shape' tag belonging to an OLE object. Now both these are imported and displayed correctly. Co-authored-by: Daniel Arato (NISZ) Change-Id: I2e6b880d88e4c46af6f3f2316ee966bac1a1f2e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100922 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-27Revert "tdf#123354 DOCX import: fix ABS formula"László Németh
This reverts commit e1aea22f3f4fbf0cc412a8867165a85a3c55f49c, except some clean-up associated to the patch. Change-Id: Id9f87b5a02a14ad304c755b10ab157ff0577e249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101401 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-27Revert "tdf#123390 DOCX import: fix SIGN formula"László Németh
This reverts commit 4d9b72d1c3929eca04c7a2e363ab6214676b0f64. Change-Id: Icd342121c375b26ad9c95631ee118de5e0a5f585 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101397 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-27Revert "tdf#123356 DOCX import: fix COUNT formula"László Németh
This reverts commit f1f27b2487ccfb7a03190ff68eadbfb611dd9749. Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport15.cxx Change-Id: Ic5c920fd70f350890c4b696797152be9307b4eee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101394 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-26[API CHANGE] Drop OSL_THIS_FUNC, directly use C++11 __func__Stephan Bergmann
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office internal macro for now", so take the liberty of removing it, even if technically that can be considered an incompatible API change. Change-Id: I7580a932e1da54845934378a650e894f3f3a9062 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-23tdf#123356 DOCX import: fix COUNT formulaLászló Németh
Convert COUNT(x) to the equivalent, but portable Writer formula SUM(x)/MEAN(x). Note: this is a temporary conversion, which supports only 1-level nesting of function calls. Adding COUNT to Writer core, it will be possible to remove portable conversion later. Change-Id: I4b4019aadad52e6d1cf3b2d18d80b1d2c7485c6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101185 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-20tdf#123390 DOCX import: fix SIGN formulaLászló Németh
Convert SIGN(x) to the equivalent, but portable Writer formula (0 < x) - (x < 0). Note: this is a temporary conversion, which supports only 1-level nesting of function calls. Adding SIGN to Writer core, it will be possible to remove portable conversion later. Change-Id: I88853fe865808427c966b8570a052b101fecdac0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101085 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-20tdf#135187 DOCX import: fix table style at character formattingLászló Németh
applied also on paragraph level during import. Regression from commit 4d5c0eaf3e0d3d3bcd9e691fffee19b75f3d6631 (tdf#118812 DOCX import: fix table style preference – part 2) See also commit 5ac6f02fdc6015a5d78071570dee310febf95fc6 (tdf#105215 DOCX import: fix paragraph-length direct formatting). Change-Id: I14072c81fc4c54e376a004fa36ba76b56d2beb01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100996 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-19Fix typoAndrea Gelmini
Change-Id: Ia659860a0512ef0bb9405e794bb4c5fc4c6f6f55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100923 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-08-18new loplugin:unusedvarsglobalNoel Grandin
I copied and modified the unusedfields plugin to find unused variables. Change-Id: I18ed6daa202da70a2e564e4fe4760aed7ce070ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100891 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-18tdf#123354 DOCX import: fix ABS formulaLászló Németh
Convert ABS(x) to the equivalent, but working Writer formula SQRT(x POW 2). Note: this is a temporary conversion, which supports only 1-level nesting of function calls. Change-Id: I96ad01dc5ac26160792e6a4cb050e103c2ad7bca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100898 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-17tdf133647 tdf123386 tdf123389 fix DOCX table formula exportLászló Németh
Keep original DOCX table formula during round-trip using grab-bagging. This is a temporary solution until fixing formula export and a proposed solution for formula cannot be converted. Follow-up of commit 68e74bdf63e992666016c790e8e4cfd5b28d6abe (tdf133647 tdf123386 tdf123389 Improved .docx table formula import). Change-Id: Ia4759e250c06e9cc0495fb0b57fccd1ee1f50da9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100872 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-17tdf133647 tdf123386 tdf123389 Improved .docx table formula importMichael Warner
Converts table formula syntax from MS Word to LibreOffice. This version uses the list separator of the document for the formula regexen; however, it does not convert the decimal or list separators in the case where the person opening the document is using a different locale from the author. Change-Id: I9600a0bea060a76705a7ad6b051ed4fdd50b9d40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98614 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
generated by cgit (git 2.34.1) at 2024-07-07 06:18:23 +0000