For all media, the SVG canvas describes "the space where the SVG content is rendered." The canvas is infinite for each dimension of the space, but rendering occurs relative to a finite rectangular region of the canvas. This finite rectangular region is called the SVG viewport. For visual media ([CSS2], section 7.3.1) the SVG viewport is the viewing area where the user sees the SVG content.
The size of the SVG viewport (i.e., its width and height) is determined by a negotiation process (see Establishing the size of the initial viewport) between the SVG document fragment and its parent (real or implicit). Once that negotiation process is completed, the SVG user agent is provided the following information:
Using the above information, the SVG user agent determines the viewport, an initial viewport coordinate system and an initial user coordinate system such that the two coordinates systems are identical. Both coordinates systems are established such that the origin matches the origin of the viewport (for the root viewport, the viewport origin is at the top/left corner), and one unit in the initial coordinate system equals one "pixel" in the viewport. (See Initial coordinate system.) The viewport coordinate system is also called viewport space and the user coordinate system is also called user space.
Lengths in SVG can be specified as:
The supported length unit identifiers are: em, ex, px, pt, pc, cm, mm, in, and percentages.
A new user space (i.e., a new current coordinate system) can be established at any place within an SVG document fragment by specifying transformations in the form of transformation matrices or simple transformation operations such as rotation, skewing, scaling and translation. Establishing new user spaces via coordinate system transformations are fundamental operations to 2D graphics and represent the usual method of controlling the size, position, rotation and skew of graphic objects.
New viewports also can be established. By establishing a new viewport, you can redefine the meaning of percentages units and provide a new reference rectangle for "fitting" a graphic into a particular rectangular area. ("Fit" means that a given graphic is transformed in such a way that its bounding box in user space aligns exactly with the edges of a given viewport.)
The SVG user agent negotiates with its parent user agent to determine the viewport into which the SVG user agent can render the document. In some circumstances, SVG content will be embedded (by reference or inline) within a containing document. This containing document might include attributes, properties and/or other parameters (explicit or implicit) which specify or provide hints about the dimensions of the viewport for the SVG content. SVG content itself optionally can provide information about the appropriate viewport region for the content via the ‘width’ and ‘height’ XML attributes on the outermost svg element. The negotiation process uses any information provided by the containing document and the SVG content itself to choose the viewport location and size.
The ‘width’ attribute on the outermost svg element establishes the viewport's width, unless the following conditions are met:
Under these conditions, the positioning properties establish the viewport's width.
Similarly, if there are positioning properties specified on the referencing element or on the outermost svg element that are sufficient to establish the height of the viewport, then these positioning properties establish the viewport's height; otherwise, the ‘height’ attribute on the outermost svg element establishes the viewport's height.
If the ‘width’ or ‘height’ attributes on the outermost svg element are in user units (i.e., no unit identifier has been provided), then the value is assumed to be equivalent to the same number of "px" units (see Units).
In the following example, an SVG graphic is embedded inline within a parent XML document which is formatted using CSS layout rules. Since CSS positioning properties are not provided on the outermost svg element, the width="100px" and height="200px" attributes determine the size of the initial viewport:
<?xml version="1.0" standalone="yes"?> <parent xmlns="http://some.url"> <!-- SVG graphic --> <svg xmlns='http://www.w3.org/2000/svg' width="100px" height="200px" version="1.1"> <path d="M100,100 Q200,400,300,100"/> <!-- rest of SVG graphic would go here --> </svg> </parent>
The initial clipping path for the SVG document fragment is established according to the rules described in The initial clipping path.
For the outermost svg element, the SVG user agent determines an initial viewport coordinate system and an initial user coordinate system such that the two coordinates systems are identical. The origin of both coordinate systems is at the origin of the viewport, and one unit in the initial coordinate system equals one "pixel" (i.e., a px unit as defined in CSS2 ([CSS2], section 4.3.2) in the viewport. In most cases, such as stand-alone SVG documents or SVG document fragments embedded (by reference or inline) within XML parent documents where the parent's layout is determined by CSS [CSS2] or XSL [XSL], the initial viewport coordinate system (and therefore the initial user coordinate system) has its origin at the top/left of the viewport, with the positive x-axis pointing towards the right, the positive y-axis pointing down, and text rendered with an "upright" orientation, which means glyphs are oriented such that Roman characters and full-size ideographic characters for Asian scripts have the top edge of the corresponding glyphs oriented upwards and the right edge of the corresponding glyphs oriented to the right.
If the SVG implementation is part of a user agent which supports styling XML documents using CSS2 compatible px units, then the SVG user agent should get its initial value for the size of a px unit in real world units to match the value used for other XML styling operations; otherwise, if the user agent can determine the size of a px unit from its environment, it should use that value; otherwise, it should choose an appropriate size for one px unit. In all cases, the size of a px must be in conformance with the rules described in CSS2 ([CSS2], section 4.3.2).
Example InitialCoords below shows that the initial coordinate system has the origin at the top/left with the x-axis pointing to the right and the y-axis pointing down. The initial user coordinate system has one user unit equal to the parent (implicit or explicit) user agent's "pixel".
<?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="300px" height="100px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Example InitialCoords - SVG's initial coordinate system</desc> <g fill="none" stroke="black" stroke-width="3" > <line x1="0" y1="1.5" x2="300" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="100" /> </g> <g fill="red" stroke="none" > <rect x="0" y="0" width="3" height="3" /> <rect x="297" y="0" width="3" height="3" /> <rect x="0" y="97" width="3" height="3" /> </g> <g font-size="14" font-family="Verdana" > <text x="10" y="20">(0,0)</text> <text x="240" y="20">(300,0)</text> <text x="10" y="90">(0,100)</text> </g> </svg>
View this example as SVG (SVG-enabled browsers only)
A new user space (i.e., a new current coordinate system) can be established by specifying transformations in the form of a ‘transform’ attribute on a container element or graphics element or a ‘viewBox’ attribute on an ‘svg’, ‘symbol’, ‘marker’, ‘pattern’ and the ‘view’ element. The ‘transform’ and ‘viewBox’ attributes transform user space coordinates and lengths on sibling attributes on the given element (see effect of the ‘transform’ attribute on sibling attributes and effect of the ‘viewBox’ attribute on sibling attributes) and all of its descendants. Transformations can be nested, in which case the effect of the transformations are cumulative.
Example OrigCoordSys below shows a document without transformations. The text string is specified in the initial coordinate system.
<?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="150px" xmlns="http://www.w3.org/2000/svg" version="1.1"> <desc>Example OrigCoordSys - Simple transformations: original picture</desc> <g fill="none" stroke="black" stroke-width="3" > <!-- Draw the axes of the original coordinate system --> <line x1="0" y1="1.5" x2="400" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="150" /> </g> <g> <text x="30" y="30" font-size="20" font-family="Verdana" > ABC (orig coord system) </text> </g> </svg>
View this example as SVG (SVG-enabled browsers only)
Example NewCoordSys establishes a new user coordinate system by specifying transform="translate(50,50)" on the third ‘g’ element below. The new user coordinate system has its origin at location (50,50) in the original coordinate system. The result of this transformation is that the coordinate (30,30) in the new user coordinate system gets mapped to coordinate (80,80) in the original coordinate system (i.e., the coordinates have been translated by 50 units in X and 50 units in Y).
<?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="150px" xmlns="http://www.w3.org/2000/svg" version="1.1"> <desc>Example NewCoordSys - New user coordinate system</desc> <g fill="none" stroke="black" stroke-width="3" > <!-- Draw the axes of the original coordinate system --> <line x1="0" y1="1.5" x2="400" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="150" /> </g> <g> <text x="30" y="30" font-size="20" font-family="Verdana" > ABC (orig coord system) </text> </g> <!-- Establish a new coordinate system, which is shifted (i.e., translated) from the initial coordinate system by 50 user units along each axis. --> <g transform="translate(50,50)"> <g fill="none" stroke="red" stroke-width="3" > <!-- Draw lines of length 50 user units along the axes of the new coordinate system --> <line x1="0" y1="0" x2="50" y2="0" stroke="red" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="30" y="30" font-size="20" font-family="Verdana" > ABC (translated coord system) </text> </g> </svg>
View this example as SVG (SVG-enabled browsers only)
Example RotateScale illustrates simple rotate and scale transformations. The example defines two new coordinate systems:
<?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="120px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Example RotateScale - Rotate and scale transforms</desc> <g fill="none" stroke="black" stroke-width="3" > <!-- Draw the axes of the original coordinate system --> <line x1="0" y1="1.5" x2="400" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="120" /> </g> <!-- Establish a new coordinate system whose origin is at (50,30) in the initial coord. system and which is rotated by 30 degrees. --> <g transform="translate(50,30)"> <g transform="rotate(30)"> <g fill="none" stroke="red" stroke-width="3" > <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue" > ABC (rotate) </text> </g> </g> <!-- Establish a new coordinate system whose origin is at (200,40) in the initial coord. system and which is scaled by 1.5. --> <g transform="translate(200,40)"> <g transform="scale(1.5)"> <g fill="none" stroke="red" stroke-width="3" > <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue" > ABC (scale) </text> </g> </g> </svg>
View this example as SVG (SVG-enabled browsers only)
Example Skew defines two coordinate systems which are skewed relative to the origin coordinate system.
<?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="120px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Example Skew - Show effects of skewX and skewY</desc> <g fill="none" stroke="black" stroke-width="3" > <!-- Draw the axes of the original coordinate system --> <line x1="0" y1="1.5" x2="400" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="120" /> </g> <!-- Establish a new coordinate system whose origin is at (30,30) in the initial coord. system and which is skewed in X by 30 degrees. --> <g transform="translate(30,30)"> <g transform="skewX(30)"> <g fill="none" stroke="red" stroke-width="3" > <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue" > ABC (skewX) </text> </g> </g> <!-- Establish a new coordinate system whose origin is at (200,30) in the initial coord. system and which is skewed in Y by 30 degrees. --> <g transform="translate(200,30)"> <g transform="skewY(30)"> <g fill="none" stroke="red" stroke-width="3" > <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue" > ABC (skewY) </text> </g> </g> </svg>
View this example as SVG (SVG-enabled browsers only)
Mathematically, all transformations can be represented as
3x3 transformation matrices of
the following form:
Since only six values are used in the above 3x3 matrix, a transformation matrix is also expressed as a vector: [a b c d e f].
Transformations map coordinates and lengths from a new
coordinate system into a previous coordinate system:
Simple transformations are represented in matrix form as follows:
Transformations can be nested to any level. The effect of
nested transformations is to post-multiply (i.e., concatenate)
the subsequent transformation matrices onto previously defined
transformations:
For each given element, the accumulation of all
transformations that have been defined on the given element and
all of its ancestors up to and including the element that
established the current viewport (usually, the ‘svg’
element which is the most
immediate ancestor to the given element) is called the current transformation matrix or CTM. The CTM thus represents the
mapping of current user coordinates to viewport
coordinates:
Example Nested illustrates nested transformations.
<?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="150px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Example Nested - Nested transformations</desc> <g fill="none" stroke="black" stroke-width="3" > <!-- Draw the axes of the original coordinate system --> <line x1="0" y1="1.5" x2="400" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="150" /> </g> <!-- First, a translate --> <g transform="translate(50,90)"> <g fill="none" stroke="red" stroke-width="3" > <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="0" y="0" font-size="16" font-family="Verdana" > ....Translate(1) </text> <!-- Second, a rotate --> <g transform="rotate(-45)"> <g fill="none" stroke="green" stroke-width="3" > <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="0" y="0" font-size="16" font-family="Verdana" > ....Rotate(2) </text> <!-- Third, another translate --> <g transform="translate(130,160)"> <g fill="none" stroke="blue" stroke-width="3" > <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="0" y="0" font-size="16" font-family="Verdana" > ....Translate(3) </text> </g> </g> </g> </svg>
View this example as SVG (SVG-enabled browsers only)
In the example above, the CTM within the third nested
transformation (i.e., the transform="translate(130,160)")
consists of the concatenation of the three transformations, as
follows:
The value of the ‘transform’ attribute is a <transform-list>, which is defined as a list of transform definitions, which are applied in the order provided. The individual transform definitions are separated by whitespace and/or a comma. The available types of transform definitions include:
All numeric values are <number>s.
If a list of transforms is provided, then the net effect is as if each transform had been specified separately in the order provided. For example,
<g transform="translate(-10,-20) scale(2) rotate(45) translate(5,10)"> <!-- graphics elements go here --> </g>
is functionally equivalent to:
<g transform="translate(-10,-20)"> <g transform="scale(2)"> <g transform="rotate(45)"> <g transform="translate(5,10)"> <!-- graphics elements go here --> </g> </g> </g> </g>
The ‘transform’ attribute is applied to an element before processing any other coordinate or length values supplied for that element. In the element
<rect x="10" y="10" width="20" height="20" transform="scale(2)"/>
the x, y, width and height values are processed after the current coordinate system has been scaled uniformly by a factor of 2 by the ‘transform’ attribute. Attributes x, y, width and height (and any other attributes or properties) are treated as values in the new user coordinate system, not the previous user coordinate system. Thus, the above ‘rect’ element is functionally equivalent to:
<g transform="scale(2)"> <rect x="10" y="10" width="20" height="20"/> </g>
The following is the Backus-Naur Form (BNF) for values for the ‘transform’ attribute. The following notation is used:
transform-list: wsp* transforms? wsp* transforms: transform | transform comma-wsp+ transforms transform: matrix | translate | scale | rotate | skewX | skewY matrix: "matrix" wsp* "(" wsp* number comma-wsp number comma-wsp number comma-wsp number comma-wsp number comma-wsp number wsp* ")" translate: "translate" wsp* "(" wsp* number ( comma-wsp number )? wsp* ")" scale: "scale" wsp* "(" wsp* number ( comma-wsp number )? wsp* ")" rotate: "rotate" wsp* "(" wsp* number ( comma-wsp number comma-wsp number )? wsp* ")" skewX: "skewX" wsp* "(" wsp* number wsp* ")" skewY: "skewY" wsp* "(" wsp* number wsp* ")" number: sign? integer-constant | sign? floating-point-constant comma-wsp: (wsp+ comma? wsp*) | (comma wsp*) comma: "," integer-constant: digit-sequence floating-point-constant: fractional-constant exponent? | digit-sequence exponent fractional-constant: digit-sequence? "." digit-sequence | digit-sequence "." exponent: ( "e" | "E" ) sign? digit-sequence sign: "+" | "-" digit-sequence: digit | digit digit-sequence digit: "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" wsp: (#x20 | #x9 | #xD | #xA)
For the ‘transform’ attribute:
Animatable: yes.
See the ‘animateTransform’ element for information on animating transformations.
It is often desirable to specify that a given set of graphics stretch to fit a particular container element. The ‘viewBox’ attribute provides this capability.
All elements that establish a new viewport (see elements that establish viewports), plus the ‘marker’, ‘pattern’ and ‘view’ elements have attribute ‘viewBox’. The value of the ‘viewBox’ attribute is a list of four numbers <min-x>, <min-y>, <width> and <height>, separated by whitespace and/or a comma, which specify a rectangle in user space which should be mapped to the bounds of the viewport established by the given element, taking into account attribute ‘preserveAspectRatio’. If specified, an additional transformation is applied to all descendants of the given element to achieve the specified effect.
A negative value for <width> or <height> is an error (see Error processing). A value of zero disables rendering of the element.
Example ViewBox illustrates the use of the ‘viewBox’ attribute on the outermost svg element to specify that the SVG content should stretch to fit bounds of the viewport.
<?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="300px" height="200px" version="1.1" viewBox="0 0 1500 1000" preserveAspectRatio="none" xmlns="http://www.w3.org/2000/svg"> <desc>Example ViewBox - uses the viewBox attribute to automatically create an initial user coordinate system which causes the graphic to scale to fit into the viewport no matter what size the viewport is.</desc> <!-- This rectangle goes from (0,0) to (1500,1000) in user space. Because of the viewBox attribute above, the rectangle will end up filling the entire area reserved for the SVG content. --> <rect x="0" y="0" width="1500" height="1000" fill="yellow" stroke="blue" stroke-width="12" /> <!-- A large, red triangle --> <path fill="red" d="M 750,100 L 250,900 L 1250,900 z"/> <!-- A text string that spans most of the viewport --> <text x="100" y="600" font-size="200" font-family="Verdana" > Stretch to fit </text> </svg>
| Rendered into viewport with width=300px, height=200px | Rendered into viewport with width=150px, height=200px | |
|---|---|---|
View
this example as SVG (SVG-enabled browsers only)
The effect of the ‘viewBox’ attribute is that the user agent automatically supplies the appropriate transformation matrix to map the specified rectangle in user space to the bounds of a designated region (often, the viewport). To achieve the effect of the example on the left, with viewport dimensions of 300 by 200 pixels, the user agent needs to automatically insert a transformation which scales both X and Y by 0.2. The effect is equivalent to having a viewport of size 300px by 200px and the following supplemental transformation in the document, as follows:
<?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="300px" height="200px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <g transform="scale(0.2)"> <!-- Rest of document goes here --> </g> </svg>To achieve the effect of the example on the right, with viewport dimensions of 150 by 200 pixels, the user agent needs to automatically insert a transformation which scales X by 0.1 and Y by 0.2. The effect is equivalent to having a viewport of size 150px by 200px and the following supplemental transformation in the document, as follows:
<?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="150px" height="200px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <g transform="scale(0.1 0.2)"> <!-- Rest of document goes here --> </g> </svg>
(Note: in some cases the user agent will need to supply a translate transformation in addition to a scale transformation. For example, on an outermost svg element, a translate transformation will be needed if the ‘viewBox’ attributes specifies values other than zero for <min-x> or <min-y>.)
Unlike the ‘transform’ attribute (see effect of the ‘transform’ on sibling attributes), the automatic transformation that is created due to a ‘viewBox’ does not affect the ‘x’, ‘y’, ‘width’ and ‘height’ attributes (or in the case of the ‘marker’ element, the ‘markerWidth’ and ‘markerHeight’ attributes) on the element with the ‘viewBox’ attribute. Thus, in the example above which shows an ‘svg’ element which has attributes ‘width’, ‘height’ and ‘viewBox’, the ‘width’ and ‘height’ attributes represent values in the coordinate system that exists before the ‘viewBox’ transformation is applied. On the other hand, like the ‘transform’ attribute, it does establish a new coordinate system for all other attributes and for descendant elements.
For the ‘viewBox’ attribute:
Animatable: yes.
In some cases, typically when using the ‘viewBox’ attribute, it is desirable that the graphics stretch to fit non-uniformly to take up the entire viewport. In other cases, it is desirable that uniform scaling be used for the purposes of preserving the aspect ratio of the graphics.
Attribute preserveAspectRatio="[defer] <align> [<meetOrSlice>]", which is available for all elements that establish a new viewport (see elements that establish viewports), plus the ‘image’, ‘marker’, ‘pattern’ and ‘view’ elements, indicates whether or not to force uniform scaling.
For elements that establish a new viewport (see elements that establish viewports), plus the ‘marker’, ‘pattern’ and ‘view’ elements, ‘preserveAspectRatio’ only applies when a value has been provided for ‘viewBox’ on the same element. For these elements, if attribute ‘viewBox’ is not provided, then ‘preserveAspectRatio’ is ignored.
For ‘image’ elements, ‘preserveAspectRatio’ indicates how referenced images should be fitted with respect to the reference rectangle and whether the aspect ratio of the referenced image should be preserved with respect to the current user coordinate system.
If the value of ‘preserveAspectRatio’ on an ‘image’ element starts with 'defer' then the value of the ‘preserveAspectRatio’ attribute on the referenced content if present should be used. If the referenced content lacks a value for ‘preserveAspectRatio’ then the ‘preserveAspectRatio’ attribute should be processed as normal (ignoring 'defer'). For ‘preserveAspectRatio’ on all other elements the 'defer' portion of the attribute is ignored.
The <align> parameter indicates whether to force uniform scaling and, if so, the alignment method to use in case the aspect ratio of the ‘viewBox’ doesn't match the aspect ratio of the viewport. The <align> parameter must be one of the following strings:
The <meetOrSlice> parameter is optional and, if provided, is separated from the <align> value by one or more spaces and then must be one of the following strings:
Example PreserveAspectRatio illustrates the various options on ‘preserveAspectRatio’. To save space, XML entities have been defined for the three repeated graphic objects, the rectangle with the smile inside and the outlines of the two rectangles which have the same dimensions as the target viewports. The example creates several new viewports by including ‘svg’ sub-elements embedded inside the outermost svg element (see Establishing a new viewport).
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [ <!ENTITY Smile " <rect x='.5' y='.5' width='29' height='39' fill='black' stroke='red'/> <g transform='translate(0, 5)'> <circle cx='15' cy='15' r='10' fill='yellow'/> <circle cx='12' cy='12' r='1.5' fill='black'/> <circle cx='17' cy='12' r='1.5' fill='black'/> <path d='M 10 19 A 8 8 0 0 0 20 19' stroke='black' stroke-width='2'/> </g> "> <!ENTITY Viewport1 "<rect x='.5' y='.5' width='49' height='29' fill='none' stroke='blue'/>"> <!ENTITY Viewport2 "<rect x='.5' y='.5' width='29' height='59' fill='none' stroke='blue'/>"> ]> <svg width="450px" height="300px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Example PreserveAspectRatio - illustrates preserveAspectRatio attribute</desc> <rect x="1" y="1" width="448" height="298" fill="none" stroke="blue"/> <g font-size="9"> <text x="10" y="30">SVG to fit</text> <g transform="translate(20,40)">&Smile;</g> <text x="10" y="110">Viewport 1</text> <g transform="translate(10,120)">&Viewport1;</g> <text x="10" y="180">Viewport 2</text> <g transform="translate(20,190)">&Viewport2;</g> <g id="meet-group-1" transform="translate(100, 60)"> <text x="0" y="-30">--------------- meet ---------------</text> <g><text y="-10">xMin*</text>&Viewport1; <svg preserveAspectRatio="xMinYMin meet" viewBox="0 0 30 40" width="50" height="30">&Smile;</svg></g> <g transform="translate(70,0)"><text y="-10">xMid*</text>&Viewport1; <svg preserveAspectRatio="xMidYMid meet" viewBox="0 0 30 40" width="50" height="30">&Smile;</svg></g> <g transform="translate(0,70)"><text y="-10">xMax*</text>&Viewport1; <svg preserveAspectRatio="xMaxYMax meet" viewBox="0 0 30 40" width="50" height="30">&Smile;</svg></g> </g> <g id="meet-group-2" transform="translate(250, 60)"> <text x="0" y="-30">---------- meet ----------</text> <g><text y="-10">*YMin</text>&Viewport2; <svg preserveAspectRatio="xMinYMin meet" viewBox="0 0 30 40" width="30" height="60">&Smile;</svg></g> <g transform="translate(50, 0)"><text y="-10">*YMid</text>&Viewport2; <svg preserveAspectRatio="xMidYMid meet" viewBox="0 0 30 40" width="30" height="60">&Smile;</svg></g> <g transform="translate(100, 0)"><text y="-10">*YMax</text>&Viewport2; <svg preserveAspectRatio="xMaxYMax meet" viewBox="0 0 30 40" width="30" height="60">&Smile;</svg></g> </g> <g id="slice-group-1" transform="translate(100, 220)"> <text x="0" y="-30">---------- slice ----------</text> <g><text y="-10">xMin*</text>&Viewport2; <svg preserveAspectRatio="xMinYMin slice" viewBox="0 0 30 40" width="30" height="60">&Smile;</svg></g> <g transform="translate(50,0)"><text y="-10">xMid*</text>&Viewport2; <svg preserveAspectRatio="xMidYMid slice" viewBox="0 0 30 40" width="30" height="60">&Smile;</svg></g> <g transform="translate(100,0)"><text y="-10">xMax*</text>&Viewport2; <svg preserveAspectRatio="xMaxYMax slice" viewBox="0 0 30 40" width="30" height="60">&Smile;</svg></g> </g> <g id="slice-group-2" transform="translate(250, 220)"> <text x="0" y="-30">--------------- slice ---------------</text> <g><text y="-10">*YMin</text>&Viewport1; <svg preserveAspectRatio="xMinYMin slice" viewBox="0 0 30 40" width="50" height="30">&Smile;</svg></g> <g transform="translate(70,0)"><text y="-10">*YMid</text>&Viewport1; <svg preserveAspectRatio="xMidYMid slice" viewBox="0 0 30 40" width="50" height="30">&Smile;</svg></g> <g transform="translate(140,0)"><text y="-10">*YMax</text>&Viewport1; <svg preserveAspectRatio="xMaxYMax slice" viewBox="0 0 30 40" width="50" height="30">&Smile;</svg></g> </g> </g> </svg>
View this example as SVG (SVG-enabled browsers only)
For the ‘preserveAspectRatio’ attribute:
Animatable: yes.
At any point in an SVG drawing, you can establish a new viewport into which all contained graphics is drawn by including an ‘svg’ element inside SVG content. By establishing a new viewport, you also implicitly establish a new viewport coordinate system, a new user coordinate system, and, potentially, a new clipping path (see the definition of the ‘overflow’ property). Additionally, there is a new meaning for percentage units defined to be relative to the current viewport since a new viewport has been established (see Units).
The bounds of the new viewport are defined by the ‘x’, ‘y’, ‘width’ and ‘height’ attributes on the element establishing the new viewport, such as an ‘svg’ element. Both the new viewport coordinate system and the new user coordinate system have their origins at (‘x’, ‘y’), where ‘x’ and ‘y’ represent the value of the corresponding attributes on the element establishing the viewport. The orientation of the new viewport coordinate system and the new user coordinate system correspond to the orientation of the current user coordinate system for the element establishing the viewport. A single unit in the new viewport coordinate system and the new user coordinate system are the same size as a single unit in the current user coordinate system for the element establishing the viewport.
Here is an example:
<?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="4in" height="3in" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>This SVG drawing embeds another one, thus establishing a new viewport </desc> <!-- The following statement establishing a new viewport and renders SVG drawing B into that viewport --> <svg x="25%" y="25%" width="50%" height="50%"> <!-- drawing B goes here --> </svg> </svg>
For an extensive example of creating new viewports, see Example PreserveAspectRatio.
The following elements establish new viewports:
Whether a new viewport also establishes a new additional clipping path is determined by the value of the ‘overflow’ property on the element that establishes the new viewport. If a clipping path is created to correspond to the new viewport, the clipping path's geometry is determined by the value of the ‘clip’ property. Also, see Clip to viewport vs. clip to ‘viewBox’.
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 font-size="50">Text size is 50 user units</text>
Alternatively, a coordinate or length value can be expressed as a number followed by a unit identifier (e.g., "25cm" or "15em"). (Note that CSS defined properties used in a CSS style sheet or the ‘style’ attribute require units for non-zero lengths, see SVG's styling properties.) The list of unit identifiers in SVG matches the list of unit identifiers in CSS: em, ex, px, pt, pc, cm, mm and in. The <length> type can also have a percentage unit identifier. 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 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, 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.
SVG needs to specify how to calculate some intrinsic sizing properties to enable inclusion within other languages. The intrinsic width and height of the viewport of SVG content must be determined from the ‘width’ and ‘height’ attributes. If either of these are not specified, a value of '100%' must be assumed. Note: the ‘width’ and ‘height’ attributes are not the same as the CSS width and height properties. Specifically, percentage values do not provide an intrinsic width or height, and do not indicate a percentage of the containing block. Rather, once the viewport is established, they indicate the portion of the viewport that is actually covered by image data.
The intrinsic aspect ratio of the viewport of SVG content is necessary for example, when including SVG from an ‘object’ element in HTML styled with CSS. It is possible (indeed, common) for an SVG graphic to have an intrinsic aspect ratio but not to have an intrinsic width or height. The intrinsic aspect ratio must be calculated based upon the following rules:
The aspect ratio is calculated by dividing a width by a height.
If the ‘width’ and ‘height’ of the rootmost ‘svg’ element are both specified with unit identifiers (in, mm, cm, pt, pc, px, em, ex) or in user units, then the aspect ratio is calculated from the ‘width’ and ‘height’ attributes after resolving both values to user units.
If either/both of the ‘width’ and ‘height’ of the rootmost ‘svg’ element are in percentage units (or omitted), the aspect ratio is calculated from the width and height values of the ‘viewBox’ specified for the current SVG document fragment. If the ‘viewBox’ is not correctly specified, or set to 'none', the intrinsic aspect ratio cannot be calculated and is considered unspecified.
Examples:
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" width="10cm" height="5cm"> ... </svg>
In this example the intrinsic aspect ratio of the viewport is 2:1. The intrinsic width is 10cm and the intrinsic height is 5cm.
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" width="100%" height="50%" viewBox="0 0 200 200"> ... </svg>
In this example the intrinsic aspect ratio of the rootmost viewport is 1:1. An aspect ratio calculation in this case allows embedding in an object within a containing block that is only constrained in one direction.
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" width="10cm" viewBox="0 0 200 200"> ... </svg>
In this case the intrinsic aspect ratio is 1:1.
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" width="75%" height="10cm" viewBox="0 0 200 200"> ... </svg>
In this example, the intrinsic aspect ratio is 1:1.
In order to allow interoperability between SVG content generators and user agents dealing with maps encoded in SVG, the use of a common metadata definition for describing the coordinate system used to generate SVG documents is encouraged.
Such metadata must be added under the ‘metadata’ element of the topmost ‘svg’ element describing the map, consisting of an RDF description of the Coordinate Reference System definition used to generate the SVG map [RDF-PRIMER]. 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 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.
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 attribute may be added to the OpenGIS ‘CoordinateReferenceSystem’ element. Note that, unlike the ‘transform’ attribute, it does not indicate that a transformation 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: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: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: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: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.
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"?> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100" viewBox="0 0 1000 1000"> <desc>An example 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://www.w3.org/2000/svg"> <rdf:Description rdf:about=""> <!-- The Coordinate Reference System is described through 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"?> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100" viewBox="0 0 1000 1000"> <desc>Example using 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://www.w3.org/2000/svg"> <rdf: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"?> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="100" height="100" viewBox="0 0 1000 1000"> <desc>Coordinate 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://www.w3.org/2000/svg"> <rdf: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>
Many of the SVG DOM interfaces refer to objects of class SVGPoint. An SVGPoint is an (x, y) coordinate pair. When used in matrix operations, an SVGPoint is treated as a vector of the form:
[x] [y] [1]
If an SVGRect object is designated as read only, then attempting to assign to one of its attributes will result in an exception being thrown.
interface SVGPoint { attribute float x setraises(DOMException); attribute float y setraises(DOMException); SVGPoint matrixTransform(in SVGMatrix matrix); };
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.
interface SVGPointList { readonly attribute unsigned long numberOfItems; void clear() raises(DOMException); SVGPoint initialize(in SVGPoint newItem) raises(DOMException); SVGPoint getItem(in unsigned long index) raises(DOMException); SVGPoint insertItemBefore(in SVGPoint newItem, in unsigned long index) raises(DOMException); SVGPoint replaceItem(in SVGPoint newItem, in unsigned long index) raises(DOMException); SVGPoint removeItem(in unsigned long index) raises(DOMException); SVGPoint appendItem(in SVGPoint newItem) raises(DOMException); };
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]
interface SVGMatrix { attribute float a setraises(DOMException); attribute float b setraises(DOMException); attribute float c setraises(DOMException); attribute float d setraises(DOMException); attribute float e setraises(DOMException); attribute float f 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 Types const 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) raises(DOMException); void setTranslate(in float tx, in float ty) raises(DOMException); void setScale(in float sx, in float sy) raises(DOMException); void setRotate(in float angle, in float cx, in float cy) raises(DOMException); void setSkewX(in float angle) raises(DOMException); void setSkewY(in float angle) raises(DOMException); };
The matrix that represents this transformation. The matrix object is live, meaning that any changes made to the SVGTransform object are immediately reflected in the matrix object and vice versa. In case the matrix object is changed directly (i.e., without using the methods on the SVGTransform interface itself) then the type of the SVGTransform changes to SVG_TRANSFORM_MATRIX.
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.
Sets the transform type to SVG_TRANSFORM_MATRIX, with parameter matrix defining the new transformation. The values from the parameter matrix are copied, the matrix parameter does not replace SVGTransform::matrix.
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.
An SVGTransformList object can be designated as read only, which means that attempts to modify the object will result in an exception being thrown, as described below.
interface SVGTransformList { readonly attribute unsigned long numberOfItems; void clear() raises(DOMException); SVGTransform initialize(in SVGTransform newItem) raises(DOMException); SVGTransform getItem(in unsigned long index) raises(DOMException); SVGTransform insertItemBefore(in SVGTransform newItem, in unsigned long index) raises(DOMException); SVGTransform replaceItem(in SVGTransform newItem, in unsigned long index) raises(DOMException); SVGTransform removeItem(in unsigned long index) raises(DOMException); SVGTransform appendItem(in SVGTransform newItem) raises(DOMException); SVGTransform createSVGTransformFromMatrix(in SVGMatrix matrix); SVGTransform consolidate() raises(DOMException); };
Creates an SVGTransform object which is initialized to transform of type SVG_TRANSFORM_MATRIX and whose values are the given matrix. The values from the parameter matrix are copied, the matrix parameter is not adopted as SVGTransform::matrix.
interface SVGAnimatedTransformList { readonly attribute SVGTransformList baseVal; readonly attribute SVGTransformList animVal; };
An SVGPreserveAspectRatio object can be designated as read only, which means that attempts to modify the object will result in an exception being thrown, as described below.
interface SVGPreserveAspectRatio { // Alignment Types const 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 Types const unsigned short SVG_MEETORSLICE_UNKNOWN = 0; const unsigned short SVG_MEETORSLICE_MEET = 1; const unsigned short SVG_MEETORSLICE_SLICE = 2; attribute unsigned short align setraises(DOMException); attribute unsigned short meetOrSlice setraises(DOMException); };
interface SVGAnimatedPreserveAspectRatio { readonly attribute SVGPreserveAspectRatio baseVal; readonly attribute SVGPreserveAspectRatio animVal; };


First of all, thanks for visiting my blog.
I think of this blog as my scratch book. A place where I can write about my experiences in personal and professional life. Remember the days we used to write diaries in the childhood as
Dear Diary,
Today I did ………
This blog is the same dear diary - the only difference being this diary is open to all.
Earlier I thought that I will confine this blog to just tech related learnings and then I saw this blog and it gave me something I can never forget. Every time he mentioned about his last days he taught something important to me. All I can feel - he is so bold and he is making me learn something through his personal experiences of last days and so, I decided to eventually write my own personal experiences and make it open to all. May be someday; someone; reading my experiences will get the strength I got due to Pieter Hintjens.
But to start, I am coming up with personal notes about a book I am currently reading these days. So, stay tuned since something interesting is coming up really soon.


Public Functions
__init__(self, compositions)
Initialize an empty graph, with empty queue, nodes dictionary and
edges dictionary.
add_nodes(self, sources, source_type)
Creates Nodes for each source and add them to the nodes table. Also
initializes the edges table now that all nodes are known. A source is
either an event or timex tag or simply an identifier.
get_edges(self)
Return all edges that have a constraint on them.
pp_html(self, filename=None, filehandle=None, standalone=False)
Print the graph to an HTML table in filename.
pp_nodes(self)
Print all nodes with their edges_in and edges_out attributes to
standard output.
propagate(self, constraint)
Propagate the constraint through the graph, using Allen's
constraint propagation algorithm.
reduce(self)
Reduce the grap to one that does not contain any relations derived by
closure. This does not get you a graph with the original annotations
because some might have been removed due to inconsistencies.
remove_node(self, node_id)
Remove a node from the graph. Involves removing the node from the
nodes hash, removing the node's column and row in the edges array and
removing the node from edges_in and edges_out attributes of other
nodes. This is not being used right now.
Private Functions
_add_constraint_to_edge(self, constraint, edge)
This method links a constraints to its edge by retrieving the edge
from the graph, adding the constraint to this edge, and setting the edge
attribute on the constraint.
_add_constraint_to_queue(self, edge, relset, c1, c2)
_check_all_i_j_k(self, node_i, node_j, edge_i_j)
Check the constriants on [node_i --> node_j --> node_k].
_check_all_k_i_j(self, node_i, node_j, edge_i_j)
Check the constraints on [node_k --> node_i --> node_j].
_check_i_j_k(self, edge_i_j, edge_j_k, node_i, node_j)
Look at the i->j->k subgraph and check whether the new constraint in
Edge(i,j) allows you to derive something new by composition. The nodes
node_i and node_j could be derived from edge_i_j but are handed to this
function because they were already available and it saves a bit of time
this way.
_check_k_i_j(self, edge_k_i, edge_i_j, node_i, node_j)
Look at the k->i->j subgraph and check whether the new constraint in
Edge(i,j) allows you to derive something new by composition. The nodes
node_i and node_j could be derived from edge_i_j but are handed to this
function because they were already available and it saves a bit of time
this way.
_combine(self, edge, relset, c1, c2)
Compare the relation set on the edge to the relation set created by
composition. Creates the intersection of the relation sets and checks
the result: (i) inconsistency, (ii) more specific than relation set on
edge, or (iii) something else. The alrgument c1 and c2 are the
constraints that were composed to create relset and will be used to set
the history on a new constraint if it is created.
_compose(self, object1, object2)
Return the composition of the relation sets on the two objects. One
object is an edge, the other a Constraint. Once the relations
are retrieved from the objects all that's needed is a simple
lookup in the compositions table.
_get_edge(self, node1, node2)
Return the edge from node1 to node2.
_html_added_table(self, fh)
_html_nodes_table(self, fh, nodes)
_intersect_constraints(self, edge, constraint)
Intersect the constraint that was just derived with the one already
on the edge. There are three cases: (1) the new constraint, if it is the
one originally handed to the propagate() function, introduces an
inconsistency; (2) the new constraint is identical to the one already
there and can be ignored; (3) the intersection of the new constraint
with the old constraint is the same as the old constraint; and (4) the
new constraint is more specific than the already existing
constraint. The method returns False in the first two cases and the
intersection in the last case.
_normalize_relations(self)
Remove all relations that are not in the set of normalized relations,
not used now but may come in handy later.
_remove_derived_relations(self)
Remove all derived relations from the graph.
_remove_disjunctions(self)
Remove all disjunctions from the graph, not used now but may come in
handy later.
_update_constraint(self, edge_i_j, constraint_i_j, intersection)
Update a constraint by setting its relation set to the intersection
and then add it to the edge. Once you have done that you need to check
whether this constraint then puts further constraints on incoming edges
to node i and outgoing edges from node j.


Demonstrates how the undropdown jQuery UI widget can be used to create a drop-down list for selection of a color palette.
Selected: None


--- layout: page title: "About Me" description: "70% American, 30% Taiwanese, I code, I play, I eat" header-img: "img/about-bg.jpg" ---
Hi I'm Eugene Chang, I am an American programmer currently working in Taiwan. This blog is an archieve of my struggle to become an expert programmer and engineer.


By the end of this module, you should be able to...
- understand how to create your own object types (classes)
- understand how objects are stored in memory
- become more comfortable with designing objects based on storiesunderstand == vs equals(..)>
By the end of this module, you should be able to...


Contact What can we do for you? Please use the contact my email<EMAIL_ADDRESS>We'd love to hear from you!


Hi, I’m Shantharam Shenoy,
a software craftsman with over 9 years of experience in shipping complex enterprise applications.
Having previously worked mainly with Enterprise Integration tools, i have recently made the switch to MEAN Stack as well as IIB.
I am currently working with
Neutrinos with a vision to bring idea to life.
Tweet to me at
@shantharamksd.


| fkSession reference pages |
[wavemean,wavestd,waveprops]=UPDATE_WAVEFORM(rootdir,ttfile,clusterfile) [...]=UPDATE_WAVEFORM(...,maxchan)
[wavemean,wavestd,waveprops]=UPDATE_WAVEFORM(rootdir,ttfile,clusterfile) loads previously calculated mean waveforms or, if cluster file is newer than wave file, calculates mean waveforms for the cluster file. Returns the mean, standard deviation and properties (peak, trough, etc.) of the waveform. Waveforms are centered at the peak of the waveform in the channel with the largest peak.
[...]=UPDATE_WAVEFORM(...,maxchan) the specified channel is used to center the waveform, rather than finding the channel with the largest peak (saves computation).
| import_env | Toolbox page | save_event |


Hello
I came across this interesting project online and would like to contribute and develop this.Am an embedded developer owning a sanguino board (based on arduino). I currently work on Embedded linux systems. I have few queries as I visited this site first time. Would be great if you can help me get started.
At my end I wish to develop a whole system of such kind and have fun!
Can I know how active this project is?
Current stage of completion?
How complex is it and time needed to build the Hardware mentioned here?
Any areas which I could get invloved immediately and contribute immediately without necessity of hardware?
Thanks
Re: Wish to Contribute and get involved
Hello kishoreinme
Thankyou for your interest, is there a particular aspect of a system that your most interested in? There certainly is a lot of scope for further development.
Have a look through these pages that detail some of the ideas we have for further developments and what we are working on:
emonTx New Version Dev Ideas
OpenEnergyMonitor in general development plans
http://openenergymonitor.org/emon/labs
If your interested in web application development, have a look at emoncms, thats what I predominantly work on:
Emoncms specific development plans
https://github.com/openenergymonitor/emoncms3/issues
Trystan
Re: Wish to Contribute and get involved
Hello TrystanLea
Thanks for the reply. I am pretty confident in getting data from schematics and datasheets and Arduino or any C kind of development with hardware.Iam not good at building hardware but can manage to get some help.I would like to get involved in the web app development in future days.
Along with an electrical grad, we had long back worked but shelved an amateur work on domestic controlling and monitoring of AC appliances with Arduino and a php web platform. It was shapeless and unguided. Now here emon has a professional design and community support with which I would like resume my project and thus contribute here too. :) Almost a fresh start for me.
I could visualize my working the following way otherise If you could suggest something else.
1) First I wish to build a basic core but an end to end setup with emonTx, emonGLCD and emonBase and get a working setup.
Going through the respective pages,I feel EmonTx can be built with less efforts than EmonGLCD or emonBase. are there any built modules available? Jeenode and Nanode modules availibity in my location (India) is unconfirmed.
How should I proceed in this front. Any suggestions on this would be great
2) Further work would for me wold be more on the emonTx on my side along with software changes on remaining setup.
Got to see the labs page for further getting the emonBase with Beagleboard kind of setup, which I would also be interested to contribute as my current work is in that lines.
Thanks
Re: Wish to Contribute and get involved
If you require help with hardware layout on this project I can help :-)
GPRS module would be a nice to have also
Re: Wish to Contribute and get involved
kishoreinme: for building the emontx, there aren't any prebuilt modules yet but you can get a kit: shop.openenergymonitor.com/emontx433-kit/ or if you prefer you can build from scratch: http://openenergymonitor.org/emon/buildingblocks/how-to-build-an-arduino-energy-monitor
It would be great to see a beagleboard based basestation. What are your thoughts for that kind of setup? Have you also looked at the raspberry PI?
Pforang: the best thing would be to get in contact with Glyn, he's currently designing the emontx SMT and has put all the design files online here: http://openenergymonitor.org/emon/node/736 He is looking for input on layout.
Re: Wish to Contribute and get involved
Hello guys
As hardware right now I have a Sanguino board (Arduino based ) and CT sensors. I would like to build a emonTx myself. Can patchup with Hardware guys aroung to get a board done.
Regarding the GLCD is there any specific modules or part numbers preferred.?
@Pforang Thanks for the help offered. I would really require your support. I dont get the GPRS part you had mentioned. what was that about?
@ TrystanLea I find the emonBase right now has a task of gettine emonTX's data to a server , may be a PC . I feel replacing just nanode with Beagle board or a Rasp PI will underutilize the boards all together. Beagle with linux is capable of running a Web server itself, which would combine the emonBase+PC actuallly.
What kind of thoughts do you guys have for this kinda implementation?


--- layout: post podcast_file_name: 'episode3.mp3' duration: '04:52' data_length: '4689001' published: true title: Episode 3 --- {% include post_start.html %} {% include note.html project='JBWBuilders' version='0.0.1' author='Joris Kluivers' twitter='kluivers' description='Builder categories for NSURL and NSDate.' source='' homepage='https://github.com/kluivers/jbw-builders' %} {% include note.html project='EDColor' version='0.2.1' author='Andrew Sliwinski' twitter='thisandagain' description='A collection of categories and utilities that extend UIColor.' source='' homepage='https://github.com/thisandagain/color' %} {% include note.html project='EBPhotoPages' version='0.9.1' author='Eddy Borja' twitter='eddyborja_' description='A photo gallery for iOS with a modern feature set.' source='' homepage='https://github.com/EddyBorja/EBPhotoPages' %} {% include note.html project='CMDQueryStringSerialization' version='0.2.0' author='Caleb Davenport' twitter='calebd' description='Easy conversion between dictionaries and query strings in Objective-C.' source='' homepage='https://github.com/calebd/CMDQueryStringSerialization' %} {% include note.html project='CCHexagonFlowLayout' version='1.0.2' author='Cyril Chandelier' twitter='cyrilchandelier' description='UICollectionView layout for both horizontal and vertical management of hexagonal cells.' source='' homepage='https://github.com/cyrilchandelier/CCHexagonFlowLayout' %}
We officially endorse the Hexagonal Laptop Sticker Standard Committee.
{% include post_end.html %}


Salmon Cookies
Shop
Contact Us
History
Locations
Menu
Internal Sales Data
Add New Location
Name:
Minimum Customers:
Maximum Customers:
Average Sale:
Add Location


Published on November 29, 2017 and updated on October 30, 2021.
Update October 30, 2021: When the original post was written, Google had not launched Google Analytics version 4, which doesn’t use views anymore and makes less use of cookies to identify users.
This is the sixth and last post of a 6 part series in which I’ll break down the main topics within statistics for online sample testing. The topics are:
- The importance of understanding statistics for tests with samples;
- Hypotheses;
- Samples and probabilities;
- Histograms and density curves;
- P-value, alpha, beta and power;
- Designing tests and configuring calculators (this post).
Bonus: A/B testing significance calculator.
Testing process
This series presented many mathematical topics that, together, make a standardized process to study samples. This process, seen from a panoramic perspective, have the following steps:
- Describe null and alternate hypotheses;
- Determine if the test will have one or two tails;
- Determine alpha and beta;
- Collect the samples;
- Calculate the conversion rates (also called proportions or probabilities of success) for all samples;
- Classify each conversion rate within a frequency;
- Repeat the previous steps for all testing variations until their conversion rate frequencies assume a normal distribution;
- Overlap all normal distributions within the same level;
- Calculate the combined mean and p-value for all normal distributions;
- Locate the p-value within the combined normal distribution using the standard error and a z-scores table;
- Check if p-value is smaller than alpha in one of the tails of the null hypothesis normal distribution;
- Check if the sample size is bigger enough to finish the test once statistical significance is achieved.
Throughout this post, some details will be added to the process in order to properly setup testing tools and calculators.
minimum detectable effect
minimum detectable effect, briefly mentioned in the introductory post of this series, is the size of the difference that the researcher wants to see between two or more variations of a test. Is the effect size to be expected. The minimum detectable effect is directly related to the sample size. The smaller the minimum detectable effect, the bigger must be the sample, which leads to more time to collect it. The hypothesis to be tested can contain a minimum expected size effect which can be used to configure testing tools and calculators.
Some companies state the expected minimum effect to be considered in a test, but end up finding differences that are smaller than what was expected. The business can then accept this difference and change its product or conclude that the cost to change will be greater than the return over investment.
Minimum sample size for a test
Sample sizes depend on four factors:
- Minimum detectable effect;
- Alpha;
- Beta;
- Conversion rate (or the null hypothesis conversion rate).
Some calculators assume at least beta to be 0.2, without the possibility to change the probability of a false negative. After providing these four values in a calculator, it can show the amount of individuals required in a sample for each variation of a test or the size of the entire sample. I’ll use Evan Miller's calculator to illustrate the effect of beta and the minimum detectable effect to calculate sample sizes.
It shows the amount of individuais needed for each variation of a test. Required parameters are:
- Baseline conversion rate: is the conversion rate of a product. This is assumed in the null hypothesis;
- Minimum detectable effect: is the size of the difference that the researcher expect to see between conversions across each study group. The bigger this number, the bigger the difference to be expected and smaller the required sample size. This number is read alongside the baseline conversion rate. Using 20% as the average conversion rate and 5% minimum detectable effect, conversion rates below 15% and above 25% will be detected considering the error margin associated with beta (note that the calculator is configured to find the interval in absolute values);
- Statistical power (1 - beta): is the probability of correctly rejecting the null hypothesis when the alternate is true. Beta is the probability of false negative and 1 - beta is the statistical power;
- Significance level (alpha): is the probability of a false positive. Alpha and significance level are synonyms. In the example, alpha is 5% (or 0.05).
Calculators can work differently, like the one created by Optimizely, but the principles are the same.
This calculator is simpler when compared to the previous one and assume 100% statistical power (or 1), as per documentation, what explains the sample size being bigger than when calculated using Evan Miller's calculator using the same configuration. The bigger the statistical power (1 - beta), the smaller is beta (smaller is the probability of a false negative) and the bigger is the required sample size.
Estimated duration of a test
Another common metric is the duration of a test. To calculate the duration of a test, it suffice to divide the sample size and the average daily number of visitors in the product. VWO calculator, for instance, ask the current and expected conversion rates, the number of testing variations and the percentage of visitors that will be included in the test in order to determine the duration of the test.
It is useful to know how long a test will run in order to set up expectations, but achieve the required sample size is far more important. Also, since the number of daily visits given to the calculator is an average, this estimate cannot be taken as completely true. If a test runs for the expected number of days and the sample size has not achieved the required size, the test should continue until the sample size is big enough, while making sure that the test doesn’t run for too long.
Sample quality
The first post of this series highlighted some technological restraints to perform tests with online samples. In summary, researchers have very limited amount of control over the conditions at which test subjects are exposed, which influence the quality of available samples. If not controlled properly, these conditions can invalidate any findings of a test. Some of these are:
- Interference between study groups;
- Multiple concurrent experiments;
- Cookie expiration;
- Seasonality and time based events;
- Multiple browsers and devices;
Interference between study groups
This is somehow related to the problem when using multiple browsers and devices, in which participants can be exposed to the effect given to other variations in a test. This type of interference can also happen depending on the type of test being conducted. One example could be testing the shipping rate of a product. Users exposed to a certain price tag can recommend the product for other users based on that price, but when they get to the website, they may end up seeing a completely different shipping rate depending on the test variant they ended up. This create noise in the sample. It is important to think about the repercussion of what is being tested to know if a test with samples is the best way to validate a given hypothesis.
Multiple concurrent experiments
Tests can be chained, increasing the risk of interference among tests. Chained tests can be mutually exclusive, meaning that participants from experiment 1 will not be subjected to experiment 2 and vice versa. Another type of chained test is sequential, in which one test must end for another to start. Mutually exclusive and sequential tests reduce can reduce noise when running multiple tests.
Multiple experiments can be done to reduce the necessary amount of time when performing tests, as long as there is enough sample for all tests.
Cookie expiration
Given the fact that website and app visitors are anonymous at first, the cookie is the method by which testing tools identify them. If a visitor returns to a product after being selected for the test, the experience should remain consistent between visits. In other words, tools should remember that a returning visitor was previously selected for a study. There are some problems with cookies:
- They can be altered, deleted or blocked by test subjects;
- They are only available on the device that accessed the product (they aren’t cross platform);
- They have expiration date.
Expiration dates for cookies vary according to the tool. VWO documentation, for instance, states that the cookies that are installed by VWO last for 100 days. Usually this can be configured by the researcher as needed and cannot be changed after the beginning of a test.
Given the instability of cookies to identify test subjects, it is not possible to guarantee that online samples are free from noise, no matter how much careful the environment was planned. The longer the test, the more noise gets added to the samples. A test that runs for too long can have a lot of noise and the test can lose it’s validity. It is common to assume that tests running for more than 30 days already have a lot of noise on the sample.
Seasonality and time based events
Seasonal events are exceptions to the rule. Adding seasonality as a variable avoid surprises when analyzing the behavior of a sample, and diminishes the chance of invalidating the test. Black Friday is an example of a seasonal event. Tests being performed during this event must take into account that samples will be composed of people that are looking for good prices when shopping, which can be something atypical for other times of the year. One way to control for seasonality is to test just during the seasonal event, assuming it for the hypothesis, or avoid tests during seasonal events.
Study groups can also behave differently during certain periods, like weekends. Depending on the type of business and product, traffic volumes decrease during weekends. Even during weekdays there can be differences. Let’s say, for instance, that every Wednesday night customers of an e-commerce receive a newsletter containing a selection of products with discounts and some of them visit the website to redeem the offer. These visitors can generate noise to the sample, as they behave differently. To deal with that, some recommendations are to run tests for at least one or two full weeks, but it is important to remember that the sample size must be achieved.
Multiple browsers and devices
The biggest challenge when conducting tests with online samples is to identify the same individual from a sample across multiple browsers and devices. Even using the same browser, visitors can use both an anonymous and a regular session, which will count it as being two distinct users. Since cookies are not shared across browsers and devices, different browsers will be counted as different individuals, and the same can be said for devices. There are some solutions to control for the noise, but there are no known solutions to eliminate the problem entirely. Some options are testing based on geographic regions or use Google Analytics Universal with User IDs, which requires a login system as well as a dedicated view on Google Analytics to count cross device sessions.
Online samples will always have some noise, despite how controlled is the environment.
Statistical significance and sample size
There are calculators for sample size, duration of a test and also for statistical significance. Statistical significance is also known as the compliment of alpha, or 1 - alpha. This number is more common when using calculators or testing tools, as is easier to comprehend by those who have no statistical background but need to run tests. Statistical significance calculators receive as inputs the desired level of statistical significance, the number of visits and the number of conversion events for each testing variation. AB Test Guide calculator accepts as input the possibility to choose between one and two tails.
This example show the result for a test with two tails, which allows for results worse than the default.
Differences on reporting for testing tools and analytics tools
Is is normal that access and conversion numbers that are reported on testing tools and analytics tools do not match. There are many reasons for that being, but some are:
- The differences on how testing and analytics software register visitors, unique sessions and conversion events;
- Errors when implementing the tools;
- Time to load the scripts.
One way to reduce the difference between reports is to use the analytics tool as a test reporting panel and send all testing data to it.
Commercial bias for testing tools
The value proposition offered by most testing tools is that researcher do not need to know statistics to perform tests. To accomplish this, providers assume default values for some variables like beta (and by extension its compliment, statistical power) or if the test have one or two tails. It can be the case that the researcher don’t need to know anything about statistics to perform tests and is capable to use such tools. The problem with that is that the researcher won’t be able to question the results or if they apply to the needs of the business. As seen on the introductory post for this series, getting to know some topics within the field of statistics can enrich the analysis of a test.
Further reading
- How to perform multiple tests simultaneously.
Let’s optimize conversions!


This website template has been designed by Free Website Templates for you, for free. You can replace all this text with your own text. You can remove any link to our website from this website template, you're free to use this website template without linking back to us. If you're having problems editing this website template, then don't hesitate to ask for help on the Forums.
Read MoreThis website template has been designed by Free Website Templates for you, for free. You can replace all this text with your own text. You can remove any link to our website from this website template, you're free to use this website template without linking back to us. If you're having problems editing this website template, then don't hesitate to ask for help on the Forums.
Read MoreThis website template has been designed by Free Website Templates for you, for free. You can replace all this text with your own text. You can remove any link to our website from this website template, you're free to use this website template without linking back to us. If you're having problems editing this website template, then don't hesitate to ask for help on the Forums.
Read MoreDonec odio nunc, consectetur fringilla tincidunt nec, cursus vitae ipsum.
Read MoreDonec odio nunc, consectetur fringilla tincidunt nec, cursus vitae ipsum.
Read MoreDonec odio nunc, consectetur fringilla tincidunt nec, cursus vitae ipsum.
Read More


Deputies chase Farmerville woman on land and water
by KNOEUNION PARISH, La. (KNOE) - A Union Parish woman is accused of leading law enforcement on a car chase Wednesday then ditching her car to escape by jumping in D’Arbonne Lake. Deputies say she was also caught with over seven grams of meth, which she said did not belong to her.
According to Johnny Gunter, media liaison for the Union Parish Sheriff's Office, it happened like this:
Two Union Parish sheriff’s deputies patrolling Pint Road near La. Hwy. 15 got behind a vehicle that suddenly accelerated to 60 mph. The deputies reported that the driver did not stop at the stop sign at Pleasure Island Road and started traveling at a much higher speed.
Sheriff Dusty Gates said that before the vehicle reached La. Hwy. 15, it ran off Pleasure Island Road, traveled across private property before hitting a guard rail in an attempt to get on Hwy. 15.
The driver, later identified as Cecelia A. Moore, 23, of 309 Pint Rd., Farmerville, exited the vehicle, ran to the lake, jumped in and started swimming.
Gates said the deputies then called for another deputy to bring a sheriff’s department boat to the location. A deputy and a Department of Wildlife and Fisheries’ agent retrieved Moore from the lake.
“As soon as they pulled her from the water she immediately stated “’those drugs aren’t mine,’” the sheriff said.
A search of the vehicle turned up 7.7 grams of methamphetamine, 5.7 grams of marijuana, two blunts containing suspected marijuana and two Clonazpam pills.
Moore and her passenger, Hayward Kyle Crenshaw, 28, of 131 Swartz School Rd., Monroe, were arrested. Crenshaw also denied ownership of the drugs found in the car.
Both were charged with a misdemeanor count of possession of marijuana and felony counts of possession of meth and Clonazpam and possession with intent to distribute meth.
Moore was additionally booked into the Union Parish Detention Center for aggravated flight from an officer, a felony, illegal lane usage and two misdemeanor counts of resisting arrest.
Bail had not been set Thursday.


Environment Collector API¶
-
class
sphinx.environment.collectors.
EnvironmentCollector
[source]¶ An EnvironmentCollector is a specific data collector from each document.
It gathers data and stores
BuildEnvironment
as a database. Examples of specific data would be images, download files, section titles, metadatas, index entries and toctrees, etc.-
clear_doc
(app, env, docname)[source]¶ Remove specified data of a document.
This method is called on the removal of the document.
-
get_outdated_docs
(app, env, added, changed, removed)[source]¶ Return a list of docnames to re-read.
This methods is called before reading the documents.
-
get_updated_docs
(app, env)[source]¶ Return a list of docnames to re-read.
This methods is called after reading the whole of documents (experimental).
-


This is the official TCD Badminton website. Here you can find everything you need to know about our fantastic club and catch up on all the exciting things that are happening within the club.
The TCD Badminton Club is a long standing member of the Dublin University Central Athletic Club (DUCAC) which is the governing body for sport clubs at Trinity College Dublin. We cater for every level of player and the club has enjoyed a rich history of success both on and off the court.
Over the course of 2016/2017 our new dedicated committee will be aiming to ensure all aspects of the club build upon the success of recent years.
The new club year kicks off in Freshers week where our committee members will be on hand in front square to sign you (new and returning students/staff/alumni) up to the club. We'll add you to our mailing list to keep you up to date with important notices about the club and events happening throughout the year.
You should also like our Facebook page and join the official TCD Badminton group to keep up to date with all the exciting things that are happening.
Freshers Week (19th - 23rd September 2016)
We will have a stand in Front Square during Freshers week. Feel free to drop by to join up or have a chat!
Every Wednesday
Social badminton is back! Every Wednesday come and join us for some laid back fun. All ability levels welcome.


Student registration form
Name
father name
postal address
personal address
sex
male
female
city
select
delhi
noida
gr. noida
course
select
b.tech
bba
mba
district
select
noida sec. 18
noida sec. 15
noida sec.16
state
select
new delhi
u.p
haryana
PinCode
Email id
DOB
Mobileno


{% extends 'base.html' %} {% load static %} {% block content %} {% include 'menu.html' %} Create an account {% if form.errors %} {% for key, value in form.errors.items %} {% for error in value %} {{ error }} {% endfor %} {% endfor %} {% endif %} {% csrf_token %} {{ form.firstName }} First Name*: {{ form.lastName }} Last Name*: {{ form.username }} Username*: {{ form.email }} E-mail Address*: {{ form.emailConfirm }} Confirm E-mail Address*: {{ form.password }} Password*: {{ form.passwordConfirm }} Confirm Password*: I want to receive news about ARKLIS I agree to the website Terms of Use and Privacy Policy* Create new account I have an account Login to your account {% include 'footer.html' %} {% endblock %}
{{ error }}
I want to receive news about ARKLIS
I agree to the website Terms of Use and Privacy Policy*


--- layout: page status: publish published: false title: Canyon Country (CCP) author: display_name: Zach Beck login: Zach Beck email<EMAIL_ADDRESS>url: '' author_login: Zach Beck author_email<EMAIL_ADDRESS>wordpress_id: 2595 wordpress_url: http://gis.utah.gov/?page_id=2595 date: '2011-09-19 10:46:11 -0600' date_gmt: '2011-09-19 16:46:11 -0600' categories: [] tags: [] ---
The Canyon Country Partnership Geographic Data Committee (CCP) was the first chartered user group in Utah. The members of the group created the Utah Transportation Model and the first Hydrology Model. The group consists of Geo-spatial technicians and specialists from State and Federal Agencies, private organizations, Carbon, Emery, Wayne, Grand, and San Juan Counties. It is open to anyone that would like to attend. CCP is active in sitting standards for the GIS community of Utah. For more information contact ...


Package-level declarations
Types
Link copied to clipboard
Link copied to clipboard
Class representing Google Pay payment capabilities
Link copied to clipboard
PaymentMethodNonce representing a Google Pay card.
Link copied to clipboard
Used to create and tokenize Google Pay payment methods.
Link copied to clipboard
Error class thrown when a Google Pay exception is encountered.
Link copied to clipboard
Callback for receiving result of getTokenizationParameters
Link copied to clipboard
interface GooglePayIsReadyToPayCallback
Callback for receiving result of isReadyToPay and isReadyToPay.
Link copied to clipboard
interface GooglePayListener
Implement this interface to receive results from the Google Pay flow.
Link copied to clipboard
interface GooglePayOnActivityResultCallback
Callback for receiving result of onActivityResult.
Link copied to clipboard
Represents the parameters that are needed to use the Google Pay API.
Link copied to clipboard
interface GooglePayRequestPaymentCallback
Callback for receiving result of requestPayment.
Link copied to clipboard
Optional parameters to use when checking whether Google Pay is supported and set up on the customer's device.