summaryrefslogtreecommitdiff
path: root/emfio
AgeCommit message (Collapse)AuthorFilesLines
2021-04-27More aggressive Clang 13 trunk -Werror,-Wdeprecated-copy[-with-dtor]Stephan Bergmann1-0/+3
...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>
2021-04-26drop mask from BitmapExNoel Grandin1-1/+1
So that we have fewer cases to deal with when we transition to 32-bit bitmaps. (*) rename maMask to maAlphaMask, since now it is only being used for alpha duties. (*) drop mbAlpha and mbTransparent to simplify state management, the only thing we need to check for alpha is if maAlphaMask is non-empty. Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-23CppunitTest_emfio_emf: avoid --disable-pdfium failureMiklos Vajna1-0/+6
'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>
2021-04-09-Werror,-Wformat (clang-cl)Stephan Bergmann1-1/+1
"format specifies type 'unsigned long' but the argument has type 'sal_uInt16' (aka 'unsigned short')" Change-Id: Ie5397be90ccb5678a97e7a3a0987b60b38ece4e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113874 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein1-1/+5
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-04-05ofz: skip slow path when fuzzingCaolán McNamara1-0/+7
Change-Id: I21d600f58174319ce6386de88ab9ac0ad371688b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113612 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-04-04pass ImplReadRegion the remaining len of record available for consumptionCaolán McNamara1-45/+65
not the total which includes consumed part Change-Id: I63b01013a31e6a3f1dcfe895c02a4fa049bb8fe6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113560 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-04-03tdf#37281 tdf#45820 tdf#48916 tdf#55058 EMF Implement complex clippingBartosz Kosiorek4-25/+41
As the visual glitches were resolved with: https://gerrit.libreoffice.org/c/core/+/113423 It is time for enabling complex clipping. Change-Id: I12edc88fc9a55c8deedf3d87faeb50cfe0067a01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113520 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2021-04-02tdf#55058 EMF: Implement PAINTRGN recordBartosz Kosiorek1-1/+12
The EMR_PAINTRGN record paints the specified region by using the brush currently selected into the playback device context. After implement support for PAINTRGN record, the reference image is displayed correctly: https://sourceforge.net/projects/libuemf/ Change-Id: I761779713d1200e6079ff798e9c3c9aaba57ad4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113461 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2021-03-31tdf#55058 tdf#141394 EMF FILLRGN record is not displayed correctlyBartosz Kosiorek3-21/+49
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>
2021-03-28drop operator bool and operator! from Bitmap and BitmapExNoel1-1/+1
IRC chat: <quikee[m]> noelgrandin: doesn't adding operator bool to Bitmap has the same problem as Graphic and the reason why you dropped that commit 7334034ae93b49fc93b5859a3c047a319d138282 "drop Graphic::operator bool" <noelgrandin> quikee[m], hmmm, good point <noelgrandin> maybe I should just drop both operator bool and operator! in favor of IsEmpty <quikee[m]> noelgrandin: I don't remember what the problem is I just remembered we dropped it Graphic :) sure, dropping everything for IsEmpty is probably the best Change-Id: Ieae289cda64f0b8d8fdecd5ea9e6f2bb874ff4cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113163 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-26loplugin:flattenNoel1-75/+75
Change-Id: Ib7a895fba66f8dc9b6501e61631c02694053b7fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113157 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-25WMF/EMF Convert all index type of Objects to unsignedBartosz Kosiorek3-14/+26
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>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein1-0/+0
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-03-22WMF EMF Add more SAL_INFO and SAL_WARN to help debugging import issuesBartosz Kosiorek2-89/+198
With this change, the WMF record type is displayed after enabling emfio. Change-Id: I055fc1dde6c37cf6ab8c6125fc2522bd7b1517cc Change-Id: Iff6ccbad69f4f836957206357dd707e4ddd06931 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112863 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2021-03-19tdf#35986 tdf#140271 EMF Fix line width of CREATEPEN recordBartosz Kosiorek2-26/+21
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>
2021-03-09Make sal/config.h the first in pchMike Kaganski1-2/+2
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>
2021-02-27cid#1473321 Division or modulo by float zeroCaolán McNamara1-2/+8
and cid#1473322 Division or modulo by float zero where oss-fuzz also found a reproducer as ofz#31370 Divide-by-zero Change-Id: I0facd2e794384515891dbf040f4fe43530478d3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111601 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-26ofz#31370 Divide-by-zeroCaolán McNamara1-1/+1
Change-Id: If581d61b678616f8a80f8ad2d2dea5ecbf10d8fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111557 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-24Fix typosAndrea Gelmini1-3/+3
Change-Id: If005139571e46fbf8aedb37e2626c54a43853fd5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111483 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-02-23tdf#127471 Detect&Correct EMF/WMF with wrong FontScaleArmin Le Grand (Allotropia)4-3/+239
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>
2021-02-19update pchesCaolán McNamara1-1/+2
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>
2021-02-17tdf#127471 correct EMF/WMF im/export for scaled fontArmin Le Grand (Allotropia)1-1/+19
If FontScaling is used, system-dependent data is held at vcl::Font Width(). Already if not scaled, we have three definitions: Width is zero, Width is equal to Height (unx) or - on Windows - Width equals avgFontWidth. If used it is W!=H where on unx Width equals Height multiplied with the scale factor. On Windows, this is Width multiplied with the only there existing avgFontWidth. Unfortunately that is ex/imported (since ever) undetected to EMF/WMF thus making EMF/WMF files containing FontScaling system-dependent - on which system was LO running when creating the file? The error can be seen when loading such a EMF/WMF on the vice-versa system, the FontScale is very ugly and wrong. Since EMF/WMF *are* Windows-specific formats the Windows-like definition is the correct one. This change makes all other systems export that now, and adapt on import to their system- specific definition (assuming coming from Windows). As can be seen, the difficulty is that these adaptions are necessary on non-Windows plattforms, but these do not have that avgFontWidth available. Thus I made a deep-dive investigation and multiple experiments to create a as similar as possible value to apply the needed calculations. For details and discussion refer to the bug description. Change-Id: I983fb6d882e2e8fccf9c8460f01509201d8157f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111000 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-02-14Move unit conversion code to o3tl, and unify on that in more placesMike Kaganski1-2/+3
This also allows to easily add more units, both of length and for other unit categories. The conversion for "Line" unit (312 twip) is questionable. Corresponding entries in aImplFactor in vcl/source/control/field.cxx were inconsistent (45/11 in; 10/13 pc; 156/10 pt). They were added without explanation in commit c85db626029fd8a5e0dfcb312937279df32339a0. I haven't found a spec of the unit (https://en.wikipedia.org/wiki/Line_(unit) is not specific). I used the definition based on "by pt", "by mm/100", "by char" (they all were consistent); "by pc" seems inverted; "by twip" was half as much. This accepted conversion makes unit test for tdf#79236 pass. Change-Id: Iae5a21d915fa8e934a1f47f8ba9f6df03b79a9fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110839 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-12fix test for tdf#137413Luboš Luňák1-13/+6
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 828504974d70111e, which made the drawing use DrawTransformedBitmap() implementation in the VCL backends, and the Cairo one apparently mishandles it. Reverting 828504974d70111e 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>
2021-01-20ofz#29691 revert throw SvStreamEOFExceptionCaolán McNamara1-1/+1
reasonably sane code like s.ReadUInt32(a).ReadUInt32(b).ReadUInt32(c).ReadUInt32(d); if (s.good()) // use a, b, c d; stopped working. FWIW on a short read we retain whatever was in the variable before the read, rather than overwrite it with new random data, so sal_uInt32 a(0xdead); s.ReadUInt32(a); assert(s.good() || a == 0xdead); the msoffice ppt/escher/xls/doc filters especially speculatively parse and rely on a variables preinit value in the case of a short read. commit b345a2bab0d6f981049951a86b172ce49ce7d4c2 cid#1470786 Uncaught exception commit 71aec4726a94dcde1169fd293dbecfeb0e840e6d ofz#29528 uncaught exception commit bed03603f6cae264abb9e5b58aa2ab00448d92ff ofz#29414 uncaught exception commit 684885a99a1eb7ad943e9736166d4bb1468663be ofz#29443 uncaught exception commit 93574ac7768d247ed754ecda322e54e4bd447e43 ofz#29251 Abrt commit 413db68d95bd39d34e6a6b81a7c5c9478ced0514 ofz#29152 short read commit f400e883044143f999c460375a293647b4a57244 ofz#29151 short read commit 96ea80a725dfe4ef38993f78917c243f13e3beb5 ofz#29129 Abrt on uncaught exception commit 646a635efe6eecbc3d1dd3a7cbb02a278c6f3be5 ofz#28931 Indirect-leak commit b0e573f18629d28fe3179c12d0d434653f92fc93 ofz#29030 Abrt in xlsfuzzer commit 95407c39168d186ee44e67b1a6a4bcf592c58b84 ofz#28902 uncaught exception commit 45175d655ad3773df1c006182108cf25e87b1091 oss-fuzz: tgafuzzer doesn't pass sanity check commit b82fc702bae9d6190bda1b4818a47cfa197df6d8 oss-fuzz: psdfuzzer doesn't pass sanity check commit e7c76d604a4694e6568bf10c2a06a786f1096319 oss-fuzz: epsfuzzer doesn't pass sanity check commit 901e5e7c9170184e286ea3e46fce406136aa9572 oss-fuzz: xlsfuzzer doesn't pass sanity check commit 127bfab61c297df06fd8e71e709bc4362cb89d21 oss-fuzz: pngfuzzer doesn't pass sanity check commit 77387ae00ae27e3f8bcdf7bccf97fb2db8f196b7 oss-fuzz: mtpfuzzer doesn't pass sanity check commit 974ffa79b0fef4ca76558bb8b16bce84af3aaf6c oss-fuzz: xlsxfuzzer doesn't pass sanity check commit 6d6d104cbb382d0045e1f04b12d268992fa5c624 oss-fuzz: bmpfuzzer doesn't pass sanity check commit a7d1d107ec58d3b00b4019c89edddcff71ca6ff3 oss-fuzz: qpwfuzzer doesn't pass sanity check commit 898993aa62276f59480df8af1da4bad530829b56 oss-fuzz: pcxfuzzer doesn't pass sanity check throw/catch parts of commit 8c9a4ff511a3b1d84a7a6d08a1b153c07f164abb throw exception in SvStream when reading past end of file Change-Id: Ic49c249768b17b64d8e868655dbc05b31906c2e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109621 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-19vcl: remove or rename too long methods names in VectorGraphicDataTomaž Vajngerl1-1/+1
Change-Id: I8a64d27927b608afdc7996e0b0bbc59a58fde90f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108443 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-01-16make the Color constructors explicitly specify transparencyNoel1-1/+1
to reduce the churn, we leave the existing constructor in place, and add a clang plugin to detect when the value passed to the existing constructor may contain transparency/alpha data. i.e. we leave expressions like Color(0xffffff) alone, but warn about any non-constant expression, and any expression like Color(0xff000000) Change-Id: Id2ce58e08882d9b7bd0b9f88eca97359dcdbcc8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109362 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-09ofz#29443 uncaught exceptionCaolán McNamara1-1/+1
Change-Id: I35b0c23f6b6df6d5e4d7e89fce84e8e0f306d8e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109038 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann2-18/+23
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-24custom literal for Degree10Noel Grandin1-1/+1
Change-Id: Id13869138a622e62d9ffebf2c89bddccda6aff01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108238 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-24vcl: move access functions into appropriate bitmap access filesChris Sherlock2-2/+2
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>
2020-12-18throw exception in SvStream when reading past end of fileNoel1-1/+1
to avoid chasing weird problems where we read past the end of file, which leads to random data in the variable we read into. I expect a couple of possible regressions from this change (1) memory leaks caused by non-exception-safe memory handling. Of which there should not be much because we're pretty good about using smart pointer classes these days. (2) Broken files which used to load, will no longer do so. These will have to be debugged by putting a breakpoint on the SvStreamEOFException constructor, and examining the backtrace to see where we should be catching and ignoring the exception to make the code continue to handle such broken files. Change-Id: I351be031bb083a3484a9a1b650a58892700e6fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105936 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-15update pchesCaolán McNamara1-2/+2
Change-Id: I280dea8fe5f346a5555f4bf479896877579d63e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107748 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-09vcl: improve EMF+ -> WMF conversionMiklos Vajna3-0/+24
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
2020-12-08emfio: allow disabling EMF+ via a bootstrap variableMiklos Vajna1-1/+4
Bootstrap variables have multiple sources, so the environment variable way continues to work. This also allows disabling EMF+ using the -env:EMF_PLUS_DISABLE=1 cmdline parameter, which is useful when soffice is not started in a shell. Change-Id: I76e82b77d70910ba4843db6ab998b0b1ea4a31f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107421 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-12-04ofz#28271 divide-by-zeroCaolán McNamara1-10/+40
Change-Id: Ib3f47dcb0a5e327f5385ccff328f410a15b2cc91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107190 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-03EMF: tdf#138467 Fix MapMode translationBartosz Kosiorek4-14/+50
Add proper translation for map mapping modes: MM_LOMETRIC = 0x02, MM_HIMETRIC = 0x03, MM_LOENGLISH = 0x04, MM_HIENGLISH = 0x05, MM_TWIPS = 0x06 according to MS-EMF documentation. Change-Id: If4c71b52e5236441837e62590797ced8acd6c80f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106251 Tested-by: Jenkins Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2020-11-16Instead of labs, use overloaded absStephan Bergmann2-4/+7
...more likely to pick an appropriate version for the involved integer types, esp. after the recent long -> tools::Long changes Change-Id: Ia91259ca35aaf74b0e907de6831fc926f30057f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-14tdf#35986 EMF import: Add support for PS_COSMETIC line style in CREATEPENBartosz Kosiorek3-11/+71
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>
2020-11-14tdf#35986 tdf#92315 tdf#116335 tdf#116622 Add support for MapMode TEXTBartosz Kosiorek3-24/+92
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>
2020-11-13tdf#123936 Formatting files in module emfio with clang-formatPhilipp Hofer1-2/+2
Change-Id: I5b0867630741713d08f533dc76c82bfb1cad9cbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105666 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-12tdf#42949 Fix new IWYU warnings in directories [e-f]*Gabor Kelemen2-2/+2
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I963aa5fb892a0be36212fd0587b69f217f017947 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105469 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-11make tools::Long 64-bit on Windows platformNoel Grandin3-9/+9
This is only for the 64-bit windows platform. I don't see the point in messing with the 32-bit platforms, they are (a) become more and more rare (b) unlikely to even have enough available process memory to load extremely large calc spreadsheets The primary problem we are addressing here is bringing Windows-64bit up to same capability as Linux-64bit when it comes to handling very large spreadsheets, which is caused by things like tools::Rectangle using "long", which means that all the work done to make Libreoffice on 64-bit Linux capable of loading large spreadsheets is useless on Windows, where long is 32-bit. The operator<< for tools::Rectangle needs to be inside the tools namespace because of an interaction with the cppunit printing template stuff that I don't understand. SalPoint changed to use sal_Int32, since it needs to be the same definition as the Windows POINT structure. Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11disable O(U)String::concat for internal codeNoel Grandin1-1/+1
in favour of the more widely used, and better optimised, operator+ Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-27tdf#137413 EMF import: fix transparency in the PDF fallback caseMiklos Vajna4-3/+29
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
2020-10-22long->tools::Long in emfio..filterNoel3-9/+9
Change-Id: I961cee10d45d628ff70dea0694a7a63a4fe867ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104624 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21new tools::Degree10 strong typedefNoel Grandin1-4/+3
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02loplugin:reducevarscope in desktop..emfioNoel2-10/+6
Change-Id: I25ca760ae15114ada621d928997a7117401c75d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103811 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-21update pchesCaolán McNamara1-1/+4
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-27 20:03:24 +0000