summaryrefslogtreecommitdiff
path: root/writerfilter/source/rtftok
AgeCommit message (Collapse)Author
2021-06-04tdf#142325 RTF import: tolerate invalid hex markup like "\'3?"Miklos Vajna
The RTF spec says \'hh is the expected form, where both "h" are 0-9, a-f or A-F. But Word accepts the bugdoc, so don't reject this input, handle \'<number><junk> as \'0<number>. At least the current case ignores the actual value, as it's a single character to provide a non-unicode value after \uN for old readers that don't support Unicode. Change-Id: Ib61247ab08278ca5012cc887cee26c7571c29fc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116499 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 6fc8a6b0b52509d735971f079d7b1660559d475d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116457 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-04-07tdf#136740: reimplement the fix using existing m_bIsNewDocMike Kaganski
This reimplements the fix from commit d7c4d0d4ea83481693af3645a03b03b53e456f60. The unit test from commit a90a324aa590a94a4091fbfadea67e0b0203767c still passes. Change-Id: I84c61fa68b9bee679a8e82ef7b8f164297bacb5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113665 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 7fc2cafbba36db25e7d0083cea162d2df08611b5) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113646 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit ef7ecb85645c68aeec2585240fa72e322e424020) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113650 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-07tdf#136740: Do not initialize document settings when pastingMike Kaganski
When pasting from clipboard, the document already has the defaults set, and pasted text must not change those defaults. When pasting RTF, RTFDocumentImpl::outputSettingsTable does the document settings initialization, and is called from RTFDocumentImpl::checkFirstRun when m_bFirstRun is true. Other defaults are set in the latter function, too. This makes m_bFirstRun false when RTFDocumentImpl is created in the context of a paste operation. Alternatively, checking the context could be made when deciding if to apply specific settings. Change-Id: Ide1eabbef1d04a4fa2f1ca14846b8e404f2a0cb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113613 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit d7c4d0d4ea83481693af3645a03b03b53e456f60) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113634 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 6d9d8c5a1abaf4ce2672406e2c04d68da5bb2cf7) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113649 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-01tdf#91920 sw page gutter margin, from top: add RTF exportMiklos Vajna
The documentation for \gutterprl is "Parallel gutter.", but it seems that's what Word use to convert between RTF and DOCX's <w:gutterAtTop/>. Change-Id: I06d80f234c6f52950db8a047bfc88910b808977d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110484 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-01tdf#91920 sw page gutter margin: add RTF filterMiklos Vajna
Map between \gutter and SvxLRSpaceItem::m_nGutterMargin. (cherry picked from commit 113e7c1be4ca87f936738270cf763800e8ec5832) Change-Id: I40303f87f59d18e04beb016869dc2a8f3c7da755 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110637 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-25tdf#137894 separate associated character propertiesMark Hung
in ww8filter/RtfAttributeOutput and treat \dbch as CJK and \hich Western in order to roundtrip the RTF document. ww8filter mix all the associated style, including properties for CJK and CTL scripts. Both RtfAttributeOutput::CharFontCJK and RtfAttributeOutput::CharFontCTL output \dbch, that result in incorrect assocation. CharFontCTL should use \rtlch, but it was already in RtfAttributeOutput::MoveCharacterProperties. To make the order correct, I separate the associated character properties that were stored in m_aSyltesAssoc into m_aSyltesAssocRtlch, and m_aSyltesAssocDbch by their script types. Note that it is not clear what associated character properties that we should adopt for \hich and \ltrch. In theory RTL scripts can output high ANSI chars too, so \hich may get properties from either Western or CTL scripts. However, examining Hebrew RTF documents, I didn't see any sign that \hich is used in that way. Use RTL as CTL might be a problem for Mongolian, Manchu and Xibe. They are CTL but top-to-bottom (aka LTR) . But I don't think they will be expressed as high ANSI chars either. Change-Id: I214edbb00a67c2ffe19c5a37254c8988a0828f40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106355 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit f97af19460fbd7483a0e1c1d0137e814f5390e69) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106523 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-11-21tdf#138210 check if CustomShapeGeometry exist first.Mark Hung
CustomShapeGeometry does not exist for a text frame. Getting the property throws an Exception and cause a general IO error. Change-Id: I0e31780292d45211bfd1250d0d359c72def50583 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105834 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com>
2020-11-04RTF import: change exception type thrown on destination errorsVasily Melenchuk
Previous exception (std::out_of_range) was not catch in case of invalid RTF imported: wrapping code checks only for uno::exception. This is not a case for loading file, but for parsing of clipboard containing invalid RTF it was causing fatal error, freeze and/or LO crash due to unhandled exception. I think there is no reason to add generic processing for std::exception in RTF filter: this can complicate diagnosing other potential problems. Instead let's throw UNO exception, like in other parts of RTF filter code. Change-Id: I064bbdc1559cc7700c96dbbeaf2911a2c8e0421e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105285 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-22tdf#137085 writerfilter: RTF import: \trpaddfl and \trpaddl are row...Michael Stahl
...properties, not cell properties. What is supposed to happen here, afaict: 1. \trpaddfr3 either has an effect on the left margin too (despite being defined for right), or \trpaddfl3 is the default, 0 is not the default 2. \trgaph600 should be ignored if the \trpaddfl3 is in effect 3. \trpaddl0 should be in effect, overriding both the value from \trgaph600 and the built-in default of #define DEF_BORDER_DIST 190 CellMarginHandler::lcl_sprm() needs to distinguish between \trpaddfl0 and \trpaddfl3 cases, but its not possible currently because a) \trpaddfl is processed after \trgaph/\trpaddl, and b) both \trgaph and \trpaddl produce the same srpm-id. This fixes \trpaddl handling just enough to import the bugdoc properly, for more fixing a new sprm-id for \trgaph would be needed at least. At the other end, there is a line in DomainMapperTableHandler.cxx: m_aTableProperties->getValue( TablePropertyMap::GAP_HALF, nGapHalf ) ... but nothing that would initialize the GAP_HALF there. That this bugdoc looked right before commit c2a5346b19c57f93f210b76c15cdba64f6871203 appears to be entirely accidental. Change-Id: I80dc34bdd5dadb7d7d7f5ec595907035d621a656 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104638 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-10-13tdf#137180 RTF import: fix bad left margin with direct format/para style/numMiklos Vajna
This is a case when a left margin appears as direct formatting on a paragraph, the paragraph has a style and the style has the same left margin. But the paragraph has a numbering as well: so it's not valid to deduplicate the left margin from the direct formatting, because then the left margin from the numbering will be used, which can be a different value. Change-Id: I5e27502b8d505bdfddfdc910858f62e501db35a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104220 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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-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-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-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-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-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-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-14loplugin:simplifybool moreNoel Grandin
look for expressions like !(a && !b) which can be expanded out Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-03tdf#42949 Fix IWYU warnings in include/[t-x]*/*hxxGabor Kelemen
Recheck after 7-0 branchoff Also drop the now unused file include/vcl/field.hxx Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-02loplugin:flatten in writerfilterNoel Grandin
Change-Id: Ifaa63738c4e38dddd385821f568911927d834f1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99966 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-21tdf#134400 RTF import: fix unexpected inner properties for picture-in-textframeMiklos Vajna
Regression from commit 4ab658b56f5c6ff0082d38d8ace1924d11e30e96 (RTF import: implement support for tables inside text frames, 2013-06-16), the problem was that both the outer "textbox" and the inner "picture frame" object had a shapeType property, and the properties were stored in a vector. So by the time RTFSdrImport::initShape() looked up the shape type for the inner shape, it thought it's not a picture frame, leading to data loss. Change-Id: I4a536789371619d1d54afa8c8d41c7d273b0d21b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99111 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-20compact namespace: writerfilterNoel Grandin
Change-Id: I1dd3aff6c08fb2bce031abd6e88603a4ec9077fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99012 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-10replace usage of blacklist with denylistThorsten Behrens
.. and a few cases of instead doing blacklist->excludelist where that made more sense. Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 [API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist [API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice [API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-06-26Upcoming improved loplugin:elidestringvar: writerfilterStephan Bergmann
Change-Id: Ib06004b058c8079692adabd384dca72b63e8167a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97210 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-15writerfilter: use std::any_of()Miklos Vajna
Change-Id: I21d5059beee737c286d85f559c767f43962a63ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96355 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-05-30loplugin:simplifybool extend to expression like !(a < b || c > d)Noel Grandin
mostly to catch stuff from the flatten work, but I think this looks good in general Change-Id: I7be5b7bcf1f3d9f980c748ba20793965cef957e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92493 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-28Make loplugin:simplifypointertobool handle parenthesized expressionsStephan Bergmann
...as discussed as an open TODO in the commit message of fe6cce01c88d045a1fcf09acf049c34c22299b02 "Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptr". The necessary changes across the code base have been done fully automatically with the rewriting plugin on Linux. (All those changes apparently involve uses of macro arguments wrapped in parentheses in the macro body, but always in conditionally-converted-to-bool contexts. In other contexts, such automatic rewriting would add the "bool" to the macro body, which would be wrong in general, but we apparently get away with that sloppy coding for now.) The parenExprs_ stack that fe6cce01c88d045a1fcf09acf049c34c22299b02 had introduced to treat such (then-undetected, it had turned out) parenthesized cases now turns out to not be needed after all. Change-Id: I2021f61c2e2805be7e18b38edf8744d186cac3cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95010 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-27Remove some unused includesMiklos Vajna
Change-Id: Id5a31185faf2a3a13b6ea266e058a7df41d44423 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94890 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-26Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptrStephan Bergmann
...where the get member function is defined on a std::__shared_ptr base class, so loplugin:simplifypointertobool used to miss those until now. (While e.g. using libc++ on macOS found those cases.) 366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool" was mistaken in breaking isSmartPointerType(const clang::Type* t) out of isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had introduced that indivisible two-step algorithm on purpose. The amount of additional hits (on Linux) apparently asked for turning loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed that the naive adivce to just "drop the get()" is not sufficient in places that are not contextually converted to bool, as those places need to be wrapped in a bool(...) functional cast now. If the expression was already wrapped in parentheses, those could be reused as part of the functional cast, but implementing that showed that such cases are not yet found at all by the existing loplugin:simplifypointertobool. Lets leave that TODO for another commit. Besides the changes to compilerplugins/ itself, this change has been generated fully automatically with the rewriting plugin on Linux. Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-05-21use for-range on Sequence in testtools..xmloffNoel Grandin
Change-Id: I05b02a2f8b4b9091c7de0f7e98409d5b608ed250 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94610 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-10new loplugin:simplifypointertoboolNoel Grandin
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-01improve loplugin:makesharedNoel Grandin
to find places where we are converting stuff to unique_ptr instead of using std::make_shared. As a bonus, this tends to find places where we are using shared_ptr where we can instead be using unique_ptr avoiding the locking overhead. Change-Id: I1b57bbc4a6c766b48bba8e25a55161800e149f62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93207 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-27Extract getting default locale for filters into separate unotools functionMike Kaganski
Change-Id: Ic97b1a4507d5629963f360147ecc20eb10f5d391 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-27Don't convert OUString to char*Mike Kaganski
Change-Id: I3bfcc6fedb782b12be1fb1d42981756287f29f82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92956 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-15Revert "NFC writerfilter: remove pointless asserts"Justin Luth
This reverts commit 708f95b87410c640f0e9e22892f4a71194631cd9. Stephan said I have it all backwards. Asserts are primarily "documentation", and there is no point in asserting something if you aren't going to accept it as true, at least not without any other qualifying remarks etc. So a simple "assert(p)" should never be followed by "if(p)". These asserts basically show that "yes, I'm using this pointer without checking on purpose, and not as an oversight." Change-Id: I7350b627a2acf027d1a6d5b33ea272050d23ce6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92059 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-04-11NFC writerfilter: remove pointless assertsJustin Luth
In an age where GDB (or whatever other platform debugger you prefer) is easy to use, there is no point in asserting something that is going to crash anyway, is there? Asserting is only good in these cases if you follow it using an _if_ statement. Noel informed me that it can also be used to silence false positive coverity warnings. Change-Id: I5a5cb7a22019768ec2807f6918d4a8ebb51194de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92049 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-08simplify QNameToStringNoel Grandin
no need for it to be a class, and no need for the data to be allocated at runtime Change-Id: I80bca34b2af221534eae5a6e90de369fa29037e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91878 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-16DOCX import: tokenize <w:numFmt w:val="custom" w:format="...">Miklos Vajna
Which means CT_NumFmt has to be a property resource, not a single value, and also ST_NumberFormat needs to recognize "custom" as a valid value. Adapt the RTF tokenizer to emit the new token format. This is needed (but not enough) to support markup like this: <w:numFmt w:val="custom" w:format="001, 002, 003, ..."/> Change-Id: I767e4b92fc41f9425f446d6eaad1d875e2233964 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90578 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-16writerfilter: extract dispatch...Value() from disptachValue()Miklos Vajna
This function was a 1582 lines monster. Extract clusters of RTF value keywords into their own function to makes this a bit more readable. Change-Id: Icf95ca11f5f909379acbfd576915485c7eb868ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90569 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-03-16Revert "loplugin:constfields in writerfilter"Noel Grandin
This reverts commit e7c6c05ae5a62e1705ffda97c5405eecd1f62a1e. Change-Id: I9072c4ef9c1a941ac3169e2b53dfd25ae7863770 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90545 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-12writerfilter: extract before/afterPopState() from popState()Miklos Vajna
This function was a 1365 lines monster. Ideally it would be a one-liner, just popping the parser stack. In reality the RTF format has lots of exceptions where the state leaks outside the current push/pop boundaries. Move this large list of special cases to separate functions. Change-Id: Ib6c729c5eccbcd361852f5bbc0539fd51315f86d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90349 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-02-21Drop o3tl::optional wrapperStephan Bergmann
...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-20tdf#42949 Fix IWYU warnings in writerfilter/Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I47ff7eecabc87081eb953c5970a3cbd56c86d728 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88897 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-31clang-tidy modernize-concat-nested-namespaceNoel Grandin
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-24loplugin:makeshared in svgio..writerperfectNoel Grandin
Change-Id: I0f8de0f78c7a8fb78d47ee5dfed09019b4eb5288 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87357 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-02tdf#129605 rtfimport: deduplicating borders loses informationJustin Luth
Because at least ONE direct attribute still existes, that SPRM overrides the style SPRM, and therefore the style contents are ignored. But deduplicating has removed the matching parts from the paragraph, so any children properties that match the style revert to default values. In this unit test, only the green border-color was kept, and so a default none-border was created. The UI in writer also directly applies all border properties during a color change, so further style changes in the border-style or thickness no longer have any effect. So there is no reason to try to deduplicate border stuff. UNRESOLVED PROBLEM NOTE: If deduplication is going to happen, then there needs to be a merging of character style child attributes and the directly applied properties - which in practice is the same as not deduplicating at all. (The problem will still come when the paragraph ONLY redefines the border color - then there is nothing to deduplicate and still the style contents are ignored.) This patch affects paragraph-style borders (in a good way), since it fixes tdf#129631 as well. Probably every SPRM that expects children should just avoid deduplication... UNRESOLVED PROBLEM NOTE: Another problem is that the direct properties themselves do not seem to be deduplicated. In addition, deduplication happens against the FIRST instance of the property, not on the LAST instance (which ultimately is the winner). Change-Id: I97333fba66db5cfb5238de426821fe458def329b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85868 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-20tdf#129513: drop incorrect and redundant erasure of paragraph sprmMike Kaganski
It was introduced in commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4 "avoid sending duplicated paragraph flags", and supposedly was meant to avoid having duplicating sprms in the collected properties, when new properties were pushed back at that time. Using specific sprm id was likely a mistake (nParam should have been used instead). Now the new sprm is added using RTFSprms::set with eOverwrite having default value of RTFOverwrite::YES, which takes care to avoid dupes, so the call to erase is redundant. This reverts commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4. Change-Id: Ied19f6feb41bd17ef317812d4d295ca0542a5843 Reviewed-on: https://gerrit.libreoffice.org/85602 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-18sw RTF export: don't mark these members as constMiklos Vajna
As the destructor wants to std::move() these members, and that only has an effect if the member is not const. Simiarly in writerfilter/, there the const prevents the implicit std::move() on return. Change-Id: I42ce393da9033abbd028bd5b83f15f69d34e254d Reviewed-on: https://gerrit.libreoffice.org/85336 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-04tdf#128428 RTF: switch off longer space at \dntblnsbdbLászló Németh
The Word 6.0 (Japanese) compatibility option \dntblnsbdb switches off the balancing of SBCS/DBCS characters, including the longer space sequences. Note: using \dntblnsbdb, it will be possible to set normal (short) space sequences in RTF export, too, to avoid broken document layout during RTF round-trip. Fix regression from commit 24b04db5a63b57a74e58a7616091437ad68548ac (tdf#123703 RTF import: fix length of space character sequence). Change-Id: I5ade9e0a2db0bde204d1debe831058045fd8f586 Reviewed-on: https://gerrit.libreoffice.org/84397 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
generated by cgit (git 2.34.1) at 2024-07-21 16:47:09 +0000