[MS-EMF] 2.3.2.2 says the RegionData field "MUST be ignored" when
iMode is RGN_COPY, but real EMFs include data with RGN_COPY and
expect the clip to be replaced with the given region (verified
against MS Word reference rendering of test files such as
TestCreatePen.emf and a chart EMF where the colored plot lines
were leaking outside the plot frame). Treat the record like the
Win32 ExtSelectClipRgn API: a non-NULL region with RGN_COPY
replaces the clip, a NULL region (cbRgnData == 0) with RGN_COPY
resets the clip to the default null region.
Add a minimal hand-crafted EMF (TestExtSelectClipRgnCopy.emf) that
draws a (0,0)-(200,200) rectangle through a (50,50)-(150,150)
RGN_COPY clip and asserts the imported metafile wraps the rectangle
in a clip-region mask matching the requested rectangle.
Update existing test expectations to reflect the new clip-region
group/mask wrappers that now appear in the metafile primitive tree
where RGN_COPY data is present (testCreatePen, testPolyPolygon,
testTextMapMode, testEmfPlusSetPageTransform,
testDrawImagePointsWithMetafile, testSine).
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: Id123157b64b75d817b4736443eac14804b04bb89
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2206
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 1c2ff94b6079451a7047a2afb45467d6fe31cb4f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205072
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
DrawPolygon and DrawRect already route Pattern fill style through
ImplEmitPatternFill, but DrawEllipse, DrawRoundRect, DrawPie,
DrawChord, and DrawPolyPolygon still emit their plain Meta*Action
which leaves the shape unfilled. Route Pattern fill through the
helper for those too, converting the shape to its polygon
equivalent and emitting the clipped MetaWallpaperAction.
Add a unit test that draws an ellipse with a DIB pattern brush and
asserts the wallpaper is emitted in the metafile dump. Without the
fix the ellipse renders as a hairline outline only.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I2d4e273029770ddc727bc24d9b3205fe079fafd6
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2205
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit e87013a0457d270d442841610f4a3430e82f1274)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205041
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
UpdateFillStyle short-circuits when maLatestFillStyle == maFillStyle,
but for a hatched brush the emitted MetaFillColorAction depends on
mnBkMode (bk color when OPAQUE, transparent when TRANSPARENT). With
no brush change between two rectangles separated only by SETBKMODE,
the second rectangle inherits the previous OPAQUE bk color fill, so
the gaps between hatch lines stay opaque.
Make SetBkMode invalidate maLatestFillStyle.aFillColor (using the
same sentinel that ResetInternalState uses) when the mode actually
changes, forcing the next UpdateFillStyle to re-emit a fresh
MetaFillColorAction with the correct bk-mode-dependent fill.
Add a unit test with a minimal hand-crafted WMF that draws two
rectangles using the same hatched brush across a SETBKMODE flip
and asserts that both a #ff0000 (OPAQUE bk color) and a #000000
(TRANSPARENT) fillcolor are emitted in the metafile.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I34b8984989f3ce9108464ad5a8c379174a988b59
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2204
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 41ddf034e276a5493f4fd56be61702a8b28e9649)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205040
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
META_DIBCREATEPATTERNBRUSH with Style=BS_PATTERN was dropped on the
floor with a SAL_WARN, and BS_DIBPATTERN averaged the bitmap to a
solid color, so neither produced a real pattern fill. Read both
variants into a real Bitmap (DIB or, for BS_PATTERN, a 1bpp Bitmap16)
and store it as a Pattern WinMtfFillStyle. Real-world generators
emit a DIB even with Style=BS_PATTERN, so peek the leading DWORD to
decide between DIB and Bitmap16. The same Bitmap16 helper handles
the obsolete META_CREATEPATTERNBRUSH record (32-byte legacy BITMAP +
reserved padding per MS-WMF 2.3.4.4).
The Pattern fill type was only handled in DrawPolygon, and that path
emitted XPATHFILL_SEQ_BEGIN/END comments with no actual paint
primitives. wmfemfhelper does not consume those comments, so the
PNG/drawinglayer rendering path saw nothing. Replace the comment
emission with a clip-region wrapped MetaWallpaperAction (Tile style)
which is fully consumed downstream. Factor the emission into
ImplEmitPatternFill and call it from DrawRect too, where Pattern
was previously not handled at all.
WinMtfFillStyle::operator== did not compare aBmp, so successive
pattern brushes with different bitmaps but identical solid-fill
fields compared equal and UpdateFillStyle short-circuited, leaving
maLatestFillStyle pointing at the previous bitmap. Include aBmp in
the equality check.
Add a unit test with a minimal hand-crafted WMF that asserts the
expected wallpaper sequence in the metafile dump.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: Ia2662de9cac5fcf1a7153237f9974467b8f849de
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2203
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 66dcbef6b5ceec8d9ccd4542509d5f9d7fdce2c1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205039
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
When an EMF+ Dual Mode file switches back to GDI records via
EmfPlusRecordType::GetDC (0x4004), the GDI parser (MtfTools)
might have outdated information about the current state of the
VCL MetaFile, as EMF+ records could have modified it in the meantime.
By introducing ResetInternalState(), we invalidate the "latest"
trackers for fill style, line style, and text attributes. This
forces the parser to re-emit the necessary GDI actions (like
SetFillColor) for the subsequent GDI records, preventing issues
like incorrect colors (e.g., black shapes instead of white).
Change-Id: I1665daba2d9a2105f135e2b638af48d2b14150eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201720
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
The size of W_META_EOF (record indicates the end of the WMF metafile)
could be different than 3 (e.g. 6).
The MS Office is allowing different sizes of EOF,
and just properly finalizine parsing WMF file, and display its content.
Original bug report:
https://bz.apache.org/ooo/show_bug.cgi?id=42090
Change-Id: I21b72615c7f45fdca145e6240c6451d7d264d238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153204
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
When doing subpixel positioning (i.e. OutputDevice is in map mode),
delay the rounding of the glyph coordinates after converting from pixel
to logical units to minimize the loss of precision as much as possible.
Some test expectations, expectedly, changes due to the improved
positioning precision.
Change-Id: I2591e3c7d4923ba7886a35bf53db759273354e24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154292
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: خالد حسني <khaled@libreoffice.org>
It is so much easier to work with if a test failure's line number unambiguously
points at the code's sole execution. (That is, test code is necessarily non-
DRY.)
Change-Id: I75919c55671348f6190e9e108e72e24ec18ce986
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148514
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The reason for the blurry document in tdf#150888 is that the image is
tiny. PPI is 2540 in that image but when using the window bounding box
(96, 81) this results in a very small image that the .odt then scales up
which makes it blurry.
Apart from that, when opening the extracted .wmf in Draw it's also very
small, around 0.04" squared.
Because MM_ANISOTROPICs definition allows for arbritrary scaling, when
an image would be smaller than an inch squared the PPI is scaled down to
either the images width or height. This makes the extracted WMF match
the size of competitor office suites and fix the blur bug without
breaking past tests.
Change-Id: I11eab879848d9308f818708a91fd9eb91fc65200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141533
Tested-by: Jenkins
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
If the lines are created with MOVETO, LINETO, LINETO...
then Line Join NONE is applied. As a result the charts are looks ugly,
with the holes inside it.
For example:
https://bugs.documentfoundation.org/attachment.cgi?id=179962
and
https://bugs.documentfoundation.org/attachment.cgi?id=179837
Additinally commit changed default line join style to miter,
as during experimenting with MS Paint and MS Word,
it appear that default Join Style is PS_JOIN_MITER and
Line Cap is Flat/Butter.
The PDF export tests has been updated, as there is less number
of PDF object after using joiners.
The size of the exported tdf145873.pptx to PDF,
was slighltly decreased from 22.8kB to 22.0KB
Change-Id: I131cc3c5e90f827d67d2360eb18167eed6315abb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133624
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
The WmfTest::testStockObject() contained test for the number of
children in the metafile dump. This can be changed when unimplemented
records are implemented.
The problem was revelead while implementing SetPolyFillMode record:
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/112114/>
xmltesttools.cxx:234:WmfTest::testStockObject
equality assertion failed
- Expected: 42
- Actual : 47
- In <>, XPath '/metafile/push[2]' number of child-nodes is incorrect
Change-Id: I627801b7ac535a2f0c736880d9675f3d0136136a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133353
Tested-by: Jenkins
Reviewed-by: Hossein - <hossein@libreoffice.org>
This patch fixes tdf#148359 which prevented the display of EMF images
embedded in the rtf files or even loading when loading them directly.
Looking into the problem caused by the cleanup commit
3e7dd04dd8, it became visible that
while enums were converted to enum class, there was a cast that
was wrongly ommited:
- sal_uInt16 nStockId = static_cast<sal_uInt8>(nIndex);
+ StockObject nStockId = static_cast<StockObject>(nIndex);
Now, it is re-written as:
StockObject nStockId = static_cast<StockObject>(nIndex & 0xFF);
The symptom was that the StockObject field was mishandled, and thus
the shapes were displayed in white, instead of black.
"Stock Logical Object" is discussed in the MS document for EMF:
* [MS-EMF] v20210625 - pages 44, 45 and 182
A unit test is provided to make sure that the regression does not
happen again. The test can be run by:
make CPPUNIT_TEST_NAME=testStockObject -sr CppunitTest_emfio_wmf
Change-Id: I9a7f1008e92a96d9fb12aeb7bd057af828c1722a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132540
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This patch fixes problems caused by the cleanup commit
3e7dd04dd8 for type and calculation of
FamilyFont and PitchAndFamily enumerations.
FamilyFont enumeration is described in [MS-WMF] v20210625 page 33:
"In a Font Object, when a FamilyFont value is packed into a byte
with a PitchFont Enumeration value, the result is a PitchAndFamily
Object".
Thus, we will use sal_uInt8 as the underlying type for FamilyFont.
The PitchAndFamily is created as shown in [MS-WMF] v20210625 page 96:
[0 1 2 3] 4 5 [6 7]
Family 0 0 Pitch
The values for FamilyFont enumeration are created according to the
[MS-WMF], and the calculations are changed to use '<< 4' and '>> 4'
instead of applying the same shift to the enumeration values.
Change-Id: I4f6df33ed6405589acf89ba2c9223a571cb510b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132614
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Converted symbolic constants with #define in mftools.hxx to:
a) 'enum' where facing multiple values of the same category with
similar prefixes, or enums from the [MS-WMF] / [MS-EMF]
b) extracted the underlying integral type from the above documents
c) 'constexpr' where there was a single value
* Where possible, 'enum class' in 'emfio' namespace is used
* Some enums with binary or comparison operations are not converted
MappingMode, TextAlignmentMode, RasterOperations, PenStyle
CharacterSet, ExtTextOutOptions, PitchFont, FamilyFont, WeightFont
Change-Id: I144b2df4722e23d3b0c0aca7880cf603faa80686
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124099
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
the font name isn't a typical semi-standard one so it neither exists nor
has a standard fallback. binary-hack "Roman" to "Arial" which is
conveniently the same length and does have a standard fallback of
"Liberation Sans" which we can add a dependency on via more_fonts
Change-Id: I1d9b8294f67a00a1e5cabe38b71467e66b83aedf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129454
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(In each case, the name of the file is obvious from the surrounding
code, so there's no loss in not having CPPUNIT_ASSERT_LESS/GREATER_MESSAGE
available here.)
Change-Id: I5e4e1a30f6389f8b2801648a6179b574727f0859
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128116
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The problems in tdf#88163 can be categorized into two parts, as
described in d259060879:
First, the problem with the wmf files without the placeable header.
Second, the problem with the wmf files with the placeable header.
The above mentioned patch fixed the first part, and this patch fixes
the second part.
The problem was that upon seeing 22-byte placeable header, the
records related to the size of the wmf like META_SETWINDOWORG (0x20b)
and META_SETWINDOWEXT (0x20c) and others were ignored. These records
were read in WmfReader::GetPlaceableBound() for the wmf files without
placeable header. Adding this method for the wmf files with placeable
header fixed the wrong calculation of bounds, which previously lead
to wrong size of text.
It should be noted that the scale in the placeable header is used,
but the bounds are ignored for now.
A new test named testTdf88163PlaceableWmf() is added that can be
checked with:
make CPPUNIT_TEST_NAME="testTdf88163PlaceableWmf" -sr \
CppunitTest_emfio_wmf
Change-Id: I820c2e5922972cb5d555d98ef70c7581cd9f02d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122095
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
The problems in tdf#88163 can be categorized into two parts:
1. A regression which is caused by the commit
a9020e4618. The font size for text is
wrongly calculated for wmf files WITHOUT the placeable header.
2. A long-lasting bug that has existed from LO 3.5 (tested with
various LibreOffice versions from 3.5 to master). The font size for
text is wrongly calculated for wmf files WITH the placeable header.
This patch solves the first part. In this patch the way wmf is scaled
is changed using mnUnitsPerInch as a variable that controls the scale.
The previous method was dividing the left/right/top/bottom fields of
aPlaceableBound which caused the bad scaling of text.
The second problem still remains, and possibly can be solved by usign
the old scaling method that was previously used here (dividing pos
values of aPlaceableBound), but the scaling factor should be
calculated, which varies in different wmf files. More study should be
done to solve this part.
Values used for the example "visio_import_source.wmf" used in the test
WmfTest::testNonPlaceableWmf() are slightly changed, but the rendering
should not noticeably change, except the fix for the text font size.
A new test WmfTest::testTdf88163NonPlaceableWmf() is added which
checks for both font height and text boxes' positions. Font height
can depend on the exact font that is used for Roman in the platform,
so it vary between Linux, Windows and macOS. Thus, a range is used
for ensuring that the font height is correct.
By visual inspection, it is confirmed that this fix does not affect
fdo#74336 and the fix for it still works for attachment 93188.
Change-Id: I55bf38ba4345a0aa48c3e522976a2a5c32f7ec8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121272
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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>
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>
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 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
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>
Needed to migrate UnitTest for Emf/Wmf import from
vcl to emfio. Corrected stuff based on gerrit build
feedback
Change-Id: I7fd2456f814ea19583072ba09730a07e9b9d4061
Andras Timar