which warns against using the 'operator bool' conversion of
std::optional<bool> which can lead to interesting bugs
The bugs that this plugin have been submitted independantly,
so this change is just using has_value() in relevant places.
Change-Id: I259b837feeecddcb8cd1d7e5db1e85bf505907cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155978
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Even when drawing to a VirtualDevice where antialiasing
is disabled, text will still be drawn with some
antialiased pixels on HiDPI displays. So, expand the
size of the VirtualDevice slightly to capture any of
the pixles drawn past the edges of the destination
bounds.
Change-Id: Ibcba8234708d8784c12f984289ec0a8fcad6694e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156098
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Patrick Luby <plubius@neooffice.org>
(Second attempt at landing this)
Image formats and graphics APIs use alpha, not transparency,
so change our internal formats and data structures to work directly
with alpha, so we don't need to modify data before we push it to
graphics APIs.
Add a couple of new Color constants to make the intention
of the vcl code clearer.
Notes
(*) On macOS, tweaking the logic in CreateWithSalBitmapAndMask
to more accurately reflect the requirements of the
CGImageCreateWithMask function seems to fix some
tests.
(*) The vcl code does not properly support gradients
with transparency. So the previous code was wrong, and this
change is going to result in slightly different wrongness.
Change-Id: I9e21c2e98d88ecfdc5f75db13bd1ffff7c38db98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114168
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This was missed in:
commit 3901e029bd
Author: Khaled Hosny <khaled@aliftype.com>
Date: Mon Aug 8 22:08:37 2022 +0200
tdf#104921: Cleanup Kashida insertion logic
The width adjustment passed through, but Kashida insertion positions
didn’t, leaving gaps in place of Kashidas when canvas is used
(apparently canvas is only used for slideshow).
Change-Id: I25ff30f10cc46a5c87bda2f3936df26b2fc926b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153234
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
(a) It is not obvious what DeviceFormat::DEFAULT means
(b) There are two parameters (each with two states), but only really 2
possible overall states
So
(1) use more useful names
(2) combine the two parameters into one enum
Change-Id: Ic0595b39e032cc9e019b88326389d055b977da00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146589
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
on modern hardware, these are less efficient than regular alpha
channels.
Also, this greatly simplies the range of stuff that vcl needs to deal
with, which will make the upcoming transparency->alpha patch easier to
deal with.
Enhance vcl::CreateFromData to convert incoming 1-bit data to 8-bit
image.
Change-Id: I35829da750029fe373d0d2911a669d10bab6ad23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
to ease the reading of code related to an upcoming patch to convert
transparency to alpha, since there is already a GetAlpha in Color.
Change-Id: I1af0f8f6dd94acfe4673c8556c7aff6c20da3f7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145209
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and
cid#1504665 Big parameter passed by value
cid#1505368 Big parameter passed by value
revert the clang-tidy modernize-pass-by-value changes that coverity
warns about
Change-Id: Id92fdc8d1caeed9eaf7ff1e9e745938e5a971a34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135803
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that started to crop up with recent GCC 12 trunk (where it expanded
the ENSURE_OR_THROW macro, but apparently didn't take into account that its
> 97 | if( !(c) ){ \
> | ^~
will always be taken in these cases where the c argument is false), and
can easily be avoided by getting rid of those uses of
ENSURE_OR_THROW(false, "...")
(And while at it, move the default case to a more reasonable position in
mtftools.cxx, obsoleting the FALLTHROUGH comment in any case.)
Change-Id: I8189d98b361e6725096d0968f3e0e604fb84e591
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126452
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to 374e261ad1 "increase maximum document
thumbnail size from 256 to 512" (which wasn't caught by Jenkins due to
bcd243793e "CppunitTest_cppcanvas_emfplus: disable
this in case there is no display to use")
Change-Id: Ibe3dc93401e237c37b4823f0393746b1e8b569bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126424
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
so we get bounds checking in debug mode
Note that I cannot just pass around the std::vectors
involved because there is a place in editeng which
calls with a subset of a vector.
Change-Id: I5088a139593c27bf9cbe5d843ab4b0048ac6d508
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124330
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...for LIBO_INTERNAL_ONLY, instead of having them as additional overloads. That
way, loplugin:bufferadd and loplugin:stringviewparam found many further
opportunities for simplification (all addressed here). Some notes:
* There is no longer an implicit conversion from O[U]String to O[U]StringBuffer
(as that goes via user-defined conversions through string_view now), which was
most noticeable in copy initializations like
OStringBuffer buf = someStr;
that had to be changed to direct initialization,
OStringBuffer buf(someStr);
But then again, it wasn't too many places that were affected and I think we can
live with that.
* I made the O[U]StringBuffer ctors taking string_view non-explicit, mainly to
get them in line with their counterparts taking O[U]String.
* I added an OUStringBuffer::lastIndexOf string_view overload that was missing
(relative to OUStringBuffer::indexOf).
* loplugin:stringconstant needed some addition to keep the
compilerplugins/clang/test/stringconstant.cxx checks related to
OStringBuffer::append and OStringBuffer::insert working.
* loplugin:stringviewparam no longer needs the special O[U]StringBuffer-related
code that had been introduced in 1250aecd71
"loplugin:stringviewparam extend to new.."
Change-Id: Ib1bb8c4632d99b744e742605a9fef6eae959fd72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122904
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
because I'm trying to track down a related heap corruption, and that is
much easier if the access to the array is checked by the std::vector
debug runtime
Change-Id: Ia665f5cebb7f14d88942e88b4b400ad3c28ef5d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
as part of a longer-term goal of doing our
widget rendering only inside a top-level render-
context.
I moved all of the OutputDevice-related code that existed in vcl::Window
into a new subclass of OutputDevice called WindowOutputDevice.
Notes for further work
(*) not sure why we are getting an 1x1 surface in
SvpSalGraphics::releaseCairoContext, but to fix it I clamp
the size there
(*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice
(*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code?
Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
