Age | Commit message (Collapse) | Author |
|
Reverts:
commit e71d05eaa9a8c9e628b256f3e889b85ac11ed474
Author: Caolán McNamara <caolanm@redhat.com>
Date: Fri Apr 27 15:42:26 2018 +0100
ofz#8038 defer subdocument redlining to end of parse like main document
Change-Id: Ie8d7a98c7927dcba53228ebcd991d715d8faabe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120563
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit b5870d727685ec10447e8ae446ada895250fec2e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120580
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I1987d39ea8ff195b397b0ee3fb0e45f9bfbfb572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117428
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This really confused me because it lead me to think
that this was something done for MS compatibility.
Well, that is only true in an off-handed way.
LibreOffice itself was changed to work similarly
to MS Word. So there is nothing special about how DOC
or DOCX/RTF are handled.
Since the compat settings are not saved or loaded
into MS Formats (i.e. it just takes the default value),
and since on an ODT save it also will just save
with the proper default value, there is no need
to specify "TabOverflow = true" in non-ODT import filters.
Only ooxmlexport16 has a unit test that reacts if
tabOverflow is false. That one is mine and it indicates
that the document would be better if tabOverflow was off,
so there are no examples of how tabOverflow improves a doc.
Change-Id: I97c25154108bc1ca0fcd3dfcff66fea0ea2bca7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116741
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
... SwHTMLNumRuleInfo
See tdf#94879 for motivation.
Change-Id: Ie091511f7b2fff3949295c310045631676879655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116421
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I674ef2bccaa56d1435b821e3e161f7c47340202f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116380
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... SwFltRedline
See tdf#94879 for motivation.
Change-Id: Ib70ed34b46f68650fbb3f1fa01cb2232a1909fa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116080
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
o3tl::narrowing() is a better way to handle this, as that way the
integer conversion is still implicit, which allows detecting integer
truncation at runtime (with suitable compiler flags).
Change-Id: I499abda3be6943e8c111c56df390e72939586221
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115948
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
WW8ListManager::nMaxLevel is a valid value meaning "Body Text".
If a valid setting is provided during initialization,
you can't tell if the property set contained the setting
(or at least not so easily).
The other related items (LFOPosition and mnWW8OutlineLevel)
both use out-of-range initializers, so it just makes
sense to do the same here.
This will be especially important to see whether
inheritance should come into play.
This should effectively be a Non-Functional-Change.
Change-Id: I05a2013e72c84653a16d61652fd8f23d3f441521
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114399
Tested-by: Jenkins
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Prior to this, if a Chapter Numbering style was assigned
as the paragraph style, any direct numbering would have
been skipped.
In this unit test, DOC defines WW8Num2 as the
numbering style for the Heading styles.
LO copies this to its special "Outline" style.
So any direct formatting with WW8Num2 must be ignored.
However, any other numbering rules should be allowed,
and that is what this patch does.
Make sure that WW8Num2 can also be applied outside of
the Heading styles. (Unfortunately, the numbering
is probably broken since these are now considered
to be two different lists - unless someone has
connected them in the background some way.)
Change-Id: If29c8bbd096acc0edd6f1fe32cedc054f16460d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114298
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ifbf762194836a3d05157e98943e65ef8aa2149c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113425
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This reverts commit 4f35958c64d5e63c30e67434936c3a0352f57698.
(which was an attempt at groundwork at fixing ofz#31538)
because ooo46246-1.doc fails to load in crashtesting
Change-Id: I334fc4ff1d1a934d92fe69eae63206c0a480e55e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112359
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib9f4665a9b77e0d90070060f635466a046058431
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112266
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
because they both attempt the same thing
Change-Id: Ica0201fc114dd6251f05aa94c685258e322f7314
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111749
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
well, at least not at the beginning of the document.
This is a .DOC followup to the 7.1 .DOCX patch
in commit 8787a45f9cbb5dce61b20817ef0e549b5a227a95.
The problem with specifying is that it becomes a property
of the paragraph - and so if the paragraph is copied or moved,
the page break comes along with it and the user has to remove
the unnecessary page break wherever it lands.
Since the default will be applied anyway,
there is no value in specifying it.
In DOC, it appears that the first page is ALWAYS set
to the default page. I tried to create a title page/first page
page style, but it always round-tripped as default page.
That makes it easier, with only specified page number exception.
Change-Id: Ie2e5ec42331d66f1883fc7b96fcefceb6d32c73d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111240
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I56f2f5aa4d9105e93f28701b8352d1fb97829ead
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111215
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
But leave the fRTLGutter case alone for now, I can't find the Word UI
for that.
Change-Id: I1d97e85308aa13892f50c0fcd3680cec514ef566
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110471
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I7cc5e98fe967da00228c1540ac28a0074e6d5e4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110344
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I190256bc9502d742ce182c0bef0698847fa77070
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108673
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I66d016a22158f9f9ef68a80842e95e45516f0b4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108228
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
move FrameDeleteWatch for reuse in the doc filter
Change-Id: I6e53549a837968cb738b5188e8670dd3e38a9c0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105264
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
grepping for stuff in template params this time
Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I44be72b3a9b14823ec37a3c799cffb4fb4d6e1de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and similar
Change-Id: I046be0e41b79f2fd51ebec0da20fccb17d947732
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103823
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ifed7220c6acf7049b2985f1911a806b37a54d794
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103646
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
commit 3cccdabf19a99fd3f657985c1822436d7679df2b "extend
AddParaSpacingToTableCells with line spacing" changed how the
ADD_PARA_SPACING_TO_TABLE_CELLS compat flag works, to improve interop
with Word.
This commit splits out the change as a separate new compat flag
ADD_PARA_LINE_SPACING_TO_TABLE_CELLS ("AddParaLineSpacingToTableCells"),
to preserve compatibility with ODT documents that were produced
by LO < 6.4 (via SwXMLImport::SetConfigurationSettings()).
New documents and WW8/RTF/DOCX import have both flags enabled.
The combination false/true is invalid, and treated as equivalent
to false/false.
Change-Id: Ida20df8fe4a8192a714f91da95345f9726fd7d98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103317
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Ie0ecacb69b1e99ca52abd9038baa176be8383661
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102404
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...and in turn add OUString::operator = and OUString::operator +=
overloads that take a std::u16string_view. Without making the ctors explicit,
the operator overloads would have caused ambiguities when called with raw
sal_Unicode pointers/non-const arrays, as those can convert to both OUString and
to std::u16string_view.
But the std::u16string_view operator overloads will generally be useful when
changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which
point many existing uses of OUStringLiteral will be replaced with uses of
std::u16string_view.
Implementing this change turned up a need for an operator = overload for
OUStringNumber, which has thus been added. No such need turned up for a
corresponding operator += overload, but which can easily be added when the need
arises.
It also revealed that the operator == overloads between an OUString and a raw
sal_Unicode pointer/non-const array were implemented rather inefficiently,
creating a temporary OUString from the raw argument. Those have been improved.
Preceding commits have already taken care of many dubious or simply unnecessary
implicit uses of the now-explicit OUString ctors. This commit makes explicit
the few remaining reasonable uses. (And in some cases needed to change variable
initialization syntax from using parentheses to using curly braces, to avoid the
most vexing parse issue. And needed to explicitly add OUString ctors from
char16 const[2] string literal lvalues in a conditional expression in
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary
because MSVC apparently still insists on doing array-to-pointer decay there.)
All of this only affects LIBO_INTERNAL_ONLY.
Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...in preparation of further OUString improvements
Change-Id: I8e1aca3b91d2843e84755691f5f5461866c1e4e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102075
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...and fix the detected fallout.
That ctor only started to get used recently with
a1570b6052ae9c9349282027c9007b071589bce6 "Make the OUString
ConstCharArrayDetector::TypeUtf16 overloads are actually used", but it turns out
that that also gave rise to that ctor being picked in error. To better guard
against such erroneous uses, make that ctor assert that the given array does not
contain embedded NUL characters, see the new
sal/qa/rtl/strings/nonconstarray.cxx tests.
The one place where that assert would fire during `make check` is fixed now in
SwWW8ImplReader::ImportDopTypography.
That assert would also fire for tow OUStringLiteral-related tests in the
recently added test::oustring::StringLiterals::checkEmbeddedNul, so drop those
for how. They cna presumably be added back (with reversed logic values) when
OUStringLiteral is changed similarly to how OStringLiteral was changed in
4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a
consteval'ed, static-refcound rtl_String".
Change-Id: I6056244003a20f77ba0d953538d25edcbd562211
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102063
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
in which case pImpRec is deleted and pImpRecTmp is invalid
Change-Id: I2a273a436ebd88cb53e329bbcb4f171dda6ed840
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101248
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia296fc6e6c8f78edf533dedf52996560ae62d143
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99853
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9af7e2fa0a450ebe396c0f049831a20100dbdc9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99659
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
That information is already used in sw/source/filter/ww8/sprmids.hxx.
Just make it available for use by converting the sprms into templated
structs with relevant members.
Inspired by commit 56b04e40ab72b6333ce278ba2980650f5272025f.
This commit changes values for the following sprms:
sprmCPlain (0x2A33): len 0 => len 1
sprmTMerge (0x5624): len variable => len 2
sprmTSplit (0x5625): len variable => len 2
Change-Id: Icd65fc1ef488e7b2db60f13246c76f89176467ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98936
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Add layout compatibility option FRAME_AUTOWIDTH_WITH_MORE_PARA
to keep paragraph area width of AutoSize width frames with
more than one paragraph.
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: Iab8926b6219ac92ef1ab7488bdef1d3f2b47c396
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97425
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I4df8fefa7f875e0a25585c4fef22f077dcd0b83d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97318
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Add a layout compat option to keep the spacing below the last paragraph
in the header in doc/docx files
Change-Id: I259511183a8252e04d9951357dbdd4f4832523ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94577
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
limited this only fixing assignments inside "if" statements, since other
things are harder to change
Change-Id: If3188a3e3d5fcd94123211c97fee097ece5e2797
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95990
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3805d7a0f8f0e93463a2285a1ce52f6a5daba27d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95578
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iaf879d5ec52cd422634287d1fe69a4aafe13c4d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95188
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...where the get member function is defined on a std::__shared_ptr base class,
so loplugin:simplifypointertobool used to miss those until now. (While e.g.
using libc++ on macOS found those cases.)
366d08f2f6d4de922f6099c62bb81b49d89e0a68 "new loplugin:simplifypointertobool"
was mistaken in breaking isSmartPointerType(const clang::Type* t) out of
isSmartPointerType(const Expr* e); c874294ad9fb178df47c66875bfbdec466e39763 "Fix
detection of std::unique_ptr/shared_ptr in loplugin:redundantpointerops" had
introduced that indivisible two-step algorithm on purpose.
The amount of additional hits (on Linux) apparently asked for turning
loplugin:simplifypointertobool into a rewriting plugin. Which in turn showed
that the naive adivce to just "drop the get()" is not sufficient in places that
are not contextually converted to bool, as those places need to be wrapped in a
bool(...) functional cast now. If the expression was already wrapped in
parentheses, those could be reused as part of the functional cast, but
implementing that showed that such cases are not yet found at all by the
existing loplugin:simplifypointertobool. Lets leave that TODO for another
commit.
Besides the changes to compilerplugins/ itself, this change has been generated
fully automatically with the rewriting plugin on Linux.
Change-Id: I83107d6f634fc9ac232986f49044d7017df83e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94888
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
This adds read support for API-based MS-CRYPTO algos.
DRM encryption is implemented as a service and desrption
will be called if we found corresponding streams inside
binary OLE package.
Change-Id: Ie1a5b0417e1e7851b24d410c8f41dc85dd9210f7
Reviewed-on: https://gerrit.libreoffice.org/81600
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Tested-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84437
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Just like with forms, the password should not be
required to make changes when only enforcement of
track changes is specified. So just grabbag
the password and let the document open in read-write mode.
TODO for the overly zealous: actually enforce
file->properties->security->protect track changes,
and also export it. (This has been done for DOCX.)
Change-Id: Ib68ec5785aa0f5dbac507a3d50059a443f7ff42b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93551
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I58d91e75ef96beaab7ec34df519ae3a376dce976
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93201
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Ende -> End
Change-Id: I205600e263d2291faa97d967c9a8c7fc0baadb1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92029
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I6b28c6782f22190b7b22b11361c200d68d672aea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92347
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|