Age | Commit message (Collapse) | Author |
|
By default Rectangle uses closed interval, if we really want to use half
open intervals then we should specifically say as such in the name.
Change-Id: Id7a91120ba1a1a4bc330014216b73a692dbf03a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136575
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
regression from
commit 3cbe3a0259bea4dec70e72191ec3c03441926a07
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Jun 14 15:05:59 2021 +0200
tdf#101083 speed up SVG rendering with pattern fill
Change-Id: Ifabe5dd0de92c3b27033c49af5713bc5825d10c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136912
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifcefc082a007ebae2c44cccc15a475d73b6bf64d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136628
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I45fc0a7a024a4288f698eb5f0abf6b0d1440edfc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136561
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I9fae1d259ecdca37a1babac8a8a0e503b2dc0118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135960
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
React/interpret new SlideBackgroundFill mode for SdrObjects/
XShapes, defined by drawing::FillStyle_NONE and usage of
XFillUseSlideBackgroundItem as (true).
Do so by adding a detection, a mode to SdrFillAttribute,
reacting on it by creating a new implemented B2DPrimitive:
SlideBackgroundFillPrimitive2D provides a Primitive2D for
the SlideBackgroundFill mode. It is capable of expressing
that state of fill and it's decomposition implements all
needed preparation/creation/collecting of the geometry
in an isolated and controllable space and way - the
B2DPrimitive way. It does so based on the given
ViewInformation2D, reacing out for all needed data/
geometry from this.
It clips & transforms/combines as needed, providing the
necessary visualization of the MasterPage content *over*
other objects on the Page/Slide. It is currently simple
buffered (due to being derived from
BufferedDecompositionPrimitive2D) and detects if
MasterPage changes. Still, more may be needed.
Change-Id: Ie11403c0b705fc2ecdfd7eb2fa5ae1a93a21b460
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135971
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
and
cid#1506307 Big parameter passed by value
Change-Id: I7386eeea04f73a4ec9fe0fe09ff2981b2022be89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136079
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic593974a44d9e327e0385c7ffaaa6d42576ae01a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135911
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8a3245c6a4d687edbc95cf28b2932d80c86a7b65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135828
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
With previous implementation, the EMF+ import is calculating
gradient positions wrongly. It is causing warning:
SvgGradientHelper got invalid SvgGradientEntries outside [0.0 .. 1.0]
and the gradient was not displayed at all.
This patch fixes that and gradient is displayed correctly
Change-Id: I6229c516165436d0c7ae187d9eb69b5494da396f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135607
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
look for local variables that can be std::move'd to parameters
off by default, since it doesn't do proper data flow analysis
Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Glow effect creates half transparent pixels on shadow. Creating 1-bit
B&W bitmap mask treates that half transparent pixels as black.
We control 1-bit B&W bitmap creation when we have half transparent
pixels.
Change-Id: Iaf298a0e5ffeeb6637fe5d3f56cf4f8e30a203e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134981
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
|
|
Change-Id: Ie3945d3a2e133d3ce527844f9c0d61a6541175e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135200
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ide40a08f70cbb30a4f18c496d986feb78e5dfa1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135103
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icf5a3ae47aec43854e669133f3d0c2bace1d942d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135090
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which we can std::move the data around, instead of copying
Change-Id: Id7aaad3970b942599807b7fda73d028f082a0f38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135089
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and save some copying
Change-Id: I34cbc2edfd53fcc440d1765dba471fcbb05b2b7b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135088
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
instead of Primitive2DContainer, because I want to change
Primitive2DContainer into a different data structure that
does not support cheap random access
Change-Id: I1bc55f2e21d9d5c4529c87be57a46aee63e04589
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135087
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(*) we can move the data rather than copying
(*) it should definitely not be const
(*) we can use STL functions to do most of the work
Change-Id: I02b4cbbdeed0588d592f24942d31608f2119561c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135083
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...where a signed and an unsigned value are compared, and the signed value has
just been proven to be non-negative here
Change-Id: I20600d61a5d59d739bc1bee838c0038e4611aec2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134875
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iae7e83253cfe7c0545d2381d83a2e69cb4b80e5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134376
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With this commit EmfPlusDrawClosedCurve and EmfPlusFillClosedCurve
support was added. There is still missing Filling Mode (it
is always set to Even Odd Alternate:
https://en.wikipedia.org/wiki/Even%E2%80%93odd_rule )
and Tension support for spline bends.
The graphics is displayed as Tension=0.
A value of Tension=0 specifies that the spline is a sequence of straight lines.
As the value increases, the curve becomes more rounded.
For more information, see [SPLINE77] and [PETZOLD].
Change-Id: Ibccfd584e3d55cd0ca8a29da9f450916d56705d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134333
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: Ib0913aef00cd252d3f082ec5e8b39064df63a7fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134319
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
With this commit the Miter is properly implemented,
according to [EMF-PLUS] documentation:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-emfplus/5ef071f3-f503-4f16-b027-7c4bcf2d1d81
The formula for stroke miter limit is described here:
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-miterlimit
Change-Id: Ida87063cc045460e61ffae118f64cf133c810dbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134164
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
EMF+ is allowing different caps and arrows on both ends
It is not possible to implement that with css::drawing::LineCap,
as it is set line endings on both line start and line end.
Additionally when the Dash Pattern is used, the css::drawing::LineCap
is also applied there.
To resolve that limitation, the Cap needs to be implemented
independetly by using PolygonStrokeArrowPrimitive2D, and
the css::drawing::LineCap inside drawinglayer::attribute::LineAttribute
always set to css::drawing::LineCap_BUTT
Change-Id: I4be76e2dbefcb34154a1404c3b57dc4b7f7ada85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133299
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
If the lines are created with MOVETO, LINETO, LINETO...
then Line Join NONE is applied. As a result the charts are looks ugly,
with the holes inside it.
For example:
https://bugs.documentfoundation.org/attachment.cgi?id=179962
and
https://bugs.documentfoundation.org/attachment.cgi?id=179837
Additinally commit changed default line join style to miter,
as during experimenting with MS Paint and MS Word,
it appear that default Join Style is PS_JOIN_MITER and
Line Cap is Flat/Butter.
The PDF export tests has been updated, as there is less number
of PDF object after using joiners.
The size of the exported tdf145873.pptx to PDF,
was slighltly decreased from 22.8kB to 22.0KB
Change-Id: I131cc3c5e90f827d67d2360eb18167eed6315abb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133624
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I64b48e60f178574a0e0382e72a002a87320bbf39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133972
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4462f7cf4740fa4d1b129d76a0775f4250f41bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133555
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...by annotating occurrences of false warnings with [-loplugin:<name>] comments
in source files and letting individual plugins opt-in to watch out for such
suppression annotations, rather than maintaining lists of excluded source files
in the individual plugins. (See the new loplugin::Plugin::suppressWarningsAt.)
Instead of making all calls to loplugin::Plugin::report check for suppression
annotations, the intent is that this check will only be added opt-in to those
places in the plugins that are prone to emitting false warnings. In general it
is better to have plugins that don't produce false warnings in the first place,
or at least let those warnings be addressed with trivial and harmless source
code modifications, avoiding the need for any suppression mechanism.
As a proof of concept, I have removed the exclude list from
loplugin:redundantfcast and instead annotated the relevant source code. (And
thereby found that three of the six originally excluded files didn't need to be
excluded any more at all?)
For now, this mechanism looks for comments (both //... and /*...*/, even
documentation-style /**...*/) that overlap the current and/or the preceding
line, because at least for code controlled by clang-format it is often easier to
move comments to a line of their own, preceding the commented code. Looking
also at the current line (and not only at the preceding one) opens the door for
erroneous over-eager annotation, where an annotation that was meant to address a
false warning on the current line would also silence a potentially true warning
on the following line. This probably doesn't cause much trouble in practice,
but is up for potential change.
Change-Id: I91ce7a0e5248886a60b471b1a153867f16bb5cea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133365
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
With this commit, the types of variable for Brush and Pen
were aligned to documentation:
[MS-EMFPLUS] - Enhanced Metafile Format Plus Extensions
As a side effect the code was simplified a bit
Change-Id: Ibabad628d0aaef510f61ee8b3d881c3f024cebef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133327
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Previously when TranfromationMatrix was used with rotation,
the line weight and dashed line shapes were changed.
In worst case if angle was larger than 90 degrees,
the lines just disappear.
This patch fixes that. The line looks exactly after rotation
(with TranfromationMatrix).
The tests were updated (added some additional rotation),
to prove that now it is working correctly.
Change-Id: Ic2382fa8d1b711a6bf06c94b2d0b9da9e7d396f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133329
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
With previous implementation, empty spaces between dashes
were too long.
Additionally line joints were not working correctly, after
EMF+ reworking: tdf#111486
This commit fixes all these issues and additionally it is
covering it with tests.
Change-Id: I9404e566d2d7d3405ab817268ad9b1f538c200eb
Change-Id: I523f92a928ab592ff175d0d01c1ad1a3bc22e324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133207
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
* Fix typo
* Improve links
Change-Id: Ie77ec795675bf7497c90620eb44ebb3191c003b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133067
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
* Add information on dumping drawyinglayer primitives as xml
* Add link to a new tool named limerest on gitlab
Change-Id: I50a0018d9c3063281b2a761d437bb9def0f34bde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132936
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
With previous implementation the clipping restoring with EmfPlusRecordTypeRestore
was implemented wrongly as it is only taken to account
the shape of clipping (state.getClipPolyPolygon) and doesn't
take if clipping was even enabled (state.getClipPolyPolygonActive).
Additionally the changing states should be made by using method:
wmfemfhelper::HandleNewClipRegion() and not directly.
The similar implementation was applied also to EmfPlusRecordTypeGetDC.
Additionally the clipping for
EmfPlusRecordTypeSetClipRect
EmfPlusRecordTypeSetClipPath
EmfPlusRecordTypeSetClipRegion
was fixed, as initially the clipping is disabled (state.getClipPolyPolygonActive)
and the clipping shape is empty (state.getClipPolyPolygon).
It means that combination other than EmfPlusCombineModeReplace,
was not working correctly.
With this implementation, if Clipping is disabled, then treat clip combining
in special way.
Change-Id: I258bda64e8bfdade7f47ffc7518bf04b7340344f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132415
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
It had a random(?) hardcoded '2' as the dashing info. While at it,
I've also made few other places use the common implementation
of creating the dotdash array instead of doing it manually.
Change-Id: Id349ca138c98d08eef47dc0bfe6d162e03fc4a9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131932
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
look for potentially trivial destructors that can then be elided
Change-Id: I435c251bd4291b5864c20d68f88676faac7c43fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131318
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
LIBREOFFICE-OWMTGGWJ
Change-Id: I68dfcb0dcbb401c62d4e29f9ab6e4ee1ebc7f072
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130973
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
LIBREOFFICE-311XVJ95
Change-Id: I159f516daafad3e4088677fe2c8c6f5423b3e264
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130666
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
because there is no check to see if the preview changed here.
But because (bizarely?) Graphic::operator== returns true when the lhs is
an empty graphic regardless of the rhs due to:
bool ImpGraphic::operator==(const ImpGraphic& rImpGraphic) const
{
///
switch( meType )
{
case GRAPHIC_NONE:
bRet = true;
break;
...
}
return bRet;
}
don't use that and instead just compare if the graphics contain
something or not which is sufficient for my needs
Change-Id: Ia3266e289b3a42ee30bdb9523bac29fb73f5e341
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130545
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
1.4142... -> M_SQRT2
0.4142... -> M_SQRT2 - 1
3.1415... -> M_PI
2.7182... -> M_E
Change-Id: If5b19aa38d9902b1a4b717f89f18bdf2f73a47cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129745
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Ib4c7176d046a86ad22d57fc8789cd53e87859076
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129346
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is similar to the previous Cairo commit. Fetching pixels
from the GPU is not as slow as fetching them from the XServer,
but this still can make a visible difference. And small surfaces
should not need fast GPU rendering that much, so hopefully this
improves more cases than it regresses.
Change-Id: Ida031b38cd1ce14ded464747c20a38c6d094c5a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128310
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The (private :( ) document contains a large number of small shapes
for which VclProcessor2D::RenderTransparencePrimitive2D() gets
called, which results in GetBitmapEx() on the VirtualDevice.
And Cairo normally needs to do a roundtrip to the XServer to fetch
the content, which makes the rendering pretty slow. Forcing
image-based surface for small sizes of VirtualDevice actually has
better performance for the document, and the lack of possible
HW acceleration generally shouldn't matter for a surface this small.
Additionally drawinglayer's VirtualDevice reusing tries to reuse
even a large one when a small one is needed, so a hack is needed
to avoid that in this case, I couldn't find a better way.
Change-Id: I0f58659ab88165a6bd915f100fc3b1d4802a0fa9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128309
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
... resulting in a stripped-down, Writer-only build to decrease
the resulting WASM bytecode size.
It removes the following code from the build:
* All other major modules: Base, Calc, Chart, Draw, Impress and
Math and related writerperfect filters
* The premultiply tables
* The (auto-)recovery functionality
* All accessibility (but not the accessibility document checker)
* The LanguageGuess component
* EPUB support
* The start center / BackingWindow
* The TipOfTheDay functionality
* The splash screen communication
Currently crashs with anything different then soffice --writer.
Closing the document also still crashes.
FYI: many of these features are now behind ENABLE_WASM_STRIP_*
defines, but they normally don't work on their own, globally!
That's because we started with stripping the main components.
Change-Id: Ib9c0f9452815910c0a2aceaf142ba1ad4a9cb0d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126182
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
See tdf#42949 for motivation
Change-Id: I916f42c46efa1b6cfd7744a189b79659b2867431
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128196
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ib16c742b39af62694ef591dcdaa975b9a720b4a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127203
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
This patch is an extension of https://gerrit.libreoffice.org/c/core/+/127734 related to comment made by Mike Kaganski
Change-Id: Ia7a6480dba2a0752a52ae4f9655c345af9f3ba64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128134
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I922778e8ced0ad922d90a153b0eda47abbec94ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127868
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9674eff3e2572ffef7ee19af12befc8a9b6b1c06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127734
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|