With previous implementation the ARC, ARCTO and CHORD were
not displayed if the corners of rectangle was switched.
With this patch the shapes are always displayed correctly.
Change-Id: Ie8ac7af812298c0b96c3b5af417117784f128ce1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115757
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With this commit the ROUNDRECT is able to change line width and
transformation (including rotation) is supported.
Change-Id: Ic303a74adf0fd0dd452353f250a13140603d492e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115429
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With this commit the rotation support was added
for INTERSECTCLIPRECT.
Before that change rotation was not applied to these CLIP rectangles.
Change-Id: I3da66790e0aeeaaeeb28d2fc30780cba8dbda390
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115102
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Previous implementation of EMR_ELLIPSE, doesn't support rotation
and EMR_ELLIPSE was not work with EMR_BEGINPATH, EMR_ENDPATH and EMR_ABORTPATH
The EMR_BEGINPATH opens path bracket construction.
Once path bracket construction is open, an application can begin specifying records to
define the points that lie in the path. Path bracket construction MUST be closed by an
EMR_ABORTPATH or EMR_ENDPATH record.
With this patch all these issue was resolved for EMR_ELLIPSE
Change-Id: I6d352e0ff0326dd788d43272bf1330fa6c777df4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115101
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Previous implementation of EMR_RECTANGLE, doesn't support rotation
and EMR_RECTANGLE was not work with EMR_BEGINPATH, EMR_ENDPATH and EMR_ABORTPATH
The EMR_BEGINPATH opens path bracket construction.
Once path bracket construction is open, an application can begin specifying records to
define the points that lie in the path. Path bracket construction MUST be closed by an
EMR_ABORTPATH or EMR_ENDPATH record.
With this patch all these issue was resolved for EMR_RECTANGLE
Change-Id: Ic51442df8905e47c92eed811cc776762c9752af2
Change-Id: I111f183e509f03c0b276a038680f61156b37b235
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115065
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
'make check' now passes for me without pdfium, all relevant tests are
annotated to skip asserts when there is no pdfium anyway.
Change-Id: Ie22a2b3b42d16e72f9d34ada85dee264d79d5155
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114523
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The EMR_FILLRGN record fills the specified region by using the specified brush.
After deep analyse of [EMF] documentation, it seems that
bounds from RegionDataHeader was treated as first rectangle of
region. As a result whole bounds was treated as the Region.
Change-Id: Ie34877b71292c05a1f17381a6de51aaed2386565
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113423
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
According to [MS-EMF] documentation:
"If the pen type in the PenStyle field is
PS_COSMETIC, this value MUST be 0x00000001."
Unfortunately based on observation of EMF import,
it seems that it is not true. As a result the implementation
must be partially reversed.
Change-Id: I0c2ec5e26b710e1a12d5196b6c8be4709f26dc4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112651
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
The test tested for the topleft corner to be transparent and not black,
but the bitmap has a black outline, so the corner actually should be
black, unlike the rest of the bitmap. I have no idea how the test
could have possibly passed (and those #if tests indicate that it
correctly failed with most drawing backends). What apparently enabled
this to pass was commit 828504974d, which made the drawing
use DrawTransformedBitmap() implementation in the VCL backends,
and the Cairo one apparently mishandles it. Reverting 828504974d
made the test fail.
This commit fixes (and simplifies) the test.
Change-Id: I1560849d683558abbe0cde816c4505b9824a0692
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110769
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Split class functions into BitmapInfoAccess.cxx, BitmapReadAccess.cxx
and BitmapWriteAccess.cxx
Split header files into BitmapInfoAccess.hxx and BitmapReadAccess.hxx
Change-Id: I7dcbe1d26c5b64d297658a6b809c93d7ad7f053d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108039
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
When the PS_COSMETIC line style is set in CREATEPEN,
line width should be set to one logical unit and a style that is a solid color
This patch is fixing that, allowing to properly import EMF file.
The corresponding unit tests were added
Change-Id: I1a0caf6382d9c313d9725d0b94e2fcd37122a099
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105790
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
To properly import some EMF files, the proper implementation of MapMode Text
needs to be done according to MS documentation.
I have also added regression tests.
Change-Id: Id788294a498b93bebb62118d13ea545f80a60f01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105771
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Commit d75c5b3891 (tdf#136836 emfio: speed
up import of EMF import when the orig PDF is available, 2020-09-17)
improved both performance and correctness of the EMF import, in case it
had a PDF fallback.
It turns out that PDF fallback can be nominally non-transparent, and
still the EMF equivalent supports transparency.
Fix the problem by enabling transparency in the PDF-in-EMF case.
Change-Id: I4d1585a5db6f28bd9c9cb380b5f193f4d5edcc8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104849
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The bugdoc has a shape, its bitmap fill is an EMF, which is actually a
PDF. The PDF is has a height of 5cm, but the shape has a height of 14
cm.
Inform vcl::RenderPDFBitmaps() about the size of the shape, so the
result won't be blurry. This approach makes sure that we don't
unconditionally render at higher resolution, i.e. the "load a PDF of 100
pages into Online" use-case won't use more memory than before.
API CHANGE, because the EMF reader is only available via UNO, though
it's likely that no actual external code would ever invoke it directly.
Change-Id: If1d8def0136d408a31a0cc54777a7f26430a0ff3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102996
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
drawinglayer::tools causes conflicts with ::tools namespace, so
better to move Primitive2dXmlDump out from this namespace as for
inspecting purposes it ccan be injected into existing code which
could break make it conflict and break compilation.
Change-Id: I5f9e594b2b8b1dd24067fa5f5ca3cfc4eefb85cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98627
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Files which could become clang-format conformant with
under 5-percent lines of change relative to the total
count of lines in the file are found by using bin/find-clang-format.py,
and fixed with /opt/lo/bin/clang-format -i <path-of-the-file>
There will be follow-up patches to fix all 'under-5-percent' files.
Change-Id: I06087a1385ca9da6a28d36ea4c0d2e40bdbf8f03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88774
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I644bbebe798329e68665b8c751eccbb829178e91
Reviewed-on: https://gerrit.libreoffice.org/85182
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This depends on commit "Make font-based unit test depend on instdir
fonts, not that it's sure that this really fixes the problem, as its
origin is really unknown.
It especially enables all the font-based tests I could find on all
archs. Same for many more test where I couldn't see any reason they
don't work generally. To get rid of even more ifdefs, it moves these
from the class to the functions, so there is actually just one needed
for any test. As a result some few tests run but do nothing.
There is still some problem with embedded fonts on MacOS and with
delayed graphics loading on Windows, so these ifdefs are kept.
Change-Id: I63f8424e9debda6cbf3e5777c93245e09f8eb0f2
Reviewed-on: https://gerrit.libreoffice.org/74719
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Also needs extending the XmlWriter to output double numbers as
the attribute content.
Change-Id: Ie749ea990d856c8c90092ed8153c24efda99c444
Reviewed-on: https://gerrit.libreoffice.org/67573
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This is very useful functionality, this way it can be invoked from the
debugger and/or nested into an outer xml dump (sw/sd doc model dump)
more easily.
Change-Id: If6c83b11d0f3e65fcce71e8d820c6bc354f64d68
Reviewed-on: https://gerrit.libreoffice.org/65834
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
While we are drawing DrawString record, in most cases optional
StringFormat information is available.
If StringFromat information is available then we should use default
values.
For LeadingMargin for String the default value is 1/6 inch.
Change-Id: I4a0a68df5ebe74e810f8b5864232b477b3aac255
Reviewed-on: https://gerrit.libreoffice.org/62927
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Added rotation support for DrawString and DrawDriverString
The EmfPlusDrawString record specifies text output with string formatting.
The EmfPlusDrawDriverString record specifies text output
with character positions.
Now both EMF+ records properly support rotation.
Change-Id: I15a7a6dd2b8a209cf2aac2af75d7dd89cedd1aeb
Reviewed-on: https://gerrit.libreoffice.org/62783
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
This unit test sometimes fails on Windows with the message:
"no suitable windowing system found, exiting."
Currently the test just depends on desktop_detector and manually
sets up VCL duplicating a lot of code and even library symbols.
The original Gerrit change describes a lot of failures in its
comments (change 28322, version 16). Now that Windows and MacOS
were converted to VCL plugins, depending on desktop_detector is
not sufficient anymore.
This reverts a lot of VCL test setup from commit 20f6a6b159
("tdf#99402: fix Metafile Font handling"). Seems now a simple
gb_CppunitTest_use_vcl is enough.
Change-Id: Ia941ded91358231021741ff4a5d96e2014ac6c80
Reviewed-on: https://gerrit.libreoffice.org/61497
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
With current EMF+ implementation all filled figures,
does not support transparency.
This patch add transparency support for following EMF+ records:
- DrawDriverString
- DrawString
- FillEllipse
- FillRects
- FillPolygon
- FillPie
- FillPath
- FillRegion
Change-Id: I1e59ea90bdf5fafc07ff9417fccace44872bbecd
Reviewed-on: https://gerrit.libreoffice.org/50609
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable
loplugin:cstylecast for some more cases" plus
solenv/clang-format/reformat-formatted-files
Change-Id: Idffd3ef04b007f04b7022e54881254da9b2aa4a0
Two unit tests, which test the EMF+ records DrawString and DrawLine
independently.
To this end, a fixed view decomposition of metafiles is implemented.
The chosen primitives should be optimal, even for future extensions
of the EMF+ parser.
Change-Id: I12672d3b294ff0fdae63c7a5ce211517ef8f763c
Reviewed-on: https://gerrit.libreoffice.org/41425
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
The CppunitTest_vcl_filters_test was not working due
to a wmf file now being loadable. This leaded to better
check errors on stream and react on it in test code.
Hrad to find since that test - for whatever reason - is
not executed on win. Also need to check result of
EmfReader. Added emfio to test's module list
Change-Id: Iea2b835408e919a8456e8f178cbfc782885ffebb
Needed to migrate UnitTest for Emf/Wmf import from
vcl to emfio. Corrected stuff based on gerrit build
feedback
Change-Id: I7fd2456f814ea19583072ba09730a07e9b9d4061
First steps to organize an importer that can read/interpret
wmf/emf/emf+ and deliver a primitive representation for
the content by parsing it. Use the same mechanisms as
already applied for Svg, so to reuse abilities to keep
original binary data to allow save again and embedding in
files and have an implemented replacement bitmap based
representation. For this, unify the used helper classes
to handle more than just Svg. For 1st try, add test code
and static bool switches
Change-Id: I6e0a82943541d811a8f8d65a84115569fcd8cee7
Bartosz Kosiorek