When exporting to PDF a document with a background image on the page.
The image would always be exported as a bitmap at a fix resolution, even
if the original data had vector form (like a pdf or svg).
This ensures that the original vector data is also exported as it is
done with regularly inserted images.
Change-Id: I7f363614ba375e01a4b076c961ce91dae8c2351b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202994
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Use less IUnknown::QueryInterface, and more COMReference::QueryInterface.
No need to use COMReference default ctor in member initializers.
Change-Id: I28cd07d16dc294d598580f353a4ec7efe82bc480
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198040
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
these were skipped in previous runs, since they contain some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
This also shaves off some 140M input
Change-Id: Ie1f57174dd6fec3ba5b0b91eb0688acdc1a8143d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197494
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
No need to look up a cairo function dynamically as we know that in
Windows we are using a cairo we build ourselves so we can be sure that
it is has what we want.
There is a TEXT() macro in winnt.h, and we use that (indirectly)
elsewhere, so we can't just undefine it in postwin.h. Thus we can't
initialise a variable calld TEXT using parentheses.
Check USE_HEADLESS_CODE before checking _WIN32 to get the former code
in the CODA-W case and the latter otherwise for Windows.
Change-Id: I8987e3b33d51ea232f8262413d17a50910d8e7b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197007
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[d-g]*
This shaves off about 150M input
Change-Id: I2b15257451d4b392dca3e5d07f4a443ee653b04c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196395
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
aSquare and aCandidateSquare are filled with the output from
GetOutputWidthPixel() and GetOutputHeightPixel(), which both return a
value of type tools::Long. Replaced the use of sal_uLong for aSquare and
aCandidateSquare with tools::Long to match. This is a follow-up patch
that fixes the incorrect use of sal_uInt64 from a previous patch.
Change-Id: I402c9ed6a949f64217b0833b513bf92b1593d62c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195038
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
GetOutputWidthPixel() and GetOutputHeightPixel() both return a value of
type tools::Long, representing an offset width and height in pixels.
Since aSquare and aCandidateSquare multiply these values, it seems
reasonable to use sal_uInt64 here just in case of larger displays.
Change-Id: Idacf8e7c43e884b72699ee1d521d1e0dbf4715a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194942
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
this path is no longer the default for gtk3 where the SDPR renderer is
the default so there:
export DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1
is needed, though it is still the default for the gen backend, so that
can be used too
Change-Id: If64b7805ee4987ceab5af99decdf755280270e02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194079
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
There is definitely a better fix for this, we should not need two
different bitmaps and masking and stuff, but this will fix the problem for now.
Mostly revert the following commits:
commit 7278030b92
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Sep 15 16:26:25 2025 +0200
remove unused DrawModeFlags
commit 581c52dad2
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Sep 10 15:08:04 2025 +0200
BitmapAlphaClampFilter is dead since
commit e7b460f919
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 30 15:23:11 2025 +0200
BitmapEx->Bitmap in canvas
Change-Id: Ic5747ce6143a8320f977111c7635bf736a9996d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193873
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
VclPixelProcessor2D::processPatternFillPrimitive2D and
impBufferDevice were independently calculating the mask rect in
different ways. So move the calculation to the callers.
This only fixed a tiny part of the problems in this bugreport,
it just helps with off-by-one at zoom levels.
Change-Id: I933f5271e31ba79794951a6b1f469fc28094d0a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192572
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
This is the same thing I did in
commit 3cbe3a0259
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Jun 14 15:05:59 2021 +0200
tdf#101083 speed up SVG rendering with pattern fill
but cut and paste from the VclPixelProcessor2D to the CairoPixelProcessor2D code.
Which makes this SVG render in reasonable time when using the cairo backend.
We can probably do even better by cutting out the usage of VCL here, but this
is good enough for now.
Change-Id: I959539741eef627b25702c91cad3e5f8ee2b3176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192394
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is follow up to commit:
commit b9f0caad5d
Author: Khaled Hosny <khaled@aliftype.com>
Date: Tue Aug 23 04:13:28 2022 +0200
tdf#66819: Disable ligatures with character spacing
Even though editengine was applying letter spacing, when drawing with
drawinglayer, letter spacing was not propagated which caused VCL to not
disable the ligature features.
Change-Id: Ia8bf2231478720262484a757e16fe5afec3cd28e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191512
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
regression from
commit cd93f83bbc
Author: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Date: Thu Aug 7 21:02:41 2025 +0200
tdf#167831 avoid painting bitmap data with zero dimensions
we cannot skip these fills if the fill bitmap is too small,
we need to fill with something or the resulting picture
is very wrong
Change-Id: I194b59414db8f675df2415c3ee4fb9a0305611b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190981
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to move the logic of constructing a new Bitmap from an existing Bitmap and an AlphaMask,
into vcl, where it can later be optimised
Change-Id: I2af1c6d1a35d968abdd07546448f7e211772e70b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190366
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
regression from
commit c2fedef548
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Aug 6 20:35:05 2025 +0200
BitmapEx->Bitmap in Graphic
the problem here, is that we are now allocating a single 32-bit bitmap instead
of a 24-bit bitmap and an 8-bit bitmap.
The crashtesting file has an image of size 17000 x 17000, which hits the
size > SAL_MAX_INT32/2
check in ImplCreateDIB the svp backend.
Change-Id: Ic76eb03adeedcfbb7d60e78405641035e3eb7087
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190323
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Khaled Hosny