Age | Commit message (Collapse) | Author |
|
and
cid#1545364 COPY_INSTEAD_OF_MOVE
cid#1545363 COPY_INSTEAD_OF_MOVE
cid#1545344 COPY_INSTEAD_OF_MOVE
cid#1545299 COPY_INSTEAD_OF_MOVE
cid#1545287 COPY_INSTEAD_OF_MOVE
cid#1545267 COPY_INSTEAD_OF_MOVE
cid#1545256 COPY_INSTEAD_OF_MOVE
cid#1545226 COPY_INSTEAD_OF_MOVE
cid#1545500 COPY_INSTEAD_OF_MOVE
cid#1545538 COPY_INSTEAD_OF_MOVE
cid#1545618 COPY_INSTEAD_OF_MOVE
cid#1545681 COPY_INSTEAD_OF_MOVE
cid#1545750 COPY_INSTEAD_OF_MOVE
cid#1545778 COPY_INSTEAD_OF_MOVE
cid#1545785 COPY_INSTEAD_OF_MOVE
cid#1545799 COPY_INSTEAD_OF_MOVE
cid#1545847 COPY_INSTEAD_OF_MOVE
cid#1545958 COPY_INSTEAD_OF_MOVE
cid#1545963 COPY_INSTEAD_OF_MOVE
cid#1545990 COPY_INSTEAD_OF_MOVE
cid#1546013 COPY_INSTEAD_OF_MOVE
cid#1546029 COPY_INSTEAD_OF_MOVE
cid#1546079 COPY_INSTEAD_OF_MOVE
cid#1546104 COPY_INSTEAD_OF_MOVE
cid#1546127 COPY_INSTEAD_OF_MOVE
cid#1546133 COPY_INSTEAD_OF_MOVE
cid#1546155 COPY_INSTEAD_OF_MOVE
cid#1546190 COPY_INSTEAD_OF_MOVE
cid#1546216 COPY_INSTEAD_OF_MOVE
cid#1546273 COPY_INSTEAD_OF_MOVE
cid#1546315 COPY_INSTEAD_OF_MOVE
cid#1546326 COPY_INSTEAD_OF_MOVE
cid#1546387 COPY_INSTEAD_OF_MOVE
accept some reasonable suggestions
Change-Id: I7b004086d490c7618d8fe7a21a53cfa8ac1f8408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161748
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The old name was misleading (it doesn't take an URL, but a filename);
also, now it's easier to grep for it - doesn't get mixed with
vcl::graphic::loadFromURL.
Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and try something a bit more generic
Change-Id: I1d8256576cd02f0a589df350ba7b53059dd586a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161250
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I23bd626973c9aa0b4a961b16d5817d58c5f0cf7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161188
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
(*) Make all of it use a "Scoped" paradigm
(*) pass by value, no need to allocate on heap
(*) make all of the construction go via the *Access constructors, instead of it being some via the constructors and some via the Acquire*Access methods.
(*) take the Bitmap& by const& in the constructor, so we can avoid doing const_cast in random places.
Change-Id: Ie03a9145c0965980ee8df9a89b8714a425e18f74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160293
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1b169e0c170c26a49941d22f0982a24ef547f941
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160391
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ida43018a83c68f5d20dbee30325b8f32099e5b1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159713
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
since:
commit c75cac85230d3899fe9f5f5086c117e4e1e5d330
Date: Sat Jun 17 02:57:42 2023 +0200
tdf#155887 WMF Fix displaying images with size of EOF other that 3
Change-Id: I326593cc556319d947bd9f3aef32b4ff6264c68f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158731
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
The size of W_META_EOF (record indicates the end of the WMF metafile)
could be different than 3 (e.g. 6).
The MS Office is allowing different sizes of EOF,
and just properly finalizine parsing WMF file, and display its content.
Original bug report:
https://bz.apache.org/ooo/show_bug.cgi?id=42090
Change-Id: I21b72615c7f45fdca145e6240c6451d7d264d238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153204
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
In previous implementation, there was no proper validation
of the records, by it's size.
This commit adds validation of the WMF records.
It would allow to interrupt reading, if wrong record found
and play only records until it it correct.
It will allow to mimic the behaviour of MS Office:
If the wrong record is detected, the image is displayed till the wrong record.
Currently in LibreOffice, if wrong record is found whole read is interrupted.
Change-Id: I0c82deabcec7a416ca44540e693822f1986437eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153351
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
and use it to make WmfTest::testSetTextAlignWmf independent of DPI
Change-Id: I2048239088a8dcc3e3ab1db96413894b5bcc56d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157377
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Checked on jenkins using 'make check' and
+ void SAL_CALL setDelegator(css::uno::Reference<css::uno::XInterface> const &) final { assert(false); }
+
Change-Id: I5ff6b1e166aff1ad67464785cf39d748f5dfc236
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156700
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I34a8ec2f69d9d58f8847e9cfb45937eae6159590
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When doing subpixel positioning (i.e. OutputDevice is in map mode),
delay the rounding of the glyph coordinates after converting from pixel
to logical units to minimize the loss of precision as much as possible.
Some test expectations, expectedly, changes due to the improved
positioning precision.
Change-Id: I2591e3c7d4923ba7886a35bf53db759273354e24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154292
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: خالد حسني <khaled@libreoffice.org>
|
|
Change-Id: I2c96b367138b94d6178a3c4a0f83049f13a04f82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Due to different imlementation of floating-point unit (FPU),
on different CPU platforms, the floating point numbers could
could be different.
https://stackoverflow.com/questions/64036879/differing-floating-point-calculation-results-between-x86-64-and-armv8-2-a
https://mcuoneclipse.com/2019/03/29/be-aware-floating-point-operations-on-arm-cortex-m4f/
With this path I have changed the tested images,
to use floating point numbers which are easily represented
by floating numbers (multiplied/divided by 2), like:
- change tension to values: 0.125, 0.25, 0.5, 1.0, 1.5 ...
- change position of curve to of control points to 256.0, 384.0 512.0
Previous values was hard to represent by floating numbers,
for example tension:
- 0.4 has been written as 0.399999976158142
- 0.1 has been written as 0.099999994039535
More information:
https://observablehq.com/@benaubin/floating-point
Additionally the precision of numbers were
increased to double.
Change-Id: I5725c1f2f474d0c00821edaa9bb2102cb172093f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152838
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I98d30b2a8ba63fdddc08668f453c5f0feeb452db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152288
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I44661cb2f9b2f44118140ae2fbcf86fe12cd282c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151760
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
since:
commit ba0bf0ab2c24d309e8a938cec26daa41eba9c8cf
Date: Mon Mar 21 20:20:02 2022 +0100
tdf#142249 EMF Implement EMR_POLYDRAW record
Change-Id: I9234a66d9f8691b9b051950b818884429b5f7277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151728
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4d67eb7112d2295185905eac52ebab022a1beb78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151670
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I1a7d7600563b57fb6dd9479b288d6fd3d4483059
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151710
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7786a63c4cad8e4538b108a06551ff274a0ddcc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151658
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I792bb179d2ac0133175e2690df6731fcb8bbbc15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151659
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The EMR_POLYDRAW record specifies a set of line segments and Bezier curves.
Change-Id: I93d846d2fbb7a60b0565668a17ee092da30ef21c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151424
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
There is several benefits of such performance optimization:
1. We are drawing single curve instead of hundreds of small curves.
In the loop we are creating single Polygon and outside
of the loop we are invoking EMFPPlusDrawPolygon drawing method only
once. As https://bugs.documentfoundation.org/attachment.cgi?id=186725
image is using single EmfPlusRecordTypeDrawBeziers EMF+ record with
hundreds of curves, with using single EMFPPlusDrawPolygon call,
there is no lnger need for individual line creation (e.g. line
color, weight, line caps, line joints, line dashes, etc.)
- The PDF export performance without optimizations of the https://bugs.documentfoundation.org/attachment.cgi?id=186725:
time ./instdir/program/soffice --headless --convert-to "pdf:writer_pdf_Export" --outdir ~ ~/Pobrane/problem.docx
real 24m18,471s
user 2m56,004s
sys 1m37,816
- The PDF export performance with optimizations:
real 0m37,527s
user 0m37,004s
sys 0m0,531s
- With Libreoffice 7.5.2 from Ubuntu 22.04, the conversion was
crashed.
2. The PDF export for document: https://bugs.documentfoundation.org/attachment.cgi?id=186725
was not working correctly for me. The original image is containing
chart. Without optimization, the exported chart was empty.
Current export is working correctly, and graph is visible.
3. The standard opening of the document from https://bugs.documentfoundation.org/attachment.cgi?id=186725
is now much faster. The zooming in, move image operations are also
noticible faster.
Change-Id: Ic77d4c20a462587bb5da4a4df757e30c5ca04fc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150821
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
This suite is large enough so that avoiding the
declaration/registration/definition of each test manually saves a lot of
space.
Change-Id: I476b58a1c45ed5c977ce71a92d172b7e2df93015
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150224
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I6898acbf7c6c9de45bbfa6a32202acf302f92caa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146822
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
It is so much easier to work with if a test failure's line number unambiguously
points at the code's sole execution. (That is, test code is necessarily non-
DRY.)
Change-Id: I75919c55671348f6190e9e108e72e24ec18ce986
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148514
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It had originally been disabled by a037f6338c19e16bcbc0674214666a786872c59d
"Disable CppunitTest_vcl_wmf_test under --enable-merglibs for now" because "the
problems caused by that test having the vcl objects linked into both the test's
library and the mergedlib (which the test's library links against) are just not
manageable", which is no longer an issue at least since
29cdfa3fc337381e2529eaac2a551137ee8a1aaa "no need to statically link against the
emfio library in the tests".
But the test code apparently uses WinMtfFontStyle, which can thus no longer be
hidden under --enable-mergelibs.
Change-Id: Ie807b19f0cb44408c69d03faca01fabe88239ca0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148493
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
since:
commit bbdbe8ea2ef176ef6f08b30b3c18876c2c4f0c22
Date: Fri Feb 3 22:55:54 2023 +0100
tdf#142018 Properly create Pen width if style is COSMETIC
Change-Id: I739932e7bbf427a72bf16a771c20b6bd5596da5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147041
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6453058c4af352a3b0e14cbccbc1a67c73cd1426
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146551
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
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>
|
|
This reverts commit 1230b88055c7389d2c376c316f91549e4aaef8aa.
Reason for revert:
The reverted commit breaks the files documented in tdf#152435 (some
text is not shown in those .EMF files). The reverted commit would solve
an issue where some text was not clipped correctly, albeit in a naive
way. As it is more important that text is shown rather than some text
having correct clipping, that patch is reverted and I will look for one
that fixes both cases.
Change-Id: I42e85b802b8bf1e77e96f0016cd1d83201047032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143970
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
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>
|
|
...added with f71606c920a3f78294da745cd9ef1eacde010224 "new loplugin:moveit".
(I came across this code with an upcoming loplugin:constmove that flags
suspicious uses of std::move involving const-qualified types.)
Change-Id: If9c79d9a838fab5efbb55cb89b27b87f7e7ccd76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142562
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I8a91edb86edd76b70648507f12b18d9e923ab16e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141774
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
|
|
EMR_SAVEDC would call UpdateClipRegion which would break the clip region
sometimes before drawing the text causing it to not be clipped
This line was introduced in a i#964 related patch
(https://bz.apache.org/ooo/show_bug.cgi?id=964)
The document in that test seems to render the same and the test file
from the changed test renders the same also before and after this patch
Change-Id: Id515b90efc9e533e18a35030a9a677de4d4ea02d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142272
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
EMR_EXTSELECTCLIPRGN would not factor in WinOrg coordinates which would
give the clip box wrong coordinates causing some graphics to look
chopped in the wrong way.
Change-Id: I4f9a1b1c27fc276d188d0d865991795dab48dce5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142110
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Id69f3639cb957570c4165150b288397c6e06727e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142324
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: If1278f336aaff56a4378dcc1f0f95e0a749b629d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142099
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: If60dfb726ba42bcb96a2d218bb81cb700f4c71f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141805
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The reason for the blurry document in tdf#150888 is that the image is
tiny. PPI is 2540 in that image but when using the window bounding box
(96, 81) this results in a very small image that the .odt then scales up
which makes it blurry.
Apart from that, when opening the extracted .wmf in Draw it's also very
small, around 0.04" squared.
Because MM_ANISOTROPICs definition allows for arbritrary scaling, when
an image would be smaller than an inch squared the PPI is scaled down to
either the images width or height. This makes the extracted WMF match
the size of competitor office suites and fix the blur bug without
breaking past tests.
Change-Id: I11eab879848d9308f818708a91fd9eb91fc65200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141533
Tested-by: Jenkins
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This is pretty much the same for SoftEdgePrimitive2D as the
change for GlowPrimitive2D, so for more comments please refer
to commit c2d1458723c66c2fd717a112f89f773226adc841
Added suggested change of DoSaveForVisualControl mechanism
Change-Id: I28901e7a0b6e1823000d2aa6a335ce2fd80e6ce3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139585
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Jusify() normalizes the rectangle so both the Width and Height are
positive, without changing the location of the rectangle. It ensures
that the x and y coordinates will be moved to the top left of the
rectangle.
The name is strange, so renaming Justify() to Normalize().
Change-Id: Idbf163e65e52a798e38f785b8961b8042cf0cf2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137379
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I34de7408553e4ca702cab9aa611c03dc60b9b6a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138472
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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: Ie091b22bd77d4e1fbff46545bc86c12f1dbafcfe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138171
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
make the plugin more conservative, so we see less false+
(although we also miss some possibilities in the process)
Change-Id: I91b1806271e7f802d7459834ab7bcc569047da3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137342
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|