SVG Color 1.2, Part 1: Primer
W3C Working Draft 01 October 2009
Copyright © 2004-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Copyright © 2004-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This Working Draft is a primer for use of the Scalable Vector Graphics (SVG) Language for color managed workflows. It explains the technical background and gives guidelines on how to use the SVG Color specification with SVG 1.2 Tiny and SVG 1.2 Full modules. It is purely informative and has no conformance statements.
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 a First Public Working 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 printing and should not yet be considered stable. There is an accompanying SVG Color 1.2, Part 2: Language that lists the ways SVG Color 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 these lists send an email to public-svg-print-request@w3.org or 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.
The main purpose of this document is to encourage public feedback. The best way to give feedback is by sending an email to public-svg-print@w3.org. Please identify in the subject line of your message the part of the specificationto which your comment refers (e.g "Print compositing" or "Print render formats"). 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 like this.
Because of its scalable, geometric nature, SVG is inherently suited to both print and screen output. The same colors can be output, using an ICC-based color managed workflow on the printer and an sRGB fallback approximation on screen. This has been true since SVG 1.0, and so SVG has been used in print workflows (for example, in combination with XSL FO) as well as on screen.
It is common in cross-media publishing to design content which will be used both online and in print media. This specification gives guidance on how to create such content and how to indicate that it has been adapted to improve its color capability.
SVG Color allows color to be specified in a number of ways. All of the sRGB color syntaxes from SVG Print 1.2 are supported. The ICC-based color syntax from SVG 1.1 Full is also supported, and unlike SVG 1.1 rendering this feature is not optional. New to the SVG Color specification, ICC named colors and device colors are supported as well: their syntax is defined below.
As with SVG Tiny 1.2, colors may be specified in the sRGB colorspace without providing a color profile. This color space, which uuses the chromaticities of a standard TV broadcast monitor and viewing conditions typical of an office environment, has a reduced gamut suitable for minimising banding on 'real world' colors at the expense of being unable to directly represent highly saturated colors. A number of equivalent syntactic forms are supported, as defined in SVG Tiny 1.2:
<circle cx="200" cy="135" r="20" fill="#3b3"/> <circle cx="240" cy="135" r="20" fill="#33bb33"/> <circle cx="200" cy="175" r="20" fill="rgb(51,187,51)"/> <circle cx="240" cy="175" r="20" fill="rgb(20%,73.333%,20%)"/>
Since SVG 1.0, SVG has contained functionality for use of ICC color profiles which define colors in a different color space than sRGB. This functionality has been available since SVG 1.0 but for the most part has not been well understood. SVP Print tightens the conformance criteria for using ICC colors.
For example, it is possible to specify all objects in terms of an ICC color space such as SWOP CMYK and the SVG renderer perform all rendering of the objects entirely in the SWOP CMYK space followed by color correction for a printer target CMYK. This render workflow would never require conversion into and out of sRGB.
In the case where opacity is used and objects overlap a render device must use the supplied sRGB fallback color in order to composite objects together.
The implication of this is that it is possible to use a fully colormanaged workflow (using SVG 1.0 onwards) that supports a full CMYK pipeline via the use of ICC profiles. Such an SVG render device must also be capable of handling a switch into the fallback render color space (sRGB) for the overlapping portions of objects with transparency.
An implementation may determine the areas of an object to render in object's ICC color and those areas to render in its sRGB fallback by doing object intersection calculations as a pre-render step. An implementation could alternatviely decide render color choice on a pixel by pixel basis during rasterisation. Such behaviour is implementation specific and can lead to varying rendering results from different implementations at the borders of overlapping areas when using ICC colors.
SVG Color introduces the ability to use so-called 'named' or 'spot' colors. Named colors are used in many print applications and are supported in SVG Print through the use of ICC named color profiles. For color managed displays, the desired color may be accurately simulated. Non color managed user agents will use the sRGB fallback value.
The paint specifiers for fill and stroke include the icc-named-color keyword. This may be used to look up colors by their name. For example in graphic arts workflows it is common to use Pantone® color names for specifying paint on objects. The icc-named-color keyword may be used for such workflows.
An SVG 1.2 file may specify ICC named color profiles via use of the color-profile element.
The ICC specification indicates that named color profiles must contain a PCS (Profile Connection Space) representation and can optionally contain a device representation for each named color. An implementation may support device representations of ICC named colors, however that support is device specific and should be managed outside of the SVG file itself by use of some form of job ticket information.
<svg width="210mm" height="297mm"
xmlns="http://www.w3.org/2000/svg" version="1.2" referenceDirection="backwards">
<pageSet>
<page>
<color-profile name="MyColors"
xlink:href="CompanyColors.icm"/>
<text x="50mm" y="85mm"
font-family="MyCompanyLogoFont" font-size="12"
color="rgb(255,12,13) icc-named-color(MyColors, logo_color)">
MyCompany logo.
</text>
</page>
</pageSet>
</svg>
SVG Color allows any visible color to be directly specified in the standard, device-independent CIE L*ab color space. Both the cartestian (L*ab) and polar (L*CHab) forms are supported. The latter has the advantage that chroma and hue are more intuitive to specify than the abstract a and b axes.
Occasionally, it is necessary to specify non-colormanaged colors in terms of the eventual device colorants. An example would be the creation of registration marks, or tint bars of pure ink for quality control purposes.