Age | Commit message (Collapse) | Author |
|
We assumed that the top left corner is the origin for scaling, but that
is not necessarily the case. The intention is that the shadow direction
can be determined from its x and y offset, and the origin is the
opposite corner of the shape.
Change-Id: I6759302767d20739b6e2be79d379740dd06f70f5
(cherry picked from commit a1dde1a85a8d1c54521a0ac6310571ffcdd4bb5a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93974
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Covers tdf#98583 and tdf#98565 too.
TRBaseGeomety (API) uses for skewX the same angle orientation as
written to file. But that results in mathematically wrong matrices.
Change sign where needed.
Vertical shearing is converted and written to file by LO as sequence
rotation * shear horizontal * scale. Same should happen on reading.
Because LO does not write skewY itself, I have used the angle
orientation, that was used in OOo1.1.5 and that is used in
Scribus 1.5.4.
Import generates a transformation matrix from the draw:transform
attribute. That is a mathematically correct matrix. It is applied
to the shape via TRSetBaseGeometry. But that uses a wrong sign in
the shear angle. Therefore conversion of mathematical matrix to
TRBaseGeometry matrix is needed.
The draw:transform attribute can generate a scaling, which needs to
be applied on top of the scaling made from svg:width and svg:height.
Such happens on import of skewY() and might happen with matrix().
SdrPathObject puts scaling form svg:width and svg:height directly
into the coordinates of its points. It had ignored any additional
scaling. I have add a part to detect and apply it.
Change-Id: I7636b9feec432cf403e7c6ef8dbd6a769793d144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86244
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
The color's alpha is normally lost when we roundtrip SvxColorItem's
tools Color via TextSimplePortionPrimitive2D's basegfx::BColor.
One way would be to add an extra transparency member to the primitive,
like BackgroundColorPrimitive2D does that.
However, a much easier way is to go via UnifiedTransparencePrimitive2D,
that way we handle transparency in
drawinglayer::impBufferDevice::paint(), rather than platform-specific
code like CairoTextRender::DrawTextLayout() in the Linux case.
Change-Id: Ie7aebe77ad9ac776dd27fc50538a5045200c8010
Reviewed-on: https://gerrit.libreoffice.org/83307
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The patch covers several errors, see comments in the bug report.
Change-Id: I6cdaf3e8951dab21b314ef61e12ffa3b3ee481dc
Reviewed-on: https://gerrit.libreoffice.org/68029
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
MS custom shapes use always zero for identifier left and top in
the formulas of the shape geometry. But custom shapes in ODF use
the left and top value from the svg:viewBox attribute, see
table 11 in section 19.171 draw:formula; part 1 of the spec.
Change-Id: Ief4b9d9b8797e165a494d049f32c5a46880044c2
Reviewed-on: https://gerrit.libreoffice.org/64704
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
A Writer image has an underlying SdrObject, but GetSdrObjectFromXShape()
won't work for it, also we can't an sw SdrObject into an XShape because
SvxDrawPage::CreateShape() has no idea how to handle sw's
SdrInventor::Swg inventor.
Fix the problem by just getting the Graphic of the Writer image and
improve GraphicExportFilter to be able to work with just a Graphic as
well.
Change-Id: I3c9b3005366fcc87815597a27df3cb8a99a8876c
Reviewed-on: https://gerrit.libreoffice.org/54527
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I0577de02000c6aeb45bf1e950b9212beadacb05b
Reviewed-on: https://gerrit.libreoffice.org/50334
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If3b22635e46dbccf0fad101f51bb653cbbcd3a32
Reviewed-on: https://gerrit.libreoffice.org/34957
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ida5bdfa06ecd7907305f4f171ca5ab64260d0259
|
|
This fails with commit 7d76bb251e0c88ff17282a33b801a5d17a434af5 (vcl:
add graphic export-as-pdf filter, 2016-06-24) reverted.
Change-Id: Idea5c282d610d949958d757677ee642d97ca1c8e
Reviewed-on: https://gerrit.libreoffice.org/26747
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This patch changes occurences in makefiles
from
$(eval $(call gb_CppunitTest_use_api,comphelper_test_config, \
udkapi \
offapi \
))
to
$(eval $(call gb_CppunitTest_use_sdk_api,comphelper_test_config))
(corrected instead of abandon, jani)
Change-Id: Ic96ec65d82d7452e288f05a8b6d576ef543b068e
Reviewed-on: https://gerrit.libreoffice.org/23426
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
The code in SdrTextObj::ImpSetTextStyleSheetListeners is obviously not
working correctly.
The families of the stylesheets are appended to the name of the family
for further usage.
An encoded string looks like "STYLE_NAME|3 "
The family is then extracted by copying the first (length-6) bytes,
e.g., "STYLE_NAME" in this example. Then another copy starting a
position 1 is created, e.g., "TYLE_NAME". This string is cast to an
Int32. Since this is not possible, 0 is returned, and the originally
stored family is lost.
This patch corrects this behavior, and adds a unit test.
Change-Id: I60c0add6e4b670acbbc264cc77672452f282f737
Reviewed-on: https://gerrit.libreoffice.org/10818
Reviewed-by: Matúš Kukan <matus.kukan@collabora.com>
Tested-by: Matúš Kukan <matus.kukan@collabora.com>
|