summaryrefslogtreecommitdiffstats
path: root/emfio/source
Commit message (Collapse)AuthorAgeFilesLines
* ofz: MemorySanitizer: use-of-uninitialized-valueCaolán McNamara2021-09-071-5/+10
| | | | | | | Change-Id: I4a34981e6597743f9f3a9ad6ca063cb347a68d14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121213 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
* ofz#31370 Divide-by-zeroCaolán McNamara2021-07-111-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Change-Id: If581d61b678616f8a80f8ad2d2dea5ecbf10d8fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111557 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit da457f41f8f0a14014ff9f122467f3a26eb1ac20) and... cid#1473321 Division or modulo by float zero 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> (cherry picked from commit 28e022c258682dc030668fed7879d9d3f078b720) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118595 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
* EMF tdf#142745 Improve performance of FILLRGN, PAINTRGN, EXTSELECTCLIPRGNBartosz Kosiorek2021-06-141-13/+20
| | | | | | | | | | | | | | | | | | With previous implementation, during reading of rectangles the optimizations were made after reading every single rectangle. This was causing performance issues, with many rectangles (eg. 2500 rectangles). With this commit, the optimization is made after reading all rectangles. It is improving performance of FILLRGN, PAINTRGN and EXTSELECTCLIPRGN records. Change-Id: I1b8b844efddd08e9bf6f6726c3fdf213a629883f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116996 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117022
* tdf#127145 WMF Fix displaying line width in ROUNDRECT recordBartosz Kosiorek2021-05-261-1/+0
| | | | | | | | | | | | The EDGE optimization shouldn't be used for curves, otherwise strange issues appearing. Change-Id: Id677fc9002f0f79913ae756f0e456af7c9f7e507 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115984 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit b7c9ce6c86a11c6cacfa190b99052da388887c49) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115957
* tdf#117957 WMF Add support for selecting colors from paletteBartosz Kosiorek2021-05-162-5/+41
| | | | | | | | | | Change-Id: I8f995dab566d9fae79d87fe13741b8ea9658b408 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112998 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit e923f752a3adfe1a941dcbc2fdffc626a569d59e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115520 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#142014 Fix displaying strokes when line width is 0Bartosz Kosiorek2021-05-161-4/+8
| | | | | | | | | | Change-Id: I80e05ff2f24f5da2f5c124c0ee1b302a1c8226ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115570 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit 699295ca7cab3a4f4e801a14496f202c05d18899) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115514 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#112603 tdf#142014 tdf#142139 WMF/EMF Fix line widthBartosz Kosiorek2021-05-161-1/+9
| | | | | | | | | | | | | Previosly line width was always 1, and changing width do not affect line. Change-Id: I462096b915e053fa089e85860f124466b650558a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115497 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit b5ece3fbc7f878846298fd9196e5a30ba50e0dc2) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115512 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#141982 tdf#142139 Add rotation and line width support to ROUNDRECTBartosz Kosiorek2021-05-161-2/+3
| | | | | | | | | | | | | With this commit the ROUNDRECT is able to change line width and transformation (including rotation) is supported. Change-Id: Ic303a74adf0fd0dd452353f250a13140603d492e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115429 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit f11ed681df15728abe6a0b6b7b1612f190aa1707) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115282 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#55058 tdf#141982 EMF: Add rotation support for INTERSECTCLIPRECT recordBartosz Kosiorek2021-05-161-9/+25
| | | | | | | | | | | | | | | 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> (cherry picked from commit 1ef26ffe39618a745d3367310565e7eeb184a4c2) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115207 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#55058 tdf#141982 EMF: Add rotation support for ARC, ARCTO, CHORD, PIEBartosz Kosiorek2021-05-161-19/+17
| | | | | | | | | | Change-Id: I5d9b76f0ddd2b7f12604f472986dd95976a8b04d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115185 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit 6bf2239a189423d087b2536dd7054b21df58ddc4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115198 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#142004 tdf#141982 EMF Import: Add rotation and path support for EMR_ELLIPSEBartosz Kosiorek2021-05-161-1/+7
| | | | | | | | | | | | | | | | | | | | | Previous implementation of EMR_ELLIPSE, doesn't support rotation and EMR_ELLIPSE was not work with EMR_BEGINPATH, EMR_ENDPATH and EMR_ABORTPATH The EMR_BEGINPATH opens path bracket construction. Once path bracket construction is open, an application can begin specifying records to define the points that lie in the path. Path bracket construction MUST be closed by an EMR_ABORTPATH or EMR_ENDPATH record. With this patch all these issue was resolved for EMR_ELLIPSE Change-Id: I6d352e0ff0326dd788d43272bf1330fa6c777df4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115101 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> (cherry picked from commit 761fdaf26dc9ed7cd0d25a7630576e7800813e2f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115194 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#55058 tdf#141982 EMF: Add rotation and path support for RECTANGLE recordBartosz Kosiorek2021-05-161-1/+8
| | | | | | | | | | | | | | | | | | | | | | | Previous implementation of EMR_RECTANGLE, doesn't support rotation and EMR_RECTANGLE was not work with EMR_BEGINPATH, EMR_ENDPATH and EMR_ABORTPATH The EMR_BEGINPATH opens path bracket construction. Once path bracket construction is open, an application can begin specifying records to define the points that lie in the path. Path bracket construction MUST be closed by an EMR_ABORTPATH or EMR_ENDPATH record. With this patch all these issue was resolved for EMR_RECTANGLE Change-Id: Ic51442df8905e47c92eed811cc776762c9752af2 Change-Id: I111f183e509f03c0b276a038680f61156b37b235 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115065 Tested-by: Jenkins Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> (cherry picked from commit 24e71494d7d1a68b2cb5f5d34083ab02009e0982) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115079
* tdf#37281 tdf#45820 tdf#48916 tdf#55058 EMF Implement complex clippingBartosz Kosiorek2021-04-061-21/+6
| | | | | | | | | | | | | | | | 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> (cherry picked from commit aa17ea3d36b8f1ea8cd3d2fb215e80051547439d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113637 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* pass ImplReadRegion the remaining len of record available for consumptionCaolán McNamara2021-04-061-38/+59
| | | | | | | | | not the total which includes consumed part Change-Id: I63b01013a31e6a3f1dcfe895c02a4fa049bb8fe6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113562 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* tdf#55058 EMF: Implement PAINTRGN recordBartosz Kosiorek2021-04-061-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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113561
* tdf#55058 tdf#141394 EMF FILLRGN record is not displayed correctlyBartosz Kosiorek2021-04-061-22/+25
| | | | | | | | | | | | | | | | | 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> (cherry picked from commit 5d4d8278b7fd2a555d6c9678d37877853562bd85) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113367 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
* tdf#35986 tdf#140271 EMF Fix line width of CREATEPEN recordBartosz Kosiorek2021-03-221-11/+6
| | | | | | | | | | | | | | | | | 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> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112865
* tdf#127471 Detect&Correct EMF/WMF with wrong FontScaleArmin Le Grand (Allotropia)2021-03-113-3/+215
| | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 3d33e4ce3987ea17e73a72e84f7f0df7af8101a6) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112222
* tdf#127471 correct EMF/WMF im/export for scaled fontArmin Le Grand (Allotropia)2021-03-101-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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112089
* ofz#28271 divide-by-zeroCaolán McNamara2020-12-071-10/+40
| | | | | | | Change-Id: Ib3f47dcb0a5e327f5385ccff328f410a15b2cc91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107202 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
* EMF: tdf#138467 Fix MapMode translationBartosz Kosiorek2020-12-031-14/+14
| | | | | | | | | | | | | | | | 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> (cherry picked from commit e179e53e3c703153bb0bb3155c1c6e2d25577fe0) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107104
* Instead of labs, use overloaded absStephan Bergmann2020-11-162-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>
* tdf#35986 EMF import: Add support for PS_COSMETIC line style in CREATEPENBartosz Kosiorek2020-11-141-11/+18
| | | | | | | | | | | | | 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>
* tdf#35986 tdf#92315 tdf#116335 tdf#116622 Add support for MapMode TEXTBartosz Kosiorek2020-11-141-8/+27
| | | | | | | | | | | 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>
* tdf#42949 Fix new IWYU warnings in directories [e-f]*Gabor Kelemen2020-11-121-1/+1
| | | | | | | | | | 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>
* make tools::Long 64-bit on Windows platformNoel Grandin2020-11-113-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>
* disable O(U)String::concat for internal codeNoel Grandin2020-11-111-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>
* tdf#137413 EMF import: fix transparency in the PDF fallback caseMiklos Vajna2020-10-272-2/+10
| | | | | | | | | | | | | | | | | 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
* long->tools::Long in emfio..filterNoel2020-10-222-7/+7
| | | | | | | Change-Id: I961cee10d45d628ff70dea0694a7a63a4fe867ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104624 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* new tools::Degree10 strong typedefNoel Grandin2020-10-211-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>
* loplugin:reducevarscope in desktop..emfioNoel2020-10-022-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>
* [API CHANGE] tdf#136836 emfio: set size hint on inner PDF if used as shape fillMiklos Vajna2020-09-182-2/+17
| | | | | | | | | | | | | | | | | | | 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
* tdf#136836 emfio: speed up import of EMF import when the orig PDF is availableMiklos Vajna2020-09-171-8/+78
| | | | | | | | | | | | | | | | | 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
* remove constructor with plain Bitmap from Graphic, use BitmapExTomaž Vajngerl2020-08-151-1/+1
| | | | | | | Change-Id: Ie429a10a8f54c6779d437ee4bc75a5ea0c427848 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100727 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
* Silence loplugin:staticmethods when the definition involves preprocessingStephan Bergmann2020-08-051-4/+4
| | | | | | | | | | | | | | | ...to help avoid false positives. (Another option to silence such warnings is to add (void) this; to false-positive function bodies, but this new approach may be more natural in certain cases.) Change-Id: Ie6ea908730c596dbfb62ff42ae60dbd0a00a8fc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100152 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* emfio: create instances with uno constructorsNoel Grandin2020-07-063-122/+11
| | | | | | | | | See tdf#74608 for motivation Change-Id: I1685fe05a2a6b1761e78359596c265ac6487f99b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98217 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Upcoming improved loplugin:staticanonymous -> redundantstatic: emfioStephan Bergmann2020-07-012-2/+2
| | | | | | | Change-Id: Id7ceb329a6fa6f2af15bf4599ef97dcbd44fa64d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97559 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* tdf#133448 tdf#133435 ignore broken rectangles so can we load dodgy EMF/WMFNoel Grandin2020-05-302-4/+2
| | | | | | | | | | | regression from commit 059f07f9f33460c809a93e0fda1165f5c6f6d805 fixes for code creating reversed Rectangles Change-Id: Ia4d41ac6845afcae3da1c259d8fbf48aa7db3489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95165 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* loplugin:simplifybool in dbaccess..frameworkNoel Grandin2020-05-291-1/+1
| | | | | | | Change-Id: I0d73bb7d8d3fde426edc0a10c0750758b68aceb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95099 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* compact namespace in editeng..extensionsNoel Grandin2020-05-081-4/+4
| | | | | | | Change-Id: Ie93ac69592c3625b8e2e5db3619ce24597a07a7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93722 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Extract getting default locale for filters into separate unotools functionMike Kaganski2020-04-271-17/+2
| | | | | | | Change-Id: Ic97b1a4507d5629963f360147ecc20eb10f5d391 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* Don't convert OUString to char*Mike Kaganski2020-04-271-1/+1
| | | | | | | Change-Id: I3bfcc6fedb782b12be1fb1d42981756287f29f82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92956 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
* fixes for code creating reversed RectanglesNoel Grandin2020-04-162-0/+12
| | | | | | | | | | | | | | | | | | | ie. where left > right or top > bottom These are all places where the code is self-evidently doing the wrong thing. Found by adding asserts to tools::Rectangle. In theory, this is legit, and code that wants a proper Rectangle is supposed to be first call Justify on a Rectangle, but lots of places don't do that, and that seems very dodgy to me. So lets work towards Rectangles always being in a valid state. Change-Id: I03296a624bd9b5b193e6aa8778addfb09708cdc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92310 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* loplugin:flatten in embeddedobj,emfioNoel Grandin2020-04-143-259/+259
| | | | | | | Change-Id: Ibaf5e1a4db1088322cf8c5e127d328b140406197 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92196 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* Drop o3tl::optional wrapperStephan Bergmann2020-02-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...now that macOS builds are guaranteed to have std::optional since 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to Xcode 11.3 and macOS 10.14.4". The change is done mostly mechanically with > for i in $(git grep -Fl optional); do > sed -i -e 's:<o3tl/optional\.hxx>\|\"o3tl/optional\.hxx\":<optional>:' \ > -e 's/\<o3tl::optional\>/std::optional/g' \ > -e 's/\<o3tl::make_optional\>/std::make_optional/g' "$i" > done > for i in $(git grep -Flw o3tl::nullopt); do > sed -i -e 's/\<o3tl::nullopt\>/std::nullopt/g' "$i" > done (though that causes some of the resulting #include <optional> to appear at different places relative to other includes than if they had been added manually), plus a few manual modifications: * adapt bin/find-unneeded-includes * adapt desktop/IwyuFilter_desktop.yaml * remove include/o3tl/optional.hxx * quote resulting "<"/">" as "&lt;"/"&gt;" in officecfg/registry/cppheader.xsl * and then solenv/clang-format/reformat-formatted-files Change-Id: I68833d9f7945e57aa2bc703349cbc5a56b342273 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* clang-tidy modernize-concat-nested-namespaceNoel Grandin2020-01-311-15/+6
| | | | | | | Change-Id: Iab35a8b85b3ba1df791c774f40b037f9420a071a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86708 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* New loplugin:unsignedcompareStephan Bergmann2020-01-282-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Find explicit casts from signed to unsigned integer in comparison against unsigned integer, where the cast is presumably used to avoid warnings about signed vs. unsigned comparisons, and could thus be replaced with o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx) o3tl::make_unsigned requires its argument to be non-negative, and there is a chance that some original code like static_cast<sal_uInt32>(n) >= c used the explicit cast to actually force a (potentially negative) value of sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the cast to avoid a false "signed vs. unsigned comparison" warning in a case where n is known to be non-negative. It appears that restricting this plugin to non- equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=) is a useful heuristic to avoid such false positives. The only remainging false positive I found was 0288c8ffecff4956a52b9147d441979941e8b87f "Rephrase cast from sal_Int32 to sal_uInt32". But which of course does not mean that there were no further false positivies that I missed. So this commit may accidentally introduce some false hits of the assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan --enable-dbgutil) `make check && make screenshot`. It is by design that o3tl::make_unsigned only accepts signed integer parameter types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in include/oox/helper/helper.hxx is used with both signed and unsigned types, so needs a little oox::detail::make_unsigned helper function for now. (The ultimate fix being to get rid of the macro in the first place.) Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* fix constants according to [MS-EMF] 2.1.10Andras Timar2020-01-201-2/+2
| | | | | | | Change-Id: I048eb097e9570f2ad2fecef5e725c98e36e6559e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87078 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
* tweak GetBitmap methods in BitmapExNoel Grandin2020-01-151-4/+4
| | | | | | | | | | | | so we return a const& for the normal case, just like other methods, which reduces copying. This revealed that CreateDisplayBitmap in Bitmap can be const. Change-Id: I9f9b9ff0c52d7e95eaae62af152218be8847dd63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86836 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
* use more std::make_sharedNoel Grandin2020-01-101-2/+2
| | | | | | | | | | found using 'git grep', I tried using clang-tidy, but it only successfully found a tiny fraction of these Change-Id: I61c7d85105ff7a911722750e759d6641d578da33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2024-05-18 11:49:52 +0000