Bug 151618 - Colorbar (using pattern fill) from an imported SVG is wrongly displayed (and shifts with zoom/scroll)
Summary: Colorbar (using pattern fill) from an imported SVG is wrongly displayed (and ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: SVG-Import Object-Fill-Pattern
  Show dependency treegraph
Reported: 2022-10-18 12:03 UTC by edera
Modified: 2023-11-06 15:18 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Figure with a colorbar (10.31 KB, image/svg+xml)
2022-10-18 12:04 UTC, edera
PDF export (7.00 KB, application/pdf)
2022-10-18 12:07 UTC, edera
Screenshot (6.19 KB, image/png)
2022-10-18 12:08 UTC, edera
Impress document with the SVG image inserted. (18.42 KB, application/vnd.oasis.opendocument.presentation)
2022-10-18 12:09 UTC, edera
Comparison: Inkscape vs Impress (159.30 KB, image/png)
2022-10-18 14:12 UTC, Rafael Lima
Video zooming in and out (197.25 KB, video/mp4)
2022-10-18 14:16 UTC, Rafael Lima
cache issue when scrolling ? (49.95 KB, video/mp4)
2022-10-18 17:20 UTC, edera

Note You need to log in before you can comment on or make changes to this bug.
Description edera 2022-10-18 12:03:32 UTC
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: / 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.
Comment 1 edera 2022-10-18 12:04:58 UTC
Created attachment 183107 [details]
Figure with a colorbar
Comment 2 edera 2022-10-18 12:07:51 UTC
Created attachment 183108 [details]
PDF export

File > Export as PDF
Comment 3 edera 2022-10-18 12:08:47 UTC
Created attachment 183109 [details]
Comment 4 edera 2022-10-18 12:09:53 UTC
Created attachment 183110 [details]
Impress document with the SVG image inserted.
Comment 5 Rafael Lima 2022-10-18 14:12:26 UTC
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: / 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
Comment 6 Rafael Lima 2022-10-18 14:16:33 UTC
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.
Comment 7 edera 2022-10-18 17:20:24 UTC
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).
Comment 8 Rafael Lima 2022-10-18 17:27:58 UTC
(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?
Comment 9 Armin Le Grand 2022-10-24 09:51:49 UTC
> @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"/>

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)
Comment 10 Armin Le Grand 2022-10-24 10:08:38 UTC
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.
Comment 11 edera 2023-03-19 18:10:35 UTC
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 (, 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.
Comment 12 Stéphane Guillou (stragu) 2023-11-06 14:20:04 UTC
Reproduced, with the zoom variability, in recent trunk build:

Version: (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?