summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2019-12-04some std::set->o3tl::sorted_vectorNoel Grandin
which is much better cache-wise Change-Id: Iacec0df48f043bcdd761ed30c1b1513850a00152 Reviewed-on: https://gerrit.libreoffice.org/84311 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03PopFieldContext calls CloseFieldCommand itselfMike Kaganski
Change-Id: I4ac75d6e73f4d60ac532829a56c5d23501e6a531 Reviewed-on: https://gerrit.libreoffice.org/84318 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-12-03remove some useless comment linesNoel Grandin
which merely announce that the next declaration is a class Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc Reviewed-on: https://gerrit.libreoffice.org/84229 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-02revert obsolete writerfilter hacks for tdf#119054 and tdf#128752Justin Luth
These are obsoleted in LibreOffice 6.5 by tdf#118947's commit 6bced3c6a1bf8d4652dd6ba75e41b128ce1bfc5c Both of these hacks were backported to 6.4, but I have no intention of backporting my patch. Change-Id: Ie639b9d55d90d25b58e140fba443fce98f2d7ba1 Reviewed-on: https://gerrit.libreoffice.org/84125 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2019-12-01Introduce o3tl::optional as an alias for std::optionalStephan Bergmann
...with a boost::optional fallback for Xcode < 10 (as std::optional is only available starting with Xcode 10 according to <https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite all code to use o3tl::optional instead of boost::optional. One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus -Werror=maybe-uninitialized" should no longer be necessary (and whose check happened to no longer trigger for GCC 10 trunk, even though that compiler would still emit bogus -Wmaybe-uninitialized for uses of boost::optional under --enable-optimized, which made me ponder whether this switch from boost::optional to std::optional would be a useful thing to do; I keep that configure.ac check for now, though, and will only remove it in a follow up commit). Another longer-term benefit is that the code is now already in good shape for an eventual switch to std::optional (a switch we would have done anyway once we no longer need to support Xcode < 10). Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses boost::property_tree::ptree::get_child_optional returning boost::optional, so let it keep using boost::optional for now. After a number of preceding commits have paved the way for this change, this commit is completely mechanical, done with > git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g' (before committing include/o3tl/optional.hxx, and relying on some GNU features). It excludes some files where mention of boost::optional et al should apparently not be changed (and the sub-repo directory stubs). It turned out that all uses of boost::none across the code base were in combination with boost::optional, so had all to be rewritten as o3tl::nullopt. Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b Reviewed-on: https://gerrit.libreoffice.org/84128 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-30Rewrite uses of boost::optionalStephan Bergmann
...to only use functions that are also available for std::optional (in preparation for changing from boost::optional to std::optional): * uses of get are replaced with operator * or operator -> * uses of is_initialized are replaced with operator bool * uses of reset with an argument are replace with operator = (All of the replacements are also available for boost::optional "since forever", so this change should not break builds against old --with-system-boost. An alternative replacement for is_initialized would have been has_value, but that is only available since Boost 1.68.) Change-Id: I532687b6a5ee37dab28befb8e0eb05c22cbecf0f Reviewed-on: https://gerrit.libreoffice.org/84124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-29tdf#118947 writerfilter: remove obsolete tablestyle fontsize hackJustin Luth
LO 6.5 commit 6bced3c6a1bf8d4652dd6ba75e41b128ce1bfc5c obsoletes this old hack. The default paragraph style has (almost) nothing to do with table styles. *Any* specified (non-inherited) paragraph style property should override a table style, including the default paratyle. One exception is the default occurance of the not-yet-supported word/settings.xml compat option overrideTableStyleFontSizeAndJustification = false. The default case should cause the table-style font to override a size 11 or 12 default-paragraph-style font. So that is actually double-reason to remove this old hack which threw out the table-style size altogether. Change-Id: Id1687f32b8431b6fa8770b01c344e75e0ffb344f Reviewed-on: https://gerrit.libreoffice.org/84044 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2019-11-28NFC tdf#120412 cleanup: use DFLT_ESC_* moreJustin Luth
and all of the comment references to 14400% are no longer accurate, so they were removed. Change-Id: Ic958cc240e4898e914958fc32d09e2bb9478f197 Reviewed-on: https://gerrit.libreoffice.org/83845 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2019-11-27Related: tdf#128611 RTF import: handle vertical flip of line shapesMiklos Vajna
UI uses SdrEditView::MirrorMarkedObjVertical() to flip a line shape vertically, handle it similarly at import time as well. Also note that this flips in-place, while the naive '*= -1' for the height would have an incorrect vertical position. Change-Id: I42b7feb5f799b99337ddec734dcf98dd1d553755 Reviewed-on: https://gerrit.libreoffice.org/83929 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-27crashtesting: failure on import of tdf113230-1.docxCaolán McNamara
which is a favorite input document for crashes and assert apparently, this is the third time it has triggered a different problem this one is new since... commit 9fdf8c0a5cc036ea9bd1e11dd8f2c1a6e601fae2 Author: Mike Kaganski <mike.kaganski@collabora.com> Date: Sat Nov 16 16:34:25 2019 +0300 Also consider saved exceptions when terminating parse Change-Id: I394b650613e8a835fe8a9f216a48864bdbc5065b Reviewed-on: https://gerrit.libreoffice.org/83924 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-27tdf#76586 fix table width of auto-width nested tablesLászló Németh
when they have (sometimes incorrect) fixed cell widths. Change-Id: I98bf37bfce72b84eed14e354520e4741ae2ddada Reviewed-on: https://gerrit.libreoffice.org/83787 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-26Remove some unused includesMiklos Vajna
Change-Id: Ia24c806f227570f7a000e85eece75c9d02d25a4b Reviewed-on: https://gerrit.libreoffice.org/83782 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-26nipick followup: add TOOLS_WARN_EXCEPTION to empty try-catchJustin Luth
followup for tdf#128153 docx/VML: apply style properties to shape text Change-Id: I2e1a057cfacb610d294ed106879af89482637a3a Reviewed-on: https://gerrit.libreoffice.org/83721 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-25Turn on clang-format for these filesMiklos Vajna
I (tried to) keep these files consistent locally with astyle in the past, switching to clang-format makes sure that the recent problem with introducing inconsistencies with automatic loplugin rewrites doesn't happen again. Change-Id: I86def0d13a1d16f8cedb7cf9927a48ce14c2b3bf Reviewed-on: https://gerrit.libreoffice.org/83690 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-11-22crashtesting: failure on import of tdf10306-1.docxCaolán McNamara
downgrade to warning instead of assert as per https://lists.freedesktop.org/archives/libreoffice/2019-November/083836.html Change-Id: If561930ca9733899cf0f4e3a6d8bb6609c94fc1d Reviewed-on: https://gerrit.libreoffice.org/83485 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 Bergmann
...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 Luth
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-21tdf#121658 Roundtrip w:doNotHyphenateCaps via InteropGrabBagSamuel Mehrbrodt
Change-Id: I8a7efffb2866e46e978d09ca9fb5c9dec231e132 Reviewed-on: https://gerrit.libreoffice.org/83384 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-11-21writerfilter: these can be constMiklos Vajna
Change-Id: I21eadcd210aef38e7690da2492bf1dfe030427e4 Reviewed-on: https://gerrit.libreoffice.org/83356 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-20tdf#124399 DOCX import: don't apply inside borders to 1-cell tablesSzabolcs Toth
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-19tdf#119054 DOCX: fix not table style based bottom marginLászló Németh
in table cells, ie. using paragraph styles with bottom margin setting or direct paragraph formatting of bottom margin. Both of them overwrite the table style based bottom margin. Change-Id: I527b16c24fe47df8412291089ff86fadd3f9430b Reviewed-on: https://gerrit.libreoffice.org/82800 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-16Also consider saved exceptions when terminating parseMike Kaganski
As with previous commit 18ae77a065cb8ae6940d4067f6ab7e99a3f74047, this will start showing parse errors on invalid files which previously just opened without warnings, silently losing the invalid stream part. Any bug bisected to this commit is not a regression from this commit! The real problem was already before, and was just disclosed by this (which is the actual goal). Also simplify unit test data for tdf#128820, which will now be enough after the change. A unit test (testN779627) revealed unexpected throws when parsing; this was fixed. Change-Id: I5a21b9001874ec6e3b8273c10043ef930bf1cc82 Reviewed-on: https://gerrit.libreoffice.org/82981 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-11-15DOCX: clean-up paragraph bottom handling of table styleLászló Németh
Revert of commit 17e904ed66c3caf87e658b9d3a18d7b13f4a0b52 ("bnc#816593 DOCX filter: import paragraph spacing from table style), keeping only the working unit test. Change-Id: I735744aadb071ef2f0d939cb637d83cfc5716fe4 Reviewed-on: https://gerrit.libreoffice.org/82776 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-15tdf#128752 DOCX: fix partial direct paragraph spacing in tablesLászló Németh
When direct formatting of a table paragraph set only top margin, but not the bottom margin, also there was no paragraph style setting for the bottom margin, the paragraph was imported using docDefault bottom spacing instead of the table style bottom spacing. Change-Id: Ib7f5f80dd2485a0fd4ab8e0645b7d730a7ec3c5c Reviewed-on: https://gerrit.libreoffice.org/82771 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-13tdf#95374 DOCX import: reset left indentation at disabled numberingLászló Németh
Paragraphs with disabled numbering using non-existent numId=0 haven't got inherited left indentation in MSO. Keeping them resulted unnecessary indentation, moreover, missing (non-visible) text in narrow table cells. Change-Id: I46003031d36f578b0b260dea74d7d45e75905261 Reviewed-on: https://gerrit.libreoffice.org/82509 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-13tdf#127925 DOCX export: fix visited hyperlink styleTünde Tóth
Custom visited hyperlink style reset to default in Word. Change-Id: I6a36c900788bb17d4f31c60048cf65960490a46b Reviewed-on: https://gerrit.libreoffice.org/80043 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-12use std::move when popping stuff off stacksNoel Grandin
Change-Id: I6ba0ee8afee1a9579045643cd0118cf19599d5b9 Reviewed-on: https://gerrit.libreoffice.org/82497 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-11tdf#128428 RTF: fix for different product versionsLászló Németh
at switching off longer space sequence mode. Change-Id: I87c265ad0ff5f7b44c92b1abebeb31f68749a1e7 Reviewed-on: https://gerrit.libreoffice.org/82434 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-11tdf#128428 RTF: clean-up for longer space sequence modeLászló Németh
Fix regressions from commit 24b04db5a63b57a74e58a7616091437ad68548ac (tdf#123703 RTF import: fix length of space character sequence). It seems, longer space sequence is an obsolete RTF-only feature, eg. new RTF documents created in MSO don't use it, but old RTF documents still keep their layout (only in RTF). - Only old-style (without \stshfdbch) or compatible (\stshfdbch31505) RTF documents get longer space sequences using a one-time conversion; - because Writer always exports old-style RTF documents, to avoid of enlargement of space sequences of new-style RTF documents later, RTF import doesn't modify the RTF documents saved in Writer (checking \generator); - text in monospaced font "Courier New" doesn't get longer space sequence (despite its \prq2 (not monospaced) font setting). Change-Id: I308ab06db57a2db5deec1d4c4573da3317cad8e9 Reviewed-on: https://gerrit.libreoffice.org/82145 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-11tdf#128460 import SwInputField from DOCX FILLINJan-Marek Glogowski
Actually the whole FILLIN handling is not that correct, because the value can actually be formatted in any way in Word, as it's just defined as a range of runs with formating, while Writer just applies the character formatitng to the whole field. But this at least allows for a round trip of the exported Writer type input field after commit 62aaaad156ef ("tdf#125103 Writer: input fields will be exported to docx") changed this. Change-Id: I6389b4a2ff9d2b62e1e4a00f1c1e112c199377b5 Regression-from: 62aaaad156ef0daccd2680161ef8b9b99d8a7bc0 Reviewed-on: https://gerrit.libreoffice.org/81686 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-11-11tdf#124986: docx: remove trailing quotation marks and spaces from set fieldsbrinzing
Change-Id: I6390344b72b0148cff8e0ed5150d7abfc9490a2a Reviewed-on: https://gerrit.libreoffice.org/81892 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-09tdf124367 DOCX import: fix rounding error in table cell widthsBakos Attila
Follow-up of commit 29cbbad64088354425c606f9eb6c267bdf7731dc (DOCX import: fix rounding error in table cell widths), its revert in commit e502463fa9a601963aa9f5a8783eb1318de36c13 (tdf#123104 DOCX import: fix lack of vertical merge due to rounding) and commit 44e44239de35c1548809c96e13bfa9d64c7ca441 (tdf#120315 DOCX import: fix cells merged vertically). Change-Id: Id85e8fd25dba26af77fe2fd3024db2ae834b5052 Reviewed-on: https://gerrit.libreoffice.org/82072 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins
2019-11-08tdf#128504 save DOCX as ODT: don't color not highlighted hyperlinksTünde Tóth
During DOCX import, not highlighted hyperlinks, ie. without hyperlink character styles, set the Visited/Unvisited character style text attributes to "Default Style" to avoid saving them with the default highlighted hyperlink character styles in ODT. Regression from the commit 576611895e51186d38ddefa10ed8d66075d9de37 "tdf#127741 DOCX import: format hyperlink with Default character style". Change-Id: I5ffbb107e6704b285bc3d1546e08a324c386a0ab Reviewed-on: https://gerrit.libreoffice.org/82205 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-07loplugin:unusedmethodsNoel Grandin
Change-Id: I65354c7476dfaede1a607441d7c1b0c7ad038df4 Reviewed-on: https://gerrit.libreoffice.org/82186 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-06crashtesting: null deref on import of lp482242-3.rtfCaolán McNamara
since... commit a991ad93dcd6807d0eacd11a50c2ae43a2cfb882 Date: Tue Oct 22 12:24:43 2019 +0200 tdf#121441 improve DOCX footnote import Change-Id: I0c6b83bd1ff61b9fa3621896d59f126384530270 Reviewed-on: https://gerrit.libreoffice.org/82045 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-06tdf#99602 writerfilter: import subscript into character styleJustin Luth
and superscripts (aka escapements, but who knows that term). This isn't perfect, but I just fixed about 4 subscript bugs under much simpler conditions. Doing this completely compatibly with MS Word would be several magnitudes of order more difficult, since WORD works in absolute amounts (much easier to deal with) and LO works in relative percentages. Normally, the default auto settings make subscripts look the best anyway, so this should be a pretty good solution. Change-Id: Iefdc8ad55988d96ddbbba4701795a4f7a61b1521 Reviewed-on: https://gerrit.libreoffice.org/80219 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-06tdf#121661 Roundtrip w:hyphenationZone via InteropGrabBagSamuel Mehrbrodt
Change-Id: I097afb54ff31bd1c878231b51eac5af9f27d35e9 Reviewed-on: https://gerrit.libreoffice.org/81880 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-11-06loplugin:indentation find broken if statementsNoel Grandin
so I don't read the "then" block as being a sequential statements Change-Id: Ib2004acd3518bd4ebd2246f02a26c2c0a8bbab4c Reviewed-on: https://gerrit.libreoffice.org/82069 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-04tdf#120315 DOCX import: fix cells merged verticallyBakos Attila
Due to rounding mistake cells weren't merged vertically, when their horizontal positions are different a little bit. Change-Id: I10623719a3759b35fcd04b154590b8ac6ec3ac45 Reviewed-on: https://gerrit.libreoffice.org/81604 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-03loplugin:stringaddNoel Grandin
tweak the plugin to be more permissive, then validate by hand afterwards Change-Id: I40c5c911fe6ff7e45baaca372abf7dac211d9654 Reviewed-on: https://gerrit.libreoffice.org/81942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-02New loplugin:conditionalstringStephan Bergmann
Change-Id: I2eab990c15f845b44a3b598571aca361dadf9ff3 Reviewed-on: https://gerrit.libreoffice.org/81946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-31tdf#125038 DOCX import: better support for linebreaks in IF fieldsMiklos Vajna
IF fields can't contain linebreaks, so instead of just calling finishParagraph() and hoping it does something sane, explicitly handle them: remember the properties and perform the call only once the field is closed. Change-Id: I676aa2c83f12cb600829177a0eb25558822b1d94 Reviewed-on: https://gerrit.libreoffice.org/81847 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-10-31Fix typosAndrea Gelmini
Change-Id: I917e4cdac3690dd5134e4994a0ee4106ae88ae36 Reviewed-on: https://gerrit.libreoffice.org/81860 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-10-31Resolves: rhbz#1766990 starmath might not be availableCaolán McNamara
Change-Id: If2e02d8da85a2af576d9563c455487ac3463c935 Reviewed-on: https://gerrit.libreoffice.org/81837 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-31tdf#125038 DOCX import: fix lost MERGEFIELD result inside an IF fieldMiklos Vajna
The problem here was that the IF field result didn't have a plain text string, rather it had a MERGEFIELD in it. Writer's conditional text field expects a plain text string, so just use the result of the MERGEFIELD for an IF parent. Do this in a generic way, it's likely that other parent-child field combinations want to do the same in the future. With this, all lost strings are fixed from the original bugdoc + all unexpected content is hidden in Writer as well. Change-Id: Ic5c03b1df2f08a2cd851647b625e0c303cc5d6c5 Reviewed-on: https://gerrit.libreoffice.org/81825 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-10-31Fix StringAdd::isCompileTimeConstantStephan Bergmann
...to find StringLiteral on the RHS of +=. Which revealed that the VisitCompoundStmt/checkForCompoundAssign logic needed to be fixed, too, so that s += side_effect(); s += "literal"; s += side_effect(); only gets combined to s += side_effect() + "literal"; s += side_effect(); and not all the way to s += side_effect() + "literal" + side_effect(); Change-Id: I432e3458b933a7d0ad6141c747b675cc8b0f0ba4 Reviewed-on: https://gerrit.libreoffice.org/81804 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-30Related: tdf#125038 DOCX import: fix unexpected linebreak inside IF conditionMiklos Vajna
Writer body text is expected to only contain the result of the field. So in case both the field command and the field result contains a linebreak, we need to make sure that linebreaks are ignored in the field command for field types where the Writer field implementation expects a single string. With this, the number of paragraphs in the bugdoc is now correct. Change-Id: I42f208d6943750ba2e8f88b52c373f6ca9cb2b71 Reviewed-on: https://gerrit.libreoffice.org/81786 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-10-30writerfilter: rtftok: filter control charactersMichael Stahl
... in RTFDocumentImpl::checkUnicode(); see ooo86460-1.xls [sic] for an example. There is another caller of text() in rtfdispatchdestination.cxx:311 but it turns out that buffered text was created by text() in the first place. This shouldn't be a problem for DOCX because XML 1.0 doesn't allow the bad control characters anyway so the sax parser should report an error in that case. Change-Id: Ice45e1c3c8c7db668a4cfb8364e42addea1777ce Reviewed-on: https://gerrit.libreoffice.org/81697 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de>
2019-10-29writerfilter: assert that start position is before end positionMichael Stahl
As seen in fdo34663-1.docx; should find more bugs hopefully. Change-Id: Id38fdebe3ab4f48af298e2ef76ad66051cee5bcf Reviewed-on: https://gerrit.libreoffice.org/81671 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-29writerfilter: need to always import form-fields with their ffDataMichael Stahl
The generic field import path ignores ffData, becuase it's a separate element and not part of the field command. Change-Id: Ie7c622aff01e4f1a63269b46aa7b06f4f18db8c4 Reviewed-on: https://gerrit.libreoffice.org/81670 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
generated by cgit (git 2.34.1) at 2024-08-08 19:54:35 +0000