Age | Commit message (Collapse) | Author |
|
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>
|
|
* Fix typo
* Improve links
Change-Id: Ie77ec795675bf7497c90620eb44ebb3191c003b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133067
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I5707dbda5468256c8d03ac35b43fb54b8b4f3c7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132991
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
* Add information on dumping drawyinglayer primitives as xml
* Add link to a new tool named limerest on gitlab
Change-Id: I50a0018d9c3063281b2a761d437bb9def0f34bde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132936
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
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
3e7dd04dd8ca1baea4b7918eb7a7080c595c4625, 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
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>
|
|
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>
|
|
Change-Id: Ic84899bf34f98382e6cc1ffc14310b1667279ee2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132214
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...after 3e7dd04dd8ca1baea4b7918eb7a7080c595c4625 "tdf#145614 Convert #define to
enum and constexpr"
Change-Id: I3ef1d17295e99c040125acd4b03fd5096848a0e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131630
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>
|
|
As EMR_SETARCDIRECTION record for EMF is now implemented in commit
7b28920382d3820344bfc4075bac98f85e838dba, it is now removed from
the unimplemented list of records for EMF.
Change-Id: Ib2931d339f924e813d243ba503d4b17aab0d6868
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131401
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
Change-Id: I30206c68ecf1829ba0094e6259b8ed7dc05f2e9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131103
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: I3459d753a8f655ca34ecf6c25fdfd9655687c6d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129660
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
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>
|
|
Change-Id: Ie0867782b0925800cc094f43f8387fb9d1ff0c21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128272
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@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>
|
|
This separates the drawinglayer core functionallity into a
separate library, to keep a strict separation what is backend
dependent and what is not. More strict separation can be done
at a later date.
This will make it possible to push part of drawinglayer
(part of processor2d) directly into VCL.
Change-Id: Ibc26580067e50bf20d7cdd37fa0e44eb10200878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127286
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ica8f0a6e3d30dba3b5a083e3c04522073de8303f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127233
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
since...
Date: Wed Jun 2 17:01:55 2021 +0200
WMF: add more SAL warnings in case record was not implemented
Change-Id: I1d58c4093817403caa5f1112b5d4d5a4e638b799
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116618
Change-Id: Ib82efbc93405b7fafb661f698a772593d2495bd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126454
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The previous patch 149bd802623d6d83ec9aa04514b938494f7f01f6 only
partially fixed the problem, and the size of the graphical objects
was wrongly calculated. This patch fixes this problem.
The fix can be tested with:
make CPPUNIT_TEST_NAME="testTdf145873" -sr \
CppunitTest_vcl_pdfexport
This test exports the PPTX to PDF and checks the size of the objects.
The previous test for this issue which exported to SVG is removed, as
it could not test the current situation.
Change-Id: I97bed99811eaf8236ded84ffe0c1a7d3d1b5bad5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125924
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
EMF can have WMF embedded inside it. The sample PPTX file contains an
EMF file consisting of several GDIcomment records in which embed a
Placeable WMF file without some records related to the size of the
WMF. It reaches pStm->SetError( SVSTREAM_FILEFORMAT_ERROR ); in
emfio/source/reader/wmfreader.cxx:1982 which causes to the problem
in loading the file.
With this fix, the EMF file will be displayed. Without the fix, the
EMF file will be displayed as blank.
Regression from
commit 5e4e1cdb1e14354b42838e1dfcf82873b3071896
tdf#88163 Fix font size for placeable wmf files
The fix can be tested with:
make CPPUNIT_TEST_NAME="testTdf145873" -sr \
CppunitTest_sd_svg_export_tests
Change-Id: I04babd5029ba123fdd03758eef2be69faf45fda8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125796
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
* Converted multiple symbolic constants using #define in wmfreader.cxx
to enum
Change-Id: Ie55f27414c230cd624cacb805897933707244ed6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122734
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Replaced multiplying by magic number 57.29577951308 with
basegfx::rad2deg() which is equal to 180.0/M_PI
* Instances of this could be found using:
git grep 57.29577951308 *.cxx *.hxx
Change-Id: I0ae99a5d63d104b79c6df2dc88e9dda6973a1d3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124226
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
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>
|
|
The variables xSrc, ySrc (x/y positions) and cxSrc, cySrc (x/y size)
come from [MS-EMF] documentation, "EMR_STRETCHDIBITS Record" section.
By calculating the difference between Bitmap x size and cxSrc (called
nWidthDiff), and also Bitmap y size and cySrc (called nHeightDiff),
the conditions used to test if it is OK to crop are simplified, and
are better readable.
Redundant checks (nWidthDiff >= 0) and (nHeightDiff >= 0) are removed
because it is now obvious that when they are bigger than non-negative
xSrc and ySrc, thus they themselves can not be negative.
Change-Id: I8e82c3d469377f21d34b57f3d50f977cf71004ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124096
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Make usage of ETO_PDY flag more visible with introducing nBytesEach
variable
* Add comments for reading OutputDx
ETO_PDY flag indicates that we should read twice values
compared to the number of characters in the output string.
Values are stored in an array of 32-bit unsigned integers called
OutputDx, so there will be either 8 bytes or 4 bytes each
depending on ETO_PDY is set or not.
Change-Id: I3892c95bd9ad80b3c414e2556f91bd5218b22c3e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124097
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
not much else can be done as far as I can see except to saturate
Change-Id: Ifb7e47b03c76eca26b7340b047032e971401e86b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124619
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I4b6b6f2ba0c4dd013489b334822e6639f265c6b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124539
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Makes code simpler, and std::span can be constructed from std::vector
too.
Change-Id: Iae26b53c52148c19d9068a63126a7393d098d654
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124507
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
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>
|
|
* Added information about dumping metaactions using mtfdemo
* 'sax' dependency was removed in d49900e5a3aae75a4c673f593e99fbc296f67cee
* Listing indirect dependencies from 'emfio/Library_emfio.mk'
Change-Id: I5ee7e20c872aff388424930a23c9a17614b5e3c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124180
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
* Replacing std::unique_ptr<char[]> with std::vector<char>
* The data bytes are read into the vector internal storage
* Modification of the internal storage of the vector using the
pointer returned by data() is allowed by the standard
C++ Standard, revision n4830, section 2.3.11.4 Data [vector.data]
Returns: A pointer such that [data(), data() + size()) is a valid
range. For a non-emptyvector, data() == addressof(front()).
https://github.com/cplusplus/draft/blob/main/papers/n4835.pdf
* It could be replaced with std::string when data is not modified
Example: 6c13e5a92ed4b6a10458cd5d5741ddb3d816df4e
* std::vector<char> is useful when working with C functions that
get "char *" for writing data. In this case, std::string is not
usable, because data() method for it returns "const char *".
Change-Id: Ife6013b16a1803c3ad7b0c64aa0cb4c8cf4373ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123764
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Describe how it works
* Fix the example
* Better formatting
* Fix typos
Change-Id: Ia568ca522453a6c3da1502bd2e7c3a8ce3a29fc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123987
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Module 'sax' was one of the dependencies of 'emfio'. This is also
mentioned in:
https://wiki.documentfoundation.org/Development/Build_System
Previously, module 'emfio' was directly depending on 'drawinglayer'
and 'sax'. But the build is fine when 'sax' is removed from
'emfio/Library_emfio.mk'. Also there is no mention of sax when
invoking 'git grep sax' inside emfio folder.
With this patch, the 'emfio' dependency on 'sax' is removed.
Change-Id: Ib6f9dc3df33865b6fc912d02b27b01232a6a3fb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123988
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7e249b2fd01dac96afb03dc0ddca6a1080f190f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124035
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
The module 'emfio' is used to read and write WMF/EMF/EMF+. This is
the list of topics discussed in the 'emfio' documentation:
* Introduction
* EMF+ Specifics
* Limitations
* Known Bugs
* Dependencies
* Tools
* Related Software
* References
Change-Id: Iccd1269f62b8099b823d755c84e0ea51a545fae9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123846
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Added in e179e53e3c703153bb0bb3155c1c6e2d25577fe0
<EMF: tdf#138467 Fix MapMode translation>
Change-Id: I4f326c95f279e4e1925f3e4324f904f81a361fcf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123823
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I1fc1b3863fd5b5472e700a5432fb4f9d353a054f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123650
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I277dc957798093001f9a3935f97db8ac0314e6a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123022
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: If50af8538e31e4fb1ee1486ec2b91963c094e7e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123007
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
The problems in tdf#88163 can be categorized into two parts, as
described in d25906087918c085239aac30fd72cb65aa7b9eb4:
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 condition nPlanes != 1 is checked in the previous if statement and if it the content of nPlanes is anything other than 1, it would have used the break to exit the switch case. Thus, there is no need to check nPlanes == 1 again.
Change-Id: I1e07b48af16de40d39eabb6f2b666e41b0b0432e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122451
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|