summaryrefslogtreecommitdiff
path: root/sw
AgeCommit message (Collapse)AuthorFilesLines
2019-11-23SpellingPopup: Create separate SID for Ignore / IgnoreAll / suggestion.Tamás Zolnai3-123/+143
Change-Id: I20f41f511ea38f960f081f92bc36e095f7752d28
2019-11-23SpellingPopup: lok: Replace the tunneled context menu.Tamás Zolnai4-12/+121
Send the menu structure instead using LOK_CALLBACK_CONTEXT_MENU. We need to set commands for menu items to make fillPopupMenu() method work. We also need to check whether there is any selection during execution of menu items. In case of LO core execution the suspicious text is selected, however in case of LO online, there is no selection. Change-Id: Id696ee9976d11f6b57e23a3bcc5b483a1d486639
2019-11-23SpellingPopup: lok: Hide unusable items for onlineTamás Zolnai1-0/+7
MN_EXPLANATION_LINK is some link, but it's exectued internally, which means the the link would be executed on the serves side and not on the client's browser. m_nCorrectMenuId is a sub menu which allows to specify new autocorrect rules. Since m_nAddId is also disabled, I expect that extending the dictionaries / autocorrect rule might be a problem for online. Change-Id: Id6e8ed078f90a4f25a335a3ab5ec0e3056db648d
2019-11-23SpellingPopup: Convert suggestion menu items to use slot ID.Tamás Zolnai2-20/+106
Change-Id: Icf1f50d04ab5e7ba467d68613f4101a3fe48589b
2019-11-23SpellingPopup: Remove m_aSuggestions member variableTamás Zolnai2-15/+20
We don't need it after the construction. The text is stored by the menu item. Change-Id: I54b0392b4564e76d405824bb297e6f993a24a5fb
2019-11-23SpellingPopup: Convert "IgnoreAll" menu item to use a slot ID (spelling).Tamás Zolnai3-17/+22
When the popup is in spelling mode. "IgnoreAll_Spelling" rule triggers this method. Change-Id: Ia1e1877f8501beff29f09bc33621c8f03008b7e8
2019-11-23SpellingPopup: Convert "IgnoreAll" menu item to use a slot ID (grammar).Tamás Zolnai3-21/+43
When the popup is in grammar mode. "IgnoreAll_Grammar" rule triggers this method. When openning the spelling popup we have the suspicious text selected, so we don't need the mouse position to apply the changes. I updated GetGrammarCorrection() method accordingly. Change-Id: Iaf86544ea5f7dbc4afa2889772a5a38c5fd5707e
2019-11-23SpellingPopup: Convert "Ignore" menu item to use a slot ID.Tamás Zolnai3-3/+31
Introduced a new slot id SID_APPLY_SPELLING, which can be used to apply any spelling / grammar related changes (e.g. ignore, ignore all, replace with suggestion, add to dictionary). In this commit, only the simple ignore is implemented. Change-Id: I06ab84efeb955cc02ce3ff531bd8b5c20ddced9e
2019-11-23SpellingPopup: Move setting UPN_IS_GRAMMAR_INTERACTIVE to the constructor.Tamás Zolnai1-4/+2
Change-Id: Ief5470e0a61f0ca40549ab6d3768c795c3f04510
2019-11-23SpellingPopup: lok: Also hide the add menuTamás Zolnai1-0/+1
Change-Id: Ic6b10d579fe1fb0afe5e80244e84ed456dc6cc87
2019-11-23SpellingPopup: Remove unused variablesTamás Zolnai1-2/+0
Change-Id: I3cb3b128ec54f82381bf6f0c17401a5d5fb58a96
2019-11-23SpellingPopup: Convert selection language items to use slot idTamás Zolnai1-15/+6
Change-Id: I10a89d7efa957e6b94e793158983c5acf623e511
2019-11-23SpellingPopup: Convert paragraph language items to use slot idTamás Zolnai1-16/+6
Change-Id: I36df4777b408f9defd883d49413847152f6b496f
2019-11-23SpellingPopup: Convert char dialog related items to use slot idTamás Zolnai3-11/+5
After this change we can make sw_CharDialog() a local function. Change-Id: I34b15fccaed07b5d89f63a69da8c870fff0e9b14
2019-11-22make some classes module-privateNoel Grandin3-14/+14
Change-Id: If7303a082e06f6937fca911c578a40475546cda2 Reviewed-on: https://gerrit.libreoffice.org/83442 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-22uitest for bug tdf#126168Zdeněk Crhonek1-0/+52
Change-Id: I35b7235b7f53789d781a567efe15f13be16f7193 Reviewed-on: https://gerrit.libreoffice.org/83530 Tested-by: Jenkins Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
2019-11-22tdf#128499 DOC export: fix lost ToC formatting regressionLászló Németh1-1/+2
caused by commit 7376a47680b65cbdfd747a736f288e06f51f7f2d (tdf#92335 DOCX: fix multiplying of "ListLabel" styles). Change-Id: I7d6fc2be3ad7556b988cb00936b9b49deae23f19 Reviewed-on: https://gerrit.libreoffice.org/83443 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-22Resolves: rhbz#1775544 crash in navigatorCaolán McNamara1-6/+2
see demo reproducer in rhbz#1775544 nChildCount is a count of all descendants not just direct children. Just looping while FirstChild returns something is sufficient. Change-Id: If7b16032731d694bfffaae22faad5fe194d1822f Reviewed-on: https://gerrit.libreoffice.org/83454 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann192-25/+1216
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-22tdf#128153 docx/VML: apply style properties to shape textJustin Luth4-24/+24
This replaces LO 4.3 commit 8766011bccfd0f12f8dd77d2f94eb16e2e8c3471 DOCX import: set document-level font size default based on default para style ...and is needed for tdf#118947, since bogus DEFAULT_VALUEs really hinder determining what a table style should override. Shape text should inherit the font size from the style that is specified. In many cases, it will not be specified, and therefore the default style was appropriate, but in cases where a style IS specified, then of course use that fontsize ... and every other character and paragraph property. HOWEVER, I only added the properties used in vml import for now, and I skipped asian/complex fontnames since VML only handles CharHeight, and not CharHeightAsian/Complex. -note: this does not affect direct formatting - it just sets default value at the shape level, not at the paragraph level. So far I have only looked at DOCX:VML - which satisfies the unit tests. There are other codepaths that lead to PushShapeContext though, and this should be easy to expand to other import situations. I've tried lots of asserts to find unit tests that should be modified, and so far they all seemed to point to VML - although round-tripping doesn't use VML and still requires at minimum the CharHeight property to be overridden, so limiting non-VML to that to maintain backward compatibility, and reduce regression footprint. Since we have to emulate here (since paragraph styles are not supported on Draw text), a perfect solution cannot possibly be found - specifically in cases where multiple paragraphs exist in one shape with different styles applied, or where some pararaphs apply a paragraph property and others do not. Compromise 1: For ambiguous paragraph styles, fallback to the default paragraph style. Rationale: Normally, most styles inherit from default and only change a couple of properties. So MOST of the properties will match the normal style. The chances that the default style will be correct are more likely than that some other random default would be. -note: no existing unit tests were ambiguous Compromise 2: Ideally, each paragraph could report whether it had DIRECT formatting, and the paragraphs could be walked through instead of the shapes. But I don't think that is reasonably possible in this SyncProperties situation. At first I had a grabbag framework setup that monitored when a paragraph property was set, and then skipped applying that property. But I later noticed that the PropertyState for paragraph properties actually did seem to reflect that - which is a better solution if it works properly. Regression potential: -for VML: should be limited to non-charheight properties where the default style sets some weird default, and an ambiguous style sets it back to the program default. Prior to this patch, the default style value wouldn't apply. On the flip side (and more likely scenario), non-ambiguous cases will use the correct value and look more like MSWord, as seen in many existing unit tests that now use corrected fonts. -for non-VML: should be none since I limit it to only CharHeight which was previously emulated by changing the program default. Change-Id: I8f1fb7ed01f990dbf998ebe04064c2645a68e1aa Reviewed-on: https://gerrit.libreoffice.org/81365 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-22log exceptions when parsingNoel Grandin1-20/+8
to make debugging easier Change-Id: Ia19384a925a2bb437fa5d961e6c3d44eebe0c6b6 Reviewed-on: https://gerrit.libreoffice.org/83345 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-21Revert "tdf#127579 DOCX export: fix losing color of ... ODT hyperlinks"Caolán McNamara3-14/+1
cause ~200 asserts of https://dev-builds.libreoffice.org/crashtest/299a13e8f7307b38ac10ad351273e2559e21ab16/backtraces This reverts commit 1d81d52b5da45f26e9d3adeb3b279eb9a488b94f. Change-Id: I8d00443f2fc8c71d6ef7baed5db0072847867ce1 Reviewed-on: https://gerrit.libreoffice.org/83406 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-21tdf#125300 extend AddParaSpacingToTableCells with line spacingLászló Németh6-6/+51
Now default compatibility mode AddParaSpacingToTableCells uses not only paragraph bottom margin, but also proportional line spacing before bottom cell border, as in MSO. Note: disable testForcepoint76, because it fails again with its fixed layout. Change-Id: I52f6204a5efc63aac4aa332a1563ada0cbeb9618 Reviewed-on: https://gerrit.libreoffice.org/83236 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-21tdf#118263 Take over doc print options for new printerMichael Weghorn1-0/+9
Take over the current document-specific print settings for a newly created printer in 'sw::DocumentDeviceManager::Create_Printer_'. This makes sure that the options of an 'SfxPrinter*' retrieved by calling 'DocumentDeviceManager::getPrinter(true)' are in line with the 'SwPrintData' currently set. This among other fixes the issue described in tdf#118263, comment 7, i.e. the options shown in "File" -> "Printer Settings" -> "Options" were not properly initialized when the config option for loading user-specific settings with the document was disabled. (All checkboxes were unchecked in the UI in this case instead of showing the default values.) What happens is that when importing the document, 'bPrinterIndependentLayout' in 'SwXMLImport::SetConfigurationSettings' is 'false', so that this block is entered there: if( ! bPrinterIndependentLayout ) { xProps->setPropertyValue( "PrinterIndependentLayout", Any(sal_Int16(document::PrinterIndependentLayout::DISABLED)) ); } resulting in the following call stack where the printer is created and set: #0 sw::DocumentDeviceManager::setPrinter(SfxPrinter*, bool, bool) #1 sw::DocumentDeviceManager::CreatePrinter_() const #2 sw::DocumentDeviceManager::getPrinter(bool) const #3 sw::DocumentDeviceManager::setReferenceDeviceType(bool, bool) #4 SwXDocumentSettings::_setSingleValue(comphelper::PropertyInfo const&, com::sun::star::uno::Any const&) #5 comphelper::MasterPropertySet::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) #6 SwXMLImport::SetConfigurationSettings(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) [...] Writer's default settings were not applied in this case. For the case where loading user-specific settings is enabled, no printer is set at this stage, but it's later set in the call to 'SwView::GetPrinter', in which case there is already an explicit call to 'SetAppPrintOptions' after the printer is created via 'DocumentDeviceManager::getPrinter(true)', so all was fine there earlier as well. (Apparently, the same issue could be reproduced with the config option for loading user-specific options enabled, but an ODT document that has "PrinterIndependentLayout" set to "disabled" in it's settings.xml.) Change-Id: I39fd300fb56b767e7103b65537b0eac1365e5fd7 Reviewed-on: https://gerrit.libreoffice.org/83394 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-11-21Drop SwAddPrinterItem::GetFaxMichael Weghorn2-4/+2
Base class's SwPrintData::GetFaxName does exactly the same thing, namely returning its 'm_sFaxName' member, so just use this one directly. Change-Id: Idd50eeeba94a1b1a25c5475511a60730368884c7 Reviewed-on: https://gerrit.libreoffice.org/83393 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-11-21SwAddPrinterItem: Remove friend SwAddPrinterTabPageMichael Weghorn1-2/+0
SwAddPrinterTabPage doesn't access any private members, so doesn't have to be a friend. Change-Id: I82918af61e7b1568127002e70da8c767aec7f03f Reviewed-on: https://gerrit.libreoffice.org/83392 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-11-21sw: check fieldmark overlap in SwpHints::TryInsertNesting()Michael Stahl3-13/+56
This is a follow-up to bd2ada701aad2c4e85d03cd8db68eaeae081d91c, which added the check for nesting hints in MarkManager::makeMark(). Change-Id: Ife847a677514fb1aeb28dc8d6254caea365b754d Reviewed-on: https://gerrit.libreoffice.org/83388 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-11-21uitest for bug tdf#126340Zdeněk Crhonek2-0/+39
Change-Id: I55972388b1f15dc86d309c5ffe998b44596b1cf2 Reviewed-on: https://gerrit.libreoffice.org/83351 Tested-by: Jenkins Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
2019-11-21Fix typoAndrea Gelmini1-1/+1
Change-Id: I041dfdaac4903d1bb0bb9ee70a2e5e705af3aafb Reviewed-on: https://gerrit.libreoffice.org/83398 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-21tdf#121658 Roundtrip w:doNotHyphenateCaps via InteropGrabBagSamuel Mehrbrodt3-0/+15
Change-Id: I8a7efffb2866e46e978d09ca9fb5c9dec231e132 Reviewed-on: https://gerrit.libreoffice.org/83384 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-11-21tdf#84929 sw UI: stay at footer when showing controlJustin Luth1-1/+8
Scenario: a new document where the first thing the user wants to do is create a footer. Scroll down to the bottom of the page (this does mean that you can't see the top of the page, right? None of my screens show an entire page by default anyway...) and click in the footer area. The screen jumps back to the top of the page and the user needs to scroll to the bottom again in order to enable the footer. So, in the very specific case of the control being turned on (because I don't care about a jump if the control is being turned off) don't process a return to the cursor position. Regression potential: The only use case I can think of is someone trying to drag a section by starting too low on the page. The early return will quickly cancel any kind of drag attempt. Basically if the user clicks in the footer area without intending to get the separator bar, it might act differently than what previously happened. I don't really see this scenario as a problem. One additional limitation could be added to only apply this if it is dealing with the footer, since in the case of a header there would be no screen-jump. Change-Id: I11cd3089b85d8eb49063b902e6bf8bf2e1412aa7 Reviewed-on: https://gerrit.libreoffice.org/82701 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-11-21tdf#97926 Add UI test for infobarSamuel Mehrbrodt1-0/+60
Change-Id: I82fe7ae4e9a564af27d1f080c0bf27e5aab17bfd Reviewed-on: https://gerrit.libreoffice.org/83188 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-11-21writerfilter: these can be constMiklos Vajna1-1/+1
Change-Id: I21eadcd210aef38e7690da2492bf1dfe030427e4 Reviewed-on: https://gerrit.libreoffice.org/83356 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-21uitest for bug tdf#128431Zdeněk Crhonek1-0/+63
Change-Id: I390ac076136140f6aaa391212afeca49ebbd1dc3 Reviewed-on: https://gerrit.libreoffice.org/83355 Tested-by: Jenkins Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
2019-11-20tdf#128557 Add tooltips to styles listsJim Raykowski4-0/+20
Change-Id: Ia8f00cd882c1c8c239b95de8e917ff317a6485e8 Reviewed-on: https://gerrit.libreoffice.org/83152 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com>
2019-11-20loplugin:redundantfcast: Don't warn about cast from braced-init-listStephan Bergmann1-2/+4
...in non-deduced context. That means that the necessary cast in 84322944980f6e2f9d4a531de7a6803797156968 "Simplify sequence initialization" (cf. <https://gerrit.libreoffice.org/#/c/82974/4/>) no longer causes a false positive, and doesn't need to use comphelper::OUStringLiteralList. Change-Id: I788da61cc0be82d2166653760e527bb18e366c99 Reviewed-on: https://gerrit.libreoffice.org/83291 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-20Removed executable permission on fileAndrea Gelmini1-0/+0
Change-Id: I331f6edcd530d0d409986cf40ebc05b134dfbd1d Reviewed-on: https://gerrit.libreoffice.org/83314 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-20tdf#124399 DOCX import: don't apply inside borders to 1-cell tablesSzabolcs Toth2-0/+11
Extra cell borders appeared on the bottom, top, left or right of the 1-cell tables when only the "inside borders" option was selected. The extra borders were the ones that would normally have appeared as inside borders if there were more than one cells in the table. Change-Id: I05d5f2a5a0168989f220d20a95b6dacf5152f9f7 Reviewed-on: https://gerrit.libreoffice.org/82675 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-20sw: revert change in expanding hints in SwXText::insertTextContent()Michael Stahl3-5/+106
The SwXText implementation for inserting text works like this: * XTextPortionAppend methods appendTextPortion()/insertTextPortion() get the text properties passed as a parameter, and they should apply only those properties to the inserted text, not expand any existing formatting hints at the insert position. * XSimpleText method insertString() does expand existing formatting at the insert position, just like editing in the UI does For inserting XTextContent: * XTextContentAppend methods appendTextContent()/insertTextContentWithProperties() with properties parameter, similar to XTextPortionAppend * XTextContent::insertTextContent(), without properties So arguably, by analogy to inserting text, the methods that take properties should not expand hints, and the insertTextContent() should follow the insertString and expand hints. Commit 18cbb8fe699131a234355e1d00fa917fede6ac46 is an important bugfix for writerfilter import, but the problem is, it added the DontExpandFormat() call to insertTextContent(), whereas the regression it was fixing (from commit 232ad2f2588beff50cb5c1f3b689c581ba317583) was that the call was removed from insertTextContentWithProperties(). So restore the state before 232ad2f2588beff50cb5c1f3b689c581ba317583. Turns out that SwUiWriterTest2::testTdf126206 was checking how a bookmark-start is formatted instead of how the text is formatted. Change-Id: If524409f88a1a36aa062b6e132996d3f9c1bb571 Reviewed-on: https://gerrit.libreoffice.org/83223 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-11-20loplugin:unusedmethodsNoel Grandin4-8/+0
Remove a filtering step in the python script that was hiding some results Change-Id: Id94268f150902405ab197c077f18aaedf98845fc Reviewed-on: https://gerrit.libreoffice.org/83256 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-20Use initializer list for unordered_set hereMichael Weghorn1-33/+34
Change-Id: I9099308834d7bf463bd92c07edc86b8e0aa1fe84 Reviewed-on: https://gerrit.libreoffice.org/82785 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-11-20Load "PrintTextPlaceholder" and "PrintHiddenText" based on configMichael Weghorn1-0/+2
While looking at tdf#118263, I realized that the "PrintTextPlaceholder" and "PrintHiddenText" attributes are unconditionally taken from the settings.xml when opening a document. All of the other options related to what content to print in "File" -> "Printer Settings" -> "Options" are (not) taken from the document based on whether the "Load user-specific settings with the document" option is enabled or not (in "Tools" -> "Options" -> "Load/Save" -> "General"). I didn't find a reason why those two should be handled differently, so also add them to the list of options not to load from the document if the above option is disabled. Change-Id: Id7e4810c10f4809650eab1f20a2caaf6881bf23d Reviewed-on: https://gerrit.libreoffice.org/82784 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-11-20Comment some code which resembles a wrong copypaste (sw/portxt)Julien Nabet1-0/+4
Thank you Miklos and Michael S! Change-Id: Ia24e2b9d39d919c26be3c7a5c38f9de875aad2e5 Reviewed-on: https://gerrit.libreoffice.org/83228 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-19Fix typoAndrea Gelmini1-1/+1
Change-Id: Ib5a16d8b5030e1974e5493b50caf7268c5c61191 Reviewed-on: https://gerrit.libreoffice.org/83242 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-19Fix typoAndrea Gelmini1-1/+1
Change-Id: I7068288ae990c9909000e9b088c03f3608694f6a Reviewed-on: https://gerrit.libreoffice.org/83241 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-19ofz#18554 sw: fix Null-dereference due to overlapping fieldmarksMichael Stahl5-13/+40
The problem is that the WW8 import wants to set a fieldmark on a range that contains only the CH_TXT_ATR_FIELDEND of another fieldmark: (rr) p io_pDoc->GetNodes()[12]->m_Text.copy(33,10) $30 = "\bÿÿÿ\001ÿÿÿ\001 " MarkManager::makeMark() must check that a new fieldmark never overlaps existing fieldmarks or meta-fields. While at it, it looks like the test in DocumentContentOperationsManager::DelFullPara() can't necessarily use the passed rPam, because it obviously deletes entire nodes, but at least SwRangeRedline::DelCopyOfSection() doesn't even set nContent on rPam. Also, the check in makeMark() triggers an assert in CppunitTest_sw_uiwriter testTextFormFieldInsertion because SwHistoryTextFieldmark::SetInDoc() was neglecting to subtract 1 from the end position for the CH_TXT_ATR_FIELDEND. Change-Id: I46c1955dd8dd422a41dcbb9bc68dbe09075b4922 Reviewed-on: https://gerrit.libreoffice.org/83000 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-19tdf#128889: don't write "page break after" into w:pPrMike Kaganski11-17/+63
This produced invalid OOXML, which Word considers as "page before", and LibreOffice ignores when re-importing. Make sure to write it as *trailing* w:r with w:br, as Word also does when imports ODT with this atribute, and saves as DOCX. Change-Id: Ifc4f45d65d4455ecb5cd62aed1ef6a03375c8aa4 Reviewed-on: https://gerrit.libreoffice.org/83232 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-11-19tdf#121186: sync itemset and supportsFullDrawingLayerFillAttributeSetMike Kaganski2-0/+6
In the bugdoc, there are three separate section styles, first of which (Sect1) has fo:background-color attribute set to #ffffff, others with no background-related attributes. The sections using the styles are nested, the outermost one using the style Sect1 with background color. When the XML is read, SwXTextSection::attach is called, which fills an item set with values stored in an SwTextSectionProperties_Impl struct, SvxBrushItem with color value of 0x00ffffff among them. The resulting set contains the SvxBrushItem item (WhichId = RES_BACKGROUND = 105). No XATTR_FILL_FIRST .. XATTR_FILL_LAST are put into the set. When later the Edit Sections dialog is opened, SectRepr objects are constructed for each section, and the brush is taken from section's format using makeBackgroundBrushItem. It checks supportsFullDrawingLayerFillAttributeSet, and if yes, uses getSvxBrushItemFromSourceSet to fill in the SvxBrushItem; the latter only considers XATTR_FILL_FIRST .. XATTR_FILL_LAST in the passed set. For the SwSectionFormat, supportsFullDrawingLayerFillAttributeSet inherited from SwFrameFormat returns true, which means that existing RES_BACKGROUND item is ignored, and default transparent color is returned. Fix by returning false from supportsFullDrawingLayerFillAttributeSet for SwSectionFormat. This makes nested sections' properties and behaviour match what was in older versions (4.0), where all three nested sections took white fill; and only setting innermost section's fill to none made it transparent (show document's background). Change-Id: Id0b4fce221cfa9c54097e69a3acfdf018a1043b5 Reviewed-on: https://gerrit.libreoffice.org/83016 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-11-19tdf#128608 ww8import: COL_AUTO == NO FILL, not solidJustin Luth3-13/+14
This fixes problems in the patches for tdf#116071. Tables have nothing to do with this bug. It just is the most common place to have a background colour, and then to have direct formatting that reverts back to COL_AUTO. I created a unit test using the page background (black), default style paragraph background (blue), and direct formatting COL_AUTO. COL_AUTO was turned into WHITE if the fillstyle was set to SOLID. Change-Id: I8197c040cec5adbdf16f379a88fab5e534ac0c6e Reviewed-on: https://gerrit.libreoffice.org/82412 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-11-19sw: fix invalid downcast of SwDrawFrameFormat in DelContentIndex()Michael Stahl4-12/+16
failure in UITest_writer_tests6: sw/source/core/undo/undobj.cxx:1021:47: runtime error: downcast of address 0x61300019d3c0 which does not point to an object of type 'SwFlyFrameFormat' 0x61300019d3c0:m note: object is of type 'SwDrawFrameFormat' a2 01 80 19 50 ac d1 9e 14 7f 00 00 00 af 19 00 30 61 00 00 e8 4f 0b 00 b0 61 00 00 40 dd 40 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'SwDrawFrameFormat' in SwUndoSaveContent::DelContentIndex(SwPosition const&, SwPosition const&, DelContentType) at sw/source/core/undo/undobj.cxx:1021:47 (instdir/program/../program/libswlo.so +0xf8e5833) Also lose the ridiculous overloading across derived classes. Change-Id: I19439d0d511c5f8c36b00d8dd02c31f802a44e00 Reviewed-on: https://gerrit.libreoffice.org/83175 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>