Building on top of commit bd520b1776 (vcl
PDF export: fix re-exporting PDF images with page-level rotation,
2019-11-06), this was already working for 90 degrees, now generalize
this to work with 180 degrees as well.
Change-Id: I5a5d51662399814d5554d7c2cb86a6c9a2974012
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115705
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
as part of a longer-term goal of doing our
widget rendering only inside a top-level render-
context.
I moved all of the OutputDevice-related code that existed in vcl::Window
into a new subclass of OutputDevice called WindowOutputDevice.
Notes for further work
(*) not sure why we are getting an 1x1 surface in
SvpSalGraphics::releaseCairoContext, but to fix it I clamp
the size there
(*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice
(*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code?
Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Otherwise this would break partial tokenize when we only read a trailer
in the middle of the file: m_aEOFs.back() is one byte larger than
rStream.Tell(), so we reader past the end of the trailer, resulting in a
tokenize failure.
What's special about the bugdoc:
- it has 2 xrefs, the first is incomplete, and refers to a second which
is later in the file
- the object length is as indirect object, triggering an xref lookup
- the first EOF is followed by a \r, but then not with a \n
This results in reading past the end of the first trailer and then
triggering a lookup failure.
FWIW, pdfium does the same in
<https://pdfium.googlesource.com/pdfium/+/59d107323f6727bbd5f8a4d0843081790638a1dd/core/fpdfapi/parser/cpdf_syntax_parser.cpp#446>,
we're on in sync with it.
Change-Id: Ia556a25e333b5e4f1418d92a98d74358862120e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115466
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Note that we render the bitmaps without FPDF_ANNOT, so comments are not
rendered into the bitmaps, rather we create them on top of the bitmaps
in Draw, explicitly.
FPDF_FFLDraw() draws content which is already an annotation, but not yet
interactive content; so this just fixes "missing text", as far as the
user is concerned.
Verified that e.g. vcl/qa/cppunit/data/PangramAcrobatAnnotations.pdf
indeed still doesn't render comments into bitmaps after this.
Change-Id: I2b74d585729305cc1d3a9fefa258d4d76d1bd038
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115122
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Rather use a proper alpha channel if we need transparency.
This is another small step towards merged alpha in our vcl
layer.
I suspect the intent in a lot of this code was to save memory.
Which have been a thing way back then, but these days our
backends mostly end up doing a copy-and-convert to a real
alpha channel anyway, so the existing code is actually
now a pessimisation.
Change-Id: I4a2bcbb2f76b841f05bc00580f364492829c69de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114808
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
So that we have fewer cases to deal with when we transition to
32-bit bitmaps.
(*) rename maMask to maAlphaMask, since now it is only being used
for alpha duties.
(*) drop mbAlpha and mbTransparent to simplify state management,
the only thing we need to check for alpha is if maAlphaMask is
non-empty.
Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Similarly how the jpg loader can load in a thread. This somewhat
complicates the loader, since bitmaps cannot be created in threads
that do not hold the SolarMutex, and SolarMutex is held by
GraphicFilter::MakeGraphicsAvailableThreaded(), which cannot
release it (otherwise something else might grab it and change
things in the background).
Change-Id: Idd711ac379b64a49ef8b8386964507b446d16944
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114165
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Revert "convert internal bitmap formats transparency->alpha"
This reverts commit c181e510c5.
and later fix up of
Revert "tdf#141504 qt5: ugly images"
This reverts commit e7424ff25a.
a lot of places are still working int transparency values
and not opacity
Change-Id: I31342cdb76629acbaebfcdfa385407d3291fe06f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114150
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This was already conditional in Module_vcl, so no need to have a
duplicated check here.
Which allows finally removing the HAVE_FEATURE_PDFIUM ifdef completely.
New code can just call vcl::pdf::PDFiumLibrary::get() at runtime and see
if the result is nullptr or not.
Change-Id: I36508181865a31618e48cf7c2680d75465130dd3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114108
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This is entirely specific to pdfium, so don't build it in the no-pdfium
case.
Towards completely avoiding the HAVE_FEATURE_PDFIUM ifdef forest.
Change-Id: I127fce64d4ba1fffe529daf927311ed4d42d745f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114067
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This changes all backends to use PixelFormat as the input to
the SalBitmap::Create method (and all the backends). This is the
first part as we need to make sure to also limit the use of
GetBitCount method and also use of it in SalGraphics.
Change-Id: I8d2b6adfcb8fe3dd78010538411f338c9a1c3996
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113603
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Just process tasks (and system events) via DoYield and actually
wake up the system timer on OSX.
This drops the testFocus unit test. There is some comment about
it in README.lifecycle, but the test's CPPUNIT_ASSERT was already
commented and mmeeks suggested to simply drop it.
Even worse: just replacing
- Scheduler::ProcessTaskScheduling();
+ Scheduler::ProcessEventsToIdle();
results in a SIGSEGV in my local Linux build, which is a totally
unrelated crash.
Change-Id: Ie3e2a8668b8501f081706dde0ba3684801c30cc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112761
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
We can cast the PixelFormat enum to int for the same information
and we can use the enum to reduce ambiguity when possible.
Change-Id: I6ea648139465568cdeb12e5f5f75c7b609365bf4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113188
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
After 5c9ba1f47d, the failures on Jenkins
(see 21191d0d89) made it apparent that
(at least some of) Jenkins builds also run in RDP sessions. Since the
tests excluded in commit 9c6142ec26 never
failed in Jenkins builds before, it is wrong to exclude all those tests
in all RDP sessions: our CI would not test those on Windows.
In the meanwhile, I discovered that the system that failed the tests
actually had 16-bit color depth, despite RDP being configured to use
32-bit colors; that was the reason why the colors were modified on
roundtrip. So it is better to test the actual problem to exclude tests.
This reimplements the check that was introduced in commit
9c6142ec26 to test default virtual device
color depth.
Change-Id: I329a3e2d8eca21732c77dcacf15394d1246b2e18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113460
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
After 5c9ba1f47d, Jenkins builds sometimes
fail the opposite way:
Test name: VclComplexTextTest::testArabic
equality assertion failed
- Expected: 70x14@(1,1)
- Actual : 71x14@(0,1)
So it seems that RDP session is not a reliable criterion. Just relax the
check to allow epsilon of 1.
Change-Id: I17ecacb61d6b0f15f7d5c9ec348e6e0b05e83c0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113453
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Without the fix, this is failing there with
Test name: VclComplexTextTest::testArabic
equality assertion failed
- Expected: 71x14@(0,1)
- Actual : 70x14@(1,1)
See also commit 6f995da5a6, that
tried to address the same issue (it was reverted later in commit
536666539c).
Change-Id: I708c22deb5f1f8a59e2e22cba14b298acaa81d5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113396
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It seems that RDP may change (limit?) color space (even configured
to use 32-bit colors), and then some tests start failing like this:
Test name: BackendTest::testDrawAlphaBitmapMirrored
equality assertion failed
- Expected: c[80000000]
- Actual : c[84000000]
Debugging ImplDrawBitmap in vcl/win/gdi/gdiimpl.cxx, and adding a
call to GetPixel immediately after the call to StretchDIBits, shows
that the resulting color on the device is different from the color
in the bitmap data: e.g., for original color {128, 0, 0} the result
is {132, 0, 0}.
Calling GetColorAdjustment shows that there's no color adjustments
set for the device, so I can't detect or modify the behavior this
way. So just disable the tests for now when running in RDP sessions.
Change-Id: Ie89d07f18f53e56bed6f7fa58432b8575b4d9f12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113388
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This removes writing 4-bit palette bitmaps when writing to the
BMP format and reading from a 4-bit BMP uses 8-bit palette
instead.
This also changes the tests with the new expectations, but at
the same time it makes sure old BMP files and SVM files are still
compatible.
Change-Id: Ia5611a1f36ffa0a27ef5973296674f743fe80f65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113137
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Use 8-bit palette instead of 4-bit when reading from XPM. Modify
the test to expect bit-count 8.
Change-Id: I7b8e8254ad58cdda0829baea75809aa8596090e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113134
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Writer's testTdf90069 was failing if there was the documents font
actually installed. If glyphs for layout are cached, it is still
necessary to do the fallback, and that needs setting the fallback
as needed.
Change-Id: I32bf453d2e46fd8f1cf53a1298d0bc4195a1b78c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112774
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Code that needs to lay out texts repeatedly can cache the result
of SalLayout::GetGlyphs() can reuse it. But GetGlyphs() returns
nullptr for MultiSalLayout, so caching for it doesn't work. Worse
still, it actually increases the number of layout calls, because
there's the initial layout for caching and then each call
will need to do the layout again because of the nullptr that's
not cached.
This commit changes SalLayoutGlyphs to possibly include multiple
SalLayoutGlyphsImpl objects, one for each SalLayout handled
by MultiSalLayout. Changes include making GenericSalLayout
work directly with the Impl class, which avoids an indirection
and simplifies code.
Change-Id: Ic4b19934a8a06d4955b51527fe3777c5e91107b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112590
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
basegfx::utils::mergeToSinglePolyPolygon() appears to have rounding
problems. Point coordinates are in pixels anyway.
Change-Id: I9880cc32f934a08923a5c59278f6aa07852c05f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112647
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The original idea for delayed scaling was that if a bitmap is to be
scaled, only the parameters will be saved and the pixel buffer
mBuffer will be resized only on-demand. But this gets complicated
by mImage sometimes not being just a cache of mBuffer, but sometimes
it is the only data. This is needed so that e.g.
OutputDevice::GetBitmap() can operate only on SkImage without
possibly ever needing a conversion to the pixel buffer, thus even
keeping the data only on the GPU in the Vulkan case.
Together with delayed scaling this means that the size of mImage
can be either the original size (if Scale() is called with mImage
already valid) or the final size (if mImage is created in
GetSkImage()). Thus relying on 'mPixelsSize != mSize' as
a detection of pending scaling does not always work for mImage.
Handle this by using mImage dimensions in cases where relevant.
Change-Id: Id9fad67b8936d2266c1f270d08023d15efee3987
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112545
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Bit count for the image is a numeric value (sal_uInt16) but only
a handful of values make sense - namely 1,4,8,24 and 32. This
replaces the numeric value with an enum, which only accepts those
values and checks the correct values are used at compile time.
Change-Id: I0fc137c62bce3b0d021f05019a1648da628521bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112408
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
PNGReader is a home-made PNG reader that does not use libpng,
so it's more code, presumably less optimized and it apparently also
doesn't always map colors properly.
The only two features it has that PngImageReader doesn't are explicit
chunk reading (used only for reading Microsoft's GIF in PNG, I
implemented that for PngImageReader in a previous commit), and it
loads paletted images as BitmapEx with a palette instead of
converting to direct-color 24/32bpp or 8bpp-gray. The latter is even
questional if nowadays that's feature or a misfeature, as it saves
memory at the expense of speed. I can implement that if somebody
misses it.
I had to adjust some tests:
- CVE-2016-0952-1.png - invalid CRC of the PNG header, neither Gimp
nor Gwenview can display that, it should fail
- afl-sample-Z_NEED_DICT.png - failure while decompressing data,
but the loader considers that only a partially broken image since
the header is correct, so it "passes" (like in Gimp or Gwenview)
- SdImportTest::testTdf134210() and
testPictureWithSchemeColor::Load_Verify_Reload_Verify()
need the colors tested changed, because apparently gamma correction
or something is now applied correctly, and it wasn't before (again
checked the loaded images with Gimp)
Change-Id: Id46f8d8a01256daf48ca64264b47c4e609183837
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112042
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...that had been added by 0c36f364b1 "tdf#138122
Detect window scaling for multi display configurations on macOS" and should have
been removed again by 06d918dcc4
"loplugin:unreffun (macOS)"
Change-Id: Ibac8fc2cae101c2c16715be97406d769f82bd3eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112158
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Miklos Vajna