summaryrefslogtreecommitdiff
path: root/sw
AgeCommit message (Collapse)Author
2020-09-02sw reqif-xhtml export, embedded objects: take OLE1 pres data from rtf if neededMiklos Vajna
Next to the native data of an embedded object, the presentation data / replacement is included at several layers: - the OLE2 container may have it - the OLE1 container may have it - the RTF container may have it - the PNG file next to the RTF container may have it Given that various consumers pick one of the above, we try to provide presentation data in all layers. We already had code to generate the OLE1 presentation data from the OLE2 container, but we gave up for OLE1 in case the OLE2 container didn't have it. This means that in case the RTF container is wrapped in a proper RTF file, Word refuses the edit the embedded object. Fix the problem by taking the presentation data from RTF for OLE1 purposes, in case it's missing from the OLE2 container. Change-Id: I158db1c87044a3895d0c64a6e5a5384686627d96 (cherry picked from commit 5c37f5713a5b9e14fcc378d91e5ed8d40edc40a4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101946 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-02Removed duplicated includeAndrea Gelmini
Change-Id: I410aa4f1c6367c3224a6e4d9b90c8046da3d4944 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101922 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2020-09-02tdf#135018: sw: Add UItestXisco Fauli
Change-Id: Ia88e28b1569ea69df81d905cb76a6791a887ef3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101883 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-02drop some unused methodsCaolán McNamara
Change-Id: I4da391591d30db9e51c1dd543bcf128f2e8621c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101914 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02drop unnecessary includeCaolán McNamara
Change-Id: I4d623a99356f211a31879a2822fd8feea73a7d60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101913 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02move Edit into toolkit only headersCaolán McNamara
Change-Id: If51bf7143116721e8f16272cf8aff797651d5ed1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101880 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02tdf#136061 Chart ODF/OOXML: fix missing custom labelsBalazs Varga
by UNO extensions ShowCustomLabel in DataPointLabel.idl and CUSTOM in ChartDataCaption.idl, fixing OOXML/ODF import/export. We should display custom data label even if DataPointLabel is disabled (e.g. category name and/or value fields are not displayed). Note: import of the embedded chart of the DOCX unit test document uses also ODF format in the background, testing also the extension of the native file format. Change-Id: I73e21f1e69fddec9f3b4163c46b6582cd1c74b5d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101640 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-02SetCallHandlersOnInputDisabled unneeded if AlwaysDisableInput not usedCaolán McNamara
and don't need to use that if we use FixedText instead of Edit Change-Id: I162bf829a62a2c7cf8a975c99509607095712e17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101851 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02annotation label doesn't need to be an Edit, FixedText is enoughCaolán McNamara
similar to: commit a2d97135411d566b0b1f3d47af7912c8412cee7f Author: Caolán McNamara <caolanm@redhat.com> Date: Tue Aug 18 10:23:27 2020 +0100 annotation label doesn't need to be a MultiLine edit, FixedText is enough Change-Id: I5035ecc2d5d03f7aaeb794006a0cb305bb89a219 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101850 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02Improve exception when shape with illegal anchor is givenSamuel Mehrbrodt
Change-Id: I24cb57b39511db3523f776463a832513a1aae0d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101843 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-09-02tdf#135655 OOXML export: Fix OLE background colorAttila Bakos
Follow-up of commit 636d16efe45a55c1a5a7a451c46fbb8618bf0393 (tdf#135653 OOXML import: fix OLE background color). Co-authored-by: Daniel Arato (NISZ) Change-Id: Iee927898884e229108b489d6d26a83ef7ad2f9a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100924 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-02tdf#134649 DOCX export: fix page break between tablesLászló Németh
Section break between tables wasn't exported, resulting missing page break and table content. For example, a table on a new landscape page was merged to the previous table, removing not only the landscape page, but hiding half of the table because of the narrower width of the previous page with portrait orientation. Change-Id: Id02529d023a6306fb5be42486d25f252d8821f2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101823 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-02sw reqif-xhtml export, embedded objects: prepare pres data earlierMiklos Vajna
If an embedded object has some native data, we provide presentation data (replacement graphic) for it in the OLE1 container. We usually take this from the OLE2 container, but it's OK to omit the presentation data there. So refactor to have the presentation data available from the OLE node (already used for RTF purposes) earlier, that'll allow taking the OLE1 presentation data from RTF if it's missing from OLE2. Change-Id: Ib6b1b5e843308b0f7af04499de5a1ef5461f7b00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101840 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-01cid#1466575 Dereference null return valueCaolán McNamara
Change-Id: Ie8f0036bad6490a409d768d9fc98ff796def129c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101824 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-01Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I8336c2a639a1d45c8370fd13204896f3f1494b4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101801 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-01Fix typo in codeAndrea Gelmini
IT passed "make check" on Linux Change-Id: Ic7eb9958a192f8ced72481e42119066b455450aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101800 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-01Fix typoAndrea Gelmini
Change-Id: I03dc9ad3ad496524efbbb2f1a48f76fb95d1bfc5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101781 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-01tdf#135412: sw_uiwriter: Add unittestXisco Fauli
Change-Id: I091f5e40161119fcc07c43deaede6bc49049bf87 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101745 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-01Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: Ide85943961b6f5102294356ff623c6be8d7bc790 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101813 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-01Resolves: tdf#136189 don't try and sort until treeview is filledCaolán McNamara
Change-Id: Ic5ac71d88bab7627e14220912f4b9c935f2f1f26 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101709 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-01tdf#136282 ww8import: track para bidi, not char bidi for styleJustin Luth
This fixes a LO 7.0 regression from tdf#99197. Apparently I was watching the wrong SPRM for bidi change in styles. It looks like it should be sprmPFBiDi: A Bool8 value that specifies whether the paragraph uses right-to-left layout. By default, a paragraph does not use right-to-left layout. Instead, I had been using sprmCFBiDi: A ToggleOperand value that specifies whether the text is formatted with right-to-left layout. By default, text is displayed from right to left if the language for the text is a right-to-left language. [So this one looks like a character run property.] I no longer remember why I used CfBiDi. Perhaps just because it sets m_bBiDi which sounds good? However, there are no existing unit tests that have a CFBiDi in a style, but there are examples with CFBiDi. I'm really surprised that QA didn't have any documents that picked up on this regression. I was counting on that... Change-Id: If5a115db5962e7e26ca1b280cd9f31d493cee69c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101726 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-01Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I8e36c4204ae9a2e2968f8006fd6830cd1f6d3905 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101786 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-01Fix typosAndrea Gelmini
Change-Id: Ieff77be89ee8505b8241234f6dbb7507256dbc4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101757 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-09-01tdf#135056 sw_redlinehide: when moving sections to undo nodes-array,Michael Stahl
... delete frames with utmost prejudice - the code that was checking for empty frames or cells was going into infinite loop because first the *outer* section is moved to the undo nodes array, then when the *inner* (index header) section is moved, its section node's m_pStartOfSection points to the section node that is already in undo nodes array and so SwNodes::GoPrevSection() goes very wrong and CheckNodesRange() is called with positions in 2 different arrays. (regression from a60dd9ef1361c5925803acaa5292e99277d1faf3) Change-Id: I5682ebc2081ffc7dc49a9c43e613f72c26e93673 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101755 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-01tdf#135661 sw: fix Undo of text deletion of SdrObjectMichael Stahl
This creates a non-working SwXShape without m_pFormat initialised: 0 SwXShape::SwXShape(com::sun::star::uno::Reference<com::sun::star::uno::XInterface>&, SwDoc const*) (this=0x278de80, xShape=uno::Reference to (SvxCustomShape *) 0x73ec840, pDoc=0x0) at sw/source/core/unocore/unodraw.cxx:889 1 SwFmDrawPage::CreateShape(SdrObject*) const (this=0x637a980, pObj=0x6409410) at sw/source/core/unocore/unodraw.cxx:372 2 SdrObject::getUnoShape() (this=0x6409410) at svx/source/svdraw/svdobj.cxx:2836 3 GetXShapeForSdrObject(SdrObject*) (pObj=0x6409410) at svx/source/unodraw/unoshape.cxx:3928 4 SdrObjCustomShape::GetCustomShapeEngine() const (this=0x6409410) at svx/source/svdraw/svdoashp.cxx:381 5 SdrObjCustomShape::GetTextBounds(tools::Rectangle&) const (this=0x6409410, rTextBound=...) at svx/source/svdraw/svdoashp.cxx:534 6 SdrObjCustomShape::AdaptTextMinSize() (this=0x6409410) at svx/source/svdraw/svdoashp.cxx:1397 7 SdrObjCustomShape::NbcSetSnapRect(tools::Rectangle const&) (this=0x6409410, rRect=...) at svx/source/svdraw/svdoashp.cxx:1421 8 SdrObjCustomShape::handlePageChange(SdrPage*, SdrPage*) (this=0x6409410, pOldPage=0x0, pNewPage=0x627fc80) at svx/source/svdraw/svdoashp.cxx:2855 9 SdrObject::setParentOfSdrObject(SdrObjList*) (this=0x6409410, pNewObjList=0x627fc80) at svx/source/svdraw/svdobj.cxx:294 10 SetParentAtSdrObjectFromSdrObjList(SdrObject&, SdrObjList*) (rSdrObject=..., pNew=0x627fc80) at svx/source/svdraw/svdpage.cxx:65 11 SdrObjList::NbcInsertObject(SdrObject*, unsigned long) (this=0x627fc80, pObj=0x6409410, nPos=0) at svx/source/svdraw/svdpage.cxx:305 12 SdrObjList::InsertObject(SdrObject*, unsigned long) (this=0x627fc80, pObj=0x6409410, nPos=0) at svx/source/svdraw/svdpage.cxx:358 13 FmFormPage::InsertObject(SdrObject*, unsigned long) (this=0x627fc80, pObj=0x6409410, nPos=0) at svx/source/form/fmpage.cxx:79 14 SwDrawContact::InsertMasterIntoDrawPage() (this=0x640d6b0) at sw/source/core/draw/dcontact.cxx:1909 15 SwDrawContact::SwClientNotify(SwModify const&, SfxHint const&) (this=0x640d6b0, rMod=..., rHint=...) at sw/source/core/draw/dcontact.cxx:1457 16 SwModify::CallSwClientNotify(SfxHint const&) const (this=0x640d090, rHint=...) at sw/source/core/attr/calbck.cxx:373 17 sw::BroadcastingModify::CallSwClientNotify(SfxHint const&) const (this=0x640d090, rHint=...) at sw/source/core/attr/calbck.cxx:378 18 SwUndoFlyBase::InsFly(sw::UndoRedoContext&, bool) (this=0x78cdfd0, rContext=..., bShowSelFrame=false) at sw/source/core/undo/undobj1.cxx:97 19 SwUndoDelLayFormat::UndoImpl(sw::UndoRedoContext&) (this=0x78cdfd0, rContext=...) at sw/source/core/undo/undobj1.cxx:440 20 SwHistoryTextFlyCnt::SetInDoc(SwDoc*, bool) (this=0x60d14c0, pDoc=0x625aa30) at sw/source/core/undo/rolbck.cxx:581 Whereas if the shape is selected and deleted that way, a completely different Undo is created, which doesn't have this problem: 0 SwXShape::SetFrameFormat(SwFrameFormat*) (this=0x2497d50, pFormat=0x564b470) at sw/inc/unodraw.hxx:206 1 SwXShape::AddExistingShapeToFormat(SdrObject const&) (_rObj=...) at sw/source/core/unocore/unodraw.cxx:945 2 SwDrawContact::SwDrawContact(SwFrameFormat*, SdrObject*) (this=0x6bad330, pToRegisterIn=0x564b470, pObj=0x5647880) at sw/source/core/draw/dcontact.cxx:709 3 SwUndoDrawDelete::UndoImpl(sw::UndoRedoContext&) (this=0x56ebcd0, rContext=...) at sw/source/core/undo/undraw.cxx:501 In SwUndoDelLayFormat, the SdrObject is apparently removed from SdrPage and the SwDrawContact remains, whereas in SwUndoDrawDelete, the SdrObject remains on SdrPage but is moved to invisible layer, and SwDrawContact is destroyed (presumably). Include obligatory rant why sw has 2 undos doing the same thing here. (reportedly regression from 2d89b9929e85bede4c72684a12e7508751875f0e but probably this can be triggered before, at least since 91b2325808a75174f284c48c8b8afc118fad74e4) Change-Id: I4fbb3620bfe1ac07f47e4441625797db7a87cecd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101740 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-01uilogger : Add support in the Logger and DSL for Writer-CommentsAhmed ElShreif
For example the DSL syntax will be: >>Delete Comment1 >>Leave Comment1 >>Show Comment1 >>Hide Comment1 >>Resolve Comment1 Change-Id: Ibdd52f3a12f1679f80e9f3290868c77fbf942d6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101513 Tested-by: Jenkins Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2020-08-31remove unneeded includeJim Raykowski
Change-Id: Ia5c5506177f8dd34c79c2792203d0eecf955771b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101667 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com>
2020-08-31tdf#135636 the selection at dialog-launch time is lost by dialog-apply timeCaolán McNamara
since... commit c3a085d22742f88e91ff92f319a26d6e8d1d9a98 Date: Tue Jan 23 18:13:01 2018 +0100 lokdialog: Convert the Table -> Properties... to async exec. so save it at launch and temp apply it during ok handler. This is somewhat similar to tdf#134439 Change-Id: Ia0869307b1a37e5efa1703e68b946793b0ddc91b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101743 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-31duplicate lineCaolán McNamara
Change-Id: I69338ac0c5aa616c21205375f133c959e13414cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101741 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-31Related: tdf#136189 don't assert on unsetting non-existing previous sort columnCaolán McNamara
Change-Id: If2330cc83ace9ec0133b99eec8c2f0be3919013e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101708 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-31tdf#97618 DOCX import: VML shape: fix missing square wrapRegényi Balázs
Co-authored-by: Szabolcs Tóth Change-Id: Ib9db4b0270ed7d4b3d47406f2384276cafdd7249 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101632 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-31tdf#104596 sw layout: wrap in header only if bLayoutInCellJustin Luth
This patch depends on tdf#77794's 7.1 commit 7cc353df4f0993228984fcda3efb2c9181dddafb. For more details about the issue in general, see the verbose comments in this bug's previous 7.1 commit e4635544b816d1ca27bd1ebba60f51444b0a898e. This patch is related to CompatibilityMode < 15. Unfortunately, the previous patch didn't work with older Word 2010 versions of the file, which _shouldn't_ wrap non-LayoutInCell table-anchored flies. Unfortunately, now that different behaviour is necessary for different Word compat levels, it no longer allows a nice way for Writer to handle this natively. So since it would be very unlikely for a user to create a document like this (since the necessary "keep inside text boundaries" is off by default in Writer, but is forced on by definition in Word 2013+), I'm removing the compatibility flag I added in 7.1, and its related unit test. [To do this natively would probably require enabling the IsFollowingTextFlow property by default in SW. That sounds very dangerous since this property is not restricted to IsInTable layout situations. This property has been around since at least LO 3.5.] Change-Id: I70da016cb68f515924ed6c17085bf73a9e1c5492 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100684 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-31tdf#132149 ww8export: nextNode has nothing to do with pageDescJustin Luth
While it can often be assumed that the next paragraph following one that has just soft-page-breaked in the middle will be on the same page, it isn't necessarily correct. Either the paragraph could span multiple pages, or a page-break could push it to the next page. Thus, strip the code out completely, and simply prepare a new page style based on the follow style - which by definition is different enough to not be a plausible single word section. A few followup commits will add enhancements, but this is broken up into minute bits in order to aid in regression identification. Change-Id: I80e4e17be69a49f45a624d819c9c4158541ee065 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101424 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-31tdf#135001 sw_redlinehide: fix IsShown() for AT_PARA flysMichael Stahl
There is one merged text frame from node 102 to node 328 with no extents, and of course a shape anchored at node 271 should not be visible at all. This crashes because the shape was removed from the layout during CheckParaRedlineMerge() but then moved to the visible heaven layer again via sw::AddRemoveFlysAnchoredToFrameStartingAtNode() and the layer determines if it's visible as far as Sdr* is concerned; it lacks a connection to a SwFrame though. warn:legacy.osl:3547848:3547848:sw/source/core/layout/paintfrm.cxx:3861: <SwFlyFrame::IsPaint(..)> - paint of drawing object without anchor frame!? (regression from 6aaae44da382f4bc3eafc287b4a21734b740cf21) Change-Id: Ia20449b3a7d251f0c049eb979c88df1e80cd7d5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101584 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-31tdf#135711: DOCX export: fix crash on page anchored textboxesAttila Bakos
Page anchored objects didn't have the address what is needed for the exporter for positioning. Fixed by using another address. Regression from commit fd88bb81236ad6d1a63436b7ce20f2f93410d359 (tdf#107225 tdf#122887 sw: fix reanchoring of textboxes). Change-Id: I0e41468148e96e1323b9f502aa1f8ca326c5de29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101480 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-08-31Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: Id8f549f69b5007ced62401130894f795dde8fb80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101616 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-31sw: prefix members of SplitTable_Para, SwTableFormatCmp, SwThreadManager ...Miklos Vajna
... and ThreadManager See tdf#94879 for motivation. Change-Id: Idfdba9e9d38310d2e38c6c72e5ecc0738a6b38fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101690 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-30Goodbye O[U]StringView, welcome O[U]String::ConcatStephan Bergmann
O[U]StringView had an odd mixture of uses. For one, it was used like std::[u16]string_view, for which directly using the latter std types is clearly the better alternative. For another, it was used in concatenation sequences, when neither of the two leading terms were of our rtl string-related types. For that second use case introduce O[U]String::Concat (as std::[u16]string_view can obviously not be used, those not being one of our rtl string-related types). Also, O[U]StringLiteral is occasionally used for this, but the planned changes outlined in the 33ecd0d5c4fff9511a8436513936a3f7044a775a "Change OUStringLiteral from char[] to char16_t[]" commit message will make that no longer work, so O[U]String::Concat will be the preferred solution in such use cases going forward, too. O[U]StringView was also occasionally used to include O[U]StringBuffer values in concatenation sequences, for which a more obvious alternative is to make O[U]StringBuffer participate directly in the ToStringHelper/O[U]StringConcat machinery. Change-Id: I1f0e8d836796c9ae01c45f32c518be5f52976622 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101586 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-30Fix typosAndrea Gelmini
Change-Id: I041e65166eab9fc497742635fe59e11f63d55c6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101645 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-30use more fastparser in SvXMLStyleContext subclassesNoel Grandin
Change-Id: I6a1596bdbfa4db128730a663fc590c9e5bfa249d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101659 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Fix typosAndrea Gelmini
Change-Id: I473956d570feac508e52a3e52cc26cc154f4dc56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101627 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-08-29Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I28048bb0396dffa7bcbcb8bcf5fe10e1c359ec79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101624 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I229b9354794b90cd7ad65fa54ecf50eea4983532 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101603 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I63ce9d46922b1a7a1f90308d2eec46b22ff925df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101595 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-29Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually usedStephan Bergmann
0c8fa58a2d73702770687ed15b98822d09f96ac3 "Support ConstCharArrayDetector also for UTF-16 arrays" had introduced those LIBO_INTERNAL_ONLY ctor and operator == overloads, but they never got called because the existing 'sal_Unicode const *' overloads always won. (The other function overloads introduced with 0c8fa58a2d73702770687ed15b98822d09f96ac3 should be unproblematic, as they do not have any 'sal_Unicode const *' overload counterparts.) Also fix the resulting loplugin:elidestringvar and loplugin:stringconstant fallout. For one, those plugins look at the actual ctor overloads being used, so had missed those cases that accidentally had used an unexpected overload. And for another, the heuristic the plugins used to detect the ConstCharArrayDetector overloads turned out to be too simplistic now and would have started to cause false positives. Change-Id: I4426890979fb832d53f391c7e1b62bc1ad501a65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101582 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-29Use OUStringBuffer::makeStringAndClearStephan Bergmann
Change-Id: I2b740fdb18bdb227806b7cce72639bb8f72e5a66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101578 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-28-Werror,-Wdeprecated-copy-dtorStephan Bergmann
> core/sw/source/core/text/possiz.hxx:44:13: error: definition of implicit copy constructor for 'SwPosSize' is deprecated because it has a user-declared destructor [-Werror,-Wdeprecated-copy-dtor] > virtual ~SwPosSize() {} > ^ > sw/source/core/text/porlin.hxx:186:5: note: in implicit copy constructor for 'SwPosSize' first required here > SwPosSize( rPortion ), > ^ apparently since d336e6c26012255015d3fc0caf8e7fafe14bd8f2 "tdf#69647 sw layout: fix line spacing with inline pictures" made the SwPosSize dtor virtual Change-Id: Iabd1eb4c4ceb7e45c86bdd0cac6ded82bc79c015 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101566 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-28Fix ooo38104-1.sxw crash after c123bfff501229f398a1b679fc7434b82d53685cTor Lillqvist
Unlike the c123bf commit, this commit does not cause the crash that was caught by the crash-testing system. (The crash could be reproduced by: wget -O ooo38104-1.sxw https://bz.apache.org/ooo/attachment.cgi?id=19889 ./instdir/program/soffice.bin --headless --convert-to docx ./ooo38104-1.sxw ) In this commit, I reinstate the "early return" in SwView::ReadUserDataSequence() that I dropped in the c123bf commit, but instead move the SelectShell() call earlier, so that it will be executed before the potential early return. The problem that we try to fix here is the one that the fresh CppunitTest_sw_updateall_object_replacements checks, so to reproduce that problem, revert both this commit and c123bf, and then run that unit test. Change-Id: I6c728b75a2f172b75fbf2ad00c019c32aecc19f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101531 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-28Add unit test for c123bfff501229f398a1b679fc7434b82d53685cTor Lillqvist
Change-Id: Ic616ec9f39b65f8e8ec840a48e3b5801b31cf5da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101530 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-28tdf#131801: sw: support of style references in ListAutoFormatVasily Melenchuk
ListAutoFormat property did support char attributes, but not style references ("CharStyleName"). It is important for correct formatting of pilcrow symbol or list format in some DOCX scenarios. Export to DOCX already works, but not to RTF/DOC. Change-Id: I1bf23d1e45fcc213adcf9aa6f404be803919fbee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100893 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de>
generated by cgit (git 2.34.1) at 2024-08-15 19:05:49 +0000