...rather than on the deprecated WeakAggImplHelper2.
It was found that that class was implementing queryInterface in a way that is
incompatible with the XAggregation protocol inherited via WeakAggImplHelper2.
It looks like no code actually made use of the XAggregation offered by this
class, so the easiest fix for this queryInterface implementation appears to
switch from WeakAggImplHelper2 to WeakImplHelper (thereby dropping XAggregation,
and thus rendering the existing queryInterface implementation OK).
Change-Id: Ia66e1d8f89740752d8ed69f0e17b75fa2c470f41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145893
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...rather than on the deprecated WeakAggImplHelper6.
The two classes SwXShape and SwXGroupShape, both deriving from
SwXShapeBaseClass, had been found to implement their respective queryInterface
in a way that is incompatible with the XAggregation protocol inherited via
WeakAggImplHelper6. It looks like no code actually made use of the XAggregation
offered by this class hierarchy, so the easiest fix for those queryInterface
implementations appears to switch from WeakAggImplHelper6 to WeakImplHelper
(thereby dropping XAggregation, and thus rendering the existing queryInterface
implementations OK).
Change-Id: I47dd177db7f3ddbd53482c3b4c194b6e7f15f69c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...rather than on the legacy OWeakAggObject.
It was found that e.g. Graphic, deriving from GraphicDescriptor, was
implementing queryInterface in a way that is incompatible with XAggregation
protocol inherited via OWeakAggObject. It looks like no code actually made use
of the XAggregation offered by this class hierarchy, so the easiest fix for that
queryInterface implementation appears to switch from OWeakAggObject to
OWeakObject.
Change-Id: I54514db32b731b9fa83831a1071da6f665fdf25e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145891
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This is the import side of commit
6ce374140f (sw XHTML export: use CSS
instead of <center> for tables, 2023-01-19), otherwise the import would
not handle the new markup of the export.
Change-Id: I7d18b06e10adff877dbbf1745861c65a07f807cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145863
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
to catch places where we are converting a weak reference to a strong
reference, and then using a pointer to store the result
Change-Id: I69b132907b574e5c6974fadf18bd9658107d3a0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145877
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is similiar to commit 1d6593dd79 (sw:
add a new .uno:DeleteFields UNO command, 2023-01-16), but that deleted
refmarks (used for e.g. Zotero citations), while this deletes sections
(used for e.g. Zotero bibliography).
Implement the section "unlinking" (delete the section, but not its data)
by deleting the section format: that will remove the matching section
node as well, but not the content nodes.
Change-Id: Ib00a8f592ddbb77c5e8e08ff94bb0eebfcf7cea8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145870
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
seen in fedora distro build. Probably since:
commit 4170b94c44
Date: Tue Nov 8 18:27:05 2022 +0100
SwModelTestBase: inherit from UnoApiXmlTest
See original discussion in https://gerrit.libreoffice.org/c/core/+/142465
use an alternative approach to solve this
[_RUN_____] testTdf143239::TestBody
Fatal exception: Signal 6
Stack:
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libuno_sal.so.3(+0x48bd8)[0xffff95428bd8]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libuno_sal.so.3(+0x4fd8c)[0xffff9542fd8c]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xffff955247fc]
/lib64/libc.so.6(+0x8d568)[0xffff94f2d568]
/lib64/libc.so.6(gsignal+0x20)[0xffff94ee3e80]
/lib64/libc.so.6(abort+0xf4)[0xffff94ed0284]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN3psp16PrintFontManager10SubstituteERN3vcl4font17FontSelectPatternERN3rtl8OUStringE+0xbc4)[0xffff91980de4]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(+0x891ea8)[0xffff91981ea8]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK3vcl4font22PhysicalFontCollection20GetGlyphFallbackFontERNS0_17FontSelectPatternEP19LogicalFontInstanceRN3rtl8OUStringEi+0xd0)[0xffff9186a7c0]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice10ImplLayoutERKN3rtl8OUStringEiiRK5Pointl13KernArraySpanN4o3tl4spanIKhEE14SalLayoutFlagsPKN3vcl4text15TextLayoutCacheEPK15SalLayoutGlyphs+0x112c)[0xffff915be0c0]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice12GetTextArrayERKN3rtl8OUStringEP9KernArrayiibPKN3vcl4text15TextLayoutCacheEPK15SalLayoutGlyphs+0x2c4)[0xffff915bf2b8]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN18ImplFontMetricData20ImplInitTextLineSizeEPK12OutputDevice+0x74)[0xffff91873da4]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice11ImplNewFontEv+0x1c8)[0xffff915b7318]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(+0x4c5f70)[0xffff915b5f70]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice14GetFontCharMapERN5tools5SvRefI11FontCharMapEE+0x34)[0xffff915b9004]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZNK12OutputDevice9HasGlyphsERKN3vcl4FontESt17basic_string_viewIDsSt11char_traitsIDsEEii+0x90)[0xffff915b9300]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libsvtlo.so(+0xff560)[0xffff8cadf560]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libsvtlo.so(_ZN11FontNameBox12CachePreviewEmP5Point+0x288)[0xffff8cae0168]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libsvtlo.so(+0x100448)[0xffff8cae0448]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN9Scheduler22CallbackTaskSchedulingEv+0x30c)[0xffff917b050c]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN14SvpSalInstance12CheckTimeoutEb+0x140)[0xffff919790a0]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN14SvpSalInstance9ImplYieldEbb+0x98)[0xffff91979818]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN14SvpSalInstance7DoYieldEbb+0xe0)[0xffff91979b70]
/builddir/build/BUILD/libreoffice-7.5.0.2/instdir/program/libvcllo.so(_ZN9Scheduler19ProcessEventsToIdleEv+0x40)[0xffff917bac84]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/CppunitTest/libtest_sw_layoutwriter.so(+0x5520c)[0xffff8d87520c]
/lib64/libcppunit-1.15.so.1(+0x1e4dc)[0xffff9549e4dc]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Library/unoexceptionprotector.so(+0x107ec)[0xffff94e107ec]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit16DefaultProtector7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x3c)[0xffff9549e1cc]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit14ProtectorChain7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x320)[0xffff954969f4]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit10TestResult7protectERKNS_7FunctorEPNS_4TestERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x80)[0xffff954a06d0]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit8TestCase3runEPNS_10TestResultE+0x11c)[0xffff954a993c]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite15doRunChildTestsEPNS_10TestResultE+0xe0)[0xffff9549e980]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite3runEPNS_10TestResultE+0x58)[0xffff9549e6a8]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite15doRunChildTestsEPNS_10TestResultE+0xe0)[0xffff9549e980]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit13TestComposite3runEPNS_10TestResultE+0x58)[0xffff9549e6a8]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit10TestResult7runTestEPNS_4TestE+0x38)[0xffff9549f5a8]
/lib64/libcppunit-1.15.so.1(_ZN7CppUnit10TestRunner3runERNS_10TestResultERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x70)[0xffff954a6b70]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x1443c)[0xaaaac255443c]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x15390)[0xaaaac2555390]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x10a38)[0xaaaac2550a38]
/lib64/libc.so.6(+0x30588)[0xffff94ed0588]
/lib64/libc.so.6(__libc_start_main+0x9c)[0xffff94ed0660]
/builddir/build/BUILD/libreoffice-7.5.0.2/workdir/LinkTarget/Executable/cppunittester(+0x10ab0)[0xaaaac2550ab0]
which: no gdb in (/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/usr/lib/jvm/java-17-openjdk-17.0.6.0.9-0.2.ea.fc38.aarch64/bin)
You need gdb in your path to show backtraces
Error: a unit test failed, please do one of:
make CppunitTest_sw_layoutwriter CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_sw_layoutwriter VALGRIND=memcheck
# for memory checking
make CppunitTest_sw_layoutwriter DEBUGCPPUNIT=TRUE
# for exception catching
You can limit the execution to just one particular test by:
Change-Id: Ife968c5d1d49081b1d28d50a557bc90d59980fc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145874
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Regression from commit a2a08463e0,
where I mistakenly assumed that the value is just to accommodate
enough entries. I don't know where it's documented, but this
fixes the bug.
Change-Id: Ifecf5d294222e3a40cb23f7c147694dbdf35e405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145869
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The base UnoControl uses WeakAggImplHelper9, so (for better or worse) derives
from XAggregation, but SbaXGridControl failed to properly implement the
XAggregation protocol.
Change-Id: I26c825b9b64b4e886e69f95bc3d4d5d42120bd8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145865
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The base FastPropertySet uses WeakAggImplHelper3, so (for better or worse)
derives from XAggregation, but SbaXGridControl failed to properly implement the
XAggregation protocol.
Change-Id: I31378f13256b1fa20775890b206f455d782ea864
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145868
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...rather than on the deprecated WeakAggImplHelper3.
It was found that those two classes were implementing queryInterface in a way
that is incompatible with the XAggregation protocol inherited via
WeakAggImplHelper3. It looks like no code actually made use of the XAggregation
offered by these classes, so the easiest fix for those queryInterface
implementations appears to switch from WeakAggImplHelper3 to WeakImplHelper
(thereby dropping XAggregation, and thus rendering the existing queryInterface
implementations OK).
Change-Id: I8f841ca959838d9a87943091b76f3ce1cf8c9303
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145866
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...rather than on the deprecated WeakAggImplHelper1.
It was found that that class was implementing queryInterface in a way that is
incompatible with the XAggregation protocol inherited via WeakAggImplHelper1.
It looks like no code actually made use of the XAggregation offered by this
class, so the easiest fix for this queryInterface implementation appears to
switch from WeakAggImplHelper1 to WeakImplHelper (thereby dropping XAggregation,
and thus rendering the existing queryInterface implementation OK).
Change-Id: I2352f5a57f2e23e6c7d512ef4d850844149269c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145867
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
When Fill style is none we can not use fill attribute element. So It is
better to hide.
Change-Id: I88d5e49448040b3afa18fbf66377d254716e7415
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145817
Tested-by: Jenkins
Tested-by: Pedro Silva <pedro.silva@collabora.com>
Reviewed-by: Pedro Silva <pedro.silva@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
otherwise it looks like only one row is getting moved
Change-Id: Ie0b63a9c3cea377c3753785d9c6f7958cbc7ac1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145818
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Split text lines in a paragraph, right before polygons are created
for rendering, so eol will brake line in fontwork just like eop.
Change-Id: Ie9e6764f9f91c2e19afd43dc9a212bd18c41c99d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145425
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Importing an inline content control from DOCX used to be just plain text
in Writer, so the PDF export of that was also just plain text.
Now that content controls are actually supported, we used to not emit
them as plain text in the PDF export, since
82d90529dc (sw content controls, rich
text: add initial PDF export, 2022-09-12). Part of this was to write the
string value of the content control as the /V (value) key of the form,
when it's not in placeholder mode. This made sure that once the form is
filled in, no overlap between the plain text and the filled in text
happens.
Try to support both use-cases at the same time by also mapping the value
of the content control to /V, even if it's in placeholder mode. This
keeps avoiding the unwanted overlap, but this way the placeholder text
is no longer lost on PDF export.
An alternative would have been to map the placeholder text to
description when the alias/title is empty, but that would show up only
as a mouse tooltip, so won't change the behavior when the PDF is
printed.
Change-Id: I9408b5abe36af28cd00845a74a3dfff13973b83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145828
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
there is no benefit to having this constructed in such a convoluted
manner
Change-Id: Ib02b4bfe689326784bd8233003d10960700811d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145778
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Sets an image for image content entries that are of linked type
Function 'InsertContent' added to replace duplicated code that
inserts content.
Change-Id: I25dec3f5765fa3dffe505743cd9c5fe044349ab0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145530
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
This patch is a mixed blessing.
It will be a regression if an IF FIELD was bogus,
and the user only wanted to see the modified, unrefreshed text.
That is because in MS Word, most fields do not update automatically,
but require the user to press F9 to refresh the contents.
The contents are also editable, so the result might not match
either the true or false result-string.
However, in LO the IF FIELD is always refreshed, and thus will
never display any bogus hand-modifications.
The import of these IF fields started in DOC in LO 6.1,
but it was never correct and immediately duplicated content.
Additionally, DOC format didn't export at all, so anything
to do with IF FIELDS was lost - meaning that after a round-trip
the result was the same as what MS Word last saw with the field gone.
So in the eyes of the user, the fixing of import and export
might be causing a regression of changed text.
So be it.
I can only assume that in most cases the use of an IF FIELD
is intentional and that it would be desirsable to have it working.
Change-Id: If90f6f4cddcefebf379352aac6519595c1bf2b23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145821
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Instead of assuming that the "insert reference" entry is always the second item of the menu tree, search for the correct child in the tree list. This commit addresses the failing build from https://gerrit.libreoffice.org/c/core/+/140985.
Change-Id: I6f0d7021ab6f632784cab85656823c69f90baf60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145816
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
The fieldmark may overlap a section; at the start was considered here,
but at the end was not and so the assertion wrongly fired.
Change-Id: I118bc36c2d9c4ca7028a583278d0f193537c4cb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145826
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...rather than on the deprecated WeakAggComponentImplHelper4.
It was found that e.g. GridControlAccessibleElement, deriving from
AccessibleGridControlBase, was implementing queryInterface in a way that is
incompatible with the XAggregation protocol inherited via
WeakAggComponentImplHelper4. It looks like no code actually made use of the
XAggregation offered by this class hierarchy, so the easiest fix for that
queryInterface implementation appears to switch from
WeakAggComponentImplHelper4 to WeakComponentImplHelper (thereby dropping
XAggregation, and thus rendering the existing queryInterface implementation OK).
Change-Id: Ia7f033d0a93e78a48573cb489dc5542603c35b8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145793
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
because if we allocate two things in the same location, we can subtlely
lose the second one.
Change-Id: I4dda5c738802da8544d280c020e059da63b5d71c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145779
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
