 first | Daisy Diff compare report. Click on the changed parts for a detailed description. Use the left and right arrow keys to walk through the modifications. |
last  |
| first | Daisy Diff compare report. Click on the changed parts for a detailed description. Use the left and right arrow keys to walk through the modifications. |
last |
All coordinates and lengths in SVG can be specified with or without a unit identifier.
When a coordinate or length value is a number without a unit identifier (e.g., "25"), then the given coordinate or length is assumed to be in user units (i.e., a value in the current user coordinate system). For example:
<text style="font-size: 50">Text size is 50 user units</text>
Alternatively, a coordinate or length value can be expressed as a number following by a unit identifier (e.g., "25cm" or "15em"). The list of unit identifiers in SVG matches the list of unit identifiers in CSS: em, ex, px, pt, pc, cm, mm, in and percentages. The following describes how the various unit identifiers are processed:
As in CSS, the em and ex unit identifiers are relative to the current font's font-size and x-height, respectively.
One px unit is defined to be equal to one user unit. Thus, a length of "5px" is the same as a length of "5".
Note that at initialization, a user unit in the the initial coordinate system is equivalenced to the parent environment's notion of a px unit. Thus, in the the initial coordinate system, because the user coordinate system aligns exactly with the parent's coordinate system, and because often the parent's coordinate system aligns with the device pixel grid, "5px" might actually map to 5 devices pixels. However, if there are any coordinate system transformation due to the use of 'transform' or 'viewBox' attributes, because "5px" maps to 5 user units and because the coordinate system transformations have resulted in a revised user coordinate system, "5px" likely will not map to 5 device pixels. As a result, in most circumstances, "px" units will not map to the device pixel grid.
The other absolute unit identifiers from CSS (i.e., pt, pc, cm, mm, in) are all defined as an appropriate multiple of one px unit (which, according to the previous item, is defined to be equal to one user unit), based on what the SVG user agent determines is the size of a px unit (possibly passed from the parent processor or environment at initialization time). For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi). Then, for all processing of SVG content:
Note that use of px units or any other absolute unit identifiers can cause inconsistent visual results on different viewing environments since the size of "1px" may map to a different number of user units on different systems; thus, absolute units identifiers are only recommended for the 'width' and the 'height' on outermost 'svg' elements and situations where the content contains no transformations and it is desirable to specify values relative to the device pixel grid or to a particular real world unit size.
For percentage values that are defined to be relative to the size of viewport:
sqrt((actual-width)**2 + (actual-height)**2))/sqrt(2).Example Units below illustrates some of the processing rules for different types of units.
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="400px" height="200px" viewBox="0 0 4000 2000" xmlns="http://www.w3.org/2000/svg" version="1.1"> <title>Example Units</title> <desc>Illustrates various units options</desc> <!-- Frame the picture --> <rect x="5" y="5" width="3990" height="1990" fill="none" stroke="blue" stroke-width="10"/> <g fill="blue" stroke="red" font-family="Verdana" font-size="150"> <!-- Absolute unit specifiers --> <g transform="translate(400,0)"> <text x="-50" y="300" fill="black" stroke="none">Abs. units:</text> <rect x="0" y="400" width="4in" height="2in" stroke-width=".4in"/> <rect x="0" y="750" width="384" height="192" stroke-width="38.4"/> <g transform="scale(2)"> <rect x="0" y="600" width="4in" height="2in" stroke-width=".4in"/> </g> </g> <!-- Relative unit specifiers --> <g transform="translate(1600,0)"> <text x="-50" y="300" fill="black" stroke="none">Rel. units:</text> <rect x="0" y="400" width="2.5em" height="1.25em" stroke-width=".25em"/> <rect x="0" y="750" width="375" height="187.5" stroke-width="37.5"/> <g transform="scale(2)"> <rect x="0" y="600" width="2.5em" height="1.25em" stroke-width=".25em"/> </g> </g> <!-- Percentages --> <g transform="translate(2800,0)"> <text x="-50" y="300" fill="black" stroke="none">Percentages:</text> <rect x="0" y="400" width="10%" height="10%" stroke-width="1%"/> <rect x="0" y="750" width="400" height="200" stroke-width="31.62"/> <g transform="scale(2)"> <rect x="0" y="600" width="10%" height="10%" stroke-width="1%"/> </g> </g> </g> </svg>
 |
View this example as SVG (SVG-enabled browsers only)
The three rectangles on the left demonstrate the use of one of the absolute unit identifiers, the "in" unit (inch). The reference image above was generated on a 96dpi system (i.e., 1 inch = 96 pixels). Therefore, the topmost rectangle, which is specified in inches, is exactly the same size as the middle rectangle, which is specified in user units such that there are 96 user units for each corresponding inch in the topmost rectangle. (Note: on systems with different screen resolutions, the top and middle rectangles will likely be rendered at different sizes.) The bottom rectangle of the group illustrates what happens when values specified in inches are scaled.
The three rectangles in the middle demonstrate the use of one of the relative unit identifiers, the "em" unit. Because the 'font-size' property has been set to 150 on the outermost 'g' element, each "em" unit is equal to 150 user units. The topmost rectangle, which is specified in "em" units, is exactly the same size as the middle rectangle, which is specified in user units such that there are 150 user units for each corresponding "em" unit in the topmost rectangle. The bottom rectangle of the group illustrates what happens when values specified in "em" units are scaled.
The three rectangles on the right demonstrate the use of percentages. Note that the width and height of the viewport in the user coordinate system for the viewport element (in this case, the outermost 'svg' element) are 4000 and 2000, respectively, because processing the 'viewBox' attribute results in a transformed user coordinate system. The topmost rectangle, which is specified in percentage units, is exactly the same size as the middle rectangle, which is specified in equivalent user units. In particular, note that the 'stroke-width' property in the middle rectangle is set to 1% of the sqrt((actual-width)**2 + (actual-height)**2)) / sqrt(2), which in this case is .01*sqrt(4000*4000+2000*2000)/sqrt(2), or 31.62. The bottom rectangle of the group illustrates what happens when values specified in percentage units are scaled.
The following elements offer the option of expressing coordinate values and lengths as fractions (and, in some cases, percentages) of the bounding box (via keyword objectBoundingBox) on a , by setting a specified attribute to 'objectBoundingBox' on the given element:
| Element | Attribute | Effect |
|---|---|---|
| 'linearGradient' | 'gradientUnits |
| ' | Indicates that the attributes which specify the gradient vector ('x1', 'y1', 'x2', 'y2') represent fractions or percentages of the bounding box of the element to which the gradient is applied. |
| 'radialGradient' | 'gradientUnits |
| ' | Indicates that the attributes which specify the center ('cx', 'cy'), the radius ('r') and focus ('fx', 'fy') represent fractions or percentages of the bounding box of the element to which the gradient is applied. |
| 'pattern' | 'patternUnits |
| ' | Indicates that the attributes which define how to tile the pattern ('x', 'y', 'width', 'height') are established using the bounding box of the element to which the pattern is applied. |
| 'pattern' | 'patternContentUnits |
| ' | Indicates that the user coordinate system for the contents of the pattern is established using the bounding box of the element to which the pattern is applied. |
| 'clipPath' | 'clipPathUnits |
| ' | Indicates that the user coordinate system for the contents of the 'clipPath' element is established using the bounding box of the element to which the clipping path is applied. |
| 'mask' | 'maskUnits |
| ' | Indicates that the attributes which define the masking region ('x', 'y', 'width', 'height') is established using the bounding box of the element to which the mask is applied. |
| 'mask' | 'maskContentUnits |
| ' | Indicates that the user coordinate system for the contents of the 'mask' element are established using the bounding box of the element to which the mask is applied. |
| 'filter' | 'filterUnits |
| ' | Indicates that the attributes which define the filter effects region ('x', 'y', 'width', 'height') represent fractions or percentages of the bounding box of the element to which the filter is applied. |
| 'filter' | 'primitiveUnits |
| ' | Indicates that the various length values within the filter primitives represent fractions or percentages of the bounding box of the element to which the filter is applied. |
In the discussion that follows, the term applicable element is the element to which the given effect applies. For gradients and patterns, the applicable element is the graphics element which has its 'fill' or 'stroke' property referencing the given gradient or pattern. (See Inheritance of Painting Properties. For special rules concerning text elements, see the discussion of object bounding box units and text elements.) For clipping paths, masks and filters, the applicable element can be either a container element or a graphics element.
When keyword objectBoundingBox is used, then the effect is as if a supplemental transformation matrix were inserted into the list of nested transformation matrices to create a new user coordinate system.
First, the (minx,miny) and (maxx,maxy) coordinates are determined for the applicable element and all of its descendants. The values minx, miny, maxx and maxy are determined by computing the maximum extent of the shape of the element in X and Y with respect to the user coordinate system for the applicable element. The bounding box is the tightest fitting rectangle aligned with the axes of the applicable element's user coordinate system that entirely encloses the applicable element and its descendants. The bounding box is computed exclusive of any values for clipping, masking, filter effects, opacity and stroke-width. For curved shapes, the bounding box encloses all portions of the shape, not just end points. For 'text' elements, for the purposes of the bounding box calculation, each glyph is treated as a separate graphics element. The calculations assume that all glyphs occupy the full glyph cell. For example, for horizontal text, the calculations assume that each glyph extends vertically to the full ascent and descent values for the font.
Then, coordinate (0,0) in the new user coordinate system is mapped to the (minx,miny) corner of the tight bounding box within the user coordinate system of the applicable element and coordinate (1,1) in the new user coordinate system is mapped to the (maxx,maxy) corner of the tight bounding box of the applicable element. In most situations, the following transformation matrix produces the correct effect:
[ (maxx-minx) 0 0 (maxy-miny) minx miny ]
When percentages are used with attributes that define the gradient vector, the pattern tile, the filter region or the masking region, a percentage represents the same value as the corresponding decimal value (e.g., 50% means the same as 0.5). If percentages are used within the content of a 'pattern', 'clipPath', 'mask' or 'filter' element, these values are treated according to the processing rules for percentages as defined in Units.
Any numeric value can be specified for values expressed as a fraction or percentage of object bounding box units. In particular, fractions less are zero or greater than one and percentages less than 0% or greater than 100% can be specified.
Keyword objectBoundingBox should not be used when the geometry of the applicable element has no width or no height, such as the case of a horizontal or vertical line, even when the line has actual thickness when viewed due to having a non-zero stroke width since stroke width is ignored for bounding box calculations. When the geometry of the applicable element has no width or height and objectBoundingBox is specified, then the given effect (e.g., a gradient or a filter) will be ignored.
In order to allow interoperability between SVG content generators and user agents dealing with maps encoded in SVG, SVG encourages the use of a common metadata definition for describing the coordinate system used to generate SVG documents is encouraged.
Such metadata should must be added under the 'metadata' element of the topmost 'svg' element describing the map. They consist , consisting of an RDF description of the Coordinate Reference System definition used to generate the SVG map [RDF10]. The definition should Note that the presence of this metadata does not affect the rendering of the SVG in any way; it merely provides added semantic value for applications that make use of combined maps.
The definition must be conformant to the XML grammar described in the OpenGIS Recommendation on the Definition of Coordinate Reference System [OpenGIS Coordinate Systems GML 3.2.1, an OpenGIS Standard for encoding common CRS data types in XML [GML]. In order to correctly map the 2-dimensional data used by SVG, the CRS must be of subtype ProjectedCRS or Geographic2dCRS. The first axis of the described CRS maps the SVG x-axis and the second axis maps the SVG y-axis. Optionally, an additional affine transformation
The main purpose of such metadata is to indicate to the user agent that two or more SVG documents can be overlayed or merged into a single document. Obviously, if two maps reference the same Coordinate Reference System definition and have the same SVG 'transform' attribute value then they can be overlayed without reprojecting the data. If the maps reference different Coordinate Reference Systems and/or have different SVG 'transform' attribute values, then a specialized cartographic user agent may choose to transform the coordinate data to overlay the data. However, typical SVG user agents are not required to perform these types of transformations, or even recognize the metadata. It is described in this specification so that the connection between geographic coordinate systems and the SVG coordinate system is clear.
Attribute definition:
Specifies the affine transformation that has been applied to the map data. The syntax is identical to that described in The 'transform' attribute section.
Specifies that no supplemental affine transformation has been applied to the map data. Using this value has the same meaning as specifying the identity matrix, which in turn is just the same as not specifying the 'svg:transform' the attribute at all.
Animatable: no.
This attribute describes an optional additional affine transformation that may have been applied during this mapping. This additional transformation is described by an SVG transform attribute that can attribute may be added to the OpenGIS 'CoordinateReferenceSystem' element. Note that, unlike the 'transform attribute on the 'CoordinateReferenceSystem' ' attribute, it does not indicate that a transformation should is to be applied to the data within the file. Instead, it simply describes the transformation that was already applied to the data when being encoded in SVG.
There are three typical uses for the SVG 'svg:transform' global attribute. These are described below and used in the examples.
Most ProjectedCRS have the north direction represented by positive values of the second axis and conversely SVG has a y-down coordinate system. That's why, in order to follow the usual way to represent a map with the north at its top, it is recommended for that kind of ProjectedCRS to use the
SVG'svg:transform' global attribute with a 'scale(1, -1)' value as in the third example below.
Most Geographic2dCRS have the latitude as their first axis rather than the longitude, which means that the south-north axis would be represented by the x-axis in SVG instead of the usual y-axis. That's why, in order to follow the usual way to represent a map with the north at its top, it is recommended for that kind of Geographic2dCRS to use the
SVG'svg:transform' global attribute with a 'rotate(-90)' value as in the first example (while also adding the 'scale(1, -1)' as for ProjectedCRS).
In addition, when converting for profiles which place restrictions on precision of real number values, it may be useful to add an additional scaling factor to retain good precision for a specific area. When generating an SVG document from WGS84 geographic coordinates (EPGS 4326), we recommend the use of an additional 100 times scaling factor corresponding to an
SVG'svg:transform' global attribute with a 'rotate(-90) scale(100)' value (shown in the second example). Different scaling values may be required depending on the particular CRS.
The main purpose of such metadata is to indicate to the User Agent that two or more SVG documents can be overlayed or merged into a single document. Obviously, if two maps reference the same Coordinate Reference System definition and have the same SVG transform attribute value then they can be overlayed without reprojecting the data. If the maps reference different Coordinate Reference Systems and/or have different SVG transform attribute values, then a specialized cartographic User Agent may choose to transform the coordinate data to overlay the data. However, typical SVG user agents are not required to perform these types of transformations, or even recognize the metadata.
Below is a simple example of the coordinate metadata, which describes the coordinate system used by the document via a URI.
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"
<svg xmlns="http://www.w3.org/Graphics/SVG/
2000/svg" version="1.1/DTD/svg11.dtd
"
>
<svg
width="100" height="100" viewBox="0 0 1000 1000">version="1.1"
<desc>An examplexmlns="http://www.w3.org/2000/svg">
that references coordinate data.</desc>
<metadata>
<rdf:RDF xmlns:rdf
=
"http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:crs
=
"http://www.ogc.org/crs"
xmlns:svg="http://wwww.w3.org/2000/svg">
<rdf:
Description>
Description rdf:about="">
<!-- The Coordinate Reference System is described
through
an
a URI. -->
<crs:CoordinateReferenceSystem svg:transform="rotate(-90)"
rdf:resource="
"
http://www.example.org/srs/epsg.xml#4326"/>
</rdf:Description>
</rdf:RDF>
</metadata>
<!-- The actual map content -->
</svg>
The second example uses a well-known identifier to describe the coordinate system. Note that the coordinates used in the document have had the supplied transform applied.
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"
<svg xmlns="http://www.w3.org/Graphics/SVG/
2000/svg" version="1.1/DTD/svg11.dtd
"
>
<svg
width="100" height="100" viewBox="0 0 1000 1000">version="1.1"
<desc>Example usingxmlns="http://www.w3.org/2000/svg">
a well known coordinate system.</desc>
<metadata>
<rdf:RDF xmlns:rdf
=
"http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:crs
=
"http://www.ogc.org/crs"
xmlns:svg="http://wwww.w3.org/2000/svg">
<rdf:
Description>
Description rdf:about="">
<!-- In case of a well-known Coordinate Reference System
an 'Identifier' is enough to describe the CRS -->
<crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)">
<crs:Identifier>
<crs:code>4326</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
</crs:CoordinateReferenceSystem>
</rdf:Description>
</rdf:RDF>
</metadata>
<!-- The actual map content -->
</svg>
The third example defines the coordinate system completely within the SVG document.
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"
<svg xmlns="http://www.w3.org/Graphics/SVG/
2000/svg" version="1.1/DTD/svg11.dtd
"
>
<svg
width="100" height="100" viewBox="0 0 1000 1000">version="1.1"
<desc>Coordinate metadataxmlns="http://www.w3.org/2000/svg"> <metadata>
defined within the SVG document</desc> <metadata> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:crs="http://www.ogc.org/crs"
xmlns:svg="http://wwww.w3.org/2000/svg">
<rdf:
Description>
Description rdf:about="">
<!-- For other CRS it should be entirely defined -->
<crs:CoordinateReferenceSystem svg:transform="scale(1,-1)">
<crs:NameSet>
<crs:name>Mercator projection of WGS84</crs:name>
</crs:NameSet>
<crs:ProjectedCRS>
<!-- The actual definition of the CRS -->
<crs:CartesianCoordinateSystem>
<crs:dimension>2</crs:dimension>
<crs:CoordinateAxis>
<crs:axisDirection>north</crs:axisDirection>
<crs:AngularUnit>
<crs:Identifier>
<crs:code>9108</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
</crs:AngularUnit>
</crs:CoordinateAxis>
<crs:CoordinateAxis>
<crs:axisDirection>east</crs:axisDirection>
<crs:AngularUnit>
<crs:Identifier>
<crs:code>9108</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
</crs:AngularUnit>
</crs:CoordinateAxis>
</crs:CartesianCoordinateSystem>
<crs:CoordinateReferenceSystem>
<!-- the reference system of that projected system is
WGS84 which is EPSG 4326 in EPSG codeSpace -->
<crs:NameSet>
<crs:name>WGS 84</crs:name>
</crs:NameSet>
<crs:Identifier>
<crs:code>4326</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
</crs:CoordinateReferenceSystem>
<crs:CoordinateTransformationDefinition>
<crs:sourceDimensions>2</crs:sourceDimensions>
<crs:targetDimensions>2</crs:targetDimensions>
<crs:ParameterizedTransformation>
<crs:TransformationMethod>
<!-- the projection is a Mercator projection which is
EPSG 9805 in EPSG codeSpace -->
<crs:NameSet>
<crs:name>Mercator</crs:name>
</crs:NameSet>
<crs:Identifier>
<crs:code>9805</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
<crs:description>Mercator (2SP)</crs:description>
</crs:TransformationMethod>
<crs:Parameter>
<crs:NameSet>
<crs:name>Latitude of 1st standart parallel</crs:name>
</crs:NameSet>
<crs:Identifier>
<crs:code>8823</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
<crs:value>0</crs:value>
</crs:Parameter>
<crs:Parameter>
<crs:NameSet>
<crs:name>Longitude of natural origin</crs:name>
</crs:NameSet>
<crs:Identifier>
<crs:code>8802</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
<crs:value>0</crs:value>
</crs:Parameter>
<crs:Parameter>
<crs:NameSet>
<crs:name>False Easting</crs:name>
</crs:NameSet>
<crs:Identifier>
<crs:code>8806</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
<crs:value>0</crs:value>
</crs:Parameter>
<crs:Parameter>
<crs:NameSet>
<crs:name>False Northing</crs:name>
</crs:NameSet>
<crs:Identifier>
<crs:code>8807</crs:code>
<crs:codeSpace>EPSG</crs:codeSpace>
<crs:edition>5.2</crs:edition>
</crs:Identifier>
<crs:value>0</crs:value>
</crs:Parameter>
</crs:ParameterizedTransformation>
</crs:CoordinateTransformationDefinition>
</crs:ProjectedCRS>
</crs:CoordinateReferenceSystem>
</rdf:Description>
</rdf:RDF>
</metadata>
<!-- the actual map content -->
</svg>
The Viewport Attribute Module defines the Viewport.attrib attribute set.
| Collection Name | Attributes in Collection |
|---|---|
| Viewport.attrib | clip, overflow |
The following interfaces are defined below: SVGPoint, SVGPointList, SVGMatrix, SVGTransform, SVGTransformList, SVGAnimatedTransformList, SVGPreserveAspectRatio, SVGAnimatedPreserveAspectRatio.
Many of the SVG DOM interfaces refer to objects of class SVGPoint. An SVGPoint is an (x,y y) coordinate pair. When used in matrix operations, an SVGPoint is treated as a vector of the form:
[x]
[y]
[1]
IDL Definition
interface SVGPoint {
attribute float x; // raises DOMException on setting
setraises(DOMException); attribute float y; // raises DOMException on setting SVGPoint matrixTransform (
setraises(DOMException); SVGPoint matrixTransform(in SVGMatrix matrix
);
};
newpoint = matrix * thispoint
This interface defines a list of SVGPoint objects.
SVGPointList has the same attributes and methods as other SVGxxxList interfaces. Implementers may consider using a single base class to implement the various SVGxxxList interfaces.
IDL Definitioninterface SVGPointList { readonly attribute unsigned long numberOfItems; void
clear
(
)
raises(
DOMException
); SVGPoint initialize
(
in SVGPoint newItem
)
raises(
DOMException, SVGException
); SVGPoint getItem
(
in unsigned long index
)
raises(
DOMException
); SVGPoint insertItemBefore
(
in SVGPoint newItem, in unsigned long index
)
raises(
DOMException, SVGException
); SVGPoint replaceItem
(
in SVGPoint newItem, in unsigned long index
)
raises(
DOMException, SVGException
); SVGPoint removeItem
(
in unsigned long index
)
raises(
DOMException
); SVGPoint appendItem
(
in SVGPoint newItem
)
raises(
DOMException, SVGException
);
};
Many of SVG's graphics operations utilize 2x3 matrices of the form:
[a c e]
[b d f]
which, when expanded into a 3x3 matrix for the purposes of matrix arithmetic, become:
[a c e]
[b d f]
[0 0 1]
IDL Definition
interface SVGMatrix {
attribute float a; // raises DOMException on setting
setraises(DOMException); attribute float b; // raises DOMException on setting
setraises(DOMException); attribute float c; // raises DOMException on setting
setraises(DOMException); attribute float d; // raises DOMException on setting
setraises(DOMException); attribute float e; // raises DOMException on setting
setraises(DOMException); attribute float f; // raises DOMException on setting SVGMatrix multiply (
setraises(DOMException); SVGMatrix multiply(in SVGMatrix secondMatrix
); SVGMatrix inverse
(
)
raises(
SVGException
); SVGMatrix translate
(
in float x, in float y
); SVGMatrix scale
(
in float scaleFactor
); SVGMatrix scaleNonUniform
(
in float scaleFactorX, in float scaleFactorY
); SVGMatrix rotate
(
in float angle
); SVGMatrix rotateFromVector
(
in float x, in float y
)
raises(
SVGException
); SVGMatrix flipX
(
); SVGMatrix flipY
(
); SVGMatrix skewX
(
in float angle
); SVGMatrix skewY
(
in float angle
);
};
interface SVGTransform { // Transform Typesconst
unsigned short SVG_TRANSFORM_UNKNOWN
= 0;
const
unsigned short SVG_TRANSFORM_MATRIX
= 1;
const
unsigned short SVG_TRANSFORM_TRANSLATE = 2;const
unsigned short SVG_TRANSFORM_SCALE
= 3;
const
unsigned short SVG_TRANSFORM_ROTATE
= 4;
const
unsigned short SVG_TRANSFORM_SKEWX
= 5;
const
unsigned short SVG_TRANSFORM_SKEWY
= 6; readonly attribute unsigned short type; readonly attribute SVGMatrix matrix; readonly attribute float angle; void setMatrix
(
in SVGMatrix matrix
); void setTranslate
(
in float tx, in float ty
); void setScale
(
in float sx, in float sy
); void setRotate
(
in float angle, in float cx, in float cy
); void setSkewX
(
in float angle
); void setSkewY
(
in float angle
);
};
The matrix that represents this transformation
A convenience attribute for SVG_TRANSFORM_ROTATE, SVG_TRANSFORM_SKEWX and SVG_TRANSFORM_SKEWY. It holds the angle that was specified.
For SVG_TRANSFORM_MATRIX, SVG_TRANSFORM_TRANSLATE and SVG_TRANSFORM_SCALE, angle will be zero.
This interface defines a list of SVGTransform objects.
The SVGTransformList and SVGTransform interfaces correspond to the various attributes which specify a set of transformations, such as the 'transform' attribute which is available for many of SVG's elements.
SVGTransformList has the same attributes and methods as other SVGxxxList interfaces. Implementers may consider using a single base class to implement the various SVGxxxList interfaces.
IDL Definitioninterface SVGTransformList { readonly attribute unsigned long numberOfItems; void
clear
(
)
raises(
DOMException
); SVGTransform initialize
(
in SVGTransform newItem
)
raises(
DOMException, SVGException
); SVGTransform getItem
(
in unsigned long index
)
raises(
DOMException
); SVGTransform insertItemBefore
(
in SVGTransform newItem, in unsigned long index
)
raises(
DOMException, SVGException
); SVGTransform replaceItem
(
in SVGTransform newItem, in unsigned long index
)
raises(
DOMException, SVGException
); SVGTransform removeItem
(
in unsigned long index
)
raises(
DOMException
); SVGTransform appendItem
(
in SVGTransform newItem
)
raises(
DOMException, SVGException
); SVGTransform createSVGTransformFromMatrix
(
in SVGMatrix matrix
); SVGTransform consolidate
(
);
};
interface SVGAnimatedTransformList {
readonly attribute SVGTransformList baseVal; readonly attribute SVGTransformList animVal; };
interface SVGPreserveAspectRatio { // Alignment Typesconst
unsigned short SVG_PRESERVEASPECTRATIO_UNKNOWN
= 0;
const
unsigned short SVG_PRESERVEASPECTRATIO_NONE
= 1;
const
unsigned short SVG_PRESERVEASPECTRATIO_XMINYMIN = 2;const
unsigned short SVG_PRESERVEASPECTRATIO_XMIDYMIN = 3;const
unsigned short SVG_PRESERVEASPECTRATIO_XMAXYMIN = 4;const
unsigned short SVG_PRESERVEASPECTRATIO_XMINYMID = 5;const
unsigned short SVG_PRESERVEASPECTRATIO_XMIDYMID = 6;const
unsigned short SVG_PRESERVEASPECTRATIO_XMAXYMID = 7;const
unsigned short SVG_PRESERVEASPECTRATIO_XMINYMAX = 8;const
unsigned short SVG_PRESERVEASPECTRATIO_XMIDYMAX = 9;const
unsigned short SVG_PRESERVEASPECTRATIO_XMAXYMAX = 10; // Meet-or-slice Typesconst
unsigned short SVG_MEETORSLICE_UNKNOWN
= 0;
const
unsigned short SVG_MEETORSLICE_MEET
= 1;
const
unsigned short SVG_MEETORSLICE_SLICE = 2;
attribute unsigned short align; // raises DOMException on setting
setraises(DOMException); attribute unsigned short meetOrSlice; // raises DOMException on setting };
setraises(DOMException); };
interface SVGAnimatedPreserveAspectRatio {
readonly attribute SVGPreserveAspectRatio baseVal; readonly attribute SVGPreserveAspectRatio animVal; };