This reverts commit 1230b88055.
Reason for revert:
The reverted commit breaks the files documented in tdf#152435 (some
text is not shown in those .EMF files). The reverted commit would solve
an issue where some text was not clipped correctly, albeit in a naive
way. As it is more important that text is shown rather than some text
having correct clipping, that patch is reverted and I will look for one
that fixes both cases.
Change-Id: I42e85b802b8bf1e77e96f0016cd1d83201047032
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143970
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
EMR_SAVEDC would call UpdateClipRegion which would break the clip region
sometimes before drawing the text causing it to not be clipped
This line was introduced in a i#964 related patch
(https://bz.apache.org/ooo/show_bug.cgi?id=964)
The document in that test seems to render the same and the test file
from the changed test renders the same also before and after this patch
Change-Id: Id515b90efc9e533e18a35030a9a677de4d4ea02d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142272
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
EMR_EXTSELECTCLIPRGN would not factor in WinOrg coordinates which would
give the clip box wrong coordinates causing some graphics to look
chopped in the wrong way.
Change-Id: I4f9a1b1c27fc276d188d0d865991795dab48dce5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142110
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.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>
CppunitTest_emfio_emf CPPUNIT_TEST_NAME=Test::TestEmfPlusDrawPathWithCustomCap
introduced in 5b21b65572 "tdf#142770 tdf#143031
EMF+ Implement CustomLineCap" failed for me both in a local master build on
macOS on Apple M1 and in a Linux aarch64 test build of the libreoffice-7.4.0.1
Flathub flatpak (at <https://buildbot.flathub.org/#/builders/21/builds/7749>)
with
> xmltesttools.cxx:195:Assertion
> Test name: (anonymous namespace)::Test::TestEmfPlusDrawPathWithCustomCap
> equality assertion failed
> - Expected: 1423.297394625,1268.98481214025 830.006276132353,558.656004112967
> - Actual : 1423.297394625,1268.98481214025 830.006276132352,558.656004112967
> - In <>, XPath contents of child does not match
As this failed in exactly the same way for rather different builds (Clang vs.
GCC; Apple M1 vs. whatever ARM processor used by <https://flathub.org/builds>),
it smells like the test input might trigger a case where operations can
legitimately produce slightly different floating point results, which would then
cause the test to erroneously fail for some builds.
So I hacked the test input
emfio/qa/cppunit/emf/data/TestEmfPlusDrawPathWithCustomCap.emf slightly, making
the EmfPlusPath's 2nd EmfPlusPointF Y coordinate identical to the 1st one's, so
that the arrow now points west rather than north-west,
> 00000190: 02 10 c0 db 00 00 00 00 00 00 cc ff 08 40 0e 03
> 000001a0: 2c 00 00 00 20 00 00 00 02 10 c0 db 02 00 00 00
> 000001b0: 00 00 00 00 2b b5 05 45 05 54 56 45 d6 66 00 45
> -000001c0: 05 54 56 45 00 01 81 01 15 40 0e 00 10 00 00 00
> +000001c0: 51 23 4d 45 00 01 81 01 15 40 0e 00 10 00 00 00
> 000001d0: 04 00 00 00 0f 00 00 00 0e 00 00 00 14 00 00 00
> 000001e0: 00 00 00 00 10 00 00 00 14 00 00 00
which happens to let the test compute a different polygonstrokearrow/polygon
value now, but which appears to be stable across at least my x86-64 and aarch64
test builds.
And temporarily reverting the non-test (i.e., drawinglayer) parts of
5b21b65572 would make the test fail with
> xmltesttools.cxx:121:Assertion
> Test name: (anonymous namespace)::Test::TestEmfPlusDrawPathWithCustomCap
> assertion failed
> - Expression: xmlXPathNodeSetGetLength(pXmlNodes) > 0
> - In <>, XPath '/primitive2D/metafile/transform/polygonstrokearrow/polygon' not found
so the test appears to still faithfully check the intended difference in
behavior.
Change-Id: Iec31246dd7666ec764176622ccc4f246eea6e4ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136896
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
With previous implementation, the EMF+ import is calculating
gradient positions wrongly. It is causing warning:
SvgGradientHelper got invalid SvgGradientEntries outside [0.0 .. 1.0]
and the gradient was not displayed at all.
This patch fixes that and gradient is displayed correctly
Change-Id: I6229c516165436d0c7ae187d9eb69b5494da396f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135607
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With this commit EmfPlusDrawClosedCurve and EmfPlusFillClosedCurve
support was added. There is still missing Filling Mode (it
is always set to Even Odd Alternate:
https://en.wikipedia.org/wiki/Even%E2%80%93odd_rule )
and Tension support for spline bends.
The graphics is displayed as Tension=0.
A value of Tension=0 specifies that the spline is a sequence of straight lines.
As the value increases, the curve becomes more rounded.
For more information, see [SPLINE77] and [PETZOLD].
Change-Id: Ibccfd584e3d55cd0ca8a29da9f450916d56705d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134333
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
EMF+ is allowing different caps and arrows on both ends
It is not possible to implement that with css::drawing::LineCap,
as it is set line endings on both line start and line end.
Additionally when the Dash Pattern is used, the css::drawing::LineCap
is also applied there.
To resolve that limitation, the Cap needs to be implemented
independetly by using PolygonStrokeArrowPrimitive2D, and
the css::drawing::LineCap inside drawinglayer::attribute::LineAttribute
always set to css::drawing::LineCap_BUTT
Change-Id: I4be76e2dbefcb34154a1404c3b57dc4b7f7ada85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133299
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
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>
Previously when TranfromationMatrix was used with rotation,
the line weight and dashed line shapes were changed.
In worst case if angle was larger than 90 degrees,
the lines just disappear.
This patch fixes that. The line looks exactly after rotation
(with TranfromationMatrix).
The tests were updated (added some additional rotation),
to prove that now it is working correctly.
Change-Id: Ic2382fa8d1b711a6bf06c94b2d0b9da9e7d396f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133329
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
With previous implementation, empty spaces between dashes
were too long.
Additionally line joints were not working correctly, after
EMF+ reworking: tdf#111486
This commit fixes all these issues and additionally it is
covering it with tests.
Change-Id: I9404e566d2d7d3405ab817268ad9b1f538c200eb
Change-Id: I523f92a928ab592ff175d0d01c1ad1a3bc22e324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133207
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
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>
With previous implementation the clipping restoring with EmfPlusRecordTypeRestore
was implemented wrongly as it is only taken to account
the shape of clipping (state.getClipPolyPolygon) and doesn't
take if clipping was even enabled (state.getClipPolyPolygonActive).
Additionally the changing states should be made by using method:
wmfemfhelper::HandleNewClipRegion() and not directly.
The similar implementation was applied also to EmfPlusRecordTypeGetDC.
Additionally the clipping for
EmfPlusRecordTypeSetClipRect
EmfPlusRecordTypeSetClipPath
EmfPlusRecordTypeSetClipRegion
was fixed, as initially the clipping is disabled (state.getClipPolyPolygonActive)
and the clipping shape is empty (state.getClipPolyPolygon).
It means that combination other than EmfPlusCombineModeReplace,
was not working correctly.
With this implementation, if Clipping is disabled, then treat clip combining
in special way.
Change-Id: I258bda64e8bfdade7f47ffc7518bf04b7340344f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132415
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
* 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>
No need to recompile most of LibreOffice, because the --with-fonts
configure flag changed. This preprocessor define is just used by
unit tests anyway.
Change-Id: Ia2eae7d0c74e59e034fdd8513504a34e51ab428e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128197
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(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>
Rather than make all the BasePrimitive2D classes bear the cost of being an UNO
object, we just wrap the top level BasePrimitive2D in this class when we need
to pass them over UNO.
This reduces the locking overhead when doing normal drawinglayer operations,
and reduces the size of drawinglayer objects and the cost of initialising
them, which shaves 5% off the load/display time of a large barchart.
Add new drawinglayer::convertPrimitive2DContainerToBitmapEx utility
method to avoid needing to convert to Sequence<XPrimitive2D>
Change-Id: I553eaa4c16ba016b098cb21f6c55f5008f0d9b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126487
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
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>
Bartosz Kosiorek