Age | Commit message (Collapse) | Author |
|
Change-Id: I4d67eb7112d2295185905eac52ebab022a1beb78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151670
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I6898acbf7c6c9de45bbfa6a32202acf302f92caa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146822
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
It had originally been disabled by a037f6338c19e16bcbc0674214666a786872c59d
"Disable CppunitTest_vcl_wmf_test under --enable-merglibs for now" because "the
problems caused by that test having the vcl objects linked into both the test's
library and the mergedlib (which the test's library links against) are just not
manageable", which is no longer an issue at least since
29cdfa3fc337381e2529eaac2a551137ee8a1aaa "no need to statically link against the
emfio library in the tests".
But the test code apparently uses WinMtfFontStyle, which can thus no longer be
hidden under --enable-mergelibs.
Change-Id: Ie807b19f0cb44408c69d03faca01fabe88239ca0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148493
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
do it like this to avoid adding another mapmode and to keep things
"the same" as much as possible
Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8a91edb86edd76b70648507f12b18d9e923ab16e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141774
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
|
|
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>
|
|
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>
|
|
This patch fixes problems caused by the cleanup commit
3e7dd04dd8ca1baea4b7918eb7a7080c595c4625 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>
|
|
Change-Id: I30206c68ecf1829ba0094e6259b8ed7dc05f2e9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131103
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
See tdf#42949 for motivation
Change-Id: I49a3ce10dee4b03f99156f5b641f69448e1d5617
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128479
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Use o3tl::convert instead of homemade constants; unify logic and
move common code out of the switch.
Change-Id: I31e53d04017aac7d6a2f435adb9233b9c0e3ba6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124939
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I36ddc11b39763dc77086591fe9bb756195b4294f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124459
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we get bounds checking in debug mode
Note that I cannot just pass around the std::vectors
involved because there is a place in editeng which
calls with a subset of a vector.
Change-Id: I5088a139593c27bf9cbe5d843ab4b0048ac6d508
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124330
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
sidestep the resize behaviour of SvMemoryStream by using an honest
std::vector and make it use that buffer
Change-Id: Ic5e405010ac076fc04e1ca8dc6dbb495162101ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121832
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id14f525e84c22caa8f974f2f1d9f398f8d8e2df8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121532
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic7410f836e584df45101e78e345c8b3c8d355e09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120680
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A WMF may have EMF with EMF+ actions embedded. When we read that,
we drop drawing non-EMF+ actions if we use EMF+. But EMF+ actions
are stored as MetaCommentAction in the metafile, and WMF writer
(unlike EMF) writer simply ignores comments. So when writing WMF,
make sure to read non-EMF actions so that something is written.
This is an extension of 295626a0bd39540544b774094a63df23e5376839.
Change-Id: I37355f694fe656b661abe54274ea203934e68151
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117062
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@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>
|
|
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>
|
|
With previous inplementation, the ARC, ARCTO, CHORD and PIE
records were get Start Point and End Point only with
positive values. It was causing display issues.
This patch fix that according to [MS-EMF] specification
Change-Id: Ie1d90a904e840674380b81af0dfe21260374587d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115994
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I8f995dab566d9fae79d87fe13741b8ea9658b408
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112998
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>
|
|
...since
<https://github.com/llvm/llvm-project/commit/abf3ca61e3235681f26d0f527b8e2763dd4c0c62>
"[Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment
operator is defined as deleted (PR45634)"
Change-Id: I43ae8a620915ad211a1f21ecf89b6955b7d2faaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114674
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Based on WMF and EMF documentation, all indexes should be unsigned.
With this commit it was applied, which simplifies code.
Change-Id: I3257da7e595ace45622c6d865fd4b034dc605cb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113039
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
By convention, it should be the first include in C/CXX files;
so use of pch should not break that.
Change-Id: Ic329c5f39e8f48ad1778724368e262e48972342b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112123
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Before correcting our EMF/WMF export to write the Windows-
specific data in the case of FontScaling, we wrote these
files with wrong FontScaling.
This change tries to detect and correct this at import, so
that newer versions of the office on all plattforms can
again load old, from us but not on Windows written EMF/WMF
files.
With this change we can read again all new and old EMF/WMF
files (see table in task, comment 80).
Change-Id: I1a0b0ab5f57c7cd40520401568af05cab4ecb4c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111399
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Ic4586057346b6de700c1bb6ff4cd759a11bb3e4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111231
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I280dea8fe5f346a5555f4bf479896877579d63e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107748
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
We throw away EMF fallback info when parsing EMF+ data. This means that
the resulting GDIMetaFile (containing EMF+ data but no EMF fallback) is
tricky to export to WMF, where EMF+ comments are not allowed.
Improve the conversion result by re-parsing such EMF+ data with EMF+
disabled, and then converting the GDIMetaFile (containing EMF fallback
data) to WMF.
Change-Id: Ib2c0388f1344aef7f601ce9be59e4a8924e8085b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107453
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I5b0867630741713d08f533dc76c82bfb1cad9cbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105666
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Commit d75c5b38911557173c54a78f42ff220ab3918573 (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
|
|
Change-Id: I961cee10d45d628ff70dea0694a7a63a4fe867ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104624
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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
|
|
Change-Id: I7840929712a8e9bd3f46b2c718cf430b97e9b683
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102970
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
The PPTX bugdoc has a 17MB EMF file, which has enough instructions to
keep Impress busy for minutes during import.
Take advantage of the detail that this EMF has a
EMR_COMMENT_MULTIFORMATS record that contains the original PDF, which
can be rendered much faster:
- old cost: 122.153 seconds
- new cost: 1.952 seconds (1.6% of baseline)
Change-Id: I38efc1c24e21a7622377b9e1c1938ebee826bae9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102918
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I75602277a5a26b012a12f2c4f4b7ff5bb663b0b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98474
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I486922d0652f26fa7ee56f5fe308e19fe5ff137e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90856
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifa76e004128223460945d58d1c59c4e23db0f108
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90370
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
With --enable-pch=full there's not much difference between a "public"
header in <module>/inc and a private one in <module>/src/somewhere/inc .
And since the script searches recursively, this apparently helps to
find even more headers for lower pch levels.
Change-Id: I8483d0aa5b4fea5a59107c20a8aa5f1ef694af0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87799
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I1b0df1a6cb5b8db9db09cb1d55d932459ab16d81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86741
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3f4ec81f78967c2d7f3c4554398cb9d "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
For emfio I believe we need more logging, so I am gradually adding this.
I decided to log the EMR_COMMENT_PUBLIC record subtypes
EMR_COMMENT_BEGINGROUP and EMR_COMMENT_ENDGROUP.
I honestly don't know what these actually do, but they are specified in
[MS-EMF] 2.3.3.4.1 and 2.3.3.4.2. Later on, we will need to look into
handling EMR_COMMENT_MULTIFORMATS so we can display things with EPS
data. We should also probably look into handling
EMR_COMMENT_WINDOWS_METAFILE later on also.
Change-Id: I7c3ba3cfd7f51a6cff2c7a47a48dde12240d0382
Reviewed-on: https://gerrit.libreoffice.org/83407
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I53809ab01d5e8eb091305c3cb618a64920ad22ad
Reviewed-on: https://gerrit.libreoffice.org/82783
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|