Description: The gradient is wrongly displayed by impress, but the pdf export is fine. Steps to Reproduce: 1. In a new impress document 2. Insert image: colorbar.svg (attached) Actual Results: Impress displays the colorbar gradient in a weird manner, as if there was a circular permutation (see screenshot.png). Expected Results: Impress should display the correct information (see colorbar.pdf). Reproducible: Always User Profile Reset: No Additional Info: PDF export by impress itself is fine. This export (colorbar.pdf) can also serve as a comparison with the faulty display. Version: 7.3.3.1 / LibreOffice Community Build ID: 30(Build:1) CPU threads: 12; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL Same with both check/uncheck Use hardware acceleration.
Created attachment 183107 [details] Figure with a colorbar
Created attachment 183108 [details] PDF export File > Export as PDF
Created attachment 183109 [details] Screenshot
Created attachment 183110 [details] Impress document with the SVG image inserted.
Created attachment 183118 [details] Comparison: Inkscape vs Impress Hi Edera, thanks for reporting. Here's what I see in Inkscape (left) and in Impress (right). Indeed the gradient is not rendered correctly. Tested with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 75e6ffe31d74ac36d8864b018008d4208a7efe73 CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
Created attachment 183119 [details] Video zooming in and out Now what's interesting is that the problem depends on zoom level. See the attached video. Notice that zooming in/out of the SVG changes the way the SVG is rendered on the screen. So this is only a problem while viewing the SVG. This is why the PDF export is OK.
Created attachment 183122 [details] cache issue when scrolling ? Indeed, thanks for investigating; same here: it depends on the zoom level. And when zoomed in, it changes when scrolling, which looks like a display cache issue (no idea whether this is related or not).
(In reply to edera from comment #7) > cache issue when scrolling ? I'm not an expert in this. @Armin, could you please give your opinion on this bug?
> @Armin, could you please give your opinion on this bug? Took a look, and was surprised that SVG gradients do not get used at all - internally. The secret is in the SVG file itself: The shape is: <path style=" stroke:none;fill-rule:nonzero;fill:url(#pattern0-A1incCHk);" d="M 12 348 L 27 348 L 27 12 L 12 12 Z M 12 348 "/> And it uses "pattern0-A1incCHk" as fill. That again is: <image id="image1800-A1incCHk" width="1" height="100" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAABkCAIAAADITs03AAAABmJLR0QA/wD/AP+gvaeTAAAAi0lEQVQYlWWKQRLDMAgDQYHkHXlQP9fP2lMb6MG4cZqDZnck0et9QkWgolBNimBPqghU9frcvumbQrBDcEB5T7+ifDy6/y8TwLQNcnLtbvtwLB0FgyNAQSAPcJKCRu8EigBPrnsyuiPM4N2Hd0PYcM8tcvPF588/Bq8NXhqs9uG1w0v7udUGL3N7dF/hDX4kYoZx1wAAAABJRU5ErkJggg=="/> <pattern id="pattern0-A1incCHk" patternUnits="userSpaceOnUse" width="1" height="100" patternTransform="matrix(15,0,0,-3.36,11.999999,348)"> <use xlink:href="#image1800-A1incCHk"/> </pattern> Or in other words: It's not a SVG gradient at all, it's a encoded PNG used as pattern fill - bitmap data. Thus I guess the variable offsets and view-dependent visualization comes from repeated pattern fill. Someone would have to find out if that SVG def is displayed as SVG implies (probably should not change, but who knows)
One more note: The fill stays relative to the window when you just scroll the loaded document. That is 'over' as soon as you 'Break' the object (convert to SdrObjects which BTW shows that the fill is a Bitmap), then the fill is fixed to the SdrObject. I remember that there are fill modes in SVG that require the fill to be positioned in the 'global' SVG coordinate system, not in the local object-one. I thiink this is one of these cases (and AFAIR was hard to do), but should probably be relative to the SdrObject containing the SVG after we imported it. But even that is not clear, it may be wanted behaviour and would need discussion/consense on how such a SVG should behave in LO.
You are right that this has nothing to do with gradients. Another figure, that should hold a rasterized image (a bitmap) inside a frame, is weirdly displayed in impress (7.4.3.2), but fine in firefox or pdf. I'm not sure I understand your questions, but yes the bitmap should be positioned relative to the frame and move/scale with it.
Reproduced, with the zoom variability, in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 31fb3045dabdb27d913712f3abcade315e3ea9bd CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Bibisected with linux-64-7.3 repo to first bad commit be530ff5d47efa2621ab40f02909e74f733106f4 which points to core commit: commit 3cbe3a0259bea4dec70e72191ec3c03441926a07 author Noel Grandin Mon Jun 14 15:05:59 2021 +0200 committer Noel Grandin Fri Aug 27 08:48:19 2021 +0200 tdf#101083 speed up SVG rendering with pattern fill Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117162 Before this commit – although it had more of a halo when compared to Chromium, Firefox or Inkscape –, the gradient looked correct and was static. Noel, can you please have a look?