summaryrefslogtreecommitdiff
path: root/basegfx
AgeCommit message (Collapse)Author
2023-07-23ofz#57493 TimeoutCaolán McNamara
Change-Id: Id8811e65227142881fc86f6d2db231fa053fc2d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154768 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-21loplugin:redundantcast small improvementNoel Grandin
Change-Id: I2c96b367138b94d6178a3c4a0f83049f13a04f82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154679 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-07-13basegfx: replace typedef with a class B2ISize based on Size2DTomaž Vajngerl
Change-Id: Iaf7d02bb236f81a38a67a1430a718b6c3c78efae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139708 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-07-10tdf#99562: Do not ignore last column from matrixXisco Fauli
Change-Id: I1dff65963e2c414d1771a1592159930150c513e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154241 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-07-07related: tdf#155735: clamp RGB valuesXisco Fauli
So when a green matrix is used, everything becomes green. Also set alpha to 1.0 so at least a green matrix on black returns green and not black Change-Id: I9104c7511545fb244750b066bb1e996b6ce229f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154167 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-07-04loplugin:constantparamNoel Grandin
Change-Id: Iee554baae7239c9bf0ac35cab6ff235a88dc29a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153973 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-26Revert "tdf#132246, tdf#155735: Add support for SourceAlpha"Xisco Fauli
This reverts commit 75399b8aad6c0f0998b9d0a6eddb2e29f8bc114c. it was incomplete. While at it, do not parse 'in' attribute for now, so only in="SourceGraphic" is used. Implementing the 'in' attribute is not trivial Change-Id: I66c721c1144638f5e3759e0aa3a1c2c062499a90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153627 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-25tdf#155735: use 4x4 matrices in testsXisco Fauli
Change-Id: I7258443036eb89e7a67fce2a683f3212972a7395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153565 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-24tdf#132246, tdf#155735: Add support for SourceAlphaXisco Fauli
Change-Id: I8feae2447b17e15113ca45fe46c0d68cb6b6ab71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153550 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-22basegfx: Add test for BColorModifier_black_and_whiteXisco Fauli
Change-Id: I35193c68034e5500f12a2e474886c6aa9c2307ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153457 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-22tdf#155735: Add support for matrix typeXisco Fauli
Change-Id: Icc172c5f47731ddcf0beca64c72c2022313e74a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153177 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-22tdf#155735: Add support for hueRotate typeXisco Fauli
Change-Id: I9c7ada2908c0739708fbc9e28ac58430350da7a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153112 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-21tdf#155735: Add tests in basegfxXisco Fauli
Add tests for BColorModifier_luminance_to_alpha and BColorModifier_saturate Use basegfx::fTools::equal in B3DTuple::operator==, otherwise some asserts fail with - Expected: [0.3575, 0.8575, 0.3575] - Actual : [0.3575, 0.8575, 0.3575] Although they are equal Change-Id: Iad6d9ff78a390f5ee2a3e33e479e34d98e751b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153394 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-21tdf#155735: use B3DHomMatrix in BColorModifier_saturateXisco Fauli
Change-Id: Ibdbe9c55220239f4b8458742ac5625c002963217 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153390 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-16tdf#155852 same method for StepCount in OOXML as in renderingRegina Henschel
Rendering of stepped gradients uses a method that doesn't take the color from a cut point, but before or after respectively. For example, for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1 are used. So sections are 'start color', '1/3 color', '2/3 color' and 'end color'. The output to OOXML now uses the same method. That way rendering in a produced pptx-file is the same as in the original odp-file. Since OOXML has nothing similar to StepCount, it is an export only problem. A second problem comes from the cuddle with StepCount in Gradient struct in API and FillStepCount in shape property set. The draw:gradient-stop-count attribute in ODF belongs to the graphic style of the shape. The gradient definition itself in the <draw:gradient> element has nothing about step count. When a file is opened, it can be that the StepCount component in the Gradient struct still has the default value 0, but the FillStepCount property has the correct value of the shape. The Gradient struct in the API should not have a component StepCount to be compatible with ODF. But the API is published and changing that struct is far-reaching in the code. So the fix here is not a general solution but solves the problem for export to OOXML by reading the FillStepCount property while exporting. Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-06-14tdf155825 result same size in synchronize gradientsRegina Henschel
While synchronizing color and transparency gradients two new sequences are generated. In case the last offsets where different, the remaining stops where not copied to the new sequence and thus they had different sizes which triggered an assert in oox/source/export/drawingml.cxx. Change-Id: I446f8cfafb23735f06ad4e05eee8c922141b864d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153063 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-06-14tdf#155735: Add support for saturate typeXisco Fauli
Add getModifierName to BColorModifier class so when can assert which modifier is being used Change-Id: I2bc2a36470a449df4dc84a8440f232149c1f8278 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153048 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2023-06-13tdf#145538 Refactor to use range-based for-loopbuldi
Change-Id: I7c75593fef6d3226011a938349850dc485b763c2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148204 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2023-06-09Fix typoAndrea Gelmini
Change-Id: Iaebe55927771985a6b574b2cb9410b0eb75441e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152789 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-09Fix typoAndrea Gelmini
Change-Id: Ib02cc0e9aaf286d8c39523ea352cfeec17a6336f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152788 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-06-09MCGR: tdf#155479 repair gradient SVG export for MCGRArmin Le Grand (allotropia)
Unfortunately SVG export is based on metafiles and thus there is (in principle) no way to get the BGradient/ColorStop/MCGR data transfered as needed. For that, using UNO API to read the model or using B2DPrimitives would help - as is better for the export respectively. Since there is not the time to re-design SVG export I added this 'compromize' as a fix. It gets the needed data transported over the metafile (that part is the compromize). It then exports the MCGR data to SVG (at least - as was already there - if it's a linear/axial gradient). This happens now with all Gradient Stops when there is a MCGR gradient. That part is/will hopefully be re-usable if SVG export gets redesigned. I also added a handling for StepCount feature, so when used (in LO, others do not have that) 'hard' color stops get generated to make the gradient look identical for SVG export. Had to make adding of that extra-information in metafiles dependent on exporting really to SVG. There are 51 cases which use 'MetaActionType::COMMENT' which would potentially have to be adapted. Also added code to solve the problem for TransparencePrimitive2D at VclMetafileProcessor2D::processTransparencePrimitive2D. This will now - also only for SVG export - directly create the needed MetaFloatTransparentAction and add additional MCGR information. This will be used on SVG export to write a 'Mask' as was done before. This is now capable of creating fill MCGR-Masks in the sense that any number of TransparencyStops will be supported. Change-Id: Ic6d022714eae96b8fbc09e60652851ac5799b757 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152623 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-06MCGR: tdf#155537 correct usage of wrong result in toolingArmin Le Grand (allotropia)
Change-Id: I8f68ecc7ccaecf84abbcda1bcdd65e2295baaf0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152673 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-05tdf#155549 MCGR: Recreate 'axial' from symmetric 'linear'Regina Henschel
When exporting a shape with an axial gradient fill to OOXML, it is converted to a linear gradient with multiple color stops. Versions before MCGR had recreated it as axial gradient on import from OOXML. But now LO is able to handle multiple color stops and so the linear gradient from OOXML is imported as linear gradient in LO. When such file is then written as ODF, the multiple color stops are in elements in extended namespace and versions before MCGR do not understand them. They show only the first and last color (which are equal) and the gradient is lost. With this patch LO converts the linear gradient back to an axial gradient on export to ODF. The exported axial gradient is rendered in a version with MCGR same as the linear gradient when opening the OOXML file. The difference is, that versions without MCGR now render an axial gradient with two colors. Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-05-28Use getXWeak in basegfxMike Kaganski
Change-Id: I650a8fcefd179937bdcbb6088658aa960008794d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150834 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-26MCGR: Border restoration supportArmin Le Grand (allotropia)
Due to tdf#155362 I added code to be able in case we would need it to convert a BGradient using added tooling from having offsets in the GradientSteps and no border to adapted GradientSteps and border. This is preferrable due to our GradientStyle_RECT (and GradientStyle_ELLIPTICAL too) use that 'non- linear' paint aka move-two-pixels-inside, someone else called it 'frame-paint'. This does not bode well with the border being applied 'linear' at the same time (argh). Thus - while in principle all is correct when re-importing a GradientStyle_RECT with a border after export to pptx, it looks slightly better ('correcter') wen doing so. That is because when being able to and restoring a border at least that border part *is* applied linearly. I took the chance to further apply tooling, move it to classes involved and instead of awt::Gradient2 use more basegfx::BGradient since it can and does host tooling. This is also a preparation to be able to adapt (restore) border in case of turn- around in ODF where the importing instance is before MCGR existance and has to handle Start/EndColor. Needed to take more care with using BGradient instead of awt::Gradient2 for initialization, also better dividing/organization of tooling, already preparation to use for other purposes. Change-Id: I2d3a4240a5ac6fff9211b46642ee80366dc09e3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152194 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-20loplugin:unusedmethodsNoel Grandin
Change-Id: Ief95f111350808f010539bb733a553007d30a9df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152006 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-19MCGR: Adaptions to WriteGradientFill and BGradientArmin Le Grand (allotropia)
Added code to make WriteGradientFill directly use the available BGradient implementation. The goal is to never directly work on awt::Gradient2, but use BGradient & it's tooling methods. Added constructors and tooling to BGradient and BColorStops to make that easier (single line conversions between uno::Any, basesgfx classes and awt:: incarnations). Directly handle uno::Any and awt:: classes, changed stuff to make use of this. Change-Id: I083a323b9efee8ca4f3becb2966aac0a294b9a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151842 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-05-18improved B2DHomMatrixNoel Grandin
since we know that this is a matrix only used for 2D transforms, we know that the last row of the matrix is always { 0, 0, 1 }. Therefore, we don't need to store that information, and we can simplify some of the computations. Also remove operations like operator+ which are not legal for such a matrix. Change-Id: I482de9a45ebbedf79e3b6033575aab590e61c2d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151909 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-17tdf#63130 use a simpler, SIMD-friendly algorithm for matrix invertNoel Grandin
which is 10% faster loading this document Algorithm copied from https://github.com/niswegmann/small-matrix-inverse/blob/master/invert3x3_c.h, which is CC0-1.0 licensed. Change-Id: I7aa272cae90b1aee30eb6b3e8e5acb260b92ceef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151830 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-16Fix typoAndrea Gelmini
Change-Id: Id590b13237bc148dac955d6f4d56092f86d1dd16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151817 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-16Fix typoAndrea Gelmini
Change-Id: I5701a1fdfe9e4f139049ed6c0de1748ec7c06e07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151816 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-16tdf#63130 make B2DHomMatrix a flat objectNoel Grandin
instead of using COW for its data. This takes the load time from 1m29 to 1m12 Also fix a bug in ImplHomMatrixTemplate::operator= which never triggered before because the usage of o3tl::cow_wrapper means it very seldom gets used. Change-Id: Ib0a7bdddf6c014f583e06d15e8dce5025e67e4a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151793 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-15MCGR: consolidations/cleanups for changes so farArmin Le Grand (allotropia)
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-19MCGR: 2nd corrections/adaptions to MCGRArmin Le Grand (allotropia)
Adapted handling of 'border' argument from our gradients for oox export, so that it looks the same. Also added quite some cases to peserve in-between GradientStops for current UI implementations to be able to edit the gradients as usual without losing the in-between GradientStops. While we will not be able to modify these, we are at least able to modify all the other gradient attributes, including start/endColor. Done this for TransparencyGradients, too. Also moved more stuff to the gradient tooling in basegfx. Change-Id: I6e94011bbf3715baa1401ab97e5b59811298342f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150577 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-14Fix typosAndrea Gelmini
Change-Id: I7f8fa704199865e67c0543f92f89f63765c8c2ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150406 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-14Fix typoAndrea Gelmini
Change-Id: Idb607f8d35163de55e29415efe8a3cfb029eb9e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150403 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-14Fix typosAndrea Gelmini
Change-Id: I2b087d0f97c675cfedd4e2e78c7f827df4605fb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150407 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-14MCGR: Adaptions to oox exportArmin Le Grand (allotropia)
This is a 1st version and might need more fine-tuning, so it is still 'hidden' behind the MCGR_TEST env var being set (as the import is, too). Still, when used, it can now import a MCGR with transparence and export it again. I will now do extended testing/experimenting, fine-tuning where needed and prepare final change/drive forward. The current state in master should not be changed as long as the mentioned env var is not set, but this will need to be checked, too, due to changes to the export api in oox. Corrected an error in GetAlphaFromTransparenceGradient method(s), css::rendering::RGBColor is [0.0 .. 1.0] Corercted an error in WriteSolidFill where transparence gradient gets checked. This should really check if TrGr is used, but only checks for 'empty/unused' color instead (assuming COL_BLACK is 'unused'). All usages of GetAlphaFromTransparenceGradient should be checked and adapted. Change-Id: If59d7a06b9207e2efe9e71f3f8ddeca4476408f3 Change-Id: If97f8abdd0e1597aa1fd865b7e884e06a22b71f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150391 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-06MCGR: Moved color compare in common computation partArmin Le Grand (allotropia)
The colors of a ColorStopRange can be equal in case of hit *and* miss, so in both cases. I moved it to the common computation part. Prev version worked and did no harm, but unnecessary color interpolations for equal colors. Change-Id: I19031f1021ee5955b48da5c0d8e3a03cb9512ebf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150046 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-04Fix typoAndrea Gelmini
Change-Id: I4ff8556c954cae844fa35385535cf9b6e9477e08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150033 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-04Fix typoAndrea Gelmini
Change-Id: I09163a500caf66c6ac2921dca3128997574d20d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150032 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-04MCGR: Improve performance for texture-mapped MCGR processingArmin Le Grand (allotropia)
Change-Id: I20b32e7c272112c6c3d9f7ee0ef59c6d4d006d94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150020 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-03Fix typoAndrea Gelmini
Change-Id: I49fe9dbdc11291c02be1dd5e41171a987d896008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149997 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-04-03MCGR: Unify Gradient intensity handling in toolingArmin Le Grand (allotropia)
Moved the Gradient intensity handling to tooling since it is also needed for TransparencyGradients. Added missing use of GradientStepCount for transparency. Change-Id: I63ae6683fa0131be7faadc8572e19f5c43bf27e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149957 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-02MCGR: 1st additions to OOXML MCGR importArmin Le Grand (allotropia)
This change provides 1st changes to get Gradients with muti color stops imported from MSO in the oox import filter. It supports currently multiple ColorStops and transparency. Also 'border'(s) should work, but -remember- this is work in progress. Since it is work in progress it is currently and temporaily secured by ENV VAR "MCGR_TEST=0", so when not using this the master version will not be touched at all. The number defines various ColorStop tests, 0 for none, but some changes are active, e.g. MSO import. You may try 1 or 16 to see all your Gradients hard replaced by something using that feature. I will take care fo cleaning this up again when the feature progresses/gets complete. Change-Id: I92e10d8cd5150733741a6def20a542abf97bd903 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149682 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-27MCGR: More corrections fo sortAndCorrectColorStopsArmin Le Grand (allotropia)
Handle cases where gradient snippets overlap Start/End- Color to preverve input information. Added more test cases to createNewSdrFillAttribute to check these cases. All 27 look good, so add this changes. Change-Id: I6b2ba190ac8cf5a00c5a27865cea6bb41efe5110 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149624 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-24loplugin:stringadd in b*Noel Grandin
after my patch to merge the bufferadd loplugin into stringadd Change-Id: Ieb9b4f5154173738e26b429b55c7a3ea38733553 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149478 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-22Fix typosAndrea Gelmini
Change-Id: Iaf63fce5295f00e5d6fff020498a01a25fc0ee93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149262 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-03-21MCGR: Model data changes for ColorSteps (II)Armin Le Grand (allotropia)
The biggest change here is to allow multiple ColorStops with the same Offset. That allows to define gradients with 'hard' color changes at any place using two ColorStops with the same Offset and different Colors. This required quite some adaptions, but works well. Also removed in this context checking for all Colors being the same to not mix up things. Also works well. Also changed the need for having Start/EndColors AKA ColorStops for 0.0 and 1.0 in place, instead 'imply' the 1st ColorStop to also define the StartColor and the last one the EndColor. This allows e.g. Gradient definitions with two GradientStops at the same Offset e.g. 0.5 with different colors to already define a full Gradient. Also added a tooling method to reverse ColorSteps, which changes the order and mirrors the Offsets (what even keeps an existing sort valid). This is useful e.g. for GradientAxial which is the only one where for decomposition the Gradient had to be interpreted 'reverse' since it's defined from center to edge, but for creating correct filled polygons to represent this the inverse order had to be used, creating polygons from edge to center. This led to 'wild' code for this one of six cases and prevented unifications with the other cases (also made your brain flip). Thus I adapted this now to use the reversed ColorSteps consequently, and the same principle loops than the other implementations to make things easier for the future and to use common tooling. Change-Id: If2943348d17d5b9cd165f4d78f22638a1dff5237 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149208 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-19MCGR: Model data changes for ColorStepsArmin Le Grand (allotropia)
Added tooling replaceStart/EndColor to allow simple transition for code that does not immediately adapt to multi color gradients. Also added createColorStepsFromStartEndColor for the same purpose. Adapted XGradient to no longer have Start/EndColor at all, but only use ColorSteps. Adapted all usages of XGradient to no longer use Get/Set/Start/EndColor, but access the ColorSteps instead. Replaced quite some XGradient constructors that used XGradient() as Start/EndColor since this is already the default. Adapted ColorBlending to black AKA Start/EndIntens in XGradient to work now on all ColorSteps in the required linearly-scaled manner. UNO API changes: Added com::sun::star::awt::ColorStep as basic data element that holds a pair of Offset and Color. Added com::sun::star::awt::ColorStepSequence to handle an array of sorted entries. Added com::sun::star::awt::Gradient2 derived from com::sun::star::awt::Gradient, extended by the needed com::sun::star::awt::ColorStepSequence. Added MID_GRADIENT_COLORSTEPSEQUENCE to UNO API to provide access to ColorSteps directly. Adapted XFillGradientItem::QueryValue/PutValue to make use of new UNO API data structures. To do so, added tooling methods for data transition: - fillColorStepSequenceFromColorSteps - fillGradient2FromXGradient - fillColorStepsFromAny - fillXGradientFromAny and adapted - case '0' (all data) - MID_FILLGRADIENT - MID_GRADIENT_COLORSTEPSEQUENCE - MID_GRADIENT_START/ENDCOLOR to make use of these. Tested usage of these in the office. Renamed from GradientStep to GradientStop after discussions with members on the list to make this closer related to other norms/definitions. Also renamed classes and class members to better reflect to GradientStop, so grepping/finding will be easier (e.g. 'Color' just exists pretty often, but 'StopColor' is more precise). Changed the used UNO API class for reprsenting the Color to better reflect to ranges [0.0 .. 1.0] and usage of RGB. Change-Id: I1eeb3e97e81d6785967615d1ff256551fc3b882d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
generated by cgit (git 2.34.1) at 2025-02-02 02:32:04 +0000