Bug 5972

This is a pretty basic feature of SVG. I think it would be a mistake to ship an SVG viewer w/o this feature, but I don't see it as a truely blocking bug. Adding to the SVG HitList for now and marking as P3. Supporting this would require adding colorspace infrastructure so that colors would be created in the proper colorspace instead of Device/Generic RGB like they are now.

leaving as p3 but removing svghitlist keyword after discussion with macdome

Created attachment 9086 [details] compare CSS, image and SVG colors An argument can be made against fixing this. 1) HTML and pictures are not drawn color matched unless a profile is specified, and we probably want to have matching color in compound documents (see the test case, which currently passes). 2) sRGB is the lowest common denominator, so enabling it as a default will suddenly make colors look dull. 3) Color matching often introduces dithering, which may be undesirable (and when it doesn't, it introduces banding on gradients).

Created attachment 9087 [details] effects of color matching The nice gradient above is drawn using SVG. The second one is a JPEG with an embedded profile - the colors are dull, and banding is visible (even with the dithering performed by CoreGraphics). Firefox 1.5 doesn't support embedded profiles, so both gradients look the same there.

> 2) sRGB is the lowest common denominator, so enabling it as a default will > suddenly make colors look dull. Whether colours look more dull will depend on the gamut of the viewers monitor - it will make colours look more dull on a monitor with a larger gamut than sRGB, but more vibrant on a monitor with a smaller gamut than sRGB. What it will do is make the colours look correct. This obviously doesn't invalidate the other two very good points

(In reply to comment #5) > - it will make colours look more dull on a monitor with a larger gamut than > sRGB, but more vibrant on a monitor with a smaller gamut than sRGB. I used to be under an impression that all modern monitors have a gamut that's much larger than sRGB (and mobile devices that are likely to have poorer screens don't have system support for color management anyway). I'll be the first to admit that I have never really investigated this, though.

(In reply to comment #6) > (In reply to comment #5) > > - it will make colours look more dull on a monitor with a larger gamut than > > sRGB, but more vibrant on a monitor with a smaller gamut than sRGB. > > I used to be under an impression that all modern monitors have a gamut that's > much larger than sRGB (and mobile devices that are likely to have poorer > screens don't have system support for color management anyway). I'll be the > first to admit that I have never really investigated this, though. > Well my iBook monitor has a gamut smaller than sRGB according to ColorSync Utility (after being calibrated with a Spyder). I am probably in the minority though I suppose.

Color gamut of a LED-backlit display vs. sRGB: <http://www.fcenter.ru/img/article/monitors/lcd_2/96026.png>. Would be nice to know the rationale for requiring sRGB by default - it seems extremely arbitrary and limiting to me.

sRGB is just the default colorspace for SVG colors. The current behavior is to use whatever the device color space is (thus no color matching) which means that your bitmap image and SVG colors don't look the same. If we were actually to support this, you could change the default profile using @color-profile or <color-profile>. See http://www.w3.org/TR/SVG/color.html

(In reply to comment #9) > sRGB is just the default colorspace for SVG colors. Yes - I'm questioning why it was chosen for the spec, not the validity of this bug. > If we were actually to support this, you could change the default profile using > @color-profile or <color-profile>. See http://www.w3.org/TR/SVG/color.html The problem is that there is no "device RGB" option to request the current (no matching) behavior then, and such behavior is desirable in some cases.

Well, at least it's consistent with CSS3: http://www.w3.org/TR/css3-color/#color-profile There are a couple possibilities here. We could invent a "none" or "device" to mean the current behavior. Or (more likely) we could keep the current behavior (since no browser color matches, period) and only make @color-profile opt-in.

Ok, either this big goes fixed somehow, or we have a regression. Anyway, there is no difference between the rects. Can we exclude that the color profile for images (or what ever) is not working?

The test case passes on Mountain Lion and newer. If there are any remaining issues, let's track them in separate bugs.