Replace code added in 090c61eb93
with something that uses the already generated ESCHER property; this
lets a warning about the unhandled property disappear too.
Change-Id: Ieed83dd8e17e92eea9901124fce5e6da2a17196a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100332
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
This reverts commit 6f22e4e5f9.
<https://ci.libreoffice.org/job/gerrit_linux_gcc_release/66787/> failed with
> Test name: testTdf131420::Load_Verify_Reload_Verify
> equality assertion failed
> - Expected: 1
> - Actual : 0
> - In <file:///home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/tempdir/lu29117kacyqp.tmp>, XPath '/w:document/w:body/w:p[2]/w:pPr/w:pBdr[2]' number of nodes is incorrect
during CppunitTest_sw_ooxmlexport12 of
<https://gerrit.libreoffice.org/c/core/+/100328> "Test build"
...of <https://gerrit.libreoffice.org/c/core/+/99697/2>:
Aug 07 15:11:38 <sberg> does anybody else see CppunitTest_sw_ooxmlexport12
testTdf131420::Load_Verify_Reload_Verify consistently fail? It got added
right now with 6f22e4e5f9, which Jenkins had
seen build green a week ago, based back then on a parent from July 21, so
sounds likely that the tested code changed meanwhile
Change-Id: I1eb5caed08dc7be27fab5773dfb23a5c608d1c47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100229
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Changed code to not save 'useFirstPageNumber' and 'firstPageNumber'
if "First page number" is not checked.
It was needed because Excel does not care about 'useFirstPageNumber',
and blindly load 'firstPageNumber' even if that had an invalid value
(that could happen when useFirstPageNumber==false).
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: I69c9ed0fd4fdca1794d4bbc197713ac687eb4005
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100203
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
SwXTextDocument::GetRenderDoc already uncondionally dereferences
pDocShell so we can assume its non null
Change-Id: I25edd2415ff052b1bdaa6d6a6d1a252a12b14100
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100289
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
On saving a frame from Writer the anchor moves to the next
paragraph, moving the whole frame lower in the document.
Co-authored-by: Attila Szűcs (NISZ)
Change-Id: Ic47becb323282500871d825c12330b328f5059d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99673
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
... and also handle a document that starts with a nextColumn break
... and also handle a nextColumn with a different number of columns.
Starting in Word 2013's compatibilityMode=15, it appears
(based on testing, but no documentation found to prove it)
that the hard-to-create column-section-break is always
handled the same way as a page break.
It already was like this if it occurred when the previous
section did not have columns. Only when the previous section
had the same # of columns did it act as a regular column break.
In any case, LO never handled any of it well.
P.S. I never liked "lastContext" since it isn't clear
whether it means the very last something or something earlier.
So I changed it to PrevSection which is much nicer.
still to do: figure out how to just do a regular column
break in the previous section.
Change-Id: I3cef4a1ab185d25dfde90b85338706e8909b72dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99936
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
and that's for alt+mnenonic which has been removed
which has a knock on effect of removing some methods
that just call this no-op
Change-Id: Id71a57880c6335ee5a052de0da6cc2449489849f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100265
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
No idea if updated VS makes a difference, or some recent Skia update...
In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11:
In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h:13:
C:/lo/src/build/workdir/UnpackedTarball/skia\include/private/SkPathRef.h(113,41): error: implicit instantiation of undefined template
'std::tuple<SkPoint *, float *>'
std::tuple<SkPoint*, SkScalar*> growForVerbsInPath(const SkPathRef& path) {
^
C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here
class tuple;
^
In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11:
In file included from C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h:13:
C:/lo/src/build/workdir/UnpackedTarball/skia\include/private/SkPathRef.h(114,30): error: implicit instantiation of undefined template
'std::tuple<SkPoint *, float *>'
return fPathRef->growForVerbsInPath(path);
^
C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here
class tuple;
^
In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11:
C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1543,65): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const
SkPoint *, const float *>'
std::tuple<SkPathVerb, const SkPoint*, const SkScalar*> operator*() const {
^
C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here
class tuple;
^
In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11:
C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1550,20): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const
SkPoint *, const float *>'
return {verb, fPoints + backset, fWeights};
^
C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here
class tuple;
^
In file included from C:/lo/src/build/workdir/UnpackedTarball/skia/src/core/SkBitmapDevice.cpp:11:
C:/lo/src/build/workdir/UnpackedTarball/skia\include/core/SkPath.h(1625,68): error: implicit instantiation of undefined template 'std::tuple<SkPathVerb, const
SkPoint *, const float *>'
return (fIter != fEnd) ? static_cast<Verb>(std::get<0>(*fIter)) : kDone_Verb;
^
C:/PROGRA~2/MICROS~1/2019/COMMUN~1/VC/Tools/MSVC/1427~1.291/Include\utility(126,7): note: template is declared here
class tuple;
^
5 errors generated.
make[1]: *** [C:/lo/src/core/solenv/gbuild/LinkTarget.mk:351: C:/lo/src/build/workdir/GenCxxObject/UnpackedTarball/skia/src/core/SkBitmapDevice.o] Error 1
Change-Id: Ica85829cf61d86e486cf4b2a730f50e06e3fb337
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100271
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
