summaryrefslogtreecommitdiff
path: root/emfio
AgeCommit message (Collapse)Author
2022-12-02tdf#152094 retain more accuracy from RefDevMode::MSO1Caolán McNamara
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>
2022-11-11Revert useless std::move of const objectStephan Bergmann
...added with f71606c920a3f78294da745cd9ef1eacde010224 "new loplugin:moveit". (I came across this code with an upcoming loplugin:constmove that flags suspicious uses of std::move involving const-qualified types.) Change-Id: If9c79d9a838fab5efbb55cb89b27b87f7e7ccd76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142562 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-08tdf#143148 Use pragma once instead of include guardsHarshita Nag
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
2022-11-08Make EMR_SAVEDC not UpdateClipRegionParis Oplopoios
EMR_SAVEDC would call UpdateClipRegion which would break the clip region sometimes before drawing the text causing it to not be clipped This line was introduced in a i#964 related patch (https://bz.apache.org/ooo/show_bug.cgi?id=964) The document in that test seems to render the same and the test file from the changed test renders the same also before and after this patch Change-Id: Id515b90efc9e533e18a35030a9a677de4d4ea02d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142272 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-11-08tdf#151844 Make EMR_EXTSELECTCLIPRGN factor in WinOrg coordinatesParis Oplopoios
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>
2022-11-05-Werror,-Wdeprecated-declarations (sprintf, macOS 13 SDK): emfioStephan Bergmann
Change-Id: Id69f3639cb957570c4165150b288397c6e06727e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142324 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-03UnoApiXmlTest: add new wrapper for XmlTestTools testsXisco Fauli
Change-Id: I767f464ec666330a2e8e832b6d6f5736a6bef54d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142228 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-11-01CppunitTest_emfio_emf: inherit from UnoApiTestXisco Fauli
Change-Id: If1278f336aaff56a4378dcc1f0f95e0a749b629d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142099 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-10-25cid#1516423 Uninitialized scalar fieldCaolán McNamara
Change-Id: If60dfb726ba42bcb96a2d218bb81cb700f4c71f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141805 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-10-24tdf#150888 Scale down PPI if it would result in a tiny imageParis Oplopoios
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>
2022-09-08Rework of SoftEdgePrimitive2DArmin Le Grand (allotropia)
This is pretty much the same for SoftEdgePrimitive2D as the change for GlowPrimitive2D, so for more comments please refer to commit c2d1458723c66c2fd717a112f89f773226adc841 Added suggested change of DoSaveForVisualControl mechanism Change-Id: I28901e7a0b6e1823000d2aa6a335ce2fd80e6ce3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139585 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-08-24tools: rename Rectangle::Justify() to Rectangle::Normalize()Chris Sherlock
Jusify() normalizes the rectangle so both the Width and Height are positive, without changing the location of the rectangle. It ensures that the x and y coordinates will be moved to the top left of the rectangle. The name is strange, so renaming Justify() to Normalize(). Change-Id: Idbf163e65e52a798e38f785b8961b8042cf0cf2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137379 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-08-18loplugin:moveitNoel Grandin
Change-Id: I34de7408553e4ca702cab9aa611c03dc60b9b6a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138472 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-14tdf#104921: Cleanup Kashida insertion logicKhaled Hosny
Communicate Kashida insertion positions in an explicit way. Rest of LibreOffice communicate adjustments to character widths (e.g. for justification or spacing) using so-called DX array. DX array is an array of absolute character positions (e.g. DX[n] is the position after character n from the start of the lines, and its widths is DX[n] - DX[n-1]). This DX array is modified also when Kashidas are inserted after a given character for Arabic justification, by expanding its width. VCL would use this to know where to insert the Kashidas and how many ones. But because DX array is used for both widths adjustments and kashida insertion, this turns out to be a source of bugs since VCL has tosecond guess the DX array to find which is pure width adjustment and which also involves Kashida insertion, and the heuristics it uses are fragile. This change adds a second array of booleans that records where Kashida is inserted and communicates it all the way from where Kashida insertion is decoded in Writer and down to VCL layout. This change passes the Kashida array only when it seems necessary (e.g. during drawing but not when measuring text since the DX array is enough in this case). Hopefully no places where Kashida insertion needs to be passed down were missed. A couple of glyph and layout flags that were used for old heuristics and no longer needed and are removed. This also fixes: tdf#87731 tdf#106309 tdf#108604 tdf#112849 tdf#114257 tdf#127176 tdf#145647 tdf#146199 Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-13clang-tidy modernize-pass-by-value in variousNoel Grandin
Change-Id: Ie091b22bd77d4e1fbff46545bc86c12f1dbafcfe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138171 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-25loplugin:moveitNoel Grandin
make the plugin more conservative, so we see less false+ (although we also miss some possibilities in the process) Change-Id: I91b1806271e7f802d7459834ab7bcc569047da3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137342 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-19Replace old png writer in emfreader.cxxofftkp
Change-Id: Ibc3ed62d5d09d2da9d7866deb21f49340ba71eea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137117 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-07-14loplugin:moveitNoel Grandin
Change-Id: I2702e716dc669ffbb870d36d060e110288d7a744 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137043 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-08Make TestEmfPlusDrawPathWithCustomCap succeed on Aarch64Stephan Bergmann
CppunitTest_emfio_emf CPPUNIT_TEST_NAME=Test::TestEmfPlusDrawPathWithCustomCap introduced in 5b21b65572610df88986e700b81f1156aff14f65 "tdf#142770 tdf#143031 EMF+ Implement CustomLineCap" failed for me both in a local master build on macOS on Apple M1 and in a Linux aarch64 test build of the libreoffice-7.4.0.1 Flathub flatpak (at <https://buildbot.flathub.org/#/builders/21/builds/7749>) with > xmltesttools.cxx:195:Assertion > Test name: (anonymous namespace)::Test::TestEmfPlusDrawPathWithCustomCap > equality assertion failed > - Expected: 1423.297394625,1268.98481214025 830.006276132353,558.656004112967 > - Actual : 1423.297394625,1268.98481214025 830.006276132352,558.656004112967 > - In <>, XPath contents of child does not match As this failed in exactly the same way for rather different builds (Clang vs. GCC; Apple M1 vs. whatever ARM processor used by <https://flathub.org/builds>), it smells like the test input might trigger a case where operations can legitimately produce slightly different floating point results, which would then cause the test to erroneously fail for some builds. So I hacked the test input emfio/qa/cppunit/emf/data/TestEmfPlusDrawPathWithCustomCap.emf slightly, making the EmfPlusPath's 2nd EmfPlusPointF Y coordinate identical to the 1st one's, so that the arrow now points west rather than north-west, > 00000190: 02 10 c0 db 00 00 00 00 00 00 cc ff 08 40 0e 03 > 000001a0: 2c 00 00 00 20 00 00 00 02 10 c0 db 02 00 00 00 > 000001b0: 00 00 00 00 2b b5 05 45 05 54 56 45 d6 66 00 45 > -000001c0: 05 54 56 45 00 01 81 01 15 40 0e 00 10 00 00 00 > +000001c0: 51 23 4d 45 00 01 81 01 15 40 0e 00 10 00 00 00 > 000001d0: 04 00 00 00 0f 00 00 00 0e 00 00 00 14 00 00 00 > 000001e0: 00 00 00 00 10 00 00 00 14 00 00 00 which happens to let the test compute a different polygonstrokearrow/polygon value now, but which appears to be stable across at least my x86-64 and aarch64 test builds. And temporarily reverting the non-test (i.e., drawinglayer) parts of 5b21b65572610df88986e700b81f1156aff14f65 would make the test fail with > xmltesttools.cxx:121:Assertion > Test name: (anonymous namespace)::Test::TestEmfPlusDrawPathWithCustomCap > assertion failed > - Expression: xmlXPathNodeSetGetLength(pXmlNodes) > 0 > - In <>, XPath '/primitive2D/metafile/transform/polygonstrokearrow/polygon' not found so the test appears to still faithfully check the intended difference in behavior. Change-Id: Iec31246dd7666ec764176622ccc4f246eea6e4ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136896 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-27tdf#142770 tdf#143031 EMF+ Implement CustomLineCapBartosz Kosiorek
Change-Id: I9fae1d259ecdca37a1babac8a8a0e503b2dc0118 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135960 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-06-14tdf#131506 tdf#143031 EMF+ Fix displaying PathGradient fillBartosz Kosiorek
With previous implementation, the EMF+ import is calculating gradient positions wrongly. It is causing warning: SvgGradientHelper got invalid SvgGradientEntries outside [0.0 .. 1.0] and the gradient was not displayed at all. This patch fixes that and gradient is displayed correctly Change-Id: I6229c516165436d0c7ae187d9eb69b5494da396f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135607 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-06-10new loplugin:moveitNoel Grandin
look for local variables that can be std::move'd to parameters off by default, since it doesn't do proper data flow analysis Change-Id: I3403a0fcffd165bdea6a772528bc53995c5fdb40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135527 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-05-16tdf#143876 EMF+ Add DrawClosedCurve and FillClosedCurve supportBartosz Kosiorek
With this commit EmfPlusDrawClosedCurve and EmfPlusFillClosedCurve support was added. There is still missing Filling Mode (it is always set to Even Odd Alternate: https://en.wikipedia.org/wiki/Even%E2%80%93odd_rule ) and Tension support for spline bends. The graphics is displayed as Tension=0. A value of Tension=0 specifies that the spline is a sequence of straight lines. As the value increases, the curve becomes more rounded. For more information, see [SPLINE77] and [PETZOLD]. Change-Id: Ibccfd584e3d55cd0ca8a29da9f450916d56705d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134333 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-05-13tdf#142261 EMF+ Add support for Miter LimitBartosz Kosiorek
With this commit the Miter is properly implemented, according to [EMF-PLUS] documentation: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-emfplus/5ef071f3-f503-4f16-b027-7c4bcf2d1d81 The formula for stroke miter limit is described here: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/stroke-miterlimit Change-Id: Ida87063cc045460e61ffae118f64cf133c810dbf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134164 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-05-09tdf#143875 tdf#55058 EMF+ Add support for individual line endingsBartosz Kosiorek
EMF+ is allowing different caps and arrows on both ends It is not possible to implement that with css::drawing::LineCap, as it is set line endings on both line start and line end. Additionally when the Dash Pattern is used, the css::drawing::LineCap is also applied there. To resolve that limitation, the Cap needs to be implemented independetly by using PolygonStrokeArrowPrimitive2D, and the css::drawing::LineCap inside drawinglayer::attribute::LineAttribute always set to css::drawing::LineCap_BUTT Change-Id: I4be76e2dbefcb34154a1404c3b57dc4b7f7ada85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133299 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-05-09tdf#89331 EMF/WMF Fix holes in lines created with LINETOBartosz Kosiorek
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>
2022-04-24Remove brittle test from WmfTestHossein
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>
2022-04-22tdf#55058 tdf#143875 EMF+ Don't change line weight while rotatingBartosz Kosiorek
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>
2022-04-21tdf#55058 tdf#143875 EMF+ Fix display of dashed lines and line jointsBartosz Kosiorek
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>
2022-04-16Update README.md filesHossein
* 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>
2022-04-14Fix typoAndrea Gelmini
Change-Id: I5707dbda5468256c8d03ac35b43fb54b8b4f3c7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132991 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2022-04-13Add info on limerest / dump drawyinglayer primitivesHossein
* 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>
2022-04-06tdf#148359 Fix emfio regression: missing emf imageHossein
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>
2022-04-06Fix type, calculation of FamilyFont PitchAndFamilyHossein
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>
2022-04-01tdf#147818 EMF+ Fix restoring clipping statesBartosz Kosiorek
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>
2022-03-29tdf#147906 change sqrt(a * a + b * b) occurences to std::hypot(a, b)Bartosz Kosiorek
Change-Id: Ic84899bf34f98382e6cc1ffc14310b1667279ee2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132214 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-15-Werror,-Wdeprecated-enum-enum-conversionStephan Bergmann
...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>
2022-03-15tdf#145614 Convert #define to enum and constexprHossein
* 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>
2022-03-14Remove EMR_SETARCDIRECTION from unimplemented recordsHossein
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>
2022-03-10tdf#113066 tdf#142204 EMF Implement SETARCDIRECTIONBartosz Kosiorek
Change-Id: I30206c68ecf1829ba0094e6259b8ed7dc05f2e9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131103 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-02-08drop checksum assert that is platform dependentCaolán McNamara
Change-Id: I3459d753a8f655ca34ecf6c25fdfd9655687c6d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129660 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-02-04the real font used for 'Roman' is arbitraryCaolán McNamara
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>
2022-01-17Recheck modules [e-f]* with IWYUGabor Kelemen
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>
2022-01-11Adapt test value intervals to my Linux --without-system-fontconfig buildStephan Bergmann
Change-Id: Ie0867782b0925800cc094f43f8387fb9d1ff0c21 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128272 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-10Move HAVE_MORE_FONTS into an extra config headerJan-Marek Glogowski
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>
2022-01-09Improve some CPPUNIT_ASSERT checksStephan Bergmann
(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>
2021-12-23Split BasePrimitive2D UNO interface into separate objectNoel Grandin
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>
2021-12-22Separate core drawinglayer func. into drawinglayercore libraryTomaž Vajngerl
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>
2021-12-21loplugin:flatten in editeng..extensionsNoel Grandin
Change-Id: Ica8f0a6e3d30dba3b5a083e3c04522073de8303f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127233 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-10Generally determine Rdb content from gb_*_set_componentfile callsStephan Bergmann
...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>
generated by cgit (git 2.34.1) at 2024-08-12 06:48:33 +0000