It is important that Inkscape implement these features in a timely fashion. Not only will it be a benefit to our users... but it is a necessary step to insuring that these features remain in SVG 2. The W3C specification process requires at least two independent implementations of feature before final publication. Having Inkscape support these features not only will provide one of the implementations but it demonstrates to others that there is serious interest in these features.

+

It is important that Inkscape implements these features in a timely fashion. Not only will it be a benefit to our users... but it is a necessary step to insuring that these features remain in SVG 2. The W3C specification process requires at least two independent implementations of feature before final publication. Having Inkscape support these features not only will provide one of the implementations but it demonstrates to others that there is serious interest in these features.

−

We do need to be careful, though, to avoid the '''Flowed Text''' of SVG 1.2 debacle. Until the SVG 2 specification (or relevevant CSS specification) is in the final stages of adoption, each new feature must be developed in the 'inkscape' name space; that is to say, the '-inkscape-' prefix must be used for new elements, attributes, and properties. It is also important that, until SVG 2 is widely supported, we support export to SVG 1.1 or clearly mark that a feature is supported only by SVG 2.

+

We do need to be careful, though, to avoid the '''Flowed Text''' of SVG 1.2 debacle. Until the SVG 2 specification (or relevant CSS specification) is in the final stages of adoption, each new feature must be developed in the 'inkscape' name space; that is to say, the '-inkscape-' prefix must be used for new elements, attributes, and properties. It is also important that, until SVG 2 is widely supported, we support export to SVG 1.1 or clearly mark that a feature is supported only by SVG 2.

−

Many SVG 2 features can be supported internally as SVG 2. For example, Inkscape currently uses 1-stop gradients for color palettes. On reading in, a one-stop gradient can be converted to a <solidColor> element. On writing out, if SVG 1.1 output is selected, the <colorColor> element can be converted back to a 1-stop gradient. An SVG 2 <hatch> element can be converted to a <pattern> large enough to cover the fill area. SVG 2 flowed text provides a natuaral fallback for SVG 1.1 renderers. A tab in the Preferences dialog could handle fine grain control of which SVG 2 features should be converted.

+

Many SVG 2 features can be supported internally as SVG 2. For example, Inkscape currently uses 1-stop gradients for color palettes. On reading in, a one-stop gradient can be converted to a <solidColor> element. On writing out, if SVG 1.1 output is selected, the <solidColor> element can be converted back to a 1-stop gradient. An SVG 2 <hatch> element can be converted to a <pattern> large enough to cover the fill area. SVG 2 flowed text provides a natuaral fallback for SVG 1.1 renderers. A tab in the Preferences dialog could handle fine grain control of which SVG 2 features should be converted.

Note, no browser seems to handles the <switch> element correctly so we should not rely on this feature.

Note, no browser seems to handles the <switch> element correctly so we should not rely on this feature.

It is important that Inkscape implements these features in a timely fashion. Not only will it be a benefit to our users... but it is a necessary step to insuring that these features remain in SVG 2. The W3C specification process requires at least two independent implementations of feature before final publication. Having Inkscape support these features not only will provide one of the implementations but it demonstrates to others that there is serious interest in these features.

We do need to be careful, though, to avoid the Flowed Text of SVG 1.2 debacle. Until the SVG 2 specification (or relevant CSS specification) is in the final stages of adoption, each new feature must be developed in the 'inkscape' name space; that is to say, the '-inkscape-' prefix must be used for new elements, attributes, and properties. It is also important that, until SVG 2 is widely supported, we support export to SVG 1.1 or clearly mark that a feature is supported only by SVG 2.

Many SVG 2 features can be supported internally as SVG 2. For example, Inkscape currently uses 1-stop gradients for color palettes. On reading in, a one-stop gradient can be converted to a <solidColor> element. On writing out, if SVG 1.1 output is selected, the <solidColor> element can be converted back to a 1-stop gradient. An SVG 2 <hatch> element can be converted to a <pattern> large enough to cover the fill area. SVG 2 flowed text provides a natuaral fallback for SVG 1.1 renderers. A tab in the Preferences dialog could handle fine grain control of which SVG 2 features should be converted.

Note, no browser seems to handles the <switch> element correctly so we should not rely on this feature.

Implementation

Framework

On read-in, convert SVG 1.1 to SVG 2

1-stop gradients -> <solidColor>

Flowed text -> CSS wrapped text

Etc.

Edit as SVG 2

On writing-out, convert SVG 2, if requested to SVG 1.1 (controlled by preferences)