Public documents on the W3C site are provided by the copyright holders under the +following license. The software or Document Type Definitions (DTDs) associated with W3C +specifications are governed by the Software Notice. By +using and/or copying this document, or the W3C document from which this statement is +linked, you (the licensee) agree that you have read, understood, and will comply with the +following terms and conditions:
+ +Permission to use, copy, and distribute the contents of this document, or the W3C +document from which this statement is linked, in any medium for any purpose and without +fee or royalty is hereby granted, provided that you include the following on ALL +copies of the document, or portions thereof, that you use: + +
When space permits, inclusion of the full text of this NOTICE should be +provided. We request that authorship attribution be provided in any software, documents, +or other items or products that you create pursuant to the implementation of the contents +of this document, or any portion thereof.
+ +No right to create modifications or derivatives of W3C documents is granted pursuant to +this license. However, if additional requirements (documented in the Copyright FAQ) are satisfied, the right to create modifications or +derivatives is sometimes granted by the W3C to individuals complying with those +requirements.
+ +THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO +REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, +WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR +TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE +IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, +TRADEMARKS OR OTHER RIGHTS.
+ +COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL +DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE +CONTENTS THEREOF.
+ +The name and trademarks of copyright holders may NOT be used in advertising or +publicity pertaining to this document or its contents without specific, written prior +permission. Title to copyright in this document will at all times remain with copyright +holders.
+ +----------------------------------------------------------------------------
+ +This formulation of W3C's notice and license became active on April 05 1999 so as to +account for the treatment of DTDs, schema's and bindings. See the older formulation for the policy prior to +this date. Please see our Copyright FAQ for common questions +about using materials from our site, including specific terms and conditions for packages +like libwww, Amaya, and Jigsaw. Other questions about this notice can be directed to site-policy@w3.org.
+ + + webmaster+ Verify the capability to handle links to 'view' elements, and the + permissible attributes on those elements. All of the links in this + test case are internal, i.e., to 'view' elements in the same SVG file. +
++ This test is identical to linking-uri-02-b except that the links there are external. +
++ In the four quadrants of the initial picture are four graphical objects. + Clockwise from upper right, they are + a purple rectangle, blue ellipse, green polygon (pentagon), and yellow + circle. Each is labelled and tightly boxes with a rectangular frame. + These are identical to their counterparts in linking-uri-01-b.svg, in which + file each has an associated 'view' element, with attributes + per the labels in the initial picture. +
++ In the center is a gray box with four lines of text, each of which says + "Go to" followed by Rectangle, Ellipse, Polygon, and Circle, respectively. + Each of these is contained within an 'a' element, whose xlink:href names + the respective 'view' element of the respective graphical object. +
++ There are several reference images associated with this test case. The first + illustrates the correct initial state of the rendered SVG file, which should + also be the correct picture after the Rectangle link is executed. + The second, third, and fourth illustrate the correct images as described + above after respectively the Ellipse, Polygon, and Circle links are activated. + (Note. This harness does not yet provide access to multiple PNGs; the PNG for the + initial view is shown.) +
++ The test uses the 'rect', 'circle', 'ellipse', and 'polygon' elements, + as well as basic fill (solid simple colors), + stroke (black and colored 1-pixel lines), font-family (Arial) and font-size properties. +
++ In turn, activate each of the "Rectangle", "Ellipse", "Polygon" and "Circle" links + in the gray box in the middle of the document, navigating back (for example with + the Back button if in a browser) after activating each one. +
++ The test is passed if all of the sub-tests have the correct behavior: +
+Company | +Person | +Old Filename | +New Filename | ++ | |
Ericsson | +Mathias Larsson Carlander | +Mathias.Carlander@era.eri | +animation-add-BE-09 | +animate-elem-01-F | ++ |
Ericsson | +Mathias Larsson Carlander | +Mathias.Carlander@era.eri | +animation-inherit-BE-10 | +animate-elem-02-F | ++ |
Ericsson | +Mathias Larsson Carlander | +Mathias.Carlander@era.eri | +animation-motion-BE-11 | +animate-elem-03-F | ++ |
Ericsson | +Mathias Larsson Carlander | +Mathias.Carlander@era.eri | +animation-motion-BE-12 | +animate-elem-04-F | ++ |
Ericsson | +Mathias Larsson Carlander | +Mathias.Carlander@era.eri | +animation-values-BE-06 | +animate-elem-05-F | ++ |
Ericsson | +Mathias Larsson Carlander | +Mathias.Carlander@era.eri | +animation-values-BE-07 | +animate-elem-06-F | ++ |
Ericsson | +Mathias Larsson Carlander | +Mathias.Carlander@era.eri | +animation-values-BE-08 | +animate-elem-07-F | ++ |
KDDI | +Arei Kobayashi | +arei_kobayasi@jmserv.kbip. | +animation-overall-BE-01 | +animate-elem-09-F | ++ |
KDDI | +Arei Kobayashi | +arei_kobayasi@jmserv.kbip. | +animation-targAtt-BE-04 | +animate-elem-10-F | ++ |
KDDI | +Arei Kobayashi | +arei_kobayasi@jmserv.kbip. | +animation-targElt-BE-03 | +animate-elem-11-F | ++ |
KDDI | +Arei Kobayashi | +arei_kobayasi@jmserv.kbip. | +animation-timing-BE-05 | +animate-elem-12-F | ++ |
W3C | +Chris Lilley | +chris@w3.org | +animation-extRef-BE-13 | +animate-elem-13-F | ++ |
CSIRO Australia | +Dean Jackson | +dean.jackson@cmis.csiro.a | +color-colorProf-BE-03 | +color-prof-01-F | ++ |
CSIRO Australia | +Dean Jackson | +dean.jackson@cmis.csiro.a | +color-property-BE-02 | +color-prop-01-F | ++ |
Schema Software Inc. | +Philip Mansfield | +philipm@schemasoft.com | +color-datatypes-BE-01 | +color-prop-02-F | ++ |
ZoomON AB | +Ola Andersson | +ola.andersson@zoomon.co | +coords-transforms-BE-02 | +coords-trans-01-F | ++ |
ILOG | +Christophe Jolif | +cjolif@ilog.fr | +coords-unitsProc-BE-05 | +coords-units-01-F | ++ |
ZoomON AB | +Ola Andersson | +ola.andersson@zoomon.co | +coords-units-BE-01 | +coords-units-03-F | ++ |
ZoomON AB | +Ola Andersson | +ola.andersson@zoomon.co | +coords-unitsProc-BE-04 | +coords-units-02-F | ++ |
ZoomON AB | +Ola Andersson | +ola.andersson@zoomon.co | +coords-viewBox-BE-03 | +coords-viewattr-01-F | ++ |
W3C | +Chris Lilley | +chris@w3.org | +extend-multiNS-BE-01 | +extend-namespace-01-F | +|
Savage Software | +Mike Bultrowicz | +mbultrowicz@savagesoftwa | +filters-blend-BE-02 | +filters-blend-01-F | ++ |
Savage Software | +Mike Bultrowicz | +mbultrowicz@savagesoftwa | +filters-colorMtrx-BE-03 | +filters-color-01-F | ++ |
Savage Software | +Mike Bultrowicz | +mbultrowicz@savagesoftwa | +filters-composite-BE-05 | +filters-composite-01-F | ++ |
Savage Software | +Mike Bultrowicz | +mbultrowicz@savagesoftwa | +filters-transfer-BE-04 | +filters-comptran-01-F | ++ |
Savage Software | +Mike Bultrowicz | +mbultrowicz@savagesoftwa | +filters-convolve-BE-06 | +filters-conv-01-F | ++ |
Savage Software | +Mike Bultrowicz | +mbultrowicz@savagesoftwa | +filters-diffuseLt-BE-07 | +filters-diffuse-01-F | ++ |
Eastman Kodak | +Thomas DeWeese | +thomas.deweese@kodak.c | +filters-dispMap-BE-16 | +filters-displace-01-F | ++ |
Savage Software | +Mike Bultrowicz | +mbultrowicz@savagesoftwa | +filters-many-BE-01 | +filters-example-01-F | ++ |
AGFA | +Chris Tuijn | +chris.tuijn.ct@belgium.agfa. | +filters-feImage-BE-13 | +filters-image-01-F | ++ |
AGFA | +Chris Tuijn | +chris.tuijn.ct@belgium.agfa. | +filters-lights-BE-09 | +filters-light-01-F | ++ |
AGFA | +Chris Tuijn | +chris.tuijn.ct@belgium.agfa. | +filters-morph-BE-10 | +filters-morph-01-F | ++ |
Eastman Kodak | +Thomas DeWeese | +thomas.deweese@kodak.c | +filters-fldMrgOff-BE-15 | +filters-offset-01-F | ++ |
AGFA | +Chris Tuijn | +chris.tuijn.ct@belgium.agfa. | +filters-specularLt-BE-08 | +filters-specular-01-F | ++ |
AGFA | +Chris Tuijn | +chris.tuijn.ct@belgium.agfa. | +filters-feTile-BE-14 | +filters-tile-01-F | ++ |
AGFA | +Chris Tuijn | +chris.tuijn.ct@belgium.agfa. | +filters-turb-BE-11 | +filters-turb-01-F | ++ |
W3C | +Chris Lilley | +chris@w3.org | +fonts-fontElement-BE-01 | +fonts-elem-01-F | ++ |
AGFA | +Chris Tuijn | +chris.tuijn.ct@belgium.agfa. | +filters-blur-BE-12 | +filters-gauss-01-F | ++ |
Hewlett Packard | +Lee Klosterman | +lee_klosterman@hp.com | +interact-cursor-BE-08 | +interact-cursor-01-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +dom-eventListener-BE-04 | +interact-dom-01-F | ++ |
Hewlett Packard | +Lee Klosterman | +lee_klosterman@hp.com | +interact-onload-BE-07 | +interact-events-01-F | ++ |
Eastman Kodak | +Thomas DeWeese | +thomas.deweese@kodak.c | +interact-bubble-BE-04 | +interact-order-01-F | ++ |
Eastman Kodak | +Thomas DeWeese | +thomas.deweese@kodak.c | +interact-pEvents-BE-05 | +interact-pointer-01-F | ++ |
Eastman Kodak | +Thomas DeWeese | +thomas.deweese@kodak.c | +interact-pEvents-BE-06 | +interact-pointer-02-F | ++ |
Eastman Kodak | +Thomas DeWeese | +thomas.deweese@kodak.c | +interact-zoomPan-BE-01 | +interact-zoom-01-F | ++ |
Eastman Kodak | +Thomas DeWeese | +thomas.deweese@kodak.c | +interact-zoomPan-BE-02 | +interact-zoom-02-F | ++ |
Hewlett Packard | +Lee Klosterman | +lee_klosterman@hp.com | +linking-inBound-BE-03 | +linking-a-01-F | ++ |
Hewlett Packard | +Lee Klosterman | +lee_klosterman@hp.com | +linking-outBound-BE-01 | +linking-a-02-F | ++ |
Hewlett Packard | +Lee Klosterman | +lee_klosterman@hp.com | +linking-view-BE-04 | +linking-uri-01-F | ++ |
Hewlett Packard | +Lee Klosterman | +lee_klosterman@hp.com | +linking-view-BE-05 | +linking-uri-02-F | ++ |
Hewlett Packard | +Lee Klosterman | +lee_klosterman@hp.com | +linking-xlinkAttr-BE-02 | +linking-uri-03-F | ++ |
Openwave | +Charles Ying | +charles.ying@openwave.co | +masking-groupOpac-BE-04 | +masking-alpha-01-F | ++ |
Openwave | +Charles Ying | +charles.ying@openwave.co | +masking-mask-BE-05 | +masking-mask-01-F | ++ |
Openwave | +Charles Ying | +charles.ying@openwave.co | +masking-mask-BE-06 | +masking-mask-02-F | ++ |
Openwave | +Charles Ying | +charles.ying@openwave.co | +masking-property-BE-07 | +masking-opacity-01-F | ++ |
Openwave | +Charles Ying | +charles.ying@openwave.co | +masking-clipPath-BE-08 | +masking-path-01-F | ++ |
Canon | +Jun Fujisawa | +fujisawa.jun@canon.co.jp | +masking-clipPath-BE-01 | +masking-path-01-F | ++ |
Openwave | +Charles Ying | +charles.ying@openwave.co | +masking-clipRule-BE-03 | +masking-path-02-F | ++ |
Canon | +Jun Fujisawa | +fujisawa.jun@canon.co.jp | +masking-clipPath-BE-02 | +masking-path-02-F | ++ |
Openwave | +Charles Ying | +charles.ying@openwave.co | +masking-vportClip-BE-09 | +masking-path-03-F | ++ |
W3C | +Chris Lilley | +chris@w3.org | +metadata-sample-BE-01 | +metadata-example-01-F | +|
KDDI | +Arei Kobayashi | +arei_kobayasi@jmserv.kbip. | +animation-href-BE-02 | +naimate-elem-08-F | ++ |
Schema Software Inc. | +Philip Mansfield | +philipm@schemasoft.com | +paint-fill-BE-01 | +painting-fill-01-F | ++ |
Schema Software Inc. | +Philip Mansfield | +philipm@schemasoft.com | +paint-inherit-BE-06 | +painting-fill-02-F | ++ |
Schema Software Inc. | +Philip Mansfield | +philipm@schemasoft.com | +paint-markers-BE-03 | +painting-markers-01-F | +|
Schema Software Inc. | +Philip Mansfield | +philipm@schemasoft.com | +paint-markers-BE-04 | +painting-markers-02-F | +|
Schema Software Inc. | +Philip Mansfield | +philipm@schemasoft.com | +paint-colIntProp-BE-05 | +painting-render-01-F | ++ |
Schema Software Inc. | +Philip Mansfield | +philipm@schemasoft.com | +paint-stroke-BE-02 | +painting-stroke-01-F | ++ |
ILOG | +Christophe Jolif | +cjolif@ilog.fr | +path-curves-BE-02 | +paths-data-01-F | ++ |
ILOG | +Christophe Jolif | +cjolif@ilog.fr | +path-curves-BE-03 | +paths-data-02-F | ++ |
ILOG | +Christophe Jolif | +cjolif@ilog.fr | +path-curves-BE-04 | +paths-data-03-F | ++ |
ILOG | +Christophe Jolif | +cjolif@ilog.fr | +path-lines-BE-01 | +paths-data-04-F | ++ |
Canon | +Jun Fujisawa | +fujisawa.jun@canon.co.jp | +gradPatt-referenc-BE-08 | +pservers-grad-01-F | ++ |
Canon | +Jun Fujisawa | +fujisawa.jun@canon.co.jp | +gradPatt-stop-BE-06 | +pservers-grad-02-F | ++ |
Canon | +Jun Fujisawa | +fujisawa.jun@canon.co.jp | +gradPatt-stop-BE-10 | +pservers-grad-03-F | ++ |
Canon | +Jun Fujisawa | +fujisawa.jun@canon.co.jp | +gradPatt-transfrm-BE-09 | +pservers-grad-04-F | ++ |
CSIRO Australia | +Dean Jackson | +dean.jackson@cmis.csiro.a | +gradPatt-linearGr-BE-01 | +pservers-grad-05-F | ++ |
CSIRO Australia | +Dean Jackson | +dean.jackson@cmis.csiro.a | +gradPatt-linearGr-BE-02 | +pservers-grad-06-F | ++ |
CSIRO Australia | +Dean Jackson | +dean.jackson@cmis.csiro.a | +gradPatt-linearGr-BE-03 | +pservers-grad-07-F | ++ |
CSIRO Australia | +Dean Jackson | +dean.jackson@cmis.csiro.a | +gradPatt-radialGr-BE-04 | +pservers-grad-08-F | ++ |
CSIRO Australia | +Dean Jackson | +dean.jackson@cmis.csiro.a | +gradPatt-radialGr-BE-05 | +pservers-grad-09-F | ++ |
Canon | +Jun Fujisawa | +fujisawa.jun@canon.co.jp | +gradPatt-pattern-BE-07 | +pservers-pattern-01-F | ++ |
Corel | +Phil Armstrong | +phila@corel.com | +rendering-shape-BE-03 | +render-elems-01-F | ++ |
Corel | +Phil Armstrong | +phila@corel.com | +rendering-text-BE-02 | +render-elems-02-F | ++ |
KDDI | +Arei Kobayashi | +arei_kobayasi@jmserv.kbip. | +script-eventDom-BE-01 | +script-handle-01-F | ++ |
KDDI | +Arei Kobayashi | +arei_kobayasi@jmserv.kbip. | +script-uiEvents-BE-02 | +script-handle-02-F | ++ |
Nokia | +Tolga Capin | +tolga.capin@nokia.com | +shapes-circle-BE-03 | +shapes-circle-01-F | ++ |
ILOG | +Christophe Jolif | +cjolif@ilog.fr | +shapes-ellipse-BE-02 | +shapes-ellipse-01-F | ++ |
Nokia | +Tolga Capin | +tolga.capin@nokia.com | +shapes-line-BE-04 | +shapes-line-01-F | ++ |
Nokia | +Tolga Capin | +tolga.capin@nokia.com | +shapes-polygon-BE-05 | +shapes-polygon-01-F | ++ |
Nokia | +Tolga Capin | +tolga.capin@nokia.com | +shapes-polyline-BE-06 | +shapes-polyline-01-F | ++ |
ILOG | +Christophe Jolif | +cjolif@ilog.fr | +shapes-rect-BE-01 | +shapes-rect-01-F | ++ |
Bitflash | +Rick Graham | +rick@bitflash.com | +structure-switch-BE-07 | +struct-cond-01-F | ++ |
Bitflash | +Rick Graham | +rick@bitflash.com | +structure-lang-BE-08 | +struct-cond-02-F | ++ |
Corel | +Phil Armstrong | +phila@corel.com | +structure-defs-BE-04 | +struct-defs-01-F | ++ |
Bitflash | +Rick Graham | +rick@bitflash.com | +structure-extRef-BE-10 | +struct-defs-02-F | ++ |
W3C | +Chris Lilley | +chris@w3.org | +dom-svg-BE-02 | +struct-dom-01-F | ++ |
W3C | +Chris Lilley | +chris@w3.org | +dom-featureString-BE-03 | +struct-dom-02-F | ++ |
W3C | +Chris Lilley | +chris@w3.org | +dom-core-BE-01 | +struct-dom-03-F | ++ |
Corel | +Phil Armstrong | +phila@corel.com | +structure-empty-BE-01 | +struct-frag-01-F | ++ |
Corel | +Phil Armstrong | +phila@corel.com | +structure-basicG-BE-03 | +struct-group-01-F | ++ |
Corel | +Phil Armstrong | +phila@corel.com | +structure-nested-BE-02 | +struct-group-02-F | ++ |
Bitflash | +Rick Graham | +rick@bitflash.com | +structure-image-BE-06 | +struct-image-01-F | ++ |
Bitflash | +Rick Graham | +rick@bitflash.com | +structure-allElem-BE-09 | +struct-image-02-F | ++ |
Bitflash | +Rick Graham | +rick@bitflash.com | +structure-imggamma-BE-11 | +struct-image-03-F | ++ |
Bitflash | +Rick Graham | +rick@bitflash.com | +structure-symbol-BE-05 | +struct-symbol-01-F | ++ |
ZoomON AB | +Ola Andersson | +ola.andersson@zoomon.co | +style-selector-BE-01 | +styline-css-01-F | ++ |
ZoomON AB | +Ola Andersson | +ola.andersson@zoomon.co | +style-selector-BE-02 | +styline-css-02-F | ++ |
ZoomON AB | +Ola Andersson | +ola.andersson@zoomon.co | +style-selector-BE-03 | +styline-css-03-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +text-alignment-BE-10 | +text-align-01-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +text-textAnchor-BE-05 | +text-align-02-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +text-alignment-BE-11 | +text-align-03-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +text-altGlyph-BE-07 | +text-altglyph-01-F | ++ |
Adobe Systems Inc. | +Jon Ferraiolo | +jferraio@adobe.com | +text-decoration-BE-12 | +text-deco-01-F | ++ |
Adobe Systems Inc. | +Jon Ferraiolo | +jferraio@adobe.com | +text-font-BE-15 | +text-fonts-01-F | ++ |
Adobe Systems Inc. | +Jon Ferraiolo | +jferraio@adobe.com | +text-font-BE-16 | +text-fonts-02-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +text-i18n-BE-09 | +text-intro-01-F | ++ |
Nokia | +Tolga Capin | +tolga.capin@nokia.com | +text-textOnPath-BE-03 | +text-path-01-F | ++ |
Adobe Systems Inc. | +Jon Ferraiolo | +jferraio@adobe.com | +text-spacing-BE-14 | +text-spacing-01-F | ++ |
Adobe Systems Inc. | +Jon Ferraiolo | +jferraio@adobe.com | +text-textLength-BE-17 | +text-text-01-F | ++ |
Nokia | +Tolga Capin | +tolga.capin@nokia.com | +text-text-BE-01 | +text-text-02-F | ++ |
Adobe Systems Inc. | +Jon Ferraiolo | +jferraio@adobe.com | +text-extTref-BE-18 | +text-tref-01-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +text-tref-BE-04 | +text-tref-01-F | ++ |
Adobe Systems Inc. | +Jon Ferraiolo | +jferraio@adobe.com | +text-selection-BE-13 | +text-tselect-01-F | ++ |
Nokia | +Tolga Capin | +tolga.capin@nokia.com | +text-tspan-BE-02 | +text-tspan-01-F | ++ |
Sun Microsystems | +Vincent Hardy | +vincent.hardy@sun.com | +text-whiteSpace-BE-06 | +text-ws-01-F | ++ |
+ This tests the return value required for the + SVGAnimationElement.getStartTime() method, as described in + section 19.5 DOM Interfaces. +
++ After the loading the document, some animations that have no + visible effect will run. The text "Test running..." will + appear in the bottom right corner until the test has + completed. (This takes 2.5s.) +
++ The test is passed if all seven rectangles are green once the animations + have stopped running (i.e., 2.5s after the document has loaded.) +
++ This tests that the methods on the ElementTimeControl + interface return the undefined value, since the IDL + operations are declared to return void. +
++ After the loading the document, a rectangle is shown + indicating whether all four methods from the ElementTimeControl + interface returned undefined when invoked. The rectangle + is black if the test did not run, red if the test failed + and green if the test succeeded. +
++ Run the test. No interaction required. +
++ The test is passed if the rectangle is green. +
++ Test 'additive' and 'accumulate' attributes. +
++ The four pictures show the effect with the four possible combinations of + 'additive' (either 'replace' or 'sum') and 'accumulate' (either 'none' or 'sum'). + Because two animations are animating the height, the effects of 'additive' and + 'accumulate' are sometimes different than when there is only a single animation. +
++ Run the test. No interaction required. +
+The test has passed if the four green rectangles each animate their height according to the following:
+The leftmost rect:
+The next to leftmost rect:
+The next to rightmost rect:
+The rightmost rect:
++ Test inheritance of animated properties. +
++ Three colored text strings appear. All three are inside of the same + 'g' element. The 'g' element has its 'font-size' animated from 30 to + 40, and its 'fill' from #00f (blue) to #070 (green). +
++ The first colored 'text' element has the font-size set, so the + animation of the parent 'g' only affects the fill color. The second + has the fill set and font-size set, so no inherited values are + used. The font-size and fill color stay constant. The third colored + 'text' element has neither of these properties specified and thus + inherits both animated values - the fill color changes and the text + grows in size. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ Test different ways of defining a motion path. +
++ An animation moves a triangle along a path. Reference rectangles, lines and text + are provided to help show what the correct behavior is. +
++ This animation uses the 'from' and 'to' attributes to define the motion path. +
++ Run the test. No interaction required. +
++ The test has passed if a triangle is animated smoothly along the path indicated by the black line, starting at the leftmost pink rectangle and stopping after 3 seconds on top of the rightmost pink rectangle. +
++ Test different ways of defining a motion path. +
++ An animation moves a triangle along a path. Reference rectangles, lines and text + are provided to help show what the correct behavior is. +
++ This animation uses the 'values' attribute to define the motion path, with a linear calcMode. +
++ Run the test. No interaction required. +
++ The test has passed if a triangle is animated smoothly along the path indicated by the black line, and + it passes over the pink rectangles at the indicated times. + When the animation starts the triangle should be positioned on top of the leftmost pink rectangle, after + 3 seconds it should reach the middle pink rectangle, and after 6 seconds it should be positioned on top + of the rightmost pink rectangle where it should stop. +
++ Test different ways of defining a motion path. +
++ An animation moves a triangle along a path. Reference rectangles, lines and text + are provided to help show what the correct behavior is. +
++ This animation uses the 'path' attribute to define the motion path. +
++ Run the test. No interaction required. +
++ The test is passed if the triangle is animated along the black curve over the course of 6 seconds. +
++ Test different ways of defining a motion path. +
++ An animation moves a triangle along a path. Reference rectangles, lines and text + are provided to help show what the correct behavior is. +
++ This animation uses the 'mpath' sub-element to define the motion path. +
++ Run the test. No interaction required. +
++ The test is passed if the triangle is animated along the black curve over the course of 6 seconds. +
++ Test rotate='auto' and rotate='auto-reverse'. +
++ Two animations have been defined that move a triangle along a path. The first animation specifies rotate='auto', which causes + the object to be rotated along the curve of the path. The second animation specifies rotate='auto-reverse', which causes the + object to be flipped and then rotated along the curve of the path. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test possible values for 'calcMode="discrete"'. +
++ Two animations have been defined. For each animation, ruler lines and text are provided to help show what the correct behavior is. + The black text and ruler lines help show the sizes and movement of the rectangles over time. +
++ The discrete animations should show stair-stepping animations, with quantum-level jumps every two seconds in these tests. The linear + animations change constantly with each keyframe to keyframe section, with the result that the change is faster when there is a larger + change within a given amount of time. The paced animations change constantly over the entire animation, regardless of the values at + particular keyframes. For calcMode='spline' in this test case, the initial rate of change is defined to be the same as linear, but the + last jump has an ease-in/ease-out effect where the change is slower at the start and end but faster in the middle. +
++ Run the test. No interaction required. +
++ The test is passed if the two orange rects are animated so that the bottom part of each rectangle is at the position + indicated by the ruler lines at the particular time noted next to each ruler line. +
++ Test possible values for 'calcMode="linear"'. +
++ Two animations have been defined. For each animation, ruler lines and text are provided to help show what the correct behavior is. + The black text and ruler lines help show the sizes and movement of the rectangles over time. +
++ The linear animations change constantly with each keyframe to keyframe section, with the result that the change is faster when there is a larger + change within a given amount of time. +
++ Run the test. No interaction required. +
++ The test is passed if the two orange rects are animated so that the bottom part of each rectangle is at the position + indicated by the ruler lines at the particular time noted next to each ruler line. Between two noted times the + bottom part of each rect must be between the two corresponding ruler lines. +
++ Test possible values for 'calcMode="paced"'. +
++ Two animations have been defined. For each animation, ruler lines and text are provided to help show what the correct behavior is. + The black text and ruler lines help show the sizes and movement of the rectangles over time. +
++ The paced animations change constantly over the entire animation, regardless of the values at + particular keyframes. +
++ Run the test. No interaction required. +
++ The test is passed if the two orange rects are animated so that the bottom part of each rectangle is at the position indicated by the ruler lines at the particular time noted next to each ruler line. Between two noted times the bottom part of each rect must be between the two corresponding ruler lines. +
++ Test possible values for 'calcMode="spline"'. +
++ Two animations have been defined. For each animation, ruler lines and text are provided to help show what the correct behavior is. + The black text and ruler lines help show the sizes and movement of the rectangles over time. +
++ For calcMode='spline' in this test case, the initial rate of change is defined to be the same as linear, but the + last jump has an ease-in/ease-out effect where the change is slower at the start and end but faster in the middle. +
++ Run the test. No interaction required. +
++ The test is passed if the two orange rects are animated so that the bottom part of each rectangle is at the position indicated by the ruler lines at the particular time noted next to each ruler line. Between two noted times the bottom part of each rect must be between the two corresponding ruler lines. The bottom of the left rectangles and the right rectangle must always be the same throughout the animation. +
++ Test 'from', 'by', 'to' and 'values'. +
++ Six animations have been defined. All six animations define the same simultaneous behavior, but use different combinations of + attributes 'from', 'by', 'to' and 'values'. In all cases, from time 2 seconds to time 5 seconds, the rectangle should change + from a width of 30 to a width of 300. +
++ The text on each line shows the attributes that were used for that particular animation. +
++ Run the test. No interaction required. +
++ The six orange rectangles should simultaneously animate their widths so that their right edges line up with the ruler lines at the indicated time. + From time 0 - 2 seconds all rectangles should have their right edges lined up with the leftmost ruler line, and at time 2 seconds the animation should + start, changing the widths of all the rectangles from 30 to 300. At time 5 seconds the animation should stop and the rectangles should all line up with + the rightmost ruler line. +
++ Test 'calcMode'=discrete. +
++ One animation has been defined to animate the height of a rectangle. Ruler lines and text are provided + to help show what the correct behavior is. The headline text shows the values for the 'calcMode' and 'keyTimes' attributes. The + black text and ruler lines help show the size and movement of the rectangle over time. +
++ This test shows an animation with calcMode="discrete" (i.e., a jumping animation). +
++ Run the test. No interaction required. +
++ The right edge of the blue rectangle should line up with the ruler lines at the indicated times, and should jump directly to each position with no animation in between. +
++ Test 'calcMode'=paced. +
++ One animation has been defined to animate the width of a rectangle. Ruler lines and text are provided + to help show what the correct behavior is. The headline text shows the values for the 'calcMode' and 'keyTimes' attributes. The + black text and ruler lines help show the size and movement of the rectangle over time. +
++ This test shows calcMode="paced" for an animation that has constant velocity, thus showing how 'values' + and 'keyTimes' are ignored. +
++ Run the test. No interaction required. +
++ The blue rectangle should animate its width at a constant speed so that the right edge of the rectangle lines up with the ruler line at the indicated times. +
++ Test 'calcMode'=spline. +
++ One animation has been defined to animate the height of a rectangle. Ruler lines and text are provided + to help show what the correct behavior is. The red text shows the values for the 'calcMode' and 'keyTimes' attributes. The + black text and ruler lines help show the size and movement of the rectangle over time. +
++ This animation shows calcMode="spline". Between time 4 seconds and 8 seconds, the animation displays an ease-in/ease-out approach + instead of a constant linear approach which would have been the case if calcMode had been linear instead. +
++ Run the test. No interaction required. +
++ The blue rectangle should animate its width so that the right edge of the rectangle lines up with the ruler line at the indicated times. Between 4 and 8 seconds the animation should show an ease-in/ease-out motion (i.e. a gradual change in speed). +
++ Test 'calcMode'=linear. +
++ One animation has been defined to animate the width of a rectangle. Ruler lines and text are provided + to help show what the correct behavior is. The red text shows the values for the 'calcMode' and 'keyTimes' attributes. The + black text and ruler lines help show the size and movement of the rectangle over time. +
++ This test shows an animation with calcMode="linear". +
++ Run the test. No interaction required. +
++ The blue rectangle should animate its width so that the right edge of the rectangle lines up with the ruler line at the indicated times. The rate of change will increase after each ruler line is passed. +
++ Test hyperlinking rules as they relate to resolved start times. +
++ Click "fade in", wait 3 seconds. Click "fade out", wait 3 seconds. Click "fade in" again, wait 6 seconds. +
+The test is passed if:
++ Test for chained animations. +
++ The assumption is that you will first click on "fade in" and + then click on "fade out", each exactly once. The first time you + select the link 'fade in', you should see a blue square appearing, + gradually and smoothly fading from white to blue over the + course of three seconds. This square is in front of and thus + obscures the lower left circle, but is behind the upper right + circle. The fill color of these circles is also animated, from white to + grey. The animations are triggered by the start of the corresponding + animation of the blue square. +
++ With the second click on "fade in", however, the behavior might + be different. In the case of having a first click on "fade in", + waiting three seconds, and then immediately perform a first click + on "fade out", waiting three seconds, and then immediately perform + a second click on "fade in", you should see the following. After + the first click on "fade in", the blue square goes from white to blue. + After the first click on "fade out", the blue square goes + from blue to white. After the second click on "fade in", + however, the blue square goes from white to blue, and then + goes back from blue to white. This is because of the + hyperlinking rules as they relate to resolved start times in the + SMIL Animation specification. +
++ Click "fade in", wait 3 seconds. Click "fade out", wait 3 seconds. Click "fade in" again, wait 6 seconds. +
+The test is passed if:
++ Test which verifies that the basic facilities of declarative + animation are working. +
++ This test uses the following element : 'animate' +
++ The test is a nine second animation with no repeats. It shows + a rectangle growing from small (37.5% width, 33.3% height) to + big (100% width, 100% height) +
++ The file includes various guides that can be used to verify the + correctness of the animation. Outlines exist for the rectangle + size and location at times 0s, 3s and 9s. +
++ Run the test. No interaction required. +
+The test is passed if:
++ Test which verifies that the basic facilities of declarative + animation are working. +
++ This test uses the following elements : 'set', + and 'animateColor'. +
++ The test is a nine second animation with no repeats. It shows a circle + changing color from 3s to 9s. +
++ The file includes various guides that can be used to verify the + correctness of the animation. + Boxes on the left show the correct circle color values at times + 3s, 6s and 9s. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test which verifies that the basic facilities of declarative + animation are working. +
++ This test uses the following elements : 'animateMotion' and + 'animateTransform' +
++ The test is a nine second animation with no repeats. It shows + the text string "It's alive" moving, rotating and growing from + time 3s to 9s. +
++ Run the test. No interaction required. +
++ The file includes various guides that can be used to verify the + correctness of the animation. Pale blue guides exist for + the text size, location and orientation at times 3s, 6s and 9s. +
++ The test is passed if the animated text covers the pale blue guides at + the indicated times on the test. +
++ Test animation options for specifying the target attribute/property. +
++ The left-hand rectangle animates an XML attribute without + specifying a value for 'attributeType'. The right-hand rectangle + animates an XML attribute and does set 'attributeType' to 'XML'. +
++ The left rectangle animates its height from 100 to 50, + starting at time 3 seconds and ending at 6 seconds. + The right rectangle animates its height from 100 to 50, + starting at time 6 seconds and ending at 9 seconds. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test animation options for specifying the target attribute/property. +
++ On the left, a circle animates the stroke-width property without + specifying a value for 'attributeType'. On the right, + a circle animates the stroke-width property and does set 'attributeType' to 'CSS'. +
++ For each circle, guides shows what + the stroke-width looks like initially and + what it looks like at the end of the animation. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test animation options for specifying the target element. +
++ The leftmost rectangle verifies the use of the 'xlink:href' + attribute to indicate the target element to be animated. + The rightmost rectangle verifies animating the parent of + the 'animate' element (in this case, a 'rect' element) + (i.e., the implicit parent of the 'animate' element). +
++ At time 0, two rectangles filled with blue and stroked with + light blue appear, each with width=100 and height=160. Starting at + time 3 seconds and ending at time 6 seconds, the height of + the leftmost rectangle decreases from 160 to 40. Starting at + time 6 seconds and ending at time 9 seconds, the rightmost + rectangle decreases from 160 to 40. Annotations on the picture + show the correct positions at particular times. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test inheritance of animated properties. +
++ Run the test. No interaction required. +
++ A yellow happy face should be displayed. The stroke for the smile and + yellow circle are both animated, the stroke color fades from yellow to black. +
++ Test compositing of animated fill opacity. +
++ First click once on "fade in" and + then, once the animation has completed, click once on "fade out". +
+The first time you + select the link 'fade in', you should see a green square appearing, + gradually and smoothly fading from zero to 100% opacity over the + course of three seconds. This square is in front of and thus + obscures the lower left circle, but is behind the upper right + circle which is thus composited on top of the animated green + square. Then, when you click on "fade out", the green square will + gradually disappear, smoothly fading from 100% to zero opacity + over the course of three seconds. +
++ The rendered picture should match the reference image, (except + for possible variations in the labelling text (per CSS2 rules)) + after activating the link on the fade-in button the first time + and waiting three seconds for the animation to complete. The picture + should remain looking the same way indefinitely, until another + link is activated. +
+ ++ The purpose of this test is to test animated <use> where + the referenced <defs> also is animated. +
++ The test shows 6 different elements, each element defined in a + <defs> and referenced with a <use>. All the elements are + animated between 0-3 seconds. The expected animation transform is + indicated with a gray silhouette showing the border values (0 and 3 seconds) + and an arrow indicating the movement in between. + For the two elements with a color animation, the colors goes from white to + blue (the same blue color used for all elements). +
+Run the test. No interaction required.
+The test passes if:
++ The purpose of this test is to test animation of the display attribute. +
++ The test shows two gray rectangles which are filled with colored circles during the length of the animation (8 sec). + The circles in the top rectangle are displayed/hidden by animating the display attribute. + The circles in the bottom rectangle are serving as the reference and are displayed/hidden by animating the visibility attribute. + A correct implementation should display/hide circles with the same color from the top and bottom rectangle at the same time. +
++ In total there are 6 different circles (purple, green, dodgerblue, blue, yellow, cyan) in 5 positions (blue and yellow share position) that should be displayed during the test. +
++ Run the test. No interaction required. +
+While the test is running (which takes approximately 8 seconds), + the text "Test running" is shown. The test passes if:
++ Tests the animation to and from the degenerate cases of the basic shapes. + The shapes are drawn within the black rectangles. +
+Run the test. No interaction required.
+The test passes if within each of the 11 rectangles an animated shape + is shown over the first six seconds and that after the six seconds, at the + end of the animation, each of these rectangles is empty.
++ The purpose of this test is to test animateMotion with keyPoints and keyTimes. +
++ The test consists of 4 sub-tests. Each test has a purple circle which moves along a path. The path is indicated with a dashed line and sample points where the circle should pass a certain position on the path is indicated with gray circles. On top of each gray circle is a number which indicates the passing time in seconds. In the cases where the purple circle should pass the gray circle two times the first passing time is written above the gray circle and the second passing time is written below. +
++ Section 19.2.12 in the spec. states that a motion path is defined by the path attribute or by values or from/to attributes. So in the animateMotion case, values is just used for defining the motionPath and the number of values do not have to relate to the number of keyTimes. +
+Run the test. No interaction required.
+The test passes if, for the first four seconds of the document, + each of the four purple circles moves along the dashed lines + such that they coincide with the gray circles at the times indicated + next to those gray circles. The purple circles must all move continuously + over the four seconds, except for the top-right one, which + jumps discontinuously at 2s from the second grey circle to + the third in that subtest.
+If a range of times is given next to a grey circle, then the purple + circle must stay stationary at that position for that duration.
++ The purpose of this test is to test animation of attributes points and fill-rule. +
++ The test consists of 2 sub-tests. The first test is a polygon shaped as a digit. The polygon + has an animation on its vertex points which morphs the polygon between the numbers 1, 2, 3 + and 4. The gray outlines indicates the expected position of the polygon at 1, 2, 3 and 4s. + The second test is 4 paths in a u-shape. They have animated fill-rules. Their initial + fill-rules are, from left to right, nonzero, evenodd, nonzero (by default value, no fill-rule attribute set) + and nonzero (by default value, no fill-rule attribute set). This means, that the second path is + initially u-shaped, and all other paths are initially rect-shaped. All four animations are set to evenodd as a last stage. + The further expected result is that one path at a time is filled. The other three paths are not filled but have the u-shape. + The fourth animation from evenodd to nonzero happens by going back to the initial state, + because the fill attribute is not set to freeze. Which path that should be filled at + which time is indicated by the number above it (indicating time in seconds). To enhance the + difference between the filled path and the rest, the filled path should always have the + same color as the morphing polygon. This is achieved by a discrete color animation. +
+Run the test. No interaction required.
+The test is passed if all of the following conditions are met:
++ The purpose of this test is to test animation of attributes stroke-dasharray, + stroke-dashoffset, stroke-miterlimit, stroke-linecap and stroke-linjoin. +
+ ++ This file contains four tests, testing animation of five attributes. + The first test animates the stroke-dashoffset. There are seven reference polylines, all with + the same stroke-dasharray but with different values on their stroke-dashoffset. A red polyline + with the same stroke-dash array has an animation on its stroke-dasharray. The red polyline is + animated so that it stops by the reference polyline that has the right stroke-dashoffset at + that perticular time. + The second test animates stroke-linecap and stroke-linejoin. There are three reference + polylines. Comparsion is done in the same manner as in the previous test. + The third test animates the stroke-miterlimit. There are two sets offilled reference paths + (black) and two outlined paths (red) with animated stroke-miterlimit. The paths are shaped like + a capital A. In the upper test the animated path is drawn on top of the reference polygons and + in the lower test the reference path is drawn on top of the animated path. As the + stroke-miterlimit is animated to different values, different reference paths are used. To pass + the test, there should never be any part of the underlying geometry visible (black in the upper + or red in the lower). + The fourth test animates the stroke-dasharray. The initial stroke-dasharray gives a + short-dashed line. This pattern is animated into a pattern that on this short path gives a + solid line at 2 seconds. +
++ [[Describe the pass criteria of the test here. The pass criteria is what + should be displayed when the test is run.]] +
++ This test validates the animation of the transform attribute on structure + elements, hyperlinks and text elements. +
++ The test applies an <animateTransform> on various element types: <g>, + <use>, <image>, <switch>, <a> and <text>. In all + cases, the type is a rotation and all the elements should rotate together about + their centers, for 3s, starting at the document's load time. +
+Run the test. No interaction required.
+The test passes if each of the seven flower-like shapes (the four above "<use>" + and the ones above "<g>", "<switch>" and "<a>"), the image and + the text "123" rotate clockwise, then anti-clockwise, then clockwise again, + over the course of a few seconds.
+The static reference image shows the final state of the animation.
++ This test validates the animation of the transform attribute shape elements. +
++ The test applies an <animateTransform> on various element + types: <g>, <use>, <image>, <switch>, + <a> and <text>. + In all cases the animation should run for 3s, starting at the document's load time. + The <circle> has a scale animation, and all the rest of the elements should rotate together about their centers. +
+Run the test. No interaction required.
+The test passes if:
+over the course of three seconds.
+The static reference image shows the final state of the animation.
++ The purpose of this test is to test animation of the viewBox attribute. +
++ Run the test. No interaction required +
++ The viewBox changes position and size + several times. At each new setting, a green indicator frame will flash a couple of times. + This frame must only appear at the edges of the SVG element. +
++ This test validates that the xlink:href attribute can be animated on + the <a>, <image> and <use> elements, using the <animate> + or <set> animation elements. +
++ For the <a> animation, showing on the left-most column, the number + indicates the number of the animation test currently linked by the xlink:href + attribute. For example, when the xlink:href animated value is "animate-elem-38-t.svg", + the text displays "38". When the user clicks on the displayed number, the user + agent should open the corresponding link. For example, if the user clicks on 38, + then the "animate-elem-38-t.svg" URI should be followed. If the user clicks on 02, + then the "animate-elem-02-t.svg" URI should be followed. +
++ For the <image> animations, the image xlink:href attribute cycles through + two values showing a sun set and a picture of the sydney opera. The image should + change every second and the images shown by the <set> and <animate> + animations should always match. +
++ For the <use> animations, the use xlink:href attribute cycles through + values "#useA" and "#useB" which reference text elements displaying values + "Use A" and "Use B". The change should happen every second and the text shown + for the two animations (<set> and <animation>) should always + match. +
+Run the test. Note each of the six subtests alternating (using animation) + between two states. (The pass criteria indicate what must be shown for + each of these.) Click on the top circle while it is showing "02": the + test animate-elem-02-t should be loaded. Go back, then click on the circle + again while it is showing "38": the test animate-elem-38-t should be + loaded. Go back again, then click on the bottom circle while it is showing + "03": the test animate-elem-03-t should be loaded. Go back again, then + click on the bottom circle while it is showing "09": the test animate-elem-09-t + should be loaded.
+Every one second, the document alternates between two states. In the first + state, the top circle shows the number "02", the bottom circle shows "03", + the two images show a picture of the Sydney Opera House, and the two 'use' + elements show the text "Use A". In the second state, the top circle shows + the number "38", the bottom circle shows "09", the two images show a + picture of some water and land, and the two 'use' elements show the text "Use B".
+The test passes if the document does alternate between these two states, + and that clicking on the circles produces the behavior described in the operator + script.
++ This test validates that the x and y attributes can be animated on + <use>, <image>, <rect> and <text> elements. + The test also validates that the width and height attributes can + be animated on <image> and <rect> +
++ For x and y animation, each test shows the reference positions at + specific points in the animation. These markers are highlighted + at the time the target element's x/y position should match that of + the marker. For the <text> element, there are two tests. The + first one tests animating a single value on the text's x and y attributes. + The second one tests animating x, y values where there are values for each + of the text's characters. For that test (bottom left), there is a set of + reference markers for each of the characters ('1' and '2'). +
++ For width and height animation (the two tests on the bottom right), the + outline showing the expected width and height at given points in the animation + is highlighted at the time the marker's width and height should match that + of the target element. +
+Run the test. No interaction required.
+Over the course of four seconds, the positions and sizes of elements + within the document are animated. The test passes if the following + conditions are met:
++ This test validates the operation of the animate element on the various graphics + properties. This test is very similar to animate-elem-78-t which uses the set element + instead of the animate element to modify graphics properties. +
++ For each of the graphics properties, there are three tests. One animates the graphics + property directly on an element (such as a rect or a line) which uses the + property. The other two tests apply the animation on a container element (g and + a), and validate that the animated property is inherited by elements which + are child of the container. +
+Run the test. No interaction required.
++ There are 11 graphics properties that are animated, and for each of these, + they are animated in one of three different ways (the three columns). The + three animations in each row must be the same. +
++ For each animation test, the element on which the animation is applied is also + translated by an animation so that the various states of the animation can + be checked more easily: +
++ The following animations must show continuous changes: fill, stroke, + stroke-width, stroke-dashoffset and color. +
++ The following animations must show discrete animation changes: fill-rule, stroke-linecap, + stroke-linejoin, stroke-miterlimit, display and visibility. The point at which + the change takes place must be half way through the animation, except for the + stroke-miter animation, which must change a quarter of the way through. + (Note that visually, stroke-miterlimit shows a sharp transition even though its value + is animated continuously, but that is because the miter is cut off when + the animated miter limit reaches the test sharp angle's miter value.) +
+The test passes if all of the above criteria are met.
++ The purpose of this test is to test animation of the d + attribute of the path element. +
++ This test consists of a path, specified as a series of + lineto commands, whose d attribute is animated. + The path morphs between the numbers 1, 2, 3, and 4. + The gray outlines indicates the expected position of the polygon at 1, 2, 3 and 4s. + The test contains an animated circle that indicates where + the path should be at a given time. +
+Run the test. No interaction required.
+The test is passed if all of the following conditions are met:
++ This test validates the operation of the animate element on the various + text and font properties. This test is very similar to animate-elem-77-t.svg + which uses the set element instead of the animate element to modify graphics + properties. +
++ For each text or font properties, there are three tests. One animates the text or font + property directly on a text element which uses the + property. The other two tests apply the animation on a container element (g and + a), and validate that the animated property is inherited by children text elements. +
++ For each animation test, the element on which the animation is applied is also + translated by an animation so that the various states of the animation can + be checked more easily. There is a gray reference marker which shows + the expected animation state at the begining of the animation, mid-way, or at the + end of the animation. +
+Run the test. No interaction required.
++ There are 5 text properties that are animated, and for each of these, + they are animated in one of three different ways (the three columns). The + three animations in each row must be the same. +
++ For each animation test, the element on which the animation is applied is also + translated by an animation so that the various states of the animation can + be checked more easily. Each test has three gray silhouettes, showing the size + and shape that the "A" must have at the start, middle and end of the animation. +
++ The animation of font-size must show a continuous change of the font size. +
++ The following animations must animate discretely: text-anchor, font-family, + font-style, font-weight. +
++ The test passes if all of the above conditions are met. +
++ The purpose of this test is to test eventbase targets. +
++ The test consists of 4 rectangles named A, B, C, D. The D rectangle contains + three animations changing the color of the animation target. + Each animation applies to one of the other rectangles + by using xlink:href. Clicking on rect A should change it's + color immediately, clicking B changes its color after 2 seconds, + clicking C changes its color after 4 seconds and clicking D shows no visible change + (although D contains the animations the event target for each + animation is the referenced rectangle, this rectangle is also the + animation target.) +
++ The following sections in the SMIL Animation spec (http://www.w3.org/TR/smil-animation/) + are relevant as confirmation of this test: + The SMIL spec(3.6.7 subsection "Event Values") states that "If the + Eventbase-element term is missing, the event-base element is defined to + be the target element of the animation" + The SMIL spec (3.1 subsection "The target element") says that the + animation target may be defined explicitly thru the targetElement IDREF + or href URI. + So in this test, the animation target is defined through + xlink:href and the event base per definition is then also this + referenced element. +
+Run the test. Click on each of the four blue rectangles from left to right.
+The test passes if all of the following conditions are met:
++ The purpose of this test is to test animation of points and calcmode. +
+ ++ 1. The green squares should animate together side by side. This applies + to the blue ones as well. + 2. The time values indicate when the squares should reach the + corresponding reference square. + 3. The total distance is 0+40+80+24.14=144.14 + a. The "green animation" is 9 sec and linear so each interval + should get 3 sec. + b. The "blue animation" is 8 sec and paced so the intervals + should get 2.22, 4.44 and 1.34 sec each. +
++ Here comes a more detailed description of the animation. + + The left green square (LG) is animated by animating the points with + a value array, consisting of 4 lists of points. This is an animation + with calc-mode=linear so an equal amount of time should be spent on + all 4 intervals. The right green square (RG) is animated by a simple + linear motion followed by a scale to follow LG. + The last scale by 1.9428 correspond to a movement of the lover right + corner of the square by sqrt((30*0.9428)^2 + (30*0.9428)^2) which is + approximately 40 distance units. This is the same distance as the first + interval in the values array (and half the second interval). + The length (in terms of distance) is not really important for the + green squares but for the blue squares which are animated with + calc-mode=paced the length is used to calculate the time for each + interval. + Since the first and last interval are of the same length which + totals to the length of the middle interval, the interval should + be given time according to [27.75%(2.22sec);55.5%(4.44sec);16.75%(1.34sec)]. + + So the left blue square (LR) is animated just as the LG square but + with calc-mode=paced. The same applies to the right blue square (RR) + that has default calc-mode (paced for animateMotion) compablue to the + RG square that has calc-mode=linear. + The calc-mode for the scale of RR (and RG) is not important since + it's not a value list type of animation. +
++ [[Describe the pass criteria of the test here. The pass criteria is what + should be displayed when the test is run.]] +
++ This test performs basic test on the begin attribute, + assuming support for the <set> element and setting the + fill attribute on a <rect> element. +
++ The test validates the various possibilities for the begin attribute + value: no specified value, offset value, event base value, sync base + value, indefinite value, repeat value, accessKey value and wallclock. +
++ There is one or several <set> elements for each of the possible begin + values. For each test, the <set> element(s) has (or have) an indefinite + duration and no other timing attribute specified other than begin + and dur. +
++ There are two sets of vertical markers which help check that the test + is handled properly by the user agent. The first set, on the left, shows + markers from 0s to 8s, where the times are offset from the document's load time. + The rectangles in that area should turn green at the time corresponding + to the column they are in. From example, the first rectangle (going left to right) + on the "sync base" line should turn green 2 seconds after the document's load. + The second set of time vertical markers shows offset from a particular event. + For example, for the event base, the markers show an offset to the time + the first event base rectangle (the left-most one) is clicked on. For the + accessKey line, the times show offsets from the time the 'a' key is pressed + and the document has focus. +
++ The first <set> has an unspecified begin attribute. That value + defaults to an offset of 0s so the animation should apply as soon as + the document is loaded. +
++ The second <set> has its begin attribute set to '2s'. So its + target rectangle should turn green two seconds after the document is + loaded. +
++ The third <set> has its begin attribute set to an event base + value 'click'. The user has to click on the left-most target red rectangle + to make the <set> target turn green. There are two rectangles + with associated <set> elements. The left most ones has a simple + value (no offset) and the second one is offset from the event time by 2 seconds. +
++ The fourth <set> elements have their begin attributes set to a sync base + value. The first two rectangles have <set> elements synchronized on their sync base + begin. The left-most one has no offset and the following one has a 2 seconds offset. + The last two rectangles have <set> elements synchronized on their sync base end. + The first one (i.e., the third from left to right on that line), has a 2 seconds + negative offset. The second one (i.e., the last one on the line) has no offset and should + begin at the time its sync base ends. +
++ The fifth <set> has its begin attribute set to indefinite and + should not turn red and stay green. +
++ The sixth <set>s have their begin attributes have their begin attributes + based on the repeat() function. The repeat they are synchronized on happens + at 3s. The first <set>, which has no offset, should begin at 3s. The + second <set>, which has a 2 seconds offset, should start at 5s. +
++ The seventh <set>s have their begin attributes set to 'accessKey(a)'. + The first one has no offset and should become active (and turn the rectangle + green), as soon as the key 'a' is pressed in the user agent. The second <set> + has a 2s offset and should become active 2 seconds after the 'a' key is pressed in + the user agent. +
++ The eight's <set> target has its begin attribute set to + 'wallclock()'. Therefore, the target should turn red because the + target wallclock time is in the past. The SMIL specification states the following about wallclock values in the past: + "When a begin time is resolved to be in the past (i.e., before the current presentation time), the element begins immediately, + but acts as though it had begun at the specified time (playing from an offset into the media)." (http://www.w3.org/TR/2001/REC-smil-animation-20010904/#AnimFuncTiming). +
+Run the test. Observe the document for at least eight seconds. + Then, click on the first red square in the "event base" row, + and observe the document for two seconds. Then, press "a" + on the keyboard, and observe the document for another two seconds.
+The test passes if the following conditions are met:
++ This tests validates multiple begin conditions in the begin attribute, + assuming support for the <set> element and setting the + fill attribute on a <rect> element. +
++ The test validates the various possibilities for the begin attribute + value: multiple offset values, multiple event base values, multiple sync base + values, multiple repeat values, and multiple accessKey values. Finally, + the test validates that begin values of different kinds can be mixed. +
++ The test shows 6 rows where a red rectangle' s x attribute is animated + with <set> elements. +
++ On the first three rows, the red rectangles should show on the left from + 0 to 1s. From 1 to 2s, the rectangles should show on the right. Then + the rectangles should show on the left from 2 to 4s, then on the right + again from 4 to 5s and come back to the left position and stay there + after 5s. +
++ On the fourth row, the rectangle's begin condition is event based + and requires a user click. After the user clicks on the rectangle, + the rectangle should move to the right position for 1s, then move + back to the left position for 3 seconds, move again to the right + position for 1 second before going back to the left position. +
++ On the fifth row, the rectangle's begin condition is accessKey based + and requires a user to press the 'a' key. After the user presses that key + the rectangle should move to the right position for 1s, then move + back to the left position for 3 seconds, move again to the right + position for 1 second before going back to the left position. +
++ The last row's rectangle has a begin condition with two offset values + (1s;4s) and should behave like the rectangles of the first three + rows for the first 5 seconds of the document's timeline. In addition, + the begin condition has a click event base and thus, the rectangle + should move to the right position for one second every time the user + clicks on it. Finally, the begin condition also has an accessKey condition + for the 'b' character. Thus, the rectangle should move to the right + position every time the user presses the 'b' key. +
+Run the test. Observe the document for a least six seconds. + Then, click on the left square in the "2 event base" row and + wait for another six seconds while observing. Then, press "a" + on the keyboard and wait for another six seconds while observing.
+The test passes if all of the following conditions are met:
++ This test performs basic test on the end attribute, + assuming support for the <set> element and setting the + fill attribute on a <rect> element. +
++ The test validates the various possibilities for the end attribute + value: no specified value, offset value, event base value, sync base + value, indefinite value, repeat value, accessKey value and wallclock. +
++ There are one or several <set> elements for each of the possible end + values. For each test, the <set> element(s) has (or have) an indefinite + duration and no other timing attribute specified other than end + and dur. +
++ There are two sets of vertical markers which help check that the test + is handled properly by the user agent. The first set, on the left, shows + markers from 0s to 8s, where the times are offset from the document's load time. + The rectangles in that area should turn green at the time corresponding + to the column they are in. From example, the first rectangle (going left to right) + on the "sync base" line should turn green 2 seconds after the document's load. + The second set of time vertical markers shows offset from a particular event. + For example, for the event base, the markers show an offset to the time + the first event base rectangle (the left-most one) is clicked on. For the + accessKey line, the times show offsets from the time the 'a' key is pressed + and the document has focus. +
++ The first <set> has no end attribute and an indefinite duration. + Since there are no constraints on the active duration (no end attribute) the + active duration is the same as the simple duration (indefinite). This + means that the animation begins at 0s and has an indefinite end time. +
++ The second <set> has its end attribute set to '2s'. So its + target rectangle should turn green two seconds after the document is + loaded. +
++ The third <set> has its end attribute set to an event base + value 'click'. The user has to click on the left-most target red rectangle + to make the <set> target turn green. There are two rectangles + with associated <set> elements. The left most ones has a simple + value (no offset) and the second one is offset from the event time by 2 seconds. +
++ The fourth <set> elements have their end attributes set to a sync base + value. The first two rectangles have <set> elements synchronized on their sync base + end. The left-most one has no offset and the following one has a 2 seconds offset. + The last two rectangles have <set> elements synchronized on their sync base end. + The first one (i.e., the third from left to right on that line), has a 2 seconds + negative offset. The second one (i.e., the last one on the line) has no offset and should + end at the time its sync base ends. +
++ The fifth <set> has its end attribute set to indefinite and + should not turn red and stay green. +
++ The sixth <set>s have their end attributes have their end attributes + based on the repeat() function. The repeat they are synchronized on happens + at 3s. The first <set>, which has no offset, should end at 3s. The + second <set>, which has a 2 seconds offset, should start at 5s. +
++ The seventh <set>s have their end attributes set to 'accessKey(a)'. + The first one has no offset and should become active (and turn the rectangle + green), as soon as the key 'a' is pressed in the user agent. The second <set> + has a 2s offset and should become active 2 seconds after the 'a' key is pressed in + the user agent. +
++ The eight's <set> target has its end attribute set to + 'wallclock()'. The result depends on the presentation time. + If the document is viewed completely before 2200-06-10T12:34:56Z, + the rectangle has to be always green. begin is not explicitely set, therefore + it is zero, dur is indefinite and end is in the future. + If the document is viewed completely after 2200-06-10T12:34:56Z, the only end + value is before the implicitely given only begin value and therefore the set + does not start, the rectangle remains red. If the document is viewed in a time interval started before + 2200-06-10T12:34:56Z and ended after this date, the rectangle will start green at the beginning, change to red at + 2200-06-10T12:34:56Z and will remain red until the end of presentation. +
+Run the test. Observe the document for at least eight seconds. + Then, click on the first red square in the "event base" row, + and observe the document for two seconds. Then, press "a" + on the keyboard, and observe the document for another two seconds.
+The test passes if the following conditions are met:
++ This tests validates multiple end conditions in the end attribute, + assuming support for the <set> element and setting the + dur attribute to 'indefinite'. +
++ The test validates the various possibilities for the end attribute + value: multiple offset values, multiple event base values, multiple sync base + values, multiple repeat values, and multiple accessKey values. Finally, + the test validates that end values of different kinds can be mixed. +
++ The test shows 6 rows where a red rectangle's x attribute is animated + with <set> elements. +
++ On the first three rows, the red rectangles should show on the left from + 0 to 1s. From 1 to 2s, the rectangles should show on the right. Then + the rectangles should show on the left from 2 to 4s, then on the right + again from 4 to 5s and come back to the left position and stay there + after 5s. +
++ On the fourth row, the rectangle's end condition is event based + and requires a user click. One of the end condition is defined + to be 5 seconds prior to the click and one is defined to be 5 + seconds after the click. If the user clicks on the rectangle + before 5 seconds (in document time), the red rectangle we move + to the left position 5 seconds after the click (because the + 'click - 5s' end time resolves to a time prior to the begin + time). If the user clicks after 5 seconds (in document time), + then the red rectangle moves to the left position immediately because + the 'click - 5s' time resolves to a time after the begin time. +
++ On the fifth row, the rectangle's end condition is accessKey based + and requires a user to press the 'a' key. The behavior is exactly the + same as for the previous row, except that the triggering event + is the 'a' key press. +
++ The last row's rectangle has a end condition with two offset values + (1s;4s) and should behave like the rectangles of the first three + rows for the first 5 seconds of the document's timeline. In addition, + the end condition has a click event base and thus, the rectangle + should immediately move to the left position if the user everytime the user + clicks clicks on the rectangle when it is on the right position. + Finally, the end condition also has an accessKey condition + for the 'b' character. Thus, the rectangle should move to the left + position every time the user presses the 'b' key and the rectangle is + on the right position. +
+Run the test. Observe the document for six seconds. + Then, click the red square in the "2 event base" row + and then press "a" on the keyboard.
+Next, reload the test. Before five seconds have elapsed, + click the red square in the "2 event base" row and then + press "a" on the keyboard. Observe the document for another six seconds.
+The test passes if the following conditions are met:
++ This tests performs basic tests on the dur attribute. +
++ The first row shows a red rectangle subject to a <set> animation + with no begin attribute, no end attribute and a dur attribute set to + '2s'. Therefore, the animation should be active from 0 to 2 seconds and + then terminate. Consequently, the rectangle should show on the right + for the first two seconds, and then move to the left position. +
++ The second row shows a red rectangle subject to a <set> animation + with no begin attribute, no end attribute and a dur attribute set to + 'indefinite'. Therefore, the animation should stay active indefinitely + and the rectangle should always be on the right position, never on the + left position. +
++ Finally, the third row shows red rectangle subject to a <set> animation + with no begin attribute, no end attribute and a dur attribute set to + 'media'. In the context of SVG 1.1, this is equivalent to an 'indefinite' + value. Therefore, the animation should stay active indefinitely + and the rectangle should always be on the right position, never on the + left position. +
+Run the test. No interaction required.
+The test passes if after three seconds, in each of the three rows, + the red rectangle is in the column at the times indicated. + Thus, from the document load until 2s afterwards, the red + square in the first row must be in the right column, + and after the 2s it must be in the left column. In the + other two rows, the red square must remain in the + right column.
++ This tests performs basic tests on the min attribute. The test is based + on the SMIL specification at: + http://www.w3.org/TR/smil20/smil-timing.html#Timing-MinMax. +
++ Each row in the test shows different rectangles subject to <set> + animations with different configurations with regards to the min + attribute. For each row but the last one, the animation should be active + during the first 5 seconds of the animations where the red rectangle + should show in the right column. At five seconds into the animation, + all the rectangles should move to their left position. +
++ On the first row, the first <set> animation (left rectangle) has an end value of 5s, + and no min attribute. The active duration resulting from the end attribute is 5s. + The first row shows a second rectangle with a <set> animation with + the same configuration except that the min attribute value is set to + 'media'. Because the <set> element does not define a media, the + behavior should be as if the attribute was not specified. The active duration (5s) + of the second <set> animation is therefore not constrained. +
++ On the second row, the <set> animation has an end value of 5s, + and a -6s min attribute. The active duration resulting from the end attribute is 5s. + The negative min value is invalid and, as per the specification, the behavior should be + as if the attribute was not specified. The active duration (5s) is therefore not constrained. +
++ On the third row, the <set> animation has an end value of 5s, + and a 3s min attribute. The active duration resulting from the end attribute is 5s. + The min value is less than the active duration, so the min attribute does not actually + constrain the active duration. +
++ On the fourth row, the <set> animation has a dur value of indefinite, an end value of 2s, + and a 5s min attribute. The active duration resulting from the end attribute would be 2s. + Because this is less than the min value (2s < 5s) the (min constrained) active duration + has to be corrected to 5s, despite a simple duration (indefinite) that is greater than the min value. +
++ On the fifth row, the <set> animation has a dur value of 1s, an end value of 2s, + a repeatCount of 7 and a 5s min attribute. The active duration resulting from dur, end and repeatCount + would be 2s. Because this is less than the min value (2s < 5s) + the (min constrained) active duration has to be corrected to 5s. +
++ On the sixth row, the <set> animation has a dur value of 1s, an end + value of 2s, a repeatCount of 5 and a 8s min attribute value. + The active duration resulting from dur, end and repeatCount + would be 2s, because this is less than the min value (2s < 8s) + the active duration has to be corrected to 8s. As the + fill attribute is set to 'remove' on the <set> animation, this + remove is applied at 5s, the end of the repeatCount. + Note, that if the end of active duration would have been used as a + syncbase-value for another animation, the corrected end event at + (begin + min) = 8s has to be used. +
++ On the seventh row, the <set> animation has a dur value of 1s, an end + value of 2s, a repeatCount of 5 and a 8s min attribute value. + The active duration resulting from dur, end and repeatCount + would be 2s, because this is less than the min value (2s < 8s) + the active duration has to be corrected to 8s. As the fill attribute + is set to 'freeze' on the <set> animation, the animation is frozen at + 5s, the end of the repeatCount, the <set> applies indefinitely. + Note, that if the end of active duration would have been used as a + syncbase-value for another animation, the corrected end event at + (begin + min) = 8s has to be used. +
+Run the test and observe it for at least six seconds. No interaction required.
+The test passes if the following conditions are met:
++ This tests performs basic tests on the max attribute and on + combinations of the min and max attributes. The test is based + on the SMIL specification at: + http://www.w3.org/TR/smil20/smil-timing.html#Timing-MinMax. +
++ Each row in the test shows different rectangles subject to <set> + animations with different configurations with regards to the max and min + attributes. For each row, the animation should be active + during the first 5 seconds of the animations where the red rectangle + should show in the right column. At five seconds into the animation, + all the rectangles should move to their left position. +
++ On the first row, the <set> animation has a (0s <= t < 5s) active duration + and no max attribute so the actual active duration is (0s <= t < 5s). + The first row shows a second rectangle with a <set> animation with + the same configuration except that the max attribute value is set to + 'media'. Because the <set> element does not define a media, the + behavior should be as if the attribute was not specified. +
++ On the second row, the <set> animation has a (0s <= t < 5s) active duration + and a min attribute set to '-6s' for the first rectangle and to 'foo' for the + second one. These values are invalid for max and, as + per the specification, the behavior should be as if the attribute was not + specified. Consequently, the behavior is as for the previous row and + the actual active duration is (0s <= t < 5s). +
++ On the third row, the <set> animation has a (0s <= t < 8s) initial active duration + and a max attribute set to '5s'. The max value is less than the active + duration, so the max attribute constrains the active duration to (0s <= t < 5s). +
++ On the fourth row, the <set> animation has a (0s <= t < 5s) initial active duration, + an indefinite simple duration (dur is set to indefinite) and a max attribute set to '8s'. + Because the initial active duration is less than the max attribute the active + duration is not constrained and is unchanged at (0s <= t < 5s). +
++ On the fifth row, the <set> animation has a (0s <= t < indefinite) initial active duration, + a min of 2s and a max of 5s. Because the min value is less than the max value, both apply + and the computed active duration is (0s <= t < 5s). +
++ On the sixth row, the <set> animation has a (0s <= t < indefinite) initial active duration, + a min of 5s and a max of 5s. Because the min value is equal to the max value, both apply + and the computed active duration is (0s <= t < 5s). +
++ On the seventh row, the <set> animation has a [0s, 5s[[ initial active duration, + a min of 8s and a max of 2s. Because the min value is greater than the max value, both are + ignored and the computed active duration is [0s, 5s[. +
+Run the test and observe it for at least six seconds. No interaction required.
+The test passes if for the first five seconds after the document loads, + the red squares in each row (two in the first two rows, and one each in the + remaining rows) are in the right column, and after the five seconds, + they all move to the left column.
++ This tests performs basic tests on restart attribute. +
++ Each row in the test shows different rectangles subject to <set> + animations with different configurations with regards to the restart + attribute. For each row, the animation should be active + during the first 5 seconds of the animations where the red rectangle + should show in the right column. At five seconds into the animation, + all the rectangles should move to their left position. +
++ On the first row, the <set> animation has a begin attribute set to + '0s;1s' and a dur attribute set to 4s. This should result in a first + interval of (0s <= t < 4s) which should be superceeded, at 1s, by a new interval + of (1s <= t < 5s) because the default restart behavior is 'always'. + Consequently, the rectangle should be in the right position during the + (0s <= t < 5s) interval and move to the left position at 5s. +
++ On the second row, the <set> animation has a begin attribute set to + '0s;1s', a dur attribute set to 4s and a restart attribute set to always. + The behavior should be the same as for the first row. +
++ On the third row, the first (left most) rectangle's <set> animation + has a begin attribute set to '0s;1s', a dur set to 5s and a restart attribute + set to whenNotActive. Because of the rules for computing intervals, the + animation's interval is (0s <= t < 5s) and is not superseded by a (1s <= t < 6s) interval + because of the restart value. + + The second (right most) red rectangle's <set> animation has a begin + attribute set to '0s;2.5s' and a dur attribute set to 2.5s. This results in + a first interval (0s <= t < 2.5s) which is followed by a (2.5s <= t < 5s) interval. Consequently, + the rectangle stays on its right position for the first five seconds before it definitively + moves to the left position. +
++ On the fourth row, the <set> animation has a begin attribute set to + '0s;5s' and a dur attribute set to 5s. This results in a first interval of (0s <= t < 5s). + Because the restart attribute is set to 'never', the following possible interval, + (5s <= t < 10s) does not apply and the animation is only active for the first 5 seconds. +
++ The fifth row shows a simple animated red rectangle which lasts for 5 seconds. It shows + a reference of how the other animations should behave visually: all red rectangles should + have the same horizontal position as the one on the reference row, at any time during the + animation. +
+Run the test and observe it for at least six seconds. No interaction required.
+The test passes if for the first five seconds after the document loads, + the red squares in each row (two in the third row, and one each in the + remaining rows) are in the right column, and after the five seconds, + they all move to the left column.
++ This tests performs basic tests on the repeatCount attribute. +
++ Each row in the test shows different rectangles subject to <set> + animations with different configurations with regards to the repeatCount + attribute. For each row, the animation should be active + during the first 5 seconds of the animations where the red rectangle + should show in the right column. At five seconds into the animation, + all the rectangles should move to their left position. +
++ On the first row, the <set> animation has its dur attribute set to + '5s' and its repeatCount unspecified. Consequently, its only interval + is (0s <= t < 5s). +
++ On the second row, the <set> animation has its dur attribute set to + 1s and its repeatCount set to 5. Consequently, its only interval is + (0s <= t < 5s (1s*5)). +
++ On the third row, the <set> animation has its dur attribute set to + 10s and its repeatCount set to 0.5. Consequently, its only interval is + (0s <= t < 5s (10s*0.5)) +
++ On the fourth row, the <set> animation has its dur attribute set to + 1s and its repeatCount set to indefinite. It also has an end attribute + set to 5s. Consequently, the repeat duration is indefinite, but the active + duration is limited by the end attribute and the active interval is (0s <= t < 5s). +
+Run the test and observe it for at least six seconds. No interaction required.
+The test passes if for the first five seconds after the document loads, + the red squares in each row are in the right column, and after the five seconds, + they all move to the left column.
++ This tests performs basic tests on the repeatDur attribute. +
++ Each row in the test shows different rectangles subject to <set> + animations with different configurations with regards to the repeatDur + attribute. For each row, the animation should be active + during the first 5 seconds of the animations where the red rectangle + should show in the right column. At five seconds into the animation, + all the rectangles should move to their left position. +
++ On the first row, the <set> animation has its dur attribute set to + '5s' and its repeatDur unspecified. Consequently, its only interval + is (0s <= t < 5s). +
++ On the second row, the <set> animation has its dur attribute set to + 1s and its repeatDur set to 5s. Consequently, its only interval is + (0s <= t < 5s). +
++ On the third row, the <set> animation has its dur attribute set to + 0.5s and its repeatDur set to 5s. Consequently, its only interval is + (0s <= t < 5s). +
++ On the fourth row, the <set> animation has its dur attribute set to + 1s and its repeatDur set to indefinite. It also has an end attribute + set to 5s. Consequently, the repeat duration is indefinite, but the active + duration is limited by the end attribute and the active interval is (0s <= t < 5s). +
++ On the fifth row, the <set> animation has its dur attribute set to + 0.7s and its repeatDur set to 5s. Consequently, its only interval is + (0s <= t < 5s). The difference with the 3rd row is that there is a fractional + number of simple durations in the active duration (7.1428) where there + is a whole number of simple durations in the third row (10). +
+Run the test and observe it for at least six seconds. No interaction required.
+The test passes if for the first five seconds after the document loads, + the red squares in each row are in the right column, and after the five seconds, + they all move to the left column.
++ This tests the animation's SMIL fill attribute. +
++ On the first row, the <set> animation has its dur + attribute set to '1s' and its begin attribute set to '0s; + firstSet.end + 1s'. The fill attribute is unspecified, so + the effect is as if it was set to 'remove', because 'remove' is + the default value for fill. + + Consequently, the first interval is (0s <= t < 1s), the second is + (2s <= t < 3s), the third, (4s <= t < 5s) etc.. The red rectangle starts on the + right position, moves to the left position for one second, moves + to the right for 1 second, and so on. +
++ On the second row, the <set> animation + with the identifier 'firstSet' has its dur attribute + set to 1s and its begin attribute set to '0s; firstSet.end'. The fill attribute + is set to 'remove'. The behavior should be exactly the same as for the previous + row, and the rectangle moves from the right position to the left position + every second. +
++ On the third row, the <set> animation has its dur attribute set to + 1s and its begin attribute set to '0s; firstSet.end'. The fill attribute + is set to 'freeze'. The first interval should be (0s <= t < 1s), the second (2s <= t < 3s), + the third, (4s <= t < 5s), etc. Between interval, the fill behavior should be applied, + so the red rectangle should stay on the right position and never go to the + left position. +
++ On the fourth row, the <set> animation has its dur attribute set to + 1s and its begin attribute set to '0s'. The fill attribute + is set to 'freeze'. The first interval should be (0s <= t < 1s) and there is no + following interval. Because of the fill behavior, the <set> should + apply the last (and only) animation value after 1s. Consequently, the + red rectangle should stay on the right position and never go to the + left position. +
+Run the test and observe it for at least 5 seconds. No interaction required.
+The test passes if for the duration of the test the following conditions are met:
++ Tests the inheritance of animated values on text. +
++ This test demonstrates how <set> elements change + text properties on a <text> element. For + each of the text properties being tested, 3 + <set> elements are set. The first <set> + element acts directly on the <text> element. The + second <set> element acts on a <g> containing + children. The third <set> element acts on an <a> + containing children. In each case the test validates that + the animated value set on the <g> and <a> + elements is inherited by the <text> element. + All the <set> elements have a begin attribute + set to 0s with an offset of 1s after end. + So, the animation will apply 1s after the document is loaded + and will repeat every 1s after the animation ends. +
++ The first <set> validates the transform property. When + applied to the <text> element, the letter A will be + translated to the right every 1s, in the <text> column. + When applied to the <g> element, the letter A inherits the + transform value and is translated to the right every 1s, as + seen in the <g> column. When applied to the <a> + element, the letter A inherits the transform value and is + translated to the right every 1s, as seen in <a> column. +
++ The second <set> validates the text-anchor attribute. + When applied to the <text> element, the anchor position + of letter A is moved from start to end. When applied to the + <g> and <a> element, the property is inherited + and hence the anchor position of letter A is moved from start + to end in the second row. +
++ The third <set> validates the font-size attribute. + The font size of letter A is changed from 20 to 30. + When applied to <g> and <a> elements, the letter + A inherits the font-size and hence in row 3, letter A has a + font-size of 30 in all 3 right columns of row 3. +
++ The fourth <set> validates the font-family attribute. + The font-family is changed from default to serif. + When applied to <g> and <a> elements, the letter + A inherits the font-family attribute and hence in row 4, + letter A has serif font-family in all 3 columns. +
++ The fifth <set> validates the font-style attribute. + The font-style is changed from normal to italic. + When applied to <g> and <a> elements, the letter + A inherits the font-style attribute and hence in row 5, + letter A is animated to italic in all 3 columns. +
++ The sixth <set> validates the font-weight attribute. + The font-weight is changed from normal to bold. + When applied to <g> and <a> elements, the letter + A inherits the font-weight attribute and hence in row 6, + letter A is changed to bold on the right. +
+Run the test. No interaction required.
++ The document is animated such that it alternates between two states, an alternation occurring every second. + For the test to pass each row must show a colored letter A that alternates between the two exact shapes and positions shown + by the gray silhouettes. +
++ This test demonstrates how <set> elements change + graphics properties on elements from the 'Basic Shapes' chapter. For + each of the graphics properties being tested, 3 + <set> elements are set. The first <set> + element acts directly on the 'Basic Shape' element. The + <set> element acts on a <g> containing + children. The third <set> element acts on an <a> + containing children. In each case the test validates that + the animated value set on the <g> and <a> + elements is inherited by the 'Basic Shape' element. + All the <set> elements have a begin attribute + set to 0s with an offset of 1s after end. + So, the animation will apply 1s after the document is loaded + and will repeat every 1s after the animation ends. +
++ The first <set> validates the fill property, with + fill set to orange. When applied directly to the 'Basic Shape' + element, the <rect> fill value will change to orange + when it is translated to the right every 1s. When applied + to the <g> and <a> elements, the <rect> + inherits the fill value and is orange. +
++ The second <set> validates the fill-style property, + with fill-style set to evenodd. When applied to the + 'Basic Shape' element, the <polyline> fill-style is + changed from nonzero to evenodd. When applied to the + <g> and <a> elements, the <polyline> inherits + the evenodd fill-style. +
++ the third <set> validates the stroke property. + In this case fill is set to none. When stroke is applied + to the 'Basic Shape' element, the <rect> on the right + appears with the stroke color. When applied to the <g> and + <a> elements, the <rect> inherits the stroke property. +
++ the fourth <set> validates the stroke-width property, + with stroke-width set to 4. When stroke-width is applied + to the 'Basic Shape' element, the <line> on the right + has a width of 4. When applied to the <g> and + <a> elements, the <line> inherits the stroke-width. +
++ the fifth <set> validates the stroke-linecap property, + with stroke-linecap set to round. When stroke-linecap is applied + to the 'Basic Shape' element, the <line> stroke-linecap + value switches from butt to round. When applied to the <g> + and <a> elements, the <line> inherits the + square stroke-linecap. +
++ the sixth <set> validates the stroke-linejoin property, + with stroke-linejoin set to bevel. When stroke-linejoin is applied + to the 'Basic Shape' element, the <line> stroke-linejoin + value switches from miter to bevel. When applied to the <g> + and <a> elements, the <line> inherits the + bevel stroke-linejoin. +
++ the seventh <set> validates the stroke-miterlimit property, + with stroke-miterlimit set to 10. When stroke-miterlimit + is applied to the 'Basic Shape' element, the miter-length to + stroke-width ratio exceeds the miter-limit and the + <polyline> switches from bevel to miter.When applied + to the <g> and <a> elements,the <line> + inherits the stroke-miterlimit. +
++ the eighth <set> validates the stroke-dashoffset property, + with stroke-dashoffset set to 5.5. When stroke-dashoffset is applied + to the 'Basic Shape' element, the <line> has a different + dashing pattern. When applied to the <g> and <a> + elements, the <line> inherits the property. +
++ the ninth <set> validates the display property, + with display set to none. When display is applied + to the 'Basic Shape' element, the <rect> does not + appear on the right. When applied to the <g> and <a> + elements, the <line> inherits the display property and + hence is not seen. +
++ the tenth <set> validates the visibility property, + with visibility set to hidden. When visibility is applied + to the 'Basic Shape' element, the <rect> is hidden + on the right. When applied to the <g> and <a> + elements, the <line> inherits the visibility property + and hence is not seen. +
++ the eleventh <set> validates the color property, + with color set to blue. When color is applied to the + 'Basic Shape' element, the <rect> on the right + switches from default color of black to blue. When + applied to the <g> and <a> + elements, the <line> inherits the color property. +
++ The eleventh <set> validates the color property, with + color set to orange. When applied directly to the 'Basic Shape' + element, the <rect> fill value will change to orange + when it is translated to the right every 1s. When applied + to the <g> and <a> elements, the <rect> + inherits the color value, and via its fill="currentColor" + becomes orange. +
+Run the test. No interaction required.
+The document is animated such that it alternates between two states, + an alternation occurring every second. In each row there are three + sub-tests, which must behave identically except for any differences + noted below. Each sub-test consists of a colored shape that in one + state appears in the left column and in the second state appears in + the right column. The test is passed if the following conditions are + met:
++ This test demonstrates validates the operation of the + animateTransform element and validates the operation + of the different type attribute values. +
++ There are 5 possible values for the type attribute and + there is one animateTransform for each type and two for + the translate type. +
++ For each transform type, the test has a corresponding animateTransform. + The test uses references to show what the expected transform should be + at different points in the animation. For example, the top left + animateTransform, for type=rotate, shows circular markers which turn + orange at the time of corresponding transform value should be set by the + animateTransform. + The marker elements show the expected transform value on reference + markers in the test. +
+Run the test. No interaction required.
+The test has eight sub-tests, each of which consists of a brown + shape being animated in some way with the animation starting two + seconds after the document is loaded. Gray shapes are used + to indicate points along the animation. The test passes if + the brown shape in each of the sub-tests is animated correctly, + according to the following descriptions:
++ This test tests the operation of the animateTransform's + additive behavior. +
++ The first two rectangles, on the top row, show the effect of the + additive attribute on animateTransform. The left-most + animateTransforms have their additive attribute set to replace, + so the effect of the two transform animation is as if only the + highest priority one applied because it replaces the underlying + value. The second animateTransforms (from left to right) have + their additive attribute set to sum, which means the transforms + they produce are concatenated. +
++ The last two rectangles, on the top row, show the effect of the + accumulate attribute on animateTransform. For the left one + (third on the row, from left to right), the accumulate attribute + is set to none. There are two repeats for the + animateTransform. Therefore, the transform goes twice from a + scale(1,1) to a scale(2,2). For the right-most animateTransform, + the accumulate attribute is set to sum. There are two repeats + and the animation goes from scale(0,0) to scale(2,2) for the + first iteration and then from scale(2,2) to scale(4,4) (because + the result of the second iteration is added to the + scale(2,2) result of the previous, first iteration). +
++ The rectangles on the bottom row show the combination of + additive and cumulative behavior. The left rectangle's + animateTransform accumulate behavior is set to none but its + additive behavior is set to sum. Therefore, the transform's + underlying value (skewX(30)) is always pre-concatenated to the + animateTransform's result, which goes from "skewX(30) + scale(1,1)" to "skewX(30) scale(2,2)" in each of its two + iterations. The right rectangle's animateTransform accumulate + behavior is set to sum and the additive behavior is also set to + sum. Therefore, the transform's underlying value is always + pre-concatenated, and repetitions of the scale animation + get added together. Consequently, the transform goes from "skewX(30) + scale(0,0)" to "skewX(30) scale(2,2)" for the first iteration + and then from "skewX(30) scale(2,2)" to "skewX(30) + scale(4,4)" for the second iteration. +
++ Run the test. No interaction required. +
+The test is passed if:
++ This test demonstrates validates the operation of + animateTransform with regards to the rotation center + and with regards to paced animation. +
++ The following descriptions describe the various animations, + going top bottom, left to right. For each animation, orange + rectangle markers show the expected position for the animated rectangle + halfway through the animation. The markers are drawn with a thick + stroke for 0.2s, starting at the time when they reflect the + expected position. +
++ The first animateTransform has type='rotate' and goes from + 45 degrees to 90 degrees over a period of 3s. The rotation + center for the from and to values is 0, 0. At 0 seconds, the + expected transform should be rotate(45). At 1.5 seconds, the + expected transform is rotate(0.5 * (90 + 45)) = rotate(67.5). + At 3s, the expected transform is rotate(90). +
++ The second animateTransform has type='rotate' but has a + rotation center that varies between the from and to values. + The rotation goes from rotate(45,0,0) to rotate(90,-15,-15). + At 0s, the expected transform is rotate(45,0,0). + At 1.5s, the expected transform is rotate(67.5, -7.5, -7.5). + At 3s, the expected transform is rotate(90, -15, -15). +
++ The third animateTransform has type='translate' and calcMode='paced'. + The animation goes from translate(-40,40) to translate(-20,20) to + translate(40,-40). + At 0s, the expected transform is translate(-40,40). + At 1.5s, the expected transform is translate(0,0). + At 3s, the expected transform is translate(40,-40). +
++ The fourth animateTransform has type='translate' and calcMode='linear'. + The animation goes from translate(-40,40) to translate(-20,-20) to + translate(40,-40). + At 0s, the expected transform is translate(-40,40). + At 1.5s, the expected transform is translate(-20,-20). + At 3s, the expected transform is translate(40,-40). +
++ The fifth animateTransform has type='scale' and calcMode='paced'. + The animation goes from scale(1,2) to scale(3,2) to + scale(1,1). + At 0s, the expected transform is scale(1,2). + At 1.5s, the expected transform is scale(3,2). + At 3s, the expected transform is scale(1,1). +
++ The sixth animateTransform has type='scale' and calcMode='linear'. + The animation goes from scale(1,2) to scale(3,2) to + scale(1,1). + At 0s, the expected transform is scale(1,2). + At 1.5s, the expected transform is scale(3,2). + At 3s, the expected transform is scale(1,1). +
++ The seventh animateTransform has type="rotate" and calcMode='paced'. + The animation goes from rotate(0,0,0) to rotate(45,-15,-20) to + rotate(180,30,50). The total length along the rotation angle component + is (45 - 0) + (180 - 45) = 180. The total length along the rotation + center along the x axis is (0 - (-15)) + (30 - (-15)) = 45 + 15 = 60. + The total length along the rotation center along the y axis is + (0 - (-20)) + (50 - (-20)) = 20 + 70 = 90. + At 0s, the expected transform is rotate(45,-15,-20). + At 1.5s, the expected transform is rotate(90,0,5) to achieve constant + velocity along the rotation angle component, the x-axis rotation center + component and the y-axis rotation center component. At 1.5s, half the + distance has been run on each component. For the rotation angle, this + means that 45 has been reached and that 45 more degrees in the (45 <= r < 180) + interval have been consumed. For the x-axis rotation center, this means + that 30 units have been run: the (0 >= x > -15) interval has been fully consumed + (15 units long) and 15 units on the (-15 <= x < 30) interval have been consumed, + which explains the computed 0 value. For the y-axis rotation center, this + means that 45 units have been run: the (0 >= y > -20) interval has been fully + consumed and 25 units have been consumed in the (-20 <= y < 50) interval, which + explains the computed 5 value. + At 3s, the expected transform is rotate(180,30,50). +
++ The test is passed if the lightgray rectangles are exactly in the positions indicated by each of the orange rectangles when they are shown with a thick stroke. If any part of the lightgray + rectangles are outside the thick stroked orange rectangles then the test has failed. +
++ This test validates the operation of the animate element + on the <path> element's d attribute. +
++ The following descriptions references to the tests by number. The first test + is the one showing on the top left. The last, sixth test is the one showing + at the bottom right. Test numbers are alocated from left to right and from + top to bottom. + + For each test, there are reference outline markers which show the expected + animated shape at different times in the animation. At the time of the expected + shape, the outline of the expected shape is drawn with a thick stroke for 0.2s + so the test user can visually check that the shapes are matching at the + expected times. +
++ The first test validates a simple from-to animation on a path's d attribute + made of M, C and Z commands where both the from and to attributes are specified. + The attributes are compatible with the path element's d attribute. +
++ The second test validates a simple to-animation on a path's d attribute + made of M, C and Z commands where the to attribute is specified. + The attribute is compatible with the path element's d attribute. +
++ The third test validates a simple values-animation on a path's d attribute + made of M, C and Z commands where the values attribute is specified and + specifies three seperate values. + The attribute is compatible with the path element's d attribute. +
++ The fourth, fifth and sixth tests validate that interpolation between compatible + path values (i.e., path values which normalize to the compatible values) is + supported. +
++ The fourth tests interpolation between a path value containing H, V and L commands + (in the from value) and a path value containing compatible h, v and l commands + (in the to value). +
++ The fifth tests interpolation between a path value containing C and S commands + (in the from value) and a path value containing compatible c and s commands + (in the to value). +
++ The sixth tests interpolation between a path value containing Q, T and A commands + (in the from value) and a path value containing compatible q, t and a commands + (in the to value). +
+Run the test. No interaction required.
+The test consists of six sub-tests. In each sub-test, the light gray filled + path must continously morph its shape, starting one second after the document + load and continuing for three seconds. In all sub-tests except for #3, there are + two orange reference shape outlines between which the gray path must morph. + In sub-test #3, there are three reference shapes. The test passes if each of the + gray shapes morphs appropriately according to the following descriptions:
+In addition, during the animations whenever the gray shape has the same shape as + a reference shape, the stroke of the reference shape must be shown thicker momentarily.
++ Test animation of color keywords that resolve to animatable RGB values. +
++ Run the test. No interaction required. +
++ The test is passed if five + black squares are shown, after two seconds, all five squares turn red and + then smoothly animate the fill color to green over the next five seconds. +
++ The first subtest tests animateColor with 'to' and 'from' values including + currentColor. The second subtest checks that the value of currentColor is the + current animated value of the color property, by animating the color property + at the same time as animating fill with a 'from' or 'to' value of currentColor. +
+ +Run the test. No interaction required. +
++ The first subtest is passed if all + four rectangles at the top smoothly animate from black to green over 5 seconds. + During this time the bottom two rectangles must be blue.
+The second subtest, which starts after the first one completes, is passed if + the bottom two rectangles smoothly animate from green (at five seconds), through + dark cyan (at 7.5 seconds), to cyan (at 10 seconds and above). Colored circles + indicate the appropriate colors at these times. +
++ [[Describe which section and what specific assertion is being tested + by the test. If the test has a number of sub tests, multiple + "testComponent" elements can be specified within the "testDescription" + element.]] +
++ This tests performs tests on fill="freeze" values. +
++ Currently, this test does not claim to show correct + behaviour in SVG 1.1. The reason is only to show the + difference between current viewers at this point. +
++ When the correct behaviour has been defined, this test + can be adjusted to reflect that. +
++ [[Describe the pass criteria of the test here. The pass criteria is what + should be displayed when the test is run.]] +
+
+ This tests that the underlying value of a scale transformation
+ is 0. Since SMIL defines a by animation as being equivalent
+ to an additive values animation where the first value is zero and
+ the second value is the by value, such an animation would
+ begin by post-multiplying a scale(0)
transformation to
+ the element's underlying transform list.
+
+ The test consists of two circles: an orange circle on the left,
+ which serves as a reference, and a blue circle on the right,
+ whose transform
attribute is animated. Animation of
+ the circles begins at t=1s and lasts for 3s.
+
+ The transform animation that applies to the blue circle is of type
+ "scale", and specifies by="1"
. Since the animation is
+ considered to be equivalent to one that specifies from="0" to="1"
,
+ when the animation begins the circle will be scaled down to a point,
+ and then will be scaled up until it reaches its original size at
+ t=4s.
+
+ The test is passed if the blue circle on the right is always the same + size as the orange circle on the left. The test runs from t=0s until + t=4s. +
+
+ This tests that any which space before semicolon separators in
+ a values=""
attribute on an animation element is ignored.
+
+ The test consists of a single rectangle whose height is animated
+ with a values=" 0 ; 50 "
attribute.
+
+ Run the test. No interaction required. +
++ The test is passed if the rectangle is animated from a height of + 0 to a height of 50 over four seconds, starting from when the + test is loaded. +
++ Tests clarification of value spacing of keySpline syntax; whitespace, or commas with optional whitespace, are allowed. +
++ Test possible values for 'calcMode="spline"', with both commas, whitespace, and mixed separators +
++ Six animations (three sets of two) have been defined. The three green ones on the left show rectangles which get smaller. The three orange ones on the right show rectangles of constant size, which move. + The black text and grey ruler lines help show the sizes and movement of the rectangles over time. + +
++ Run the test. No interaction required. +
++ The test is passed if the bottom edge of all six animated rectangles move together in sync. +
++ Test that the class attribute is animatable and that style + sheets select on the animated value. + + +
++ This test uses the following elements : 'set', + and 'animate'. It requires that CSS style sheets are supported. +
++ The test shows a circle which is initially hidden, becomes visible and blue at + 3s, abruptly changing to dark red at 5s. Two overlapping animations both animate the + class attribute. The class attribute, as a string value, does not support + linear interpolation so a discrete animation is produced, changing from the + start to the end value midway through the animation duration. +
++ The first animation starts at 2s and lasts for 4s so the mid point is at 3s. + The second animation starts at 3s and lasts for 4s so the midpoint is at 5s. + The file includes various guides that can be used to verify the + correctness of the animation. The value of the class attribute + at 02 is "start" so the first CSS rule matches. At 3s it becomes "midway" + so the second rule matches. At 5s it becomes "final midway" so the second and + third rules match; the third rule has higher specificity so determines the fill color. + +
++ The color of the large circle must match the colour of the smaller guide + boxes on the left at times 0s, 3s and 5s. If the text "CSS not supported" + is visible, the test does not apply. +
++ This tests that to-animations on attributes whose values cannot be + interpolated are treated as discrete animations. +
++ Run the test. No interaction required. +
++ The test passes if there initially eight red squares in the + left column when the document is loaded and the all move + at the same time to the right column two seconds after the + document is loaded. +
++ This tests checks the behavior of discrete to-animations. +
+Run the test. No interaction required.
+The test passes if after five seconds, in each of the three rows, + the red rectangle is in the column at the times indicated. + Thus, from the document load until 2s afterwards, the red + square in all three rows must be in the left column. At 2s, + all three red squares must move to the right column. At 4s, + the red square in the first row must move to the left column + and the other two red squares must remain in the right column.
+Tests 'mouseover' event on SVGElementInstance
++ What each case tests is as follows. + Case 1: mouseover event on SVGElementInstance. Referenceing an element that contains an event. + Case 2: mouseover event on referencing element. Event bubbling from SVGElementInstance to referencing element. + Case 3: mouseover event on parent of referencing element. Event bubbling from SVGElementInstance to referencing element ancestors. + Case 4: mousedown event on referencing element. SVGElementInstance is not effected by event listener on referencing element. +
++ Mouseover each of the red rectangles, and then click on the bottommost rectangle. +
++ This test contains four cases. The cases must produce the following results for the test to pass. +
++ This test tests 'pointer-events' on text. Initially you should see four big rects with black stroke. + In the uppermost rect there should be 10 'O':s with black fill. + In the second rect from the top there should be 10 'O':s with no fill but with black stroke. + In the third and fourth rects there should be no visible 'O':s at all. + In the fourth rect there should be two green rects, and in each of the other three rects there should be one green rect. +
++ Using the pointer device move the cursor over each of the four black-stroked rectangles from left to right. + As the mouseover event triggers, the 'O':s will become visible and marked + in either green (a pass) or red (an immediate fail). Some 'O':s will not + change when the pointer is moved over them. +
++ The test has passed if after moving the cursor over all the rects: +
+Testing pointer-events and rendering order
++ Move the mouse over the blue and purple shapes. Click the pink circle at the top right of the page. Move the mouse over the blue and purple shapes again. +
++ For the test to pass the blue rectangles must always turn pink on mouseover, and the ovals must turn pink on mouseover only if pointer-events are set to "ALL". + If a shape other than the one currently hovered turns pink then the test has failed. +
+Tests the pointer-events attribute with different 'visible' values
++ The 2nd and 3rd columns represent respectively rects with no fill/stroke and transparent fill/stroke. + The 4th column (most right column) has a non activatable pointer event as the visibility of the column + is set to hidden. +
++ The first row tests the default value for pointer-event, i.e. visible fill and stroke will trigger an event. + The second row tests pointer-events="visiblePainted", i.e. visible fill and stroke will trigger an event. + The third row tests pointer-events="visibleFill", i.e. visible fill only an event. + The fourth row tests pointer-events="visibleStroke", i.e. visible stroke only an event. + The fifth row tests pointer-events="visible", i.e. visible fill and stroke will trigger an event. +
++ Slowly move the mouse over the rectangles in each row while checking the pass criteria. +
++ The test is passed if the following conditions are met +
+Tests the pointer-events attribute with different painting values
++ The 2nd and 3rd columns represent respectively rects with no fill/stroke and transparent fill/stroke. + The 4th column has visibility set to hidden. +
++ The first row tests pointer-events="painted", i.e. event on fill and stroke that are set. + The second row tests pointer-events="fill", i.e. event on a fill that is set. + The third row tests pointer-events="stroke", i.e. even on a stroke that is et. + The fourth row tests pointer-events="all", i.e. event on fill and stroke that are set. + The fifth row tests pointer-events="none", i.e. no event. +
++ Slowly move the mouse over the rectangles in each row while checking the pass criteria. +
++ The test is passed if the following conditions are met: +
++ This test shows rectangles filled with animated gradient which inherits some of their properties: stop-color, stop-opacity. +
++ Load the svg and wait 5 seconds for the animation to run, then compare the image to the reference. +
++ The correct result should show: +
++ This tests that the 'xlink:href' attribute on the 'script' element is not animatable. +
++ After loading the test and waiting one second, two rectangles + will appear, indicating the result of two sub-tests. The + upper rectangle reflects the result of testing that an + attempt to animate 'xlink:href' on 'script' does not affect + the .href.animVal of the element. The lower rectangle reflects + the result of testing that the animation attempt does not + cause a new script to be loaded and executed. Black indicates + that the sub-test did not run, red that it failed and green + that it passed. +
++ Run the test. No interaction required. +
++ The test is passed if both rectangles are green once they + appear one second after loading the test. +
++ This tests that calling SVGSVGElement.getCurrentTime() before the + document timeline has begun returns 0, and that + calling SVGSVGElement.setCurrentTime() before the document timeline + has begun will queue a seek to that time once the timeline + does begin. + After loading the test, two rectangles will be shown. + The left rectangle indicates whether SVGSVGElement.getCurrentTime() + correctly returned 0 before the document timeline had begun. + The right rectangles indicates whether a call to + SVGSVGElement.setCurrentTime() was acted upon once the timeline + did begin. For each rectangle, red indicates that the sub-test + failed and green indicates that the sub-test passed. +
++ Run the test. No interaction required. +
++ The test is passed if both rectangles are green. +
++ The purpose of this test is to determine if an application can apply ICC + color profiles to raster images. The same image is displayed twice; a color profile + is applied to one by the SVG, so that the colors change. +
+ ++ +
++ Run the test. No interaction required. +
++ If the two images (each of 9 colored squares) look identical, the test fails. + If the colours in the lower right image are more saturated, brighter versions of + those in the top left image, as shown by the reference image, the test is passed. +
++ This tests the 'color' property and the 'currentColor' value on fill, stroke, and stop-color properties. +
++ Run the test. No interaction required. +
+ ++ There are three subtests. The first subtest, to the top left, is passed if the circle has a green fill. The second subtest, + to the top right, is passed if the circle has a green stroke. The third subtest shows a rectangle + with a gradient fill, which has three stops. The subtest is passed if central stop is green, + fading off to blue to the left and pale yellow to the right. +
++ Tests if the color datatype is supported. There are multiple syntaxes for + specifying the same color, such as #37F and #3377FF. This test is focussed on the + X11 color names, which are not part of the tiny profile. + Each group of circles uses four forms - 6-digit hex, rbg() integer form, rgb() percentage form, + and named ('X11') colors. It does not use 3-digit hex, because the colors used in this test + cannot be represented in three digit form. +
++ Run the test. No interaction required. +
++ For each of the nine groups of circles shown here, all circles must + be identical in color, and the same color as in the reference image. +
++ Tests if the color datatype is supported. There are multiple syntaxes for + specifying the same color, such as #37F and #3377FF. +For each of the six groups shown here, + each of the circles in the group uses one of the syntactical forms +
++ The first row uses five forms - 3-digit hex, 6-digit hex, rbg() integer form, rgb() percentage form, + and the 'HTML' subset of the name ('X11') colors. +
++ The second row uses only four forms - 3-digit hex, 6-digit hex, rbg() integer form, rgb() percentage form - + as there are no HTML or X11 names for those colors. +
++ Run the test. No interaction required. +
+ ++ For each of the six groups of circles shown here, all circles must + be identical in color, and the same color as in the reference image. +
++ This tests the 'system' colors. +
+Run the test. No interaction required.
++ This test has no specific pass criteria, except that no error must be indicated. +
++ The colors on your screen might not match the reference + image at all, but they should at minimum be legible and should + preferably resemble the colors used on menus and other user interface + elements on your computer, pda or phone. +
++ Tests the color that is used for the currentColor value in the fill + attribute when more than one color is specified. +
++ This is illustrated using a single rectangle that is a child of a group + element. A fill is specified for the group element but not the + rectangle. Colour is specifed for the rectangle and the group element. +
+Run the test. No interaction required.
++ The test is passed if the user agent renders the rectangle with a green + fill. +
++ Test that the viewer can read gzipped content in data uri. +
++ Open the test in any SVG player. +
++ The test has passed if you see a star in the middle of the test frame. +
++ This test checks that namespace prefixes are handled correctly. +
++ First, a random 20-character string is generated. The string only contains characters that are valid NCName letters. + This string is then used as a custom prefix for an 'href' attribute in the XLink namespace. + An 'image' element is created and two image references are added, one is in the "http://www.this.is.not.an/xlink" namespace, + and one is in the XLink namespace. Only the attribute with the 20-character prefix is actually in the XLink namespace, + which means that that link should be the one that is used when rendering the 'image' element. This first subtest is + using the setAttributeNS method. +
++ Run the test. No interaction required. +
++ The testcase has passed if after the script execution has taken place these conditions are met: +
++ Tests the default initial coordinate system used by renderer. +
+Should be 0,0 if not specified. This is illustrated by comparing blue boxes that are + missing a coordinate or all coordinates with yellow boxes that have the + correct coordinates specified. +
++ Run the test. No interaction required. +
++ The test is passed if there are three blue boxes, + with small yellow boxes rendered on top of them. These boxes should be + placed along the origin, and x and y axis. +
++ Tests the default units used for the initial coordinate system. This is + illustrated by comparing blue boxes that have no units specified for their + coordinates, with yellow boxes that have px units specified for their + coordinates. +
++ Run the test. No interaction required. +
++ This test should produce three blue boxes, with small yellow + boxes rendered on top of them. These boxes should be placed along the + origin, x and y axis. +
++ Tests the liveness of SVGTransform.matrix. +
++ Load the svg, you should see a green circle. +
++ The test has passed if: +
++ Tests the liveness of SVGTransform.matrix, that the SVGTransform object is updated when the SVGTransform.matrix object is changed. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ This tests that SVGTransformList.createSVGTransformFromMatrix(), + SVGSVGElement.createSVGTransformFromMatrix() and SVGTransform.setMatrix() + all do not track changes to the SVGMatrix passed to them. +
++ After loading the test, three rectangles will be presented. The + upper rectangle indicates the result of testing whether + SVGTransformList.createSVGTransformFromMatrix() behaved correctly, + the middle rectangle indicates the status for SVGSVGElement.createSVGTransformFromMatrix(), + and the bottom rectangle for SVGTransform.setMatrix(). +
++ Run the test. No interaction required. +
++ The test is passed if the three rectangles are green. +
++ The test checks the SVGTransformList.consolidate method. +
++ Run the test. No interaction required. +
++ There must be 13 green rectangles visible. + The text next to the first rectangle must say "Scripting enabled". + The other 12 lines must each say "Passed subtest #n" where n is the subtest number 1..12. + If anything red shows, the test has failed. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ The test uses the rect element, the fill color (solid primary colors) and transforms. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ The test uses the rect element, the fill color (solid primary colors) and transforms. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ The test uses the rect element, the fill color (solid primary colors) and transforms. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ The test uses the rect element, the fill color (solid primary colors) and transforms. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ The test uses the rect element, the fill color (solid primary colors) and transforms. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ The test uses the rect element, the fill color (solid primary colors) and transforms. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ The test uses the rect element, the fill color (solid primary colors) and transforms. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text - a long blue line at four o'clock and a short red line at seven o'clock below the text "translate+rotate", and, below and to the left of that, a long green line at four o'clock and a short red line at seven o'clock below the text "rotate+translate". +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ This test will check if the transfomations performed are carried out in the proper order. The result should differ depending on which transformation comes first. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This test verifies the implementation of transforms. It tests elementary transforms + and transform nesting. + Note that for layout purposes, this test uses nesting of translation with the elementary transforms. +
++ This test will check if the various matrix operations work +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ Translation is equivalent to the matrix [1 0 0 1 tx ty], where 'tx' + and 'ty' are the distances to translate coordinates in X and Y + respectively. The test overlays a group of black graphics elements + with a 'translate' transform specified on top of an identical group + of red elements with the equivalent 'matrix' transform and vice + versa. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ Scaling is equivalent to the matrix [sx 0 0 xy 0 0], where one unit in the X and Y directions in the new coordinate system equals 'sx' and 'sy' units in the previous coordinate system respectively.The test overlays a group of black graphics elements with a 'scale' transform specified on top of an identical group of red elements + with the equivalent 'matrix' transform and vice versa. +
++Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ Rotation about the origin is equivalent to the matrix [cos(a) sin(a) -sin(a) cos(a) 0 0], which has the effect of rotating the coordinate system axes by angle 'a'. The test overlays a group of black graphics elements with a 'rotate' transform specified on top of an identical group of red elements + with the equivalent 'matrix' transform and vice versa. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ A skew transformation along the x-axis is equivalent to the matrix [1 0 tan(a) 1 0 0], which has the effect of skewing X coordinates by angle 'a'. +The test overlays a group of black graphics elements with a 'skewX' transform specified on top of an identical group of red elements + with the equivalent 'matrix' transform and vice versa. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ A skew transformation along the y-axis is equivalent to the matrix [1 tan(a) 0 1 0 0], which has the effect of skewing Y coordinates by angle 'a'. +The test overlays a group of black graphics elements with a 'skewY' transform specified on top of an identical group of red elements + with the equivalent 'matrix' transform and vice versa. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ Tests that separating transform definitions by whitespace and/or a comma is supported. The test draws a red 'rect' element with a valid, non-delimited transform list. It overlays it with an identical black rectangle with + equivalent transform list delimted by commas and numerical Unicode references of space (U+0020), tab (U+0009), carriage + return (U+000D), line feed (U+000A), and combination of all five, +so that no red is visible. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ If a list of transforms is provided, then the net effect is as if each transform had been specified separately in the order provided. +
+The test overlays a black 'rect' with transform list on top of an equivalent red 'rect' with equivalent nested transforms, and vice + versa, so that there is no red visible on the page.
p> ++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ If 'ty' is not specified for a 'translate' transform, it is assumed to be zero. +
++ Specify a series of various red graphics elements. Specify an equivalent series of black graphics elements that are defined to have positions + that are shifted '10' user units to the right of the red graphics elements. Specify a 'transform' value of 'translate' with only the 'tx' value + specified (i.e., 'translate(10)'). If the 'ty' parameter takes the default value of '0' user units, there will be no red on the page. +
+Run the test. No interaction required.
++ The test is passed if there is no red visible on the page. +
++ If 'sy' is not specified for a 'scale' transform, it is assumed to be equal to 'sx'. +
++ Specify a series of various red graphics elements. Specify an equivalent series of black graphics elements that are defined to have dimensions + that are half the size as the red elements. Specify a 'transform' value of 'scale' with only the 'sx' value specified (i.e., 'scale(2)'). If the 'sy' + parameter takes the same value as the 'sx', there will be no red on the page. +
+Run the test. No interaction required.
++ Test passes if there is no red visible on the page. +
++ If 'cx' and 'cy' are not specified for a 'rotate' transform, the rotation is about the origin of the current user coordinate system and thus corresponds to the matrix [cos(a) sin(a) -sin(a) cos(a) 0 0]. +
++ Specify a series of various black graphics elements inside a 'g' element with 'transform' set to a 'rotate' value with unspecified 'cx' + and 'cy' parameters (i.e., 'rotate(15)'). Specify an equivalent series of red graphics elements inside a 'g' element with 'transform' set + to a 'matrix' value which would rotate the elements 15 degrees about the point (0,0) of the current user coordinate system. If the 'g' element containing the black elements correctly rotates its content by 15 degrees around the origin of the current user coordinate system, there will be no red on the page. +
+Run the test. No interaction required.
++ Test passes if there is no red visible on the page. +
+ ++ Verify the conversion processing of percentage and fraction values relative to + object bounding boxes. This is used when defining linear and radial gradients + as well as patterns. +
++ The test validates conversion for coordinates, width, height and length. The first + test defines three corresponding linear gradients, which specify coordinates + using percentages for one, fractions for the second and user coordinates for the + third. The second test defines three corresponding radial gradients, which specify + a length (radius) using percentages for the first, fractions for the second and + user space for the third. Finally, the third test defines three corresponding patterns, + which specify their width and height using percentages for the first, fractions for the + second and user space coordinates for the last one. +
++ The test also assumes that linear and radial gradients, + as well as patterns are implemented. +
++ Run the test. No interaction required. +
++ The rendered image should match the reference image. Also, the text may + show minor differences, per CSS2 rules for font selection and matching. +
++ Verify the conversion processing of CSS units and percentage values for both + coordinates and length values. Note that the test uses the CSS px unit to be usable + in all pixel resolutions. Hence, the conversion from other CSS units to CSS px is + left out of the test. +
++ There are six atomic tests in this test. For each, the approach is to draw two similar + elements (circles or rects) with coordinates specified in user space for one and in + CSS units or percentage for the other. Each test is such that these two values (or + value pairs) should match. +
++ Run the test. No interaction required. +
++ In the first two tests, that validate coordinate processing, the circles + should have the same center. In the following two tests, the rectangles should have + the same height and width. And finally, in the last test, the 3 skewed circles should have the + same radius. +
++ The rendered image should match the reference image except for the text which may + show minor differences, per CSS2 rules for font selection and matching. +
++ This test verifies both the initial viewport size and the support for the various + unit specifiers. +
++ The units in SVG can be: user coordinate and CSS units: em, ex, px, pt, pc, cm, mm, + in and percentages. The test does not check the absolute length accuracy as this + can only be truly validated with a ruler. However, it validates that the different + units are supported by drawing multiple elements who have the same length specified + in different units. +
++ The viewport is the "finite rectangular region" where rendering occurs in SVG. + Hence, nothing should be rendered outside the viewport (paragraph 7.1). Furthermore, + when no positioning properties are set on the top svg element, the initial viewport + size should have the value of the top svg element's "width" and "height" attributes. + To check this behavior, the test does not define positioning properties on the top + svg element but defines its "width" and "height" properties. Then it fills a red + rectangle that is bigger than the viewport size. Then, a rectangle, the size of the + viewport is drawn in white. If rendering is limited to the viewport area, none of the + red should show. +
++ The line showing the "ex" units will not necessarily appear with the same length + as shown in the reference image because the X-height of a font is not + necessarily half of the font size (which is assumed in the reference image where + 1ex is considered to be .5em). +
++ Run the test. No interaction required. +
+The test passes if the top three lines (user units, px, em) are the same length, + the fifth line (%) is the same length as the top three lines, and the bottom + five lines (in, cm, mm, pt, pc) are the same length. The fourth line (ex) may have + any non-zero length, since the X-height of the font will depend on the exact font + chosen by the user agent (which may vary).
++ This test verifies the implementation of the viewBox and the + preserveAspectRatio attribute. This is a modified version of the sample + file included in the SVG specification. It exercises the various + preserveAspectRatio values and uses a general entity definition in order + to make reading of the SVG source easier. +
++ Load the document in the user agent. +
++ The rendered picture should match the reference image exactly except for + variations in the labeling text. +
++ This test verifies the implementation of the preserveAspectRatio attribute on <image> + referencing raster content. +
++ This is a modified version of the sample file included in the SVG specification. + It exercises the various preserveAspectRatio values and uses a general entity definition + in order to make reading of the SVG source easier. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ This file tests the allowed syntax of the viewBox attribute. The viewBox attribute is a list of + four numbers min-x, min-y, width and height, separated by whitespace and/or a comma. +
++ Run the test. No interaction required. +
++ In the rendered result, you should see 6 identical light blue shapes. +
++ This test verifies the implementation of the preserveAspectRatio attribute on <image> + referencing svg content. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ Test mixing a business data namespace with elements in SVG namespace. +
++ The test case uses a different namespace to hold fake sales data. + Using ECMAScript to make calls to the DOM, the test case extracts + the sales data and then makes calls to the SVG DOM to build up + a 'path' element and a 'text' element for each individual pie slice. +
++ Run the test. No interaction required. +
++ The result should show five pie slices. + The first pie slice should be exploded, with a pink fill and a blue border. + The other pie slices should have various levels of gray fill and black borders. + The name of each region should appear in black towards the center of + the pie slice. +
++ Test background image processing. +
++ The first subtest enables background image processing and adds an empty ‘g’ element + which invokes the ShiftBGAndBlur filter. This filter takes the current accumulated + background image (i.e., the entire reference graphic) as input, shifts its offscreen + down, blurs it, and then writes the result to the canvas. Note that the offscreen for + the filter is initialized to transparent black, which allows the already rendered + rectangle, circle and triangle to show through after the filter renders its own + result to the canvas. +
++ The second subtest enables background image processing and instead invokes the + ShiftBGAndBlur filter on the inner ‘g’ element. The accumulated background at the + time the filter is applied contains only the rectangle. Because the children + of the inner ‘g’ (i.e., the circle and triangle) are not part of the inner ‘g’ element's + background and because ShiftBGAndBlur ignores SourceGraphic, the children of the inner ‘g’ + do not appear in the result. +
++ The third subtest enables background image processing and invokes the ShiftBGAndBlur on the + ‘polygon’ element that draws the triangle. The accumulated background at the time the filter + is applied contains the rectangle plus the circle ignoring the effect of the ‘opacity’ + property on the inner ‘g’ element. (Note that the blurred circle at the bottom does not + let the rectangle show through on its left side. This is due to ignoring the effect of + the ‘opacity’ property.) Because the triangle itself is not part of the accumulated background + and because ShiftBGAndBlur ignores SourceGraphic, the triangle does not appear in the result. +
++ The fourth subtest is the same as the third except that filter ShiftBGAndBlur_WithSourceGraphic is + invoked instead of ShiftBGAndBlur. ShiftBGAndBlur_WithSourceGraphic performs the same effect as + ShiftBGAndBlur, but then renders the SourceGraphic on top of the shifted, blurred background + image. In this case, SourceGraphic is the blue triangle; thus, the result is the same as in + the fourth case except that the triangle now appears. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Verify correct operation of the five compositing modes + of the feBlend filter primitive. Seven rectangles are + blended into a gradient, with text strings identifying + which of the the five feBlend modes were used. +
++ All rectangles but the fourth one have a blue fill, although the + blend mode will adjust this color. The fourth has a yellow fill. +
++ The third and fourth rectangles are grouped and the filter is applied to the group. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image + exactly, except for possible variations in the + labelling text (per CSS2 rules). +
++ Test which verifies the basic facilities of + feColorMatrix. +
++ This test uses the following elements : a nested + <svg> with a viewBox attribute, <linearGradient>, + <filter>, <feColorMatrix>, <feComposite>. +
++ The test case shows five rectangles filled with a + gradient showing the effects of feColorMatrix: an + unfiltered rectangle acting as a reference, use of the + feColorMatrix matrix option to convert to grayscale, + use of the feColorMatrix saturate option, use of the + feColorMatrix hueRotate option, and use of the + feColorMatrix luminanceToAlpha option. +
++ The test is somewhat self-explanatory as the strings + document the type of feColorMatrix operation that is + being used. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image + exactly, except for possible variations in the + labelling text (per CSS2 rules). +
++ Tests the default behaviour of feComponentTransfer +
++ The test displays two rects with the same gradient fill. The gradient + fill has the stops red, green, blue and black all of which are evenly + spaced. +
++ The first rect with the 'Reference' label beneath it has an + feComponentTransfer filter applied to it. This filter specifies a + 'linear' transform for the Red component such that Red is transformed to + Black. The Green component is specified as an 'identity' transform. The + remaining components (Green, Alpha) are unspecified and by default + must be treated as 'identity' transforms. +
++ The second rect with the 'Default' label beneath it has an + feComponentTransfer filter applied to it. This filter specifies a + multiple transforms from the Red component. The last transform + specified for the Red component is a 'linear' transform that shifts Red + to Black. This is the transform that should be used by a conforming + implementation. There are no other components specified for the filter + of the second rect. A conforming implementation should treat + unspecified components in an feComponentTransfer as 'identity'. +
++ Run the test. No interaction required. +
++ For this test to pass both rects must have a gradient fill that has the + stop colors Black, Green, Blue and Black, equally spaced. +
++ Test which verifies the basic facilities of feComposite. +
++ This test uses the following elements: <path>, <filter> + <feImage> <feComposite>. +
++ The test case shows six pairs of overlapping triangles + depicting the six different feComposite operators. The + first row shows compositing when both triangles have + opacity=1. The second row shows compositing when both + triangles have opacity=.5. The six columns illustrate the + six types of compositing operations. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image + exactly, except for possible variations in the + labelling text (per CSS2 rules). +
++ Tests the arithmetic operator in feComposite. +
++ Run the test. No interaction required. +
++ The test is passed if there are four filled squares visible, and the + fill color matches the respective reference stroke exactly. +
++ Test feComposite and the arithmetic operator to implement a simple dissolve operation. +
++ Run the test. No interaction required. +
++ The test has passed if there are four images visible, each in + different stages of dissolving the bird in the foreground into the + tree in the background. +
++ Testing the feComposite element and that the 'k2' and 'k3' attributes + are animatable. The result is an animated dissolve between two images. +
++ Reload the testcase or click the image to run animation again. +
++ The test has passed if there is an animation effect that gradually + dissolves a photo of a tree into an image of a bird over the course + of two seconds. The final result is that the bird is fully visible + and the tree photo is invisible. +
++ Test which verifies the basic facilities of + feComponentTransfer. +
++ This test uses the following elements : a nested <svg> + with a viewBox attribute, <linearGradient>, <filter>, + <feComponentTransfer>. +
++ The test case shows four rectangles filled with a + gradient showing the effects of feComponentTransfer: an + identity function acting as a reference, use of the + feComponentTransfer table option, use of the + feComponentTransfer linear option, and use of the + feComponentTransfer gamma option. +
++ The test is somewhat self-explanatory as the strings + document the type of feComponentTransfer operation that + is being used. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image + exactly, except for possible variations in the + labelling text (per CSS2 rules). +
++ Test which verifies the basic facilities of + feConvolveMatrix. +
++ This test defines six filters that exercise traditional + convolutions: uniform blur, vertical and horizontal + blurs, edge detection, embossing and sharpening. Note + that the edge detection filter produces a fully + transparent image because the alpha channel is convolved + and produces 0 values. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image + exactly, except for possible variations in the + labelling text (per CSS2 rules). +
++ Tests feConvolveMatrix with different values for the 'order' attribute. +
+Run the test. No interaction required. + +
+You should see three filtered images. Each image is the same + and has the same filter applied to it. + The test has passed if all the three filtered images look the same, and the filtered result shows bright white edges on a dark background. + The rendered picture should match the reference image. +
++ Tests the 'in1' DOM attribute on 'feConvolveMatrix'. +
++ Load the testcase, you should see three nearly identical images that say "FAIL". + After 3 seconds all three images should be replaced by the same image of a bird. + The two images to the right have filters applied, while the one on the left is always unfiltered. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ Tests the 'bias' attribute on 'feConvolveMatrix'. +
++ The test uses a raster image and a vector graphic to test the effect + that the 'bias' attribute on 'feConvolveMatrix' has. +
++ The first row of images in the test are four identical raster images. + The first image is the original unfiltered image. The second has the + filter kernel applied with no bias value specified. The third and fourth + images both have a bias value specified for the filter. +
++ The second row of images in the test are four rectangle objects with a + gradient fill. The gradient fill transitions from opaque green to + transparent green. The first image is the original unfiltered graphic. The + second graphic has a filter kernel applied with no bias value specified. + The third and forth images both have a bias value specified for the + filter. +
++ Behind each filter result there's a checkerboard pattern placed, to help + verify that there's transparency in the lower row, but not in the upper. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ Tests feConvolveMatrix and the 'edgeMode' attribute. +
++ Run the test. No interaction required. +
++ You should see three filtered images, each result should be slightly different, if they all look the same the test has failed. + The rendered picture should match the reference image. +
++ Verify the basic operation of the feDiffuseLighting + element. The test shows three rows of 3 images. Each + rows tests a different aspect of the filter and shows + the result of the filtering operation. +
++ The first row shows the result of varying the + surfaceScale attribute. The second row shows the result + of varying the diffuse constant (kd) attribute. The last + row shows the result of varying the lighting-color + property. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image. +
++ Verify the basic capability to handle the feDisplacementMap filter + node. Six images should appear in 2 rows of 3. On the left in each + row a test image of a checker board is displayed. In the middle + column is the displacement map. In the right-hand column is the + result. All displacement maps are generated as png files with gamma + 1.0 and must be interpreted linearly for the proper geometric + displacement to occur. +
++ The top row tests a displacement map which displaces each pixel by an + amount equivalent to a rotation of 20 degrees around the center of the + image. A blue reference rectangle is drawn on the result using an svg + transform attribute to mimick the same 20 degree rotation. The edges + of the blue rectangle should be parallel to the grid lines in the + displaced image. Distortion of the grid pattern such that the grid + lines are slightly curved is indicative of improper gamma handling in + the viewer. +
++ The bottom row tests a displacement map which distorts the image + spherically. +
++ In addition to feDisplacementMap, this test uses the 'feImage' and + 'rect' elements. Figure labeling uses the text element. The + reference blue rectangle uses fill, fill-opacity, and transform. +
++ Run the test. No interaction required. +
++ The rendered image should match the reference image. The edges + of the blue rectangle must be parallel to the grid lines in the + displaced image. The center of the bottommost right distorted image + should be on a gridpoint. +
++ This tests feDisplacementMap without feImage. The input geometry is also used as the displacement map. +
++ The bottom subtest tests that not specifying the 'xChannelSelector' attribute has the same effect as if 'A' was specified. +
++ In both cases the filter input image consists of a gradient that is rendered using the default 'color-interpolation' which is 'sRGB'. + The default colorspace for filter primitives is 'linearRGB'. The filtering operation happens in 'linearRGB' space and the + result is then transformed back to 'sRGB' space for display. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ A single filter that uses a combination of filter + primitives. You should see a gray rectangle that + contains a green outer ring and a green inner button + with "SVG" on it, both having a 3D appearance. +
++ Verify that a typical usage of filtering is operation. + This test case creates a 3D lighting effect and requires + that several filters are working: feGaussianBlur, feOffset, + feSpecularLighting, feComposite and feMerge. The graphic + consisting of the string "SVG" sitting on top of oval + filled in green and surrounded by an oval outlined in green. +
++ The test uses a nested 'svg' element, 'rect' element, + 'path' element, as well as basic fill (solid + colors), stroke (solid colors with stroke-width + lines), font-family (Verdana and Arial) and font-size properties. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image + exactly, except for possible variations in the labelling + text (per CSS2 rules). +
++ Test which verifies null filters and filter regions. +
++ Four subtests each consist of a small red circle overdrawn with a larger green circle. + Filters are applied to three of the red circles, hiding them and showing the green circle. +
++ The top left subtest has no filter applied to the circle, so the green circle is visible and the red one is not. + The top right subtest applies a filter to the red circle, but there is no corresponding filter element. + Thus, a null filter is applied and the red circle is not shown, allowing the green circle to be seen. +
++ The bottom left subtest applies an empty filter element with the default filterRegion, and the bottom right + subtest applies an empty filter with a non-default filterRegion. In both cases where empty filters are applied, + the result of the filter is a transparent black offscreen, thus showing the green circle underneath. +
++ Run the test. No interaction required. +
++ The test is passed if there are four green circles visible. +
++ This tests the 'primitiveUnits' attribute and how it affects other attribute values. +
++ You should see three rectangles in a row, then a row of three circles, then a row of three stars. +
++ The test has passed if: +
++ In the upper left corner of the output are blue and yellow rectangles that overlap, + they appear normally, no gaussianBlur has been applied. + In the upper right the same rectangles are displayed with a blur filter applied, + the standard deviation is the same for both the x and y axis. + In the lower right corner the rectangles appear again, + this time the standard deviation is different along the x (20) and y (1) axis. +
++ On top of the rectangles in the upper right and lower right, thin (half-pixel-wide) blue + lines are drawn to show the outline of the object bounding box (the inside lines) and the + outline of the filter region (the outside lines). The blur effect should be clipped + to the bounds of the filter region. +
++ The test uses the 'rect' element, as well as basic fill (solid primary colors), + stroke (black 1-pixel and blue half-pixel lines), font-family (Arial) and font-size properties. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ Test that when 'stdDeviation' is zero in one of X or Y the filter input image is + blurred only in the non-zero direction. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test that when 'stdDeviation' is zero the result is a non-blurred image. +
++ Run the test. No interaction required. +
++ The test is passed if there's a green rectangle visible, and no red. +
++ An image should be displayed in the middle of the view area. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image. +
++ Tests the animatability of 'xlink:href' on the 'feImage' element. + The test will first show two blue images that should look exactly the same, + then after two seconds both images should simultaneously change to show two + pink images that also look exactly the same. +
+Run the test. No interaction required. + +
++ The test has passed if: +
++ This tests the feImage element with a number of different filter primitive subregion values. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ This tests the feImage element with a number of different filter primitive subregion values. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ This test verifies the implementation of the preserveAspectRatio attribute on <feImage> + referencing raster content. +
++ This test copies coords-viewattr-02-b, substituting feImage for image. + It exercises the various preserveAspectRatio values. An external bitmap + is referenced. +
++ The rendered picture should match the reference image exactly except for variations in the labeling text. +
++ Verify the basic operation of the different lights used in the feDiffuseLighting + and feSpecularLighting elements. The test uses the same feDiffuseLighting filter, + using different lights. +
++ The first row shows different settings for feDistantLight. The second row shows + different settings for fePointLight. The last row shows different settings for + feSpotLight. +
++ Run the test. No interaction required. +
++ The rendered image should look approximately like the reference image, except for the last + feSpotLight test for which a reference image could not be created. The reference image may not be pixel accurate. However, the rendered image should show + at least 'similar' lighting results and bump maps. +
++ This test verifies that the 'azimuth' attribute is interpreted as a clockwise value in degrees. +
+The test should show four arrows, indicating the direction of the incoming distant light. + As the four circles are lit by a specular lighting filter a faint shaded arc should appear. + The middle of each such arc should be where the corresponding arrow points.
++ Run the test. No interaction required. +
++ The test has passed if the shaded arcs are displayed only on the side indicated by the arrows. +
++ Test resolving of 'primitiveUnits' on the 'z' attribute of 'fePointLight'. +You should see some shapes that have a black border, three circles and three rectangles. + The fill of these shapes should look the same. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ Test various values for limitingConeAngle in feSpotLight. +
++ There should be four rects in two rows. Each of the rects has a different filter applied, + and each of those filters uses different values for limitingConeAngle. +
++ Run the test. No interaction required. +
++ The rendered image should look approximately like the reference image, and the third rectangle from the left + in each row must be animated. +
++ This test verifies that the 'elevation' attribute is interpreted as a + complementary value to the z-axis in degrees. +
++ The test shows four different elevation angles that can be used for feDistantLight source. + The four different feDistantLight light sources are used in three different filter cases; feDiffuseLight, feSpecularLight + and feMerge which merges both feDiffuseLight and feSpecularLight to form a single filter. Using four different elevation values + in three different filter cases gives twelve different filters. All twelve filter cases are applied to a vector graphic and + then to a raster graphic. The vector graphic results are shown to the left and the raster graphic results are shown to the right. +
++ Run the test. No interaction required. +
++ The test has passed if +
++ If the test shows any red, the test has failed. +
++ Test which verifies the basic facilities of feMorphology. +
++ The test shows the same graphics filtered with four different feMorphology + settings. The top two have the type erode and a radius of 1(left) and 2(right). + The bottom two have the type dilate and a radius of 1(left) and 3(right). +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ The target crosshairs should align with + lower left bounds of the associated circle. + The color of each crosshair should match + the associated circle. +
++ Verify the basic capability to handle the feOffset, feMerge and + feFlood filter nodes. Four copies of a filled circle should appear at + various offsets and colors. For each circle a reference crosshair is + drawn at the lower left of the circle to indicate the expected color, + opacity and position for the filtered element. The targets are drawn + with the standard svg path element. +
++ In addition to feFlood, feMerge, and feOffset, this test uses + 'feComposite' to recolor the SourceGraphic with the feFlood color. + The source graphic uses 'circle'. The target cross hairs are drawn + with 'path' and use 'fill' and 'fill-opacity'. +
++ Run the test. No interaction required. +
++ The rendered image should match the reference image. Additionally, the + target crosshairs should match the color, lower left corner, and + opacity of each copy of the filtered circle. +
++ Tests primitiveUnits="objectBoundingBox" and relative values. +There should be three green rectangles with thick black stroke. +
+Run the test. No interaction required. + +
++ The test has passed if there is nothing red visible and there are three + green rectangles with black stroke. If any green is visible outside the + black stroked rectangles the test has failed. +
+The purpose of this file is to test the 'in' attribute on filter primitives.
++ Run the test. No interaction required. +
++ To pass this test, the UA must render all 6 cases (SourceGraphic, SourceAlpha, BackgroundImage, BackgroundAlpha, FillPaint, StrokePaint) correctly. +
++ The purpose of this file is to test the 'in' attribute on filter primitives. + This test is the same as filters-overview-01-b.svg but uses gradients with gradientUnits="userSpaceOnUse" instead for the + FillPaint/StrokePaint. +
++ Run the test. No interaction required. +
++ To pass this test, the UA must render all 6 cases (SourceGraphic, SourceAlpha, BackgroundImage, BackgroundAlpha, FillPaint, StrokePaint) correctly. +
+The purpose of this file is to test the 'in' attribute on filter primitives.
++ Run the test. No interaction required. +
++ To pass this test, the UA must render all 6 cases (SourceGraphic, SourceAlpha, BackgroundImage, BackgroundAlpha, FillPaint, StrokePaint) correctly. +
++ Verify the basic operation of the feSpecularLighting element. The test shows + four rows of 3 images. Each row tests a different aspect of the filter and + shows the result of the filtering operation. +
++ The first row shows the result of varying the surfaceScale attribute. The second + row shows the result of varying the specular constant (ks) attribute. The third + row shows the result of varying the specular exponent (np) attribute. The last + row shows the result of varying the lighting-color property. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image. +
++ The test case constructs a filter that uses feTile to tile the entire specified filter region. + The tile consists of a green rectangle over a larger transparent rectangle. + The green rectangle is created with feFlood and feOffset. There is also a semi-transparent + blue rectangle that should exactly cover one of the tiled rectangles, creating a purple + tile with a black stroke (4 tiles down and 3 across). +
++ The test uses the 'rect' element, feTile, feFlood, feOffset, feMerge, fill style, stroke, + font-family and font-size properties. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for possible variations + in the labelling text (per CSS2 rules). +
++ Test which verifies the basic facilities of feTurbulence. Six rectangular areas showing the + effects of various parameter settings for feTurbulence. The sample image indicates the + parameter settings to produce the given image. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for possible variations + in the labelling text (per CSS2 rules). +
++ This tests the 'seed' attribute on 'feTurbulence'. +
++ Run the test. No interaction required. + +
+You should see three rectangles with black stroke. In each of these rectangles there should be + a series of numbers indicating the value for 'seed' that was used on the small rectangle + directly above the number. The top stroked rectangle should contain 7 smaller rects that all + have a different filter applied to them, the lower two rectangles should contain 2 smaller rects + each. The filtered rectangles in each stroked rectangle should all look exactly the same. + If the filtered rectangles are red, that indicates that the test has failed. +
++ The test has passed if: +
++ This tests case show the behaviour of CSS font matching + based on the font-size attribute. +
+ ++ Run the test. No interaction required. +
++ The most correct output is + two squares, the exact match of the size, but as these are + vector fonts, and therefore scalable, the user agent can + use a margin of error, so conformant results may vary. +
++ This tests the behaviour of CSS font matching based on font-variant attribute. +
++ The first line of text tests that the small-caps font is used for the second text element. +
++ The second line of text tests that the order of font specification does not effect the selection + of these fonts. +
++ The third line of text tests that the correct font is selected when a font in the list does not support + the variant required. Note that the fonts provide no x-height so scaling + (allowed by CSS) cannot be used to simulate a small cap from a regular font. +
++ The last line tests if small-caps are synthesized. +
++ Run the test. No interaction required. +
++ The first line of text should be 'square' 'triangle'. +
++ The second line of text should be 'square' 'triangle'. +
++ The third line of text should be 'square', 'diamond', 'square', 'diamond'. + Note that the fonts provide no x-height so scaling + (allowed by CSS) cannot be used to simulate a small cap from a regular font. +
++ The last line of test can be 'square', 'a', 'a' (from a fallback font), + 'diamond'. The first 'a' + can be replaced with a smallcaps 'A', if there is a smallcaps font installed + or if synthesis is supported. +
++ This test demonstrates CSS font matching based on the + font-weight attribute. +
++ The first line tests selecting a bold font. +
++ The second line tests that order of font definition does not + effect selection. +
++ The last line tests basic font-weight selection using + font-weight numbers. +
++ Run the test. No interaction required. +
++ The first line should show a square and then a triangle. +
++ The second line should show a triangle and then a square. +
++ The last line should show a square then a triangle. +
++ This test demonstrates CSS font matching based on the + font-style attribute. +
++ The first line of text tests selecting an italic font. +
++ The second line tests that order of font definition + does not effect correct matching. +
++ The third line tests selecting an italic and an oblique font. + Italic can match against oblique or italic, but all other values must match exactly. + The letter 'a' will be an UA-dependent default font-family, + it should be oblique, possiblely a transformation of a + normal font. +
++ Run the test. No interaction required. +
++ The first line of text should produce a square followed + by a triangle. +
++ The second line should produce a square followed + by a triangle. +
++ The third line should produce in first place + either a triangle, a diamond, or a letter 'a' in some fallback font. + (All are correct,and depend on which font is chosen for fallback). + This is followed by two diamonds. +
++ This tests a combination of font attribute matching. +
++ Run the test. No interaction required. +
++ The correct result for the first line is diamond, diamond, upward-triangle, + downard-triangle. The correct result for the second line is + upward-triangle, downard triangle, and a right-triangle. +
++ Reasoning for glyphs on the first line: + The first character is a diamond because it is matched purely + on the font-style attribute. The second character is a diamond + because font-style (italic) is of highest precedence, followed + by font-variant (normal), then font-weight (bold). The third + character matches upward-triangle because again font-variant + (small-caps) is a higher precedence than font-weight. The + fourth character undisputedly matches the downward-triangle. +
++ Reasoning for the glyphs on the second line: + The first character is a upward-triangle because the font + matching must fall back to SVGFont1 to get a match + for small-caps. The second character is a downward-triangle + because there is no match for small-caps in SVGFont2. + The third character is a right facing triangle because + italic should match oblique in SVGFont2. +
++ This is a basic test for embedded SVG fonts. The font "Comic Sans" + (available from Microsoft) has been converted into an SVG font and embedded + in the SVG file. The test contains two text areas, each with the character + string "AyÖ@ç" drawn at the same font size. +
++ The upper area contains the glyphs from the embedded font placed in + the SVG file as path elements. Each glyph is placed at the location it + would be if rendered using normal text rendering (ie. the horizontal + advance between characters has been preserved). +
++ The lower area contains the text string rendered using the embedded + SVG font. It should appear exactly the same as the upper text area, + ie. font size, character baseline and horizontal advance should be + the same. +
+Run the test. No interaction required.
++ The test passes if the string "AyÖ@ç" is visible and fontsize, + character baseline and horizontal advances are the same on both lines, + as shown in the reference image. +
++ This is an accuracy test for embedded SVG fonts. The font "Comic Sans" + (available from Microsoft) has been converted into an SVG font and embedded + in the SVG file. The test contains two text areas, each with the character + string "AyÖ@ç" drawn at the same font size. +
++ The upper area has the placed glyphs as path elements filled with + white over a solid black background (creating a white cutout). The + embedded SVG font text is then drawn over the cutout. +
++ The lower area is the reverse of the upper area, with the placed + black glyphs filling the cutout created by white SVG font text. + An implementation that passes this test should completely fill the + cutout, leaving a solid black area (some slight antialiasing effects + may remain). +
+Run the test. No interaction required.
++ The test is passed iff the black text exactly overlays the white text + on black, giving a solid black area. Some slight antialiasing effects may + remain and do not cause the test to fail. +
++ This is a basic test for external SVG fonts. The font "Comic Sans" + (available from Microsoft) has been converted into an SVG font and placed + in an external SVG file referenced by a font-face-src element. + The test contains two text areas, each with the character + string "AyÖ@ç" drawn at the same font size. +
++ The upper area contains the glyphs from the font placed in + the SVG file as path elements. Each glyph is placed at the location it + would be if rendered using normal text rendering (ie. the horizontal + advance between characters has been preserved). +
++ The lower area contains the text string rendered using the external + SVG font. It should appear exactly the same as the upper text area, + ie. font size, character baseline and horizontal advance should be + the same. +
++ Run the test. No interaction required. +
++ The test passes if the upper and lower lines show the same glyphs with + the same glyph positioing and inter-glyph spacing. +
++ This is a basic test for external SVG fonts. The font "Comic Sans" + (available from Microsoft) has been converted into an SVG font and placed + in an external SVG file referenced by a CSS stylesheet with an @font-face rule. + The test contains two text areas, each with the character + string "AyÖ@ç" drawn at the same font size. +
++ The upper area contains the glyphs from the font placed in + the SVG file as path elements. Each glyph is placed at the location it + would be if rendered using normal text rendering (ie. the horizontal + advance between characters has been preserved). +
++ The lower area contains the text string rendered using the external + SVG font. It should appear exactly the same as the upper text area, + ie. font size, character baseline and horizontal advance should be + the same. +
++ Run the test. No interaction required. +
++ The test passes if the upper and lower lines show the same glyphs with + the same glyph positioing and inter-glyph spacing. +
++ This tests the horiz-origin-x attributes on the font and glyph elements. +
+Run the test. No interaction required. +
++ There are three subtests. The test is passed if for each subtest there is labelling text on the left and on the right, a series of black squares whose lower-left corner aligns with the centre of the corresponding small, pale blue square as shown in the reference graphic. +
++ This test validates that the font element's horiz-adv-x is used as + the default glyph's advance when there is no glyph advance specified. + All fonts have a units-per-em of 1000. +
++ The first row shows a layout with a default advance of 1000. + Glyphs have no advance so the 1000 default should be used. +
++ The second row shows a layout with a default advance of 2000. + Glyphs have no advance so the 2000 default should be used. +
++ The last row shows a layout with a default advance of 0. + Glyphs have a specified advance so the 0 default should be ignored. +
++ Blue reference markers show the expected glyph positions. +
+Run the test. No interaction required. +
++ There are three subtests. The test is passed if for each subtest there is labelling text on the left and on the right, a series of black squares whose lower-left corner aligns with the centre of the corresponding small, pale blue square as shown in the reference graphic. +
++ This is a basic test for embedded SVG fonts. The font "Comic Sans" + (available from Microsoft) has been converted into an SVG font and embedded + in the SVG file. The test contains two text areas, each with the character + string "AyÖ@ç" drawn at the same font size. +
++ The upper area contains the glyphs from the embedded font placed in + the SVG file as path elements. Each glyph is placed at the location it + would be if rendered using normal text rendering (ie. the horizontal + advance between characters has been preserved). +
++ The lower area contains the text string rendered using the embedded + SVG font, referenced with a CSS @font-face declaration. The SVG font does not have a font-family attribute, so the reference is via the @font-face block which points to a font element by ID. It should appear + exactly the same as the upper text area, + ie. font size, character baseline and horizontal advance should be + the same. +
+Run the test. No interaction required.
++ The test passes if the string "AyÖ@ç" is visible and fontsize, + character baseline and horizontal advances are the same on both lines, + as shown in the reference image. +
++ The first subtest tests the arabic-form attribute on the glyph element, + the second subtest is the same, but with glyphs for the letter khah. + It should match the reference image. +
++ Run the test. No interaction required. +
++ The first subtest must produce a + 'downward triangle', a 'space', a 'square', a 'diamond' + and then an 'upward triangle' in this order. Remembering + that arabic text is right to left. +
+The second subtest must produce the isolated, initial, medial, final and + glyphs of the letter khah. Again in the writing direction, from right to left. +
+ISSUE: http://www.w3.org/2011/02/27-svg-irc#T22-20-51 - unapprove test for now
++ This files tests the lang attribute support of the glyph + element. The test should produce an upward-triangle for + the first (en) test element and a square for the second (fr) + and third (fr-ca) text element. In the third case, a glyph for + fr is also suitable for a more specific language text fr-ca. + In the fourth case, no suitable language specific or general + glyph is provided by the test so a fallback font for the letter + 'a' should be used. A triangle or square must not be + displayed in the fourth case. +
+Run the test. No interaction required.
++ The test is passed if, from top to bottom, you see an upward pointing triangle, then two squares, and finally the letter "a". +
++ This tests that glyph selection is done in the + order in the definition of the font element. + The first line of text should be represented by + two triangles and an 'l'. The second line should + be represented by a square. +
+Run the test. No interaction required.
++ The test is passed if on the first line you see two upward pointed triangles + followed by the letter "l". On the second line, a single square. +
++ This test validates handling of the hkern element. +
++ In all instances, a text element matching a font with hkern + is displayed along with reference markers showing the expected + glyph positioning. +
++ The 'fontA' cell shows the string "12" with "fontA" for which there + in a kerning pair defined with u1="1" and u2="2". +
++ The 'fontB' cell shows the string "12" with "fontB" for which there + in a kerning pair defined with g1="gl_1" and g2="gl_2", + where "gl_1" has unicode="1" and "gl_2" has unicode="2". +
++ The 'fontC' cell shows the string "1234" with "fontC" were the same kerning pair + uses u1/u2 to match "12" and g1/g2 to match "34". +
++ The 'fontD' cell shows the string "1234" with "fontD" were the same kerning pair + uses u1/u2 to match "12" and "34" (u1/u2 are lists of character vales). +
++ The 'fontE' cell shows the string "1234" with "fontE" were the same kerning pair + uses g1/g2 to match "12" and "34" (g1/g2 are lists of names). +
++ The 'fontF' cell shows the string "1234" with "fontF" were the same kerning pair + uses u1/u2 to match "12" and "34" (u1/u2 are unicode ranges). +
++ The 'fontG' cell shows the string "12" with "fontG" were for which there + is a kerning pair with u1 matching "1" and g2 matching "gl_2". +
+Run the test. No interaction required.
++ The test is passed if for each of the seven subtests there is a series of black squares whose lower-left corner aligns with the centre of the corresponding small, red square as shown in the reference graphic. +
++ This tests a range of values for the 'units per em' attribute. +
++ The same glyph is defined three times in three fonts, but with different values + for units-per-em - 1,000, 10, and 10,000 - and with the other numerical values + that depend on units-per-em scaled accordingly. Text using these fonts must all be displayed at the same size, + because the same font-size is used throughout. +
++ Run the test. No interaction required. +
++ The test is passed if the three letter β are all the same size. +
++ Tests that markers are drawn on zero-length 'path' and 'line' segments. +
+Run the test. No interaction required.
++ Test passes if there are two blue boxes, positioned as in the reference image. +
++ Purpose of test is to determine if the cursor property and cursor element are + supported. +
++ This test requires user interaction. Firstly, the default cursor behaviour should be examined. + Move the cursor to the top left corner, in the white area. This is the default + cursor. Now move the cursor over the text at the top of the example. The cursor + changes to the text cursor. Lastly, move the cursor to the blue link + text - the cursor changes to the pointer cursor. +
++ Now, move the cursor in turn to each of the gray rectangles (but not on top + of the white text label text). From top to bottom in the first row, the cursor + should change to: +
++ A crosshair or other 'accurate positioning' cursor + The 'default' cursor, as noted above + The 'pointer' cursor, as noted above + A cursor indicating movement, such as panning +
+Now from top to bottom in the second row, the cursor should change to:
++ The 'text' cursor, as noted above + A 'wait' cursor + A 'help' cursor + A special cursor which looks like a small magnifying glass. This is a downloaded image cursor. + +
++ Moving to the bottom-leftmost of the eight red triangles, and moving around them clockwise, the + cursor should change to: +
++ SouthEast-resize, South-resize, SouthWest resize, West-resize, + NorthWest-resize, North-resize, NorthEast-resize, East-resize. +
++ Lastly, move the cursor to the target in the bottom-right of the test. The cursor must not + change to the 'pointer' cursor, but instead to the custom magnifying glass cursor as noted + above. +
++ The test is passed if, at each position, the cursor changes as described in the operator script. +
++ Verify basic support for DOM event listener registration. The root svg element + has an onload handler where a click event listener is registered on group element 'Start Button'. +
++ If UI events listener registration is supported (and UI events), + when the user clicks on the button a text node is inserted reading "Event Listeners supported". +
++ At the end of the test, the start test button is changed to green, + and the click event listener is removed from the the start button. +
++ Subsequent clicks on the start button should cause no effect if + the event listener has been removed successfully. + If additional lines of text appear in the document that say "Event Listeners supported", + then the implementation has not successfully removed the event listener. +
+This test requires user interaction. Run the test, then click on the grey rectangle. + If it turns green, click it again. +
++ After clicking once on the button, the rectangle should have a green fill + and the text "Event listeners supported" should appear, once. + +
++ Test 'onload' event attribute. +
++ Six blue rectangles have been defined, each initially defined with + 'visibility:hidden'. 'onload' event attributes are assigned in + a variety of ways, usually to set 'visibility:visible'. + The red text indicates the correct behavior + (whether a given rectangle should appear in the visual result). +
++ The first rectangle has no associated 'onload' event so it remains invisible. + The second rectangle has an 'onload' event on itself, which invokes a script + which sets 'visibility:visible', so it should appear. + The third rectangle has an 'onload' event on its parent 'g', which invokes a script + which sets 'visibility:visible' on the rectangle, so it should appear. + The fourth rectangle has an 'onload' event on an ancestor 'svg', which invokes a script + which sets 'visibility:visible' on the rectangle, so it should appear. + The fifth rectangle has an 'onload' event both itself and its parent 'g'. + The rectangle's script sets 'visibility:visible' on the rectangle + but the parent's script sets 'visibility:hidden' on the rectangle, + which should happen afterwards, so the rectangle should not appear. + The sixth rectangle has an 'onload' event on the outermost 'svg', which invokes a script + which sets 'visibility:visible' on the rectangle, so it should appear. +
+Run the test. No interaction required.
++ The test is passed if blue squares are visible for subtests 2, 3, 4 and 6 (only) +
++ This tests that the SVGLoad event does not bubble. +
++ After loading the tests, two rectangles are displayed. + The left rectangle indicates whether the SVGLoad event + dispatched to the root 'svg' element did not bubble + and the right rectangle indicates whether the SVGLoad + event dispatched to an 'image' element did not bubble. + Each rectangle is red if the sub-test failed or green + if it passed. +
+Run the test. No interaction required.
++ The test is passed if both rectangles are green + once the document has loaded. +
++ Testing event bubbling through 'use' element. +
++ Mouseover the blue rect, then the green rect and then away from the rects. +
++ Moving the mouse over the blue rect should make a yellow rect visible underneath it. + Moving the mouse over the green rect should make a purple rect visible underneath it. + Moving the mouse away from the blue/green rect should hide the rect underneath it again. +
+Tests 'mouseover' event on SVGElementInstance
++ What each case tests is as follows. + Case 1: mouseover event on SVGElementInstance. Referenceing an element that contains an event. + Case 2: mouseover event on referencing element. Event bubbling from SVGElementInstance to referencing element. + Case 3: mouseover event on parent of referencing element. Event bubbling from SVGElementInstance to referencing element ancestors. + Case 4: mousedown event on referencing element. SVGElementInstance is not effected by event listener on referencing element. +
++ Mouseover each of the red rectangles, and then click on the bottommost rectangle. +
++ This test contains four cases. The cases must produce the following results for the test to pass. +
++ Test event bubbling of event attributes, part a. +
++ The two circles test whether event bubbling is occurring + to parents of the target object, and whether the target object + is able to prevent bubbling. The supplemental text next to + the circles describes what should occur. +
+This test requires user interaction. Firstly, move the pointer + over the top circle. Then, move it over the bottom circle.
++ The test is passed if two black circles are displayed. The top circle +must turn pink when the pointer is over the circle, and go back to black once +the pointer leaves. The second circle must turn blue when the pointer is over +the circle, and go back to black once the pointer leaves. +
++ Test event bubbling of event attributes, part b. +
++ The two circles test whether events are handled in the + proper order. Events listeners and event attributes are processed + before hyperlink processing, which is processed before text selection. + +
+Click on the first circle, then the second, and lastly the new third circle.
++ Clicking on the first circle should change the circle from black to red. Clicking + on the second circle should take you to another SVG file titled "Hyperlink target for + interact-order-02.svg. Cliking on the circle in this SVG file should return you to the orginal + two circles. +
++ Test event bubbling of event attributes, part c. +
++ The three strings tests event handling behavior on text. + Text selection only is available after event listeners and event + attributes have been processed, and after hyperlink processing + has occurred. +
++ First, click the string on the first line; then the second. Lastly, all text should be selectable. +
++ The supplemental text below the text strings describes what should occur. +
++ This test tests 'pointer-events' on text. Initially you should see four big rects with black stroke. + In the uppermost rect there should be 10 'O':s with black fill. + In the second rect from the top there should be 10 'O':s with no fill but with black stroke. + In the third and fourth rects there should be no visible 'O':s at all. + In the fourth rect there should be two green rects, and in each of the other three rects there should be one green rect. +
++ For UA debugging purposes it's possible to click the "Toggle freeze" button before running the test. + That will reset the visibility, fill and stroke on each 'O' as the cursor moves over them so that it's + possible to trigger the change more than once. If the "Toggle freeze" button is clicked once again that + means the change will remain after the cursor moves out. +
++ Using the pointer device move the cursor over the rects all the rects from left to right. + As the mouseover event triggers the 'O':s will become visible and marked in either green (a pass) or red (a fail). +
++ The test has passed if after moving the cursor over all the rects: +
+Tests that pointer events are not delivered to text elements when the pointer is + over any white space due to letter-spacing.
+For each line of text, slowly move the mouse from left to right over and between all of the visible glyphs. + When the mouse is at various points along each line of text, the text will become green.
+For all of the lines of text, when the mouse is over a visible glyph, that line of text + must be green. When the mouse is between the visible glyphs, it must be either green or + black as follows:
++ Tests where text is considered intersected by the cursor when letter-spacing is used. +
++ The first two lines should look the same, but the second line is using a slightly different svgfont that defines an empty path for the space glyph. +
++ The third line doesn't have any spaces, just letter-spacing, so there are no glyphs in between the letters. Hovering the whitespace between the letters should not highlight the line. +
++ The fourth line has a space glyph between the other glyphs, and letter-spacing. +
++ The fifth line has no spaces only letter-spacing. +
++ Slowly move the mouse over the characters on each row. +
++ Tests when text is considered hit by pointer-events. + According to SVG 1.1 pointer-events on text is not supposed to use the text boundingbox, instead it should use the 'character cells'. +
+Consider each of the two light blue boxes to be divided up into nine vertical strips: + five consisting of areas just wide enough to fit each of the glyphs, and four + consisting of the white space between those five other strips. For each of these + vertical strips, move the mouse slowly from the top of the light blue box to the bottom, + keeping the mouse within the strip. At various points, all of the glyphs within + the box will be green and at others they will all be black.
+When the mouse is over a glyph, then all of the glyphs within the light blue box + must be green.
+When the mouse is within one of the white space strips, then all of the glyphs + within the light blue box must be black.
+When the mouse is within the strip containing the first, second or fourth + glyph ("@", "A" or "Ö") and it is below the glyph, then all of the glyphs + within the light blue box must be black.
+When the mouse is within the strip containing the second, third, fourth or + fifth glyph ("A", "y", "Ö" or "ç") and it is above the glyph, then all of the glyphs + within the light blue box must be black.
+Testing pointer-events and rendering order
++ Move the mouse over the blue and purple shapes. Click the red circle on the top left. Move the mouse over the blue and purple shapes again. +
++ For the test to pass the blue rectangles must always turn red on mouseover, and the ovals must turn red on mouseover only if pointer-events are set to "ALL". + If a shape other than the one currently hovered turns red then the test has failed. +
+Tests the pointer-events attribute with different 'visible' values, same as the interact-pevents-201-t test but with script instead of declarative animation
++ The 2nd and 3rd columns represent respectively rects with no fill/stroke and transparent fill/stroke. + The 4th column (most right column) has a non activatable pointer event as the visibility of the column + is set to hidden. +
++ The first row tests the default value for pointer-event, i.e. visible fill and stroke will trigger an event. + The second row tests pointer-events="visiblePainted", i.e. visible fill and stroke will trigger an event. + The third row tests pointer-events="visibleFill", i.e. visible fill only an event. + The fourth row tests pointer-events="visibleStroke", i.e. visible stroke only an event. + The fifth row tests pointer-events="visible", i.e. visible fill and stroke will trigger an event. +
++ Slowly move the mouse over the rectangles in each row while checking the pass criteria. +
++ The test is passed if the following conditions are met: +
+Tests the pointer-events attribute with different painting values, same as the interact-pevents-202-t test but with script instead of declarative animation
++ The 2nd and 3rd columns represent respectively rects with no fill/stroke and transparent fill/stroke. + The 4th column has visibility set to hidden. +
++ The first row tests pointer-events="painted", i.e. event on fill and stroke that are set. + The second row tests pointer-events="fill", i.e. event on a fill that is set. + The third row tests pointer-events="stroke", i.e. even on a stroke that is et. + The fourth row tests pointer-events="all", i.e. event on fill and stroke that are set. + The fifth row tests pointer-events="none", i.e. no event. +
++ Slowly move the mouse over the rectangles in each row while checking the pass criteria. +
++ The test is passed if the following conditions are met: +
++ An element with 'display' set to 'none' or an element whose parent has 'display' set to 'none' is not a target of pointer events. +
++ Stack a 'circle' element with 'display' equal to 'none' on another 'circle' element. + Specify an 'onclick' event handler on the 'circle' with 'display' set to 'none' that will change the 'visibility' of 'FAIL' text to 'visible'. + Verify that the event handler does not fire which clicking on the top 'circle' element. + Repeat with another set of 'circle' elements with the parent of one of the 'circle' elements having its 'display' set to 'none'. +
++ Click on both black circles. +
++ Test passes if there is no red visible on the page after clicking the black circles. +
++ This tests that zero opacity pixels in a mask do not affect + hit testing for the purpose of pointer event targetting. +
++ After loading the test, a rectangle will be displayed. + Move the pointer over the rectangle, and it will change color + to indicate whether the test was passed. +
++ If the rectangle turns green once the pointing device is moved over it, + the test was passed. If instead it turns red (or remains black), + then the test failed. If the rectangle was initially red when + the document was loaded, then that also indicates that the test failed. +
++ This tests that clipped-out parts of shapes do not receive pointer events. +
++ After loading the test, a rectangle will be displayed. + Move the pointer over the rectangle, and it will change color + to indicate whether the test was passed. +
++ If the rectangle turns green once the pointing device is moved over it, + the test was passed. If instead it turns red (or remains black), + then the test failed. If the rectangle was initially red when + the document was loaded, then that also indicates that the test failed. +
++ This tests that the "painted" keyword for the pointer-events property + does not cause pointer events to be captured when a shape's fill falls + back to "none" because a referenced paint server was not available. +
++ After loading the test, a rectangle will be displayed. + Move the pointer over the rectangle, and it will change color + to indicate whether the test was passed. +
++ If the rectangle turns green once the pointing device is moved over it, + the test was passed. If instead it turns red (or remains black), + then the test failed. If the rectangle was initially red when + the document was loaded, then that also indicates that the test failed. +
++ +
++ +
++ +
++ +
++ Verify correct handling by Dynamic (interactive) viewers for the + "zoomAndPan" attribute on the 'svg' element. This is the second of three + tests, and tests the default value. +
++ The test consists of a set of black circles with a blue stroke. +
++ After the initial picture is displayed, the user should attempt to use + the magnify controls that are required on conforming Dynamic SVG + viewers. +
++ The correct behaviour is that magnification and panning works + correctly, as required by a conformant viewer. +
++ Verify correct handling by Dynamic (interactive) viewers for the + "zoomAndPan" attribute on the 'svg' element. This is the second of three + tests, and tests the value "magnify". +
++ The test consists of a set of black circles with a blue stroke. +
++ After the initial picture is displayed, the user should attempt to use + the magnify controls that are required on conforming Dynamic SVG + viewers. +
++ The correct behaviour is that magnification and panning works + correctly, as required by a conformant viewer. +
++ Verify correct handling by Dynamic (interactive) viewers for the + "zoomAndPan" attribute on the 'svg' element. This is the third of three + tests, and tests the value "disable". +
++ The test consists of a set of black circles with a blue stroke. +
+ + ++ After the initial picture is displayed, the user should attempt to use + the magnify controls that are required on conforming Dynamic SVG + viewers. +
++ The correct behaviour is that the magnify and pan controls + shall have no effect -- the viewer shall disable them. +
++ This is the first of a set of three tests that verify the capability to + handle links into SVG content, using + each of the three fragment identifier forms permissible in SVG. +
++ There is a colored arrow comprising the content of an 'a' element. The + link destination is in an auxiliary file, linkingCircle-f.svg, and + is expressed by xlink:href="linkingCircle-f.svg#fragmentValue". + The initial view of this test contains one pale blue arrow plus labelling text. +
++ The (blue) arrow uses the "bare name" fragment identifier + form, "#circle-2", to target the circle with id "circle-2" in the external + file. +
++ The user should activate the link on the center blue arrow. +
++ Upon clicking the first arrow, the full image of the linkingCircle-f.svg + file should replace the initial view of this test case in the viewer frame. +
++ The reference image illustrates the correct image after the link is + activated (full view of linkingCircle-f.svg). +
++ This is the third of a set of three tests that verify the capability to + handle links into SVG content, using + each of the three fragment identifier forms permissible in SVG. +
++ There is a colored arrow comprising the content of an 'a' element. The + link destination is in an auxiliary file, linkingCircle-f.svg, and + is expressed by "xlink:href=linkingCircle-f.svg#fragmentValue". + The initial view of this test contains one green arrow plus labelling text. +
++ The (green) arrow uses the SVG view specification form, + "linkingCircle-f.svg#svgView(viewBox(63,226,74,74))", + to target the circle with id "circle-2" + in the external file. +
++ The user should activate the link on the center green arrow. +
++ Upon clicking this arrow, circle-2 should fill most of the + viewer frame (white space on each side is 25% of the diameter of the circle). +
++ The reference image illustrates the correct image after the link is + activated, with the circle-2's + framing rect filling the viewer frame, uniformly scaled. +
++ Verify the capability to handle basic links out of SVG content + using the 'a' element, with the xlink:href attributes. + There are three subtests, in each of which one + of three colored arrows comprise the content of an 'a' element. The + link destination is expressed by "xlink:href=". + The initial view of this test contains the three arrows, a colored + circle, labelling text, and the usual template legend and frame. +
+ ++ There are several reference images associated with this test case. The first + illustrates the correct "start" or initial state of the rendered SVG file. + The second illustrates the correct image after the first link is activated + (to the linkingToc.svg file). The third (for browser-environment viewers) + should match the current image of the W3C home page, as viewed with a + conventional browser. (Note. This harness does not yet + provide access to multiple PNGs; the first, initial-state PNG is shown.) +
++ The test uses the 'rect' and 'polygon' elements, as well as basic fill (solid simple colors), + stroke (black and colored wide and 1-pixel lines), font-family (Arial) and font-size properties. +
++ The user should interact with each of the arrows activating each of the links, + using the UA's back mechanism to restart each link test. +
+ ++ The top-most (yellow) arrow links to an external SVG file, which is + local (in the same directory). The target file contains SVG 'text' elements + which comprise a TOC and brief description of all of the test files + for Linking. Upon clicking the first arrow, the image of the linkingToc-t.svg + file should replace the initial view of this test case in the viewer frame. +
++ The middle (green) arrow links to an object in this SVG test file, the yellow + circle (id="internal-circle") immediately to its right, using "#circle-object" + as the value of of the xlink:href attribute. + There should be no change to the viewer frame upon clicking this arrow. +
++ The bottom-most (blue) arrow links to remote non-SVG content, the W3C home page + using xlink:href attribute value "http://www.w3.org". For viewers in a Web + browser environment, the W3C home page should replace the initial view + of this test case in the browser/viewer frame. For other viewers (e.g., + interactive but SVG-only standalone viewers), the result is undefined, but could + include such actions as a diagnostic "Error parsing..." message. +
++ Verify if the 'a' element properly accept the transform + attibute. There are three subtests, in each of which one + of three sets of colored arrows comprise the content of + an 'a' element. The link destination is expressed by + "xlink:href=" as in the test 'linking-a-04-t.svg'. + The arrows transformed is in the brighter color, and the + arrows before transformation is shown in the darker color. + The transformation parameters used for each 'a' element is + shown on the left side of each arrow. +
++ The top-most arrow (yellow) is rotated for 20 degree. + The middle arrow (green) is skewed horizontally for + -30 degree, and the last arrow (cyan) is translated + for (-10, -20). +
+ ++ The test uses the 'rect' and 'polygon' elements, as well as basic fill (solid simple colors and RGB values), + stroke (black and colored wide and 1-pixel lines), font-family (Arial) and font-size properties. +
++ The user should interact with each of the arrows activating each of the links, + using the UA's back mechanism to restart each link test. +
++ Each arrow, i.e. link, should behave as described + in 'linking-a-04-t.svg'. The arrows in this test + have the same 'xlink:href' attribute as the 'linking-a-04-t' + test. +
++ Verify that the target attribute on the 'a' element takes precedence over the xlink:show attribute. + There are three subtests, in each of which two similarly + colored arrows comprise the content of an 'a' element. The arrow on the left, outlined + in blue, has no "target" attribute; the arrow on the right, outlined in red, has a + "target" attribute. The + link destination is expressed by "xlink:href=". + The initial view of this test contains the six arrows, labelling text, and the usual template legend and frame. +
++ The top-most (yellow) arrows link to an external SVG file, which is + local (in the same directory). The target file contains SVG 'text' elements + which comprise a TOC and brief description of all of the test files + for Linking. +
++ The middle (green) arrows links to the same external SVG file, but with xlink:show="new". +
++ The bottom-most (blue) arrows links to the same external SVG file, but with xlink:show="replace". +
++ Click each of the arrows once. +
++ The test has passed if: +
++ This is a simple test for links on text elements. The upper subtest has an 'a' element + inside a 'text' element; the lower subtest has the 'a' outside the 'text'. +
++ Click each of the links once. +
++ Both lines of text must be working links, and must take you to the linking TOC svg in the same frame. +
++ This is a simple test for links on tspan elements. The upper subtest has an 'a' element + inside a 'tspan' element; the lower subtest has the 'a' outside the tspan. +
++ Click each of the links once. +
++ Both lines of text must be working links, and must take you to the linking TOC svg in the same frame. +
++ Test that the 'a' element supports various types of graphics and container elements as content. +
+Run the test. No interaction required.
++ Test passes if there are fourteen blue shapes on the page, in the sizes and positions + shown in the reference image. +
++ Tests svgView(viewBox();transform()) syntax, with and without escaped semicolons. +
++ Run the test. Click on the green arrow. If that results in circle-2 being displayed, go back to this test and click on the blue arrow. If that shows a quarter of circle-2, go back to this test and click on the purple arrow. +
++ The test is passed if you clicked on three arrows, and clicking the purple arrow results in a quarter of circle-2 being displayed. +
++ Verify the capability to handle links to 'view' elements, and the + permissible attributes on those elements. All of the links in this + test case are internal, i.e., to 'view' elements in the same SVG file. +
++ This test is identical to linking-uri-02-b except that the links there are external. +
++ In the four quadrants of the initial picture are four graphical objects. + Clockwise from upper right, they are + a purple rectangle, blue ellipse, green polygon (pentagon), and yellow + circle. Each is labelled and tightly boxes with a rectangular frame. + These are identical to their counterparts in linking-uri-01-b.svg, in which + file each has an associated 'view' element, with attributes + per the labels in the initial picture. +
++ In the center is a gray box with four lines of text, each of which says + "Go to" followed by Rectangle, Ellipse, Polygon, and Circle, respectively. + Each of these is contained within an 'a' element, whose xlink:href names + the respective 'view' element of the respective graphical object. +
++ There are several reference images associated with this test case. The first + illustrates the correct initial state of the rendered SVG file, which should + also be the correct picture after the Rectangle link is executed. + The second, third, and fourth illustrate the correct images as described + above after respectively the Ellipse, Polygon, and Circle links are activated. + (Note. This harness does not yet provide access to multiple PNGs; the PNG for the + initial view is shown.) +
++ The test uses the 'rect', 'circle', 'ellipse', and 'polygon' elements, + as well as basic fill (solid simple colors), + stroke (black and colored 1-pixel lines), font-family (Arial) and font-size properties. +
++ In turn, activate each of the "Rectangle", "Ellipse", "Polygon" and "Circle" links + in the gray box in the middle of the document, navigating back (for example with + the Back button if in a browser) after activating each one. +
++ The test is passed if all of the sub-tests have the correct behavior: +
++ Verify the capability to handle links to 'view' elements, and the + permissible attributes on those elements. All of the links in this + test case are external, i.e., to 'view' elements in another SVG file. + That file is linking-uri-01-b.svg. +
++ This test is identical to linking-uri-01-b except that the links here are external. +
++ In the four quadrants of the initial picture are four graphical objects. + Clockwise from upper right, they are + a purple rectangle, blue ellipse, green polygon (pentagon), and yellow + circle. Each is labelled and tightly boxes with a rectangular frame. + These are identical to their counterparts in linking-uri-01-b.svg, in which + file each has an associated 'view' element, with attributes + per the labels in the initial picture. +
++ In the center is a gray box with four lines of text, each of which says + "Go to" followed by Rectangle, Ellipse, Polygon, and Circle, respectively. + Each of these is contained within an 'a' element, whose xlink:href names + the respective 'view' element of the respective graphical object. +
++ There are several reference images associated with this test case. The first + illustrates the correct initial state of the rendered SVG file, which should + also be the correct picture after the Rectangle link is executed. + The second, third, and fourth illustrate the correct images as described + above after respectively the Ellipse, Polygon, and Circle links are activated. + (Note. This harness does not yet provide access to multiple PNGs; the PNG for the + initial view is shown.) +
++ The test uses the 'rect', 'circle', 'ellipse', and 'polygon' elements, + as well as basic fill (solid simple colors), + stroke (black and colored 1-pixel lines), font-family (Arial) and font-size properties. +
++ In turn, activate each of the "Rectangle", "Ellipse", "Polygon" and "Circle" links + in the gray box in the middle of the document, navigating back (for example with + the Back button if in a browser) after activating each one. +
++ The test is passed if all of the sub-tests have the correct behavior: +
++ Verify the handling of the allowable xlink attributes on the 'a' element. + The initial view of this test contains a single green triangle, labelling text, + and the usual template legend and frame. +
++ The purpose of the test is to + verify that viewers tolerate the presence of xlink attributes on the 'a' + element. The presence of the attributes should not change the behavior of + the test in any way. +
++ There are two reference images associated with this test case. The first + illustrates the correct "start" or initial state of the rendered SVG file. + The second illustrates the correct image after the link is activated + (to the linkingToc-t.svg file). (Note. This harness does not yet + provide access to multiple PNGs; the first, initial-state PNG is shown.) +
++ The test uses the 'rect' element, as well as basic fill (solid simple colors), + stroke (black and colored wide and 1-pixel lines), font-family (Arial) and font-size properties. +
+Click on the center green triangle.
++ There is a link on the triangle, pointing to an external SVG file, which is + local (in the same directory). The target file contains SVG 'text' elements + which comprise a TOC and brief description of all of the BE test files + for Linking. Upon clicking the triangle, the image of the linkingToc-t.svg + file should replace the initial view of this test case in the viewer frame. +
++ The results of executing the link should be identical + to executing the first (topmost) link of linking-a-04-t. +
++ This tests that the 'filter' property does not apply to 'mask'. +
++ The mask 'm' covers a rectangular area (200 x 200) except for a window + (100 x 100) in the top left hand corner. Initially the mask window is + set on top of the green square. Hence, the green square is shown and + the red square is covered. If filters are supported the window within + the mask will be shifted by an offset of 100,100 placing it on top of + the red square. +
++ Run the test. No interaction required. +
++ The test passes if a green square is shown. If any + red shows, the test has failed. +
++ The rules are different regarding the geometry of a shape when clipping and masking. + For example, a clip-path does not take into account the stroke of the shape used for clipping. + It is however, used when masking. +
++ Run the test. No interaction required. +
++ The test is passed if there are two identical darkblue circles at the top of the illustration, and + below those two circles, two more circles should appear. They are of lighter appearance, + the one on the left has a darker and thick stroke. +
++ Test to see if the masking features using the mask element and mask + property are available. +
++ A red rectangle is displayed in the background to help view the result + of transparency and masking. +
++ From top to bottom, the tests are as follows. +
++ In the top test, a linear gradient is used inside the mask to change the opacity + of the rectangle from 1.0 (at the top) to 0.5 (at the bottom). +
++ In the second test, a simple 50% opaque rectangle is used as a mask. +
++ In the third test, no mask is used, but a rectangle is shown with 50% opacity. + The second and third test should look the same. +
++ Lastly, a string of text has a mask applied to it. The mask only covers a partial + area of the text, so the text should only be half visible. Also the mask consists + of 4 rectangles with various levels of opacity. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except + variations are possible in the labelling text (per CSS2 rules). +
++ If the 'mask' property references a 'mask' element containing no children, the element referencing it is not rendered. +
+Run the test. No interaction required.
++ Test passes if there is a single green rectangle, with no red visible on the page. +
++ Test to see the effect of applying an opacity property to a group. +
++ A blue rectangle with a green rectangle on top are contained in a + group. This opacity of the group and the opacity of the rectangles are + changed in this test. A red rectangle is provided in the background so + that opacity changes are obvious visually. +
++ From top to bottom, the tests are as follows. +
++ In the top test, the opacities of the group and the individual rectangles are + all set to 1. +
++ In the second test, the group is given an opacity of 0.5. +
++ In the third test, the group maintains a group opacity of 1 whereas each individual + rectangle is given an opacity of 0.5 in the group. +
++ Lastly, the group and individual rectangles are all given an opacity of 0.5. +
+ + ++ Run the test. No interaction required. +
++ In the top test, the green rectangle should appear on top of the blue + rectangle. +
++ In the second test, the blue + rectangle should not show through in the region where the green and blue overlap. +
++ In the third test, the blue rectangle + should show through in the overlap region. +
++ Lastly, the + result should be similar to the previous test only fainter (because the opacity) is + resulting in less contribution. +
++ The rendered picture should match the reference image exactly, except for possible + variations in the labelling text (per CSS2 rules). +
++ Test to see if the basic clipping works using the clipPath element + and the clip-path property. +
++ This test uses the following elements : <clipPath> and the following + properties : clip-path. +
++ Run the test. No interaction required. +
++ The test at the top shows an orange rectangle (with black stroke) being clipped by another rectangle. + So only the middle portion of the orange rectangle should be visible. Also the black stroke should + only be visible along the top and bottom edge of the rectangle. +
++ The example at the bottom has a group containing a text string and two rectangles. The group + has a clipping path defined using two overlapping rectangles. Of concern is the overlapping area + shared by the two rectangles. There should not be holes in this overlapping area, the + clip region is the union of the two rectangles. For clarity, + guide rectangles in grey show the position of the clipping rectangles. +
++ The rendered picture should match the reference image exactly, except for possible + variations in the labelling text (per CSS2 rules). +
++ Test to see if clipPathUnits attribute is handled properly on a + clipPath element. Only tests the userSpaceOnUse and + objectBoundingBox items of the clipPathUnits. userSpace has been + tested by the previous test as it is the default. +
++ The test at the top shows a pink rectangle that has been clipped by a + rectangular clipping path. The clipping path is defined using clipPathUnits=objectBoundingBox. + +
++ The example at the bottom a rotated blue rectangle that has been clipped by a + rectangular clipping path. The clipping path is defined using clipPathUnits=userSpaceOnUse. + +
++ The rendered picture should match the reference image exactly, except for possible + variations in the labelling text (per CSS2 rules). +
++ Run the test. No interaction required. +
++ The test passes if the pink rectangle and blue diamond do not have any + color painted outside of their black borders. +
++ Test 'overflow'/'clip' on outermost and inner 'svg' elements. +
++ There are two parts to the test. The first part tests viewport clipping + on outermost 'svg' elements. The second part tests viewport clipping + on inner 'svg' elements. +
++ The test case also tests the initial value of the 'overflow' property + to ensure that it is set to 'hidden' for all 'svg' elements. + Tester should zoom out and/or pan to check this. +
++ To test clipping to the outermost 'svg' element, + a rectangle with a light blue interior, a light red border and a black + string that says "Clip to outer 'svg'" is painted four times such that + it will overflow each of the top, left, right and bottom + sides of the bounds of the outermost 'svg' element, respectively. +
++ To test clipping to inner 'svg' elements, a rectangle with a light red + interior, a light blue border and a black string that says "Clip to + inner 'svg'" is painted four times such that it will overflow each of + the top, left, right and bottom sides of the bounds of an inner 'svg' + element, respectively. +
++ Note that minor text layout differences, as are permissible under CSS2 + rules, can lead to slightly different visual results regarding where + the text strings get clipped. +
++ Run the test. No interaction required. +
+The test passes if:
++ This test exercises basic user-specified clip paths, using a text + string (i.e., content of a 'text' element) as the clip path. +
++ There is a rectangular image of a swirly blue pattern with large + yellow text, "Clip Test" superimposed. The image is a PNG file, + imported into the picture via the 'image' element. +
++ The test uses the 'rect' element, as well as basic fill (solid primary + colors), stroke (black 1-pixel lines), font-family (Arial and + Impact) and font-size properties. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for + possible variations in the labelling text (per CSS2 rules). +
++ Test to see if clip-rule property has been implemented properly. +
++ The test at the top shows a red rectangle that has been clipped by a + clipping path that overlaps itself. +
++ The test at the bottom shows a blue rectangle that has been clipped by a + clipping path that overlaps itself. +
++ The rendered picture should match the reference image exactly, except for possible + variations in the labelling text (per CSS2 rules). +
++ Run the test. No interaction required. +
++ In the first rectangle, the clip-rule is defined to be evenodd so the overlap should have a hole in it. + The clip-rule is defined to be nonzero so the overlap should be filled. +
++ The intent of this file to test the 'clip' property. In this test, the clipped objects are + raster and SVG images. + + +
++ Run the test. No interaction required. +
+The UA should render two images inside the red rectangles.
++ This tests that 'clipPath' elements can be used together and how the clipping paths are intersected. +
++ There is a gray-white pattern as a background for the two subtest rectangles. This is to show that the holes that are cut out using clip-paths are transparent. + The first subtest verifies that when you use the 'clip-path' property on a child element inside a 'clipPath' element the child element is clipped correctly. + The second subtest verifies that when a 'clipPath' element has a 'clip-path' property the result is the intersection of the two clip paths. +
++ Run the test. No interaction required. +
++ The test has passed if the following conditions are met: +
++ This tests a few 'clip-path' cases to see that clipping paths are applied and constructed properly. +
++ Run the test. No interaction required. +
++ There are nine subtests in this test. There should be a big stroked rectangle with nine smaller rectangles inside. If all of the smaller rectangles are green the test has passed. +
++ The test has passed if: +
++ This tests that a clip path applied to an element does not affect + bounding box computation. +
++ Run the test. No interaction required. +
++ The test is passed if the rectangle is green. The test is failed + if any part of the rectangle is red. +
++ This tests a few 'mask' cases to see that masks are applied and constructed properly. +
++ There are nine subtests in this test. There should be a big stroked rectangle with nine smaller rectangles inside. If all of the smaller rectangles are green the test has passed. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ Test the mask element with child elements with white and black fills, + to create a mask that clips out some text in the middle. +
++ Run the test. No interaction required. +
++ The test is passed if the letters 'ABC' are visible inside a blue + circle, and the letters are transparent, showing the checkered + background image. +
++ Properties inherit into the 'clipPath' element and its children. +
+Run the test. No interaction required.
++ Test passes if there is a green rect visible, and no red. +
++ Test that the children of the 'clipPath' element are not rendered directly. +
++ Test passes if there is a green rectangle, and no red visible on the page. +
++ The 'clipPath' element itself and its children elements do not inherit clipping paths from ancestors of the 'clipPath' element. +
++ Overlay a red 'rect' with a black 'rect' of a larger size. Define a 'clipPath' with a 'rect' of the same size as the red 'rect', but different 'x' and 'y' offsets. Reference that 'clipPath' from a 'g' element containing another 'clipPath' element. In this latter 'clipPath', specify a 'rect' of the same size and same 'x' and 'y' offsets as the red 'rect', and reference it from the black 'rect' element. Reference the same 'clipPath' elements, but this time with a black 'rect' which overlays a red 'rect' of a larger size. If there is no red on the page, the first 'clipPath' was not inherited by the second 'clipPath'. +
++ Run the test. No interaction required +
++ Test passes if there are two black rectangles, and there is no red visible on the page. +
++ Check that metadata in a variety of namespaces, inside a metadata + element, does not affect rendering in any way. The file is not valid to + the SVG 1.1 DTD, but is well formed. +
+The diagram on the table is, by the way, a visualization of the + RDF metadata in the graphic.
++ Run the test. No interaction required. +
++ The rendered result should match the reference image and there should be + no error messages or warnings +
++ Elements are rendered when the 'display' attribute is set to any valid value other than 'none'. +
++ For each valid 'display' value (except none), the test creates a 'rect' element with that 'display' value assigned. Under that + element, a red 'rect' is placed at the exact same 'x', 'y' position with the same height and width. Test passes if the 'rect' + with 'display' covers the red 'rect'. +
++ Run the test. No interaction required. +
++ Test passes if 16 black rectangles are shown and there is no red visible on the page. +
++ 'Stroke' attributes affected by directionality start at the point at which the graphics element starts. +
++ The test creates two 'path' elements that have the same 'stroke-dasharray' assignment. The paths will create the same visual shape, + but the start and end points will be opposite. Test passes if the 'stroke-dasharray' of each path is drawn differently. + Second subtest is the same but with stroke-dashoffset. +
++ Run the test. No interaction required. +
++ Test passes if there are two lines, each composed of alternating black and orange boxes. +
++ Open polyline and path elements are filled as if they were closed with the last point linked to the first point. +
++ The test specifies two polylines and two paths on the page with five points each. One polyline/path closes the shape with the fifth + point linking to the first. One polyline/path is open (no link from fifth point to first). Both polylines/paths are filled. + The open subpath is placed over the closed one. Test passes if the open subpath fills over the closed path. +
++ Run the test. No interaction required. +
++ Test passes if two black shapes are shown and no red visible on the page. +
++ A zero length subpath with 'stroke-linecap' set to 'square' or 'round' is stroked, but not stroked when 'stroke-linecap' is set to 'butt'. +
++ Run the test. No interaction required. +
++ Test passes if there is a blue circle, a blue square, and no red on the page. +
++ This tests setting the 'display' property to 'none' on an element that is a child of a 'mask' or 'clipPath' element, which should cause the element to not be + included in the 'mask' or 'clip' region. +
++ Run the test. No interaction required. +
++ The test is passed if there are 8 green rectangles visible, and no red. +
++ Setting the 'visibility' property to 'hidden' on a 'g' tag will affect its children, unless the children of the 'g' tag override the parent setting. +
++ Have a 'g' tag with an red filled shape as a child. Set 'visibility: hidden' on the 'g' tag. Verify no red is on the page. + Also, have a 'g' tag with a green filled shape as a child. Set 'visibility: hidden' on the 'g' tag. Set 'visibility: visible' on + the child tag. Verify that the green 'rect' renders on the page. +
++ Run the test. No interaction required. +
++ The test is passed if there are two green squares visible on the page, and no red. +
++ Verify the basic capability to handle the fill properties fill:none, + and fill with a color (fill:green) +
++ Run the test. No interaction required. +
++ There should be two rectangles, the rectangle on the left hollow (fill:none) and the rectangle on the right filled with green. +
++ The test uses the "currentColor" value for the "fill" attribute. +
++ Run the test. No interaction required. +
++ The rectangle on the left should be green filled, the rectangle on the right should be blue. + The text above the rectangles should be black. +
++ Verify the basic capability to handle the fill rule properties evenodd and nonzero +
++ Run the test. No interaction required. +
++ There should be two green filled stars, the leftmost star should be unfilled in the very center. +
++ This tests inheritance of three properties: "fill", "stroke" and "stroke-width". There is a "g" element (id="G1") which + sets fill="blue", stroke="purple", and stroke-width="5". The first two rectangles on top should inherit all those + properties. The middle left rectangle has fill="yellow" and stroke-width="2", it should inherit the stroke="purple" + from the parent container. The middle rectangle on the right has stroke="yellow", it should inherit fill and + stroke-width from the parent "g". The bottom two rectangles are in another "g" element (id="G2") which is a child + of "G1". "G2" sets fill="yellow". It should inherit the stroke and stroke width from the parent "G1". The two + bottom rectangles set no fill or stroke properties, they should inherit through the parents, stroke="purple" + and stroke-width="5". +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for possible + variations in the labeling text (per CSS2 rules). +
++ The test uses the "rect" element, as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family (Arial) and font-size properties. +
++ Test using "fill-opacity" values for "rect" element. + This test verifies that opacity is clamped to the + specified range. +
++ Run the test. No interaction required. +
++ The six rect elements on the left have varying 'fill-opacity' values + within the valid range of 0 to 1. The six elements on the right have + 'fill-opacity' values outside the 0 to 1 range, and must be clamped. + The top three rect elements on the right must have their 'fill-opacity' + clamped to 0, while the bottom three rect elements on the right must + be clamped to 1. +
++ Tests the basic support for markers. +
++ The top test examines the basic support for the marker element and style. The markers are purple rectangles. +
++ The middle test examines the support for the different styles of marker properties. The + "marker-start" property defines the marker to use at the first vertex of the marked path, + in this case a purple rectangle. The "marker-end" property defines the marker to use at the + last vertex of the marked path, in this case a blue triangle. The "marker-mid" property + defines the marker to use at all vertices, other than the first and last, of the marked path, + in this case a green circle. +
++ The bottom test examines the support for marker orientation along the + path direction. The second vertex, the top right corner of the path, has a marker that + is rotated 45 degrees, since that is the average of the horizontal and vertical segments + each side. The last vertex, the bottom right corner of the path, has a marker rotated 90 + degrees since that is the direction of the last path segment. +
++ Run the test. No interaction required. +
++ For the three tests, there should be two identical paths with markers drawn. + The path on the left is rendered using the marker elements. The path on the + right is rendered using the equivalent SVG, showing what the marked path should + look like. +
++ The rendered picture should match the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ Tests the rendering of markers, specifically property inheritance. For the four tests, there should + be two identical paths with markers drawn. +
++ The top two tests examine the rendering of markers when the marker and the path + referencing it share the same parent and all painting properties are specfied on + that parent. The first test show inheritance of the 'fill' property and the + second the inheritance of the 'paint' property. In both tests, the marker + is painting using the same properties as the referencing object. Because of + scaling transformations on the marker, the stroke on the second test is thinner + than on the referencing object. +
++ The third and fourth tests examine the rendering of markers in a situation where the + marker and referencing path do NOT share the same parent and painting + properties are specified both on the parent of the marked path and on the contents + of the marker itself. In both cases, the marker's parent specifies + fill="green" stroke="blue" stroke-width="8". For the third test, the marker contents + override with stroke="black". For the fourth test, the marker contents + override with fill="black". In neither case should you see + fill="orange" or stroke="blue" or "stroke="purple" on the markers as these properties + are specified on the ancestor of the referencing object or the referencing object itself + and thus shouldn't affect the marker. +
++ Run the test. No interaction required. +
++ The path on the left is rendered using the marker elements. + The path on the right is rendered using the equivalent SVG, + showing what the marked path should look like. These should be + identical and match the image to the right. +
++ The SVG specification defines three properties to reference markers: marker-start, marker-mid, + marker-end. It also provides a shorthand property,marker. Using the marker property from a style sheet + is equivalent to using all three (start, mid, end). However, shorthand properties cannot be used as presentation attributes. +
++ Run the test. No interaction required. +
++ The test passes if the two rows of shapes are identical, and that + all of the shapes have small blue markers (26 in total per row). +
++ The SVG specification defines three properties to reference markers: marker-start, marker-mid, + marker-end. It also provides a shorthand property,marker. Using the marker property from a style sheet + is equivalent to using all three (start, mid, end). However, shorthand properties cannot be used as presentation attributes. +
++ Run the test. No interaction required. +
++ The test passes if the shapes in the top row have no markers, + while the shapes in the bottom rom have small blue markers + (26 in total). +
++ Test all the 'overflow' property values except 'inherit' on the 'marker' element. +
++ Each column tests a value of the 'overflow' property. + The first row uses the 'marker' property to set the same marker on start-, mid- and end-points on the path. + The second row uses 'marker-start', 'marker-mid' and 'marker-end' to give each point its own marker. + The third row uses the 'marker' property like the first row, but here the marker has orient="auto" set. +
++ Run the test. No interaction required. +
++ The test has passed if: + + The columns labeled 'visible' and 'auto' show markers without clipping them. + All other columns show clipped markers. + The rendered picture matches the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ Tests the basic support for markers. For the three tests, there + should be two identical paths with markers drawn. The path on the left is + rendered using the marker elements. The path on the right is rendered using + the equivalent SVG, showing what the marked path should look like. +
++ This test is similar to the painting-marker-01-f.svg test, but has some viewBox attributes + that have a non-zero offset. +
++ The top test examines the basic support for the marker element and style. The markers are purple rectangles. +
++ The middle test examines the support for the different styles of marker properties. The + "marker-start" property defines the marker to use at the first vertex of the marked path, + in this case a purple rectangle. The "marker-end" property defines the marker to use at the + last vertex of the marked path, in this case a blue triangle. The "marker-mid" property + defines the marker to use at all vertices, other than the first and last, of the marked path, + in this case a green circle. +
++ The bottom test examines the support for marker orientation along the + path direction. The second vertex, the top right corner of the path, has a marker that + is rotated 45 degrees, since that is the average of the horizontal and vertical segments + each side. The last vertex, the bottom right corner of the path, has a marker rotated 90 + degrees since that is the direction of the last path segment. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ A 'marker' element with 'display' set to 'none' on that + element or any ancestor is rendered when referenced by another element. +
++ Run the test. No interaction required +
++ Test passes if there are two green triangles visible on the page. +
++ +
++ +
++ +
++ This tests shows the same linear gradient used with different values for the + color-interpolation rendering property. The top bar is painted using the + default color-interpolation value, which should produce the same result as + sRGB. The middle bar is painted using the 'sRGB' color-interpolation and + should be the same as the top bar. Finally, the bottom bar is painted using + the linearRGB interpolation, which produces a result visibly different from + the top two bars: the white to blue ramp is whiter, the blue to red ramp + goes through a pinkish color and the red to yellow ramp turns orange before + the similar sRGB rampl. +
++ Run the test. No interaction required. +
++ The top two gradients must look the same, and the bottom gradient must look + different to the top two. The rendered picture should match the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ This tests that the 'color-interpolation' property is honored when + alpha compositing is performed. +
++ The test slide consists of seven rectangular regions, + each of which is filled with either a dark or light + shade of gray. The 'color-interpolation' property + is used on the rectangles to control whether a + dark or light shade of gray appears. Text inside each + rectangular region indicates whether the shade of gray + should be dark or light. The top two rectangular regions + are references against which the remaining five are to + be compared. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Verify the basic capability to handle the stroke properties ("stroke") + in combination with the "rect" element . + The pair should be rendered as two blue rectangles, + the upper one without a stroke and the lower with a green stroke. +
++ The test uses the "rect" element, as well as basic "fill" (solid primary colors), + "stroke", stroke="green", "font-family" and "font-size" attributes. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for possible + variations in the labeling text (per CSS2 rules). +
++ Verify the basic capability to handle the stroke properties ("stroke", "stroke-width", + "stroke-linejoin") in combination with the "rect" element. +
++ Run the test. No interaction required. +
++ The pair should be rendered as two blue rectangles without an interior fill. + The upper rectangle should have a thick stroke and sharp corners. + The lower rectangle should have a thick stroke and round corners. +
++ This test checks the basic capability of handling the stroke properties ("stroke", "stroke-width" + "stroke-linejoin", "stroke-linecap", "stroke-miterlimit") + with straight-line path commands. +
++ Run the test. No interaction required. +
++ The two paths should be rendered as two blue line segments. + The upper segment should have round end caps. The lower segment + should be chopped off where the two line segments meet. +
++ This test checks the "stroke-dasharray" and "stroke-dashoffset" properties. Two lines are drawn, one blue + and one black. Both have a "stroke-dasharray" of "10,10" giving a dashed appearance + where the size of the gaps and the size of the dash is equal. +
++ The black line is lower than but parallel to the blue line. The "stroke-dashoffset" on each line should make the dashes of each line line up with the gaps in the other line. +
++ User agents may render graphical primitives with different levels of accuracy. + This test is aimed at determining how a UA renders thin strokes. +
++ The test file contains a number of vertical and horizontal lines. + The stroke width of the vertical lines increase from left to right. + The stroke width of the horizontal lines increase from top to bottom. +
++ The test is passed if user is able to see a smooth stroke width + increment for the vertical and horizontal lines. The top left hand + corner should contain strokes that are very thin in width and the bottom + right hand corner should contain thick strokes. +
++ Test default effects of stroke-dasharray. +
++ This specifically tests the values of none and 0. + This also tests an odd number of values in a dash-array attribute + and in combination with an offset. +
++ The top two lines must be solid black. The next line shows a thick + black line with a thinner blue line on top; both must have the same + dash pattern. The bottom two lines, one black and one blue, must render + so that the gaps of one correspond to the dashes of the other. +
++ Test effect of different stroke-miterlimits. For this particular combination of + stroke width and angle, the cut off value of stroke-miterlimit is 18.028. +
++ Run the test. No interaction required. +
++ The first and second subtests should not truncate the stroke, and all the rest must truncate it. +
++ Test effects of stroke-opacity range. Values + outside the range 0-1.0 must be clamped. +
++ There must be no blue bars visible beside the three pink dots. + Four semitransparent blue bars, increasingly more opaque, + must line up with the yellow dots. Three fully opaque + blue bars must line up with the green dots. +
++ This tests that the "stroke-dasharray" property accepts values + that are separated by white space. +
++ Run the test. No interaction required. +
++ The test is passed if it matches the reference rendering + by showing a thick stroke with alternating long and short + stroke dashes. +
++ This tests that stroking of zero length subpaths will result in + some rendering if the 'stroke-linecap' property is set to + 'square' or 'round', but not if it is set to 'butt'. +
++ Simply load the test. Two rows of shapes should be presented, + with a text label describing the row. +
++ Run the test. No interaction required. +
++ Simply load the test. Two rows of shapes should be presented, + with a text label describing the row. +
++ Test that the viewer has the basic capability to handle the 'path' + element and its data (d) attribute in combination with the cubic + Bezier curveto commands, C, c, S, s (plus Mm and Zz). +
++ There are 8 subtests, each composed from the cubic Bezier path commands per + the label by the subtest. On-curve control points (i.e., the curve position) + are marked by small blue squares. Subtests are filled, or stroked, or + both, using simple style properties and colors. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Test that the viewer has the basic capability to handle the 'path' + element and its data (d) attribute in combination with the quadratic + Bezier curveto commands, Q, q, T, t (plus Mm and Zz). +
++ There are 7 subtests, each composed from the quadric Bezier path commands per + the label by the subtest. On-curve control points (i.e., the curve position) + are marked by small colored squares. Subtests are filled, or stroked, or + both, using simple style properties and colors. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Test that the viewer has the basic capability to handle the 'path' + element and its data (d) attribute in combination with the elliptical + arc curveto commands, A, a (plus Mm and Zz). +
++ There are 6 subtests, each composed from the elliptical arc path commands per + the label by the subtest. The curve positions + are marked by small colored squares. Subtests are filled, or stroked, or + both, using simple style properties and colors. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Verify the basic capability to handle the 'path' element, and its data attribute (d) + in combination with the straight-line path commands. + Two pairs of concentric equilateral triangles are drawn using respectively + M,L,Z and m,l,z. The shapes are identical, with one stroked and + one filled. The fill-mode default of "even-odd" means that + the inner triangle is hollow. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Verify the basic capability to handle the 'path' element, and its data attribute (d) + in combination with the straight-line path commands. + Two pairs of concentric equilateral triangles are drawn using respectively + M,L,Z and m,l,z. The shapes in each pair are identical, with one stroked and + one filled. The fill-mode default of "even-odd" means that + the inner triangle is hollow. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Verify the basic capability to handle the 'path' element, and its data attribute (d) + in combination with the straight-line path commands. + Two pairs of staircase figures are drawn using + respectively M,H,V,Z and m,h,v,z. The shapes in each pair are identical, with one stroked and + one filled. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Verify the basic capability to handle the 'path' element, and its data attribute (d) + in combination with the straight-line path commands. + Two pairs of staircase figures are drawn using + respectively M,H,V,Z and m,h,v,z. The shapes in each pair are identical, with one stroked and + one filled. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Verify the basic capability to handle the 'path' element, and its data attribute (d) + in combination with the straight-line path commands. + Two pairs of concentric equilateral triangles are drawn using + M and Z. No L commands are used in this test as they are implied after + an M or Z command. The shapes are identical, with one stroked and + one filled. The fill-mode default of "even-odd" means that + the inner triangle is hollow. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Verify the basic capability to handle the 'path' element, and its data attribute (d) + in combination with the straight-line path commands. + Two pairs of concentric equilateral triangles are drawn using + m and z. No l commands are used in this test as they are implied after + an m or z command. The shapes are identical, with one stroked and + one filled. The fill-mode default of "even-odd" means that + the inner triangle is hollow. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Verify that the viewer renders the line caps and line joins for + open and closed paths properly. + Verify that the open triangular paths are stroked differently at + ends of the path than they are at their intermediate corners. + In contrast, the corners of a closed path should all appear the + same. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image exactly +
++ Test using multiple coord sets to build a polybeizer, and implicit values for initial S. +
++ The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules). +
+ ++ The rendered picture should match the reference image. +
++ Test multiple coordinates for V and H. +
++ Run the test. No interaction required. +
+The test is passed if there is one horizontal green line and one vertical blue line. +
++ Test implicit values for moveto. If the first command is 'm' it should be taken as an absolute moveto, plus implicit lineto. +
+Run the test. No interaction required.
+The test is passed if the three triangles are shown: two concentric, unfilled + triangles with black strokes on the left, and one unfilled triangle with + a thick blue stroke on the right.
++ Test using multiple coord sets to build a polybezier, then T with no preceding Q or T. +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, apart from any allowable font selection differences due to CSS2.
+A purple wavy line above a short, blue horizontal line must be shown. + Small black triangles pointing to the start, middle and end of the blue + line must also be shown.
++ This tests that any implicit lineto commands that result from an + 'M' or 'm' command with more than one pair of coordinates are absolute + if the moveto was specified with 'M' and relative if the moveto was + specified with 'm'. +
++ Run the test. No interaction required. +
++ After loading the test, the test is passed if two yellow + triangles with black borders are shown. Otherwise, the + test has failed. +
++ Test that the 'z' and 'Z' command have the same effect. +
++ Specify four 'path' elements that each use three 'L' commands to draw three sides of a square. The fourth line of each + square is drawn via a 'closepath' command. A red square closed via 'z' is covered with a black square closed via 'Z' and + vice versa. +
++ Run the test. No interaction required. +
++ The test is passed if two black-stroked, unfilled squares are visible and + there is no red visible on the page. +
++ The 'path' element's 'd' attribute ignores additional whitespace, newline characters, and commas, and BNF processing consumes as much content as possible, stopping as soon as a character that doesn't satisfy the production is encountered. +
++ Various black path segments are rendered that each demonstrate one of the parsing rules. Each path segment is placed on top + of a similar path segment that lacks the particular parsing rule that is being tested. Test passes if no red is visible. +
++ Run the test. No interaction required. +
++ The test passes if seven thick black horizontal lines are shown with corresponding + gold horizontal lines just above them, and the black and gold lines are all of the + same length and horizontal position. +
++ Test that additional parameters to pathdata commands are treated as additional calls to the most recent command. +
++ Each of the applicable 'pathdata' commands are used in separate 'path' elements. Each command is repeated in red and + overlayed with another 'path' element with identical coordinates specified but without the repeated command in black. + Commands that do not render or do not take parameters are omitted. +
++ Run the test. No interaction required. +
++ The test is passed if there is no red visible on the page. +
++ Tests parsing of the elliptical arc path syntax. +
++ Run the test. No interaction required. +
++ The test has passed if the image looks as if there are eight green circles that have + two white rectangles overlapping them, like in the reference image. If any red is visible + the test has failed. +
++ Test the getTotalLength, getPointAtLength and getPathSegAtLength DOM methods. +
++ The left green rect should have text around it. The text should start at 50 user units distance-along-the-path, which is the same as half the rect width. + The right green rect should also have text around it, but the text should start 50 units along the path relative to the provided pathLength. Since 50 is + half of the provided pathLength the text will start at the lower right-hand corner, and if the text is too long to fit it will be cut off when reaching + the upper left corner of the rect. +
++ Run the test. No interaction required. +
+The test has passed if:
++ This test is designed to test the PathSegList interface. At first a flower-like shape with 6 petals should be displayed. + The roundness and number of petals are then animated using script. +
++ The roundness of the petals is animated from star-like sharp petals to softly rounded petals and back again, and is repeated like that until the animation stops. + The number of petals should increase one by one until the flower has a total of 12 petals, and then go back one by one until it has 6 petals, then increase again one by one until the flower has 9 petals. + Then the animation will stop. The rendered image should look exactly like the reference image. +
++ If the flower is clicked after the animation has finished, it will restart the animation and repeat it for some time. +
++ [[Describe the pass criteria of the test here. The pass criteria is what + should be displayed when the test is run.]] +
++ Test that the viewer can handle the xlink:href attribute on + linear gradients. The top rectangle has a simple + blue (left) to lime (right) linear gradient. The lower one + has a different gradient definition, but + should look the same as the one above, because the gradient makes a + reference to the first gradient, without modifying any attribute. +
++Run the test. No interaction required. +
++ The test is passed if there are two rectangles, both with a blue to lime gradient. +
++ Test that the viewer can handle the xlink:href attribute on + radial gradients. +
++ There are two rectangles. The top one has + a radial gradient (black to orange) that should appear elliptical + to fit the aspect ratio of the rectangle. The units are + specified in objectBoundingBox space. The gradient + on the lower one + references the gradient of the top rectangle, but modifies + the units to use userSpace instead. So it is only using the + stops from the gradient to the left, with a different geometry. The radial gradient appears circular. +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, except + for any differences in text due to CSS2 rules. Specifically:
++ Test that the viewer can handle the xlink:href attribute on + patterns. +
++ There are two rectangles with a pattern fill made + up of 4 rectangles. The pattern definition of the lower one references the pattern definition + of the upper one, using the xlink:href attribute. Because + the particular way that the patterns and rectangles are + defined in this test case, the two fills will appear the + same - the rectangles are positioned on pattern-size + boundaries, so that the offsets into the pattern at the left + edges of the respective rectangles is identical. +
++ Run the test. No interaction required. +
+The test passes if the rendering matches the reference image, except + for any differences in text due to CSS2 rules. Note that the top rectangle must + look identical to the bottom rectangle.
++ Test that checks the capability of the stop element in linear and radial + gradients. +
++ The first rectangle has a linear gradient fill with a vector starting at top left + and going to bottom right. The stop colors are at 20% spacing apart and are in the + following order : violet, blue, lime, yellow, orange, green. + Because the gradient vector vector goes from (0,0) to (1,1) in object bounding box space + and because the object bounding box has a larger width than height, the gradient vector + is skewed off of a pure 45 degree angle. The gradient stripes are also skewed + so that they are no longer perpendicular to the gradient vector. +
++ The next rectangle has a radial gradient fill with a multi-color stops from innermost + to outermost in the following order: black, yellow, orange, blue, white, green. +
++ Run the test. No interaction required. +
+The test passes if the rendering matches the reference image, except for + any differences in text due to CSS2 rules.
++ Test that checks the capability of the stop opacity in linear and radial + gradients. +
++ There are two tests which contain rectangles with gradients using stop-opacity properties. + A cyan color text string "Background" is put behind both of the rectangles to help + demonstrate the opacity concept. +
++ From top-down the appearance of objects is as follows. +
++ The first rectangle has a linear gradient fill with a vector starting at top left + and going to bottom right. The stop colors are at 20% spacing apart and are in the + following order : violet, blue, lime, yellow, orange, black. + Also a stop opacity is given to the colors in the following order: 1, 0.2, 0.5, 0, 0.8, 1 + Because the gradient vector vector goes from (0,0) to (1,1) in object bounding box space + and because the object bounding box has a larger width than height, the gradient vector + is skewed off of a pure 45 degree angle. The gradient stripes are also skewed + so that they are no longer perpendicular to the gradient vector. +
++ The next rectangle has a radial gradient fill with a multi-color stops from innermost + to outermost in the following order: black, yellow, red, blue, white, green. + Also a stop opacity is given to the colors in the following order: 1, 0.2, 0.5, 0, 0.8, 1 +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, except for + any differences in text due to CSS2 rules.
++ Test that the viewer can handle the gradientTransform and the patternTransform + attribute on gradients and patterns respectively. +
++ From top-down the appearance of objects is as follows. +
++ The top rectangle has a linear gradient whose coordinate system has been scaled down by + a half. So the gradient travelling from left to right (from blue to green to lime) should + only occuply the left half the rectangle. +
++ The next rectangle has radial gradient that has been translated to the center and skewed + in the positive X direction by 45 degrees. Therefore the gradient should appear + ellipltical and rotated around the center. +
++ The last row contains a rectangle with pattern on the fill. The transformation on the + pattern moves the coordinate system to the top left of the rectangle and then scales it + by a factor of 2 and then skew's it in the X direction by 45 degrees. The pattern + consists of a 2 by 2 array of colored rectangles. +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, apart + from any differences in font choice due to CSS2 rules. Specifically:
++ Test that the viewer has basic capability to handle linear gradients + on fills and stroke of objects and text. +
++ This test uses the following elements : <linearGradient>, <stop> + and the following properties : stop-color, fill:url(# ), stroke(url# ) +
++ Both elements in this test use the same simple gradient. It is a linear gradient from + blue (left) to lime (right). From top-down the appearance of objects is as follows. +
++ The top rectangle should be filled with the gradient. +
++ The next rectangle has no fill, but has a thick stroke on which the gradient is + applied. +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, apart + from any differences in font choice due to CSS2 rules. Specifically:
++ Test that the viewer has basic capability to handle linear gradients + on fills and stroke of text. +
++ Both elements in this test use the same simple gradient. It is a linear gradient from blue (left) to lime (right). From top-down the appearance of objects is as follows. +
++ The first item is a text string "Gradient on fill" with the gradient on the fill of the text. +
++ The second item is a text string that is not filled. It has a 2 user unit stroke on which the gradient is applied. +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, apart + from any differences in font choice due to CSS2 rules. Specifically:
++ Test that the viewer can handle the gradientUnits attribute on linear gradients. + It tests the following values of gradientUnits: default (userSpace), objectBoundingBox, + and userSpaceOnUse. +
++ From top-down the appearance of objects is as follows. +
++ The first rectangle uses the default attributes on the linearGradient element. + Therefore the linear gradient should default to objectBoundingBox. It should appear + from the left edge of the rectangle (blue) to the right edge of the rectangle (lime). + The rectangle is smaller than the viewport, because a previous version of the SVG spec had the default value be 'viewport'. + The test fails if only a portion of the gradient is shown. +
++ The next rectangle uses gradientUnits=objectBoundingBox. The linear gradient should + travel from blue (top) to lime (bottom). +
++ The last rectangle uses gradientUnits=userSpaceOnUse. The rectangle element is given it's + own transformation and the gradient is assumed to be in this user space. + The gradient should appear as a linear gradient from lime (left) to blue (right). +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, apart + from any differences in font choice due to CSS2 rules. Specifically:
++ Test that the viewer can handle the spreadMethod attribute on linear gradients. +
++ Run the test. No interaction required. +
+The test passes if the rendering matches the reference image, apart + from any differences in font choice due to CSS2 rules. Each of the + three rectangles is filled with a linear gradient from blue on the left + to lime on the right. The width of the gradient is only a fifth of + the width of the rectangle, so:
++ Test that the viewer has basic capability to handle radial gradients + on fills and stroke of objects and text. +
++ This test uses the following elements : <radialGradient>, <stop> + and the following properties : stop-color, fill:url(# ), stroke(url# ) +
++ From top-down (left to right) the appearance of objects is as follows. +
++ The top left rectangle should be a radial gradient from dark blue (in) to lime (outside). + The gradient is applied to the fill of the rectangle. +
++ The next rectangle has no fill, but has a thick stroke on which the gradient is + applied. The gradient goes from dark orange(in) to pale yellow (out). +
++ The next item is a text with a radial gradient on the fill. The gradient goes + from green (in) to yellow (out). +
++ The last item is a text with a 2 user unit stroke on which a black (in) to magenta + (out) linear gradient is applied. +
+Run the test. No interaction required.
+The test passes if the rendering matches the reference image, apart + from any differences in font choice due to CSS2 rules. Specifically:
++ Test that the viewer can handle the gradientUnits attribute on radial gradients. + It tests the following values of gradientUnits: default (objectBoundingBox), objectBoundingBox, + and userSpaceOnUse. +
++ From top-down the appearance of objects is as follows. +
++ The first rectangle uses the default attributes on the radialGradient element. + Therefore the radial gradient should be relative to the object bounding box. It should appear + from the center of the viewport (blue) to the edges of the viewport (lime). + The rectangle is wider than tall so it the gradient should be elliptical, not circular. +
++ The next rectangle uses gradientUnits=objectBoundingBox. The radial gradient should + travel from a center of 20%, 20% of the rectangle with a radius of 50%. +
++ The last rectangle uses gradientUnits=userSpaceOnUse. The rectangle element is given it's + own transformation and the gradient is assumed to be in this user space. + The gradient should appear in the center of the rectangle as a radial gradient from yellow (center) to blue (edge). +
+Run the test. No interaction required.
+The test passes if the rendering of the three rectangles matches those + in the reference image. Specifically:
++ The purpose of this file is to test several values for focal points of radial gradients. +
+Run the test. No interaction required.
+The test passes if the rendered image matches the reference image, except + for any differences in font choice due to CSS2.
++ The intent of this file is to test the 4 allowed spread methods for linear and radial gradients. + The 4 values (pad, reflect, repeat and default) are available for both types of gradients. + On the left side are the linear gradient results, and on the right, the radial results. + The UA should render a result equivalent to the reference image. +
+Run the test. No interaction required.
+The test passes if the rendered image matches the reference image, except + for any differences in font choice due to CSS2.
++ Test linear and radial gradient defaults. Includes + testing defaults for linear grad x1,y1,y2 = 0%, x2 = 100%. + and testing defaults for radial grad cx,cy,r = 50%, fx,fy = cx,cy. +
++ Run the test. No interaction required. +
++ The top rectangle must be blue at the lefthand side and fuchsia at the right + hand side, fading smoothly accross. The lower rectangle must be fuchsia at + the edges with a black centre to the radial gradient at the centre of the + rectangle, and the gradient occupying the whole rectangle. +
++ Test gradient stop rules. Including: + No stops, like fill = none. + One stop, like fill = black. + If a stop less than all previous stops, it is set equal to the largest stop. + If two stops are equal the last stop controls the color at the overlap point. +
++ [[ + Describe how to use the here. The instructions should specify any + steps requied to run the test or any manual operation that need + to be performed to run the test. + ]] +
++ The top rectangle must have a pink outline and no fill. The middle rectangle must have a + solid black fill. The lower rectangle must have a yellow to pink to green + linear gradient on the left-hand half and a solid blue fill for the right hand half. +
++ This test has a gradient with gradientUnits='objectBoundingBox' which is a fade from black to white. + The gradient is used for the stroke of a line. Vertical and horizontal lines don't have a boundingbox, + since they are one-dimensional, even though the + stroke-width makes it look like they should have a boundingbox with non-zero width and height. + See the coordinate chapter, last paragraph of 7.11. +
++ [[ + Describe how to use the here. The instructions should specify any + steps requied to run the test or any manual operation that need + to be performed to run the test. + ]] +
++ The left rectangle has four 'line' elements rotated in different ways. The stroke for the lines have a green solid stroke fallback which + should be used if the gradient should be ignored. For this sub-test to pass there must be three lines with solid green stroke, and one line + (from bottom left to top right) with a gradient stroke, visible in the rectangle. +
++ The right rectangle is the same as the left rectangle except that the stroke paintservers don't have a fallback specified. + For this sub-test to pass only the line from bottom left to top right must be visible in the rectangle, and it must have a gradient stroke. +
++ This test shows rectangles filled with gradient. + Several gradients are defined, with two stops: +
++ For the top-left rectangle's gradient: + The first stop defines a fully-opaque green color. + The second stop explicitly inherits (i.e. using the 'inherit' keyword) its stop-color. +
++ For the top-right rectangle's gradient: + The first stop defines a fully-opaque green color. + The second stop defines a green stop-color but explicitly inherits (i.e. using the 'inherit' keyword) the stop-opacity. +
++ For the bottom-left rectangle's gradient: + The first stop defines a fully-opaque green color. + The second stop does not specify the stop-color and the stop-opacity. + Since both properties are not inherited, the initial value should be used. +
++ For the bottom-right rectangle's gradient: + The first stop defines a fully-opaque green color. + The second stop specifies the stop-color using the 'currentColor' keyword. +
++ The result should be: +
++ The top-left rectangle is filled with a gradient from green to pink since + the stop-color is inherited from the location of the gradient definition. +
++ The top-right rectangle filled in green with a gradient opacity. +
++ The lower-left rectangle filled with a gradient going from fully-opaque green to fully-opaque black. +
++ The lower-right rectangle filled with a gradient going from fully-opaque green to fully-opaque yellow. +
++ This test has a gradient with gradientUnits='objectBoundingBox' which is a fade from black to white. + The gradient is used for the stroke of a line. Vertical and horizontal lines don't have a boundingbox, since they are one-dimensional, even though the + stroke-width makes it look like they should have a boundingbox with non-zero width and height. + See the coordinate chapter, last paragraph of 7.11. +
++ The left rectangle has four 'line' elements rotated in different ways. The stroke for the lines have a green solid stroke fallback which + should be used if the gradient should be ignored. + + The right rectangle is the same as the left rectangle except that the stroke paintservers don't have a fallback specified. +
++ The test is passed if +
++ Test the inheritance of radial gradient attributes. The test has six ellipses with blue stroke, each filled + with two gradients. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ Tests that transforms affect the rendering of a gradient. +
++ Run the test. No interaction required. +
++ The test passes if each of the two gradient-filled rectangles + towards the top of the test slide is identical to the one below it. +
++ +
++ +
++ Run the test. No interaction required +
++ +
++ +
++ Test that the 'linearGradient' and 'radialGradient' elements are neither rendered directly nor via the 'use' element. +
++ The test defines 'linearGradient' and 'radialGradient' elements with a red 'stop' and references them from a 'use' element. 'linearGradient' + and 'radialGradient' elements with a red 'stop' are also specified outside of a 'defs' tag as if they were regular graphical elements. +
+Run the test. No interaction required.
++ Test passes if there is no red visible on the page. +
++ Test that gradient offset values less than zero are rounded up to zero and values more than one are rounded down to one. +
++ The test defines four gradients, each with a single stop where the 'stop-color' is set to 'blue'. + The four gradients have 'offset' set to '-1', '-1%', '101%' and '2'. Four rectangles reference + the gradients. All of these should render as if they have plain blue fills. +
+Run the test. No interaction required.
++ The test passed if there are four blue boxes on the page. +
++ Test that the viewer has basic capability to handle patterns + on fills and stroke of objects and text. +
++Run the test. No interaction required. +
++ From top-down the appearance of objects is as follows. +
++ The top rectangle should be filled with a pattern composed of a green + rectangle on top of yellow rectangle. A default stroke has been applied to the original + rectangle to see the boundary of the rectangle. +
++ The next rectangle has no fill, but has a thick stroke on which the pattern is + applied. The pattern consists of 4 colored rectangles. +
++ The next item is a text with a pattern on the fill. The pattern appears as + alternating rows of orange and green. +
++ The last item is a text with a 2 user unit stroke on which a pattern is applied. + The pattern appears as alternating columns of maroon and blue. +
++ Test that the 'patternTransform' attribute has an effect on the 'pattern' element. +
++ Run the test. No interaction required. +
++ The test is passed if the testframe is filled with a blue and white + diamond pattern. +
++ Test that empty patterns are not rendered, and that the fallback color is used instead. +
++ Run the test. No interaction required. +
++ The test is passed if there are 8 green rectangles visible, and no red. +
++ Inherited attributes from a referenced 'pattern' are not applied if they are already defined on the referencing 'pattern' element. +
++ Define a pattern 'pattern1' with circles that have red fill. Inherit 'pattern1' into 'pattern2' and add circles at different 'y' + attribute and with 'fill' set to 'lime' on 'pattern2'. Reference 'pattern1' from a square using 'fill' attribute. Reference 'pattern2' + from a different square using 'fill' attribute. Position the second square directly over the first square. Verify that there is green visible. +
++ Run the test. No interaction required. +
++ The test is passed if there are four green circles visible on the page, and no red. +
++ Test that a 'pattern' element can inherit attributes through multiple levels of + 'xlink:href' referencing. +
++ The test defines a pattern 'pattern1' with some attributes that scale the contents. The attributes on + 'pattern1' are inherited into 'pattern2' and then inherited from 'pattern2' + into 'pattern3'. 'pattern3' has a green circle as its graphical content. + A 'rect' uses 'pattern3' as its fill, if the attributes are correctly inherited into + 'pattern3', then the green circle will occlude a red circle in the same position. +
+Run the test. No interaction required.
++ The test passed if there is no red visible on the page. +
++ +
++ +
++ +
++ Test that an invalid xlink:href on a 'pattern' element has no effect on the pattern. + The pattern dimensions and coordinate-system are defined completely on the pattern that has the invalid xlink:href, + to test that they're not overridden by the non-existant pattern that is referenced. +
++ Run the test. No interaction required. +
++ The test is passed if there are four green circles visible on the page. +
++ Test that an invalid xlink:href on a 'pattern' element has no effect on the pattern. + This test specifies only 'width' and 'height' on the pattern that is tested in order to catch + incorrectly overridden values from a non-existant pattern. The result is tested + with a reference pattern using slightly different syntax. +
++ Run the test. No interaction required. +
++ The test is passed if there are four green circles visible on the page, and no red. +
++ Test that an invalid xlink:href on a 'pattern' element has no effect on the pattern, and that the + pattern isn't rendered since the default 'width' and 'height' is 0. + A subtest that explicitly specifies 'width' and 'height' as 0 is added as a reference. + Both of these cases should result in the fallback color being used. +
++ Run the test. No interaction required. +
++ The test is passed if there is a green rectangle visible on the page, and no red. +
++ Verifies that shapes can be filled. +
++Run the test. No interaction required. +
++ There is one pair of octagons. These are filled. +
++ Verifies that shapes can be stroked. +
++Run the test. No interaction required. +
++ There is one pair of octagons. These are stroked. +
++ Verifies that shapes can be filled, stroked and the order of filling and stroking. +
++Run the test. No interaction required. +
++ There is one pair of octagons. These are filled plus stroked. +
++ Verifies that text can be filled. +
++Run the test. No interaction required. +
++The + test shows two 'G' characters that are filled + (green to the left, and with navy to the right) and not stroked. +
++ Verifies that text can be stroked. The + +
++Run the test. No interaction required. +
++ The test shows two characters that are stroked and not filled. +
++ Verifies that text can be stroked. + +
++Run the test. No interaction required. +
++ The test shows two 'G' characters that are both stroked and filled. +
++ Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). + It also validates basic Shape, Image and text rendering. +
++Run the test. No interaction required. +
++ The rendered image should match the reference image exactly. +
++ This test renders 3 elements: a text string "SVG", then + a shape, then an image. Because of their definition order and coordinates, the image + should be on top of the rectangle and the rectangle on top of the text. The + test validates that groups are conceptually rendered offscreen before being + rendered on the canvas. This is done by grouping the same overlapping objects and + rendering the group at half opacity. The background pattern (vertical stripes) should + show through all the group elements. However, none of the "SVG" text string should show through the + rectangle and none of the rectangle should show through the image. +
++ Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). + It also validates basic Shape, Image and text rendering. +
++Run the test. No interaction required. +
++ The rendered image should match the reference image exactly. +
++ This test renders 3 elements: a text string "SVG", then + a shape, then an image. Because of their definition order and coordinates, the image + should be on top of the rectangle and the rectangle on top of the text. None + of the "SVG" text string should show through the + rectangle and none of the rectangle should show through the image. +
++ Tests basic mouse event handler and DOM manipulation through + ECMAScript binding. +
++ The test uses ECMAScript and initially displays a target with + a message asking the user to click on the target. Once the user + has done so, and if both event handling and DOM manipulation are + supported, then the target and initial text are hidden and a text + message indicating that the test was successful is displayed. +
+Load the test. Click on the blue square.
+The test passes if, after clicking on the blue square, it and + the instruction text "Click on the blue square" is removed + and replaced with green text stating "Scripting Test Passed!".
++ Resolved to unapproved this test because elements being + focusable and activatable is underdefined in the spec. ACTION-2977 +
++ Tests basic mouse event handlers. +
++ The test shows a target that can be used to generate the various + kinds of events supported in SVG. Below the + target, the list of events is shown with red markers next to each. +
++ If the test passes, all the markers should have turned to green + after the events have been triggered on the target. If any event + has not triggered, its marker will remain red. +
+Load the test. Focus the gray circle, activate it, then move the focus away from the circle.
+The test passes if, after following the operator script, the three rectangles are green.
++ Tests basic mouse event handlers. +
++ The test shows a target that can be used to generate the various + kinds of mouse events supported in SVG. Below the + target, the list of events is shown with red markers next to each. +
++ If the test passes, all the markers should have turned to green + after the events have been triggered on the target. If any event + has not triggered, its marker will remain red. +
+Load the test. Click on the gray circle.
+The test passes if, after clicking the gray circle, the three rectangles are green.
++ Tests basic mouse event handlers. +
++ The test shows a target that can be used to generate the various + kinds of mouse events supported in SVG. Below the + target, the list of events is shown with red markers next to each. +
++ If the test passes, all the markers should have turned to green + after the events have been triggered on the target. If any event + has not triggered, its marker will remain red. +
+Load the test. Move the pointing device over the gray circle, and then away from it.
+The test passes if, after moving the mouse away from the gray circle, all three rectangles are green.
++ Tests the assertion that "The ‘contentScriptType’ attribute on the ‘svg’ element specifies the default scripting language" by setting it to an unknown value and checking the script is not executed. + The test uses an unknown (bogus) script language, which looks exactly like ECMAScript. +
+Load the test.
++ The test is passed if string "Good, script didn't run" is displayed. + It fails if the string "No! This is not ECMAScript!" is displayed. +
++ Tests the assertion that "It is also possible to specify the scripting language for each individual ‘script’ element by specifying a ‘type’ on the ‘script’ element." by setting it to an unknown value and checking the script is not executed. + The test uses an unknown (bogus) script language, which looks exactly like ECMAScript. +
+Load the test.
++ The test is passed if string "Good, script didn't run" is displayed. + It fails if the string "No! This is not ECMAScript!" is displayed. +
++Tests the circle element +
++Run the test. No interaction required. +
++ Six circles are displayed, with position, size, fill and stroke matching the reference image +
++ Default attributes test with circle. +
++ Run the test. No interaction required +
++ The test is passed if a group of four circles is displayed, arranged as shown in the reference image. +
++ Test the ellipse element. +
++Run the test. No interaction required. +
++ Seven ellipses are displayed, with position, size, fill and stroke matching the reference image +
++ Defaults test with ellipse. +
+Run the test. No interaction required.
+The test passes if one blue ellipse is shown completely within the test slide, + and a quarter ellipse is shown in the top-left corner of the test slide.
++ The 'ellipse' element defines an ellipse which is axis-aligned with the current user coordinate system when it is not the initial user coordinate system. +
++ The test shows an 'ellipse' element originating at (0,0) of the current user coordinate system, which has been altered via 'transform' from + the initial user coordinate system. Two perpendicular lines which also originate at (0,0) and advance along the x and y axes of + the current user coordinate system are shown. These lines overlap the top and left edges of the ellipse and verifies that the ellipse is + thus axis-aligned with its current user coordinate system. +
++ Run the test. No interaction required. +
++ The test is passed if both ellipses are divided into four equal parts by two sets of crossing lines, and the rightmost ellipse and crossing lines are rotated together. +
++Check that negative second coordinate in a coordinate pair does not need separating wsp-comma. +
++ Run the test. No interaction required. +
++The test is passed if each shape seems to have a double stroke, dark green and light green. +
++ Tests the degenerate cases of the basic shapes. The shapes are positioned + within the black rectangles. +
+Run the test. No interaction required.
+The test passes if the 11 rectangles are empty.
++ Test that basic shape elements are equivalent to a 'path' element that constructs the same shape. +
++ For each basic shape, a 'path' reference element that is red is created. + A basic shape is then placed on top of the 'path' element. + For each basic shape there's also a reverse test that uses the shape as a reference for the 'path' element. +
++ Run the test. No interaction required. +
++ The test is passed if there is no red visible on the page. +
++Tests the line element. +
++Run the test. No interaction required. +
++The test is passed if five diagonal lines are displayed on the top row. On the bottom row, a square wave pattern is displayed. The position, size, fill and stroke of the lines matches the reference image. +
++ The 'fill' attribute has no effect on the 'line' element. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ This test draws six different polygons excercising portions of the path attribute. +
++ Run the test. No interaction required. +
++ The six polygons drawn should match the reference image. +
++Checks that polygons and the equivalent paths are indeed equivalent. +
++ Run the test. No interaction required. +
++The test is passed if each shape seems to have a double stroke, dark green and light green. +
++ Test that 'polyline' and 'polygon' elements with an odd number of coordinates render up to the invalid coordinate. +
++ Run the test. No interaction required. +
++ The test is passed if four green triangles are visible on the page, and no red. +
++Tests the polyline element. +
++Run the test. No interaction required. +
++ The test is passed if polylines are displayed whose position, size, fill and stroke matches the reference image. +
++Checks that polylines and the equivalent paths are indeed equivalent. +
++ Run the test. No interaction required. +
++The test is passed if each shape seems to have a double stroke, dark green and light green. +
++ This is a simple test of the rect element. +
++ Run the test. No interaction required. +
++ The test passes if all four sets of two rectangles are drawn and + they match the reference image. +
++ Test x, y, width, height, rx and ry default/lacuna values on a rect element. +
++ Run the test. No interaction required. +
++ There should be four green rectangles visible, two of them should have rounded corners. +
++ Tests rx and ry clamping and aliasing. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ 'Rect' elements with unspecified 'rx' and 'ry' attributes will use the specified 'rx' and 'ry' value if the other one is specified; if neither is specified, the 'rect' has square edges. +
++ Creates one 'rect' element with an unspecified 'ry'. Places it over a red 'rect' element with both 'rx' and 'ry' specified. Repeat with unspecified 'rx'. Finally creates a 'rect' element that has neither 'rx' or + 'ry' specified. +
++ Run the test. No interaction required. +
++ Test passes if the two shapes on top are rounded rectangles, the shape below has square corners, and no red is visible on the page. +
++ The 'rect' element defines a rect which is axis-aligned with the default user coordinate system when it is not the initial user coordinate system. +
++ Draws a 'rect' element originating at (0,0) of the current user coordinate system, which has been altered via 'transform' from the + initial user coordinate system. Draws perpendicular lines which also originate at (0,0) and advance along the x and y axes of the + current user coordinate system. Verifies that the lines overlap the top and left edges of the rectangle and that the rectangle is + thus axis-aligned with its current user coordinate system. +
++ Run the test. No interaction required. +
++ Test passes if the top and left of the rectangle is black while the right and bottom are orange, and the right half of the diamond is orange and the left half is black. +
++ When 'rect' attributes 'rx' and 'ry' have a value greater than half of the width/height of the rectangle, they are treated as half the width/height of the rectangle. +
++ The test creates one 'rect' element with 'rx' greater than 1/2 the 'rect' width. Underneath that element, it creates a red 'rect' element with + 'rx' set to 1/2 the width. Repeats with 'ry' attribute. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ Checks that unspecified 'ry' and 'rx' attributes are copied from each other before their values are clamped. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ This test evaluates a switch statement. +
++ The test uses the 'rect' element, as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family (Arial) and font-size properties. +
++ Run the test. No interaction required. +
++ The result should be a green rectangle in the lower left quarter of the output window. +
++ This tests ability to use the 'systemLanguage' as a test attribute within a + switch element. +
++ Run the test. No interaction required. +
++ To pass, either the name (in English) of the current system language, or + the names of the three languages (English, French and Japanese) of W3C + must appear. The second case will occur if either the user language is + not one of the (60 or so) languages present in the test, or if there is + no user language information available. +
++ It is an error to display no output; the last child of switch has no test, so + it will always be taken unless a more suitable child has already evaluated to true. +
++ In addition, the string "Why don't they just speak <language>" should appear + in the center of the graphic, translated into that language. It is not an error for + some or all of this string to display as 'missing character' glyphs, if no + suitable font is available - however, this is unlikely if the language is indeed + the users primary language. (It can easily occur during testing, however). +
++ Tests the <switch> element with requiredFeatures. +
++ Run the test. No interaction required. +
++ On the bottom half of the test, there is a first switch. + Because SVG Tiny does not support DOM, an SVG Tiny implementation + which does not support other SVG Profiles should show a green + rectangle. If the application supports the DOM, meaning that + it does more than just SVG Tiny, it should show a turquoise rectangle. +
++ On the bottom half of the test, there is another switch. + The first child has a requiredFeatures set to + http://www.w3.org/TR/SVG11/feature#BasicText which all + SVG Tiny implementations should support. If the application + does, another green rectangle is displayed. Otherwise, + a red rectangle shows. +
++ Test that 'use' instances of elements with failing conditional processing attributes are not rendered. +
++ Six blue 'rect' elements are defined. For each conditional processing attribute, a black 'rect' element is defined with that particular conditional + processing attribute set to an arbitrary string that would cause the attribute's requirement test to fail. Each of the black 'rect' elements is + positioned so that it would completely cover the blue 'rect' if it were visible. A corresponding 'use' element is defined for each black 'rect' + and is positioned such that it would cover the remaining three blue 'rect' elements. The six blue 'rect' elements should be visible. +
+Run the test. No interaction required.
++ The test passes if six blue boxes are visible on the page. +
++ Test that conditional processing attributes set to an empty string are evaluated as false. +
++ Three blue 'rect' elements are in the document. For each of the + conditional processing attributes, a black 'rect' element is + specified with a conditional processing attribute set to an empty string. + The black 'rect' is positioned so that it would completely cover the + blue 'rect' if it were visible. The three blue 'rect' + elements should be visible. +
+Run the test. No interaction required.
++ The test passes if three blue boxes are visible on the page. +
++ Test that elements with conditional processing attributes that evaluate to true do not render if their parent contains conditional processing attributes that evaluate to false. +
++ The test has a 'g' element with its 'requiredFeatures' attribute set to an arbitrary feature string that would cause the attribute's requirement test to fail. + A red 'rect' element is a child node of the 'g' element. The 'rect' element has the 'requiredFeatures' attribute set to a supported feature string. + 'http://www.w3.org/TR/SVG11/feature#ConditionalProcessing' was chosen as a valid feature string to reduce dependencies on other SVG features. +
++ Run the test. No interaction required. +
++ The test passed if there is no red visible on the page. +
++ Elements whose parent elements have failing conditional processing attributes are able to be referenced and rendered by 'use' elements. +
++ Define three 'rect' elements that have a 'g' parent with either an invalid 'requiredFeature', 'requiredExtension', or 'systemLanguage'. + Then define three 'use' elements that reference the 'rect' elements. Verify that the 'use' elements render. +
++ Run the test. No interaction required +
++ Test passes if there is no red visible on the page. +
++ Test to verify that the defs element is used as a container correctly. +
++ In this test a fill is created which is solid green. The view should be a solid green rectangle + centered in the viewport 100 pixels from from left,top and right,bottom. Also, in the + defs sections there are rectangle defined, one to paint over the entire canvas with + a red fill and the other to obscure most of the green rectangle. +
++ The rendered picture should match the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ A green rectangle should be visible, and no red. +
++ Verify the basic capability to handle the SVG DOM API. +
++ The test is composed of a top + level svg element with an 'onload' event handler and a rect element. Both + the svg and the rect elements have an identifier. The 'onload' handler + invokes SVG-specific DOM API methods which use these identifiers. +
++ First, the handler gets the SVG element owner of the rect element and checks it has + the expected identifier. Then, the handler accesses the coordinates of the rect element + and uses them to build a 'shadow' rectangle under the existing one. Finally, the 'shadow' + rectangle is created using the SVGSVGElement's createSVGRect method. +
++ Run the test. No interaction required. +
+The test passes if:
++ Verify the basic capability to handle the hasFeature DOMImplementation method. + The DOMImplementation instance is retrieved from the Document instance. Then, + its hasFeature method is invoked on the various SVG feature strings. +
++ The test displays the set of SVG feature strings and, next to them, a text + string that shows whether the feature is supported or not. +
++ Note that this test uses the 'onload' event on the root svg element. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for the true and + false values which may differ depending on the implementation. +
++ Note that the test passes whether or not the feature is supported (i.e., true or + false are valid). The test fails if no value (true or false) appears next to the feature string + value. +
++ Verify the basic capability to handle the hasFeature DOMImplementation method. + The DOMImplementation instance is retrieved from the Document instance. Then, + its hasFeature method is invoked on the various SVG feature strings. +
++ The test displays the set of SVG feature strings and, next to them, a text + string that shows whether the feature is supported or not. +
++ Note that this test uses the 'onload' event on the root svg element. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for the true and + false values which may differ depending on the implementation. +
++ Note that the test passes whether or not the feature is supported (i.e., true or + false are valid). The test fails if no value (true or false) appears next to the feature string + value. +
++ Verify the basic capability to handle the hasFeature DOMImplementation method. + The DOMImplementation instance is retrieved from the Document instance. Then, + its hasFeature method is invoked on the various SVG feature strings. +
++ The test displays the set of SVG feature strings and, next to them, a text + string that shows whether the feature is supported or not. +
++ Note that this test uses the 'onload' event on the root svg element. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for the true and + false values which may differ depending on the implementation. +
++ Note that the test passes whether or not the feature is supported (i.e., true or + false are valid). The test fails if no value (true or false) appears next to the feature string + value. +
++ Verify the basic capability to handle the hasFeature DOMImplementation method. + The DOMImplementation instance is retrieved from the Document instance. Then, + its hasFeature method is invoked on the various SVG feature strings. +
++ The test displays the set of SVG feature strings and, next to them, a text + string that shows whether the feature is supported or not. +
++ Note that this test uses the 'onload' event on the root svg element. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except for the true and + false values which may differ depending on the implementation. +
++ Note that the test passes whether or not the feature is supported (i.e., true or + false are valid). The test fails if no value (true or false) appears next to the feature string + value. +
++ Verify the basic capability to handle the DOM API. The test is composed of a top + level svg element with an onload event handler. This handler invokes core (i.e., non + SVG specific) DOM API methods to modify the document's content: it removes an element, + modifies an attribute and adds elements. +
++ Run the test. No interaction required. +
+The test passes if the text "DOM API is supported" is shown, the text + "Removing DOM Elements is not supported" is not shown, and no red is + visible.
++ The svg contains three use elements that each reference three rects from an svg element in the document. + Before the onload-script is run there should be 9 red rects visible. The script changes the fill of the rects to be green. +
++ Run the test. No interaction required. +
++ The test is passed if 9 green rectangles are shown. +
++ This tests that SVGSVGElement.unsuspendRedraw() does not + throw an exception if the redraw suspend timeout has elapsed. + After loading the test, wait for one second. Some time + before the one second has elapsed, the rectangle should change + color to indicate the result of the test: black if the test + did not run, red if the test failed and green if the test + passed. +
++ Run the test. No interaction required. +
++ The test is passed if the rectangle is green one + second after the test is loaded. +
++ This tests that the getIntersectionList() and getEnclosureList() + methods return NodeLists that are not live. +
++ After loading the test, two rectangles will be presented. The + upper rectangle indicates the result of testing whether + getIntersectionList() returns a non-live NodeList, while the + lower rectangle indicates so for getEnclosureList(). +
++ Run the test. No interaction required. +
++ The test is passed if both rectangles are green. +
++ This test checks two properties from the SVGElementInstance interface, correspondingElement and correspondingUseElement +
++ Click the grey rectangle on the right side. +
++ For the test to pass, both lines starting with "Test for" must turn to green + when the grey rectangle on the right side is clicked, and the grey rectangle + must also turn green. +
++ Test for checkIntersection and getIntersectionList. +
++ Run the test. No interaction required. +
++ The test passes if 17 green rectangles are displayed and if the legend indicates PASSED. +
++ Test SVGElementInstance.childNodes. +
++ The test has an optional subtest that indicates whether SVGElementInstance.firstChild and + SVGElementInstance.childNodes.item(0) are strictly equal. The status of this subtest is + displayed by a circle in the middle of the testframe, it will be yellow if the objects are + not strictly equal, and green if they are. +
++ Run the test. No interaction required. +
++ The test is passed if there is a green rect visible, + and there is a yellow or dark green circle in the middle. + If there's any red visible the test has failed. +
++ Test SVGElementInstance and EventTarget.dispatchEvent. +
++ Run the test. No interaction required. +
++ The test is passed if there are three green circles visible, and no red. +
++ The 'SVGSVGElement' interface allows for creation of references to various primitive SVG interface types with explicitly defined default values. +
++ A reference to an 'SVGSVGElement' is obtained through an 'svg' element in the page's markup. Each of the 'CreateSVG*' methods is called from this + reference and initial values are verified. A counter is used to determine whether all conditions are satisfied. The word 'fail' in red via an SVG + 'text' element is used to indicate failure and the word 'pass' in black is used to indicate passing. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ Tests that the 'getElementById' method for the 'SVGSVGElement' interface is scoped. +
++ Two subtrees of 'svg' elements are used, each with 'rect' elements as children. A reference to the first 'svg' element is obtained via the + 'document' element's 'getElementById' method. This reference is used to verify the presence of 'getElementId'. Next, 'getElementById' on + the 'SVGSVGElement' reference is used to locate its child element. Then, 'getElementById' attempts to get an element in a neighboring subtree. + Finally, an element at the sibling level is attempted to be accessed via 'getElementById'. +
++ The test is passed if there is no red visible on the page. +
++ +
++ +
++ +
++ Test that the 'SVGElementInstanceList' element's 'length' attribute correctly reflects the implied element hierarchy on recursive 'use' instances. +
++ The test has a 'use' element referencing a 'g' element with another 'use' element referencing the 'use' element. The 'instanceRoot' of the + most indirect 'use' element is used to access the corresponding 'SVGElementInstance'. The test passes if the 'childNodes' attribute's 'length' + attribute for the most indirect 'SVGElementInstance' has a value of '1' and the 'childNodes' attribute's 'length' attribute for the most direct + 'SVGElementInstance' has a value of '0'. +
++ Run the test. No interaction required. +
++ The test is passed if there is no red visible on the page. +
++ Test SVGElementInstance and EventTarget.dispatchEvent. +
++ Run the test. No interaction required. +
++ The test is passed if there are two green circles visible, and no red. +
++ This is an empty SVG document. +
++ Run the test. No interaction required. +
++ Nothing should be rendered by the User Agent. +
++ This test validates the use of the preserveAspectRatio attribute on the + root svg element in an SVG Tiny document. In this document, preserveAspectRatio + is set to none and the width and height of the document set to 100%. +
++ The document's viewBox is defined to be 100 by 100 with an origin + in (100, 100). The content is made of 2 red squares and 2 + orange circles. +
++ Run the test. No interaction required. +
++ Because preserveAspectRatio is set to 'none', the content should + appear distorted (if the aspect ratio is not 1): squares show as rectangles and circles show as + ellipses. +
++ This test validates the use of the preserveAspectRatio attribute on the + root svg element in an SVG Tiny document. In this document, preserveAspectRatio + is set to 'xMidYMid meet' and the width and height of the document set to 100%. +
++ The document's viewBox is defined to be 100 by 100 with an origin + in (100, 100). The content is made of 2 red squares and 2 + orange circles. +
++ Run the test. No interaction required. +
++ Because preserveAspectRatio is set to 'xMidYMid meet', the content should + appear centered within the viewport: squares show as squares (and not + rectangles) and circles show as circles (and not ellipses). +
++ This test validates the operation of the svg element when there is no + viewbox. +
++ The document has x/y attributes set to (1000, 1000). Because + x/y are ignored on the root svg element, the x/y origin should have no + effect on the drawing. +
++ The document contains squares and circles between the + (100,100) and (200, 200) coordinates. +
+Run the test. No interaction required. If the test is run outside of the harness, the operator may resize the viewport.
+The rendered picture should match the reference image. Changing the viewport + size should have no effect on the placement or scale of the document's content.
++ This tests that XML Namespaces are correctly implemented, in that the tuple + of local name and namespace URI, rather than the prefix, is important. +
++ The first subtest is a + group where the namespace prefix s is bound to the SVG namespace and an s:circle is drawn + in pale yellow. The same group declares the default namespace to be a non-SVG namespace; the + blue circle element in that namespace must not be drawn. +
++ The second subtest puts the namespace declarations on the elements themselves. The + prefix toto is bound to the SVG namespace and the XLink namespace is made the default namespace. + Thus, the blue <toto:a href="uri">Valid</toto:a> is a valid link and must be traversable. Select this link, + then go back to the test. +
++ The third subtest has no prefix on the element name 'a' and uses the usual xlink: prefix on the href + attribute. However, both the default namespace and the namespace bound to the xlink prefix are + dummy namespaces. Not only should the link not be traversable, it must not even display at all. + If the text 'Invalid' is displayed, the test fails. +
+Run the test and click on the "Valid" link.
+The test passes if the following conditions are met:
++ This test adds testing of some basic XML features SVG User Agents + should support. +
++ First, the test checks support for the default entities amp, lt, gt, apos + and quot. This is what the first line shows in gray. +
++ Second, the test checks support for hexadecimal and decimal character + entities, as shown in the second line, again in gray +
++ Finally, the last line shows usage of an entity defined in the + document's internal DTD subset. The same geometry (a path) is + reused twice, once filled in gray and ones stroked in gray. +
+Run the test. No interaction required.
+The test passes if the following conditions are met:
++ The test checks to see that graphics elements (g) can be nested and that the like attributes can be passed to the children. + All the g elements for this test are in the g element whose id=allGs. +
++ The test uses the 'rect' element, as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family and font-size properties. +
++ The two blue rectangles and the yellow are in the g labeled rects. + The blue rectangles inherit a fill color the green rect has a fill specified and it should not be overwritten. + The two yellow rectangles should inherit the fill color and the transform attribute, they should be + yellow and rotated at -20 degrees. These two rectangles are in g "yellowNrotate", that g is nested + inside g "gratuitiousG". The black rectangle in the upper right, has no attributes inherited from its parent. + The focus is nesting of g elements and passing on of attributes. +
++ The rendered picture should match the reference image, except for possible + variations in the labelling text (per CSS2 rules). +
++ The purpose of this test is to check the nesting of SVG elements. +
++ The test uses the 'rect' element, as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family and font-size properties. +
++ There are 4 svg elements in the test. + The first defines the outer square at 480x360. + The second whose id is lowerRight defines a green rectangle which is 1/4 of the outer svg element. + The third svg whose id is upperLeft defines a region that is the upper 1/4 of the outer svg, + it is filled with a blue rectangle. It has a child svg element that defines an area + half again the size of its parent but sharing the same center point, it is filled with a yellow rectangle. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ This test validates that properties are inherited (or not, depending on + their defintion), from a group to its children. +
++ [[ + Describe how to use the here. The instructions should specify any + steps requied to run the test or any manual operation that need + to be performed to run the test. + ]] +
++ The two rows displayed in this test should be identical. In the top row, + each property is set to the value 'inherit'. In the bottom row, which is + the reference, each property is set to the value that should be inherited + in the top row. +
++ The image test case checks to see if the required raster image formats are supported. +
++ The upper right has an JPEG image, the lower right has a PNG image. They are + the same image. + Those positions are relative to the upper left of the entire canvas. + If any of the components are missing, then an image format is not being + properly supported. +
++ Run the test. No interaction required. +
+The test passes if two identical images are shown.
++ To test the 9 structure elements and their relationships. +
++ S1 tests the defs element and the rendering of an image via the use element. + S2 tests the defs element and the use element by creating an svg element + that contains a blue rectangle. S3 tests the nesting of an SVG element, a + separate graphics element is defined, its coords relative to the svg element. + S4 tests a switch statement, if there is not a green rectangle showing in + S4 there is probably a problem processing a switch. +
++ The test uses the 'rect' element, as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family and font-size properties. +
++ Run the test. No interaction required. +
++ The test is passed if the upper left rectangle shows an image, + the upper right a blue rectangle, the lower left a cyan rectangle + and the lower right a green rectangle. +
++ This test verifies the support for gamma correction of displayed PNG + images. +
++ Run the test. No interaction required. +
++ Several different images are displayed one above the other; + if gamma correction is correctly performed based on the values in + the gAMA chunk in the PNG file, the resulting displayed values are + the same in all of the files (except for rounding error, which gives + some artefacts at the right side of the lowest two images due to the + very high levels of gamma correction needed for this test) +
++ The image test case checks to see if the basic image formats allowed in + are supported using the data: URI schema and base64 encoding. +
++ The upper right has an JPG image the lower right has a PNG image. They are + the same image. + Those positions are relative to the upper left of the entire canvas. + If any of the components are missing, then an image format is not being + properly supported. +
++ Run the test. No interaction required. +
+The test passes if two identical images are shown.
++ The image test case checks to see if the svg image format are supported. +
++ The test uses the 'rect' element, as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family and font-size properties. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image showing two rectangles, one blue and one yellow. +
++ Check that all the preserveAspectRatio values are supported + for the <image> element. In particular, check that + values which are not supported on the svg element's + preserveAspectRatio are supported for <image>. +
+Run the test. No interaction required.
+The test shows four smiley images: the leftmost one is the reference, + and the three on the right are the three sub-tests. The test is passed + if the following conditions are met: +
++ This test validates that xml:base is properly handled on the + <image> element. +
++ It shows the same image three times, with different xml:base and + xlink:href values. +
+Run the test. No interaction required.
+The test is passed if three smiley face images are shown.
++ Tests PNG images with alpha. +
++ Run the test. No interaction required. +
++ The result should be identical to the reference image. +
++ Tests PNG images with pallete ransparency (tRNS chunk). +
++ Run the test. No interaction required. +
++ The result should be identical to the reference image. +
++ Tests PNG greyscale images with alpha. +
++ Run the test. No interaction required. +
++ The result should be identical to the reference image. +
++ Test interactivity in an svg image referenced by an 'image' element. +
++ This test requires support for CSS2 and referencing SVG and PNG images via the 'image' element. +
++ Click each of the three rectangles in the center of the testframe once. +
++ The test is passed if all three rectangles are green after being clicked once each. +
++ [[Describe which section and what specific assertion is being tested + by the test. If the test has a number of sub tests, multiple + "testComponent" elements can be specified within the "testDescription" + element.]] +
++
++ [[Describe the pass criteria of the test here. The pass criteria is what + should be displayed when the test is run.]] +
++ Tests that different PNG image types are correctly handled. These images are non-interlaced. +
++ This test uses the + PNG Group test suite + created by Willem van Schaik. +
++ Run the test. No interaction required. +
++ The test is passed if all the small PNG icons are displayed as in the reference image. +
++ Tests that different PNG image types are correctly handled. These images are interlaced. +
++ This test uses the + PNG Group test suite + created by Willem van Schaik. +
++ Run the test. No interaction required. +
++ The test is passed if all the small PNG icons are displayed as in the reference image. +
++ The first row tests that alpha PNG images are correctly displayed as part of an SVG image, + ignoring the background colour in the image which is only used to display the + PNG image stand-alone. +
+The second row tests indexed PNG transparency (tRNs), again checking that + the background color is ignored when displayed as part of an SVG image. +
++ This test uses the + PNG Group test suite + created by Willem van Schaik. +
++ Run the test. No interaction required. +
++ The test is passed if all the small PNG icons are displayed as in the reference image. +
++ Test that the 'image' element loads the same resources as when it's standalone. +
++ Run the test. No interaction required. +
++ The test is passed if there's a green rectangle visible, and no red. +
+Verifies that SVG images referenced from an <image>
element
+ do not have any scripting or animation run.
The referenced SVG image has a green rectangle. If either animation or + script runs, it will turn the rectangle red.
+Run the test. No interaction required.
+The rendered picture should match the reference image.
+If the rectangle is red, the test has failed.
++ Test referencing an svg from an 'image' element, where the referenced + svg has no viewBox and a larger width and height than the 'image' + element viewport. +
++ Run the test. No interaction required. +
++ The test is passed if a green quarter circle with black stroke is displayed, and no red. +
++ Test referencing an svg from an 'image' element, where the referenced + svg has a viewBox and a larger width and height than the 'image' + element viewport. +
++ The same image resource is reference twice, and will scale to fit the + viewport that is established by the 'image' element. +
++ Run the test. No interaction required. +
++ The test is passed if two green circles are displayed, and no red. +
++ The default values for 'width' and 'height' are '100%' and 'x' and 'y' are '0' for the 'svg' element. +
++ Empty 'svg' element is referenced via 'getElementById()'. From that reference, 'width', 'height', 'x', and 'y' are evaluated + via 'baseVal.valueAsString'. A failure of one or more tests is indicated by the word 'FAIL' in red text. +
++ Test passes if there is no red visible on the page. +
++ Testing various interactions on the width attribute on an svg element. + The width attribute defaults to "100%" if it's not specified. +
++ Run the test. No interaction required. +
++ The test is passed if the testframe is filled with green, and there's no red. +
++ Test nested svg elements. +
++ Run the test. No interaction required. +
++ Passed if there are two green rectangles visible, and no red. +
++ The purpose of the symbol test case is to create some symbols and then + have them rendered when instantiated by the use element. +
++ This file contains 3 symbol definitions. Only two are ever rendered. + There is a viewport defined to be 0,0,1000,1000 on the svg element. + Each symbol has is own viewport of the same dimensions. The symbols are + scaled when they are instantiated by the use element, The first set + of symbols is 4 squares, blue and yellow in color they should appear + in the lower right of the view arranged in a checkerboard fashion. + The second symbol to be used is an image which should appear in the + upper left of the view area. The symbol that is not used and should + not be rendered is a large black rectangle. If the symbols don't + appear, there is something askew with the use statement, if they + appear but either overlap each other or in some way aren't in the + correct positions they have not honored either their viewport or + were not scaled when placed by the use element in the area defined by + it. If everything is black then perhaps a symbol was rendered that + should not have been. +
++ Run the test. No interaction required. +
+The test passes if:
++ The purpose of this test is to validate proper handling of + the use element. In particular, the test checks the proper inheritance + of properties through the shadow tree (rather than through the document + tree). +
++ Run the test. No interaction required. +
++ The test should display various elements in different shades of green. + If an element is not displayed in green, but in red fill and/or yellow + stroke, then it is in error. +
++ The purpose of this test is to validate proper handling of + the x/y attributes on the use element. +
++ The test shows a <use> element displayed on the right. + On the left, a group built as described in section + 5.6 of the SVG 1.1 specification validates that the + <use element is properly processed. +
++ Run the test. No interaction required. +
++ The test is passed if there are two identical diamond shapes visible. +
++ The intent of the file is to determine if the UA supports references to external SVG fragments. +
++ See referenced image. +
++ To pass this test, the UA agent must display a total of 8 graphical + primitives (2 rectangles, 2 circles, 2 ellipses and 2 triangles). + For each pair of objects, one is a semi-transparent duplicate + copy at the other displayed at an offset position.. +
++ This file is intented to test the computed values in external references. + Both files (referencing and referenced) define similar colors/gradients via 'color', 'linearGradient' and 'radialGradient'. + The ids of those definitions are the same but the actual appearance are different. These definitions are used to test the + property inheritance feature of SVG. +
++ [[ + Describe how to use the here. The instructions should specify any + steps requied to run the test or any manual operation that need + to be performed to run the test. + ]] +
++ The top left rectangle should be filled with the blue linear gradient since the 'use' has a specified value + defined in the 'defs' section. The top right rectangle is forestgreen since the 'use' has a computed value. + The bottom left rectangle is also forestgreen since the fill is not inherited from the referenced element's original parent. + The bottom right rectangle is filled with the orange radial gradient since the computed value is given by the CSS cascade. +
++ Test onlick handlers in externally referenced content. + + There are two 'use' elements, each of them is referencing an external file showing a rectangle. + + The rect elements in the external file have onclick attributes, and the handler will attempt to change the fill of the + referenced rect element to red. +
++ Click each of the two green rectangles once. +
++ The test is passed if the two rectangles remain green when clicked, and there is no red visible. +
+
+ This tests interactivity and event handlers on use elements. It also tests
+ that the SVGElementInstance.correspondingElement
property and the
+ CSSStyleDeclaration.setProperty()
method defined in
+ DOM Level 2 Style. By testing different ways of setting the fill on a rectangle
+ it verifies that the result is consistent, and that CSS properly overrides
+ the specified values.
+
+ You should at first see a pyramid of four pink rects. + Click each of the pink rects once. +
++ If the useragent doesn't support CSS, this test does not apply. +
++ The test has passed if when clicking each of the rects the clicked rect turns blue - + note that only the clicked rect must turn blue, if any other rect turns blue too then the test has failed. +
++ The reference image shows the final state, what the result should be after all rects have been clicked. +
++ [[Describe which section and what specific assertion is being tested + by the test. If the test has a number of sub tests, multiple + "testComponent" elements can be specified within the "testDescription" + element.]] +
++ [[Describe how to use the here. The instructions should specify any + steps requied to run the test or any manual operation that need + to be performed to run the test.]] +
++ [[Describe the pass criteria of the test here. The pass criteria is what + should be displayed when the test is run.]] +
++ This tests the use element inside a symbol definition. +
+Run the test. No interaction required.
++ For the test to pass, 5 nested rectangles with different coloured strokes + (black, yellow, orange, purple and blue) must be rendered. +
++ Properties are inherited according to the 'use' element rules, CSS selectors only apply to the original elements + and not the (conceptually) cloned DOM tree. +
++ Run the test. No interaction required. +
++ The test has passed if the three rectangles have green fill and a thick darkgreen stroke. If any red shows the test has failed. +
++ CSS selectors that apply to an element referenced via 'use' also apply to the 'use' instance. +
++ A 'style' block contains all CSS rules. Various CSS selectors are applied to 'circle' elements. A unique 'class' selector is + used for all cases to ensure that the selectors don't interfere with each other. For each 'circle', there is a corresponding + 'use' instance. For structure-related rules, a 'g' tag is used. +
++ Run the test. No interaction required. +
++ Test passes if twelve blue circles and no black circles are visible on the page. +
++ Tests that recursive 'use' instances do not block rendering. +
++ Various scenarios that directly and indirectly create circular references via the 'use' tag. A 'g' element is used when + structural elements are necessary. None of the 'use' scenarios render anything. 'useLongCycle' tests a chain of recursive + 'use' instances that eventually cycles back to the first element. In 'useNested' 'use' elements are nested, with the child + referring to the parent. In 'useNestedGroup' a 'use' instance references a parent 'g' element. In 'useIndirectNestedGroup' + a 'use' instance indirectly references its own parent 'g'. In 'useMultipleIndirectNestedGroup', two 'use' instances + reference their parent 'g' elements, and additional 'use' instances refer to these self-referencing 'use' elements. A green + 'rect' is used to verify that rendering was processed up to that point. +
++ Run the test. No interaction required. +
++ Test passes if there is green visible on the page. +
++ Test that 'use' elements are synchronized at run time with the elements they reference. +
++ This test verifies visual synchronization during run time between 'use' instances and the elements they reference. A 'g' element containing + two 'rect' elements is referenced via 'use'. One 'rect' is red and the other has no fill specified. DOM synchronization is verified visually + by removing the red 'rect'. Presentation attribute synchronization is verified visually by setting the other rect's 'fill' attribute to 'lime'. + The 'g' that is referenced is inside of a 'defs' tag so only the 'use' instance is visible. +
++ Run the test. No interaction required. +
++ The test is passed if there is a green square visible on the page, and no red. +
++ Test that the 'use' element's 'xlink:href' attribute referencing dynamically set 'id' attributes is supported. +
++ The test defines a 'use' element with its 'xlink:href' attribute set to 'pass' which is an invalid element id. A green 'rect' element has its 'id' + attribute set to 'pass' via 'setAttribute'. The referenced 'rect' is a child of a 'defs' element so that it does not render, and it is wrapped with a 'g' + element in order to obtain a DOM reference to it. +
++ Run the test. No interaction required. +
++ The test is passed if there is a green square visible on the page, and no red. +
++ Test that recursive 'use' elements are synchronized at run time with the originally referenced element. +
++ Inside of a 'defs' element, a 'g' element containing two 'rect' elements is referenced via 'use'. Outside of the 'defs', a 'use' element references + the other 'use' element. One 'rect' is orange and the other has no fill specified. DOM synchronization is verified visually by removing the orange 'rect'. + Presentation attribute synchronization is verified visually by setting the other rect's 'fill' attribute to 'blue'. All elements are inside of a 'defs' + element except for the recursive 'use' element to ensure that it is the only element rendered. Verify that blue is visible and orange is not visible. +
++ Run the test. No interaction required. +
++ The test is passed if there is a green square visible on the page, and no red. +
++ The 'class' attribute assigns one or more class names to an element, and shared class names among several element instances are supported. +
++ Assigns a class to two elements and specify a 'fill: blue' style rule on the class. On one of the elements, also specify a + second class with a specified 'stroke: orange' style rule. Verify the 'fill' and 'stroke' styles applied appropriately. +
++ Run the test. No interaction required. +
++ Test passes if there are two blue rectangles on the page, and the lower right one has an orange border. +
++ Test element and class selectors. +
++Run the test. No interaction required. +
++The test is passed if all six shapes have a green fill. +
++ Test ID and attribute selectors +
+Run the test. No interaction required. +
++ The test is passed if all six shapes have a green fill. +
++ Test ancestor, child and sibling selectors. +
++ Run the test. No interaction required. +
+ ++ The test is passed if all six shapes have a green fill. +
++ This purpose of the file is to test some of the CSS2 selector syntax. +
++ A UA supporting CSS selectors should render an image identical to the referenced image. +
+ ++ The test is passed if a grid of 6x3 squares is shown, the colors in each column + are the same and are those of the reference image (blue, green, orange, gold, purple and silver) +
++ For a full analysis of this test, please see + + this explanation. + +
++ Tests the language selectors, :lang(c). +
++ Note that a less specific language (such as fr) also matches a more specific + language (such as fr-CA) but a more specific language (such as en-GB) does not match a less specific language (such as en). + Also note that language tags,and thus language selectors are case-insensitive. +
++ Run the test. No interaction required. +
++ The phrase "Good morning!" should be in green. The phrase "Bon avant-midi!" + should be in blue; in addition, the "avant-midi" should be italic because its Canadian French. +
++ Tests the dynamic pseudoclasses :link, :visited, :active, :hover and :focus. +
++ For the test to work, you must have previously visited ../linkingToc-t.svg which you can do by + traversing the "Visited" link, then going back to this test file. +
++ The links marked "Visited" and "Hover me" should now be purple, + while the "Unvisited" link is blue. +
++ Note: If you do not have a pointing device, or if it provides pick but not hover + (eg a stylus on a PDA) skip the hover portion of the test and mark this part as + passed: Hover the pointing device over the "Hover me" and then, over the "And me, too!". + As each of the two text strings text is hovered, it should turn a dark orange color + while the other string should be whatever color it was before being hovered. +
++ Note: If the device you are using does not support text selection, e.g. a mobile phone, + you may skip this part of the test and consider this part passed.:Finally, select + some of the "Select me" text. SVG states that text selection causes an element to receive focus. + There is a style rule :focus { fill: rgb( 0, 255, 127); stroke: rgb( 0, 255, 127); stroke-width:3px } + which applies, although since it has specificity + 010 while the following rule text:active {text-decoration: underline; fill: red } + has a higher specificity of 011, the fill is in fact red while the stroke is still green. +
++ Because this is a dynamic test , a single static image cannot fully capture all the + states. The reference image simulates the state during the third subtest. Visited and + unvisited links have the appropriate blue and purple colors. The color and presentation + of the selected text are user-agent dependent, but the unselected part of the "Select me" + text must be red and underlined with a green stroke. +
++ Tests that inline CSS styling (style attributes) is supported. +
++ Specifies an inline 'visibility: hidden' style rule on a red element and verifies there is no red on the page. +
++ Run the test. No interaction required. +
++ Test passes if a green rectangle is visible, and there is no red visible on the page. +
++ Test that CSS styling via the 'style' element is supported. +
++ For each of a representative sampling of selectors, specify a 'visibility: hidden' style rule and add a corresponding red + element to the markup. A reference in green is shown for each shape. +
++ Run the test. No interaction required. +
++ The test is passed if there is no red visible on the page and there are seven green shapes visible. +
++ Tests that CSS styling from an external style sheet is supported. +
++ For each of a representative sampling of selectors, a 'visibility: hidden' style rule is specified + to match a corresponding element in the markup. Identically shaped and sized elements (but which are not + applicable to any of the style selectors) are placed beneath them and should be visible + if the style sheet was applied correctly. +
+Run the test. No interaction required.
++ The test passes if there are seven blue shapes on the page. +
++ Checks that stylesheets (style attributes, style elements, +external style sheets) are case-insensitive, unlike presentational attributes.
+ +Subtest a checks that the invalid attribute +FiLl is ignored. Subtest b checks that the style attribute is +applied, the values being case-insensitive. Subtests c and d check +the same for style elements and imported external style sheets. +
++ Run the test. No interaction required. +
++ If any red shows, the test fails. If four orange circles are shown, + the test passes and the user agent supports CSS style sheets. If + the top two circles are orange while the bottom two are blue, and the user agent does + not claim to support CSS style sheets, the test also passes. +
++ This tests that the 'type' attribute on a 'style' element is + honored. +
++ Once the test is loaded, two rectangles are presented, + the upper indicating the result of a sub-test that checks + whether the 'type' attribute on a 'style' element correctly + defaults to "text/css", and the lower indicating the result + of a sub-test that checks whether a bogus value for 'type' + does not cause the 'style' element contents to be interpreted + as CSS. Each rectangle is green if the sub-test is passed + or red if it failed. +
++ Run the test. No interaction required. +
++ The test is passed if both rectangles are green. +
++ Verify property inheritance as required by 6.15 "Property + inheritance". Since all implementations are required to do this, only + presentation attributes are used. +
++Run the test. No interaction required. +
++ At the center right, there is an ellipse. The fill color is not + specified on that element but on its parent. The ellipse should be filled a solid yellow +
++ At the top left, an oval shape is formed from a rectangle + with a radial gradient. The color of the middle stop uses the keyword 'inherit' + and thus takes its parent's value of green, giving a yellow, green, white gradient. +
++ At the bottom left, an oval shape is formed from a rectangle + with a radial gradient. The color of the middle stop uses the value 'currentColor' + and thus takes the value its parent's color property, a dark red, + giving a yellow, dark red, white gradient. +
++ Tests that !important in a presentation attribute is an unsupported value +
++ A fill attribute is set to red with !important. This is an unsupported attribute value, + consequently the fill attribute should be the lacuna value, which is black. Therefore, to pass, the rectangle should be filled with black. +
+A lime green border is also drawn, to check that rendering continues after the element with the unsupported value.
++ Run the test. No interaction required. +
++ The rectangle should be filled with black, with a lime green border. +
++ This tests that a presentation attribute that is not relevant + to a given element which is otherwise stylable is correctly stored + in the property collection for that element. In particular, + it tests the following presentation attributes: +
++ The test comprises 14 sub-tests, each with a rectangle that indicates + whether a given presentation attribute of the 14 listed in the test + description affects the style of the element on which it is specified. A rectangle + is black if the sub-test did not run, red if the sub-test failed and + green if the sub-test succeeded. +
++ The test is passed if all 14 rectangles are green. +
++ Presentation attributes have lower priority than internal CSS style rules. +
++ Specify an inline 'fill: none' style rule on an element with 'fill=red' presentation attribute and verify there is no red + on the page. +
++ Test passes if there is no red visible on the page. +
++ Presentation attributes have lower priority than other CSS style rules specified in an internal style sheet. +
++ For each of a representative sampling of selectors, specify a 'fill: green' style rule for it, and add a corresponding + element with 'fill=red' presentation attribute to the markup. Verify there is no red on the page. +
++ Test passes if there is no red visible on the page. +
++ Presentation attributes have lower priority than other CSS style rules specified in an external style sheet. +
++ For each of a representative sampling of selectors, specify a 'fill: green' style rule for it, and add a corresponding + element with 'fill=red' presentation attribute to the markup. Verify there is no red on the page. +
++ Test passes if there is no red visible on the page. +
++ This tests how unspecified attributes affect the return values from the + SVG DOM methods related to attributes. +
++ After loading the test, you should see a list of red or green rectangles followed by some text describing each subtest. +
++ Run the test. No interaction required. +
++ The test has passed if there is a line of text saying "Test status: PASSED", and there is a green rectangle to the left of that text. +
++ Test 'text-anchor' property (horizontal). +
++ The three lines test the three values for property 'text-anchor': start, middle and end. +
++ Run the test. No interaction required. +
++ The lines in pink, 'text-anchor:none' and 'text-anchor:start', should both start from the same horizontal position (indicated by the black circle on each line) and extend to the right. + The green line, 'text-anchor:middle', should be centered horizontally around the black circle. + The blue line, 'text-anchor:end', should be aligned such that the end of the text meets the black circle. +
++ Test the 'baseline-shift' property (horizontal). +
++ Run the test. No interaction required. +
++ This three lines test property 'baseline-shift'. + The first line tests 'baseline-shift:7' (i.e., a length for 'baseline-shift'). + The pink text should be shifted upwards by an amount approximately half of the height of the text. + The second line tests 'baseline-shift:-70%' (i.e., a percentage for 'baseline-shift'). + The pink text should shift downward by about the height of the text. + The third line tests the three keywords 'sub', 'super' and 'normal'. + The string "sub" should be shifted downwards, the string "super" shifted upwards, + and the string "te" (in blue) aligned with the remainder of the text in the line. +
++ Test for viewer capibility to handle the basics of the 'textAnchor' + alignment property for 'text' and related elements. +
++ This test verify that + the interpreter correctly handles and applies the text-anchor + properties when present on "chunks", which are comprised of tspan elements + with absolute positioning, within the containing 'text' element. +
++ Run the test. No interaction required. +
++ The test is passed if +
++ Test for viewer capibility to handle the basics of the 'text-anchor' + alignment property for 'text' and related elements. +
++ The second group from the top contains sub-tests to verify that the + interpreter handles text-anchor when the text is comprised of other + text related elements, 'tspan', 'tref', and 'textPath'. + The text-anchor property is present on the containing 'text' element + in these cases, not on the contained child elements. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test 'text-anchor' property (vertical). +
++ This tests the three values for property 'text-anchor': start, middle and end. +
++ Run the test. No interaction required. +
++ The test is passed if three vertical lines of text are displayed with + each line containing a single black dot. +
++ Tests various ways that the 'baseline-shift' property (vertical) can be + altered. +
++ The first sub test sets the 'baseline-shift' to an absolute unit. The + second sub test sets the 'baseline-shift' to a percentage. The third sub + test sets the 'baseline-shift' to "sub". The fourth sub test sets the + 'baseline-shift' to "super". +
++ Run the test. No interaction required. +
++ The test is passed if four lines of vertical text are rendered. +
+ISSUE - http://www.w3.org/2011/02/27-svg-irc#T22-20-51
++ Test horizontal baselines across script and font size changes. +
++ Original test authored by Rodney Hardy at CISRA and modified by + Anthony Grasso. +
++ Run the test. No interaction required. +
++ The dominant baseline should be alphabetic, so the 'a' will be sitting + on the blue line, the Japanese character '犜' will be on the ideographic baseline + and 'ण' is a Devangari character and will use the hanging baseline. The + smaller versions of the characters should be aligned to the same baselines. + So the 'a's on the blue line, the Japanese characters slightly below the line + and the Devangari characters should be hanging from the hanging baseline. +
+ISSUE - http://www.w3.org/2011/02/27-svg-irc#T22-20-51
++ Test horizontal baselines across script and font size changes. It uses an SVG Font, where + the Latin letter "a" is a rectangle, the Japanese letter "犜" is an upward-pointing triangle, + and the Devanagari letter "ण" is a downward-pointing triangle. +
++ Original test authored by Rodney Hardy at CISRA. +
++ Run the test. No interaction required. +
++ The dominant baseline should be alphabetic, so the 'a' will be sitting on the alphabetic (blue) line, + the Japanese glyph (upward pointing triangle) will be aligned on the ideographic (pink) baseline + and 'ण' is a Devangari character (downward pointing triangle) and will use the hanging baseline (green). + The smaller versions of the characters should be aligned to the same baselines as the respective larger + characters, so all like shapes align to the same baseline. +
++ Test 'altGlyph' facilities and many-to-many chars to glyphs. +
++ Run the test. No interaction required. +
++ This test requires some support for SVG fonts. +
++ Three text strings show: the word "HAPPY" in pink, the word "SAD" in green + and the word "SASSY" in blue. +
++ The "HAPPY" and "SAD" strings test the 'altGlyph' facility and + the ability to map multiple glyphs to a single character. + All characters except the "D" are bracketed by 'altGlyph' elements + to use two different glyphs to render each character. + For "HAPPY", the horizontal stroke through the center of the characters + is a smile stroke. + For "SAD", the horizontal stroke through the center of the characters + is a frown stroke. +
++ The "SASSY" string tests a single glyph representing multiple characters + (a ligature). The SVG font in the test case contains an "SS" ligature + so that the "SS" in "SASSY" is rendered with a single glyph, where + the two parts of the "SS" are connected. +
++ Test glyph selection using altGlyphDef and altGlyphItem elements. +
++ Run the test. No interaction required. +
++ Support for SVG Fonts is required for this test, and the last two text + strings are used to give a quick visual indication this is indeed + supported. +
++ The test shows 24 different text strings with different combinations + of altGlyphItem element count and validity inside the altGlyphDef + elements, and number of characters in the altGlyph elements. The + glyphs are from a sans serif font, except those selected by + altGlyph, which are from a boldface serif font. The text + in the "Actual" columns should appear as shown in the corresponding + "Expected" column text. +
+The test passes if each pair of (actual,expected) text strings + render identically.
++ Test glyph selection using altGlyphDef and altGlyphItem elements. +
+This test was copied from text-altglyph-02-b.svg revision 1.9, which had some subtests + involving 'altGlyph' elements with no character data removed. All of the subtests + that are common with text-altglyph-02-b.svg can be removed from this test.
++ Run the test. No interaction required. +
++ Support for SVG Fonts is required for this test, and the last two text + strings are used to give a quick visual indication this is indeed + supported. +
++ The test shows 24 different text strings with different combinations + of altGlyphItem element count and validity inside the altGlyphDef + elements, and number of characters in the altGlyph elements. The + glyphs are from a sans serif font, except those selected by + altGlyph, which are from a boldface serif font. The text + in the "Actual" columns should appear as shown in the corresponding + "Expected" column text. +
+The test passes if each pair of (actual,expected) text strings + render identically.
++ Test directional type, ltr context, arabic. + Assertion: In a left-to-right context, without markup, styling or special characters, a sequence of Arabic characters and spaces will progress from right to left. +
+You will need a font that allows you to distinguish Arabic characters.
++ Run the test. No interaction required. +
++ Test passes if the characters follow the same order. +
++ Test the 'text-decoration' property. +
++ Run the test. No interaction required. +
+The test has passed if:
++ This tests the methods and properties of the SVGTextContentElement interface on the text element with the id 'testText' + and the content 'This is a test of the interface SVGTextContentElement'. The word 'is' has two glyphs with different + rotation values defined with a <tspan/> element. There are 12 subtests testing the 9 methods and 2 properties. + Note that the numeric results of some methods may vary. The additional instructions state where the result may vary + and where it should have an exact value. +
++ [[ + Describe how to use the here. The instructions should specify any + steps requied to run the test or any manual operation that need + to be performed to run the test. + ]] +
++ The first subtest is testing the method .getCharNumAtPosition(svgPt), where svgPt has an x value of 240 and y value of 25. + The result of this subtest must be "30". +
++ The second subtest is testing the method .getComputedTextLength(). The rounded result may vary in the implementations but should be around 364. + A red line below the testText is visually indicating the result of the method .getComputedTextLength() and must look like a red underline + with a length that spans the whole text length from 'T' to '.'. +
++ The third subtest is testing the method .getEndPositionOfChar() at the 11th character ('e'). + The rounded result may vary in the implementations but should be around 131 for the 'x' value and must be 30 for the 'y' value. + Additionally, a red vertical line is indicating the end position of the character 'e'. Its lower 'y' value must be at 30 + and the 'x' values must match the end position of the 11th character 'e'. +
++ The fourth subtest is testing the method .getExtentOfChar() at the 11th character ('e'). + The rounded result may vary in the implementations but should be around '123,16,8,17' for the 'x,y,width,height' values. + A lightblue rectangle below the character 'e' must fully enclose the 11th glyph. +
++ The fifth subtest is testing the method .getNumberOfChars(). The result must be 54. +
++ The sixth subtest is testing the method .getRotationOfChar() for the fifth character. The result must be 45. + Additionally, a lightblue rectangle below the text indicates the extent of the fifth glyph 'i'. + It must fully enclose the diagonally rotated fifth glyph 'i'. +
++ The seventh subtest is testing the method .getStartPositionOfChar() at the 11th character ('e'). + The rounded result may vary in the implementations but should be around 123 for the 'x' value and must be 30 for the 'y' value. + Additionally, a red vertical line is indicating the start position of the character 'e'. Its lower 'y' value must be at 30 + and the 'x' values must match the end position of the 11th character 'e'. +
++ The eighth subtest is testing the method .getSubStringLength(), starting at character 22 and including the 9 following characters. + The result may vary in the implementations but should be around 58. Additionally, a green (lime) line visually indicates + the result of the method. The word 'interface' must be fully underlined with the green line. +
++ The ninth subtest is testing the method .selectSubString(). After loading the file, the word "the" must be selected. +
++ The tenth subtest is testing the property .textLength. The rounded result of .textLength.baseVal.value may vary in + the implementations but should be around 364. + It must match the value calculated in the second subtest (.getComputedTextLength()). +
++ The eleventh subtest is again testing the property .textLength. The rounded result of .textLength.animVal.value may vary in + the implementations but should be around 364. + It must match the value calculated in the second subtest (.getComputedTextLength()). +
++ The twelfth subtest is again testing the property .lengthAdjust. The results of .lengthAdjust.baseVal and + .lengthAdjust.animVal must be 1 and 1. +
++ This tests that methods on the SVGTextContentElement interface + that take an index to a character or a number of characters + actually interpret these as indexes to or numbers of UTF-16 code + units. To test this, a character from outside the Basic Multilingual Plane + (U+10000; LINEAR B SYLLABLE B008) is used in a text string. + This character is stored in UTF-16 as a surrogate pair. +
++ The test consists of two sub-tests, which test those methods + on the SVGTextContentElement interface which do not rely on rendering. The result + of each sub-test is shown as a small rectangle: black + indicates that the sub-test did not run, red indicates that + the sub-test failed and green indicates that the sub-test + succeeded. +
++ Run the test. No interaction required. +
++ The test is passed if both rectangles are green. +
++ This tests that SVGTextContentElement.getSubStringLength() + handles out-of-range charnum and nchars parameter values correctly. +
++ The test consists of 5 sub-tests, which test the different + combinations of values passed to SVGTextContentElement.getSubStringLength(). + The result of each sub-test is shown as a small rectangle: black + indicates that the sub-test did not run, red indicates that + the sub-test failed and green indicates that the sub-test + succeeded. +
++ Run the test. No interaction required. The test relies on support for SVG Fonts. +
++ The test is passed if all 5 rectangles are green. +
++ This tests the SVGTextContentElement.getSubStringLength method. +
++ Run the test. No interaction required. +
++ To pass the test there should be no red visible. +
++ This tests that methods on the SVGTextContentElement interface + that take an index to a character or a number of characters + actually interpret these as indexes to or numbers of UTF-16 code + units. To test this, a character from outside the Basic Multilingual Plane + (U+10000; LINEAR B SYLLABLE B008) is used in a text string. + This character is stored in UTF-16 as a surrogate pair. +
++ The test consists of 5 sub-tests, which test the methods + methods on the SVGTextContentElement interface. The result + of each sub-test is shown as a small rectangle: black + indicates that the sub-test did not run, red indicates that + the sub-test failed and green indicates that the sub-test + succeeded. +
++ Run the test. No interaction required. +
++ The test relies on support for WebFonts - either SVG Fonts, or WOFF, or OpenType. +
++ The test is passed if all 5 rectangles are green. +
++ Purpose of test is to determine if the font family is being + correctly selected. The top two lines of text test serif fonts; + the top line in maroon tests the generic font family 'serif' + and the second line in black tests a selection of commonly + available named serif fonts. The next two lines of text test + sans-serif fonts; + the top line in maroon tests the generic font family 'sans-serif' + and the second line in black tests a selection of commonly + available named sans serif fonts. The following two lines + of text test monospaced fonts; + the top line in maroon tests the generic font family 'monospaced' + and the second line in black tests a selection of commonly + available named monospaced fonts. The lowercase 'i' and uppercase'W' + should be the same width,for monospaced fonts. +
++ The seventh line of text, in green, tests for + three non-existent fonts (nonsense names). There is no fallback + generic font specified. The text must be displayed anyway. +
++ Run the test. No interaction required. +
++ The first six lines contain two Japanese characters (ç”»åƒ) + at the end of the line. Both of these characters must be displayed, + although it is compliant to display them with the 'missing glyph' + if no suitable font containing Japanese characters can be found. + Most but not all fonts have a visible missing glyph character. + If the selected font has a visible missing glyph character, it should appear + wherever the corresponding glyph is not available. +
++ Purpose of test is to determine if the font weight is being + correctly rendered. A number of font families are specified. The + numerical weight values (100 to 900) should show the lighter weights + on the lower numbers and the heavier weights on the larger numbers. + Heavier is defined to mean 'no lighter'. +
++ If only one font weight is available, they should all display at the + same weight. The transition from black to green figures shows the + correct light to bold transition for the common case where two + weights are available. If three or more weights are available, see + the CSS2 specification for how these are allocated to the nine + weight numbers. +
++ The absolute keywords 'normal' and bold' are tested + by the first two lines on the right hand side of the test, + the third line of text tests the to 'bolder' + relative keyword and the fourth tests the + 'lighter' relative keyword. +
++ Run the test. No interaction required. +
++ The numerical weight values (100 to 900) should show the lighter weights on the + lower numbers and the heavier weights on the larger numbers. Heavier is defined + to mean 'no lighter'. +
++ Testing font-family attribute. + Two SVG fonts are defined. Various text elements are then + used with varying values for the font-family attribute. +
++ Run the test. No interaction required. +
++ The first two text elements should display in their respective fonts, + the last two should be displayed using the system font since the + value specified for font-family is either invalid or not specified. +
++ Testing font-family attribute. + Various text elements are + used with varying values for the font-family attribute. +
++ Run the test. No interaction required. +
++ The first two text elements should display in their respective fonts, + Haettenschweiler and + Charlesworth, + if they are installed on the target system. Otherwise, simply + displaying the text in some fallback font is enough to pass the test. + The last two should be displayed using a fallback font since the + value specified for font-family is either invalid or not specified. + Failing to display the text means the test is not passed. +
++ Test that the 'line-height' property has no effect on text layout. +
++ Run the test. No interaction required. +
++ Test passes if the three blue instances of 'Filler Text' all have the same vertical position on the page. +
++ This tests the 'font-weight' property when multiple weights are available. A + font family with six weights is specified, with a fallback to 'serif'. +
++ If only one font weight is available, they should all display at the same weight. + The transition from black to green figures shows the correct light to bold transition + for the common case where two weights are available. If three or more weights are + available, see the CSS2 specification for how these are allocated to the nine weight + numbers. The specified font has six weights. +
++ The absolute keywords 'normal' and bold' are tested by the first two lines on the + right hand side of the test, the third line of text tests the to 'bolder' relative + keyword and the fourth tests the 'lighter' relative keyword. +
++ If the platform supports installable opentype fonts, please download and install + Zalamander Caps + by Tim Ahrens of Just Another Foundry. + Then, view this test. +
++ The numerical weight values (100 to 900) should show the lighter weights on the + lower numbers and the heavier weights on the larger numbers. Heavier is defined + to mean 'no lighter'. +
++ This tests the 'font-weight' property when multiple weights are available. A + font family with five weights is specified, with a fallback to 'serif'. +
++ The specified font family has five weights - 300, 400, 600, 700 and 800. + See the CSS3 Font specification + for how these are allocated to the nine weight numbers. +
++ The absolute keywords 'normal' and bold' are tested by the first two lines on the + right hand side of the test, the third line of text tests the to 'bolder' relative + keyword and the fourth tests the 'lighter' relative keyword. +
+The fonts are SVG fonts convertted, with the author's explicit permission, + from Zalamander Caps + by Tim Ahrens of Just Another Foundry. + An ASCII subset has been generated for this test. The font names have been + obfuscated, to deter + user agent sniffing for keywords like "Ultrabold". All weights in this generated + family are multiples of 100 and greater or equal to 300.
++ Run the test. No interaction required. +
++ The numerical weight values (100 to 900) should show the lighter weights on the + lower numbers and the heavier weights on the larger numbers. Heavier is defined + to mean 'no lighter'. +
++ This tests the 'font-weight' property when multiple weights are available. A + font family with five weights is specified, with a fallback to 'serif'. +
++ The specified font family has five weights - 300, 400, 600, 700 and 800. + See the CSS3 Font specification + for how these are allocated to the nine weight numbers. +
++ The absolute keywords 'normal' and bold' are tested by the first two lines on the + right hand side of the test, the third line of text tests the to 'bolder' relative + keyword and the fourth tests the 'lighter' relative keyword. +
+The fonts are WOFF fonts convertted, with the author's explicit permission, + from Zalamander Caps + by Tim Ahrens of Just Another Foundry. + The font names have been obfuscated, to deter + user agent sniffing for keywords like "Ultrabold". All weights in this generated + family are multiples of 100 and greater or equal to 300.
++ Run the test. No interaction required. +
++ The numerical weight values (100 to 900) should show the lighter weights on the + lower numbers and the heavier weights on the larger numbers. Heavier is defined + to mean 'no lighter'. +
++ Test left-to-right aspect of internationalized text. +
++ Various text strings in various languages appear. The main + purpose of the test is to verify that the correct characters + appear and that they appear in the correct order and orientation, even + though the first choice font does not have the right glyphs. +
++ Run the test. No interaction required. +
++ Correct rendering requires that each character is rendered. It may be rendered + with the 'missing glyph' if no + glyphs are found in the fonts listed in the content, or in any fallback font + that is available. The first choice font + is a special SVG font that only contains the 'missing glyph'. Missing glyph from + other fonts may conformantly be used, however. +
++ The test is passed if the lines of text appear as follows: +
++ Test various aspects of internationalized text, including + left-to-right, right-to-left, and the + following properties: 'writing-mode', + 'direction' and 'unicode-bidi'. +
++ Various text strings in various languages appear. Ttest of bidi algorithms and support of 'unicode-bidi' and + 'direction' properties. +
++ This test requires installation of a system font that supports + the various international characters used in this test case. A + suitable font should be used by the SVG renderer if none of the + specified font families are available (or if they are available but do + not have the required glyphs). +
++ Run the test. No interaction required. +
++ The test is passed if the correct characters + appear and they appear in the correct order and orientation. + Ensure that the three lines with Hebrew are ordered + correctly, as shown in the reference image. +
++ Test top-to-bottom internationalized text and the + following properties: 'writing-mode', + 'glyph-orientation-vertical', 'glyph-orientation-horizontal'. +
++ Various text strings in various languages appear. The main + purpose of the test is to verify that the correct characters + appear and that they appear in the correct order and orientation. + Ensure that the two lines of + vertical Japanese text have the proper orientation + (test of 'glyph-orientation-vertical' property). +
++ This test requires installation of a system font that supports + the various international characters used in this test case. A + suitable font should be used by the SVG renderer if none of the + specified font families are available (or if they are available but do + not have the required glyphs). To + minimize system dependencies, a future version of this test + might include all necessary glyphs as an SVG font. +
++ Run the test. No interaction required. +
++ The test is passed if first line of text has the english text "Text" and + "in Chinese" rotated 270 degrees and the Chinese text displayed top to + bottom. The second line of text has the english text "Japanese:" rotated + 270 degrees and the Japanese text displayed top to bottom. The third + line of text has the letters in the english text "Japanese:" displayed + vertically and the Japanese text displayed top to bottom. +
++ Test basic aspect of internationalized text. +
++ Various text strings in various languages appear. The main + purpose of the test is to verify that the correct characters + appear and that they appear in the correct order and orientation. +
++ A future version of this test + might include all necessary glyphs as an SVG font. +
++ Run the test. No interaction required. +
++ Correct rendering requires that each character is rendered. It is not required that a given character + be rendered with any particular font; just that it is rendered. + It may be rendered with the 'missing glyph' if no + glyphs are found in the fonts listed in the content, or in any fallback font that is available. +
++ Tests Arabic text using various platform fonts. If these fonts are not available, + a fallback font should be used that has Arabic glyphs. If such a font is not available, + the 'missing glyph' (typically an open rectangle) should be displayed. It is an error + to display the wrong Arabic glyphs, for example to display all isolate forms. +
++ Run the test. No interaction required. +
++ The text should be positioned such that the begining of the start of the + Arabic text is at very right of the test and runs towards the left of + the test border. +
++ This test ensures that mandatory ligatures in Arabic are displayed. + This test uses WOFF fonts for rendering, with platform fonts for fallback. +
++ There are two subtests. The first + requires an isolate lam-alef ligature and the second requires + a right-joining lam-alef ligature. +
++ The first subtest has the word for 'tools', آلات + 0622: آ ARABIC LETTER ALEF WITH MADDA ABOVE + 0644: ل ARABIC LETTER LAM + 0627: ا ARABIC LETTER ALEF + 062A: ت ARABIC LETTER TEH +
++ The second subtest has the word for 'three', ثلاثة + 062B: ث ARABIC LETTER THEH + 0644: ل ARABIC LETTER LAM + 0627: ا ARABIC LETTER ALEF + 062B: ث ARABIC LETTER THEH + 0629: ة ARABIC LETTER TEH MARBUTA +
++ Run the test. No interaction required. +
++ The test is passed if subtests are displayed as following: +
+In the first subtest, there must be an isolate lam-alef ligature + and in the second subtest there must be a right-joining lam-alef + ligature, (so that them, lam and alef are all connected), as in the reference image. +
+The precise glyph shapes will depend on which font was used for rendering, + and do not affect the pass criteria. Only the presence of the + mandatory ligatures is tested here.
+This test ensures that mandatory ligatures in Arabic are displayed.
++ There are two subtests. The first requires an isolate lam-alef ligature + and the second requires a right-joining lam-alef ligature. +
+Run the test. No interaction required.
++ The test is passed if subtests are displayed as following: +
++ Test various aspects of internationalized text, including + left-to-right, right-to-left, and the + following properties: 'writing-mode', + 'direction' and 'unicode-bidi'. +
++ Various text strings in various languages appear. Test of bidi algorithms and support of 'unicode-bidi' and + 'direction' properties. Uses Webfonts. +
++ This test uses Webfonts; both SVG and WOFF fonts are provided. +
++ Run the test. No interaction required. Make sure scripting is enabled. +
++ The test is passed if the correct characters + appear and they appear in the correct order and orientation. + Ensure that the three lines with Hebrew are ordered + correctly, as shown in the reference image. +
++ Tests Arabic text using various platform fonts. If these fonts are not available, + a fallback font should be used that has Arabic glyphs. If such a font is not available, + the 'missing glyph' (typically an open rectangle) should be displayed. It is an error + to display the wrong Arabic glyphs, for example to display all isolate forms. +
+This test uses writing-mode and direction to set the text as right-to-left.
++ Run the test. No interaction required. +
++ The text should be positioned such that the begining of the start of the + Arabic text is at very right of the test and runs towards the left of + the test border. +
++ This test ensures that mandatory ligatures in Arabic are displayed. + Three values for text-anchor are also tested; + middle, + start and + end. + This test uses platform fonts for rendering. +
++ There are two subtests. The first + requires an isolate lam-alef ligature and the second requires + a right-joining lam-alef ligature. +
++ The first subtest has the word for 'tools', آلات + 0622: آ ARABIC LETTER ALEF WITH MADDA ABOVE + 0644: ل ARABIC LETTER LAM + 0627: ا ARABIC LETTER ALEF + 062A: ت ARABIC LETTER TEH +
++ The second subtest has the word for 'three', ثلاثة + 062B: ث ARABIC LETTER THEH + 0644: ل ARABIC LETTER LAM + 0627: ا ARABIC LETTER ALEF + 062B: ث ARABIC LETTER THEH + 0629: ة ARABIC LETTER TEH MARBUTA +
++ Run the test. No interaction required. +
++ The test is passed if the blue glyphs آ and ث touch the first vertical + line. The second vertical line falls in middle of the brown glyphs + inbetween آلا and ت and inbetween ثلا and ثة. The black glyphs ت and ة + touch the last vertical line. +
++ This test ensures that mandatory ligatures in Arabic are displayed. + This test uses downloaded WOFF fonts for rendering. +
++ There are two subtests. The first + requires an isolate lam-alef ligature and the second requires + a right-joining lam-alef ligature. +
++ The first subtest has the word for 'tools', آلات + 0622: آ ARABIC LETTER ALEF WITH MADDA ABOVE + 0644: ل ARABIC LETTER LAM + 0627: ا ARABIC LETTER ALEF + 062A: ت ARABIC LETTER TEH +
++ The second subtest has the word for 'three', ثلاثة + 062B: ث ARABIC LETTER THEH + 0644: ل ARABIC LETTER LAM + 0627: ا ARABIC LETTER ALEF + 062B: ث ARABIC LETTER THEH + 0629: ة ARABIC LETTER TEH MARBUTA +
++ Run the test. No interaction required. +
++ The test is passed if subtests are displayed as following: +
+In the first subtest, there must be an isolate lam-alef ligature + and in the second subtest there must be a right-joining lam-alef + ligature, as in the reference image. +
++ Test textPath element in combination with the tspan element. Properties + of the text on a path are changed using the tspan element. +
++ Run the test. No interaction required. Make sure scripting is enabled. +
++ For this test to pass the rendered output must match the reference + image. The letters "Te" in first "Text on a path" sentence must be + colored pink and offset from the path in the y direction. +
++ This tests the 'textPath/startOffset' with both negative and positive values, and + compares it to the case where a 'tspan/dx' attribute is used with the same values. +
++ Run the test. No interaction required. Make sure scripting is enabled. +
++ You should see four paths with text following each path. + The top two paths should show the text "Negative offset", and the bottom two paths should show the text + "Positive offset". +
++ The test has passed if: +
++ Test properties 'letter-spacing' and 'word-spacing' +
++ The first three lines test property 'letter-spacing', with + values 0, -1 and .3em respectively. +
++ The next three lines test property 'word-spacing', with + values 0, -3 and 3em respectively. +
++ Run the test. No interaction required. +
++ This test is passed if: +
++ Test viewer capibility to handle basic use of 'textLength' + and 'lengthAdjust' attributes. +
++ There are four pairs of sub-tests. Each pair of sub-tests consists + of the same two strings: "Line to Stretch" on the left, and "this is + a line to squeeze" on the right. +
++ The first (topmost) pair contains no occurrences of the textLength and + lengthAdjust attributes in the 'text' elements. + The pink reference line under each of the top + two strings indicates the approximate length of the strings. Since + the lengths are not constrained by the 'textLength' attribute, small + variations of the lengths are permissible. +
++ The remaining three pairs each applies 'textLength' attributes to the + strings. In the leftmost sub-test of each pair, the 'textLength' value + will cause a stretching of the string of approximately 25% over the + "normal" length. In the rightmost sub-test of each pair, the 'textLength' value + will cause a squeezing of the string of approximately 20% under the + "normal" length for the string. +
++ In each of the sub-tests with an application of 'textLength', the + pink reference lines indicate the exact extent of the rendered text. + The rendered text should fit snugly just within the ticks at the end of + the pink lines. +
++ The second pair from the top contains 'textLength' but no 'lengthAdjust' + attributes. In this case, the effect should be as if the value "spacing" + were specified. Only the inter-character advancement and inter-word spacing + should change. The aspect ratio of the glyphs should be unaffected. The + reference image illustrates one valid way to achieve this, by a + uniform increase or decrease of inter-character advancement. +
++ The third pair from the top explicitly sets 'lengthAdjust' value + to "spacing". Therefore it should be rendered identically to the second pair. +
++ The fourth (bottommost) sub-test pair explicitly sets 'lengthAdjust' value + to "spacingAndGlyphs". The advancements between characters and words, as well as + the glyph aspect ratios should be affected. + The reference image illustrates one valid way to achieve + this, by a uniform expansion or compression of the string as a whole. + This effect is equivalent to application of a "scale(xfactor, 1.0)" transformation + to the 'text' elements. +
++ Run the test. No interaction required. +
++ The rendered picture should match the reference image, except as noted in the Test Description. + In particular, the 'textLength' constraint must be satisfied precisely, + and the basic rules associated with the "spacing" and "spacingAndGlyphs" values + of 'lengthAdjust' must be met, but the precise algorithm for meeting all + of the required contraints is otherwise unspecified. +
++ Test text element, tspan element and various text decorations +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ The purpose of this test is to validate proper handling of + the text element's x and y attributes. + In the various samples, a orange marker shows the text's (0,0) + coordinate. The blue markers show the current text positions. + These are either defined by absolute x/y positioning or they + are computed from the embeded font's glyphs advances. +
++ The first text sample shows a reference piece of text. +
++ The second text sample (x all) shows a piece of text where + all the glyphs are positioned along the x axis. +
++ The third text sample (x more) is a text element where there + are more x values than characters (5 values for 4 characters). + The last x value should be ignored and the result should + be the same as the third sample. +
++ The fourth text sample (x fewer) is a text element where there + are fewer x values than characters (3 values for 4 characters). + The last character should not be positioned but laid out normally, + following its previous character sibling. +
++ The fifth (y all), sixth (y more) and seventh (y fewer) text sample + parallel the second, + third and fourth test, but for the y attribute values. +
++ The samples in the right column show combinations of x/y + value sets. +
++ Run the test. No interaction required. +
++ In all the above tests, blue markers represent the expected glyph + positions. The orange markers are showing positions where no glyph + should appear. The glyphs are black squares of increasing sizes. +
++ The purpose of this test is to validate the interaction of text-anchor + and x/y glyph positioning. +
++ Each row shows a different combination of x/y values: 1, more than characters, + fewer than characters. This tests the anchor value: start. +
++ The blue markers show the various x/y absolute positions around which text + chunks should be anchored. The glyphs are black squares of increasing sizes. +
++ Run the test. No interaction required. +
++ Rendered output must match the reference image for the test to pass. +
++ The purpose of this test is to validate the interaction of x/y + glyph positioning and ligatures. +
++ The first line shows an example where there is a ligature (fi) which + should be accounted for before breaking into text chunks (see specification + section 10.5, additional x/y/dx/dy processing rules, bullet discussing + ligatures). In this first line, the ligatures cause the x position 180 + (shown in orange), to be ignored. As a result, a glyph should be shown over + each pale blue square markers. The glyphs are black squares of increasing sizes + except for the initial ligature which has the form of two small black triangles + joined at their tops. The ligature should show on the first pale blue + marker position. +
++ The second line shows the same test but using multiple y positions. +
++ The third line shows the same test but using multiple x and y + positions. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Tests multiple x, y, rotate, with various combinations. Since an + array of values is given, each glyph must use the value from the + corresponding character in the list. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ The three opacity properties (fill-opacity, + stroke-opacity, and opacity) of 'text' elements are + covered in this test. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Tests multiple x, y, rotate, with various combinations. Since an + array of values is given, each glyph must use the value from the + corresponding character in the list. In this test, there are less values + in the array than there are characters. +
++ Run the test. No interaction required. +
++ The test is passed if: +
++ Test rendering of text rotated by a transform attribute. +
++ Run the test. No interaction required. +
++ The test has passed if the image shows text rotated by various different angles, the result should closely match the reference image. +
++ Test rendering of text rotated by a transform attribute, same as the text-text-10-t test but not using an SVGFont. +
++ Run the test. No interaction required. +
++ The test has passed if the image shows text rotated by various different angles, the result should closely match the reference image, but note that the font is allowed + be different from the font used in the reference image. +
+ISSUE: the glyphs don't cover the entire em-cell, and the spec doesn't require visual alignment - text adjustments are based on advances
++ The purpose of this test is to validate the interaction of text-anchor + and x/y glyph positioning. +
++ Each row shows a different combination of x/y values: 1, more than characters, + fewer than characters. Each column shows different anchor values: middle + and end. +
++ The blue markers show the various x/y absolute positions around which text + chunks should be anchored. The glyphs are black squares of increasing sizes. +
++ Run the test. No interaction required. +
++ Rendered output must match the reference image for the test to pass. +
++ Test viewer capability to handle a basic 'tref' element + which points to a text string in an external file. +
++ The test case consists of a single sub-test. +
++ Run the test. No interaction required. +
++ The box in the middle of the frame should + contain green "Simple external referenced text.", + which is obtained by a 'tref' element reference to a 'text' element in a 'defs' + section of another file (text-extTref-BE-18-targ.svg). +
++ Test viewer capability to handle 'tref' elements + which point to text strings outside the current SVG document fragment. +
++ The test case consists of two sub-tests; one results in the word "Hello" and the second, the word "World". +
++ Run the test. No interaction required. +
++ The test is passed if the phrase "Hello World" is displayed, in green. +
++ Test viewer capability to handle 'tref' elements + which point to elements that have children. The flattened text content is to be used. +
++ The test case consists of one sub-test; it results in the word "Flattened" being displayed. +
++ Run the test. No interaction required. +
++ The test is passed if the phrase "Flattened" is displayed, all in green and at the same font size. +
++ Test text selection. +
++ Run the test. Make a text selection in the upper block of text, and verify that text selection is possible and that the selection does not extend across multiple lines. Now make a text selection in the lower block of text, verifying that the selection does extend over multiple lines. + +Thus, it should + be possible to start text selection at the start of the "However" + and drag through the end of "same time." and the all four lines + should be selected. +
++ Run the test. No interaction required. +
++ For basic viewers conformant acion is as described above if there + is a text selection mechanism. Since text selection is optional + on a basic device if text selection is not implemented then this + test is a pass, move on to the next test. +
++ This test demonstrates text selection of bidirectional text. +
++ Run the test. No interaction required. +
++ The initial result should be that the first 9 characters in logical order + starting from logical position 0 are selected. +
++ Visually the selection is discontigous and these substrings must be selected (listed in visual order): +
++ "abc" +
++ the space between "c" and "ו" +
++ "1" +
++ the space between "3" and "×’" +
++ "×בג" +
++ If only the substrings listed above were selected then the test has passed. +
++ A user agent that allows selecting text in logical order would have generated the same selection + as in this testcase if the user started the selection on the character "a" and ended it on the + character "1". + + A user agent that allows selecting text in visual order would not have a discontigous selection + if the user started the selection on the character "a" and ended it on the character "1". The copied + text would be discontigous instead in this case. + + Note that the SVG DOM method requires logical order text selection, so for both types of user agents + this testcase must look the same. +
++ The testcase also shows what happens when the selection is modified via DOM (click the buttons below + the bidi-text). Compliant viewers must throw an exception when the first parameter handed + to SVGTextContentElement.selectSubString is out-of-range. + That means the variable 'startIndex' must always be in the range 0 <= startIndex <= 18. + It can be noted that the parameter 'numChars' is not restricted in this way. +
++ Note that the color of the text selection is UA dependent and not defined in the SVG specification. +
++ This test demonstrates text selection of bidirectional text. +
++ Run the test. No interaction required. +
++ The initial result should be that the first 9 characters in logical order + starting from logical position 0 are selected. +
++ Visually the selection is discontigous and these substrings must be selected (listed in visual order): +
++ "abc" +
++ the space between "c" and "ו" +
++ "1" +
++ the space between "3" and "×’" +
++ "×בג" +
++ If only the substrings listed above were selected then the test has passed. +
++ A user agent that allows selecting text in logical order would have generated the same selection + as in this testcase if the user started the selection on the character "a" and ended it on the + character "1". + + A user agent that allows selecting text in visual order would not have a discontigous selection + if the user started the selection on the character "a" and ended it on the character "1". The copied + text would be discontigous instead in this case. + + Note that the SVG DOM method requires logical order text selection, so for both types of user agents + this testcase must look the same. +
++ The testcase also shows what happens when the selection is modified via DOM (click the buttons below + the bidi-text). Compliant viewers must throw an exception when the first parameter handed + to SVGTextContentElement.selectSubString is out-of-range. + That means the variable 'startIndex' must always be in the range 0 <= startIndex <= 18. + It can be noted that the parameter 'numChars' is not restricted in this way. +
++ Note that the color of the text selection is UA dependent and not defined in the SVG specification. +
++ Test tspan element styling and relative position adjustments. +
++ Run the test. No interaction required. +
++ The test has passed if: +
++ Tests the rotate attribute in the tspan element. +
++ Run the test. No interaction required. +
++ For this test to pass the text "Not all characters in the text have a + specified rotation" must be displayed in green without any red showing. + If any red shows the test is a fail. +
++ Rotation values: +
++ Test for viewer correct handling of whitespace and the 'xml:space' attribute. + There are two sub-tests, for xml:space value "default". + In each test, the content of the 'text' element is written on + multiple lines. The first test of each pair has indented text with leading + space characters, tabs, etc. The second has no indentation, but a line break + before the content and after it. There are no space (or other whitespace) + characters at the ends of the lines. +
++ The two test cases are self-descriptive. From the top; + first, "default" value applied to 3 lines of content with indents, space characters, tabs, etc; + second, "default" applied to two lines content with no indent; +
++ Run the test. No interaction required. +
++ In each test, the test string is in blue and the reference + image is in black. + The rendered picture should approximately match the reference image, + however there is some question in the reference image concerning the + exact amount of space in the long-space areas. The third test uses the nbsp unicode character + to force the reference white spaces display, which provides an accurate match if the font in use + has the same metrics for that character and the default white space. + Also, variations are possible in the text fonts and layout (per CSS2 rules). +
++ The test also uses the 'rect' element, + as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family (Arial) + and font-size properties. +
++ Test for viewer correct handling of whitespace and the 'xml:space' attribute. + There are two sub-tests, for value "preserve". + In each test, the content of the 'text' element is written on + multiple lines. The first test of each pair has indented text with leading + space characters, tabs, etc. The second has no indentation, but a line break + before the content and after it. There are no space (or other whitespace) + characters at the ends of the lines. +
++ The two test cases are self-descriptive. From the top; + first, "preserve" applied to essentially the same content as first; + second, "preserve" applied to essentially the same content as second. +
++ Run the test. No interaction required. +
++ In each test, the test string is in blue and the reference + image is in black. + The rendered picture should approximately match the reference image, + however there is some question in the reference image concerning the + exact amount of space in the long-space areas. The third test uses the nbsp unicode character + to force the reference white spaces display, which provides an accurate match if the font in use + has the same metrics for that character and the default white space. + Also, variations are possible in the text fonts and layout (per CSS2 rules). +
++ The test also uses the 'rect' element, + as well as basic fill (solid primary colors), + stroke (black 1-pixel lines), font-family + and font-size properties. +
++ Tests scientific notation in attribute values; in particular, that numbers + of the form .n with a leading decimal point, are supported +
++ Run the test. No interaction required. +
++ The test is passed if all the coloured rectangles are of the same height + and line up with each other and + with the grey marker lines. If any red is visible, the test fails. +
++ Tests units and no units on <length> in CSS on a property defined in the SVG specification. +
++ Run the test. No interaction required. +
++ The test is passed if there are six circles with the same thick green stroke visible, and no red. + If the SVG user agent doesn't support CSS styling then this test does not apply. +
++ This test checks all the methods and properties of the SVGLocatable interface. + Note the use of nested svg elements and testing against different elements in the hierarchy. + Note that the values of .getScreenCTM() and .getCTM() can only be tested correctly if they are + in the html-based test or the width and height of the root element is explicitly set to 480x360. + The methods .getScreenCTM() and .getCTM() are tested from the rotated text element, the method .getBBox(), + .getTransformToElement() is tested between the rotated text and its parent group, the method .getBBox() and + the properties .farthestViewportElement and .nearestViewportElement are tested on the blue circle. +
++ Run the test. No interaction required. Make sure scripting is enabled. +
++ For the test to pass, the values generated by script must match the values provided in the png image. The correct values are: +
++ .getScreenCTM() for id "rotText": 0.42,0.42,-0.42,0.42,70.00,-60.00 +
++ .getCTM() for id "rotText": 0.42,0.42,-0.42,0.42,70.00,-60.00 +
++ .getTransformToElement() between id "rotText" and id "parentGroup": 0.42,0.42,-0.42,0.42,0.00,0.00 +
++ .getBBox() for 'blueCircle': .x=-50,.y=-50,.width=100,.height=100 +
++ .farthestViewportElement of blueCircle=svg-root +
++ .nearestViewportElement of blueCircle=nestedSVG +
++ This tests that the animVal properties that are objects + are always distinct from their corresponding baseVal properties. + This is tested for interfaces SVGAnimatedNumberList, SVGAnimatedLength, + SVGAnimatedLengthList, SVGAnimatedAngle, SVGAnimatedRect, + SVGAnimatedTransformList and SVGAnimatedPreserveAspectRatio. +
++ Run the test. No interaction required. +
++ Once loaded, the test shows 7 rectangles + representing seven sub-tests reflecting + the result of checking that an animVal object is + not the same object as its corresponding baseVal object. + Each rectangle will be either black to indicate that + the sub-test wasn't run, red to indicate that the + sub-test failed, and green to indicate that the + sub-test passed. +
++ The test is passed if all 7 rectangles are green. +
++ Test that bounding box geometry can be obtained + before the SVGLoad event is dispatched. +
++ Run the test. No interaction required. +
++ Load the test. A rectangle will be shown indicating + the result of the test. It will be black if test + did not run, red if the test failed and green if + the test passed. +
++ The test is passed if the rectangle is green. +
++ This tests that SVG DOM objects that correspond to attributes + are live. + This is tested for interfaces + SVGAnimatedNumberList, SVGAnimatedLength, + SVGAnimatedLengthList, SVGAnimatedAngle, SVGAnimatedRect, + SVGAnimatedTransformList, SVGAnimatedPreserveAspectRatio, + SVGAnimatedBoolean, SVGAnimatedString, SVGAnimatedEnumeration, + SVGAnimatedInteger and SVGAnimatedNumber. +
++ Run the test. No interaction required. +
++ Once loaded, the test shows 12 rectangles, one for + each sub-test. Each sub-test is checking that + an SVG DOM object of a particular interface is live. + The rectangle indicates the result of running the + sub-test: black to indicate that it wasn't run, + red to indicate that it failed, and green to indicate + that it passed. +
++ The test is passed if all 12 rectangles are green. +
++ This tests that assigning a valid length or angle string to + valueAsString on an SVGLength or SVGAngle will affect that object's + unitType, and that assigning an invalid string will throw + a DOMException with code SYNTAX_ERR. +
++ Run the test. No interaction required. +
++ Once the test is loaded, four rectangles are presented, indicating + the result of passing a valid or invalid string to an + SVGLength or SVGAngle object, as indicated. Each rectangle + will be black if the sub-test did not run, red if it + failed or green if it passed. +
++ The test is passed if all four rectangles are green. +
++ This tests parts of the SVGStringList interface. Particularly it tests that + strings that are taken from one SVGStringList and then inserted into another + SVGStringList duplicates the value instead of removing the value from the + first list when it's inserted into the second list. +
++ Run the test. No interaction required. +
++ The test has passed if there are three green rectangles visible and no red. Red is an indication that the test failed. +
++ This tests that the contents of an animVal object are read only. + This is tested for interfaces SVGAnimatedNumberList, SVGAnimatedLength, + SVGAnimatedLengthList, SVGAnimatedAngle, SVGAnimatedRect, + SVGAnimatedTransformList and SVGAnimatedPreserveAspectRatio. +
++ Run the test. No interaction required. +
++ Once loaded, the test shows 7 rectangles + representing seven sub-tests reflecting the result + of checking that an animVal object's contents is read + only. + Each rectangle will be either black to indicate that + the sub-test wasn't run, red to indicate that the + sub-test failed, and green to indicate that the + sub-test passed. +
++ The test is passed if all 7 rectangles are green. +
++ This test draws a few basic shapes and checks for correct values from getBBox(). +
++ Run the test. No interaction required. +
++ To pass, each returned bounding box must be correct (indicated by printing the values in green), and when this happens the text in the rect with blue stroke changes from 'failed' to 'passed'. +
++ Retrieving the 'viewBox' and 'preserveAspectRatio' attributes of the 'SVGFitToViewBox' interface is supported. +
++ Run the test. No interaction required. +
++ Test passes if there is no red visible on the page. +
++ The 'getItem', 'replaceItem', and 'removeItem' operations of the 'SVGLengthList' interface raise the 'INDEX_SIZE_ERR' exception when the specified + index number is greater than the number of items in the list. +
++ Retrieve a 'SVGLengthList' object by getting the 'baseVal' attribute from the 'x' object of a 'SVGTextElement'. Attempt to call 'getItem', + 'replaceItem', and 'removeItem' with an index larger than the number of items in the list. For each of these operations, verify there was an + exception of type 'INDEX_SIZE_ERR' thrown. +
++ Test passes if there is no red visible on the page. +
++ The 'getItem', 'replaceItem', and 'removeItem' operations of the 'SVGNumberList' interface raise the 'INDEX_SIZE_ERR' exception when the specified + index number is greater than the number of items in the list. +
++ Retrieve a 'SVGNumberList' object by getting the 'baseVal' attribute from the 'rotate' object of a 'SVGTextElement'. Attempt to call 'getItem', + 'replaceItem', and 'removeItem' with an index larger than the number of items in the list. For each of these operations, verify there was an + exception of type 'INDEX_SIZE_ERR' thrown. +
++ Test passes if there is no red visible on the page. +
++ The 'getItem', 'replaceItem', and 'removeItem' operations of the 'SVGStringList' interface raise the 'INDEX_SIZE_ERR' exception when the specified index number + is greater than the number of items in the list. +
++ Retrieve a 'SVGStringList' object by getting the 'requiredExtensions' attribute from a 'SVGSVGElement'. Attempt to call 'getItem', 'replaceItem', + and 'removeItem' with an index larger than the number of items in the list. For each of these operations, verify there was an exception of type 'INDEX_SIZE_ERR' thrown. +
++ Test passes if there is no red visible on the page. +
++ Retrieving and setting the 'transform' attribute of the 'SVGTransformable' interface is supported. +
++ Test passes if there is no red visible on the page. +
+