As EmfImportTest.cxx code style is follow the recommended
code style (except too long lines), the code
is used only for testing and it is rarely modified,
I decided to enable automatic code formatting.
It is one step closed to migrate to common code style.
Change-Id: I1b7f980b9e68e121ba981b8a8222daa31424ac53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118864
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Commit 574dc1e8ff (EMF+ tdf#142995
tdf#142997 tdf#143076 Add alignment support for DrawString, 2021-06-24)
added this test, it seems the result depends on what fonts are
installed, so add some tolerance.
Probably it fails for me (and not on Jenkins) as I have lots of
additional fonts installed, e.g. Arial (and not only Liberation Sans).
Change-Id: Ie93d1f1efe1fbbf1851ad46f33f5f83c8812e6d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118470
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The SrcRect could be specified outside of source bitmap.
In such cases the Destination bitmap should be displayed as shifted
(eg. if position is negative), and scaled properly.
Change-Id: Ied6d339703999faaae061802ef6a28e190d5a176
Change-Id: Ia9772ced282684c2c94a261d97d30b53921d6171
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118345
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With this commit, real size of the text is used to make
proper horizontal alignment. Additionally vertical alignment
is added and fix for Center alignment was applied
Change-Id: I17d9fd7de7f00f5e69f99c5b09061eb6059be67e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117794
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With previous implementation, the RestoreDC index argument was skipped,
and always the last entry was taken.
With this commit the support for reading SaveDC by specific index
was added. The SaveDC/RestoreDC index support was added for
both EMF and WMF, according to [MS-WMF] and [MS-EMF] documentation.
Change-Id: I9b8a1a41462ae01de25ac3c85e453bcd80e05537
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117033
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With previous implementation, only BitBlt record with 1 bit color depth
was supported and StretchBlt was not implemented at all.
With this commit the support for 1 bit, 24 bit and 32 bit,
for both BitBlt and StretchBlt were added.
Change-Id: I061b2beae8c2f143ddff9c8c8bb64bf52f4cf502
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116873
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Additionally the names of variables were improved,
and additional checks were added for unsupported cases
Change-Id: Id84ef1218c5c2a40c8d01f2d40857d892badbb9f
Change-Id: I1b8571d0a627827bc1e67c2bfc6c1932d58c5233
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116744
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
In previous implementation if BKMode was set to Transparent,
then both Background of Text and Rectangle was not drawn.
It was wrong, and Rectangle should be always drawn.
This commit fix that issue and allows EMF images
exported by LTspice to be rendered correctly under LibreOffice.
Change-Id: I03801d35d92eb2a3fdc175ca1d5b348a2aa30842
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116394
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With OPAQUE option enabled, the rectangle need to be drawn,
before drawing text.
With CLIPPED option enabled, the text needs to be drawn
only inside rectangle.
In previous implementation, the rectangle read was skipped and
it was not drawn (for OPAQUE).
For CLIPPED the rectangle was read but Clip was not applied
to text drawing
This commit fix that issues, and allow to draw rectangle correctly,
with BGColor (background color), and add support for Text Clipping
according to [MS-WMF] and [MS-EMF] specification.
The fix applied to EMR_EXTTEXTOUTW, EMR_EXTTEXTOUTA and EXTTEXTOUT records
Change-Id: I0f6248bb9465e6d5f797cddb53f058afb0815a2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116072
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
The issue is caused by floating numbers,
On x86_64 it is:
338.499728160392-445.269903703769
on arm it is:
338.499728160392-445.26990370377
As in test files, we have two ellipses (which are made from small lines),
which points rounds differently on different architectures
Change-Id: I44dd5c7b3b13f3b1680d5a3a8348d6f467cb2f7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116270
Tested-by: Jenkins
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
So the issue is caused by floating numbers,
On x86_64 it is:
338.499728160392-445.269903703769
on arm it is:
338.499728160392-445.26990370377
As in test files, we have two ellipses (which are made from small lines),
which points rounds differently on different architectures
Change-Id: I10efe80fea0944cf957e949c8c209c94fd588702
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116234
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
In Metafile specification, if Start Point is the same as End Point,
then the full circle should be drawn.
Unfortunately with previous implementation, if Start Point is the same
as End Point, nothing is drawn.
This patch fixes that and removed EDGES optimizations, which causes
display issues.
Change-Id: I16a1b98f10378d57bed59696db6cc9f228044292
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115891
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
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>
Bartosz Kosiorek