Age | Commit message (Collapse) | Author |
|
Change-Id: I717319dd3843aa7d73d0722967e80f7d07e98143
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143006
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
- Disable security tab as protect/password subdialog
not fully async-ed
- Disable custom property tab as still unstable
- Hide Digital signatures button
- Make duration dialog async
- Set location as file name
Signed-off-by: NickWingate <nick.wingate@collabora.com>
Change-Id: I5843bb7737af8dd6b7d3af273ddd8997f2e35e10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138010
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142987
Tested-by: Jenkins
|
|
Signed-off-by: rash419 <rashesh.padia@collabora.com>
Change-Id: I27cbb72b4ccd486b58934503b1d3d5d7ff47cbfe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132865
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142970
Tested-by: Jenkins
|
|
This is needed for Impress which can have slides in
two Edit Modes: Master Page and Page.
Change-Id: I3eca0f51ba7970e793026d1ac6aa09b19b7a904b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137869
Reviewed-by: Ashod Nakashian <ash@collabora.com>
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142969
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I54ec1486f49f240e1ab88662b9d1b0b741cf8878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142905
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
|
|
Change-Id: I5bb3e60d52813fddfc9a5eb7a0e87d5f5e3853f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142904
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142964
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I5dcba14a9b0dfcc5267760410f6d135fcd3b1bd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142944
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This primitive is created if a text edit is active
and contains it's current content, not from model
data itself.
Pixel renderers need to suppress that content, it
gets displayed by the active TextEdit in the EditView.
Suppression is done by decomposing to nothing by
default.
MetaFile renderers have to show it, so that the
edited text is part of the MetaFile, e.g. needed
for presentation previews and exports.
So take action here and process it's content.
Note: Former error was #i97628#
Change-Id: I32c83c0ad7883a79fc40f5a21ac6ed7b1055b7df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142910
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
69e9925ded584113e52f84ef0ed7c224079fa061 "sdext.pdfimport: resolves tdf#104597:
RTL script text runs are reversed" and f6004e1c457ddab5e0c91e6159875d25130b108a
"tdf#151546: RTL text is reversed (Writer pdfimport)" had introduced two calls
to comphelper::string::reverseString into sdext. That function reverts on the
basis of individual UTF-16 code units, not on the basis of Unicode code points.
And while at least some pre-existing callers of that function want the former
semantics (see below), these two new callers in sdext apparently want the latter
semantics. Therefore, introduce an additional function
comphelper::string::reverseCodePoints with the latter semantics.
I identified three other places that call comphelper::string::reverseString:
* SbRtl_StrReverse in basic/source/runtime/methods1.cxx apparently implements
some StrReverse Basic function, where a (presumably non-existing) Basic spec
would need to decide which of the two semantics is called for. So leave it
alone for now.
* SvtFileDialog::IsolateFilterFromPath_Impl in fpicker/source/office/iodlg.cxx
reverts a string, operates on it, then reverts (parts of) it back. Whether or
not that is the most elegant code, using the latter semantics here would
apparently be wrong, as double invocation of
comphelper::string::reverseCodePoints is not idempotent when the input is a
malformed sequence of UTF-16 code units containing a low surrogate followed by
a high surrogate.
* AccessibleCell::getCellName in svx/source/table/accessiblecell.cxx apparently
always operates on a string consisting only of Latin uppercase letters A--Z,
for which both semantics are equivalent. (So we can just as well stick with
the simpler comphelper::string::reverseString here.)
(Extending the tests in comphelper/qa/string/test_string.cxx ran into an issue
where loplugin:stringliteralvar warns about deliberate uses of sal_Unicode
arrays rather than UTF-16 string literals wrapped in OUStringLiteral, as those
arrays deliberately contain malformed UTF-16 code unit sequences and thus
converting them into UTF-16 string literals might be considered inappropriate,
see the newly added comment at
StringLiteralVar::isPotentiallyInitializedWithMalformedUtf16 in
compilerplugins/clang/stringliteralvar.cxx for details. So that loplugin had to
be improved here, too.)
Change-Id: I641cc32c76b0c5f6339ae44d8aa85df0022ffb05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142949
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... and likewise DeleteWindowFromPaintView -> DeleteDeviceFromPaintView
because they add/delete output devices, not windows, ever since commit
53fd4bb47c53cbb62a542c847ed38238e7b3e148 (INTEGRATION: CWS sdwarningsbegone
(1.42.34); FILE MERGED, Dec 12 18:19:15 2006)
And use references instead of pointers, because they are dereferenced
unconditionally.
Change-Id: I67d5841babaec040aa5308e95f333948eb0dde2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142945
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
not used outside cppunit tests and it's not something to encourage
to toggle
Change-Id: I6519de48dfaa20293afc0874702653439e142285
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142940
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie2cdb0a361376b488d9829c892c9f4c6e9711503
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142941
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If525ba9826f5bc2d860233cbabf58d1d290be054
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142936
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I772f529ea4bd225701b9864ad9156c573f41484c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142715
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
MacOS produces a slightly different glyph height.
Quoting from Khaled in dev IRC:
"Currently GetGlyphBoundRect() calls different platform-specific
implementations on each platform, so even with the same font it is
possible to get some difference. So my suggestion is to use a large font
size and allow for some fuzziness".
Consequently I'm using a 110pt font.
Change-Id: I939e633eb1e45a16171ad0675216246b31966454
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141234
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I656037ef4e40e7c79daef5dd73f8f10c9818ac25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142215
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This patch creates a new color entry in Tools - Options - Application Colors for "Grammar mistakes". Default values are also set for the "LibreOffice" and "LibreOffice dark" schemes.
This patch also applies the selected color to the document, as well as in the SpellChecker dialog.
Change-Id: I07f79da9858b675b330540cf08cf389dce39228d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142294
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
|
|
And extract the identical code used in all components into
static SfxLokHelper methods.
Change-Id: I6556b1b996936835ecfc0d59e2c1dd1ef6380db2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142793
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
so createScDoc handles the dispose of new documents
saveAndClose can go now
Change-Id: I7f88ef6ff9aaece72461489a31b0ef456ce5e170
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142781
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Assert not only that the widget is a text one, but also that it has the
correct date format.
Change-Id: If2bb8dcdfca0a8b76b5ed179ff558d351137bc06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142747
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
we no longer need to wrap it in the framework XBitmap
implemenation
Change-Id: I0dc56ad63364e2c5a4cedd5e70d4ae7ea7eae563
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142746
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If2402c824e637016e3c10860810501ec60732bc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142000
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Ica799419ed628f94f134433ca5b37518c5698909
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142730
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Some notes:
* testLinkedGraphicRT needed to be adapted. Saving to
Calc Office Open XML doesn't keep IsLinkedGraphic.
Reported in tdf#152036. No idea why it didn't fail before
* Some tests used "generic_HTML" as export filter format, which
is wrong. Instead, "HTML (StarCalc)" should have been used.
But then, the test would have failed with
- unsatisfied query for interface of type com.sun.star.sheet.XSpreadsheetDocument!
So trying to export to html in those tests is not expected.
No idea why it didn't fail before
* testTdf90299 fails now with
- Expected: 'file:///tmp/lu23738863wthph.tmp/dummy.xls'#$Sheet1.A1
- Actual : 'file:///tmp/lu23738863wthph.tmp/lu23738863wthpg.tmp/dummy.xls'#$Sheet1.A1
I added a TODO to check it later
* testNamedRangeBugfdo62729 fails on mac with an infinite loop
Change-Id: I63168583a47f510d1ac22971a274e28d085de61b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142576
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Ic68aa91b1cbf23ac305ad4e361c56b91556757ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141604
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This patch fixes tdf#152012 which caused an assertion failure on opening
date picker field in a DOCX file
The assertion was:
include/o3tl/span.hxx:83: constexpr o3tl::span<T>::value_type& o3tl::
span<T>::operator[](o3tl::span<T>::size_type) const [with T = const
int; o3tl::span<T>::reference = const int&; o3tl::span<T>::size_type
= long unsigned int]: Assertion `pos < size()' failed.
And the backtrace was:
1 __pthread_kill_implementation pthread_kill.c:44
2 __pthread_kill_internal pthread_kill.c:78
3 __GI___pthread_kill pthread_kill.c:89
4 __GI_raise raise.c:26
5 __GI_abort abort.c:79
6 __assert_fail_base assert.c:92
7 __GI___assert_fail assert.c:101
8 o3tl::span<int const>::operator[] span.hxx:83
9 OutputDevice::ImplLayout text.cxx:1396
10 OutputDevice::DrawTextArray text.cxx:948
11 Calendar::ImplDraw calendar.cxx:71
12 Calendar::Paint calendar.cxx:1133
The problem was caused by an out of bound access to a vector of integers
which was created for rendering calendar header consisting of the first
letters of 7 days of week, when you clicked on the down arrow on the
date field.
The function OutputDevice::DrawTextArray() takes an 'rStr' string to
draw, and 'pDXAry' array for the exact position of the the individual
characters. It also takes 'nIndex' as the first index, and 'nLen' as the
length of the array. 'nLen' has the default value of -1. In this case,
the length is calculated from the size of the string passed to the
function. This works well if the one who uses the function makes sure
that the size of the array and the length of string are equal.
Previously, for the 7 days of the week, a 7 letter string "smtwtfs"
(depending on the week start day this can be different, but length is
always 7) was sent to this method without providing the length, thus
the string length: 7 was used. In this case, positions of the letters
were calculated and used from other array named mnDayOfWeekAry[7].
mnDayOfWeekAry[k+1] was used as the position of letter k (k=0..5).
In this case, there was 7 letters for 7 days, and only 6 positions
provided by the array. This caused assertion failure in span.hxx:83
when trying to accesss mnDayOfWeekAry[7] via o3tl::span<T>::operator[].
Value of mnDayOfWeekAry[0] was used in other calculations, therefore to
fix this problem, mnDayOfWeekAry was extended from 7 to 8, and the last
position was set to the end of drawing rectangle.
The other thing that is done in this patch to avoid this problem in the
future is removing the default value from the function prototype, so
that the use should always be done by providing the length of array and
starting index. After removing these defaults, it became necessary to
provide empty arrays for 'pKashidaAry' which provides the kashida
positions, if needed.
With this fix in place, the assertion failure no longer happens.
A UI test is added to make sure the crash will not happen again. The
test can be run by invoking:
cd sw && make -srj1 UITest_writer_tests5 \
UITEST_TEST_NAME="DateFormFieldPropertiesDialog.dateFormFieldDialog.test_date_picker_drop_down" \
SAL_USE_VCLPLUGIN=gen
Change-Id: I347afb358fbc4956524f7f0a0abc3a221bf42992
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142642
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
Change-Id: I0fc55e829e22b81a076f2b66d78bb2b90abdfc41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136413
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
As long as not all our mechanisms are changed to RGBA
completely, mixing OutDev with Alpha (2x VDev) and RGB
target rendering is just too dangerous and expensive
and may to wrong or deliver bad quality results (see
comments in code for details).
Nonetheless we need a RGBA result for convert to
BitmapEx. Luckily we are able to create a copmplete
and valid AlphaChannel using 'createAlphaMask'.
Based n that we know the content (RGB result from
renderer), alpha (result from createAlphaMask) and
the start condition (content rendered usually
against COL_WHITE). Tht makes it possible to
calculate back the content, quasi 'remove' that
initial blending against COL_WHITE.
That is what the helper Bitmap::RemoveBlendedStartColor
does. Luckily we only need it for convert To BitmapEx,
not in any other rendering.
This gives good results, it is in principle comparable
with the results using pre-multiplied alpha tooling,
also slightly reducing the range of color values where
high alpha vlaues are used, but in areas that are
highly transparent anyways.
Also important is that this will work with RGB-based
system-dependent renderers, too. The method before
could only work with the VCL-based primitive renderers
by principle (only there - by coincidence - OutputDevice
with Alpha worked).
NOTE: Had to re-add usage of *unused* alpha channel
in convertToBitmapEx due to test SdPNGExportTest. It
somehow creates an Alpha in Bitmap size when I *remove*
Alpha in convertToBitmapEx, so I just keep it for now,
it is created anyways, just wanted to make it sleeker.
Change-Id: I12e47327f5793d6ed87e217a2355c608f528246f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142547
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
so other places inheriting from UnoApiTest can also import/export
protected documents
Change-Id: I0e2716204dbb171c9e17e3939b266977e1b96dda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142592
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
...that was apparently left by accident by
24c709655e5c1ca51c6c6da7ef0cb733354f6d20 "clang-tidy modernize-pass-by-value in
comphelper", thwarting the use of std::move here.
And clean up the declarations in the include file, too.
(I came across this code with an upcoming loplugin:constmove that flags
suspicious uses of std::move involving const-qualified types.)
Change-Id: I8178ad09bc4e7d4f57c5dfd9b0e2103e6d4fa72a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142566
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It will share information about real size of a data inside
spreadsheet so we can easily check where data ends in online
side.
Change-Id: I376187a33c5c82d409f559d5cc826a4f36d4252e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139472
Reviewed-by: Gökay ŞATIR <gokaysatir@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142503
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I3905fc9e6376ca1cef3e438e7a5f229d3720b1f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138961
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Henry Castro <hcastro@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142501
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
this gets nice sidebar icons in this case
as far as I can see only gtk_image_new_from_file (or
gtk_image_new_from_resource) can support the use of a scaleable input
format to create a hidpi GtkImage, rather than an upscaled lodpi one so
forced to go via a file here
Change-Id: I665cd5be2c87f6fe8e264640be228263cdfc1fba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142504
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I74d3307aab8fc038bd2409b5f10a2d08db885223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138957
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Henry Castro <hcastro@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142472
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I165295609a95e6dd03ae5e35f987b2defa18ff18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142496
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I1d84d8c1e371016a4f4f068af1e9c76635f28cf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142490
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
it seems setUp/tearDown can also go as well.
See the discussion in gerrit.
Change-Id: I5e81dcdcb2e070eb4beb737f3cb25c86cb9d042b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142465
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
After 6d6a143913603b040c10a5db83c2103557899011 "Address some of the sprintf in
vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23
compiler that implements
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1:
Simpler implicit move" started to fail with something like
> vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString'
> return aDefaultGlyphName;
> ^~~~~~~~~~~~~~~~~
[...]
> include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument
> OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() )
> ^
etc. So I figured there should be something better than
433ab39b2175bdadb4916373cd2dc8e1aabc08a5 "Adapt implicit OString return value
construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts
in comphelper/source/xml/xmltools.cxx and
sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in
a way that keeps code that works up to C++20 also working in C++23.
(The fix is only relevant for non-explicit constructors that involve
NonConstCharArrayDetector and non-const lvalue references, not for other
functions involving those. OUString has a similar constructor but which is
explicit, and OUStringBuffer doesn't have any similar constructors at all, so
this only affects OString and OStringBuffer constructors.)
Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2695c86e9b749a4c38920af6d33e8e89f8ea3c62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142426
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iec42b3bf348ba82a98d4ad8236a9e8b95fdfe5f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142422
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
SwModelTestBase does the same. this will help to make
SwModelTestBase inherit from UnoApiTest
Change-Id: If1c824cf92f0e8b70253e4d5fdeddcaa521d4632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142287
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Currently SvtOptionsDrawinglayer::IsAntiAliasing() is used
in the constructor of the VCL based processor2Ds to decide
if AA is to be used or not. Using this inside the
constructors makes it currently impossible to use a
primitive renderer independent from these settings,
except when changing these settings temporarily what
may influence other renderings and is a hack.
The setting SvtOptionsDrawinglayer::IsAntiAliasing() is
intended to decide if LO shall use AA mode from user's
perspective, this means for the EditViews of the Apps
and some other occasions (previews, exports, conversions
to bitmap, ...).
This works currently since all visualizations for these
purposes use newly constructed primitive renderers. But
there is no way to use primitive renderers independent
from that setting. For future renderers which might be
used for other purposes this is not sufficient, there
has to be a method to create a renderer using e.g. AA
independent of the global setting.
To allow that, move the deciding flag to the already
used geometry::ViewInformation2D. To not change anything
initially, use the global flag for now to init that
default value at ViewInformation2D.
I took the opportunity to adapt ViewInformation2D to
no longer being read-only and not changeable, it uses
internally an impl class based on cow_wrapper already
anyways. Extending this would lead to the constructors
getting even bigger, when usually only 1-3 values
need to be changed and many usages want to copy an
existing instance and modify it. Adapted that usages
to a much smaller footprint.
Up to this point this does not change anything, but
move the usage of the SvtOptionsDrawinglayer to the
defaults (constructors) of the involved class
ViewInformation2D. Using this then in the primitive
rederers should be safe and will allow to use a
primitive renderer with or without AntiAliasing
independent of the user setting, so also for non-
EditView usages.
Also already added the PixelSnapHairline setting, this
will also be needed independent of user settings to
have full freedom of usage.
Unfortunately I cannot use SvtOptionsDrawinglayer
methods
::IsAntiAliasing() or
::IsSnapHorVerLinesToDiscrete
inside ViewInformation2D where I would need it. It's
now in drawinglayercore and thus not linked against
svtools (svt) anymore.
Thus I have to do some forwarding mechanisms to get
the correct values available in ViewInformation2D.
Not nice, caused by creating drawinglayercore...
Change-Id: I9f572ce67e5d86a242188bdc6d4ba7c9a12f6a9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142393
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
4 bits bmp support has been dropped in March 2021 with:
a6c6f35ccc78e74cfa76397d649c1b6fc4baad29
"drop 4bpp image formats
on a path to simplifying our internal bitmap stuff, aiming to
support a smaller set of image formats, but support them
in an accelerated fashion.
"
1 bit dithered bmp support last remnant has been dropped in April 2020 with:
e3cc7b94b13d6cc4e044cfd688e0fcc9dca63987
"loplugin:unusedenumconstants BmpConversion"
Change-Id: I958bea6baabb9ef21c5fa71bfc7ff96cba201245
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142375
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
...(which cause -Werror,-Wdeprecated-declarations with macOS 13 SDK), by making
CffSubsetterContext::getString, and in turn CffSubsetterContext::getGlyphName,
return OString. Which in turn required adding rtl::OStringConstExpr and
OString::unacquired counterparts of rtl/ustring.hxx functionality to
rtl/string.hxx.
(It's not quite clear to me whether the nMaxLen clipping in
CffSubsetterContext::getString was only there to avoid overflow of the--
somewhat arbitrarily sized?---static aNameBuf, so could go now, or rather served
as a more general safety measure to not read past the mpReadPtr buffer end and
should thus remain. Hence, I added a TODO comment for now.)
Change-Id: I473d5a54a4be5b02917e197391e4f0982dcf690c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142412
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I823a2ec24aea47b4b3d005107c8a18fec223e6df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142398
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
no need for the indirection, which is out by one anyway, perhaps
from some time that the "none" entry was in the list vs a separate
widget as it is now
Change-Id: I028e03260f500473b42847ee748d7af8a4791ccd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142397
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...when shoehorning a std::size_t value into sal_Int32, to not suppress
potential warnings from tools like -fsanitize=implicit-signed-integer-truncation
and -fsanitize=implicit-integer-sign-change
Change-Id: I610410f7cd69769c3721b2019e16b4c9f214ad81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142407
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...from ustring.hxx, in preparation of using its OUStringConstExpr as a
blueprint for a corresponding OStringConstExpr in string.hxx
Change-Id: I3bf89133e9308dd56e2041a2a5ebb68145fdd0e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic0c1a73668e990c91ef6e90e8c01e669761fe356
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142403
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie5df0153446e6af1c717c74dba722ac2aea2b738
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142379
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|