Age | Commit message (Collapse) | Author |
|
PDF annotations have the modification date and time accessible in
the PDF specific format. With PDFium we read the annotation date
and time and convert that to css::utils::DateTime (by converting
to ISO8601 compatible string first).
Add support for modification date and tme for annotations into
ImportPDFUnloaded and when the annotations are inserted into the
document as comments (in Draw document).
Change-Id: I24aacde84b7530365d67ed335b1eefbaee706eca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96759
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 4e3196ceedc2b79d58bb57dba86f2f0158d32998)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97440
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Also add tests readin annotations from Evince and Acrobat modified
PDF files.
Change-Id: I4565c6b621774fc8485a6c33bc18708664917b73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96756
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 7e4dc3b1eabcb1993d4143c046a2f32fedc852ed)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97438
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96753
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 526b09604399a71c17b15ee80bab48967563bfb6)
Change-Id: Idd33dfe752a22b6628750c06f02e9467a69802bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97435
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
PDFDocument::Sign() had this hardcoded to always place the signature
widget on the first page, add a way so that xmlsecurity/ can tell the
pdf signing code to put it on an other page.
This way in case the user created the signature line shape on the Nth
page, it'll end up on the Nth page of the PDF result as well, as
expected.
(cherry picked from commit 022f6bb1f7ed06edb126a2b85719d8622104bb57)
Conflicts:
vcl/Module_vcl.mk
Change-Id: I63decba98774151e9634ea924c2fed0f7814cb28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97256
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
THis adds support for match case and match whole word to the
VectorGraphicSearch + tests.
It uses the new options in PDF seearch in Draw/Impress.
Change-Id: I20a6382c22bf01a5a021c8bae1ff78861419c0ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95530
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 112d8113388513d9c6b317e828f5d373b4a54330)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95950
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
enclose with HAVE_FEATURE_PDFIUM
Change-Id: I46f8d6b19c46dbdf313b6192dddf85741ceb301f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95462
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit e848e95faa5cea1f258c9f97d99ffc91614e5a3b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95948
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Initial implementation only allowed to set the search string once.
This change allows to change the search string and still retain
the last position of a found string, so the search continues
from this positon forward or backwards. This mimicks how we search
through the GUI (which is the main use for this functionallity
anyway).
Change-Id: I8a7aee4b6b6525f483f105feaa1f83c4a0ad9594
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95460
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 1f8a46ae50c6977add4c4116f114df3a58796be3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95946
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
With more and more usage of PDFium, it is hard to keep track of
the life-time of the PDFium library, so it can happen that a
FPDF_DestroyLibrary happens when we still have another instance
where PDFium is still use. The result of this is a crash. To
prevent this, just initialize the library once and delete, when
on LO exit.
This can be improved in the future to only keep the library
active when in actual use.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95391
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 067a8a954c8e1d8d6465a4ab5fb61e93f16c26c2)
Change-Id: I5c7e5de7f8b97d10efb394c67c7a61b976c8d57c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95933
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
By default we start at the begin of the page, but with this change
make it possible to start at the end. This makes it possible to
search in the backwards direction (set the start position at to
the end and search with "previous").
Change-Id: I78fb1461b86bf9eab2f91c3b9a81cbb5c6557332
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95382
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 83d27791fed75941c75d3cc571c3d5cf27d14e8c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95930
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Previous moves backwards in the search matches.
Change-Id: I88d402e0b8cb9dc4fd93e7f1ce5b08fb42aadd06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95381
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit e20440effc7a47c8a5e8ef0943e6872cd9b3646a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95929
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95261
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 936a670f61fed891f8aaec77b2422f366240f193)
Change-Id: I12e7ad10dc3ed68d20d94713acece1361da27e81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95834
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia0c5610f600719bcfb5de503f3876fc896cb630a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95256
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 4062b3f87689e48fd250d9cf0297a24b5427bf59)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95833
|
|
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95254
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit efba780d6155317b592b6f5f73945a7851ec4d3b)
Change-Id: Iee940a3927330c8739774ff3c1af15998f89193b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95801
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
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>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95701
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ib50ebadf73979068d3595f09de113aa8745eccb9
Reviewed-on: https://gerrit.libreoffice.org/83591
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I714a44d40a99e0bb5ff48e3d36ded73db60af5a0
Reviewed-on: https://gerrit.libreoffice.org/83133
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
PDF printing tests cannot run when we don't have the proper
support enabled, so we need to detect those cases and
avoid failing the test unnecessarily.
Change-Id: Ia602dbb5c3d16c082a8ff6e707db90501bb5453c
Reviewed-on: https://gerrit.libreoffice.org/78610
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/82168
Tested-by: Jenkins
|
|
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.
(cherry picked from commit 141e0449fdab89384564659191492b698e4b13d8)
Conflicts:
filter/source/pdf/pdfexport.cxx
include/vcl/pdfwriter.hxx
Change-Id: I9598dc46fe7db428bd2eff98bebff8b3c873b4ff
|
|
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.
(cherry picked from commit 4830592b780833cf5eee2aef30bc9c5d444dfb24)
Conflicts:
vcl/source/gdi/pdfwriter_impl.cxx
vcl/source/gdi/pdfwriter_impl.hxx
Change-Id: I8ee159f2571f4070aded85388792a215de86f7ff
|
|
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.
(cherry picked from commit 01dbb38680aa39a4d3bc7afd05d44a4b2c9bc6ab)
Conflicts:
vcl/qa/cppunit/pdfexport/pdfexport.cxx
Change-Id: Ic29e345d45bc7c944d65e6e450f1d742dd0e9f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90551
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.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>
(cherry picked from commit 6dff631f8f4b964b48aadde52a1e1b8b04b9ba53)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89923
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.
(cherry picked from commit 7088140dbf1d5e0391c2662f0213018a45620ff9)
Change-Id: I4edcb12fab71bb305d97a50d20fbfbf86d9aab85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87956
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t
backward compatibility remediation", as implemented now by <https://gcc.gnu.org/
git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++:
P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads
that would print an integer rather than a (presumably expected) character.
But for simplicity (and to avoid issues with non-printing characters), keep
printing an integer here.
Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7
Reviewed-on: https://gerrit.libreoffice.org/84348
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 5d8f0fad50f90195a11873c70ddab4644f5839ea)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87760
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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.
(cherry picked from commit b0fa356eed82a0452e6bcb915f179f5e2d02943a)
Conflicts:
vcl/source/window/cursor.cxx
Change-Id: Iba378cef3a693b0712389fab519f38ee222577d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86158
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
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
Reviewed-on: https://gerrit.libreoffice.org/85636
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Regression from commit dd4a67084853a030bf4b9f1f85d728620e0604a5 (vcl:
avoid downscale && upscale in DrawTransformedBitmapEx(), 2019-10-08),
the original problem to be solved was that in case you downscale a
bitmap and upscale it later, then you get blurry result, so we try to
avoid touching the pixels and just scale during rendering of the bitmap.
However, here the problem is that scaling is also (mis)used for flip
purposes, so go back to the original behavior for negative scaling.
This keeps the original problem fixed and solves the loss of flip as
well.
(cherry picked from commit 8dde8f9768f0dab97cdd30e3116f7e4d737c482f)
Change-Id: Ic9a6eb49d55f2fb8ccf18d982e574398f010cabd
Reviewed-on: https://gerrit.libreoffice.org/83732
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
It makes no sense to set the size of an image based on the swap info
when the swap info unit and the actually loaded image's unit doesn't
match.
Converting the size would be also an option, but let's wait for the
first case when a custom size is actually needed for mismatching units.
(cherry picked from commit 0098563895f6a4024b400582d1bf93cb4435ceed)
Change-Id: I96b5c237f0be5587bb2f938faf3c69fa0e1d4a5c
Reviewed-on: https://gerrit.libreoffice.org/83160
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
kCGColorSpaceGenericGray is deprecated and should be
kCGColorSpaceGenericGrayGamma2_2, and kCGColorSpaceGenericRGB is
similary deprecated and now should be kCGColorSpaceSRGB.
This fixes the "color skew" issue found in a variety of tests.
Change-Id: I8088b2377e03cde3f8e03e9d3778a40fc3081c4a
Reviewed-on: https://gerrit.libreoffice.org/82809
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 3a8d16ba8ca7ef7349e893f2bf1c7e12d9a8d7ae)
Reviewed-on: https://gerrit.libreoffice.org/83081
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Regression from commit 68549e00d5e23aa22bc974a8151d93cd948444b3 (vcl,
BitmapEx transformed draw: special-case simple rotations, 2019-10-10),
the intention there was to fix an error on the last col/row of a bitmap,
but that was only tested with input where the aspect ratio doesn't
change on scaling.
Fix the problem by going back to the original way in the "aspect ratio
changes" case.
Change-Id: I52bed503ddaadbbbdf64ac6fec2fe268153866f1
Reviewed-on: https://gerrit.libreoffice.org/82467
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
PDF images are effectively 1 page PDF documents. The page object may
have a /Rotate key, which was simply ignored before. We turn page
objects into form XObjects on PDF export, such rotation can be expressed
with a /Matrix key.
Add support for the 90 degrees rotation case, this can be generalized
later if wanted.
Change-Id: I55a4f63e0b986637ccdeba0b783f1db9a85c4d93
Reviewed-on: https://gerrit.libreoffice.org/82154
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Re-exporting PDF images works by tokenizing the PDF image, identifying
which PDF object is the page object and then copying that over to the
PDF output, together with the dependencies of that object.
This involves copying the resources of the page object. Previously we
assumed that the sub-keys of the resources are always inline
dictionaries, but the bugdoc shows that they can be references as well,
which point to dictionary objects, so add support for this scenario.
Change-Id: I78ee1c726e6ecd958232e9fab64773595e5b9c86
Reviewed-on: https://gerrit.libreoffice.org/82076
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I0f20e057b97bcb3ab120ae6b211729ea60937bd8
Reviewed-on: https://gerrit.libreoffice.org/81769
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Fix Graphic::IsAlpha() and Graphic::IsTransparent() for unloaded
graphics. This fixes tdf#118036.
GraphicDescriptor::Detect(true) is currently used to read the image size
from the header of images which are not being fully loaded yet. This
change extends GraphicDescriptor to also report whether the image
supports transparency or alpha, implemented only for PNG format so far.
Change-Id: I1753c0d11491f1dc518e23da8d7b3842945770cb
Reviewed-on: https://gerrit.libreoffice.org/81785
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Also fix a misleading comment
Change-Id: Ide6096291c2fc6c43cfd7116af7798ae03069fab
Reviewed-on: https://gerrit.libreoffice.org/81448
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
This reverts commit 302af8c2da58719844d22483b65a9fe5b3674684
I would like to revert it until a better solution is proposed
due to the number of duplicates already reported
After the commit, Libo exports LTR formulas in RTL documents to PDF
as RTL formulas
it also introduced other problems like tdf#112513 and tdf#117560
Unittest added
Change-Id: I097fb5801eb728bd258ae96bd981c6725e7aa06a
Reviewed-on: https://gerrit.libreoffice.org/81262
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Change-Id: Ic00f5a5fe562022524c60a23509722f9e2406524
Reviewed-on: https://gerrit.libreoffice.org/81135
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2d4fb034e72369dc051c4bc2f5a7598e1d58f9c1
|
|
Change-Id: I3186b63d4c6c437ff0c0653a6b6c7fd61ae69304
Reviewed-on: https://gerrit.libreoffice.org/81069
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
In case OutputDevice::DrawTransformedBitmapEx() has to do both shearing
and rotation, then recording to a metafile is unchanged. But if we need
to do rotation, then it's not necessary to go via transformations.
This has the additional benefit that 90/180/270 degree rotations don't
introduce an off-by-one error, where the first row and col of the
transformed bitmap is transparent.
(At the moment it's not clear what introduces the unwanted translation,
but at least the direct Rotate() way resolves the visible end-user
problem, see the test.)
Change-Id: Ie1adbdb2221b086c19cc66f69308b6b7256fe29a
Reviewed-on: https://gerrit.libreoffice.org/80626
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
If you have a very small bitmap and you rotate it by 90 degrees, then
smoothing is not needed, but the result will be blurry. So in case
scaling / shear doesn't need it and we do 90/180/270 rotation, avoid
smoothing.
Change-Id: I4b8fad4b0b70516d35eaecfa70a707e6e8362d18
Reviewed-on: https://gerrit.libreoffice.org/80589
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
If we rotate a bitmap and put it to a metafile, we'll create a
MetaBmpExScaleAction. But just because we need to store a transformed
bitmap for rotation purposes, it doesn't mean we also need to scale it.
This helps in case later the metafile is upscaled and the downscaled
bitmap would look blurry.
Change-Id: I7d64a88af460e80dffde8052186888eddbb440fe
Reviewed-on: https://gerrit.libreoffice.org/80426
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
GetPrefSize() at this point is Size(0,0), so the test was testing
topleft corner. And getPixel() takes Y,X , so even then it wasn't
testing the center.
Change-Id: Ie2e489a693fae2b7ea41075ebe6fa3ef405545d5
Reviewed-on: https://gerrit.libreoffice.org/80351
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ic331d33e0f0feca1fde4425fdb4106b1a769194d
Reviewed-on: https://gerrit.libreoffice.org/80350
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I75fe2a1a5846cf31b3036afaec18e4e55d7b0394
Reviewed-on: https://gerrit.libreoffice.org/79949
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
activates-default of True means pressing return activates the default
button of the action area, which is typically what vcl Edit did by
default.
Change-Id: I60bc1634b04a486af86526d887d0ada961b08076
Reviewed-on: https://gerrit.libreoffice.org/79860
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is a regression from commit
acb803b730f2c6bd82e39beab58949ec14f85eb0 (tdf#125591 DOC import:
lazy-load metafiles with explicit size, 2019-06-11), which assumed that
once maSwapInfo.maPrefSize stores the preferred size, it'll be set on
the Graphic when it's loaded later.
It seems there was no support for that, it was just an accident that the
guessed size of the metafile was about right.
Handle this explicitly in ImpGraphic::loadPrepared(), so that the bugdoc
(which has a custom preferred size) aspect ratio is correct.
Change-Id: Ic7c4009ad6723a2e16129d27600c904311ff3daf
Reviewed-on: https://gerrit.libreoffice.org/79899
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
It's important that we also check from the files as we can change
both - the import and export code, and we could actually break the
SVM file compatibility.
Change-Id: Iedb245f84e49f931e46ae20beadf612758076603
Reviewed-on: https://gerrit.libreoffice.org/79792
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
none of our supported hardware uses these any more
Change-Id: Ic95d6df619a05df0bec1f5870596cb2bb3bcc6cb
Reviewed-on: https://gerrit.libreoffice.org/79476
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If4202cb7b13bc1af81303cc682af5f30d414c5b5
Reviewed-on: https://gerrit.libreoffice.org/78875
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Adds in logic to OutputDevice that takes a font color and the font's
background color - if the font and background is dark then return the
stock white color, if the font and background are bright, then return
the stock black color, otherwise just return the font color.
Also added a unit test to ensure that SmTmpDevice restores font and
test color correctly.
Change-Id: Id805682778d82826c644e7a27017c8d30b1ff5eb
Reviewed-on: https://gerrit.libreoffice.org/75524
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|