485497 - We should use the fallback specified before icc-color()

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

Attachment: testcase for fallback with uri()

We should support paint fallback. Currently if the user does:

  <rect width="100%" height="100%" fill="uri(#not-there) #0f0"/>

or:

  <rect width="100%" height="100%" fill="#0f0 icc-color(not-there, 0.1, 0.2, 0.3)"/>

then we reject the 'fill' attribute and paint black rects. This is especially annoying for people that want to use ICC color profiles for implementations that support them such as Opera, but can't because they will look completely broken in Firefox rather than using the fallback color. For info on <paint> see:

http://www.w3.org/TR/SVG11/painting.html#SpecifyingPaint

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: testcase for fallback with icc-color()

Comment 2

[Robert Longson [:longsonr]]

Fallback colours were implemented in bug 368840. I even did reftests.

Comment 3

[Robert Longson [:longsonr]]

Hmm, that's not the right bug for the original code.

Comment 4

[Jonathan Watt [:jwatt]]

So what's up with the two attached tests?

Comment 5

[Robert Longson [:longsonr]]

For the first one the style system doesn't identify the fill type as a paint server.

Comment 6

[Robert Longson [:longsonr]]

The second one is invalid CSS so the style system drops it altogether (check out the error console). I don't think your second test is valid and your first is CORE->Style System(CSS) rather than CORE->SVG.

Comment 7

[Jonathan Watt [:jwatt]]

Comment on attachment 369645 [details]
testcase for fallback with uri()

Actually the first test is invalid - it should be url(), not uri().

Comment 8

[Robert Longson [:longsonr]]

Ahh, I thought uri might be something new.

As to the second one, you can't fallback from a colour, only a url. But since not-there is invalid you lose the whole fill attribute.

Comment 9

[Robert Longson [:longsonr]]

I think this bug is invalid then.

Comment 10

[chris]

Robert, why do you say the syntax is 'invalid CSS'? Its the SVG 1.1 syntax for fill, not anything new or experimental:
http://www.w3.org/TR/SVG11/painting.html#SpecifyingPaint

<color>  [icc-color(<name>[,<icccolorvalue>]*)]

Comment 11

[Robert Longson [:longsonr]]

I stand corrected. This is a CSS issue though not an SVG issue.

Comment 12

[Jonathan Watt [:jwatt]]

The fact that we defer parsing of the values of the 'fill' attribute to the style system is just an implementation detail. It's SVG that defines what the value of 'fill' is -- it's actually <paint>, not <color> -- and <paint> is defined only in SVG, not in CSS. Also, the only mechanisms for handling ICC profiles in CSS seem to have been dropped for now:

http://www.w3.org/TR/2008/WD-css3-color-20080721/#dropped

Of course you're right that we want to handle this in the style system, and preferably without ugly hacks to detect when the <color> is actually from SVG, and is therefore really <paint>. Ugh.

Chris, what's the utility of allowing authors to specify a profile per-color, rather than per-file? The ‘@color-profile’ at-rule mentioned above would seem to better address the common use case, no? Also, how would you compare and contrast the mechanism in <paint> to the ‘color-profile’ property?

Comment 13

[Jonathan Watt [:jwatt]]

The ‘@color-profile’ at-rule and the ‘color-profile’ property can be found via the link in my previous comment. Sorry, that wasn't very clear.

Comment 14

[Robert Longson [:longsonr]]

This bug is morphing into icc-color not implemented rather than paint fallback. I suggest either a change of title or starting again.

Comment 15

[Jonathan Watt [:jwatt]]

Well, it's still about using the fallback specified before icc-color() to work, not about implementing icc-color() itself, but updating the title isn't a bad idea.

Comment 16

[Robert Longson [:longsonr]]

I'm confused again then.

Firstly you can't fallback from a <color> or even an invalid icc colour only a <uri> so

<rect width="100%" height="100%" fill="#0f0 icc-color(not-there, 0.1, 0.2,
0.3)"/>

is invalid.

And the reason that fill="url(#not-there) icc-color(not-there2, 0.1, 0.2,
0.3)"

wouldn't work is that the style system would throw out the entire line as invalid when it can't parse the icc-color. If it parsed then fallback would work.

Comment 17

[Jonathan Watt [:jwatt]]

So one of the possible constructs for <paint> is:

  <color>  [icc-color(<name>[,<icccolorvalue>]*)]

so :

  <rect width="100%" height="100%" fill="#0f0 icc-color(not-there, 0.1, 0.2,
0.3)"/>

would seem to be valid to me. Also, the accompanying text for this construct is:

------------------
    <color> is the explicit color (in the sRGB [SRGB] color space) to be used to paint the current object. SVG supports all of the syntax alternatives for <color> defined in [ CSS2-color-types], with the exception that SVG contains an expanded list of recognized color keywords names. If an optional ICC color specification is provided, then the user agent searches the color profile description database for a color profile description entry whose name descriptor matches <name> and uses the last matching entry that is found. (If no match is found, then the ICC color specification is ignored.) The comma-separated list (with optional white space) of <icccolorvalue>'s is a set of ICC-profile-specific color values, expressed as <number>s. (In most cases, the <icccolorvalue>'s will be in the range 0-to-1.) On platforms which support ICC-based color management, the icc-color gets precedence over the <color> (which is in the sRGB color space). Note that color interpolation occurs in an RGB color space even if an ICC-based color specification is provided (see 'color-interpolation' and 'color-interpolation-filters'). Percentages are not allowed on <icccolorvalue>'s. For more on ICC-based colors, refer to Color profile descriptions.
---------------

The important sentence here seems to be "On platforms which support ICC-based color management, the icc-color gets precedence over the <color> (which is in the sRGB color space)." So on platform such as Mozilla that don't support icc-color, then <color> is used. In other words, we would "fall back" to <color>. At least that's my current take on what the spec says.

Comment 18

[Robert Longson [:longsonr]]

OK, I see now.

Comment 19

[chris]

Yes, this bug is about "implementing the fallback to icc colour in SVG paint". 

The fallback is specifically there so that user agents which don't implement icc colour have a fallback to render with rather than dropping the entire attribute value. Breakage here puts people off using the feature.

Although, once that is done, given the ICC profile support already in Firefox 3.1 beta and later, actually rendering the specified icc colour would be a logical next step (perhaps selectable by a preference and off by default, to allow testing).

Comment 20

[Robert Longson [:longsonr]]

Looks like icc-color was dropped from SVG 2 and is not in https://www.w3.org/TR/css-color-3/