Age | Commit message (Collapse) | Author |
|
do it like this to avoid adding another mapmode and to keep things
"the same" as much as possible
Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1f1c8285a1d41a9c9694a54c0bdfb20c6f0b27ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141512
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
...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>
|
|
Communicate Kashida insertion positions in an explicit way.
Rest of LibreOffice communicate adjustments to character widths (e.g.
for justification or spacing) using so-called DX array. DX array is an
array of absolute character positions (e.g. DX[n] is the position after
character n from the start of the lines, and its widths is DX[n] -
DX[n-1]).
This DX array is modified also when Kashidas are inserted after a given
character for Arabic justification, by expanding its width. VCL would
use this to know where to insert the Kashidas and how many ones.
But because DX array is used for both widths adjustments and kashida
insertion, this turns out to be a source of bugs since VCL has tosecond
guess the DX array to find which is pure width adjustment and which also
involves Kashida insertion, and the heuristics it uses are fragile.
This change adds a second array of booleans that records where Kashida
is inserted and communicates it all the way from where Kashida insertion
is decoded in Writer and down to VCL layout.
This change passes the Kashida array only when it seems necessary (e.g.
during drawing but not when measuring text since the DX array is enough
in this case). Hopefully no places where Kashida insertion needs to be
passed down were missed.
A couple of glyph and layout flags that were used for old heuristics and
no longer needed and are removed.
This also fixes:
tdf#87731
tdf#106309
tdf#108604
tdf#112849
tdf#114257
tdf#127176
tdf#145647
tdf#146199
Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1d9bebc5bc0b32e71694915070a8770b3ca601c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134606
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See tdf#42949 for motivation
Change-Id: I74a3c3a67c3639376e2251c3eb917fa4139dfbd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127808
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I02b42dc4a825e01363e36d6a82f78519e2c6dfe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127294
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Makes code simpler, and std::span can be constructed from std::vector
too.
Change-Id: Iae26b53c52148c19d9068a63126a7393d098d654
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124507
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
A leftover from commit bc413e15fae3672f580894a3cd7b077d533d8e6c
Change-Id: Ibacdf71f608657a4488c84b88ef54fb52d3e8439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124496
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
|
|
Change-Id: Ifb96e496b0994b5fc66975b7aea0a60bcb4a3a03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124345
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
revert commit 8689bd5490b473a7ffb149bbe5f7f0683f679c72
Author: Caolán McNamara <caolanm@redhat.com>
Date: Thu Jul 29 20:49:29 2021 +0100
convert TextAlign to scoped enum
lets leave this as it always was
Change-Id: Id4d2a5644974cdd2b0ed6d361d5c52629674d057
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120626
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id2c466eacb44f0ea6adba75a0ac0be8be8e7ed4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119682
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I651858d71e378341205d6a785bd97f294664a439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116737
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: I7022ffba519faad5a333d7ef6eabf1ba5f0ae3bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115232
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I352147dd86d8ba73da1706c42c885bef0f11b2cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115071
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
So that we have fewer cases to deal with when we transition to
32-bit bitmaps.
(*) rename maMask to maAlphaMask, since now it is only being used
for alpha duties.
(*) drop mbAlpha and mbTransparent to simplify state management,
the only thing we need to check for alpha is if maAlphaMask is
non-empty.
Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Revert "convert internal bitmap formats transparency->alpha"
This reverts commit c181e510c5f5e74f1f6824b64637849aace9ae63.
and later fix up of
Revert "tdf#141504 qt5: ugly images"
This reverts commit e7424ff25a724ea5bb54b2282d5c3cbf74c92053.
a lot of places are still working int transparency values
and not opacity
Change-Id: I31342cdb76629acbaebfcdfa385407d3291fe06f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114150
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
We can cast the PixelFormat enum to int for the same information
and we can use the enum to reduce ambiguity when possible.
Change-Id: I6ea648139465568cdeb12e5f5f75c7b609365bf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113188
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
since we have already removed the 4-bit internal bitmap formats.
Change-Id: Ie481aaa8e25642a47e30beb6f37e2d3beda304e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113412
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
IRC chat:
<quikee[m]> noelgrandin: doesn't adding operator bool to Bitmap
has the same problem as Graphic and the reason why you dropped that
commit 7334034ae93b49fc93b5859a3c047a319d138282
"drop Graphic::operator bool"
<noelgrandin> quikee[m], hmmm, good point
<noelgrandin> maybe I should just drop both operator bool and
operator! in favor of IsEmpty
<quikee[m]> noelgrandin: I don't remember what the problem is I just
remembered we dropped it Graphic :) sure, dropping everything for
IsEmpty is probably the best
Change-Id: Ieae289cda64f0b8d8fdecd5ea9e6f2bb874ff4cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113163
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idcae44440a197f6b3b824cbbac430e370964ac25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112368
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If32c6f6d3618c134cfb2ac89e827491525c34687
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111811
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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.
Change-Id: I537f77f79e83876be11d787901df42710d190842
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108919
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie8d28702bbae6c76924745a5a773393f1b831012
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109706
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: Ida34f9428d342cbe7f89f7bf40688c71cdba30c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109299
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
this just changes the Get/Set methods, the constructor and internal
representation of Color is not changed.
Change-Id: Idb6e07cc08bbaa5bd55b6bd4b585e648aef507b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109074
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Split class functions into BitmapInfoAccess.cxx, BitmapReadAccess.cxx
and BitmapWriteAccess.cxx
Split header files into BitmapInfoAccess.hxx and BitmapReadAccess.hxx
Change-Id: I7dcbe1d26c5b64d297658a6b809c93d7ad7f053d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108039
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If7f47cf6dad860e4f8eab68931b72a38a7eda136
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107362
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
It is by now practically unmaintained, even bugreports in bugzilla
have been already closed for it. AFAICT this used to be really
used only on Windows, where it's no longer the default.
There's still some OpenGL code left, because there are still two
other places that use OpenGL. One is OpenGL slideshows, which
reuse some of the base OpenGL code (and I've checked they
still work even after this removal). Second one is OpenGL canvas,
which it seems has never been finished or enabled (or so it
most probably should be dumped too).
Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ifcdecb0a60f5a4b09acc83ed38b6d1ec46765ba6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105649
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
...more likely to pick an appropriate version for the involved integer types,
esp. after the recent long -> tools::Long changes
Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since
commit 77809fba7d4bf5e0b604ffa3937c18d5530c2d56
Author: Luboš Luňák <l.lunak@collabora.com>
Date: Fri Oct 9 19:28:49 2020 +0200
implement ImplFastBitmapConversion() for 8bit gray source
Change-Id: I730aef10c1705ae6d3141014228cf79b8bfa3c63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105305
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...after 1ebeacb20ad0165e399629fcfd7795ad0da3edf8 "Extend loplugin:cstylecast to
certain function-style casts"
Change-Id: I99bd383f5b3bee861d442d2e1be6ecd356b78315
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104523
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This commit was carried out by a Python script, source of which
is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97.
Change-Id: Icd712adf20fa2dbaaea2fc33a0fd870c8595b7e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100147
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I6512e6e4217ef9084c74e46e3b4f1e8defbd1bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100108
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie28438633d9d81d756013772c573f02a756478d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100096
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I85149c0618a9b347fd1710f46b825844b3119bf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100087
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idc808459b403bcdcccbd86b73dd22b424e507c8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98897
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Ie1f1736ceda372a53e1065d4829f019338f5b7bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98730
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
See tdf#74608 for motivation.
Change-Id: Id8d6ef240ba872f7e93752614cd2d45fc50897ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98729
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's much simpler and more performant to work with 8bpp bytes
rather than fiddle with 1bpp bits, and the memory savings don't
really matter nowadays. E.g. the soft edges feature performs
much worse when operating on 1bpp bitmaps (tdf#134237).
I've looked and it seems nothing in LO code actually requires
bitmap masks to really be 1bpp. As a next step we could perhaps
also leave antiquity and embrace the past by dropping 1bpp masks
entirely and using just alpha masks.
The change also moves the workaround for #i75531, it was breaking
CppunitTest_vcl_svm_test and X11-related hacks belong to the X11
code (especially with the X11 backend becoming more and more niche).
Change-Id: I7848f06c8b83bbad2ea35f17f2b65855f8d1f456
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97839
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Common::Misc::OpenCLWhiteList -> OpenCLAllowList
Change-Id: I65636b19b13e4af1e4851f70e78053f3443d6bb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98181
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
.. and a few cases of instead doing blacklist->excludelist where that
made more sense.
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
[API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist
[API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice
[API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList
Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Idad3d8fbe785c7b1b8b287a3227372adb2757de8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94260
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7bd0c2a55b936896fcfe7e1a374871008a18618f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93706
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...now that macOS builds are guaranteed to have std::optional since
358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
The change is done mostly mechanically with
> for i in $(git grep -Fl optional); do
> sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \
> -e 's/\<o3tl::optional\>/std::optional/g' \
> -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i"
> done
> for i in $(git grep -Flw o3tl::nullopt); do
> sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i"
> done
(though that causes some of the resulting
#include <optional>
to appear at different places relative to other includes than if they had been
added manually), plus a few manual modifications:
* adapt bin/find-unneeded-includes
* adapt desktop/IwyuFilter_desktop.yaml
* remove include/o3tl/optional.hxx
* quote resulting "<"/">" as "<"/">" in officecfg/registry/cppheader.xsl
* and then solenv/clang-format/reformat-formatted-files
Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|