Age | Commit message (Collapse) | Author |
|
Change-Id: I88b25dd676fc57303978e3d5e875af129240b676
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157762
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: If228639806c49d77d1c1a36a8d536992e1402896
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158144
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I091b68bbeee74452a3d6a03711cfc482b7a78e1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157685
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I93b8225b7ae2fdb4ea5fc371ce278f00d3dec33f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157356
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
These shaves 20% of the time of the construction of the "drag view"
object. Of course, it is still heinously slow.
Change-Id: I4c6ee2d7e0cc2030a9966a281d2fdbe7f6859289
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156896
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Drawing with 'mouse as pen' in a slideshow creates hundreds of points.
By commit 631964a2ce1da3fbbeb53a5550c0e6728ba644aa they are at least
already combines to a polyline. The patch here now reduces the amount
of points in such polyline to a reasonable number. If at some point the
drawings in the slideshow are improved, this can be removed.
The reduction is performed using the Douglas-Peucker algorithm. I have
added the method to b2dpolygontools because I think it could be useful in
other contexts.
Change-Id: I9224ec3546d4442da8bc348aea8ce7b88fcc46dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155811
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This is needed because the module dependencies are an issues if
the conversion is done in basegfx. The bigger issue will come when
the ComplexColor conversion will be done as basegfx can't depend on
docmodel because of circular dependencies.
The BGradient is also more suitable for docmodel anyway as the
previously it was part of the model and is not a basic (gfx)
type - however this doesn't move the whole BGradient into docmodel
yet.
Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Iac66822757814d67383f6e19f3ab25e3dc7f8b0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155085
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id8811e65227142881fc86f6d2db231fa053fc2d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154768
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I2c96b367138b94d6178a3c4a0f83049f13a04f82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaf7d02bb236f81a38a67a1430a718b6c3c78efae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139708
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I1dff65963e2c414d1771a1592159930150c513e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154241
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
So when a green matrix is used, everything becomes green.
Also set alpha to 1.0 so at least a green matrix on black returns
green and not black
Change-Id: I9104c7511545fb244750b066bb1e996b6ce229f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154167
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Iee554baae7239c9bf0ac35cab6ff235a88dc29a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153973
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 75399b8aad6c0f0998b9d0a6eddb2e29f8bc114c.
it was incomplete.
While at it, do not parse 'in' attribute for now, so only
in="SourceGraphic" is used.
Implementing the 'in' attribute is not trivial
Change-Id: I66c721c1144638f5e3759e0aa3a1c2c062499a90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153627
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I7258443036eb89e7a67fce2a683f3212972a7395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153565
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I8feae2447b17e15113ca45fe46c0d68cb6b6ab71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153550
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I35193c68034e5500f12a2e474886c6aa9c2307ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153457
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Icc172c5f47731ddcf0beca64c72c2022313e74a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153177
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I9c7ada2908c0739708fbc9e28ac58430350da7a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153112
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Add tests for BColorModifier_luminance_to_alpha and
BColorModifier_saturate
Use basegfx::fTools::equal in B3DTuple::operator==,
otherwise some asserts fail with
- Expected: [0.3575, 0.8575, 0.3575]
- Actual : [0.3575, 0.8575, 0.3575]
Although they are equal
Change-Id: Iad6d9ff78a390f5ee2a3e33e479e34d98e751b2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153394
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Ibdbe9c55220239f4b8458742ac5625c002963217
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153390
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Rendering of stepped gradients uses a method that doesn't take the
color from a cut point, but before or after respectively. For example,
for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1
are used. So sections are 'start color', '1/3 color', '2/3 color' and
'end color'. The output to OOXML now uses the same method. That way
rendering in a produced pptx-file is the same as in the original
odp-file. Since OOXML has nothing similar to StepCount, it is an export
only problem.
A second problem comes from the cuddle with StepCount in Gradient
struct in API and FillStepCount in shape property set. The
draw:gradient-stop-count attribute in ODF belongs to the graphic style
of the shape. The gradient definition itself in the <draw:gradient>
element has nothing about step count. When a file is opened, it can be
that the StepCount component in the Gradient struct still has the
default value 0, but the FillStepCount property has the correct value
of the shape.
The Gradient struct in the API should not have a component StepCount
to be compatible with ODF. But the API is published and changing that
struct is far-reaching in the code. So the fix here is not a general
solution but solves the problem for export to OOXML by reading the
FillStepCount property while exporting.
Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
While synchronizing color and transparency gradients two new sequences
are generated. In case the last offsets where different, the remaining
stops where not copied to the new sequence and thus they had different
sizes which triggered an assert in oox/source/export/drawingml.cxx.
Change-Id: I446f8cfafb23735f06ad4e05eee8c922141b864d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153063
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Add getModifierName to BColorModifier class so when
can assert which modifier is being used
Change-Id: I2bc2a36470a449df4dc84a8440f232149c1f8278
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153048
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I7c75593fef6d3226011a938349850dc485b763c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148204
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: Iaebe55927771985a6b574b2cb9410b0eb75441e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152789
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib02cc0e9aaf286d8c39523ea352cfeec17a6336f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152788
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Unfortunately SVG export is based on metafiles and thus there
is (in principle) no way to get the BGradient/ColorStop/MCGR
data transfered as needed. For that, using UNO API to read the
model or using B2DPrimitives would help - as is better for the
export respectively.
Since there is not the time to re-design SVG export I added
this 'compromize' as a fix. It gets the needed data transported
over the metafile (that part is the compromize). It then
exports the MCGR data to SVG (at least - as was already there -
if it's a linear/axial gradient). This happens now with all
Gradient Stops when there is a MCGR gradient. That part is/will
hopefully be re-usable if SVG export gets redesigned.
I also added a handling for StepCount feature, so when used (in
LO, others do not have that) 'hard' color stops get generated
to make the gradient look identical for SVG export.
Had to make adding of that extra-information in metafiles
dependent on exporting really to SVG. There are 51 cases which
use 'MetaActionType::COMMENT' which would potentially have
to be adapted.
Also added code to solve the problem for TransparencePrimitive2D
at VclMetafileProcessor2D::processTransparencePrimitive2D. This
will now - also only for SVG export - directly create the needed
MetaFloatTransparentAction and add additional MCGR information.
This will be used on SVG export to write a 'Mask' as was done
before. This is now capable of creating fill MCGR-Masks in
the sense that any number of TransparencyStops will be supported.
Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I8f68ecc7ccaecf84abbcda1bcdd65e2295baaf0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152673
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
When exporting a shape with an axial gradient fill to OOXML, it is
converted to a linear gradient with multiple color stops. Versions
before MCGR had recreated it as axial gradient on import from OOXML.
But now LO is able to handle multiple color stops and so the linear
gradient from OOXML is imported as linear gradient in LO.
When such file is then written as ODF, the multiple color stops are
in elements in extended namespace and versions before MCGR do not
understand them. They show only the first and last color (which are
equal) and the gradient is lost.
With this patch LO converts the linear gradient back to an axial gradient
on export to ODF. The exported axial gradient is rendered in a version
with MCGR same as the linear gradient when opening the OOXML file. The
difference is, that versions without MCGR now render an axial gradient
with two colors.
Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I650a8fcefd179937bdcbb6088658aa960008794d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150834
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Due to tdf#155362 I added code to be able in case we
would need it to convert a BGradient using added
tooling from having offsets in the GradientSteps
and no border to adapted GradientSteps and border.
This is preferrable due to our GradientStyle_RECT
(and GradientStyle_ELLIPTICAL too) use that 'non-
linear' paint aka move-two-pixels-inside, someone
else called it 'frame-paint'. This does not bode
well with the border being applied 'linear' at the
same time (argh). Thus - while in principle all is
correct when re-importing a GradientStyle_RECT
with a border after export to pptx, it looks
slightly better ('correcter') wen doing so. That is
because when being able to and restoring a border
at least that border part *is* applied linearly.
I took the chance to further apply tooling, move
it to classes involved and instead of awt::Gradient2
use more basegfx::BGradient since it can and does
host tooling. This is also a preparation to be
able to adapt (restore) border in case of turn-
around in ODF where the importing instance is before
MCGR existance and has to handle Start/EndColor.
Needed to take more care with using BGradient instead
of awt::Gradient2 for initialization, also better
dividing/organization of tooling, already preparation
to use for other purposes.
Change-Id: I2d3a4240a5ac6fff9211b46642ee80366dc09e3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152194
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ief95f111350808f010539bb733a553007d30a9df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152006
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Added code to make WriteGradientFill directly use the
available BGradient implementation. The goal is to
never directly work on awt::Gradient2, but use
BGradient & it's tooling methods.
Added constructors and tooling to BGradient and
BColorStops to make that easier (single line
conversions between uno::Any, basesgfx classes
and awt:: incarnations). Directly handle uno::Any
and awt:: classes, changed stuff to make use of
this.
Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
since we know that this is a matrix only used for 2D transforms,
we know that the last row of the matrix is always { 0, 0, 1 }.
Therefore, we don't need to store that information, and
we can simplify some of the computations.
Also remove operations like operator+ which are not legal for
such a matrix.
Change-Id: I482de9a45ebbedf79e3b6033575aab590e61c2d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151909
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which is 10% faster loading this document
Algorithm copied from https://github.com/niswegmann/small-matrix-inverse/blob/master/invert3x3_c.h, which is CC0-1.0 licensed.
Change-Id: I7aa272cae90b1aee30eb6b3e8e5acb260b92ceef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151830
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id590b13237bc148dac955d6f4d56092f86d1dd16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151817
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5701a1fdfe9e4f139049ed6c0de1748ec7c06e07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151816
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
instead of using COW for its data.
This takes the load time from 1m29 to 1m12
Also fix a bug in
ImplHomMatrixTemplate::operator=
which never triggered before because the usage
of o3tl::cow_wrapper means it very seldom gets used.
Change-Id: Ib0a7bdddf6c014f583e06d15e8dce5025e67e4a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151793
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Adapted handling of 'border' argument from our gradients
for oox export, so that it looks the same.
Also added quite some cases to peserve in-between
GradientStops for current UI implementations to be
able to edit the gradients as usual without losing
the in-between GradientStops.
While we will not be able to modify these, we are
at least able to modify all the other gradient
attributes, including start/endColor.
Done this for TransparencyGradients, too.
Also moved more stuff to the gradient tooling in
basegfx.
Change-Id: I6e94011bbf3715baa1401ab97e5b59811298342f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150577
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I7f8fa704199865e67c0543f92f89f63765c8c2ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150406
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Idb607f8d35163de55e29415efe8a3cfb029eb9e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150403
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I2b087d0f97c675cfedd4e2e78c7f827df4605fb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150407
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This is a 1st version and might need more fine-tuning,
so it is still 'hidden' behind the MCGR_TEST env var
being set (as the import is, too).
Still, when used, it can now import a MCGR with
transparence and export it again. I will now do extended
testing/experimenting, fine-tuning where needed and
prepare final change/drive forward.
The current state in master should not be changed as
long as the mentioned env var is not set, but this
will need to be checked, too, due to changes to the
export api in oox.
Corrected an error in GetAlphaFromTransparenceGradient
method(s), css::rendering::RGBColor is [0.0 .. 1.0]
Corercted an error in WriteSolidFill where transparence
gradient gets checked. This should really check if
TrGr is used, but only checks for 'empty/unused'
color instead (assuming COL_BLACK is 'unused').
All usages of GetAlphaFromTransparenceGradient should
be checked and adapted.
Change-Id: If59d7a06b9207e2efe9e71f3f8ddeca4476408f3
Change-Id: If97f8abdd0e1597aa1fd865b7e884e06a22b71f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150391
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
The colors of a ColorStopRange can be equal in case of
hit *and* miss, so in both cases. I moved it to the
common computation part. Prev version worked and did
no harm, but unnecessary color interpolations for equal
colors.
Change-Id: I19031f1021ee5955b48da5c0d8e3a03cb9512ebf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150046
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I4ff8556c954cae844fa35385535cf9b6e9477e08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150033
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I09163a500caf66c6ac2921dca3128997574d20d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150032
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I20b32e7c272112c6c3d9f7ee0ef59c6d4d006d94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150020
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|