summaryrefslogtreecommitdiff
path: root/sw
AgeCommit message (Collapse)Author
2020-06-23tdf#116194 DOCX import: fix missing tables with w:gridBeforeLászló Németh
Regression from the commit cf33af732ed0d3d553bb74636e3b14c55d44c153 "handle w:gridBefore by faking cells (fdo#38414)" This patch replaces the previous fix with a better solution, fixing tdf#38414 on the proposed DomainMapper level. (Note: to reject the old fix completely, its follow-up commit w:gridAfter will be handled in a similar way.) Now the related regressions, tdf#111679, tdf#120512 and the complex forms of tdf#116194, tdf120256 and tdf#122608 are fixed, too. Reviewed-on: https://gerrit.libreoffice.org/84263 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit da1f71edfc72928b07a569b98e2766a8a7de9d2a) Reviewed-on: https://gerrit.libreoffice.org/84711 Tested-by: Jenkins Change-Id: Id25f5fb4d9021c87ee8c82782b2038e6fb255673
2020-06-23sw: fix use after free on tdf117215-1.odtMichael Stahl
Move the fix from 6d0ea082889c89eb8b408779f2de08da7441ff54 to SwFlyFrame::DestroyImpl() so we unregister every SwFlyFrame. ==1550==ERROR: AddressSanitizer: heap-use-after-free on address 0x615000383f56 at pc 0x7efcd70d5ab9 bp 0x7ffeb7ac7c40 sp 0x7ffeb7ac7c38 WRITE of size 1 at 0x615000383f56 thread T0 0 SwAnchoredObject::SetTmpConsiderWrapInfluence(bool) sw/source/core/layout/anchoredobject.cxx:743:32 1 SwObjsMarkedAsTmpConsiderWrapInfluence::Clear() sw/source/core/layout/objstmpconsiderwrapinfl.cxx:53:23 2 SwLayouter::ClearObjsTmpConsiderWrapInfluence(SwDoc const&) sw/source/core/layout/layouter.cxx:387:84 3 sw::DocumentLayoutManager::ClearSwLayouterEntries() sw/source/core/doc/DocumentLayoutManager.cxx:497:5 4 sw::DocumentStateManager::SetModified() sw/source/core/doc/DocumentStateManager.cxx:45:39 5 sw::DocumentContentOperationsManager::DeleteRangeImplImpl(SwPaM&) sw/source/core/doc/DocumentContentOperationsManager.cxx:3942:36 0x615000383f56 is located 342 bytes inside of 504-byte region [0x615000383e00,0x615000383ff8) freed by thread T0 here: 1 SwFlyAtContentFrame::~SwFlyAtContentFrame() sw/source/core/inc/flyfrms.hxx:159:7 2 SwFrame::DestroyFrame(SwFrame*) sw/source/core/layout/ssfrm.cxx:389:9 3 SwFrameFormat::DelFrames() sw/source/core/layout/atrfrm.cxx:2624:17 4 SwUndoFlyBase::DelFly(SwDoc*) sw/source/core/undo/undobj1.cxx:161:19 5 SwUndoDelLayFormat::SwUndoDelLayFormat(SwFrameFormat*) sw/source/core/undo/undobj1.cxx:403:5 6 SwHistoryTextFlyCnt::SwHistoryTextFlyCnt(SwFrameFormat*) sw/source/core/undo/rolbck.cxx:538:20 7 SwHistory::Add(SwFlyFrameFormat&, unsigned short&) sw/source/core/undo/rolbck.cxx:1083:50 8 SwUndoSaveContent::DelContentIndex(SwPosition const&, SwPosition const&, DelContentType) sw/source/core/undo/undobj.cxx:1020:39 9 SwUndoDelete::SwUndoDelete(SwPaM&, bool, bool) sw/source/core/undo/undel.cxx:229:9 11 sw::DocumentContentOperationsManager::DeleteRangeImplImpl(SwPaM&) sw/source/core/doc/DocumentContentOperationsManager.cxx:3939:55 Change-Id: Ia0c28c9d5792615cbb566e502374efd0f4056daf Reviewed-on: https://gerrit.libreoffice.org/75857 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit dea72ef111ee8a0b1b178f8cd48757514d5ca831) Reviewed-on: https://gerrit.libreoffice.org/75941 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 4b9324b93dcbd72c8c8949309d45790dd8f7d5fd) Reviewed-on: https://gerrit.libreoffice.org/76306 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 00c4ae49aa88319660b9201e8e5d8393953fa1ed)
2020-06-23forcepoint73 deleted SwAnchoredObject still referenced in TmpConsiderWrapInflCaolán McNamara
Reviewed-on: https://gerrit.libreoffice.org/58760 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 6d0ea082889c89eb8b408779f2de08da7441ff54) Change-Id: If255723834d049865fcf6fd0eac7768dfcbad2a1 Reviewed-on: https://gerrit.libreoffice.org/58768 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit de765158b372d5f7bbb1b37c7d6be695ab6104ac)
2020-06-23ofz#11125 pass param len aroundCaolán McNamara
Change-Id: I4b382271df21c58de0e102af6e0b07a88a1d9610 Reviewed-on: https://gerrit.libreoffice.org/62448 Tested-by: Jenkins Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 6253b1a29c8c1bcd7fd9efb07ca1a12fb0fc1746)
2020-05-18DOCX export: fix interaction between the crop and the wrap polygon of imageMiklos Vajna
If the wrap polygon is influenced by crop at import time, we need to do the opposite at export time. Do this for RTF and DOCX, where there is matching import code in writerfilter/, leave DOC alone for now. Test this by changing testFdo76803 into an export test, then seeing how the first point's Y position fails and fixing up the exporter, so we get back the old good value. Conflicts: sw/source/filter/ww8/docxsdrexport.cxx writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx (cherry picked from commit c68b458514b35cae70c9a6630e06f46a867aa3b9) Change-Id: Ieef18aad3c76f7945c7348201b07bcb27a4cd48d
2020-05-18DOCX import: fix interaction between the crop and the wrap polygon of imagesMiklos Vajna
Word first applies the crop, then applies the wrap polygon on the remaining visible part of the image. Writer applies the crop on the original bitmap, and even has explicit code to make sure the uncropped bitmap is used for the wrap polygon, see how SwFlyFrame::GetContour() calls SwNoTextFrame::GetGrfArea(), which will extend the resulting size based on cropping. Fix the problem by moving and scaling the wrap polygon, so it ends up where it would in Word. Also adapt testFdo76803, which had a similar crop+wrap polygon case, but the different there is quite small. (cherry picked from commit 2abe9837deee3823c7928a76b5b2f94f1464f1a3) Conflicts: writerfilter/CppunitTest_writerfilter_dmapper.mk writerfilter/qa/cppunittests/dmapper/GraphicImport.cxx Change-Id: Iab2adaa81a33eb04e1806b17ed129ac50f5d2aa3
2020-05-18tdf#130494: DOCX import: limit paragraph-level character propertyLászló Németh
expansion for the whole table paragraph based on the last character context. regression from 2ab481b038b62b1ff576ac4d49d03c1798cd7f84 (tdf#90069 DOCX: fix character style of new table rows) (cherry picked from commit abb9c7db8bcc06f907d39a7811711882161d5803) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx writerfilter/source/dmapper/DomainMapper_Impl.cxx Change-Id: I49da23c268436488ff1537771869c38108113c12
2020-05-18tdf#128959 DOCX import: fix missing text lines in tablesLászló Németh
Orphan/widow line break settings aren't always ignored by Writer table layout code, in this case, in vertically merged cells, resulting missing paragraph lines. As a workaround for interoperability, disable orphan/widow control in cell paragraphs during the DOCX import to get correct layout in Writer, too. (cherry picked from commit 8b13da71aedd094de0d351a4bd5ad43fdb4bddde) Conflicts: sw/qa/extras/layout/layout.cxx writerfilter/source/dmapper/DomainMapper_Impl.cxx Change-Id: I48fdb0a3bb421fd4df2c729e307a7ef483e3e772
2020-05-18tdf#118672 sw layout, TabOverMargin: allow using the area over the tab portionMiklos Vajna
TabOverMargin in general is about allowing the cursor to jump over a margin if there is an explicit tab stop there. A corner-case is what to do when there is enough content so a line break is necessary for the characters after the tab portion. Allow using the area up to the edge of the whole text frame (i.e. over the tab position), this matches what Word does. (cherry picked from commit 4b345f95ce7cb09011892bf465cfdf3811adaf8e) Conflicts: sw/qa/extras/layout/layout.cxx sw/source/core/text/inftxt.cxx sw/source/core/text/xmldump.cxx [ Just the sw layout xml dump part. ] Change-Id: Ie86edf030d54fba556eee26e7ea563fb8d4fbee4
2020-05-18tdf#90069 DOCX: fix character style of new table rowsLászló Németh
DOCX table import didn't set paragraph level character styles on paragraph level, only on text portions, resulting default character style in the newly inserted table rows instead of copying the style of the previous table row. (cherry picked from commit 2ab481b038b62b1ff576ac4d49d03c1798cd7f84) Conflicts: sw/qa/extras/uiwriter/uiwriter2.cxx Change-Id: Idb4438c767bdc7e0026fc6e0f0a795d8efdda3c8
2020-05-18tdf#126723 writerfilter::finishParagraph - me, not previousJustin Luth
In LO 6.2 commit 480ac84f2f5049fb4337b36f12fd6796e005761b the existing m_xPreviousParagraph was conveniently used to apply the changed properties. I never did like that choice, but despite looking at it, I failed to see that it is set in an inside loop, which means that it was NOT NECESSARILY reset to the current paragaph. So I'm happy to have proof that we should not use m_xPreviousParagraph. (cherry picked from commit 4c096b7e75a3c47abe4b3eb41183c133cb4cb441) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport13.cxx Change-Id: I5c7f1b0f097711d65ae0d0be1f0fbc40c8b96e9d
2020-05-18tdf#119188 DOCX import: fix zero margins of numbered lines in cellsLászló Németh
regression from 5c6bce38a01b21403a603acd3148cf3bbb4c685f (tdf#104354 DOCX import: fix paragraph auto spacing in tables). (cherry picked from commit 5e2caf236091c71b2148970eba36b22655d8845a) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: I486d155eb4463599ab922837fd2f4347b48e0851
2020-05-18tdf#118521 writerfilter: ContextMargin grouped with Top/BottomJustin Luth
fixes tdf#104348, but tagging with the bug# of the initial fixes. Internally, EditEng holds Top/Bottom/Context settings in one object, so if only one piece is set, the cloned object starts with docDefaults, so the un-initialized parts also need to be specified with the values they inherit from their style. So this patch makes two corrections. The first is grouping ContextMargin with top/bottom. The second correction is to check the entire style-chain instead of only the direct style for the inherited property. Change-Id: Ie1d4c9538aefece4ff8b7287242c7f4d33319b3b Reviewed-on: https://gerrit.libreoffice.org/57914 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 07266e2314fd19dcbf777dadd52d7b826b23c207)
2020-05-18tdf#118521 DOCX import: style sets unset left/right/hanging marginJustin Luth
followup to commit 480ac84f2f5049fb4337b36f12fd6796e005761b which nicely paved the way by doing this for top/bottom. (cherry picked from commit eab67995d7056682c250efa3c903b1fffd812700) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport11.cxx Change-Id: I61b4e298e8732391b4f0467b459d9c15298925fa
2020-05-18tdf#117504 ooxmlimport: check paragraph props for actual styleJustin Luth
m_sCurrentParaStyleName sounds like a nice idea, and has been around since the initial fork, but by the time finishParagraph() rolls around, the chances that it is still accurate are rather low. Anything that contains a paragraph (like comments, textboxes, shapes, tables, flys etc) might have modified that value. This fix queries the current paragraph itself to see if PROP_PARA_STYLE_NAME is set, which it typically is by lcl_startParagraphGroup() except when IsInShape(). If it isn't specified, then fallback to the previous result, which still may not be accurate, but at least it won't be a regression. It is too late in the development cycle to look into fully eliminating m_sCurrentParaStyleName. I hope to investigate that in the 6.2 development cycle. (cherry picked from commit 8920d865ee148518bf71f71ce1866b24cc17c07e) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport12.cxx Change-Id: I124688d864f553dd5778b3593f511cc41d31c262
2020-05-18tdf#95377 ooxmlimport: treat default style like named stylesJustin Luth
The default style was missing out on all of the fixes made by LN_CT_PPrBase_pStyle. That included right margins, and numbering styles. Essentially, this change is just copy and paste from one function to another. I tried to make all of the logic changes separately in previous commits. So the adjustments here are simply to accommodate different variable/function names. So if this causes any regressions, it ought to just be related to either applying later on (at finishparagraph instead of LN_CT_PPrBase_pStyle or because it includes the default style. One important note regards the preparatory commit 254c80037a3939c110d5c66fef6c28caf47625e5. If this commit is reverted, make sure to check that commit to add a conditional wrappers around GetCurrentNumberingRules(). (cherry picked from commit cc1c9c7484d97167021301f32c3397124c4d79f5) Conflicts: writerfilter/source/dmapper/DomainMapper.cxx Change-Id: I9827b2cd1a74a13cf18ada9baa221c5c567a7391
2020-05-18tdf#76817 ooxmlimport: connect Heading to existing numbersJustin Luth
This fixes the inability to insert a numbered Heading into an existing sequence in an opened document. Before it would start a new sequence, but now it connects to / adjusts the other numbered Headings. LibreOffice has built-in handling for "Chapter Numbering". All of the formatting for this is tied to the paragraph stylename. Since MSO has a different structure, in docx format these are defined as "regular" styles with an OutlineLvl component. During import, that style information was copied to LO's special Outline chapter numbering style. *From this point on, the "regular" list style should no longer be referred to.* Numbering is only defined by the paragraph stylename (which by definition is "Heading X"). The unit test I am hijacking has an unchangeable Paragraph Numbering style of "Outline Numbering" and not WWNumX. So, in reality the document ought to require the style name to be the internal Outline style like it originally was. A followup patch allows this to round-trip. Change-Id: If5d544529fa32d4abaa2b46403bc61c028e53f21 Reviewed-on: https://gerrit.libreoffice.org/47827 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 7201d157a2ff2f0a8b6bb8fa57e31871187cbc81)
2020-05-18ooxmlimport: support inherited listidJustin Luth
This is prep work for tdf#95377. This unit test avoids the unique chapter-numbering style (from the heading paragraph styles) and just has a basic, user-created style inheriting from Default. Also unique about this unit test is that the numbering is specified by the "Default Style" which takes a rather unique code path and exposes even more problems. We already know the listId through a recursive function, and GetCurrentNumberingRules only looks at the current style which isn't good enough. Moved that modified function into DomainMapper_Impl since I will need it there for bug 95377. Additionally, ensure that directly applied paragraph properties are not overwritten. That also meant changing the order, so that paraStyle properties are directly applied to the paragraph before applying RightMargin and friends. Change-Id: I5c1fb71d64727be9d9105f287150daf4e0ff413d Reviewed-on: https://gerrit.libreoffice.org/48457 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 8fd13c356d78fb72ba5dd288a495551f23e15363)
2020-05-18tdf#104354 DOCX import: fix paragraph auto spacing in tablesLászló Németh
Top margin of first paragraph of a table cell with auto spacing, and bottom margin of last paragraph of a table cell with auto spacing are zero (except in numbered last paragraphs), but LibreOffice set 14pt instead of them, resulting much longer tables. Following cases needed special handling: - auto spacing in style - direct top and bottom auto spacing - direct top and bottom margins - footnotes in cell paragraphs Change-Id: I462847616dd43b4ba30fae2c4eb99abb49bfb9a3 Reviewed-on: https://gerrit.libreoffice.org/57352 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 5c6bce38a01b21403a603acd3148cf3bbb4c685f)
2020-05-18tdf#106062 ooxmlimport: skip fake tab only on hanging indentJustin Luth
Export has changed, so that it only exports a tab when the footnote paragraph has a hanging indent. Adjusting the import code to match that change. Please test with MSO before flagging this patch as a regression. Certainly there will be some documents previously saved by LO which will now, in LO, show an extra tab character after the footnote. Any previously saved document without a hanging indent will display this extra tab. However, MSO has always seen that extra tab, so these patches are enhancing compatibility. This patch corrects several incorrect assumptions: -The paragraph style is not necessarily "Footnote". -The paragraph may have directly defined a hanging margin. -An aesthetic tab is needed on a hanging indent, not a defined margin. (cherry picked from commit 946fee3ef1e319ad63a599b72dbd55ef52cbc640) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport9.cxx Change-Id: Ieaa76448ce202d92efdb8d1fc04ba2674ed120ba
2020-05-18tdf#106062 ooxmlexport: hanging indent ? aesthetic tab : noJustin Luth
By default, LO footnote paragraph style has a hanging indent of .60cm. In LO footnotes, the footnote character starts at the hanging indent (position 0) and the footnote text "magically" starts at the left margin. MSO doesn't do any magical formatting so exporting emulates that by inserting a tab after the footnote character. However, that aethetic tab was being inserted after EVERY footnote character, regardless of whether the emulation was needed or not. That particularly caused problems when the document was originally authored by MSO, which typically has no margin or first line indent. In those cases, the document is altered by gaining undesirable extra space. Since the emulation is only of value with a hanging indent that is larger than the footnote character, only add the tab when a hanging indent exists. (Checking the size of the hanging indent could improve this even more, but measuring font size etc adds too much complexity.) The import code also knows about the fake tab and removes it. Follow-up patches will change the import to ONLY remove the fake tab if there is a hanging indent. (That is going to cause "regressions" because tabs from some previously saved documents will now show the "aesthetic tab" - just like MSO does.) Change-Id: I371da3f2b09f600f027377a36583f91b39425151 Reviewed-on: https://gerrit.libreoffice.org/52171 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 818619b0f2f7813decb26d0b14362dec76a8ff37)
2020-05-18tdf#112886 ooxmlimport: skip useless footnote placeholderJustin Luth
Inserting the 0x02 placeholder as the first entry in the line interferes with the aesthetic tab code. lcl_text has code to ignore that placeholder, but lcl_utext doesn't. Ignoring at lcl_utext has the same affect as not processing it at all. Only .docx adds 0x02, so it should be fairly safe to avoid the 0x02 completely. Nothing was detected missing by skipping the placeholder. All of the code was inherited from OOo. Change-Id: Ie8840e5946fec89f270fef5523c88ee5051ca8ef Reviewed-on: https://gerrit.libreoffice.org/51912 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 3138abfb052a4241cfca4b8d430c139cca50a85c)
2020-05-18tdf93121 MS export: only one fake tab per footnoteJustin Luth
Every paragraph was getting the fake tab added. The fake tab is only inserted by LO in order to emulate the spacing between the footnote character and the footnote paragraph, so it is not desirable to insert it before additional paragraphs. The fake tab is also only removed once per footnote during the import process, so this fake tab was altering the document during the first round-trip. (cherry picked from commit add7a962bc33b3c1f2252a9920bebf324df688de) Conflicts: sw/source/filter/ww8/wrtww8.cxx Change-Id: Ia54cea1b04c747a021032f46f22b673fe6658995 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94324 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-03-03SwCursorShell argument of AttrChangedNotify is unusedCaolán McNamara
Change-Id: I1fde665dcb77d29cad7f6a5c12e82c1822cff022 Reviewed-on: https://gerrit.libreoffice.org/80621 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2020-01-10tdf#128207: DOCX import: fix chart positioningBakos Attila
Embedded graphic objects had got 0 values for vertical and horizontal positioning before, resulting overlapping, hidden charts, but now they are positioned according to the values in the document. (cherry picked from commit d9c535ead688e9f156dbcf43948df08a69e218be) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport14.cxx [ Miklos: reworked the testcase to use the UNO API, the other way would only work on master. ] Change-Id: Ia5403ac65ff7192d61072e8a9d8a7f80c7178b9b
2020-01-09sw: don't send LOK notifications about redlines during saveMiklos Vajna
SwXMLWriter::Write_() sets redline flags to show insertion and hide deletion, but it resets those flags before the function returns. So LOK notifications for redline changes during save is not useful. Conflicts: sw/qa/extras/tiledrendering/tiledrendering.cxx Change-Id: I4bf963bbe9c7003cbe85ea6c5538be733a3e3cdf
2019-10-09DOCX import: fix interaction of table and paragraph style in table cellsMiklos Vajna
Both table and paragraph styles can define paragraph properties for the content of table cells, e.g. line spacing. The intended behavior is that direct formatting has priority, then paragraph style, then the table styles. But in practice table style had priority: table style is turned into a set of property name-value pairs by writerfilter/ code, then this is applied to the content of a cell using SwXCell::setPropertyValue(). To make sure that direct-format-from-table-style doesn't override direct-format, there was already a check to not replace properties which are set directly. The problem is that in case the property value comes from a paragraph style, that's not direct and still should have priority over direct-format-from-table-style. Fix this by checking for custom values not only in the paragraph's item set, but also in its parents. Unless the parent would be the default style, which doesn't count. Or in case the paragraph is numbered, which complicates the situation, so leave that case unchanged. Reviewed-on: https://gerrit.libreoffice.org/80146 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit c424a1f509205cfbaa3421bddfd6514b340a798a) Change-Id: Ib554247cdc51fee0d9a6c7a26aecd38442dfa692 Reviewed-on: https://gerrit.libreoffice.org/80294 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-10-09tdf#126544 writerfilter: check parent style exists before assigningJustin Luth
If you set the parent style to a style that is not yet created, then it silently fails, and thus inherits from nothing! Change-Id: Ibb85235643dd5b1eb9b0bd43f701580f24b2b7fa Reviewed-on: https://gerrit.libreoffice.org/76805 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit b47a8f091ad8f9048a6b7962e9cde5d04ea0d665) Reviewed-on: https://gerrit.libreoffice.org/80503 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-10-09tdf#117297 sw unotbl XCell: apply char/para style props to textJustin Luth
This is specifically for the benefit of DOCX import, but it also makes sense in general. If a SwXCell is given char/para properties, then apply those properties (without overwriting) to the cell's contents. This allows ANY paragraph or character properties that are applied to a table style to become the "default" for the table. This fixes a number of things: -remove one-off hack to get PROP_PARA_LINE_SPACING to work. -works for all character and paragraph properties (except those shared with tables like borders). -works in multi-paragraph cells. Previously those could return AMBIGUOUS state, in which case the style wasn't applied at all. Change-Id: Ia98c129879575c1aa8ca1fe2a64f4991c0a264e8 Reviewed-on: https://gerrit.libreoffice.org/54511 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 5e4d89f59614cec08376e1e77625f8610a1490e5) Reviewed-on: https://gerrit.libreoffice.org/80293 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-10-09NFC SwUnoCursorHelper: add SetModeAttr option to setPropertyValueJustin Luth
The other function, setPropertyValues already has this variable, so for consistency and flexibility, add it here as well. Plus, this is prep work for another patch. Change-Id: I16c5b1cbb9fd99a11be99a59005bd856d787a6ca Reviewed-on: https://gerrit.libreoffice.org/54510 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit f7f2d03bd6f5aa5dcd0f7976b4a7f2db278c2f03) Reviewed-on: https://gerrit.libreoffice.org/80292 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-10-07lok: comments: fix hidden text cursor and sudden document scrollMarco Cecchetti
On Android, SwAnnotationWin::Rescale leads to invoke ImpEditEngine::UpdateViews which hides the text cursor. Moreover it causes sudden document scroll when modifying a commented text. Not clear the root cause, anyway skipping this method fixes the problem, and there should be no side effect, since the client has disabled annotations rendering. Change-Id: I572a9c6b3fe39473a596209413945d777bd79506 Reviewed-on: https://gerrit.libreoffice.org/80243 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>
2019-09-27lok: send an invalidation by document size changeTamás Zolnai
It was sent by the kit code earlier. Now we move it to the LO core code, so we can optimize it later. co-author: Michael Meeks <michael.meeks@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/79491 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit cd7ff1797d754018db1d47888781c9d7ecb24dcf) Change-Id: Id0a8991016dbe8d13891071e2d5b4c9250720da9 Reviewed-on: https://gerrit.libreoffice.org/79617 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2019-07-15sw: fail loading when the fallback text detection failsAshod Nakashian
When we document in question fails to match any known type, we try to open as plain text (and convert to a Writer doc). However we should not display non-text when we have failed to detect ascii or unicode contents in the file. This happens with corrupted documents, for example, where we end up displaying non-printable binary data. Change-Id: Iccc158a4cb6051a8b17ba01987a30a9882a27fa9 Reviewed-on: https://gerrit.libreoffice.org/75512 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Jan Holesovsky <kendy@collabora.com> (cherry picked from commit d1f6f27e2a014aa55e2762f1209dc520fb183404) Reviewed-on: https://gerrit.libreoffice.org/75625 Reviewed-by: Andras Timar <andras.timar@collabora.com> Tested-by: Andras Timar <andras.timar@collabora.com>
2019-06-19More uses of referer URL with SvxBrushItemStephan Bergmann
Reviewed-on: https://gerrit.libreoffice.org/73643 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit b518882de8213ef71a8003f95fbdf7689069c06d) Conflicts: sw/source/core/text/porfld.cxx sw/source/core/unocore/unosett.cxx Reviewed-on: https://gerrit.libreoffice.org/73860 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 87c418a98650ab6e4a62a0b4b72e02fee358dced) Change-Id: I04b524784df4ef453d8b1feec13b62f183a17e23
2019-06-12tdf#118375, tdf#70838 correct position of rotated shape in docRegina Henschel
Word relates the position to the unrotated shape in legacy doc format. Writer uses the rotated shape. The patch corrects the difference on import and export. Reviewed-on: https://gerrit.libreoffice.org/70152 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> (cherry picked from commit 421e6fc3cd2e6fe37afbef341e2d0ad7b8edde37) Change-Id: I25537123656e62d6ffae5118ee8d621a4b5c5be0
2019-06-12tdf#120145 ww8import: ignoreCols if section is insertedJustin Luth
Otherwise, the column setting is duplicated both in the section and in the page style. Change-Id: I14383c646e709a3653f1054f0d4170a2963529c1 Reviewed-on: https://gerrit.libreoffice.org/66151 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 84fefd7c295fc05499ca222dff50c2fe4e0fb27e) Reviewed-on: https://gerrit.libreoffice.org/66217 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 0e863f5529318e07f46568150e489cb0bef9b616)
2019-06-12tdf#123636 writerfilter: handle deferred breaks on framesJustin Luth
and... related tdf#123636 writerfilter: split newline also if PAGE_BREAK ...but only with old MSWord compat flag SplitPgBreakAndParaMark. All of the other cases (COLUMN_BREAK and non-empty runs) split the paragraph, so why not here? This document shows it is needed, but only for SplitPgBreakAndParaMark documents. Note: Word 2003 doesn't display "modern" docx well in this regard. It adds extra paragraphs where it shouldn't. There are already example unit tests that ensure that extra paragraphs aren't written for SplitPgBreakAndParaMark == false. The actual bug's document is not related to the compatibility flag. That will be handled in separate commit. Reviewed-on: https://gerrit.libreoffice.org/70835 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 89e44da1ab450f6e2f4106103efd169227683f20) tdf#123636 writerfilter: handle deferred breaks on frames ...similar to handling breaks before shapes in lcl_startShape. Three different examples found to create/split a paragraph. Which one to use? (addDummy, m_bIsSplitPara, and lcl_startCharacterGroup). SplitPara is not good because the paragraph properties probably should not be copied to the dummy paragraph (like numbering for example). Slightly modified the lcl_startChar example to ensure that the dummy paragraph doesn't steal a part of the properties, but is only default properties plus page-break. This doesn't export very well, so roundtripping is very poor. Research Note: There exists a compat flag showBreaksInFrames (Display Page/Column Breaks Present in Frames) "This element specifies whether applications should honor the presence of page and/or column breaks which are present within the contents of paragraphs which have been defined as frames using the framePr element." --Currently, LO does nothing with this flag. Probably too exotic and irrelevant (word 2003 era?). No existing unit tests found that have isSet(pg_brk) frames. Reviewed-on: https://gerrit.libreoffice.org/71255 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit f6f53f76e15f5eecc5b6ce56e471c53cebfea8ad) Change-Id: I29f815355401c7af8b347a3ed9d0298bc9b27b93
2019-06-12tdf#120515 ODT filter: relax layout requirement before exportMiklos Vajna
This reverts commit 343af46fc301a984929e071d477b8fb9f211e289 (ODT filter: make sure we have a layout before export, 2017-11-29) as it causes a performance problem with large documents (see bugreport). I added it initially for the EPUB export, but there this is no longer needed as commit 3ed8466b55ace15a28761e06b6bb76ebd8758106 (EPUB export, fixed layout: switch to a metafile-based approach, 2017-12-01) switched to the better metafile-based approach. (cherry picked from commit e83c1f0ef999bdedaf9a5d5903aa5423c40f6d95) Change-Id: Ie404e23db77b8ded1d29f42b6279a3cd06a574b5 Reviewed-on: https://gerrit.libreoffice.org/71943 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>
2019-04-25tdf#120338: The paragraph formatting changes are not undone, part 1Henry Castro
Rejecting paragraph formatting is not implemented yet. "Reject All" command is affected because the changes were not removed Change-Id: Ic4af1def97025643ecbc5cf0752cd06d9b94c74a Reviewed-on: https://gerrit.libreoffice.org/69865 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/70202 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-04-25disable SwUiWriterTest2::testTdf122942 on MacAndras Timar
Change-Id: I1c7e1ea5b3ba5fa8b6969081b0df4eba48af327c
2019-04-23tdf#123651 sw AddVerticalFrameOffsets: make vert offset depend on hori offsetMiklos Vajna
Regression from commit 961ba62df045473e5793d9e103be86eaad8d9575 (tdf#123032 sw, AddVerticalFrameOffsets: fix shape pos after mouse move, 2019-02-07), the vertical position of the bugdoc was too large, and turns out Word only works with vertical offsets if there is already a horizontal offset. For example open tdf98987.docx in Word, remove the left square shape, notice how the other square shape jumps up due to no longer working with a vertical offset (while the doc model vertical position of the shape is unchanged). Change our layout, so that in case the AddVerticalFrameOffsets compatibility flag is on (which was added to emulate Word's behavior), we also consider the horizontal offset before setting the vertical offset. Also improve the SwUiWriterTest2::testTdf122942() test that asserted doc model positions, which are now different (needed so that at the end the layout position visible to the user is unchanged). (cherry picked from commit 27894be916d5d03ee820e757d2f4abbf21d54615) Conflicts: sw/qa/extras/layout/layout.cxx sw/qa/extras/uiwriter/uiwriter2.cxx Change-Id: I8ac451efbacefdd3578b3a578260e7b2060c16a6 Reviewed-on: https://gerrit.libreoffice.org/71128 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2019-04-23tdf#123032 sw, AddVerticalFrameOffsets: fix shape pos after mouse moveMiklos Vajna
Regression from commit 50223ea6e212b60b7d33839c2753c5601fb50f95 (tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31), the problem was that vertical position of the shape was wrong after mouse move, even if we attempted to take fly frames of the paragraph into account. (Similar situation is when saving and loading the file; which is much easier to test.) Fly frames are created as the text frames is formatted, and then SwTextFrame::CalcBaseOfstForFly() can calculate the vertical offset correctly. But in the "move with mouse" case SwToContentAnchoredObjectPosition::CalcPosition() was invoked by the time the old flys of the text frame were already removed, but the new ones were not yet added. Solve the problem by formatting the text frame from SwAnchoredDrawObject::MakeObjPosAnchoredAtPara() (if any of its validity flags are set to false) -- this is expected to be safe, as the object formatter is invoked by SwLayAction::FormatContent(), i.e. there is no recursive SwFrame::Calc() call here. (cherry picked from commit 961ba62df045473e5793d9e103be86eaad8d9575) Change-Id: I95851874e3da3f50f304421537c6743e04bdfc7b Reviewed-on: https://gerrit.libreoffice.org/71127 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2019-04-23tdf#122942 sw: update shape insert UI for the AddVerticalFrameOffsets optionMiklos Vajna
Regression from commit 50223ea6e212b60b7d33839c2753c5601fb50f95 (tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31), SwFEShell::ImpEndCreate() was not adapted to call SwTextFrame::GetBaseVertOffsetForFly() when determining the vertical position of the inserted shape. The call can be unconditional, the returned value is already 0 when the DocumentSettingId::ADD_VERTICAL_FLY_OFFSETS compat setting is false. (cherry picked from commit 4218caf142a7ecac34548c6d38c6f6fbebb898b9) Conflicts: sw/qa/extras/uiwriter/uiwriter2.cxx Change-Id: Iec6af5a6d1ff3466e08377853cc8ca84f33a76d1 Reviewed-on: https://gerrit.libreoffice.org/71126 Reviewed-by: Aron Budea <aron.budea@collabora.com> Tested-by: Aron Budea <aron.budea@collabora.com>
2019-04-19Fix build without precompiled headers (on Linux)Tor Lillqvist
Change-Id: Ic33646ec1af38d36c344fd7ec1ccfdcb838bc716
2019-04-19Add a SAL_INFO to SwWordBasic::FileSaveAs()Tor Lillqvist
Change-Id: I04a3a22918ead008b560c2e1159747e8d28da404
2019-04-19Add XWordBasic.FileSaveAs() and implementTor Lillqvist
Factor out the setFilterPropsFromFormat() also used by SwVbaDocument::SaveAs2000() to a header file of its own. Change-Id: I4bc9e1e420719a115036beb7e82a4ac3feac05f0
2019-04-18Build fix after commit 916c5834d09a4f9742cbdd00ab5d53b140a97153Mike Kaganski
Change-Id: Ia5ca829877712b9814ce6eee392d8f1f23a7e97b Reviewed-on: https://gerrit.libreoffice.org/70915 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-04-17sw lok: add unit test for deselect custom shapeHenry Castro
Change-Id: I41a9ff0d281d9032ddaafbbcb55352254a809efe Reviewed-on: https://gerrit.libreoffice.org/70824 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/70880 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-04-17sw lok: fix "Cannot deselect the shape after inserting the first in a...Henry Castro
document" Change-Id: I976318fe299306b65190b4f5ae0ed2565830c6f7 Reviewed-on: https://gerrit.libreoffice.org/70475 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com> Reviewed-by: Henry Castro <hcastro@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/70794 Tested-by: Jan Holesovsky <kendy@collabora.com>
2019-04-12f315fee54eee57e6e55e5fcacf2522534682c2ce follow-up: fix tdf#109310 unit testMike Kaganski
The test should guarantee presense of w:val attribute of w:rStyle element. Turns out we must not use w: namespace before attribute name; likely it is true when attribute namespace is the same as of its element. Change-Id: I28e2936b51f039473326c6debf4b5559e2baf24c Reviewed-on: https://gerrit.libreoffice.org/70612 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/70681 Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2024-06-08 18:25:19 +0000