summaryrefslogtreecommitdiff
path: root/emfio/qa
AgeCommit message (Collapse)Author
2023-10-07loplugin:ostr: automatic rewriteStephan Bergmann
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2023-10-06xmltesttools: add assertXPathDoubleValue that takes a double with deltaIlmari Lauhakangas
and use it to make WmfTest::testSetTextAlignWmf independent of DPI Change-Id: I2048239088a8dcc3e3ab1db96413894b5bcc56d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157377 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-07-23tdf#156234: Don’t round glyph coordinates when doing subpixel positioningKhaled Hosny
When doing subpixel positioning (i.e. OutputDevice is in map mode), delay the rounding of the glyph coordinates after converting from pixel to logical units to minimize the loss of precision as much as possible. Some test expectations, expectedly, changes due to the improved positioning precision. Change-Id: I2591e3c7d4923ba7886a35bf53db759273354e24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154292 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-06-13tdf#143877 Fix failing tests caused by floating point precisionBartosz Kosiorek
Due to different imlementation of floating-point unit (FPU), on different CPU platforms, the floating point numbers could could be different. https://stackoverflow.com/questions/64036879/differing-floating-point-calculation-results-between-x86-64-and-armv8-2-a https://mcuoneclipse.com/2019/03/29/be-aware-floating-point-operations-on-arm-cortex-m4f/ With this path I have changed the tested images, to use floating point numbers which are easily represented by floating numbers (multiplied/divided by 2), like: - change tension to values: 0.125, 0.25, 0.5, 1.0, 1.5 ... - change position of curve to of control points to 256.0, 384.0 512.0 Previous values was hard to represent by floating numbers, for example tension: - 0.4 has been written as 0.399999976158142 - 0.1 has been written as 0.099999994039535 More information: https://observablehq.com/@benaubin/floating-point Additionally the precision of numbers were increased to double. Change-Id: I5725c1f2f474d0c00821edaa9bb2102cb172093f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152838 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2023-06-01tdf#143877 EMF+ Implement EmfPlusDrawCurve with cardinal splineBartosz Kosiorek
Change-Id: I98d30b2a8ba63fdddc08668f453c5f0feeb452db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152288 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2023-05-12EMF Fix text aligning for EMR_SETTEXTALIGN for wrong values.Bartosz Kosiorek
Change-Id: I4d67eb7112d2295185905eac52ebab022a1beb78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151670 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2023-05-10tdf#142249 EMF Implement EMR_POLYDRAW recordBartosz Kosiorek
The EMR_POLYDRAW record specifies a set of line segments and Bezier curves. Change-Id: I93d846d2fbb7a60b0565668a17ee092da30ef21c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151424 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2023-04-23tdf#154789 EMF+ Performance boost of the EmfPlusRecordTypeDrawBeziersBartosz Kosiorek
There is several benefits of such performance optimization: 1. We are drawing single curve instead of hundreds of small curves. In the loop we are creating single Polygon and outside of the loop we are invoking EMFPPlusDrawPolygon drawing method only once. As https://bugs.documentfoundation.org/attachment.cgi?id=186725 image is using single EmfPlusRecordTypeDrawBeziers EMF+ record with hundreds of curves, with using single EMFPPlusDrawPolygon call, there is no lnger need for individual line creation (e.g. line color, weight, line caps, line joints, line dashes, etc.) - The PDF export performance without optimizations of the https://bugs.documentfoundation.org/attachment.cgi?id=186725: time ./instdir/program/soffice --headless --convert-to "pdf:writer_pdf_Export" --outdir ~ ~/Pobrane/problem.docx real 24m18,471s user 2m56,004s sys 1m37,816 - The PDF export performance with optimizations: real 0m37,527s user 0m37,004s sys 0m0,531s - With Libreoffice 7.5.2 from Ubuntu 22.04, the conversion was crashed. 2. The PDF export for document: https://bugs.documentfoundation.org/attachment.cgi?id=186725 was not working correctly for me. The original image is containing chart. Without optimization, the exported chart was empty. Current export is working correctly, and graph is visible. 3. The standard opening of the document from https://bugs.documentfoundation.org/attachment.cgi?id=186725 is now much faster. The zooming in, move image operations are also noticible faster. Change-Id: Ic77d4c20a462587bb5da4a4df757e30c5ca04fc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150821 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2023-04-11CppunitTest_emfio_emf: use CPPUNIT_TEST_FIXTURE()Xisco Fauli
This suite is large enough so that avoiding the declaration/registration/definition of each test manually saves a lot of space. Change-Id: I476b58a1c45ed5c977ce71a92d172b7e2df93015 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150224 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-03-09Demultiplex test codeStephan Bergmann
It is so much easier to work with if a test failure's line number unambiguously points at the code's sole execution. (That is, test code is necessarily non- DRY.) Change-Id: I75919c55671348f6190e9e108e72e24ec18ce986 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148514 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-11tdf#142018 Properly create Pen width if style is COSMETICBartosz Kosiorek
Change-Id: I6453058c4af352a3b0e14cbccbc1a67c73cd1426 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146551 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2022-12-13tdf#152435 Revert "Make EMR_SAVEDC not UpdateClipRegion"Paris Oplopoios
This reverts commit 1230b88055c7389d2c376c316f91549e4aaef8aa. Reason for revert: The reverted commit breaks the files documented in tdf#152435 (some text is not shown in those .EMF files). The reverted commit would solve an issue where some text was not clipped correctly, albeit in a naive way. As it is more important that text is shown rather than some text having correct clipping, that patch is reverted and I will look for one that fixes both cases. Change-Id: I42e85b802b8bf1e77e96f0016cd1d83201047032 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143970 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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-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-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-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-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-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-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-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-10-19emfio: remove unused fileXisco Fauli
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>
2021-10-15CppunitTest_emfio_emf: add some tolerance in TestPdfInEmfIlmari Lauhakangas
Change-Id: I1fc1b3863fd5b5472e700a5432fb4f9d353a054f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123650 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-09-27tdf#88163 Fix font size for placeable wmf filesHossein
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>
2021-09-03tdf#88163 Fix WMF font sizeHossein
The problems in tdf#88163 can be categorized into two parts: 1. A regression which is caused by the commit a9020e461803964a206d5551884b70717eed165c. The font size for text is wrongly calculated for wmf files WITHOUT the placeable header. 2. A long-lasting bug that has existed from LO 3.5 (tested with various LibreOffice versions from 3.5 to master). The font size for text is wrongly calculated for wmf files WITH the placeable header. This patch solves the first part. In this patch the way wmf is scaled is changed using mnUnitsPerInch as a variable that controls the scale. The previous method was dividing the left/right/top/bottom fields of aPlaceableBound which caused the bad scaling of text. The second problem still remains, and possibly can be solved by usign the old scaling method that was previously used here (dividing pos values of aPlaceableBound), but the scaling factor should be calculated, which varies in different wmf files. More study should be done to solve this part. Values used for the example "visio_import_source.wmf" used in the test WmfTest::testNonPlaceableWmf() are slightly changed, but the rendering should not noticeably change, except the fix for the text font size. A new test WmfTest::testTdf88163NonPlaceableWmf() is added which checks for both font height and text boxes' positions. Font height can depend on the exact font that is used for Roman in the platform, so it vary between Linux, Windows and macOS. Thus, a range is used for ensuring that the font height is correct. By visual inspection, it is confirmed that this fix does not affect fdo#74336 and the fix for it still works for attachment 93188. Change-Id: I55bf38ba4345a0aa48c3e522976a2a5c32f7ec8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121272 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-07-13Enable automatic code style formatting for EmfImportTest.cxxBartosz Kosiorek
As EmfImportTest.cxx code style is follow the recommended code style (except too long lines), the code is used only for testing and it is rarely modified, I decided to enable automatic code formatting. It is one step closed to migrate to common code style. Change-Id: I1b7f980b9e68e121ba981b8a8222daa31424ac53 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118864 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2021-07-13Decrease line length of EmfImportTest.cxx by introducing const stringBartosz Kosiorek
Change-Id: Ie30d0246d6ca54821f00fe516ab67f803ef0d804 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118863 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2021-07-06CppunitTest_emfio_emf: add some tolerance in TestDrawStringAlignMiklos Vajna
Commit 574dc1e8ff6ea4214fefd91216fca5146a4ff13e (EMF+ tdf#142995 tdf#142997 tdf#143076 Add alignment support for DrawString, 2021-06-24) added this test, it seems the result depends on what fonts are installed, so add some tolerance. Probably it fails for me (and not on Jenkins) as I have lots of additional fonts installed, e.g. Arial (and not only Liberation Sans). Change-Id: Ie93d1f1efe1fbbf1851ad46f33f5f83c8812e6d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118470 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-07-03EMF+ tdf#142941 Fixes for SrcRect in DrawImagePointsBartosz Kosiorek
The SrcRect could be specified outside of source bitmap. In such cases the Destination bitmap should be displayed as shifted (eg. if position is negative), and scaled properly. Change-Id: Ied6d339703999faaae061802ef6a28e190d5a176 Change-Id: Ia9772ced282684c2c94a261d97d30b53921d6171 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118345 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2021-07-01EMF+ tdf#142995 tdf#142997 tdf#143076 Add alignment support for DrawStringBartosz Kosiorek
With this commit, real size of the text is used to make proper horizontal alignment. Additionally vertical alignment is added and fix for Center alignment was applied Change-Id: I17d9fd7de7f00f5e69f99c5b09061eb6059be67e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117794 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
2021-06-23EMF+ tdf#142975 Add brush support to DrawString recordBartosz Kosiorek
Change-Id: Icfcb4199dcd755fb20e14a8166571b6d6e763f2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117671 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
generated by cgit (git 2.34.1) at 2025-01-19 10:38:58 +0000