Age | Commit message (Collapse) | Author |
|
Change-Id: I21e01f63da1c95c3a2c8bae9b998a28fc0a27bc1
Reviewed-on: https://gerrit.libreoffice.org/73560
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: If31cf3c02ab714f45ebbc0139e0e77102b5eb2ba
Reviewed-on: https://gerrit.libreoffice.org/73325
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia6ecd04b81abb751bd7159ca8432c00f97ab5e2d
Reviewed-on: https://gerrit.libreoffice.org/72407
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
BitmapColor itself is kept to distingish the Color usage as part
of a color palette, which continues to store the offset in the
blue value. The original special mbIndex handling is long gone
since commit 1fefdd6f3b41 ("Alpha channel in BitmapColor - change
bIndex to alpha"), so there is no data difference.
This also results in the following changes:
* now has a basic_ostream<charT, traits>& operator<<
(that was my actual starting point... for an other bug fix)
* there is a minimal difference for GetLiminance
BGR(29,151,76) => BGR(28,151,77)
* no more return values for Merge and Invert
(previously returning *this)
* replaces all GetBlueOrIndex with GetIndex
This leaves one "problematic" part: the GetColorError handling.
At first glance it should probably be virtual. The Color variant
is less strict then the BitmapColor one - for whatever reason.
BitmapColor is always used to search for the best match in a
Palette. Currently I'm simply leaving both variants. Would be
nice to have an explict for functions here.
Change-Id: I251ba3024a1d60f2a9d9fde9cd0a60f08e8322a7
Reviewed-on: https://gerrit.libreoffice.org/72181
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Currently we detect a graphic format in a ImpPeekGraphicFormat
method, which is called when reading a graphic from a stream.
The code is quite convoluted and doesn't help with readability
of graphicfilter.cxx
Additionally there exists an detection code written for the UNO
class GraphicDescriptor, which duplicates the detection, but can
in addition also extract other metadata at the same time.
This introduces the initial implementation of GraphicFormatDetector
class. It will first replace the code in ImpPeekGraphicFormat
to detect the graphic format and then later also be extended to
do what the GraphicDescriptor is doing. But currently it only
duplicates the implementation of ImpPeekGraphicFormat.
The problem with both of the current solution is that there are
not any tests written. For the GraphicFormatDetector however the
approach is to add test cases to check the current implementation
and only then refactor the code.
Change-Id: Idb9d3859b4380e3f15237d97aff969ce81e631dd
Reviewed-on: https://gerrit.libreoffice.org/72086
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This is intended to replace the ImplPixelFormat in macOS and
OpenGL backends, which are duplicated. It'll also come in
handy for other situations in the future.
Also ImplPixelFormat4 (4-bit Palette) in the macOS backend
doesn't work and never has worked correctly (bug at writing).
This fact was discovered while testing the ScanlineTranformer,
which was based on the ImplPixelFormat* code.
Change-Id: I96a172bd61c2cc116ab3e8b9f47f23f945243e96
Reviewed-on: https://gerrit.libreoffice.org/71992
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
...after 7764439f85f23efb4510b41e795abd1e4c9089e9 "WidgetDefinition: add
'action' state for the PushButton" introduced code that downcasts that
suspicious ImplControlValue to a PushButtonValue
Change-Id: I3ed24cc4a862d53ad5b6e95b4707bab7947ce7ba
Reviewed-on: https://gerrit.libreoffice.org/71998
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
|
|
Change-Id: Ic4c0977357d7c4feb4100eeb15a6e9a4866374d3
Reviewed-on: https://gerrit.libreoffice.org/71554
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia927070883e5647b61876e31d6a0a085e2456f8a
Reviewed-on: https://gerrit.libreoffice.org/71498
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I58b7bb114864a9fdf901a92d54717964c6f1b68e
Reviewed-on: https://gerrit.libreoffice.org/71497
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id130dd7739b9662541b50b7792da170da70a6a9b
Reviewed-on: https://gerrit.libreoffice.org/71496
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I51bd172cdd22d55a6800d1e74e38149874629f85
Reviewed-on: https://gerrit.libreoffice.org/71495
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Icce9c3c5fa826b6f5237d2d0e28fc51555a3e267
Reviewed-on: https://gerrit.libreoffice.org/71494
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I96113168d4ae8289cec3a5b0bbd6aa79faf97c48
Reviewed-on: https://gerrit.libreoffice.org/71493
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ic0f143ea6871965a5d1e9db4b35db88f8adb5181
Reviewed-on: https://gerrit.libreoffice.org/71491
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The UI default is in the SwForm ctor, where the content type sets the
link start char style to STR_POOLCHR_TOXJUMP.
Have the same default in the UNO API in case the import filters don't
set it explicitly, since that breaks clickable hyperlinks on PDF export.
This also fixes the OSL_ENSURE() failure for missing character formats
in SwTextINetFormat::GetCharFormat().
Change-Id: Ifff354d56a569614ca7f5a89dd75f41817300078
Reviewed-on: https://gerrit.libreoffice.org/71366
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I1f46c6043b3263ef983991ffa4aa0418006d55a7
Reviewed-on: https://gerrit.libreoffice.org/71292
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ifdee7c4bd9ed3306530c7bc4ecf3017008e90c3d
Reviewed-on: https://gerrit.libreoffice.org/71215
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
has high failure rate on jenkins
Change-Id: If429483face1c118ec3bdfed86cf9b84a23e7e0b
Reviewed-on: https://gerrit.libreoffice.org/71040
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia771aff267005b32364c441c41be22160009e4e3
Reviewed-on: https://gerrit.libreoffice.org/70970
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Windows Tinerbox fails because of rounding error in blending
(but only in some environments), so allow for a small rounding
error in colors.
Change-Id: If45ae99a445e9d6f795d06d88c902a723913b9a6
Reviewed-on: https://gerrit.libreoffice.org/70932
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I92ce3bbcd7e7d52c53b70a1b9339c2e110c2ccbb
Reviewed-on: https://gerrit.libreoffice.org/70926
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id0222c9f6a7ef04ed46dc5ceacd814619b4d7c21
Reviewed-on: https://gerrit.libreoffice.org/70912
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ibd28b8fa92e98ebeb482a9081fbeae24defe4adb
Reviewed-on: https://gerrit.libreoffice.org/70826
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Greyscale conversion with OpenGL results in RGB values sometimes
having color components one off compared to the normal VCL values,
so be a bit lenient.
Change-Id: I58c279fb90e540cd2ac76d4217c774ff09229051
Reviewed-on: https://gerrit.libreoffice.org/70778
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Related to tdf#105277, check that scaling a bitmap with different
scale methods and different bitmap sizes produces (roughly)
the expected results.
Change-Id: Iea9be675b7cc4b0fbbc634501d32ded82bccbb17
Reviewed-on: https://gerrit.libreoffice.org/70775
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The bitmaps have different CRC, because OpenGL uses different algorithm
and data format.
Change-Id: Ic4d2e6215cfc6b971b470367002936f4a81e9fbe
Reviewed-on: https://gerrit.libreoffice.org/70777
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The two blocks are identical.
Change-Id: I58464160009d1276bd1ca92482cd677c00471251
Reviewed-on: https://gerrit.libreoffice.org/70776
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This adds an test for a VirtualDevice with an alpha channel,
which checks that getting a BitmapEx from the alpha VirtualDevice
is has a alpha channel properly set.
Test that using GetPixel and DrawPixel properly handle an alpha
based Color, which they didn't, so this also includes the fix for
thouse 2 methods.
Change-Id: I419b8e0f66ab5f8266c6129e501ed75ef517fd44
Reviewed-on: https://gerrit.libreoffice.org/70805
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This adds a test for drawing a BitmapEx which has an alpha channel
onto a VirtualDevice. Most important is that alpha blending is
done as we expect it (but it is prone to rounding error).
Change-Id: I41a16ca9da98d7a067ada9aafad8c9fc7c6484d5
Reviewed-on: https://gerrit.libreoffice.org/70804
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0c1b8447acd6681d8731c35412b90a00741274fa
Reviewed-on: https://gerrit.libreoffice.org/70803
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This (finally) adds backend tests as CPPUNIT tests too. In the
future they'll also be added into LibreOffice directly as a way
to test if the backend is OK, which will be useful especially
for the OpenGL backend, which draw quality depends on the driver.
Currently all the tests are ignored because of the bugs in the
backend, which need to be addressed first and tests then can
be enabled one by one.
The main reason for the test is to identify issues when drawing
is done at a wrong position, which is a very common problem. Also
other types of tests will be added in time, which will have a big
role in the refactoring of VCL that will happen in the future.
Change-Id: I92237d47d49fa0db01b73b8bc39f7a621b65961e
Reviewed-on: https://gerrit.libreoffice.org/70769
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I4f142586ceedb8f51610139db914845892f65d2c
Reviewed-on: https://gerrit.libreoffice.org/70728
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
V522 There might be dereferencing of a potential null pointer.
Change-Id: Ie4bc74a734a6d5a73838a27e0d80cc8e51595839
Reviewed-on: https://gerrit.libreoffice.org/70730
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The old approach was to calculate the number of stripes of the
bitmap per thread and later create the exact number tasks
(ScaleTask) as there are threads, where each task would process
stripes it had been given. This is needlesly complicated as the
job of a thread pool is to properly delegate the tasks between
threads. This was now changed so that we create one stripe
per ScaleTask and let the threadpool delegate the tasks to its
threads (that are available).
It also wanted to be clever and use the main thread to do the
work also, but it had a major flaw. The threadpool started to
process the tasks only when "waitUntilDone" method was called,
but the code first processed its slices and then called the
threadpool method to start processing. Because of this the
performance of scaling wasn't as good as it could be.
This behaviour was now changed so that the main thread isn't
involved in processing. It just creates the task, runs the
threadpool and waits until the tasks are finished.
Change-Id: I1e8c733bdbced8867d0a7f1190f0421a0cc3e067
Reviewed-on: https://gerrit.libreoffice.org/70668
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
There were some changes since last run and some omitted files
Change-Id: I666ac8ed7d06684e252ca590e3d7d454e9e10975
Reviewed-on: https://gerrit.libreoffice.org/70497
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Hopefully fixes problems on 32-bit linux.
Change-Id: I1fc22f1bb37c8297bd3bd6828206d1ffa9ae722d
Reviewed-on: https://gerrit.libreoffice.org/70241
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This adds basic support for 32bit bitmaps for the SVP backend. For
other backends the support is disabled for now as we need to add it for
each backend separately and enable support.
When this patch is applied it is possible to a Bitmap with bit count
32, but currently no input filter uses this with the exception of the
new PngImageReader(libpng based), which is used only for the icons.
For a general support more things need to be implemented and tested:
- conversion back and fourth between 32-bit and 24-bit + 8bit alpha (or
other supported pairs)
- 'raw' export of the bitmap needs to be handeled properly (like in
SVM import/export) so it creates the correct image.
- input filters need to be checked and converted if this is necessary
- look for possible bugs when drawing transparent bitmaps
- check of UNO API
Change-Id: I7a7be0e6134dfdd9a7aeaef897131bb6e710ae7e
Reviewed-on: https://gerrit.libreoffice.org/69289
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id78ef9fd05bc158b52aa465c932869c0ef1c55d7
Reviewed-on: https://gerrit.libreoffice.org/69921
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I83d7f1f28c7b0dc707ef26675449d5f3654dacda
Reviewed-on: https://gerrit.libreoffice.org/69922
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Visible at e.g. in Calc: Format Cells/Borders/Line Styles.
The problem was that first commit
2e99e4e11d33679aed674eea0d6054d16d39d6df (opengl: use MVP matrix in
vertex shaders, pixel offsets, 2015-07-08) introduced the concept of
pixel offsets, setting the value (implicitly) to 0 in
OpenGLSalGraphicsImpl::DrawTrapezoid(), but using 0.5 in
OpenGLSalGraphicsImpl::FlushLinesOrTriangles().
This is fine, but then later commit
2003076c4318511a3d621558d3b44b4e8e6c6529 (opengl: batch draw
polypolygons, 2016-05-29) changed
OpenGLSalGraphicsImpl::drawPolyPolygon() to use deferred drawing instead
of DrawTrapezoid(), without doing any translation of the input
polypolygon. This resulted in loss of those polygons when used in the
above mentioned dialog, which has a listbox of bitmaps, where each line
style preview is drawn on a virtual device with a height of 1px. So at
the end the 1px offset meant the previews were simply missing.
('make CppunitTest_vcl_gen SAL_USE_VCLPLUGIN=gen SAL_FORCEGL=1' is
needed on Linux to see the test failing without the fix.)
Change-Id: Ia9f3d6e7cb38a43fe2f8a41746b538af68add43c
Reviewed-on: https://gerrit.libreoffice.org/69920
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This is a simpler check for 77146ca8193a8e258dbb0dae0793497a66734ff1
(related to tdf#121615).
Change-Id: I33b92f07bebeb735466e0728c6c51b79fc0b5bb8
Reviewed-on: https://gerrit.libreoffice.org/69820
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This checks what I fixed in 1893024c54ab173ec6262d77a05cad285c17a617
(related to tdf#116888).
Change-Id: I721017fd037d62ba75cbc962fdd9316e02085624
Reviewed-on: https://gerrit.libreoffice.org/69819
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
The missing case caused BitmapReadAccess to work with random data
(together with a follow-up bug that didn't deallocate data properly
after ReadTexture() failed).
Change-Id: I4546ee4ca85d6a0b01cc41636c257008c9f19587
Reviewed-on: https://gerrit.libreoffice.org/69745
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
I'm not sure why #if HAVE_MORE_FONTS guard is not enough, but in any
case, the purpose of the test is to see if the final assert succeeds or
not, so if layout fails completely, that's not interesting here.
Change-Id: Ie663f82b86e101167cd7317d25345b2d48960cbb
Reviewed-on: https://gerrit.libreoffice.org/69736
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Icef900e75255d477812a198fdb29e0cdebba35b8
Reviewed-on: https://gerrit.libreoffice.org/69654
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
If the bitmap to be written is non-8bit, e.g. in case of using OpenGL
(on Linux the test requires "SAL_FORCEGL=1 SAL_USE_VCLPLUGIN=gen",
on Windows it's probably the default case), then the bitmap is not
in native format for 8bit. This was done correctly by 45e8e0fbee40f
that introduced it but somehow it got lost later (I can't even find
where).
Change-Id: Ib1810cb9cf12e373c1cb41da40fa28e96ad7db28
Reviewed-on: https://gerrit.libreoffice.org/69213
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This was broken because GenericSalLayout::LayoutText() sets the
SalLayoutFlags::KashidaJustification flag as a side-effect of building
the glyph list. So in case we cache the list and not build it, the flag
will be missing. This means that later in
GenericSalLayout::ApplyDXArray() kashida glyphs won't be inserted.
With this, the workaround in sw can be removed.
Change-Id: Ic18211bf50ca673daa238e8950a381915e4b3096
Reviewed-on: https://gerrit.libreoffice.org/69566
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Fix regression from:
commit dc9ee533dc707cc10b99d537eaccc3ee5aa555fe
Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Date: Fri Jun 15 19:32:15 2018 +0200
vcl: parser of font features included in the font name
Where hb_feature_from_string() was replaced by a simple parser that supports
avery limited subset of the syntax it supports (as documented in
https://harfbuzz.github.io/harfbuzz-hb-common.html#hb-feature-from-string)
Change-Id: I613190a677d24183e8c718fcfcaf9cf9b37a1e8f
Reviewed-on: https://gerrit.libreoffice.org/69062
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
Tested-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Also adds support for signaling if arrow points up or down, which
is signaled through extra attribute.
Change-Id: I5a87cdb31e18150495df521bf925c7b983e2313a
Reviewed-on: https://gerrit.libreoffice.org/69013
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|