Age | Commit message (Collapse) | Author |
|
For pixel-wide lines it should not make a difference.
Change-Id: I28a9034eef9a81c6899c5fae679af5e413ee981c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93435
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
For backends that do the object-to-device coordinates transformation
directly, it's necessary to also convert the size of line width.
But simply multiplying it with the matrix can also rotate the line
width "vector", making it e.g. negative. So don't use just the X
coordinate, use vector length for the transformation, which is ok.
In fact it doesn't even make sense to treat width as a vector, because
a width simply is not a vector (and for this reason it's also not
actually used).
Change-Id: I1241c9cb29155df105170d568a879ebc32b11a5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93203
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
This seems to only enable better sampling in Impress, but still.
Change-Id: I654e320a55982183ea0b935618badb3409b94316
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93434
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ia08bc3824c9040e9601f4e4c3296e02b53ad5221
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93433
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The cairo-based method on Unix and manual glyph handling way taken
from GL on Windows should be longer be needed, now that using Skia
itself for text rendering seems to work fine.
This reverts more or less reverts the following commits:
b1d3ef798a89d11b853c467fa9ce0fe6ed235735
5ac9a62f3a354db80837bdd1c95b763989b303bb
619959827003814053a5e9ec81acfd07b3aa270a
6f5c85daa0e5073d87d1d7699bfa59af159686ca
ad3580df085b3a3d66eb73cae997ea5ca178ccc1
f109a1ac6fdf0c878d53dfea6fceffd93248608f
59205c742c43b4c456b69c3fd94e7fa35ff3eec0
Change-Id: Ib28b2469c7d6471c227bb2aa08d5485bb24c2fe1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93428
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
In the Basic code window, extend the selection on the last paragraph
during the search/replace process in order to consider newly inserted
text portions.
Change-Id: I27ad998709ac25cffbef4a354c87d422f97e1b51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93432
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This makes the last (or the only) strip to run im main thread, thus
removing threading overhead for small (width/height <= 16) objects.
Change-Id: I6da050a62b00a013838f16eb94a32e2639d93aec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93423
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...left over presumably accidentally by bb459008de9d410e6e7ea982ce30aa22f70ae849
"vcl: add DetectorTools + tests, refactor array string matching", but which
causes heap-buffer-overflow during CppunitTest_vcl_filters_test when printing an
apparently not null-terminated string, see
<https://ci.libreoffice.org/job/lo_ubsan/1614/>:
> ==12896==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61d0000e5480 at pc 0x000000454f7f bp 0x7fffaff10200 sp 0x7fffaff0f9b0
> READ of size 2049 at 0x61d0000e5480 thread T0
> #0 0x454f7e in printf_common(void*, char const*, __va_list_tag*) /home/tdf/lode/packages/llvm-472c6ef8b0f53061b049039f9775ab127beafbe4.src/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors_format.inc:547
> #1 0x45568b in vprintf /home/tdf/lode/packages/llvm-472c6ef8b0f53061b049039f9775ab127beafbe4.src/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1631
> #2 0x45575e in printf /home/tdf/lode/packages/llvm-472c6ef8b0f53061b049039f9775ab127beafbe4.src/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1689
> #3 0x2b0e63a119ca in vcl::checkArrayForMatchingStrings(char const*, int, std::__debug::vector<rtl::OString, std::allocator<rtl::OString> > const&) /vcl/inc/graphic/DetectorTools.hxx:57:9
> #4 0x2b0e63a1ad0a in vcl::GraphicFormatDetector::checkXBM() /vcl/source/filter/GraphicFormatDetector.cxx:426:9
[...]
> 0x61d0000e5480 is located 0 bytes to the right of 2048-byte region [0x61d0000e4c80,0x61d0000e5480)
> allocated by thread T0 here:
> #0 0x4f5648 in operator new[](unsigned long) /home/tdf/lode/packages/llvm-472c6ef8b0f53061b049039f9775ab127beafbe4.src/compiler-rt/lib/asan/asan_new_delete.cc:108
> #1 0x2b0e63a1a839 in vcl::GraphicFormatDetector::checkXBM() /vcl/source/filter/GraphicFormatDetector.cxx:419:42
> #2 0x2b0e639685b8 in ImpPeekGraphicFormat(SvStream&, rtl::OUString&, bool) /vcl/source/filter/graphicfilter.cxx:394:23
> #3 0x2b0e639693b0 in GraphicFilter::ImpTestOrFindFormat(rtl::OUString const&, SvStream&, unsigned short&) /vcl/source/filter/graphicfilter.cxx:455:13
> #4 0x2b0e63970153 in GraphicFilter::ImportGraphic(Graphic&, rtl::OUString const&, SvStream&, unsigned short, unsigned short*, GraphicFilterImportFlags, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const*, WmfExternal const*) /vcl/source/filter/graphicfilter.cxx:1437:19
Change-Id: I8d88a417083c14e4f1a9a78f9e1354390283d83c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93403
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I63ae6adec1967bcf888538437e5e88f0acdea66e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93392
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: Ia48560274c33aaa8e81a5ee6eb00f6470e92e0fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93349
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia6a4cedf5c570e5d9544887ae66da0ec1e491647
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93348
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Add DetectorTools with byte array searching and matching to a
input string (or another byte array). This refactors the existing
function in GraphicFormatDetector. It needs to go into its own
header so that the function(s) can be tested easily. Replace
the previous searchEntry implementation with refactored one in
the source code.
Change-Id: I59d30b694e13f28d6366f1a99fe2ef2ea3c1a07d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93339
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Add test case for Animation and GDIMetaFile serialization.
Change-Id: Ibe2fa9982c8faea36e1f26ca9c6b735ae0ebd8ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93337
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Makes the code much more readable..
Change-Id: I99d89652bda4ac74c867d70ec565403510c58c61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93338
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I73aafc4f9a6f964a31d116610df6cf15dc51770c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93334
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3c4845550e776c4c2c891d94db71bacea27c9a37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93328
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ic365d27e9ef1c676e47de22b8949b5679c0a2841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93326
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The test checks that the exported PDFs contain embedded PDF for
different pages.
Change-Id: I4e5cd108d8597851d86aa774efbde0d4f2b9d2ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93322
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id26a79fa047f1f6d26cab1f08e1db57330d4168b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93319
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
simply calling gtk_drag_cancel on the treeview dnd under X doesn't seem to work
as hoped for (though under wayland all is well). Under X the next (allowed)
drag effort doesn't work to drop anything, but a then repeated attempt does.
But sending an Escape keyevent to get gtk to cancel the drag for us does work
as hoped for.
Change-Id: I09d3187e66774f9d23c77e0d515af7ae2a8fe156
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93317
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3ec4d8b5e508653668bee3567e32f0920f56e3b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93313
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1014ee1ee67b475d5dd72ceb07fd8fd234171f55
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93309
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I37bd5adab653f80a120cb9850a0bebd45c5cb7e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93276
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6b463724e301989a60e423bbfc25aa1bf146ff5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93267
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
not just the menubutton sub-part
Change-Id: I75342e3b7b21537565a3a367e1a8b2924b95e822
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93233
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I344dde9e04496612641bca502e7aac53506f920a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93232
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I186622aec3e944b89536bdcd44ff0be6b1d9cd8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93213
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I380b85646a62c4eafa40fdb5257060fac040feb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93195
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
the default is very wide in the default gtk themes, try and minimize
that padding as the existing designs generally assume a very narrow
dropdown
Change-Id: Ibb3b0280067e981b7c782b6023fc3d36dbc0d364
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93167
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ifd1d3999d1c6eb9aba7919850859e6b7cb652e3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92055
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Mulit-line label split, Build realized as link_button
Required changes also solve tdf#132066 partially as many
localized strings are not anymore copied to clipboard
Change-Id: I346fdc65cd1734f17854eccd587fe0b7e216e720
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93119
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
The changed code is used to initialize data before processing first
pixel of each row/column of the bitmap, since in order to blur it,
we need some information about assumed previous pixels. But previous
code assumed that information for the first pixel or each row and
each column is taken from first pixels of first column, not from
first pixels of respective row or respective column. This doesn't
make practical difference for the pre-extended bitmap with a solid
color of the border (see centerExtendBitmap; it's the only actual
case ATM). But in case of not pre-extended bitmap with non-solid
border color, that would result in wrong blur of first pixels.
Consider this bitmap (* is white, 0 is black):
*00000000
*00000000
*00000000
*00000000
*00000000
000000000
...
For this bitmap, existing code pre-initialized each row and each
column as if it were prepended with "******" from column 0, and so
each first pixel of each column and each row would be blurred with
white, even where it's all black (consider columns >=1, and rows
>=5).
Additionally, the existing initialization assumed that there's
always at least as many scanlines as min(radius, bmpWidth), which
might be false. See how aArrays was initialized using nLastIndexX
in stackBlurHorizontal, and then that value affected the index
passed to pReadAccess->GetScanline.
This changes the code to consistently consider first pixels of
respective rows/columns for pre-initialization data.
Change-Id: Ibe3be8750fe5347302eca782a00b36096d99820c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93118
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If20d8f0140b223bad921c8d7be34b1973cfe692e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93076
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib3f6d01ddec37afc3987423dc15ab84ad6475f37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92942
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
* make cache size configurable (defaults to 15)
* have one cache object per PDFWriter instance, thus avoiding
accidentally caching JPEGs with different compression settings
Change-Id: I6664fc09b382f471cbe7c3e7aaedb3ebb5883b47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93112
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I50a80014addf5fb6a3974139249f45f6a2e67d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92939
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Before, code was test-compressing every single bitmap coming along.
Let's buffer those SvMemStreams, and keep the last 15 around in
case the same image comes along again.
Change-Id: Ic8da32725ea46b01bd6beacc389abf8f52845d36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93058
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I94d7ce65aebd6b74f214362c466fda38c4808d9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92966
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8a1c1d862a998fb0bef912bea5b6b4dd058c127f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93059
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3ca1676f3f447d720aa9dea28572daff8cff8d87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92992
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4c7c5cfa36d43a15509498dc4f28c10bf3fd7344
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92991
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I990fafa8b01e94aef58d6cad30bc13de539ea496
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92968
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... since b512ce255f46d90e682634e4dd17e146af7f9080.
Yes, MSVC also produces an error if the completeness requirements
are not met.
Change-Id: I0ad573ef1d14a383eed3a8f83aa932657c22ae20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92963
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Test the rotation in JPEG metadata is what we expect.
Change-Id: I5ee2d646a5257d5695c51f37fb6fe795dcb9af50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92948
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
ImplCreateSwapInfo changed to createSwapInfo.
Flatten the code body
Change-Id: I5865373d0b7f3cc717a9600bcf6fd198e8320e35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92947
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Iec0227b1e1ceebda961e158315ea5e56c2d33204
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92946
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I30930f61385e31e7754d6653ff2eecfea61ce4e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92945
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3e578c3172fcea341a218798843cd750971a5af1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92944
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
We can display PDF as an graphic in the document, where the PDF
is treated as a vector graphic and rendered with Pdfium. When
in that case we export the document as PDF, we can insert the
original PDF page as an reference XObject. This workes fine,
however the PDF as an graphic also contains the page number,
which page should be rendered. This was not taken into account
in the PDF export - it was hardcored to first page.
This extends the support so it reads the page index from the
graphic, and sets the correct PDF page.
Change-Id: I15188ee495f9b3fcc3aa7df6f4bad4fa09903c6a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92924
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|