User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)
New problem in 2.0, it looks like the SVG linear gradient rendering is ignoring spreadMethod="pad" from the SVG 1.1 spec (http://www.w3.org/TR/SVG11/pservers.html#LinearGradients). In the linked example, you can see that the bottom part of the letter shapes are transparent, instead of being padded with white (as Firefox 1.5 correctly did). It looks like start padding is working correctly just end padding is not.
Steps to Reproduce:
1. Load SVG
2. View lack of end padding on fill gradient
Created attachment 244217 [details]
Broken gradient redering in Firefox 2.0
Shows lack of padding in Firefox 2.0 rendering.
Created attachment 244220 [details]
Correct gradient padding rendering by librsvg2.
Shows correct gradient padding rendering (but not correct placed image rendering) from librsvg2 on Linux.
Works fine on my linux build here. This sounds like a cairo version mismatch, and I see that Ubuntu uses the unsupported --enable-system-cairo build config option.
Please test using the official linux build from mozilla.com.
Yep, testing with official build shows no problems, it's a problem downstream. Sorry to waste your guys' time, I'll file a bug with Ubuntu.
So why has this been resolved as invalid? If --enable-system-cairo has a bug, then its worth an open bug. You might not suppor that, but you apparently maintain that, because it exists their. So, though this bug might be less severe its still a bug in code maintained by you.
All --enable-system-cairo does is make Mozilla use the system cairo, and in that limited task it succeeds perfectly. However, the cairo binary installed on a system is of course outside Mozilla's control. Bugs in the version of cairo installed on the system are not bugs in Mozilla, and since the binary installed on a system is not (and should not be) controlled by Mozilla, --enable-system-cairo is naturally not something we can support for releases.
That aside, I'd have thought it a good idea for package maintainers to ensure their system version of cairo is the same (or at least as recent) as the version of cairo in the Mozilla tree before using such an option.
Jonathan, thanks clarifying that you think its a bug in our version of cairo and not that its due to the use of system cairo in general.
looking at cairo-features.h, you ship (from 1.8.1 branch):
#define CAIRO_VERSION_STRING "1.0.2"
#define CAIRO_VERSION_STRING "1.0.2" (breezy)
#define CAIRO_VERSION_STRING "1.0.4" (dapper)
#define CAIRO_VERSION_STRING "1.2.4" (edgy - current stable)
#define CAIRO_VERSION_STRING "1.3.14" (feisty)
So the reporter has this issue with 1.2.4, which is more recent than cairo. Any chance that you might take a look if this is a regression in cairo, or if mozilla code base could be improved to support current cairo too?
Tim points out that at some point between cairo 1.0.2 and 1.2.4 cairo's gradient API was changed. To get "pad" behavior in the former you had to use CAIRO_EXTEND_NONE.
Later CAIRO_EXTEND_PAD was added and the meaning of CAIRO_EXTEND_NONE was changed to "pixels outside of the source pattern are fully transparent".
(In reply to comment #9)
> Tim points out that at some point between cairo 1.0.2 and 1.2.4 cairo's
> gradient API was changed. To get "pad" behavior in the former you had to use
> Later CAIRO_EXTEND_PAD was added and the meaning of CAIRO_EXTEND_NONE was
> changed to "pixels outside of the source pattern are fully transparent".
Yes, that's fairly accurate.
What didn't change is that the default extend mode for gradients has always been a "pad" behavior, (even though we did not have the PAD enum value in 1.0).
And we hoped that not many people would be bitten by making NONE actually live up to its name in 1.2 since in 1.0 there's no real benefit to explicitly calling cairo_pattern_set_extend (gradient_pattern, CAIRO_EXTEND_NONE) --- that call doesn't actually change anything.
So, writing code to get compatible PAD behavior should be as simple as not calling cairo_pattern_set_extend at all, (or, if you really want to call it for some reason, then yes it will require a version check and using NONE for 1.0 but PAD for 1.2 and on).
Sorry for this little gotcha in the cairo API. I hope you will find that there really aren't a lot of these as far as backwards compatibility is concerned.
I reopen the bug for now, as imo we should definitly try to get something that works across cairo versions. And comments from Carl sound like this should be doable with little or no tradeoff.
Yup, cool. Should be as simple as removing the two lines at:
I'll attach a patch later today. Would you be able to test it asac?
i already have the patch here ... testing.
Created attachment 257027 [details] [diff] [review]
patch with comment
Created attachment 257028 [details] [diff] [review]
patch without comment (candidate)
for me it indeed fixes this issue.
... have not yet tried with 1.0 cairo though.
Alexander, were you going to test 1.0?
*** Bug 375849 has been marked as a duplicate of this bug. ***
*** Bug 375659 has been marked as a duplicate of this bug. ***
I've applied the patch 257028 into FF 126.96.36.199 (my cairo version is 1.2.6) and now SVG images are finally rendereder fine. Good job guys =)
Jonathan, renders correctly with patch applied and built against 1.0 system cairo here. Who can review svg?
Johnathan can, and tor can SR...
Created attachment 260571 [details] [diff] [review]
(In reply to comment #24)
> Created an attachment (id=260571) [details]
From a cairo point-of-view, the patch and the description look good to me.
Thanks for looking Carl.
Comment on attachment 260571 [details] [diff] [review]
approved for 188.8.131.52, a=dveditz for release-drivers
Checking in mozilla/layout/svg/renderer/src/cairo/nsSVGCairoGradient.cpp;
/cvsroot/mozilla/layout/svg/renderer/src/cairo/Attic/nsSVGCairoGradient.cpp,v <-- nsSVGCairoGradient.cpp
new revision: 184.108.40.206; previous revision: 220.127.116.11