An odd-length array will be drawn as one dash spanning the entire path.
The specifications under
https://www.w3.org/TR/svg-strokes/#StrokeDashing state: "If the list has
an odd number of values, then it is repeated to yield an even number of
values. Thus, the rendering behaviour of stroke-array: 5,4,2 is
equivalent to stroke-dasharray: 5,4,2,5,4,2."
Change-Id: I8f233c4cec5c85f5ab1096b032cbb8743715f14d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211062
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Tested-by: Jenkins
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[d-g]*
This shaves off about 150M input
Change-Id: I2b15257451d4b392dca3e5d07f4a443ee653b04c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196395
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Up to now these needed to be decomposed to be
rendered and did not support animation. I already
added animation, but that was a compromize.
Done that now in the correct way, so that animation
is possible and can be directly rendered using
a FillGraphicPrimitive2D if wanted, including one
extra layer of alpha, too.
This will also enhance other primitive processors,
but of course most those that do handle that now
directly, so CairoPixelProcessor2D does that.
Note that it does not need to support animation
in any way (that is part of the primitive stack),
but just direct tiled rendering.
Change-Id: I8860098dfb3f2369e361579cf1deea7c67b662b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170937
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Detect where created when a RGBA gradient could be
used directly and create a primitive representing
that, a PolyPolygonRGBAGradientPrimitive2D.
That primitive decomposes to what was created before,
so no primitive renderer has to be touched, all will
work as before.
NOTE: That helper primitive just holds references to
what would be created anyways, so one depth step
added but not really any additional data.
This is the 1st step for direct support, the 2nd is
to then detect and use that primitive in SDPR
implementations directly.
Change-Id: I4f247636ce58a8a1fd1e0df32dabed0d6cc10d0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170527
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The ticket had a pptx with a:
<a:blipFill> <a:stretch> <a:fillRect ...>
Impress loaded the fillRect as a crop, but never used.
Implemented a crop in
SdrFillGraphicAttribute::createFillGraphicAttribute
because in the case of stretching, it blindly used the whole picture.
Cropping data was not available there so it is copied
into OffsetPosition, and Size
Change-Id: I195cc40a35dc24c708e7c0e3cdbe40d6e47b8ce5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168391
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Introduces RectangleAlignmentItem that holds a value of the enum
model::RectangleAlignment.
Introduces SDRATTR_SHADOWALIGNMENT that holds alignment for a shadow.
Implements import of algn for outerShdw.
Makes the alignment considered while the shadow is being scaled.
Also adds a unit test that covers this.
Change-Id: I8f4eaed5f0d9428a7f405c65f19237f9e70ca151
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148934
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@collabora.com>
Also simplified using the test cases, these now depend on
an ENV VAR called MCGR_TEST. Fallback is no test. For
seeing a multi-color gradient use 1, for Case16 use 16.
If active, all gradients are replaced with the one active
for the test, 2D and 3D. This is temporary but also for
pro build to check for speed there.
Change-Id: I90f3c7e59d9d0a3e070a849af3f9ea1c9e5462a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149316
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Added tooling replaceStart/EndColor to allow simple
transition for code that does not immediately adapt
to multi color gradients. Also added
createColorStepsFromStartEndColor for the same
purpose.
Adapted XGradient to no longer have Start/EndColor
at all, but only use ColorSteps.
Adapted all usages of XGradient to no longer use
Get/Set/Start/EndColor, but access the ColorSteps
instead.
Replaced quite some XGradient constructors that
used XGradient() as Start/EndColor since this is
already the default.
Adapted ColorBlending to black AKA Start/EndIntens
in XGradient to work now on all ColorSteps in the
required linearly-scaled manner.
UNO API changes:
Added com::sun::star::awt::ColorStep as basic data
element that holds a pair of Offset and Color.
Added com::sun::star::awt::ColorStepSequence to
handle an array of sorted entries.
Added com::sun::star::awt::Gradient2 derived from
com::sun::star::awt::Gradient, extended by the
needed com::sun::star::awt::ColorStepSequence.
Added MID_GRADIENT_COLORSTEPSEQUENCE to UNO API
to provide access to ColorSteps directly.
Adapted XFillGradientItem::QueryValue/PutValue to
make use of new UNO API data structures. To do so,
added tooling methods for data transition:
- fillColorStepSequenceFromColorSteps
- fillGradient2FromXGradient
- fillColorStepsFromAny
- fillXGradientFromAny
and adapted
- case '0' (all data)
- MID_FILLGRADIENT
- MID_GRADIENT_COLORSTEPSEQUENCE
- MID_GRADIENT_START/ENDCOLOR
to make use of these.
Tested usage of these in the office.
Renamed from GradientStep to GradientStop after
discussions with members on the list to make this
closer related to other norms/definitions.
Also renamed classes and class members to better
reflect to GradientStop, so grepping/finding will
be easier (e.g. 'Color' just exists pretty often,
but 'StopColor' is more precise).
Changed the used UNO API class for reprsenting the
Color to better reflect to ranges [0.0 .. 1.0] and
usage of RGB.
Change-Id: I1eeb3e97e81d6785967615d1ff256551fc3b882d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Due to the fact that handling of a vector GradientSteps
will get used more often with ongoing changes I moved
some handling to tooling, see sortAndCorrectColorSteps.
That method sorts and corrects a vector of ColorSteps
so that only valid entreis remain in a sorted order,
for details please refer to the docu at function
definition. I took the occasion to rearrange that to
work on the single provided vector which is better for
speed & ressources.
Also changed the ColorStep constructor to not
automatically correct constructed entries: While that
is formally correct, it moves an invalid entry to 0.0
or 1.0, thus creating additional wrong Start/EndColor
entries. Those may then 'overlay' the correct entry
when corrections are applied to the vector of entries
which leads to getting the wanted Start/EndColor to be
factically deleted, what is an error.
Also rearranged FillGradientAttribute to now work
initially with ColorSteps, no longer requires the
Start/EndColor, also adapted all usages. This securely
allows start/end and in-between single-color sections
in gradients.
Also needed to re-formulate GradientRect &
GradientElliptical ::appendTransformationsAndColors
method for correct 2D mapping(s) - always incrementing
from the start to end conflicts with the adaption of
the start value for the inner loop mainly because
increment is at start of inner loop (pre-increment).
Corrected errors from clang plugin, but also some
wrong initialiations for basegfx::ColorSteps.
Change-Id: I292592ed9abcfa591f68a680479f4fcdda46cbeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148196
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Added to make GradientLinear work using the MCGR
as 1st of six types. Had to do quite some tickeling
to get it all work, but looks good.
Five more to go, already started to put some things
to tooling to make re-usable for the other types.
Besides adapting this the main change is that the
adaption of defined step-count (versus automatic)
has to be done in modifyBColor now instead of the
back-mapping methods (e.g. getLinearGradientAlpha).
It is still 100% backward-compatible, so as long
as there is no source using this it will stay
invisible - by purpose.
I started to do quite some tests (and fixes/
adaptions in consequence), see the static variable
nUseGradientSteps. If you want to play with this,
you might set it to '1' instead of '0' and use a
linear gradient on an object.
Change-Id: I9d61934defb0674456247f2879f0a89b6a5e50f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147413
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Move GradientSteps data to GeoTexSvxGradient and adapt
interfaces. Also move tooling to more isolated place
in gradienttools in basegfx.
Keep everything still compatible, the work will be now
to adapt all six different derivations of
GeoTexSvxGradient to make use of the evtl. given
GradientSteps.
Change-Id: Iaa212763c603d46de0a94b1b203b979bb7ce359d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147050
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
MCGR stands for MultiColorGRadient. This change allows/
prepares adding multiple color steps to gradient rendering.
This is preparation work to allow rendering MCGRs in the
future. All places are adapted in a way that currently
no change of behaviour will happen. It will be the base
to get MCGR rendering/decompose for Primitives and our
internal/existing gradients working.
Change-Id: I28bbd7d10b8670042343ada2a66b5909d3d31bbd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146748
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
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>
This adds support for 3D drawinglayer primitive XML dumping and
adds dumping support for many more primitives and attributes that
were missing before. This is needed to be able to check the
fontwork objects, which can be rendered in 3D.
Change-Id: I0e78be4d4030a0cae3d2b952a1a38de8940ee310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124804
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Excessive padding in 'struct ValueSetItem' (8 padding bytes, where 0 is
optimal).
Excessive padding in 'struct framework::CommandInfo' (12 padding bytes,
where 4 is optimal). Optimal fields order: aIds, nId, nImageInfo,
consider reordering the fields or adding explicit padding members
[optin.performance.Padding]
Excessive padding in 'class
drawinglayer::attribute::ImpFillGradientAttribute' (10 padding bytes,
where 2 is optimal).
Excessive padding in 'class
drawinglayer::attribute::ImpSdrLineAttribute' (8 padding bytes, where 0
is optimal).
Change-Id: I606f2bfc2c0c51b386182b900401dd15b5404451
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121938
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The shadow of objects must not be scaled: this displaces any internal
areas that need blur, e.g. holes. Instead, it needs to dilate the
shadow using kernel with radius equal to blur radius: this allows the
borders of dilated objects to be in the middle of the blur area. The
following blur makes those new margin points to have 50% intensity,
and full glow intensity at the point of old object margins. This also
removed artifacts when moving objects with glow effect caused by
mismatch between scaling and D2D range calculation.
The D2D range therefore is not calculated by scaling, but using grow.
Blur filter's "extend bitmap by blur radius" option got obsoleted and
removed.
There's no need to blur the glow color (24-bit RGB). Instead, glow
bitmap must be filled by glow color, and have an alpha mask that is
blurred accordingly. This makes the glow properly transparent, and
also reduces the blur complexity which now only needs to process 8
bits of alpha channel.
The object shadow is created using basegfx::BColorModifier_replace
inserted into the 2d decomposition of the effect, as before. To make
sure that any non-fully-transparent pixel will become black pixel in
the shadow, black color is used, and the result is further processed
in VclPixelProcessor2D::processGlowPrimitive2D with monochrome filter
using threshold 255.
Glow transparency attribute is taken into account: the initial value
at the margins of the objects. Color replacement filter is used to
replace the object shadow with the attribute value before blur pass.
Correct blur radius is used, calculated from glow effect radius,
instead of hardcoded value of 5 pixels. This makes the glow to fade
gradually along the full width of the effect, instead of only fading
in narrow outer border previously.
Since blur filter is only implemented for radius up to 254 pixels,
and since downsampling the shadow before blur increases performance
without noticeable quality loss, the image is downsampled before
filtering.
It should be noted that the glow effect is almost identical to soft
shadow effect, likely with the only difference of using dilation in
the former, but not in the latter. The code might be reused later to
implement soft shadow as well.
Change-Id: I728c532f9df7ccf85f353c23c6c7d8352d7b2086
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93235
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Glow effect is a color-blurred outline outside of the shape. In ooxml
document it is specified with the <a:glow> element.
The commit contains the following:
- Add support for importing and exporting <a:glow> from ooxml documents.
- Assign new properties to XShape which stores glow-related attributes.
- A new 2D primitive is introduced in module 'drawinglayer' which is
responsible for representing the glow primitive which is to be rendered.
+ A glow primitive is a clone of the original shape which has been
scaled up slightly and a new color has been assigned to it. The
radius of the glow effect and the color is defined in the <a:glow>
element being imported.
- A blur algorithm is introduced in module 'vcl', which is called during
rendering the primitive.
+ The blur algorithm works on a bitmap.
+ Since the algorithm is CPU-intensive, the result is cached in the
processor and it is recalculated only if needed.
- Add support for importing and exporting glow effect to ODF format. For
that, new attributes of element <style:graphic-properties> has been
added:
+ loext:glow, which can have the values "visible" or "hidden"
+ loext:glow-radius: which holds the radius of the glow effect in cm.
+ loext:glow-color: holds the color of the glow effect
- Tests have been added to assert properties after pptx import and
export.
Change-Id: I836aeb5e0f24e2c8d5725834c8c0f98083bc82e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89125
Tested-by: Jenkins
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
Also make the functions constexpr.
Due to slight changes in floating-point arithmetics (90.0 instead of
180.0, M_PI2 instead of M_PI resp.), results might differ in last
digits (usually 17th decimal digit). This has lead to need to tweak
char2dump's PieChartTest unit test.
Change-Id: I20323dd7dab27e4deb408ea4181e390cc05e7cd3
Reviewed-on: https://gerrit.libreoffice.org/58583
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: I38baea4d1dd354e48eb90fc2fc385ef60485b5e3
Andreas Heinisch