IsExoticProtocol used GetHost() to recover the nested package url of a
vnd.sun.star.pkg url, but the package content provider in
ucb/source/ucp/package/pkguri.cxx uses the whole authority between "://"
and the next '/', which GetHost() truncates at '@'. Check the same
substring the provider does.
The vnd.sun.star.zip branch below already did the equivalent extraction,
so pull the shared parts into a helper that both branches call.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I27be6a839108f2e58d62baefc1a71dcbfc9a4568
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4410
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(cherry picked from commit ce436efb34d2e0e90ee2cdb450da285530c562f7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206681
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
And not truncate it to an integer value.
Add additional overload for attribute that takes an enumerated type, otherwise
the compiler will complain about ambiguous conversion because it cannot
choose between the attribute that takes a integral value and the one that
takes a double value.
Change-Id: I9eae22817ec3b26da7b9468d1c8b5e6f3e900538
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201193
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Starts a process of converting the call-sites of SvFileStream
to just write data, relying on the stream being set
into the correct encoding somewhere during initialisation.
In this commit, I change WriteByteStringLine to do that.
For most of the call sites, they either:
(a) use the stream encoding explicitly
(b) already set the stream to the encoding being used at the call-site
Only in buildFontMenuName did I need to make the stream explicitly
set the stream encoding.
Also add a utility constructor to SvFileStream to make it easy
to set the stream in the correct mode at open-time.
Ideally a stream should be set into the correct encoding
at open time and never changed.
Change-Id: I57afa74807e15320a176a05d43c94c377dad4561
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200289
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Use the correct term. E.g., Unicode charset has different encodings
like UTF-8 and UTF-16, and we mean encoding here.
Change-Id: I65e90b31cda6e39fdb1584b492e6e0b9821865a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200285
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Seems like recent font/pdf related changes have exposed a latent
bug(?) in the SvMemoryStream class. Specifically, writing to
SvMemoryStream using a source pointer that points inside the SvMemoryStream
data buffer causes trouble when the buffer is re-allocated.
Make SvMemoryStream tolerant of this, although it is a rather
dodgy use-case.
READ of size 177 at 0x531000155fe7 thread T0
SvMemoryStream::PutData(void const*, unsigned long) /tools/source/stream/stream.cxx:1578:5
SvStream::WriteBytes(void const*, unsigned long) /tools/source/stream/stream.cxx:1195:26
vcl::filter::PDFDocument::WriteCatalogObject(int, vcl::filter::PDFReferenceElement*&) /vcl/source/filter/ipdf/pdfdocument.cxx:577:27
freed by thread T0 here:
in SvMemoryStream::FreeMemory() /tools/source/stream/stream.cxx:1694:9
in SvMemoryStream::ReAllocateMemory(long) /tools/source/stream/stream.cxx:1671:9
in SvMemoryStream::PutData(void const*, unsigned long) /tools/source/stream/stream.cxx:1569:22
in SvStream::WriteBytes(void const*, unsigned long) /tools/source/stream/stream.cxx:1195:26
in vcl::filter::PDFDocument::WriteCatalogObject(int, vcl::filter::PDFReferenceElement*&) /vcl/source/filter/ipdf/pdfdocument.cxx:577:27
Change-Id: I2613ed66cec600b7f44e575a56f6a97c0ff3053d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199959
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which helps avoid some supposedly spurious -Werror=free-nonheap-object seen
at least with recent GCC 16 trunk,
> In destructor ‘virtual SvLockBytes::~SvLockBytes()’,
> inlined from ‘void SvRefBase::ReleaseRef()’ at include/tools/ref.hxx:160:36,
> inlined from ‘tools::SvRef<T>::~SvRef() [with T = writerfilter::rtftok::RTFTokenizer]’ at include/tools/ref.hxx:56:46,
> inlined from ‘writerfilter::rtftok::RTFLookahead::~RTFLookahead()’ at sw/source/writerfilter/rtftok/rtflookahead.cxx:37:1:
> include/tools/stream.hxx:115:48: error: ‘void operator delete(void*, std::size_t)’ called on pointer ‘((tools::SvRef<writerfilter::rtftok::RTFTokenizer>*)this)[1].tools::SvRef<writerfilter::rtftok::RTFTokenizer>::pObj’ with nonzero offset 56 [-Werror=free-nonheap-object]
> 115 | virtual ~SvLockBytes() override { close(); }
> | ^
etc.
Change-Id: I26a599f0e3258e6bf6a4d6e63e559b41029862db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197842
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
In tests we many times rerun the XPath search to just check another
XML attribute, or first check the size of child elements and then
check each element's attributes in a separate call (re-running the
XPath search). Re-running an XPath search all the time takes up
quite some CPU resources and doing it a lot will accumulate, so the
idea here is to have an object as a result on which you can reuse
instead of re-running the search.
In addition it is possible to combine the search path from the
previous search, so it is possible to construct paths in a more
concise way.
Example:
auto primitivePath = aXPath.create("/primitive2D");
auto polyPath = aXPath.create(primitivePath, "/polypolygon");
polyPath will use a combined path "/primitive2D/polypolygon"
as the search path.
Checking can be done by simply using CPPUNIT_ASSERT* functions
with this, but we might extend UnoApiXmlTest with some checks
for convenience because the assertXPath methods do have better
reporting when the assert fails. Also integration into the
UnoApiXmlTest class will need to be done, because namespaces need
to be registered before tools::XPath can be used correctly. This
change does not touch that yet.
A couple of tests in SvdrawTest have been changed to use the new
tools::XPath class - most notable testRectangleObject. These tests
don't use any namespaces so it is easy to convert those.
Change-Id: I29251d2e7f4c3ee5b76e46daf78c21d0ca067cb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195618
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
We don't use it yet from any C source file, but the plan is to do
that. Mainly from freetype, fontconfig, and cairo, when these are
built for Windows when the --enable-headless options is used (for the
new Collabora Office).
Also some cleanups, sorting #include lines, avoiding warnings, etc.
Change-Id: Ifef3588d06fdcceaeaeb3482399737faaf558d7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195602
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
So we can use it in dumpAsXml functions and eventually use it as
a replacement to directly using libxml.
Change-Id: I204d487b52343f69224fec2fd480657785bc0a69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195167
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
LOK_HOST_ALLOWLIST allows to pass a restricted list of hosts that
curlsession will be allowed to download from.
LOK_HOST_ALLOWLIST_EXEMPT_VERIFY_HOST reuses this list for the use case
of not verifying SSL host additionaly for them. This is useful for say
developpement environement.
Change-Id: I75ac26a4bfe1c33ff183c4ad12391b2da08593cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193961
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 8688e9d8c94a21a7a0abc9edfe632e6fa0e94281)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194187
Tested-by: Jenkins
Reviewed-by: Méven Car <meven.car@collabora.com>
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Direct leak of 392 byte(s) in 1 object(s) allocated from:
#0 0x5cc5b75ab144 in ___interceptor_malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3
#1 0x5cc5ba1b928a in _cairo_image_surface_create_for_pixman_image /work/workdir/UnpackedTarball/cairo/src/cairo-image-surface.c:191:15
#2 0x5cc5ba1b928a in _cairo_image_surface_create_with_pixman_format /work/workdir/UnpackedTarball/cairo/src/cairo-image-surface.c:370:15
#3 0x5cc5ba200f40 in cairo_surface_create_similar_image /work/workdir/UnpackedTarball/cairo/src/cairo-surface.c:598:10
#4 0x5cc5b8b16a5c in createTmpCompatibleCairoContext /src/libreoffice/vcl/headless/CairoCommon.cxx:621:31
#5 0x5cc5b8b16a5c in CairoCommon::getCairoContext(bool, bool) const /src/libreoffice/vcl/headless/CairoCommon.cxx:432:14
#6 0x5cc5b8b1a473 in CairoCommon::drawPolyPolygon(basegfx::B2DHomMatrix const&, basegfx::B2DPolyPolygon const&, double, bool) /src/libreoffice/vcl/headless/CairoCommon.cxx:959:19
#7 0x5cc5b8558575 in SalGraphics::DrawPolyPolygon(basegfx::B2DHomMatrix const&, basegfx::B2DPolyPolygon const&, double, OutputDevice const&) /src/libreoffice/vcl/source/gdi/salgdilayout.cxx:499:5
#8 0x5cc5b81c0ece in OutputDevice::DrawTransparentNatively(tools::PolyPolygon const&, unsigned short) /src/libreoffice/vcl/source/outdev/transparent.cxx:230:25
#9 0x5cc5b81c0794 in OutputDevice::DrawTransparent(tools::PolyPolygon const&, unsigned short) /src/libreoffice/vcl/source/outdev/transparent.cxx:460:14
#10 0x5cc5b83629c0 in GDIMetaFile::Play(OutputDevice&, unsigned long) /src/libreoffice/vcl/source/gdi/gdimtf.cxx:374:26
this happens because once a cairo context enters an error state no
functions have an effort on the cairo context.
The error is CAIRO_STATUS_INVALID_MATRIX and the matrix derived
from the polypolygon is degenerate.
The polypolygon contains a polygon with 0 points, which looks invalid,
detect that at import boundary rather than mess around with duplicating
with some with cairo_matrix_invert the invalid matrix at use location.
Change-Id: I3f6a53de3d2638146f969a6f0997c1a58f1669c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192184
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1659699 Overflowed return value
cid#1659759 Overflowed return value
cid#1659922 Overflowed return value
cid#1660190 Overflowed return value
cid#1660286 Overflowed return value
cid#1660457 Overflowed return value
Change-Id: Ie9fffe4994b10ed3d4feb14eaf7950e3f01714ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189927
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
As WMF and EMF is using integers and previous EMR_ROUNDRECT implementation
used many small lines to display curves, it produces low quality curves.
With this implementation using Bezier curves,
EMR_ROUNDRECT images are scalable without any loss of quality.
Change-Id: I3ef7f15ed9e3835065030bdf196b9bfa044d84a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189016
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Caolán McNamara