Age | Commit message (Collapse) | Author |
|
Change-Id: I9588841de6f751ad767f695dec51f660b2990b49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93954
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iff68e8f379614a6ab6a6e0d1bad18e70bc76d76a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91907
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I792efb417504a3b55043ff4fc3fd3597a9b953f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93678
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
Needed for glow effect (tdf#101181)
Change-Id: Id41daa1dc17e3749a30ce75fa3127878b9e0cfd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93552
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
in unit tests
Change-Id: Id16731bbbe2f1b0e3642722d77aba04fc98db4cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93508
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
AquaSalGraphics: :drawPolyLine() does not implement
basegfx: :B2DLineJoin::NONE for large line width.
Change-Id: I406941797ad2b8bab79ea0a635eddc624755cbdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93568
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
For backends that do the object-to-device coordinates transformation
directly, it's necessary to also convert the size of line width.
But simply multiplying it with the matrix can also rotate the line
width "vector", making it e.g. negative. So don't use just the X
coordinate, use vector length for the transformation, which is ok.
In fact it doesn't even make sense to treat width as a vector, because
a width simply is not a vector (and for this reason it's also not
actually used).
Change-Id: I1241c9cb29155df105170d568a879ebc32b11a5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93203
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
Change-Id: I63ae6adec1967bcf888538437e5e88f0acdea66e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93392
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: Ia6a4cedf5c570e5d9544887ae66da0ec1e491647
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93348
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Add DetectorTools with byte array searching and matching to a
input string (or another byte array). This refactors the existing
function in GraphicFormatDetector. It needs to go into its own
header so that the function(s) can be tested easily. Replace
the previous searchEntry implementation with refactored one in
the source code.
Change-Id: I59d30b694e13f28d6366f1a99fe2ef2ea3c1a07d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93339
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Add test case for Animation and GDIMetaFile serialization.
Change-Id: Ibe2fa9982c8faea36e1f26ca9c6b735ae0ebd8ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93337
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I73aafc4f9a6f964a31d116610df6cf15dc51770c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93334
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3c4845550e776c4c2c891d94db71bacea27c9a37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93328
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ic365d27e9ef1c676e47de22b8949b5679c0a2841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93326
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The test checks that the exported PDFs contain embedded PDF for
different pages.
Change-Id: I4e5cd108d8597851d86aa774efbde0d4f2b9d2ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93322
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id26a79fa047f1f6d26cab1f08e1db57330d4168b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93319
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I94d7ce65aebd6b74f214362c466fda38c4808d9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92966
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Test the rotation in JPEG metadata is what we expect.
Change-Id: I5ee2d646a5257d5695c51f37fb6fe795dcb9af50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92948
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I895002aa31380d2b5bc2593e66080f3fc94034e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92920
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
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
|
|
The value of these coordinates are not allowed to be larger than 14 400,
and Adobe Reader complains about them.
Use UserUnit to declare in case we won't work with points anymore, but
with a larger unit. This will mean UserUnit=2 in practice, since e.g.
Draw has is page size limited to 600x600cm, so larger values won't
happen, at least not for now.
Change-Id: I8ee159f2571f4070aded85388792a215de86f7ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92383
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I80d3f5896f4e3b985ab1563a0a8306e5ff7183ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91337
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Performance increase from ~3100ms to ~1400ms on 4c/8t CPU.
Change-Id: Ic057c3fafc3cf6f0f90430ca431db569be08a133
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91684
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia7f3441404d8d2e5de501e70da496b6fdc6c9a4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90728
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 59887868da3499c68d5f259cfa48178354397448.
Change-Id: I0f3f6a7680c78103a559a0f881badc8211b97ace
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90544
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
SdPage::IsExcluded() decides if a slide is hidden,
SdXImpressDocument::render() checks for this and returns early if
needed. In that case PDFExport::ExportSelection() detects that the
produced metafile has no actions and avoids creating a PDF page.
Then Impress links are created using the
vcl::PDFExtOutDevData::CreateLink() call in
drawinglayer::processor2d::VclMetafileProcessor2D::processTextHierarchyFieldPrimitive2D(),
not specifying the PDF page number explicitly. This means the link is
created on the "current" page number, set in
vcl::PDFExtOutDevData::SetCurrentPageNumber(), called by
PDFExport::ExportSelection(), but that filter/ code can't know about
hidden slides in sd/.
Fix the problem by setting the page number again in
SdXImpressDocument::render(), that way the link created by drawinglayer
will end on the correct page.
Change-Id: Ic29e345d45bc7c944d65e6e450f1d742dd0e9f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90299
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ibf4d070fa9085bad103c52fa7656e2f8240784df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89997
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
For more info and discusson please have a look
at the task. It reverts the change from tdf#99680
which did a wrong paradigm change in how clip in
Region(s) is defined and tries to fix the
underlying error in a more correct way.
This includes problems noted in tdf#44388 and
tdf#113449.
This is a decent improvement, but - due to dealing
with numerical problems - not yet the whole healing.
Still thinking about how to solve this for good.
Adapted PdfExportTest::testTdf99680() and
PdfExportTest::testTdf99680_2() as needed, empty
clip regions are allowed again. Added comments, too.
Had to change solvePolygonOperationAnd to work
on ranges if both inputs *are* ranges. The AND-case
is then completely solvable. Also increased geometry
for transformations of clip geometries - may help
later.
Change-Id: I2370447597faa6efb81d58ee31c63654e304262e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89874
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
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>
|
|
Change-Id: Ia3877f58b6e5ccc4fb1621e6b928638e0c850e7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88602
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The ATI brand has not been in use for a decade, and it's confusing
to have both AMD and ATI there. All AMD gfx cards use the 0x1002
formerly-ATI PCI vendor ID, so just use AMD and that vendor ID.
Change-Id: I9d60f1e86fe12a2e0fe9548c7c912d2d1ecec240
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88534
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Icc150b853f5d2d06afedcb7878f6a031aff57c2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88533
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
in c05680bd27f0f9fc9d5371f4ef97fd45184de1c6
Change-Id: I8d35ed9411c51b8bfffc2ca67d9d8de94ba067dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88355
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieeeaa53d916e192e7219d7d3d405584a22249e7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88181
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
To avoid duplication.
Change-Id: I0ee7c26d5d55bd868ead04c77e7f4ef2582f90e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88138
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The bugdoc has a transparent PDF image, and we currently put a white
background behind that in Impress, given that vcl::RenderPDFBitmaps()
works with Bitmap instances, not BitmapEx ones.
This means that in case we preserve transparency during PDF export, the
content that was rendered OK now becomes unreadable.
Adapt the PDF export to do the same as rendering by putting a white
background behind the PDF image.
Change-Id: I4edcb12fab71bb305d97a50d20fbfbf86d9aab85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87910
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
as shown with ./bin/find-headers-to-move-inside-modules.py
Change-Id: I7662417e76fe00c0fc352957560e104b6c2a3d61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87850
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia485601a08e2c0093e802c175041b76f94cbbb63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87848
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.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>
|
|
The data was given to the PDF filter, but then we stopped iterating
right after finding our output stream. Seems this was always like this,
ever since commit 4111b430a0a7954416ff95794a8ffb8fbc4472e3 (#101570#:
added pdf filter, 2002-08-13).
Change-Id: If26661935c22a7b7959fda5f92b4d50b15f13a35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87152
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Regression from commit b6588bd7c831ce88a29131ca7ea8d3f3e082564e (Reduce
image resolution by default in PDF Export, 2014-03-02) the problem is
that in case you have small enough bitmaps, then these used to look
OK at reasonable zoom levels, but now we intentionally scale down
bitmaps by default.
That makes little sense for tiny images, do this only for large ones.
Change-Id: Iff15325b842b47d9285a7c0f83f402897498392d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87086
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Fortunately it seems this is largely unused (I can see 5 invocations
when running all LO tests), so I went for the crude approach
of redirecting all drawing to a temporary bitmap and then manually
xor-ing all the data after each draw operation. This could be
optimized if needed.
Change-Id: I6fc91362dd93188775b371d5548a68a58645f85c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86776
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
so we return a const& for the normal case, just like other methods,
which reduces copying.
This revealed that CreateDisplayBitmap in Bitmap can be const.
Change-Id: I9f9b9ff0c52d7e95eaae62af152218be8847dd63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86836
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1c3280e811bf65641bf559e3f01bc62e609548f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86811
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Regression from commit d4714b0fdb81e6e561ae526cc517ecc9a40a603e
(tdf#101978 vcl combobox/listbox floating window: avoid flicker,
2019-06-17).
High-level vcl double-buffering never set up RTL status of the virtual
device correctly, but now that double-buffering is used at more places,
this got noticed.
Change-Id: Iba378cef3a693b0712389fab519f38ee222577d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86134
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I4359b7042f98586e2c9f5529d83d769cdf3d033c
Reviewed-on: https://gerrit.libreoffice.org/85775
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Regression from commit e8d5b8beb5958147235ff955ed38c47b51d860ff
(tdf#113714 vcl menu bar window: avoid flicker, 2019-05-20), the problem
was that while the original render context has RTL set up correctly, the
intermediate virtual device had it disabled all the time.
Change-Id: Ic063c4a6c0537891c0bfceb8927edb97cf1c6e86
Reviewed-on: https://gerrit.libreoffice.org/85624
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ibd7a2c28f086577563151e20ed51ec1030559b3c
Reviewed-on: https://gerrit.libreoffice.org/85493
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|