summaryrefslogtreecommitdiff
path: root/writerfilter/source/rtftok/rtfdocumentimpl.cxx
AgeCommit message (Collapse)AuthorFilesLines
2022-04-08tdf#95706: RTF import: tolerant font table parsingVasily Melenchuk1-74/+88
While font name in font table should end with semicolon ({\fonttbl{\f42 Arial;}}) it is not always true and MS Word is tolerant to it: it still able to parse this correctly. Seems LO also should not require strict spec conformance. So idea of font parsing is changed: instead of inserting font on semicolon, it is done on next \fN or destination end. All collected text to this moment is a font name. Change-Id: I6b41951217442a71fd2ebbfc58a3fc79f6f913db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132686 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-04-07tdf#95706: RTF import: Use fontname suffixes to detect encodingVasily Melenchuk1-2/+37
Font names like "Arial CE", "Times New Roman Cyr" are not special fonts. They are classical Arial, Times New Roman... And these suffixes can be used to detect encoding used for RTF text. Most interesting: for MS Word these suffixes have priority: {\f34\cpg1253\fcharset161 Arial Baltic;} will have cp1257 and not cp1253. Looks like compatibility issue came from dark ages. Change-Id: Ife8e781d5d04c3f6a8c11fcf604357c74bf33055 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132584 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-04-05tdf#139948: docx and rtf import: emulate border in betweenVasily Melenchuk1-2/+3
Writer does not support border in between available in all MS formats. Since this feature is missing in core it will be better to emulate it with top borders than to ignore it completely. Change-Id: I4e5a99cde5908066c4bb483136cfe9a1316df53c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132429 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-22tdf#104390: rtf import: init default font for entire state stackVasily Melenchuk1-7/+13
If first document element is buried deep in destinations and thus deep in state stack (m_aStates) initialization of default font is very local and will be lost after closing these destinations. So let's initialize entire states stack with default font if none is provided istead of initialization just a top element. Change-Id: I966c282f43b84baece909a4c3cd359cbcd317e63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131906 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-03-21tdf#118047: RTF import: better deduplication for header/footerVasily Melenchuk1-12/+14
Here are two related fixes in one patch: 1. By default current style index is 0, not -1. Due to this we can assume usage of default "Normal" style during deduplication. Seems there is no difference in case of no style mentioning in run or mentioning "Normal" one (\s0), so value -1 looks unnesesary. 2. During header/footer "substreams" processing StyleTableEntires was not reused in new domain mapper impl instance. So deduplication did not work well. 2a. To avoid copying of whole StyleTableEntries between instances it is stored as pointer in domain mapper impl. Change-Id: Id003d35554e9b43186238920d9a6373452095121 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131899 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-02-08Extend loplugin:stringview to O[U]StringBuffer::toStringStephan Bergmann1-1/+1
Change-Id: I7ad212dfff8b34d05e3b45107a1ef033a4efc454 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129651 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-02tdf#129578 rtfimport: CJK char properties are not CSJustin Luth1-2/+2
This fixes a LO 6.4/6.3.0.1 regression caused by commit fd95fb975b754d71d3750e85431a4e596a40e659 which was focused on export, and not import. The code originally didn't have any mention of DBCH, so it used the default. However, in the 6.4 change, it was wrongly tied together with the Complex Script indicator. So revert that part of the change. Mark fixed the same problem in 7.1 for font size. Change-Id: I1c87ae856de93ebc693135585574f2eb144b214b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128113 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2021-11-12Fix (mis-)uses of temporary O[U]StringLiteralStephan Bergmann1-3/+4
...as sub-expressions of ternary operators, which happened to keep compiling after 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String" and e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" because both branches are of the same type O[U]StringLiteral<N>, and which didn't cause any issues because no dangling pointers to those temporary objects escaped the surrounding full expressions. This was found with an experimental build with VS 2022 with --enable-latest-c++, which would support HAVE_CPP_CONSTEVAL after some linking fix in the configure.ac detection code (which is forthcoming in a later commit) and flagged all these uses in ternary operators as error C7595 "call to immediate function is not a constant expression". That error looks bogus (and it also caused a false > sd/source/ui/unoidl/unoobj.cxx(742): error C7595: 'Color::Color': call to immediate function is not a constant expression so HAVE_CPP_CONSTEVAL will need to remain undefined for VS 2022 until that compiler bug is fixed), but it nicely found all these cases that should arguably be cleaned up. Change-Id: I81de94e8af5a6c50e5fe7dfa1a4b253e0c2a68f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125082 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-08use more OUStringLiteral in MediaDescriptorNoel Grandin1-1/+1
Change-Id: I0567d103db8db401c737fed98483912a39352929 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124835 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-04RTF import: fix too small graphic size when both picwgoal and picw are providedMiklos Vajna1-6/+12
The original document provided \picwgoal and \pichgoal, stating the desired size of the image in twips. \picw and \pich is not provided, but we write it on export. The value of \picw and \pich is ignored by Word (it can calculate both the current and the original size from picw/hgoal and picscalex/h), so it displays the document correctly. Use the same trick in our RTF import: picscalex/y has a specified default value (100%), so if we have picwgoal and pichgoal, then we can also ignore picw and pich. This is needed, otherwise the much smaller size from picw/pich is used as the original size, so the layout "zooms in" so much that only a small white rectangle of the top left area is visible, as if the images would be all lost. Change-Id: I924e5f8b68613c654c857a57561c8a2e3a6db2f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124679 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-04-22no need to create temporaries when appending number to O[U]StringBufferNoel Grandin1-1/+1
Change-Id: I36d82423b5f75010552696a66cec7e53ee265ce4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114395 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-14tdf#100961 rtf import: fldlock is FIXEDFLDJustin Luth1-0/+4
This depends on another fix in this bug report for exporting. I'm not sure why I even bother trying to work on RTF stuff. I'm not really into black magic. Change-Id: If596cae011a261a80ca13962932bf25561c0f63f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114062 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2021-04-06Fix typosAndrea Gelmini1-1/+1
Change-Id: I64d32773984a3ab06e809fcaeff8f95b910e127b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113700 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-04-06tdf#136740: reimplement the fix using existing m_bIsNewDocMike Kaganski1-2/+4
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>
2021-04-05tdf#136740: Do not initialize document settings when pastingMike Kaganski1-1/+2
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>
2021-03-31Make RTFKeyword and RTFControlType scoped enumsMike Kaganski1-56/+57
Change-Id: Ifae0afd1468ab162b8d815e8b614afc1442169a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113406 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-05emplace_back: use perfect forwarding if possibleThorsten Behrens1-5/+4
When using that new-ish method, try giving the compiler a chance to construct in-place. Left out harder cases using initializer lists, and might have missed slightly less obvious places. Change-Id: Ifcc3a6d4599474457e37dd17a35c41fc73e7a17e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111980 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-01-29loplugin:stringviewparam extend to new..Noel1-1/+1
O[U]StringBuffer methods Change-Id: I0ffbc33d54ae7c98b5652434f3370ee4f819f6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel1-1/+1
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel1-3/+3
(*) 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-13tdf#137180 RTF import: fix bad left margin with direct format/para style/numMiklos Vajna1-1/+1
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-09-21tdf#136855 writerfilter: RTF import: buffer annotations inside tablesMichael Stahl1-1/+9
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-11tdf#136587 rtf writerfilter: don't deduplicate yourselfJustin Luth1-2/+6
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-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann1-2/+2
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 Bergmann1-4/+3
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 Grandin1-2/+2
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-02loplugin:flatten in writerfilterNoel Grandin1-50/+50
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-06-26Upcoming improved loplugin:elidestringvar: writerfilterStephan Bergmann1-3/+3
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 Vajna1-6/+3
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 Grandin1-3/+2
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 Bergmann1-1/+1
...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-26Fix loplugin:simplifypointertobool for libstdc++ std::shared_ptrStephan Bergmann1-1/+1
...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-10new loplugin:simplifypointertoboolNoel Grandin1-12/+10
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-04-15Revert "NFC writerfilter: remove pointless asserts"Justin Luth1-0/+1
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 Luth1-1/+0
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-03-12writerfilter: extract before/afterPopState() from popState()Miklos Vajna1-145/+159
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-01-31clang-tidy modernize-concat-nested-namespaceNoel Grandin1-4/+1
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 Grandin1-2/+2
Change-Id: I0f8de0f78c7a8fb78d47ee5dfed09019b4eb5288 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87357 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-18sw RTF export: don't mark these members as constMiklos Vajna1-1/+1
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-11-26Remove some unused includesMiklos Vajna1-2/+0
Change-Id: Ia24c806f227570f7a000e85eece75c9d02d25a4b Reviewed-on: https://gerrit.libreoffice.org/83782 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-21writerfilter: these can be constMiklos Vajna1-1/+1
Change-Id: I21eadcd210aef38e7690da2492bf1dfe030427e4 Reviewed-on: https://gerrit.libreoffice.org/83356 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-11tdf#128428 RTF: fix for different product versionsLászló Németh1-2/+2
at switching off longer space sequence mode. Change-Id: I87c265ad0ff5f7b44c92b1abebeb31f68749a1e7 Reviewed-on: https://gerrit.libreoffice.org/82434 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-11tdf#128428 RTF: clean-up for longer space sequence modeLászló Németh1-0/+6
Fix regressions from commit 24b04db5a63b57a74e58a7616091437ad68548ac (tdf#123703 RTF import: fix length of space character sequence). It seems, longer space sequence is an obsolete RTF-only feature, eg. new RTF documents created in MSO don't use it, but old RTF documents still keep their layout (only in RTF). - Only old-style (without \stshfdbch) or compatible (\stshfdbch31505) RTF documents get longer space sequences using a one-time conversion; - because Writer always exports old-style RTF documents, to avoid of enlargement of space sequences of new-style RTF documents later, RTF import doesn't modify the RTF documents saved in Writer (checking \generator); - text in monospaced font "Courier New" doesn't get longer space sequence (despite its \prq2 (not monospaced) font setting). Change-Id: I308ab06db57a2db5deec1d4c4573da3317cad8e9 Reviewed-on: https://gerrit.libreoffice.org/82145 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-10-31Resolves: rhbz#1766990 starmath might not be availableCaolán McNamara1-14/+19
Change-Id: If2e02d8da85a2af576d9563c455487ac3463c935 Reviewed-on: https://gerrit.libreoffice.org/81837 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-30writerfilter: rtftok: filter control charactersMichael Stahl1-0/+25
... in RTFDocumentImpl::checkUnicode(); see ooo86460-1.xls [sic] for an example. There is another caller of text() in rtfdispatchdestination.cxx:311 but it turns out that buffered text was created by text() in the first place. This shouldn't be a problem for DOCX because XML 1.0 doesn't allow the bad control characters anyway so the sax parser should report an error in that case. Change-Id: Ice45e1c3c8c7db668a4cfb8364e42addea1777ce Reviewed-on: https://gerrit.libreoffice.org/81697 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2019-10-26size some stringbuffer to prevent re-allocNoel Grandin1-7/+10
I started with 32 and kept doubling the size until the site did not need re-alloc, but clamped it at 512 (e.g. in emfio/). Change-Id: Ib7caf35a1b7e42b0e4ed8aa812493449e3eefc8f Reviewed-on: https://gerrit.libreoffice.org/81540 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-21loplugin:constvars, look for loop vars that can be constNoel Grandin1-8/+8
Change-Id: I67ee714739800f3718f9d3facf57474cd564d855 Reviewed-on: https://gerrit.libreoffice.org/77415 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-15loplugin:sequenceloop in writerfilter..xmlhelpNoel Grandin1-1/+1
Change-Id: I7c9c911aa6b051eeab46344f25ea2919605de645 Reviewed-on: https://gerrit.libreoffice.org/77534 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-21loplugin:referencecasting in writerfilter..xmlhelpNoel Grandin1-5/+3
Change-Id: I84954e35f285d968e3a83591c476b3c814c2a13f Reviewed-on: https://gerrit.libreoffice.org/76033 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-18loplugin:logexceptionnicely in writerfilterNoel Grandin1-3/+3
Change-Id: Ie01d0e6af6af0cfeb46cdde38f52ab068b64db6b Reviewed-on: https://gerrit.libreoffice.org/74284 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-26 09:41:34 +0000