The test cases mentioned are the following:When a gradient uses gradientUnits="userSpaceOnUse" the values of the gradient vector (x1,y1,x2,y1) are rendered using the wrong viewport. It seems the same viewport is used as if gradientUnits="objectBoundingBox" was set.
Therefore when specifying the gradient vector using percentages of the viewport, the SVG is rendered wrongly.
See the testcases for details.
– testcase1 specifies a linear gradient with <linearGradient gradientUnits="userSpaceOnUse" x2="1">.
– testcase2 specifies a linear gradient with <linearGradient gradientUnits="userSpaceOnUse" x2="100%">. x2 could be left out here however since 100% is the default.
As long as the viewport doesn't extend from (0,0) to (1,1) – the testcase should have a viewport from (0,0) to (256,256) – those gradients should render differently.
- testcase 1 using <linearGradient gradientUnits="userSpaceOnUse" x2="1">
- testcase 2 using <linearGradient gradientUnits="userSpaceOnUse" x2="100%">
How to reproduce: Open both test cases linked above using ImageMagick, e.g.:For what it’s worth, all of the following programs disagree with Inkscape (i.e. do not render the same image for test cases 1 and 2):
– Firefox
– Chromium
– GIMP
– Eye of GNOME
– GPicView
(ImageMagick, on the other hand, seems to follow Inkscape’s behavior…)
So at least from an “implementations defining standards” point of view, it seems pretty clear that Inkscape’s behavior is wrong.
Code: Select all
display testcase1.svg
display testcase2.svg
Version information (running on Ubuntu 16.04.1):
Code: Select all
display --version
Version: ImageMagick 6.8.9-9 Q16 x86_64 2016-11-29 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates: bzlib cairo djvu fftw fontconfig freetype jbig jng jpeg lcms lqr ltdl lzma openexr pangocairo png rsvg tiff wmf x xml zlib