This Working Draft defines features of the Scalable Vector Graphics (SVG) Language that are specifically for color-managed environments.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is an editors draft. It defines features of SVG specific to color management. It is a draft in progress; some descriptions in this document may be incomplete. This document shows the current thoughts of the SVG Working Group on the use of SVG for color managed environments and should not yet be considered stable. There is an accompanying SVG Color 1.2, Part 1: Primer that lists the ways SVG Color, along with other SVG documents, may be used.
This document has been produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain. The Working Group expects to advance this Working Draft to Recommendation Status.
We explicitly invite comments on this specification. Please send them to www-svg@w3.org (archives). Acceptance of the archiving policy is requested automatically upon first post to either list. To subscribe to this list send an email to www-svg-request@w3.org with the word subscribe in the subject line.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This draft of SVG Color is a snapshot of a work-in-progress.
The main purpose of this document is to encourage public feedback. The best way to give feedback is by sending an email to www-svg@w3.org (archive) . Please identify in the subject line of your message the part of the specification to which your comment refers. If you have comments on multiple areas of this document, then it is preferable to send several separate comments.
The public are welcome to comment on any aspect in this document, but there are a few areas in which the SVG Working Group are explicitly requesting feedback. These areas are noted in place within this document.
This document lists features that may be used with SVG in color-managed environments, including document interchange, publishing, and high-quality display. SVG Color extends the control of color, relative to SVG 1.1, in three ways. Firstly, the use of ICC color definitions and the respect of color managed embedded images ( both optional in SVG 1.1)are given explicit conformance criteria for user agents and for content. Secondly, by adding additional color spaces for interpolation and compositing; this means that colors are no longer constrained to the sRGB gamut during processing. Thirdly by extending the syntax for Paint, thus allowing colors to be specified as hsl/hsla/rgba values (from CSS3 Color), calibrated (ICC and named) and uncalibrated ('device') color.
This document contains explicit conformance criteria that may overlap with the EBNF or RNG definitions. If there is any conflict between these, the explicit conformance criteria in the prose of this specification are the definitive reference.
This document contains conformance criteria for two classes of product:
SVG color is an addition to a base profile of the SVG language. A user agent therefore conforms to at least one base profile (e.g. SVG 1.1 or SVG Tiny 1.2 ) and also to this specification.
A Color-managed User Agent MUST support both ICC v.2 and ICC v.4 color profiles.
Implementations of SVG Color are required to color-manage all images. The embedded profile is used (if there is no embedded profile, sRGB is assumed, for RGB images).
If a referenced image contains color profile information, a Color-managed User Agent MUST use that profile to render the image .
If a referenced image contains no color profile information, a Color-managed User Agent MUST use the sRGB profile to render the image .
Example:
<circle fill="rgb(205,133,63)"/>
<circle fill="peru"/>
<circle fill="rgb(80.392%, 52.157%, 24.706%)"/>
<circle fill="#CD853F"/>
Note: Same syntax as SVG 1.1, extended color keyword list compared to SVG Tiny 1.2
As with SVG 1.1 and SVG Tiny 1.2, colors may be specified in the sRGB color space (see [sRGB]). Five syntactical forms are specified for SVG Color, and all of them must be supported in a conforming Color-managed User Agent:
All the SVG 1.1 syntactic forms for an sRGB color, including the full set of color keywords, shall be supported by a Color-managed User Agent, regardless of the base language profile of SVG.
Since all Color-managed User Agent are color management capable, the rendering requirements for sRGB colors are more strict than for SVG 1.1 or SVG Tiny 1.2 User Agents, where color management is optional.
When an sRGB color is used - because it is the sole color specification, or in a permitted fallback situation - a conformant Color-managed User Agent shall render it in conformance with the ICC profile for sRGB to obtain the desired color appearance.
<fallback> icc-color(<name> [,<icccolorvalue>]*)
Example:
<color-profile name="acmecmyk" xlink:href="http://printers.example.com/acmecorp/model1234"/>
<circle fill="#CD853F icc-color(acmecmyk, 0.11, 0.48, 0.83, 0.00)"/>
Note: same syntax as SVG 1.1.
SVG Color uses the extended ICC color specification from SVG 1.1. In SVG Tiny 1.2, this was not supported; an SVG Tiny 1.2 user agent which also conforms to this specification is required to support it. In SVG 1.1, parsing the syntax was required but implementing the ICC colour itself was optional, as indicated by phrases such as "If ICC-based colors are provided and the SVG user agent supports ICC color, then...". An SVG 1.1 user agent which also conforms to this specification "supports ICC color" for the purposes of conforming to SVG 1.1.
As with SVG Full 1.1, SVG Color content may specify color using an ICC profile (see [ICC42]); an sRGB fallback must still be provided.
A Color-managed 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; painting shall be done using the given ICC color, where the comma-separated list (with optional white space) of <icccolorvalue>'s is a set of ICC-profile-specific color values, expressed as <number>s (see ICC colors). If no match is found, then the fallback sRGB color is used.
If ICC-based colors are provided, a Color-managed User Agent MUST use the the ICC-based color in preference to the sRGB fallback color, unless the ICC color profile cannot be used (is unavailable, malformed, or uses an unsupported profile connection space).
When rendering, if both ICC and sRGB fallback colors are provided and the referenced ICC profile ican be used, a Color-managed User Agent MUST render using the ICC color values, and using the specified ICC profile as the input profile.
<fallback>
cielab(<Lightness>, <a> <b> <WP>?) |
<fallback>
cielchab(<Lightness> <Chroma>, <Hue> <WP>?)
Example:
<circle fill="#CD853F cielab(62.253188, 23.950124, 48.410653)"/>
<circle fill="#CD853F cielch(62.253188, 54.011108, 63.677091)"/>
<circle fill="#CD853F cielab(62.253188, 23.950124, 48.410653, D65)"/>
Note: new in this specification.
A Color-managed User Agent directly uses the CIE LAB or CIE LCHab values, where the comma-separated list (with optional white space) of <icccolorvalue>'s is a set of Lightness, a and b or Lightness, Hue and Chroma values, expressed as <number>s.
An optional white point may be specified, of the form Dnn. This corresponds to the whitepoint of a daylight source of nn00 Kelvin (for example, D65 is 6500 Kelvin). If not specified, the lacuna value is D50 which is the whitepoint defined by the CIE for CIELab profile connection space.
A fallback sRGB color must still be provided, for non-colormanaged user agents.
<fallback> icc-named-color(<name>, <namedColor>)
Example:
<color-profile name="FooColors" xlink:href="http://swatches.example.com/Foo"/>
<circle fill="#CD853F icc-color(FooColors, Sandy23C"/>
Note: new in this specification.
SVG Color introduces the ability to specify a color using a 'Named Color Profile'.
A Color-managed 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; painting shall be done using the given ICC color, where namedColor is a <string> indicating the named color to use.
If ICC-based named colors are provided, a conformant Color-managed User Agent MUST use the the ICC-based named color in preference to the sRGB fallback color, unless the ICC named color profile is unavailable, malformed, or uses a profile connection space other than CIE XYZ or CIE LAB.
When an ICC named color is used, a conformant Color-managed User Agent shall render it in conformance with the specified ICC profile to obtain the desired color appearance.
<fallback>
device-gray(<gray>) |
<fallback>
device-rgb(<red> <green> <blue>) |
<fallback>
device-cmyk(<cyan> <magenta> <yellow>
<black>) |
<fallback>
device-nchannel(<number>+) |
Note: new in this specification.
Example:
<circle fill="#CD853F device-cmyk(0.11, 0.48, 0.83, 0.00)"/>
SVG Color also introduces a method of specifying uncalibrated device colors. This is sometimes useful in print workflows, for example to produce patches of known ink density used for quality control purposes.
A Color-managed User Agent which supports the indicated class of output device will pass the values through without color management. If the class of output device (for example, cmyk) is not supported, then the fallback sRGB color is used.
As these are uncalibrated, any interpolation or compositing occurs using the fallback sRGB color value.
Completely different syntax in this version of the specification, responding to feedback from previous last call and aligning with industry practice.
The definition of paint in SVG Tiny 1.2 [SVGT12] is extended by this specification to add the icc-color values from paint in SVG Full 1.1 [SVG11] and also to add new values for named colors, CIELAB colors, and uncalibrated device colors.
| <paint> : |
none | currentColor | <color> | fallback <icccolor> | fallback <cielabcolor> | fallback <iccnamedcolor> | fallback <devicecolor> | <FuncIRI> [ none | currentColor | <color>] | <system paint> | inherit |
Note that by default, color interpolation occurs in the sRGB color space, even if an ICC-based color specification is provided, unless the 'color-interpolation' property is set to one of the CIE Lab color spaces. If an sRGB color interpolation space is specified, all ICC-based colors used for the interpolation must be converted into the sRGB interpolation colorspace.
The solidColor element in SVG Tiny 1.2 [SVGT12] is extended by this specification to add the icc-color values from paint in SVG Full 1.1 [SVG11] and also to add new values for named colors, CIELAB colors, and uncalibrated device colors.
| Value: |
currentColor | <color> | fallback <icccolor> | fallback <cielabcolor> | fallback <iccnamedcolor> | fallback <devicecolor> | <system paint> | inherit |
| Initial: | black |
| Applies to: | 'solidColor' elements |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Animatable: | yes |
| Computed value: | Specified <color> value, except inherit |
The viewportFill element in SVG Tiny 1.2 [SVGT12] is extended by this specification to add the icc-color values from paint in SVG Full 1.1 [SVG11] and also to add new values for named colors, CIELAB colors, and uncalibrated device colors.
| Value: |
none | currentColor | <color> | fallback <icccolor> | fallback <cielabcolor> | fallback <iccnamedcolor> | fallback <devicecolor> | <system paint> | inherit |
| Initial: | none |
| Applies to: | viewport-creating elements |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Animatable: | yes |
| Computed value: | "none" or specified <color> value, except inherit |
The gradients in SVG Tiny 1.2 [SVGT12] are extended by this specification. The 'stop-color' property s extended by this specification to add the icc-color values from paint in SVG Full 1.1 [SVG11] and also to add new values for named colors, CIELAB colors, and uncalibrated device colors. The color-interpolation property is extended by this specification to add new values using the CIE L*a*b* color space.
The 'stop-color' property indicates what color to use at that gradient stop. The keyword currentColor and ICC colors can be specified in the same manner as within a <paint>. This is the same syntax as is used in SVG 1.1; the conformance criteria are however more stringent as color management is no longer optional.
| Value: |
currentColor | <color> | fallback <icccolor> | fallback <cielabcolor> | fallback <iccnamedcolor> | fallback <devicecolor> | <system paint> | inherit |
| Initial: | black |
| Applies to: | 'stop' elements |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Animatable: | yes |
If any stop-color uses a cmyk color space and stop-opacity is set to any value other than fully opaque, the result is undefined by this specification. Even for f ully opaque gradients, the result of interpolating cmyk colors may be unexpected. In general, the use of cmyk (either calibrated or uncalibrated) in gradients is discouraged.
The color-interpolation property, not in SVG Tiny 1.2 but used in SVG 1.1 [SVG11], is extended by this specification to add new values using the CIE L*a*b* color space. Both the cartesian (CIE-Lab) and polar (CIE-LCHab) forms are supported.
A Color-managed User Agent MUST use the color space defined by color-interpolation for calculations when interpolating between gradient stops, and when alpha compositing of graphics elements into the current background.
| Value: | auto | sRGB | linearRGB | CIE-Lab | CIE-LCHab | inherit |
| Initial: | sRGB |
| Applies to: | container elements, graphics elements and 'animateColor' |
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
| Animatable: | yes |
The 'color-interpolation' property specifies the color space for gradient interpolations and alpha compositing.
When a child element is blended into a background, the value of the 'color-interpolation' property on the child determines the type of blending, not the value of the 'color-interpolation' on the parent. For gradients which make use of the xlink:href attribute to reference another gradient, the gradient uses the 'color-interpolation' property value from the gradient element which is directly referenced by the 'fill' or 'stroke' property. When animating colors, color interpolation is performed according to the value of the 'color-interpolation' property on the element being animated.
The International Color Consortium has established a standard, the ICC Profile [ICC32], for documenting the color characteristics of input and output devices. Using these profiles, it is possible to build a transform and correct visual data for viewing on different devices.
A color profile description provides the bridge between an ICC profile and references to that ICC profile within SVG content. The color profile description is added to the user agent's list of known color profiles and then used to select the relevant profile. The color profile description contains descriptors for the location of the color profile on the Web, a name to reference the profile and information about rendering intent.
Attribute definitions:
'rendering-intent' permits the specification of a color profile rendering intent other than the default. 'rendering-intent' is applicable primarily to color profiles corresponding to CMYK color spaces. The different options cause different methods to be used for translating colors to the color gamut of the target rendering device:
This method is often the preferred choice for images, especially when there are substantial differences between the source and destination (such as a CRT display image reproduced on a reflection print). It takes the colors of the source image and re-optimizes the appearance for the destination medium using proprietary methods. This re-optimization may result in colors within both the source and destination gamuts being changed, although perceptual transforms are supposed to maintain the basic artistic intent of the original in the reproduction. They will not attempt to correct errors in the source image.
NOTE With v2 ICC profiles there is no specified perceptual reference medium, which can cause interoperability problems. When v2 ICC profiles are used it may be safer to use the media-relative colorimetric rendering intent with black point compensation, instead of the perceptual rendering intent, unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result.
This option was created to preserve the relative saturation (chroma) of the original, and to keep solid colors pure. However, it experienced interoperability problems like the perceptual intent, and as solid color preservation is not amenable to a reference medium solution using v4 profiles does not solve the problem. Use of this rendering intent is not recommended unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result.
Media-relative colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the respective media white points. Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods.
NOTE The media-relative colorimetric rendering intent is often used with black point compensation, where the source medium black point is mapped to the destination medium black point as well.
ICC-absolute colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the adopted white (a perfect reflecting diffuser). Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods. This method produces the most accurate color matching of in-gamut colors, but will result in highlight clipping if the destination medium white point is lower than the source medium white point. For this reason it is recommended for use only in applications that need exact color matching and where highlight clipping is not a concern.
Animatable: no.
Fallback behaviour needs to be specified, for when the requested rendering intent does not have a corresponding table in the profile; or when all rendering-intents are provided using the same table.
The EBNF grammar is as used in the XML specification, with the addition of a case-insensitive literal: characters in the ASCII range (only) are case-insensitive. ~"Hello" will match (H|h)(e|e)(l|L)(l|L)(o|O). This makes the productions much easier to read.
| ? | optional, zero or one |
| + | one or more |
| * | zero or more |
| | | alternation |
| "string" | literal |
| ~"string" | case-insensitive literal |
| [] | a character range |
| [^] | excluded character range |
| () | grouping |
icccolor ::=
~"icc-color(" name (comma-wsp number)+ ")"
iccnamedcolor ::=
~"icc-named-color(" name comma-wsp namedColor ")"
cielabcolor ::=
~"cielab(" lightness comma-wsp a-value comma-wsp b-value WP? ")"
cielchabcolor ::=
~"cielchab(" lightness comma-wsp chroma comma-wsp hue WP? ")"
devicecolor ::=
device-gray | devicergb | devicecmyk | devicenchannel
devicegray ::=
~"device-gray(" gray ")"
devicergb ::=
~"device-rgb(" red green blue ")"
devicecmyk ::=
~"device-cmyk(" cyan magenta yellow >black ")"
devicenchannel ::=
~"device-nchannel(" number+ ")"
name ::=
namestartchar (namechar)*
lightness ::=
number
a-value ::=
number
b-value ::=
number
chroma ::=
number
hue ::=
number
WP ::=
comma-wsp "D" [0-9] [0-9]
gray ::=
number
red ::=
number
green ::=
number
blue ::=
number
cyan ::=
number
magenta ::=
number
yellow ::=
number
black ::=
number
namedColor ::=
name
fallback ::=
color
color ::=
"#" hexdigit hexdigit hexdigit (hexdigit hexdigit hexdigit)?
| ~"rgb(" wsp* integer comma integer comma integer wsp* ")"
| ~"rgb(" wsp* integer "%" comma integer "%" comma integer "%" wsp* ")"
| color-keyword
hexdigit ::=
[0-9A-Fa-f]
number ::=
sign? digit-sequence? "." digit-sequence
sign::=
"+" | "-"
integer ::=
digit-sequence
digit-sequence ::=
[0-9]+
namestartchar ::=
":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [
#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] |
[#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] |
[#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
namechar ::=
namestartchar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] |
[#x203F-#x2040]
comma-wsp ::=
(wsp+ comma? wsp*) | (comma wsp*)
comma ::=
","
wsp ::=
(#x20 | #x9 | #xD | #xA)
color-keyword ::=
~"aliceblue" | ~"antiquewhite" | ~"aqua" | ~"aquamarine" | ~"azure" | ~"beige" |
~"bisque" | ~"black" | ~"blanchedalmond" | ~"blue" | ~"blueviolet" | ~"brown" |
~"burlywood" |~"cadetblue" | ~"chartreuse" | ~"chocolate" | ~"coral" | ~"cornflowerblue" |
~"cornsilk" | ~"crimson" | ~"cyan" | ~"darkblue" | ~"darkcyan" | ~"darkgoldenrod" |
~"darkgray" | ~"darkgreen" | ~"darkgrey" | ~"darkkhaki" | ~"darkmagenta" | ~"darkolivegreen" |
~"darkorange" | ~"darkorchid" | ~"darkred" | ~"darksalmon" | ~"darkseagreen" | ~"darkslateblue" |
~"darkslategray" | ~"darkslategrey" | ~"darkturquoise" | ~"darkviolet" | ~"deeppink" | ~"deepskyblue" |
~"dimgray" | ~"dimgrey" | ~"dodgerblue" | ~"firebrick" | ~"floralwhite" | ~"forestgreen" |
~"fuchsia" | ~"gainsboro" | ~"ghostwhite" | ~"gold" | ~"goldenrod" | ~"gray" |
~"grey" | ~"green" | ~"greenyellow" | ~"honeydew" | ~"hotpink" | ~"indianred" |
~"indigo" | ~"ivory" | ~"khaki" | ~"lavender" | ~"lavenderblush" | ~"lawngreen" |
~"lemonchiffon" | ~"lightblue" | ~"lightcoral" | ~"lightcyan" | ~"lightgoldenrodyellow" | ~"lightgray" |
~"lightgreen" | ~"lightgrey" | ~"lightpink" | ~"lightsalmon" | ~"lightseagreen" | ~"lightskyblue" |
~"lightslategray" | ~"lightslategrey" | ~"lightsteelblue" | ~"lightyellow" | ~"lime" |
~"limegreen" | ~"linen" | ~"magenta" | ~"maroon" | ~"mediumaquamarine" | ~"mediumblue" |
~"mediumorchid" | ~"mediumpurple" | ~"mediumseagreen" | ~"mediumslateblue" | ~"mediumspringgreen" | ~"mediumturquoise" |
~"mediumvioletred" | ~"midnightblue" | ~"mintcream" | ~"mistyrose" | ~"moccasin" | ~"navajowhite" |
~"navy" | ~"oldlace" | ~"olive" | ~"olivedrab" | ~"orange" | ~"orangered" |
~"orchid" | ~"palegoldenrod" | ~"palegreen" | ~"paleturquoise" | ~"palevioletred" | ~"papayawhip" |
~"peachpuff" | ~"peru" | ~"pink" | ~"plum" | ~"powderblue" | ~"purple" |
~"red" | ~"rosybrown" | ~"royalblue" | ~"saddlebrown" | ~"salmon" | ~"sandybrown" |
~"seagreen" | ~"seashell" | ~"sienna" | ~"silver" | ~"skyblue" | ~"slateblue" |
~"slategray" | ~"slategrey" | ~"snow" | ~"springgreen" | ~"steelblue" | ~"tan" |
~"teal" | ~"thistle" | ~"tomato" | ~"turquoise" | ~"violet" | ~"wheat" |
~"white" | ~"whitesmoke" | ~"yellow" | ~"yellowgreen"
The following changes ave been made, relative to the First Public Working Draft: