Age | Commit message (Collapse) | Author |
|
Change-Id: I8acfaceea2b0f88d5783ef864c294c048f0ab3e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93519
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This is the import side of commit
1392fd6a7eaf9f507639096984c2a0108f254795 (sw reqif-xhtml export,
embedded objects: handle Ole10Native stream, 2020-04-30).
Change-Id: Ib98620f06c471a58e75b0e6c0230d37820dbc928
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93402
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I7ac5ccb356501983da645f0a6037b5292ce8b5b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/20207
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Jenkins
|
|
ARGENTINIA->ARGENTINA
Change-Id: I711f775c1296779630e99e8cfc6db0262afa47ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92941
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ic97b1a4507d5629963f360147ecc20eb10f5d391
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92957
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3bfcc6fedb782b12be1fb1d42981756287f29f82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92956
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If2473097c1c8e66e09238061da9d186d4c8e3d9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92871
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Flash technology is going to be retired by the end of 2020 by Adobe:
https://theblog.adobe.com/adobe-flash-update/
With this ahead doesn't make much sense for LO 7.0 to support exporting
presentations and drawings to swf anymore.
Change-Id: Ic2c6e95db2f56bcd4eb25abdd0a6748aee9b0e4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92507
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Make it clear that this is not "OOXML Strict"
Change-Id: I025e982c12e66a3088ce9ee093382df02a88ff9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92375
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
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>
|
|
In some cases at import there are extra space separated
numbers at the end of the names of arrow objects.
Remove these extra numbers before they could interfere
with the choice of markers.
See commit 2d3b7a07c02c90d2d64a630ab84886ef3096edfc
(tdf#100491 fix DOCX import shape line with arrow marker).
Co_Author: Balázs Regényi
Change-Id: I2156502b0ce5cd755a731359398a40edabb603a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91375
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
We already write markup which is newer than 1.5, but the PDF version was
not changed. Fix the one violation I'm aware of.
Printing is left unchanged, similar to how commit
99ac4ee05b039166eedfe361fb985682fd92dd13 (Change default PDF version to
1.5, 2018-04-24) updated the default last time.
Change-Id: I9598dc46fe7db428bd2eff98bebff8b3c873b4ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92457
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
ie. where left > right or top > bottom
These are all places where the code is self-evidently doing the wrong
thing.
Found by adding asserts to tools::Rectangle. In theory, this is legit,
and code that wants a proper Rectangle is supposed to be first call
Justify on a Rectangle, but lots of places don't do that, and that seems
very dodgy to me.
So lets work towards Rectangles always being in a valid state.
Change-Id: I03296a624bd9b5b193e6aa8778addfb09708cdc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92310
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iac753e528e13cb2565832a484e87f88061bbc91e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92239
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7f5201e2ea6c74329336e16bf219630e38ff92cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92264
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I24861f7401c0046962d536950fe8b2b6bdbad969
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92186
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There is no need to hide std::shared_ptr<VectorGraphicData> type
under an alias name. It doesn't make the code more understandble
and it usually is the exact opposite because we know with what
type we are dealing with.
Change-Id: Iec80ee99697ff2fe3a8275fc2787b5370510ebe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92069
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I227e304c6868afe7a98dbd8e96487270d06ce1eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92067
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
as preparation to have drawinglayer module
independent from vcl in the future
Change-Id: Iaa01370f27b51cba5114a54f37d1ec73d0719918
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92048
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
The line shape itself didn't really have a height, rather it had a
stroke. For some reason, the SVG mask then decides that nothing has to
be painted there, so unless the line is entirely opaque, the line shape
gets lost on export.
Fix the problem by handling transparency similar to the PDF export,
which detects if the whole purpose of the transparency gradient is to
pass around a transparency percentage. We don't need a mask in that
case, we can just use opacity as described at e.g.
<https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/opacity>.
Change-Id: I0355b9b09b6dd48bbacc5b7cc54fb71866304ef1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91932
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
a particularly aggressive checker, which is why it is off by default
Change-Id: Id5a0faa50b3ecc75e01f4aedc6579c5209e585da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91643
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
broken by...
commit 6909838e2966b3fd3c2de6b6db70d952cd8b3114
Date: Thu Apr 25 18:08:33 2019 +0200
Fix typo
Change-Id: I40ee245faa75c885d76299ddee79fdaca9d0d715
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91233
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I4897a6f2622e3e219f8b7b93d818d2edca03b117
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91008
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Moving PDF to use VectorGraphicData in Graphic has temporary
removed the support for showing different PDF pages when opening
the PDF using pdfium (LO_IMPORT_USE_PDFIUM=1).
This adds the support for back by specifying whcih PDF page to
render when creating the VectorGraphicData (and can't be changd
afterwards), which is used to create a Graphic and contains the
PDF source data array.
Change-Id: Ib915216b8d4c0c063d0fead44ff156b1915a35d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90562
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
In principle, the current Svg/Emf/Wmf and PDF handling is trying to
achieve the same thing: Keep the original stream untouched, provide a
replacement graphics, and a kind of rendering.
To hold the data, the Svg/Emf/Wmf and PDF were using different structures
though. This commit consolidatates that, and makes the Insert
-> Image... (for PDF) actually using the VectorGraphicData to hold the
original stream.
This breaks loading the PDF as a document via PDFium - I'll fix it in
the next commit(s).
Change-Id: Iac102f32b757390a03438c165e430283851cc10b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90561
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I5d53e6369d35093445b2efd8936bbf8c6775ff47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90451
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
See tdf#130911 for motivation.
Change-Id: Iad0960d5e6298236dea57e37930dfad1f13628c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90127
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
...plus ensuing -Werror,-Wunused-const-variable
Change-Id: I1a22c7e3ddaad50b27ad311bce165141d30491e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90199
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3fd06ddf1548c1d6b5d8e91db944d2c720040718
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89873
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9b74ac9e8c0fa679624bed2e184a161a8f48b641
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89630
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Writer shapes are implemented using SwXShape, Impress shapes use
SdrGrafObj. So switch to working with the XShape interface, which is
supported by both.
Also, don't work with the transformed graphic if it has the same
checksum as the original graphic: the transformed graphic is not linked
to the original JPG/PNG data.
Now selecting an image in Writer Online has the same speedup that
Impress Online already had.
Change-Id: Iab2791c5f5c7a2754e3de0ebb2d6ea664f6c77e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89540
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This has a number of benefits:
1) For a sample JPG photo, the SVG output is now 4,9MB, not 20MB.
2) Even the first export to SVG is fast, see commit
570be56b37e4ff105649e604ff4c8a6c368e2e79 (svx: cache PNG export of
graphic shapes, 2020-02-25) for exact numbers.
3) Allow using less memory as the SdrGrafObj doesn't have to store a PNG
result till the document is closed.
We still require matching checksums, so in case anything problematic
happens with the bitmap (grayscale filter applied, etc), then the
optimization is meant to not help, but still produces correct output.
Change-Id: Id3bc359a8dcc4c4d12d3b66ffb512cfa71939a26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89419
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
One scenario where this is useful is: manipulate a JPEG photo in
Online's Impress, e.g. resize it multiple times. Each time we generate
an SVG preview of the shape, which includes the PNG export of the bitmap
itself.
This helps with a desktop CPU:
debug:9976:9974: SVGFilter::filter finished in 3422 ms
debug:9976:9974: SVGFilter::filter finished in 176 ms
But it is meant to help on mobile, too, where writing such a bitmap as
PNG takes 16-17 seconds without this.
(This works because SVG writes the original bitmap, even if it's scaled.
If that invariant will be broken in the future, we still emit correct
output, but then the cache will be less useful.)
Change-Id: I7204b04efeeb42c6eec67f04dfdb8a4ed50443a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89377
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
to complete:
https://gerrit.libreoffice.org/c/core/+/89082
Change-Id: I8363f05f15c8d4ef032ccc8d469dc29231d74ca7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89360
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...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>
|
|
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Files which could become clang-format conformant with
under 5-percent lines of change relative to the total
count of lines in the file are found by using bin/find-clang-format.py,
and fixed with /opt/lo/bin/clang-format -i <path-of-the-file>
There will be follow-up patches to fix all 'under-5-percent' files.
Change-Id: I702c09bcd3a9a113b3d66c30edb6cf3b7e6a6593
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88776
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
Change-Id: Ifa384933569b27d0d08eb479bb95b799163ae386
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88450
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2c06b12c958dfde09adcc2ae4c59532ffde6b6fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88127
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I6ce3a3dbe71df1d3f56279879e3f91bd7c82f784
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84687
Tested-by: Jenkins
Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
|
|
Change-Id: Icd90eeb492002c45ddd8ff562a6da411abead122
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88185
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id56901a6bf4da7bc8fbdcbcc811f6afb2121fe07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88015
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id16c1fe3fef0149a881f0ea684141e4e198892ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87999
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iaeb3c17fe157dec82cd70991122c08ee1e215752
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87955
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id64855e3879d21106930a4dc9c36b246deb3c6e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85818
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
cid#1458018 Untrusted loop bound
cid#1242844 Untrusted loop bound
Change-Id: I9062240290708f4b51b0ce42a30897b50d1a2677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87702
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: If658720502739e6ad88c3cf73ac6674e0313a48b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87648
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
I checked return values.
Long variables didn't affect the calculation.
Change-Id: Ia3713eedf275de71b1096d1fe7e22da012a7f94e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87493
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|