summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2021-12-11tdf#146140 sw DOCX import: fix moveFrom regression with broken text contentLászló Németh
(Also a small clean-up: increase the character limit for tracked text moving detection: Only 2 or more (non-whitespace) character deletions are checked for it, because single characters are often typos or some control-like characters, e.g. soft hyphen, not real text movings.) Details of the regression: commit d32d9a2b3c5e3963f4a18f6c7bbf50fab2e9b2be "tdf#123460 DOCX track changes: moveFrom completely" fixed the missing redline import of the end of the moved paragraphs, but paragraph end was imported as w:del, not w:moveFrom explicitly. From commit f51fa7534421a195a58b4a737a2e836d8c25ba81 "tdf#145718 sw, DOCX import: complete tracked text moving" this resulted two deletions (a moved one and a plain one) instead of the previous single one. Moreover, exporting these double deletions at the same position to ODT, raised a back-compatibility issue with broken text content, see tdf#107292 (solved recently, but not in older LibreOffice versions). Removing the explicit w:del code path in writerfilter, it solved the regression from commit f51fa7534421a195a58b4a737a2e836d8c25ba81 "tdf#145718 sw, DOCX import: complete tracked text moving". See also commit 9e1e88ad5cf2dc0e9b188c60930445652a6c7519 "tdf#145720 DOCX export: fix loss of tracked moving". Change-Id: I15bfc83b87dd42a762ff84edf5bae765fe02a5ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126631 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 692bc46b25db61176b4ced7b7beffeca7d55068e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126669 Tested-by: László Németh <nemeth@numbertext.org>
2021-12-11tdf#145720 DOCX export: fix loss of tracked movingLászló Németh
of documents created in MSO to keep interoperability. Export moved redlines as moveFrom/moveTo instead of del/ins elements (also for newly created tracked moving). Export "MoveBookmark" elements moveFromRangeStart, moveFromRangeEnd, moveToRangeStart, moveToRangeEnd, which imported from DOCX documents created in MSO. Without them, moveFrom/moveTo elements were imported as plain deletion or insertion in MSO. Note: MoveBookmark elements were imported and exported as collapsed plain bookmarks. Now keep their ranges, also store the information of moveFrom/moveTo for correct export. In the export filter, mandatory author and date of the tracking information restored from RedlineData of the first redline within the MoveBookmark, if it's possible. Follow-up to commit f51fa7534421a195a58b4a737a2e836d8c25ba81 "tdf#145718 sw, DOCX import: complete tracked text moving". Change-Id: I54242453a7f7d8f73ea074fc74e8e7bc86d07d01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126258 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 9e1e88ad5cf2dc0e9b188c60930445652a6c7519, commit bbb09ebda08fec0702de0fb50dbe630acf73af2f and commit 3efde47ec9ee091479c04129696f99dc934c3f64) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126290 Tested-by: Jenkins
2021-12-09sw: support for other sdt attributes roundtrip in datepickerVasily Melenchuk
Word Control Field with datepicker is implemented with LO datepicker, but during this conversion we lose some field data, like control color, data mapping, etc. This data is already retrieved and stored in grab bag, so we need just to keep this grabbag in field and use it again on export. Change-Id: I6af8204fe1a7d2f9081d83372a6786b2f86260d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125486 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126280
2021-12-09writerfilter: extend SdtHelper for better support control typesVasily Melenchuk
There is much more different controls which must be supprorted in future. So approach with isInsideDropDownControl() and validateDateFormat() is not sufficient. Use enum to determine and store control type. Change-Id: Ibea7fde117c059053195be213a3ae821644f277c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125471 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126279
2021-12-03tdf#137466: docx: support w:placeholder & w15:color in w:sdtPrVasily Melenchuk
Content controls in Word can contain some other elements which are not supported by Writer. Put them into grabbag and write back to DOCX on save to avoid losing quite sensitive data. Test testSimpleSdts is modified: testcase is actully containing 4 sdt elements with ids in input and output. Change-Id: I1f9addd03ed828bf375ccac5188a004f011e8a0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125271 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> (cherry picked from commit 7db38a496a5e458ec12888ddbf63c603706ae3fc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126000 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-11-30tdf#54465 tdf#139336 sw: add compat. flag for footnote in columnAttila Szűcs
Add compatibility option FOOTNOTE_IN_COLUMN_TO_PAGEEND to keep layout of old ODT files, where multicolumn sections have footnotes in columns, growing sections to the full page. Note: Multicolumn page styles or not evenly distributed multicolumn sections, or footnotes not collected at the end of the sections still use footnotes in columns, so they don't need this compatibility option. Follow-up to commit 4c31b4ef2083087a822c3ae648fd09acc67d2f88 "tdf#139336 sw: fix extra pages of multicolumn sections with footnotes". Co-authored-by: Tibor Nagy (NISZ) Change-Id: I7d6a1f804b555dc5372767014b8fb5e3fa57ba9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125442 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 41cc1d2c0c0c3bfa5ba341311f68df05375859fb) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126001 Reviewed-by: Attila Szűcs <szucs.attila3@nisz.hu> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2021-11-30tdf#97899 DOCX import: allow character formatting only of numberingTünde Tóth
After the DOCX round-trip of a numbering created in Writer using direct formatting (e.g. using Toggle Ordered/Unordered List icons), it was not possible to format only the numbering or bullets, e.g. selecting and formatting them by positioning the text cursor on the numbering. Set CharStyleName property during the DOCX import to allow this formatting. Note: default list styles of Writer is still not supported, resulting missing numbering after DOCX import. Change-Id: I6f2c5d6e0d63b15e9c28367181af1e9e083ae68d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125649 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 7b8ae6f90c37c18ff724c0751b5f73cca6ae02ac) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125999 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-11-23O[U]String::replaceAt overloads that take string_viewNoel Grandin
which results in lots of nice string_view improvements picked up by the plugins Change-Id: Ib0ec3887816b3d4436d003b739d9814f83e244b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125657 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-19Use more basegfx::deg2rad<N> and basegfx::rad2deg<N>Mike Kaganski
Change-Id: I9dc57628b98f67994d546f6887e96389be1efe62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125568 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-18tdf#81507: word content control support for w:multiLineVasily Melenchuk
<w:text multiLine="1"/> is now supported for import/export to DOCX. Like other content control items it is stored in grabbag. Change-Id: Id6f1aa0072dc5db980d0fa43cab4b38a0aa047fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125024 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-11-17tdf#145718 sw, DOCX import: complete tracked text movingLászló Németh
Add IsMoved bit to SwRangeRedline, and keep it in both parts of a split Delete/Insert redline. Set this bit during DOCX import, fixing incomplete import of moveFrom/moveTo elements. Details: - Search text moving only at redline Insert() and AppendRedline() instead in the layout code (which was much slower, because triggered by also mouse hovering): - detect text moving in Hide Changes mode, too; - Insertion inside or directly after tracked text moving keeps "moved text" layout of the original moved text parts (before and after the insertion). - at detection of text moving, invalidate (update) layout of the redline pair, too. - fix DOCX import: extend makeRedline() with property RedlineMoved to keep all moveFrom/moveTo stored in DOCX instead of losing them (joining them with normal redlines) in the case of missing Delete/Insert pair (see unit test document); Follow-up to commit ec577f566fa3e6d2666069180f8ec8474054aea9 "tdf#145233 sw track changes: show moved text in green color", commit bcdebc832b272662d28035007a4796e42d1305ae "tdf#104797 DOCX change tracking: handle moveFrom and moveTo" and commit d32d9a2b3c5e3963f4a18f6c7bbf50fab2e9b2be "tdf#123460 DOCX track changes: moveFrom completely". Change-Id: Iaca80e5e326a172bc7ba5fec64b63668b9378e2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125317 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-11-13Use o3tl::convertMike Kaganski
Change-Id: I78db3001d602ec1a0847785b3c127b9d345f5af7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125173 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-12Fix (mis-)uses of temporary O[U]StringLiteralStephan Bergmann
...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-09RTF import: handle \snextMiklos Vajna
I.e. pressing enter at the end of a heading 1 paragraph should switch to body text. Change-Id: Idde9da3e2c058869a2ae4a9c61b3b43165121f5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124883 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-11-08use more OUStringLiteral in MediaDescriptorNoel Grandin
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-06related tdf#136472 writerfilter: only copy even pages if usedJustin Luth
Allowing the use of Even pages is a document-level setting. So if the document does not allow the use of an even page, although we will read it in once (in order to preserve the contents) there is no point in copying it to every inheriting page style (especially if it contains large items like images). Change-Id: I22ccb16e29c5335e50010f8a334494aaa1d45785 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124437 Tested-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Justin Luth <justin_luth@sil.org>
2021-11-06NFC writerfilter: m_bDiscardHeaderFooter = false in both casesJustin Luth
Change-Id: Ie16100c10fce6366659be17261a97795d372ff11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124754 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2021-11-05NFC writerfilter: simplify logicJustin Luth
if (!A && !B || B) is the same as if (!A || B) and the ELSE is also by definition A && !B now. Change-Id: Ie797976423bb910386a26e96692c43faf0344132 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124753 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2021-11-05crashtesting: downgrade assert on bookmark missing from input docx to a warningCaolán McNamara
The docx bugdoc is "generated by ComMA version 3.3.0" and has a pair of bookmarkEnd/bookmarkStart in a non-conformant order, like so... <w:bookmarkEnd w:id="23"/> ... <w:bookmarkStart w:id="23" w:name="_Toc483311613"/> both bookmarkStart and bookmarkEnd are mapped to the same DomainMapper_Impl::StartOrEndBookmark (without a distinction made between begin/end) which assumes the first time it's called for an id that it's a bookmark start, and the second time for an id that it's a bookmark end and that there will have been a w:name seen between the 1st and 2nd calls to be used as the name for the bookmark to use at the 2nd call. That there is no bookmark name is a problem in the input docx rather than the import logic so turn this assert into a warning $ wget https://bugs.documentfoundation.org/attachment.cgi?id=157489 -O tdf130241-1.docx $ ./instdir/program/soffice --headless --convert-to pdf ./tdf130241-1.docx https: //dev-builds.libreoffice.org/crashtest/b6ef68cdaa51ca5c9fdab40ade97f4a0f18da51b/backtraces/task815-core.backtrace.txt Change-Id: Id389d186ea825f515c2638a76c9bba00666e0686 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124734 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-11-04RTF import: fix too small graphic size when both picwgoal and picw are providedMiklos Vajna
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-11-03loplugin:constparamsNoel Grandin
Change-Id: Iebeb531fad5cc819b536788925cf8508737198b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124599 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-01Prepare for removal of non-const operator[] from Sequence in writerfilterMike Kaganski
Change-Id: I4002bc1ca227726bf1c36ecdb657175a42c2d9be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124413 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-23tdf#145215: docx: do not initialize prefix/suffix and include levelsVasily Melenchuk
On DOCX import we do not need to provide prefix, suffix and included levels: these values are calculated in SvxNumberFormat out from list format. Moreover these values are incorrect and do not correspond not to DOCX data nor to internal writer representation of list level. Change-Id: I91ec9de679e67056ba3746f2e1a0bd923532d76c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124090 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
2021-10-22Optimize assignment from OUStringLiteral to OUStringStephan Bergmann
...by making the OUString's pData point to the OUStringLiteral, instead of copying the contained characters. This is one of the improvements that had not been done as part of e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString": "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." (Simply dropping the OUStringLiteral overload was not possible in this case, though, as that would have lead to ambiguities among the various OUString and std::u16string_view overloads.) The now-deleted OUStringLiteral rvalue reference overload means that some existing assignments from ternary-operator OUStringLiteral<N> to OUString no longer compile and had to be replaced with uses of std::u16string_view. Those had not already been replaced in e6dfaf9f44f9939abc338c83b3024108431d0f69 because they happened to use OUStringLiteral instances of identical length N in both arms of the ternary operator, so did not already start to fail to compile back then. Change-Id: I328e25b8324d045774e811d20a639f40d6a9a960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124040 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-21loplugin:flattenNoel Grandin
Change-Id: I3b4226a9d089ec9aedab95d96e50a068f57a76c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123991 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-20loplugin:indentation check for indent inside blockNoel Grandin
look for places where the statements inside a block are not indented Change-Id: I0cbfa7e0b6fb194b2aff6fa7e070fb907d70ca2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123885 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-19writerfilter: give up if body text is missingMiklos Vajna
Crashreport trace: writerfilter::dmapper::DomainMapper_Impl::DomainMapper_Impl(writerfilter::dmapper::DomainMapper&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, writerfilter::dmapper::SourceDocumentType, utl::MediaDescriptor const&) writerfilter/source/dmapper/DomainMapper_Impl.cxx:359 (discriminator 2) writerfilter::dmapper::DomainMapper::DomainMapper(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, bool, writerfilter::dmapper::SourceDocumentType, utl::MediaDescriptor const&) writerfilter/source/dmapper/DomainMapper.cxx:113 writerfilter::dmapper::DomainMapperFactory::createMapper(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, bool, writerfilter::dmapper::SourceDocumentType, utl::MediaDescriptor const&) writerfilter/source/dmapper/domainmapperfactory.cxx:34 ollaboraoffice6.4/program/../program/libwriterfilterlo.so RtfFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) writerfilter/source/filter/RtfFilter.cxx:152 I.e. we end up in a situation where the insert position does not have a containing XText. It's hard to continue from that point and this is in the ctor of the dmapper, so we didn't start the import. Just throw an exception to avoid further crashes. Change-Id: Idb5c06186a82c00b838d0b3330260340eb4218b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123795 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-10-19tdf#144798 DOCX import: handle ZOrder of chart objectsMiklos Vajna
Regression from commit 10efab2b9a3cf7fc49655c90ba29db4512680c38 (tdf#82824 DOCX import: fix at-char embedded object handling, 2016-11-15), the problem was that if we start supporting anchor types other than as-char, then handling ZOrder is no longer optional. Change-Id: I605cee33180490817055978b22f3271b3c08a1c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123757 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-10-17Simplify vector initialization in writerfilterJulien Nabet
Change-Id: I54f6eaed64f0a4209e57ce12b5cbb38d2cf66fb6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123709 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-15Avoid usage of incomplete types in member functions defined in-classStephan Bergmann
...that started to fail now at least with clang-cl (where the MSVC rules when to emit inline member function definitions are more aggressive than for other ABIs) with --with-latest-c++ and --with-visual-studio=2022 (where usage of incomplete types in std::vector now triggered > In file included from C:/lo-clang/core/slideshow/source/engine/opengl/TransitionerImpl.cxx:31: > In file included from C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\memory:11: > In file included from C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\exception:12: > C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\type_traits(744,50): error: incomplete type 'Primitive' used in type trait expression > struct is_trivially_destructible : bool_constant<__is_trivially_destructible(_Ty)> { > ^ > C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\type_traits(59,53): note: in instantiation of template class 'std::is_trivially_destructible<Primitive>' requested here > struct conjunction<_First, _Rest...> : _Conjunction<_First::value, _First, _Rest...>::type { > ^ > C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\type_traits(64,44): note: in instantiation of template class 'std::conjunction<std::is_trivially_destructible<Primitive>, std::disjunction<std::_Is_default_allocator<std::allocator<Primitive>>, std::_Has_no_alloc_destroy<std::allocator<Primitive>, Primitive *>>>' requested here > _INLINE_VAR constexpr bool conjunction_v = conjunction<_Traits...>::value; > ^ > C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\xmemory(934,20): note: in instantiation of variable template specialization 'std::conjunction_v<std::is_trivially_destructible<Primitive>, std::disjunction<std::_Is_default_allocator<std::allocator<Primitive>>, std::_Has_no_alloc_destroy<std::allocator<Primitive>, Primitive *>>>' requested here > if constexpr (!conjunction_v<is_trivially_destructible<_Ty>, _Uses_default_destroy<_Alloc, _Ty*>>) { > ^ > C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\vector(1632,13): note: in instantiation of function template specialization 'std::_Destroy_range<std::allocator<Primitive>>' requested here > _Destroy_range(_Myfirst, _Mylast, _Al); > ^ > C:/PROGRA~1/MIB055~1/2022/Preview/VC/Tools/MSVC/1430~1.305/Include\vector(583,9): note: in instantiation of member function 'std::vector<Primitive>::_Tidy' requested here > _Tidy(); > ^ > C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(74,5): note: in instantiation of member function 'std::vector<Primitive>::~vector' requested here > TransitionScene( > ^ > C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(42,7): note: forward declaration of 'Primitive' > class Primitive; > ^ etc.). Which in turn required tweaking of loplugin:unnecessaryoverride to avoid false > In file included from C:/lo-clang/core/slideshow/source/engine/opengl/TransitionerImpl.cxx:67: > C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(389,18): error: unnecessary user-declared destructor [loplugin:unnecessaryoverride] > TransitionScene::~TransitionScene() = default; > ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ > C:/lo-clang/core/slideshow/source/engine/opengl/TransitionImpl.hxx(81,12): note: declared here [loplugin:unnecessaryoverride] > inline ~TransitionScene(); > ~~~~~~~^~~~~~~~~~~~~~~~~~ Change-Id: Ia72fb44e6e92ff47376d7b7159c0df7cbf883b69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123648 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-14Avoid COW overhead using css::uno::SequenceMike Kaganski
The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-13writerfilter: remove a bunch of unused documents from gitXisco Fauli
Change-Id: I95d6f5780ec43787f7daa75f435f1c918de6a57e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123549 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-10-11loplugin:moveparam in writerfilterNoel Grandin
Change-Id: Iabc09d0388da68ee5bb74c75125b8dd8d75a5a73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123386 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11tdf#142407 fix incorrect number of lines in vertical writing.Mark Hung
Wrting mode isn't read correctly. The property PROP_WRITING_MODE contans an Any of sal_Int16. When converting to WritingMode enum directly, it always get WrtingMode::LR_TB(0), hence use wrong side to calculate number of grid lines for vertical writing. The resulted number of grid lines are much smaller than expected, it ends up leaving large space between header and text. Change-Id: Ifb0ff09fe981819cc2705de8d5596190f320f79e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123223 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com>
2021-10-10Typo: CT_SytemColor_lastClr->CT_SystemColor_lastClrJulien Nabet
Change-Id: I10ebe939562097d3fc098a42c09b1e0f6e5cbd6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123315 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-04tdf#144609: numbering "None" should still show prefix/suffixVasily Melenchuk
Unlike it was implemented in tdf#143605, prefix and suffix should be displayed anyway, we do not display only numbers. Moreover tdf#143605 did accidentally fix tdf#135164 in a invalid way. So this patch is also providing a better fix for it: untittest is already created and failing without it. Problem in tdf#135164 is inability to distingush missing level text (bullet char in given case) and empty ("") one. In first case we should use abstract level definition. In second - not. Change-Id: Ica3a714d22de4d2f14ebbcb12f0e1311dbc9b801 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122609 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
2021-10-04tdf#77051 DOCX: fix user index and index entry supportLászló Németh
defined by field code \f. E.g. INDEX \f "user-index" inserts only the entries defined by XE "entry" \f "user-index" field codes. Revert commit a7bc9c1e4977bd3430df69287fa0a8377a686c58 "fdo#77051: Preservation of Index field flag '\f'", which added an undocumented UNO property only for round-trip support of INDEX, but not for XE index entries, so the DOCX export still resulted a broken index with lost entries, not only the import was broken because of the missing functionality in com.sun.star.text.DocumentIndex. Now the import uses com.sun.star.text.UserIndex and com.sun.star.text.UserIndexMark index and index entry fields, which support the requested user index not only during the DOCX and OpenDocument round-trip, but its run-time functionality, the multiple user-defined indices. Note: for manual testing, update the user index (the first index) of the left original unit test document IndexFieldFlagF.docx: the updated index is not empty, as before, but contains the user index entries. Change-Id: Ia6139bba88907051fd050cfd40809f5544b9a89e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122930 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-28vcl: rename OutDevState to StackChris Sherlock
I have moved the header file to include/vcl/rendercontext as this will eventually be part of the RenderContext split from OutputDevice. State and associated enums have also been moved to the vcl namespace. I have also moved ComplexTextLayoutFlags into the vcl::text namespace. Change-Id: I0abbf560e75b45a272854b267e948c240cd69091 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-09-27tdf#89383 DOCX import: fix permission for editingTünde Tóth
w:writeProtection passwords in DOCX documents created with Word weren't asked and verified to permit editing. Change-Id: I53d73e3acaf0c0fd398ded2de52e1d8ef00cfd56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122384 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-09-27sw: paragraph styles: add DOCX filter for a linked character styleMiklos Vajna
And the same in the other direction: link a para style from a char style. This gets the info out of the grab-bag, so later we can store it also in ODF. No new tests, the existing testStyleInheritance in CppunitTest_sw_ooxmlexport3 covers this refactor. Change-Id: I5ada7ea471a253204984ae0466bd0f8ad70046e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122681 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-09-21tdf#143591 DOCX import: handle anchored objects as at-charMiklos Vajna
This partially reverts cc8f8ae55f681755f5da3bf64e4c30bb713f0383 (DOCX drawingML shape import: wp:anchor's behindDoc attribute, 2013-11-19), it seems to be more important to be consistent with the DOC import than with the VML import which is no longer used for DOCX shapes crated with Word >= 2010. Change-Id: I631da010bce1b4d3c392645e0ae3797a03665a42 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122367 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-09-15loplugin:constvarsNoel Grandin
Change-Id: I9b35d6333afa6b305bf73fc55a7e60c8365674e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122134 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-13tdf#123642: keep last bookmark at the document endVasily Melenchuk
In some cases DomainMapper_Impl::RemoveLastParagraph() can also remove last bookmark from real last paragraph. This does never happens when we use xParagraph->dispose(), but pretty always during older way with xCursor->setString(OUString()). Unfortunately without deep refactoring of redlines, bookmarks, etc. I see no other way to avoid this removal except given hack which is trying to store last bookmark and if it did disappear restore it. Some existing unittests were adjusted: corresponding original DOCX files did contain final bookmarks not taken into account by the code. In some cases test code is modified, in some just removed final bookmark in DOCX: such multi-format tests as in ooxmlfieldexport.cxx will be more identical to RTF & DOC variants. Change-Id: Ie9948b58cda705a0b85fa8e5e08b72fbb7d682b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121409 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-09-09reserve space in vector to reduce reallocationsNoel Grandin
Change-Id: I6263c0b742331138188f7b557c05b2a59188d4fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121853 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-08Fix typosAndrea Gelmini
Change-Id: Ic3793bd77a7db52e59797cc6b2153850b1cec42e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121737 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-09-07Avoid repeating the return type from the declarationMiklos Vajna
Change-Id: I0dce02d10b8c74e80f5672e2dd580b6837ba3291 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121732 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-09-06clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: Ib41556edafb03c770938c91cff89bfaefa23d7cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121691 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-03Remove some unused includesMiklos Vajna
See tdf#42949 for motivation. Change-Id: I62354cf2ae750a91b72e91ad838a40e205e7cd61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121526 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2024-06-21 18:12:55 +0000