+ 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.
+
+ 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.
+
+ An animation moves a triangle along a path. Reference rectangles, lines and text are provided to help show what the
+ correct behavior is. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'from' and 'to' attributes to define the 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. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'values' attribute to define the motion path, with a linear calcMode.
+ An animation moves a triangle along a path. Reference rectangles, lines and text are provided to help show what
+ the correct behavior is. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'path' attribute to define the 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. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'mpath' sub-element to define the motion path.
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+ 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.
+
+ 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 red text shows the attributes that were used for that particular animation.
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 test shows an animation with calcMode="discrete" (i.e., a jumping animation).
+ 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 test shows calcMode="paced" for an animation that has constant velocity, thus showing how 'values' and
+ 'keyTimes' are ignored.
+
+ 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.
+
+ 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".
+ 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 red square appearing, gradually and smoothly fading
+ from white to red over the course of three seconds.
+
+
+ The rendered picture should match the reference image, (except for possible variations in the labeling text
+ (per CSS2 rules)) after activating the link on the fade-in button the first time and waiting three seconds for the
+ animation to compete. The picture should remain looking the same way indefinitely, until another link is activated.
+
+
+ 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 red square goes from white to red. After the first click on "fade out", the red square goes from red
+ to white. After the second click on "fade in", however, the red square goes from white to red, and then goes back
+ from red to white. This is because of the hyperlinking rules as they relate to resolved start times in the SMIL
+ 2.1 specification.
+
+ Five orange rectangles have one animation each. When an
+ animation is active it moves its orange rectangle from its
+ left marker to its right marker. The active intervals
+ are [1-2], [4-6] and [8-10].
+
+ Precision test for accumulative animateMotion.
+
+
+ The main indication for a failed test is the appearence of something
+ red and that circles are not centered below the paths given in gray.
+
+
+ Circles are moved along squares given with the path attribute,
+ repeatDur and accumulate with a repeatDur of 30s and repetition.
+ Different values for the rotate attribute are given too, this has no visible effect,
+ because centered circles are moved.
+
+ Precision test for additive animateMotion using,
+ mpath element, path attribute, values, from-to.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the circle. A switch of the stroke of the circle from blue to gray indicates
+ the end of the test at 30s.
+
+
+ A circles is moved along some paths
+ (two of them indicated in gray) with
+ a duration of 30s using additive animateMotion.
+ The superposition is no motion.
+ The circle is positioned always at the bottom right.
+ The colour of the circle switches from blue to gray after
+ the animation is finished.
+ If the red center of the circle becomes visible, an error is
+ occured.
+
+ Precision test for linear animateMotion with separated path fragments,
+ mpath element, rotate auto.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the test circle. The circle has to follow exactly the paths given
+ in gray.
+
+
+ A linear animateMotion of a blue stroked square with a centered
+ circle is compared with four animateMotion of a red square
+ with a centered circle.
+ The motion of the red square is following the
+ combination of four animateMotion following on
+ each other and is the same as the motion of the blue
+ square, because the timing is choosen in such a way.
+ Therefore the blue square covers always the red one
+ completely.
+
+
+ The path is given in gray. The red fill of the circle
+ is always covered with the gray path.
+ Eight gray stroked markers are lightened, when the circle
+ is exactly above the marker. The red fill of the marker
+ is exactly covered by the blue stroked circle.
+ If something red gets visible, an error is occured
+ and the animateMotion is not linear.
+
+
+ The exact timing is calculated using an analytical
+ integration of the path length of the sub paths
+ (this is available for quadratic or linear curves).
+ With this method the path position and the
+ time can be determined as functions of the usual
+ parametrisation of the used Bézier curves.
+
+ Precision tests for animateMotion with animated mpath.
+
+
+ The main indication for a failed test is the appearence of something
+ red and that circles are not centered below the paths given in gray.
+
+
+ Blue rectangles and a red circles are moved along
+ light blue paths with a duration of 30s. The paths itself are animated.
+ This results in motions along the gray paths. The rectangles
+ are aligned along the animated light blue paths.
+ The circle is always covered by the path given in gray.
+ If something red gets visible, an error is occured.
+
+ Precision test for paced animateMotion with separated path fragments,
+ mpath element, rotate auto.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the test circle. The circle has to follow exactly the paths given
+ in gray.
+
+
+ A paced animateMotion of a blue stroked square with a centered
+ circle is compared with four animateMotion of a red square
+ with a centered circle.
+ The motion of the red square is following the
+ combination of four animateMotion following on
+ each other and is the same as the motion of the blue
+ square, because the timing is choosen in such a way.
+ Therefore the blue square covers always the red one
+ completely.
+
+
+ The path is given in gray. The red fill of the circle
+ is always covered with the gray path.
+ Eight gray stroked markers are lightened, when the circle
+ is exactly above the marker. The red fill of the marker
+ is exactly covered by the blue stroked circle.
+ If something red gets visible, an error is occured
+ and the animateMotion is not paced.
+
+
+ The exact timing is calculated using an analytical
+ integration of the path length of the sub paths
+ (this is available for quadratic or linear curves).
+ With this method the path position and the
+ time can be determined as functions of the usual
+ parametrization of the used Bézier curves.
+
Compare from-to, from-by and by animate with values animate.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ Additionally set animations can be replaced by values animations too.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
values="0;a" additive="sum"
+
+
+
set to="a"
+
values="a" additive="replace" accumulate="none"
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space.)
+
+
+ The from-to, from-by and by animations applied to the attributes x, y, width, height
+ of blue rectangles are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red rectangles. Additionally underlying dark red
+ rectangles simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The blue rectangles cover all red rectangles. Therefore if something
+ red gets visible, an error is occured. Because fill is always not set and therefore remove,
+ the final value is only that of the set animation, not very interesting for the test.
+
+ 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 red square appearing, gradually and smoothly fading
+ from white to red 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 red square.
+
+
+ The rendered picture should match the reference image, (except for possible variations in the labeling text
+ (per CSS2 rules)) after activating the link on the fade-in button the first time and waiting three seconds for the
+ animation to compete. The picture should remain looking the same way indefinitely, until another link is activated.
+
+
+ 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 red square goes from zero to 100% opacity. After the first click on "fade out", the red square goes
+ from red to white. After the second click on "fade in", however, the red square goes from white to red, and then
+ goes back from red to white. This is because of the hyperlinking rules as they relate to resolved start times in
+ the SMIL 2.1 specification.
+
Compare from-to, from-by and by animateColor with values animateColor and animate.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animations. Therefore they have to be the same as the related values animation.
+ Additionally set animations can be replaced by values animations too.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
values="0;a" additive="sum"
+
+
+
set to="a"
+
values="a" additive="replace" accumulate="none"
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. In the color space
+ 0 is represented by black, #000, #000000, rgb(0,0,0) etc. Addition is performed for each
+ of the three components of the color vector separately.)
+
+
+ The from-to, from-by and by animations applied to fill properties
+ of circles are compared with the related values animations including additive and
+ cumulative hehaviour for the stroke of the same circles. Additionally underlying
+ filled larger circles simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The fill of the background circle and stroke and fill of the smaller
+ test circle centered in it are always exactly the same. Therefore if
+ rings in each centered circle system with different color get visible, an error is occured.
+ But each separated circle system representing one of 12 subtests can have another color.
+ Because the fill attribute for animation is always not set and therefore remove,
+ the final value is only that of the set animation, not very interesting for the test.
+
Compare from-to, from-by and by animateMotion with values animateMotion.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateMotion
+ the '0' is no motion or is related to a translation given in coordinates: 0,0.)
+
+
+ The from-to, from-by and by are applied to animateMotion of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The blue paths cover all red paths. Therefore if something
+ red gets visible, an error is occured. Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateMotion, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform rotate (around zero) with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the rotate type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive rotate angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the rotate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform rotate with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the rotate type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive rotate angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the rotate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform scale with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the scale type this is a scaling with 0,0, this means no display if not added to another
+ value. Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive.)
+
+
+ The from-to, from-by and by are applied to animateTransform of the scale type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
+ Compare from-to, from-by and by animateTransform translate with values
+ animateTransform and animateMotion.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the translate type this is a translation given in coordinates: 0,0.)
+
+
+ The from-to, from-by and by are applied to animateTransform of the translate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform skewX with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the skewX type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive skewX angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the skewX type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform skewY with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the skewY type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive skewY angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the skewY type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
+ xml:id or id? Identification of the element, that is target of an animation.
+ For authors it is recommended not to use different for id and xml:id for the same
+ element and not the same value for id in one element and the same value for
+ xml:id in another element. This is done in this document only as a (stupid) test,
+ not as an application.
+
+
+ The main indication for a failed test is the appearance of red or no animation after 2s.
+
+
+ Because for historical reasons, SVG tiny 1.2 has two fragment identifiers.
+ It is recommended, that xml:id is used and not only id. As a consequence
+ it is possible to have two different identifier values for one element.
+ In such a case, id is skipped and only xml:id has to be choosen.
+
+ In this test the height of the blue rectangle is set to another value. This is compared
+ with a set animation of another red rectangle, having the same value for xml:id and
+ id. The blue rectangle has to cover always the red one. If something red is visible,
+ an error is occured.
+
+ Identify the attributeType and the priority of an animation.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ With the top triangle is tested, that the points attribute of a
+ polygon is animated using attributeType auto or XML and
+ is not animated if CSS is used, because there is no CSS property
+ points applicable for the polygon element.
+
+
+ The bottom triangles test the priority for an animation with
+ attributeType CSS or auto over an XML animation, all for the
+ stroke attribute. Even if the attributeType is completely ignored,
+ the priority should still work for the bottom right triangle,
+ because the priority is set here with a later begin.
+
+
+ In all cases the coloring or positioning of elements is choosen in
+ such a way, that normally not visible lower priority or not
+ applicable animations are indicated with a red stroke,
+ higher priority or applicable animations with a blue stroke
+ or an animation in the blue range.
+
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 to big.
+
+ 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.
+
+ Correct timing with begin, end, dur, fill, max.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ Simple from to animations for cx and cy of a blue stroked
+ circle are stopped with max attributes.
+ The gray path gives the correct trajectory.
+ If the red center of the circle becomes visible, an error is
+ occured.
+
+ Correct timing with begin, end, dur, fill, min.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ Simple from to animations for cx and cy of a blue stroked
+ circle are used with begin, dur, end, fill and min attributes and
+ correlated with syncbase values.
+ This is compared with simple animateMotion with the
+ same trajectory and timing.
+ The related red circle is always
+ covered by the blue stroke circle.
+ The gray path gives the correct trajectory.
+
+
+ The test is passed if the blue circle follows the defined path.
+ If part of the red circle becomes visible, the test is failed.
+
+ This test verifies that error handling for the begin attribute is working.
+ An error in the begin-value-list means that the attribute as a whole is in error, and
+ that is the same as if the value was set to 'indefinite'.
+
+
+ There should be three green rects visible. If any of them turns red the test has failed.
+
+ The test is passed if you see a large swirly blue image, outlined in green. Below,
+ two smaller copies also outlined in green. Below that, a thick red outline that does
+ not have an image inside it. All three blue images with green outlines animate over
+ ten seconds, alternating between a blue and a pink image.
+ The animations all finish at the same time and display the pink image thereafter.
+
+
+ This tests the resolving of QNames in the attributeName attribute value. The
+ attribute tested is href, in the XLink namespace.
+
+
+ If an image is displayed on top of the red rectangle, or if the large image is not shown, or a
+ purple image with 'FAIL' is shown rather than blue, the implementation is using magic prefixes
+ and is only looking for the string 'xlink:href' rather than following the Namespaces in
+ XML specification.
+
+
+ If the right-most of the two small images animates but the left-most does not,
+ the implementation is only handling animation elements that are a direct child of
+ the element to be animated, and does not implement animation specified by an
+ XLink href. In that case, the large image will not animate either, but this does
+ not necessarily mean that namespace resolution is incorrect. (It does mean that
+ the test is failed, however).
+
+
+ If the two small images animate correctly but the large one does not, then
+ resolution of QNames in the 'attributeName' attribute is not following the
+ Namespaces in XML specification as required by the SVG specification.
+
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.
+
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.
+
+
+ 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.
+
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.
+
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.
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 red and stroked with blue appear, each with width=100 and height=200.
+ Starting at time 3 seconds and ending at time 6 seconds, the height of the leftmost rectangle decreases from 200
+ to 50. Starting at time 6 seconds and ending at time 9 seconds, the rightmost rectangle decreases from 200 to 50.
+ Annotations on the picture show the correct positions at particular times.
+
+ A yellow happy face should be displayed. The stroke for the smile and yellow circle are both animated, the stroke
+ goes from "#F1E900" to "#FF0000".
+
+ 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 red 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 is composited on top of the animated red
+ square. Then, when you click on "fade out", the red 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 compete. The picture should remain looking the same way indefinitely, until another link is
+ activated.
+
+
+ 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 red square goes from zero to 100% opacity. After the first click on "fade out",
+ the red square goes from 100% to zero opacity. After the second click on "fade in", however, the red square goes
+ from zero to 100% opacity, and then goes back from 100% to zero opacity. This is because of the hyperlinking rules
+ as they relate to resolved start times in the SMIL 2.1 specification.
+
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).
+
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, red, blue, yellow, cyan) in 5 positions (blue and yellow
+ share position) that should be displayed during the test.
+
Tests the animation to and from the degenerate cases of the basic shapes. The shapes are drawn within the black rectangles.
+
+ The rendered picture should match the reference image at the end of the animation, except for possible variations in the
+ labelling text (per CSS2 rules).
+
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 16.2.13 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.
+
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.
+
+ 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.
+
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.
+
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. The static reference image shows the final state of the animation.
+
The purpose of this test is to test animation of the viewBox attribute.
+
+ This file tests animation of the viewBow attribute. 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.
+
+ 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.
+
+ 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.
+
+
+ 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. In most tests, 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.
+
+
+ The following animations should show continuous changes: fill, stroke, stroke-width, stroke-miterlimit,
+ stroke-dashoffset and color. Note that visually, stroke-miterlimit shows a sharp transition, but that is because
+ the miter is cut off when the animated miter limit reaches the test sharp angle's miter value. The stroke-miterlimit
+ value is changed continously but that is not visible in this test.
+
+
The following animations have a discrete behavior: fill-rule, stroke-linecap, stroke-linejoin, display and visibility.
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.
+
+ 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.
+
+
Only the animation of font-size should show a continuous change of the font size.
+
The following animations have a discrete behavior: text-anchor, font-family, font-style, font-weight.
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 SMIL 2.1 are relevant as
+ confirmation of this test:
+
+
+
+
+
+ 10.4.1
+ subsection "Event values"
+ states: "If the Eventbase-element
+ term is missing, the event-base element defaults to the element on
+ which the eventbase timing is specified (the current element)."
+
+
+
+ 3.5.1
+ subsection "The target element"
+ says that the animation target may
+ be defined explicitly through the targetElement="" IDREF or href=""
+ URI, according to the host language. SVG Tiny 1.2 uses the
+ xlink:href="" attribute to specify the target element, so in this
+ test, the animation target is defined through xlink:href="" and the
+ event base per definition is then also this referenced element.
+
+ 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 red 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 "red 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 calcMode="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 red squares which are animated with
+ calcMode="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 red square (LR) is animated just as the LG square but
+ with calcMode="paced". The same applies to the right red square (RR)
+ that has default calcMode ("paced" for animateMotion) compared to the
+ RG square that has calcMode="linear".
+ The calcMode for the scale of RR (and RG) is not important since
+ it's not a value list type of animation.
+
+ 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.
+
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.
+
+ 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.
+
+ 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[.
+
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.
+
+ 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).
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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> animations are applied. The first <set>
+ element acts directly on 'Basic Shape' elements. 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 'Basic Shape' element. All
+ the <set> elements have a begin attribute set to 0s with an offset of 1s after the 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.
+
+ 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.
+
+ This test validates the operation of the animateTransform's additive behavior, as described in the SVG 1.1
+ specification (see http://www.w3.org/TR/SVG11/animate.html#AnimateTransformElement).
+
+
+ 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
+ roduce 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(1,1)
+ 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 concatenated 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, so is the result of previous animation iterations.
+ Consequently, the transform goes from "skewX(30) scale(1,1)" to "skewX(30) scale(2,2)" for the first iteration
+ and then from "skewX(30) scale(2,2) scale(1,1)" to "skewX(30) scale(2,2) scale(2,2)" for the second iteration.
+
+ 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). The total length along the sx component is 2 + 2 = 4. The total length along the sy component is
+ 0 + 1 = 1. At 0s, the expected transform is scale(1,2). At 1.5s, the expected transform is scale(3,1.5) so that a
+ length of 2 has been run on the sx component and a length of 0.5 has been run on the sy component. At 3s, the
+ expected transform is scale(3,2).
+
+
+ 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).
+
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).
+
Test animation of color keywords that resolve to animatable RGB values.
+
+ Five black squares are shown. After two seconds, all five squares should turn red and then smoothly animate the
+ fill color to green over the next five seconds.
+
All four rectangles at the top must smoothly animate from black to green over 5 seconds.
+
+ During this time the bottom two rectangles must be red. Then, the bottom two rectangles must smoothly animate
+ from green( at five seconds), through khaki (at 7.5 seconds), to yellow (at 10 seconds and above). Colored
+ circles indicate the appropriate colors at these times.
+
+ This test tests fill="freeze" for the case where the duration has been constrained by an 'end' attribute
+ and calcMode="discrete".
+
+
+ The correct behaviour is defined by the SMIL time interval model.
+ Time intervals created by the test case from implicit begin, dur and calcMode discrete:
+
+
+
+ [0;2s) This means time including 0 seconds until (but not including) time 2 seconds
+
+
+ [2s;4s) Time including time 2 seconds until (but not including) time 4 seconds
+
+
+
+ Time intervals created by implicit begin and end:
+
+
+
[0;2s)
+
+
+ Therefore the frozen value will be 74, resulting in the purple fill
+ being in the right rectangle after 0 seconds.
+
+
+ The test has passed if the purple fill is on the right rect only after 0 seconds.
+ Fill must never be set to purple on the left rect, except for before the animation has begun.
+
+ 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.
+
+
+ The second subtest generates a new prefix string, and makes sure it's not equal to the first prefix string.
+ Then an svg fragment is generated as a string, to be parsed by a call to the parseXML method.
+ The 'xlink' prefix is bound to the "http://example.net/bar" namespace, and the generated prefix is bound to the XLink namespace.
+ Similar to the first subtest, the image has two references but only one attribute is actually in the XLink namespace.
+ The fragment is parsed and the result is inserted into the document, which should make the 'image' element visible.
+ If an exception is thrown during the parsing or the insertion of the result output will be shown in the status part of the testcase.
+
+
+ The testcase has passed if after the script execution has taken place these conditions are met:
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ The test will pass if, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+ The reference image displays the file after performing a user agent zoom.
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ An animation is applied to the viewBox attribute.
+ The test will pass if the circles are affected by the viewBox animation and, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ An animation is applied to the content group.
+ The test will pass if only the first circle is affected by the group animation and, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+
+ Animates a rect that has transform="ref" and tests that the animateMotion transform is supplemental.
+ The rects should follow a path diagonally from top-left to bottom-right.
+ The test is passed if a single green rectangle is visible across the screen if a red rectangle is seen
+ the test is failed.
+
Tests the default initial coordinate system used by renderer. Should be 0,0 if not specified.This is illustrated by comparing red boxes that are missing a coordinate or all coordinates with yellow boxes that have the correct coordinates specified. This test should produce three red boxes, with small yellow boxes rendered on top of them. These boxes should be placed along the origin, and x and y axis.
+ This test verifies the implementation of the viewBox and the preserveAspectRatio attribute on the animation element.
+ It exercises the various preserveAspectRatio values and uses a general entity definition in order to make reading of the SVG source easier.
+
+
+ For the test to pass the following criteria should be met:
+
+
+
the xMin* test image left edge should be on the left edge of the blue viewport rect
+
the xMid* test image should be centered in the blue viewport rect
+
the xMax* test image right edge should be on the right edge of the blue viewport rect
+
the yMin* test image top edge should be on the top edge of the blue viewport rect
+
the yMid* test image should be centered in the blue viewport rect
+
the yMax* test image bottom edge should be on the bottom edge of the blue viewport rect
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ The test uses the rect element, the fill color (solid primary colors) and transforms.
+
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ 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.
+
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ This test will check if the various matrix operations work
+
+ Verify the conversion processing of percentage and fraction values relative to object bounding boxes.
+ This is used when defining linear and radial gradients.
+
+
+ The test validates conversion for coordinates, width, height and length. The first test defines two
+ corresponding linear gradients, which specify coordinates using fractions for the first and user
+ coordinates for the second. The second test defines two corresponding radial gradients, which specify
+ a length (radius) using fractions for the first and user space for the second.
+
+
+ The rendered image should match the reference image.
+
+
+ The test also assumes that linear and radial gradients are implemented.
+
+ 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.
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.
+
+
+ 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.
+
This tests the behaviour of CSS font matching based on font-variant attribute.
+
The first line of text should be 'square' 'triangle'. The small-caps font should match the second text element.
+
The second line of text should be 'square' 'triangle'. The second line is used to ensure that the order of font specification does not effect the selection of these fonts.
+
The third line of text should be 'square', 'diamond', 'square', 'diamond'. This shows 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 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 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.
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. An implementation that passes this test should completely fill the cutout, leaving a solid black area (some slight antialiasing effects may remain).
+
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).
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.
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 adavance of 1000. Glyphs have no advance so the 1000 default should be used.
+
The second row shows a layout with a default adavance of 2000. Glyphs have no advance so the 2000 default should be used.
+
The last row shows a layout with a default adavance of 0. Glyphs have a specified advance so the 0 default should be ignored.
+
Reference blue markers show the expected glyph positions.
The first subtest tests the arabic-form attribute and should 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 is the same, but with glyphs for the letter khah. It should match the reference image.
+ 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.
+
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.
+ Test that ligatures are always used, and only used, when they occur before the
+ glyphs for characters they are ligatures of. The word "fjord" is displayed twice;
+ the top one must use the fj ligature and the bottom one must not; the top of the letter f overlaps the
+ dot of the letter i..
+
+
+ Two fonts are defined, almost identical; in one the fj ligature is the
+ first glyph defined, in the second one it is the last glyph.
+
+ Test that ligatures are always used, and only used, when they occur before the
+ glyphs for characters they are ligatures of. The word "fjord" is displayed twice;
+ the lower one must use the fj ligature and the upper one must not; the top of the letter f overlaps the
+ dot of the letter j..
+
+
+ Two fonts are defined, almost identical; in one the fj ligature is
+ defined after "f" but before "j"; in the second one it is the last glyph.
+ This tests longest-substring matching.
+
+ Test that all of the SVG path commands are accepted for defining glyphs. The upper,
+ black text must be a reflection of the lower, colored glyph shapes.
+
+
+ The letter A uses L commands, the letter H uses H and V commands, and
+ the letter B uses cubic beziers. The letter C uses a mix of quadratic beziers and vertical lines.
+
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".
+ This tests a range of values for the 'units per em' attribute. The
+ test is passed if the three letter β are all the same size.
+
+
+ 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.
+
+ 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 in changed to pink,
+ 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.
+
+
+ After clicking at least once on the button, the rendered image should be
+ exactly as the reference image, except for differences in text display.
+
+
This test requires that the user agent support scripting.
+ Testing event bubbling through 'use' elemnt.
+ Moving the mouse over the red 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 red/green rect should hide the rect underneath it again.
+
+ This test contains four cases. The cases must produce the following results for the test to pass.
+ Case 1: On a mouseover event on the top square, all four squares must turn blue.
+ Case 2: On a mouseover event on the top middle square, all four squares must turn blue and a black stroke
+ must appear on the referencing square (element).
+ Case 3: On a mouseover event on the bottom middle square, all four squares must turn blue and a black
+ stroke must appear on the referencing square (element).
+ Case 4: On a mouseover event on the bottom square, all four squares must turn blue, and on a mousedown event
+ a black stroke must appear on the referencing square (element).
+
+
+ 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.
+
Two rectangles and a text element are targets of animateColor elements which begin on focusin and end on focusout.
+
The top-level SVG has a nav-next attribute referencing the text element.
+
When loading the file, initial focus will go to the text element, which should be red.
+
Moving to the next focus will turn the text black while making the blue rectangle green.
+
Moving to the next focus will return the rectangle to blue and make the red rectangle green.
+
Moving to the next focus will return the rectangle to red and turn the text red.
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+ User agent dependent behavior is accepted with all focus tests. Focus can be given immediately to first element in the focus ring,
+ or held in the UA until focus is requested - then focus is given to the first element.
+
Testing the focusable property : its default value and animatability on text and anchor elements.
+
The 1st text is the target of animateColor which starts on focusin, and also has the focusable attribute set to false.
+
The 2nd text does not have a focusable attribute and is not the target of animations which start by focus events.
+
The 3rd text is the target of animateColor which starts on focusin.
+
The 4th text is the target of animateColor which starts on activate.
+
The 5th text is the child of an a element.
+
The 6th text is the child of an a element and also has the focusable attribute set to false.
+
The 7th text has the editable attribute set to simple.
+
The 8th text is the observer DOMFocusIn and DOMFocusOut handlers.
+
The 9th and 10th text elements are used to modify the focusable attribute of the 11th element.
+
+ The 11th text is the target of animateColor which starts on focusin, and also has the focusable attribute set to false.
+ The focusable attribute is modified by activate events on the 9th and 10th elements.
+
+
The 12th and 13th text elements are used to modify the focusable attribute of the 14th element.
+
+ The 14th text is the child of an a element - the a element also has the focusable attribute set to false.
+ The focusable attribute is modified by activate events on the 12th and 13th elements.
+
+
+
The focus ring will look like the following: 3, 4, 5, 7, 8, 9, 10, 12 and 13.
+
Activating the 9th text element will make the 11th element focusable.
+
Activating the 12th text element will make the 14th element focusable.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+ User interaction should navigate focus starting at 1 and go through 5.
+ This test applies only to user agents which locate to focus which is outside of the viewport, and
+ thus the pass criteria for this test is optional.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
This test tests initial focus within the svg document
+
+ The root SVG element has 'focusable' set to 'true'.
+ At start up an animation set element is used to change the poem
+ to red if the root element SVG has focus.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+ Each tspan has an animation that sets the fill to green upon receiving
+ focus. The focus should be moved in turn to "Old", "pond", "frogs",
+ "jumped", "in", "sound", "of" and then "water".
+
+
+ For the test to pass:
+
+
+
+ "Old", "pond", and "sound", "of" and "water" must each turn green
+ respectively when given focus.
+
+
+ "frogs" and "in" must both turn green at the same time when each is
+ given focus.
+
+
+ "jumped" must turn green when given focus and in addition "frogs" and
+ "in" must turn green at the same time due to focus bubbling.
+
+
+
+ In the 2nd phrase there are two nested tspan elements: "jumped" is in
+ the inner tspan, so focus should be received by the outer two words
+ "frogs", "in" and then by the word "jumped".
+
+
+ Focus navigation is user agent dependant but typically is navigated
+ with the keyboard keys.
+
+
+ TAB or arrow keys move the focus while the ENTER key activates the
+ focused element.
+
+ Each tspan has an animation that sets the fill to green upon receiving
+ focus. The focus should be moved in turn to "A", "lonely", "pond", "in",
+ "age-old", "stillness", "sleeps", "Apart,"
+ "unstirred by sound or motion", "... till", "Suddenly",
+ "into", "it", "a", "lithe", "frog" and then "leaps".
+
+
+ For the test to pass:
+
+
+
+ "A", "lonely", "pond", "in", "age-old", "stillness", "sleeps",
+ "Suddenly", "into", "it", "a", "lithe", "frog" and "leaps" must each
+ turn green respectively when given focus.
+
+
+ "Apart" and "... till" must both turn green at the same time when
+ each is given focus.
+
+
+ "unstirred by sound or motion" must turn green when given focus and
+ in addition "Apart" and "... till" must turn green at the same time
+ due to focus bubbling.
+
+
+
+ In the 2nd line there are two nested tspan elements - "unstirred by
+ sound or motion" is in the inner tspan, so focus should be received
+ first by the outer two words "Apart", "till" and then by the inner
+ phrase.
+
+
+ Focus navigation is user agent dependant but typically is navigated with
+ the keyboard keys.
+
+
+ TAB or arrow keys move the focus while the ENTER key activates the
+ focused element.
+
+ The first four occurrences of "focus next" will highlight all four top rects.
+ All four bottom rects should be able to receive the focus and be red when they have focus.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+ Test on focus with a use-element. Focus should move first to the "g" element and then to its children.
+ When it gets to the use-element focus is first set on the use (right column) and then its children.
+
+ 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 that the user agent support scripting.
+ 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. The supplemental
+ text next to the circles describes what should occur.
+
+
This test requires that the user agent support scripting.
+ 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. The supplemental
+ text below the text strings describes what should occur.
+
+
This test requires that the user agent support scripting.
+ 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 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: 1. all the 'O':s in the green rects have green
+ fill 2. there are no red 'O':s visible 3. there are 9 green 'O':s in the first and second rect, 4 in the third rect
+ and 6 in the fourth rect
+
Tests the pointer-events attribute with different 'visible' values
+
+ The test is passed if the following conditions are met:
+ - In the first row of squares, the fill and stroke of squares 1 and 3 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the second row of squares, the fill and stroke of squares 1 and 3 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the third row of squares, the fill only of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fourth row of squares, the stroke only of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fifth row of squares, the fill and stroke of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+
+
+ 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.
+
Tests the pointer-events attribute with different painting values
+
+ The test is passed if the following conditions are met:
+ - In the first row of squares, the fill and stroke of squares 1, 3 and 4 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the second row of squares, the fill only of all squares must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the third row of squares, the stroke only of all must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fourth row of squares, the fill and stroke of all squares must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fifth row of squares, nothing is to trigger on mouseover.
+
+
+ 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.
+
Tests when text is considered hit by pointer-events.
+
+ The test is passed if the following conditions are met:
+ - Any single character in either of the lines of text has 'mouseover' event and the fill of the
+ characters' assocated line of text is set to green.
+ - The fill of the characters' assocated text is set back to black on a 'mouseout' event.
+
+
+ The dy of the glyphs vary quite a bit, so it's easy to tell if an implementation uses the text
+ boundingbox for 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'.
+
+ Verify correct handling by Dynamic (interactive) viewers for the "zoomAndPan" attribute on the 'svg' element. This
+ is the first 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..
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ 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..
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ 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.
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ Test That UTF-16 is supported, as required by the XML specification. If the implementation
+ treats this file as UTF-8 then every second character will be treated as 0. This
+ will typically mean that the file will not load, since the XML elements and attributes
+ will not be reconginized.
+
+ This verifies the capability to handle links into SVG content, using the svgView fragment identifier form.
+ The test is passed if traversing this link shows a portion of the target
+ translated so that the green circle with id "circle-2" is in the top left corner of the viewer
+ frame.
+
+
The initial view of this test contains one green arrow plus labelling text. The arrow is a link - follow the link.
+
+ The arrow links to ./images/linkingCircle-f.svg#svgView(transform(translate(64,227)))".
+
+ 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'. Both must be working links.
+
+ Verify target attribute has priority over xlink attribute on the 'a' element. The destination expressed by
+ "xlink:href=" is overridden when 'target' is specified on the 'a' element.
+
+
+ For the test to pass; each arrow in the test, when clicked, must show the image of the
+ linkingToc-t.svg in a new frame.
+
+
+ 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.
+
+
+ This test was modified and renamed from linking-a-07-t.svg.
+
+ Testing Links to external and internal 'svgView' with Transforms.
+
+
+ The first part of the test is passed if the rect links on the top line go to the linking-frag-202-t.svg file and
+ adjust the resulting view according to their respective text;
+ - The rect with 'Rotate' must link to the linking-frag-202-t.svg file and rotate resulting view
+ - The rect with 'Shift' must link to the linking-frag-202-t.svg file and shitf the resulting view
+ - The rect with 'Scale' must link to the linking-frag-202-t.svg file and scale the resulting view
+ - The rect with 'skewX' must link to the linking-frag-202-t.svg file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to the linking-frag-202-t.svg file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to the linking-frag-202-t.svg file and restore the view to an identity transformation.
+
+
+ The second part of the test is passed if the rect links on the bottom line link to this file and adjust the
+ resulting view according to their respective text;
+ - The rect with 'Rotate' must link to this file and rotate resulting view
+ - The rect with 'Shift' must link to this file and shitf the resulting view
+ - The rect with 'Scale' must link to this file and scale the resulting view
+ - The rect with 'skewX' must link to this file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to this file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to this file and restore the view to an identity transformation.
+
+ Testing Links to external and internal 'svgView' with Transforms.
+
+
+ The first part of the test is passed if the rect links on the top line go to the linking-frag-202-t.svg file and
+ adjust the resulting view according to their respective text;
+ - The rect with 'Rotate' must link to the linking-frag-201-t.svg file and rotate resulting view
+ - The rect with 'Shift' must link to the linking-frag-201-t.svg file and shitf the resulting view
+ - The rect with 'Scale' must link to the linking-frag-201-t.svg file and scale the resulting view
+ - The rect with 'skewX' must link to the linking-frag-201-t.svg file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to the linking-frag-201-t.svg file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to the linking-frag-201-t.svg file and restore the view to an identity transformation.
+
+
+ The second part of the test is passed if the rect links on the bottom line link to this file and adjust the
+ resulting view according to their respective text;
+ - The rect with 'Rotate' must link to this file and rotate resulting view
+ - The rect with 'Shift' must link to this file and shitf the resulting view
+ - The rect with 'Scale' must link to this file and scale the resulting view
+ - The rect with 'skewX' must link to this file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to this file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to this file and restore the view to an identity transformation.
+
+ Activating the link on the red circle should pan the viewport to
+ center the orange circle (which is initially located outside the viewport).
+
+
+ Activating the link on the orange circle should pan the viewport to
+ center the yellow circle, and zoom out to show the entire yellow circle.
+
+
+ Activating the link on the yellow circle should pan the viewport to center
+ the red circle, but remain at the existing zoom level (i.e. not zoom in).
+
+
+ Note that the visual effect is only part of the pass criteria, and that the
+ changes in the viewport should be made using currentTranslate and currentScale,
+ not the viewBox; this part is currently not tested.
+
+ Tests various external fragments with 'use' element:
+ fill, stroke, text, group, multiple levels, name clash and circular references
+
+
+ SVG fragments defined in an external file are invoked with the 'use' element.
+ The test is passed if the following objects are rendered:
+ - Right top; square with a horizontal gradient fill from orange to yellow, diagonal gradient stroke from blue to pink
+ - Right middle top; square with a diagonal gradient fill from blue to pink, horizontal gradient stroke from orange to yellow
+ - Right middle bottom; the letters ABC in an SVG font
+ - Right bottom; the English alphabet a to j in the shape of a square
+ - Left Top; square with horizontal gradient fill from orange to yellow, and 3 circles all with a blue to red gradient fill
+ running diagonally inside the square
+ - Left middle top; green square with a yellow circle in the middle
+ - Left middle bottom; red square
+ - Left bottom; two identical squares with light blue fill.
+
+ Tests SVG fragments defined in an external file are invoked with the 'use' element.
+ The test is passed if the following objects are rendered:
+ - Right top; square with red fill and blue stroke
+ - Right middle; square with black fill
+ - Right bottom; the letters 'A' in blue, 'B' in red, 'C' in blue
+ - Left top; square with red fill and a circle in the middle with a blue fill
+ - Left middle; square with green fill
+ - Left bottom; square with green transparent fill with an overlapping circle with a blue transparent fill.
+
+ Tests a 'use' element referencing an 'image' element and an 'a' element with xml:base.
+
+
+ The test is passed if two identical images are displayed.
+
+
+ The image on the right is located in the images directory (../images/) while the
+ image on the left is located in image2 directory (../images/image2). The image on
+ the right is specified in the svglib3.svg file using an 'image' element. The image
+ on the left is specified in the svglib3.svg using an 'a' element. The 'a' element
+ contains a group around it that specifies the image2 directory using 'xml:base'.
+
+ Tests that values for the xlink role and arcrole attributes are stored in the DOM.
+ The test is passed if the raster image and the vector image both have dark
+ green and light green borders, same as the reference image.
+
+
+ The values for role and arcrole are based on the RDDL specifications of
+ well known link natures (role) and well known link purposes (arcrole). Roles uses the namespace URI (for XML content types) or the canonical IANA URI of the media type registration (for non-XML content).
+
+
+ A uDOM script reads the values of the xlink role and arcrole attributes,
+ checks that they are the correct values, and sets the fill colour of some rectangles
+ from shades of red (meaning incorrect) to shades of green (meaning correct).
+
+ 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.
+
+
+ There is a link on the triangle, pointing to an external SVG file, which is in the images directory (../images/).
+ The target file contains SVG 'text' elements which comprise a TOC and brief description of all of the SVG Tiny 1.2
+ 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 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. The results of executing the link
+ should be identical to executing the first (topmost) link of linking-uri-01-t.
+
+
+ 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.
+
Testing 'audio' Element with the 'audio-level' Attribute
+
+ The scale at the bottom of the slide uses a 'set' element to modify the 'audio-level' on the sample audio element.
+ The 'audio' element can be triggered by activating the current focus.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Test on audio level animation. audio-level is animated to many values between 0 and 1. The volume dial graphic animates to show the expected relative volume.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
+ Test on audio-level inheritance in several child elements. audio-level on the first element is 0.5. audio-level on the second sound is halved to 0.25. audio-level on the third and fourth sounds are halved agian to 0.125 and 0.0625 respectively.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
This test validates the Animation element with external references.
+
There are five references. Each one is a separate file.
+
The time scale loops from 0 to 10 seconds - the vertical red line pans from left to right.
+
In the first example the two rectangles are set to rotate 90 degrees alternatively.
+
In the second case the circle has focus. Since this is the only item that has focus it can not loose focus and should remain red even when an attempt is made to change focus.
+
The third example has a circle that is set to change to red on a mouseover event. On mouseout the circle should change back to grey.
+
The forth example invokes the same external file twice - two squares with a gradiant should be rotating in sync continously.
+
The last case calls an animation that should display a blue square with five gradiant circles all rotating continously.
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+ This is one of a series of test slides that exercise all the permitted values for the 'preserveAspectRatio'
+ attribute values.
+
+
+ The external resource referenced by the animation element has a viewport-fill defined with a solid color.
+ This should be ignored and the local color of blue should be used.
+
+
A semi-transparent yellow rectangle should be animating within each viewport.
This slide tests the 'viewport-fill' and 'viewport-fill-opacity' attributes defined locally.
+
+ The externally resource referenced by the animation element has a 'viewport-fill' defined with a black to yellow gradient.
+ This should be ignored and the local definitions should be used - red for the left, blue for the middle and semi-transparent black for the right.
+
+
A semi-transparent yellow rectangle should be animating within each viewport.
This slide applies different transformations to the animation element.
+
+ The externally resource referenced by the animation element has a viewport-fill defined with a black to yellow gradient.
+ This should be ignored and over ridden by the color aqua.
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+ This slide tests independent primary documents. Each referenced primary document has a separate script context.
+ This test is only applicable if application/ecmascript is available.
+
+
Four animation elements reference a document which has an activate handler on a circle.
+
Focus should start on the top-left circle and move to top-right, bottom-left and bottom-right.
+
Activating the circle will toggle its radius size, but for the currently focused circle only.
+
This is due to the fact that each primary document has a separate script context.
+ Animation Element with animating xlink:href
+ This slide tests animating the xlink:href attribute of animation elements
+ Every 2.5 seconds the animation will display a circle instead of a timeline.
+ The circle is focusable and as such should receive the focus and turn red.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
+ Tests the audio-level property for nested audio elements and clamping
+ of audio-level.
+
+
+ The test consists of 6 subtests. When each audio sub-test is executed a
+ corresponding rect will turn blue. When each audio sub-test is
+ finished the corresponding rect will turn gray again. For this test to pass, all subtests must
+ have a green rectangle next to them.
+
+ The audio must also be heard to pass this test. If the user agent does not support the WAV media format, the test is still a pass.
+
+
+ The 1st subtest has an audio-level = 1. To pass this subtest the audio
+ must be played at the system volume.
+
+
+ The 2nd subtest has an audio-level = 2. To pass this subtest the audio
+ must be played at the system volume.
+
+
+ The 3rd subtest has an audio element with an audio-level = 2. Within
+ the audio element there is a child audio element with an
+ audio-level = 0.5. The source audio is the child audio element. To pass
+ this subtest the audio must be played at 1/2 the system volume.
+
+
+ The 4th subtest has an audio element with an audio-level = 0.5. Within
+ the audio element there is a child audio element with an
+ audio-level = 2. The source audio is the child audio element. To pass
+ this subtest the audio must be played at 1/2 the system volume.
+
+
+ The 5th subtest has three audio elements. The first audio element has
+ an audio-level = 0.5 and is the parent audio element. The second audio
+ element has an audio-level = 2 and is a child to the first audio
+ element. The third audio element has an audio-level = 0.5 and is a
+ child to the second audio element. The source audio is third audio
+ element. To pass this subtest the audio must be played at 1/4 the
+ system volume.
+
+
+ The 6th subtest has four audio elements. The first audio element has
+ an audio-level = to the audio level of the 3rd audio element (0.5). The
+ second audio element references an audio element from another subtest
+ with an audio-level of 2. The second audio element is a child of the
+ first audio element. The third audio element has an audio-level = 0.5
+ and is a child of the second audio element. The fourth audio element
+ has an audio-level of 2 and is a child of the third audio element. The
+ source audio is the fourth audio element. To pass this subtest the
+ audio must be played at 1/4 the system volume.
+
+ This file tests the transformBehavior attribute set to 'pinned'.
+ The video should always overlap the two crossing lines, even during zoom/pan, proving it
+ is always rendered at its native resolution, and pinned at its the center (the blue dot).
+ If the video is rendered inside the small rotated rectangle, it means the transformBehavior
+ attribute is not applied / supported.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'none' on a video element. The width of
+ the video element has been made larger than the subsequent
+ preserveAspectRatio tets.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMin meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMidYMid meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMaxYMax meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMin meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMid meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMax meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'none' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Colored circles should maintain rendering order as marked on them.
+ Video is 10 seconds in length and should freeze at the end. The circles should continue to animate indefinitely
+ Bottom frame contains a jpeg reference image. The jpeg image is rendering order is on the top and the video
+ rendering order is on the bottom.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the case when type is set to 'rotate' in animateTransform. The test
+ contains two objects; one video and one image. Both are rotated about a
+ point definied by the center of the black circle. The video will rotate
+ clockwise, and the image will rotate anti-clockwise.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the rendering order of Video with other objects. Test contains
+ a video element with a polygon rendered over the top. The polygon has
+ a solid fill; no video should be visible through the polygon.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing and xlink href is changed the stream should change. The
+ new stream should start playing at the same position as the reference video, if the media play time cannot be controlled. Otherwise the media time will be re-started.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the different transformBehavior values on video.
+ Pinned, Pinned90, Pinned180, Pinned270
+
+
+ The 1st video element has transformBehavior set to pinned and is displayed in the top-left of a 4-video box.
+
+
+ The 2nd video element has transformBehavior set to pinned90 and is displayed in the top-right of a 4-video box.
+
+
+ The 3rd video element has transformBehavior set to pinned180 and is displayed in the bottom-left of a 4-video box.
+
+
+ The 4th video element has transformBehavior set to pinned270 and is displayed in the bottom-right of a 4-video box.
+
+
+ There are 4 green-stroked rectangles indicating the expected position and orientation, but not size.
+
+
+ The videos should display with the appropriate rotation, centered on the green rectangles but not bound by them in any way, since determining the exact pixel size of the rectangles is not possible.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ When no video element is displayable (visibility is hidden or display is none of the use element),
+ audio level should be set to 0 and video should not be rendered.
+ -Video1 should be displayed between 0-4s, not rendered between 4-6 s and displayed between 6-8s.
+ -Video2 should be displayed between 0-2s, not rendered between 2-6 s and displayed between 6-8s.
+ -The audio of the video should be muted between 4-6s as no video is then rendered.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing and it is repositioned by removing it's corresponding use
+ from tree and then reinserting it in tree the video should continue playing but change position
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing when it is removed from document tree
+ it should continue playing when re-inserted in tree.
+ - The video should change position at 2 seconds but continue playing.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ When xlink:href is animated on a use element between two different video elements, the
+ displayed video should change and it should play at the current time.
+ -video1 should be displayed between 0-2 and 4-6s and video2 between 2-4s.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
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 DTD, but is well formed.
+
The diagram on the table is a visualization of the RDF metadata in the graphic.
+
The rendered result should match the reference image and there should be no error messages or warnings
+ The purpose of this test is to determine if an application has the basic capability to process the 'color' property.
+ There are three subtests.
+
+
+ The first subtest, to the top left, is passed if the circle has a red fill. The second subtest, to the top right, is
+ passed if the circle has a red stroke. The third subtest shows a rectangle with a gradient fill, which has three stops.
+ The subtest is passed if central stop is red, fading off to blue to the left and pale yellow to the right.
+
+ Purpose of test is to determine 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 shapes in the group uses
+ one of the syntactical forms and all in the group should be identical in color.
+
+
+ The first row uses five forms - 3-digit hex, 6-digit hex, rbg() integer form, rgb() percentage form, and named
+ ('HTML') 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.
+
+ Tests system colors. 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. The user agent should render the rectangle with a RED fill.
+ This tests inheritance of three properties: "fill", "stroke" and "stroke-width". There is a "g" element (id="G1")
+ which sets fill="blue", stroke="red", 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="red" 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="red"
+ and stroke-width="5".
+
+
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.
+
+ 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.
+
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, red.
+ 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.
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling
+ text (per 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, red. 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
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
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 red (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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
Test that the viewer has basic capability to handle linear gradients on fills and stroke of 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 red (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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ Test that the viewer can handle the gradientUnits attribute on linear gradients. It tests the following values of
+ gradientUnits : default (objectBoundingBox), specifying objectBoundingBox, and specifying 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 (red). 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 red (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 red (left) to blue
+ (right).
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
+ 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 (red). 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 red (center) to blue (edge).
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
+ Test linear and radial gradient defaults. Includes testing defaults for linear grad x1,y1,y2 = 0.0, x2 = 1.0 and
+ testing defaults for radial grad cx,cy,r = 0.5
+
+
+ The top rectangle must be blue at the lefthand side and red at the right hand side, fading smoothly accross. The
+ lower rectangle must be red 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.
+
+
+ The top rectangle must have a red outline and no fill. The middle rectangle must have a solid black fill. The
+ lower rectangle must have a yellow to red 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.12.
+
+
+ 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. The result should be that the top-left rectangle is filled with a gradient from green to red since the stop-color is inherited from the location of the gradient definition.
+
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. The result should be that the top-right rectangle filled in green with a gradient 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. The result should be that the lower-left rectangle filled with a gradient going from fully-opaque green to fully-opaque black.
+
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 that the lower-right rectangle filled with a gradient going from fully-opaque green to fully-opaque yellow.
+ This test shows rectangles filled with animated gradient which inherits some of their properties: stop-color, stop-opacity.
+ The correct result must show: - the top-left rectangle filled initially with a linear green-to-red gradient and turning into
+ a solid green color after 5s. - the top-right rectangle filled initially with a green gradient fully opaque on the left and
+ half transparent on the right, but after 5s the rectangle must be filled with a fully opaque solid green. - the bottom-left
+ rectangle filled with a static green-to-black opaque gradient - the bottom-right rectangle initially filled with a green-to-yellow
+ fully-opaque gradient animated and turning into a fully-opaque green solid color. Animations numbered a4 to a7 must have no impact.
+
+ A linearGradient is defined with a stop-opacity of 0 that is also animated from 0 to 1 (clear to solid).
+ The yellow star must initially be visible through the gradient. After 5 seconds most of the start must
+ be covered by the linearGradient.
+
+ There are three lines of text. For this test to pass each line of text must have the same gradient
+ from green to blue all set to a 'stop-opacity' of 0.4 . The reference rect at the bottom has a
+ similar gradient but with 'stop-opacity set to 1. The text of the poem should be lighter than
+ the reference line.
+
+ Test on gradients with gradientUnits set. There are two rects, one using a gradient with gradientUnits set to "objectBoundingBox" and one with "userSpaceOnUse". Both rects contain a smaller rect to visualise the use of gradientUnits.
+ In the top rect, the small one should appear as a smaller version of the big rect.
+ In the bottom rect, the small one should just as a "frame" on the big rect.
+
+ Gradient with no stop-elements. The painting shall occur as if 'none' were specified
+ as the paint style, thus allowing the pale blue rectangle to be seen inside the square.
+
Testing non-scaling-stroke on basic shapes and text.
+
The bottom shapes - triangle and oval - also have a gradient applied to the outline stroke.
+
+ At the start the two sets of shapes may not appear identical - depending on viewport size.
+ As the geometric shapes are zoomed out the outline strokes of the left-hand set of shapes
+ should remain fixed while the strokes of the right-hand set should scale in proportion to the shapes.
+
+ Test solidColor animation. Animates solid-color and solid-opacity on two rects.
+
+
+ The test is passed if the following objects are displayed:
+ Rect 1
+ - Fill: blue animated to red, opacity 0 animated to 1
+ - Stroke: none
+
+ Rect 2 (roated -30 degrees)
+ - Fill: none
+ - Stroke: red animated to yellow, opacity 1 animated to 0
+
+
+ One rect animates its fill from blue to red over 3 seconds and has its solid-opacity animated from 0 to 1 over 5 seconds.
+ The other rect (no fill and rotated -30) has its stroke animated from red to yellow over 3s and solid-opacity from 1 to 0 over 5 seconds.
+
+ 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 red stroke.
+
+
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", stroke="red",
+ "font-family" (Arial) and "font-size" attributes.
+
+ Verify the basic capability to handle the stroke properties ("stroke", "stroke-width", "stroke-linejoin") in
+ combination with the "rect" element. The pair should be rendered as two red rectangles without an interior fill.
+ The upper rectangle should have a stroke width of 5 with sharp corners. The lower rectangle should have a stroke
+ width of 5 with round corners.
+
+
+ The test uses the "rect" element, as well as basic "fill" (solid primary colors), "stroke", stroke="red"
+ stroke-width="10" stroke-linejoin="round", "font-family" (Arial) and "font-size" properties.
+
+ Verify the basic capability to handle the stroke properties ("stroke", "stroke-width" "stroke-linejoin", "stroke-linecap",
+ "stroke-miter") in combination with straight-line path commands. The pair should be rendered as as two red line segments.
+ The upper segment should have round end caps. The lower segment should be chopped off where the two line segments meet.
+
+
+ The test uses the "path" element, as well as basic "fill" (solid primary colors), "stroke", "stroke-width",
+ "stroke-linejoin", "stroke-linecap", "stroke-miter", "font-family" (Arial) and "font-size" properties.
+
+ Verify the "stroke-dasharray" and "stroke-dashoffset" properties. Two lines are drawn, one red 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 help show this, the black line has a "stroke-dashoffset" so that the dashes in the black
+ line match up with the gaps in the red line.
+
+
+ The test uses the "path" element, "stroke", "stroke-width", "stroke-dasharray" and "stroke-dashoffset", "font-family"
+ (Arial) and "font-size" properties.
+
+ User agents may render graphical primitives with different levels of accurancy.
+ This test is aimed at determining how does a UA render thin strokes.
+
+
+ The test file contains a number of vertical and horizontal lines.
+ The stroke width of the vertical lines are increasing from left to right.
+ The stroke width of the horizontal lines are increasing from top to bottom.
+ The user should be able to see a smooth stroke width increment for the vertical and horizontal lines.
+
+ 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 red 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. Thus, 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.
+
+ Stroking for circle, large stroke-width, small r.
+
+
+ The main indication for a failed test is the appearence of something red.
+ A second indication is a thin white line inside a blue area.
+
+
+ For smaller circles the radius gets smaller than the half stroke-width, therefore the fill is not
+ visible anymore for them. Only the animated circle at the beginning and the next circle
+ on its right have a visible fill.
+
+
+ To test the correct rendering, the blue circles cover always red filled circles without a stroke.
+ Additionally the size of the circles is given with a thin white stroke on top. If something
+ red gets visible or blue parts of the stroke of the circle are outside of the related white
+ stroked circle, an error is occured. If the circles are not displayed as circles with an accuracy of
+ one device pixel, an error is occured too.
+
+ Direction of stroke-dasharray and stroke-dashoffset for basic shapes.
+
+
+ The main indication for a failed test is the appearence of a blue path on
+ a white background area. It is passed, if all blue paths are on a gray background area.
+
+
+ stroke-dasharray and stroke-dashoffset are tested on basic shapes circle, ellipse, rectangle,
+ rectangle with rounded corners, line, polyline and polygon. The test is sensitive to the
+ direction of stroke-dasharray and stroke-dashoffset and on the starting point on the basic
+ shape.
+
+
+ The dashes are positioned correctly, if they are only on a gray background area.
+ If there are dashes on a white background, this is an indication for an error.
+ Additional information given in the elements title and desc for the related subtest
+ may help to identify the tested shape and property combination and the error,
+ if there is one.
+
+ The main indication for a failed test is the appearence of something red.
+
+
+ stroke-linejoin is tested, using a comparsion with filled or stroked paths or shapes with the same appearance.
+ This is tested for different three miter angles for the values round, miter and bevel, for each of them one with
+ test path on top of the comparsion shapes and one with the path below.
+
+ The four paths top right test the inheritance either for the value explicitely set to 'inherit' or a missing stroke-linejoin property.
+
+
+
+ The top is always blue. If something
+ red gets visible, an error is occured.
+
+ Stroking for subpaths with path length zero, depending on stroke-linecap.
+
+
+ The main indication for a failed test is the appearence of something red
+ (this simple indication may fail itself, if the viewer does not support stroke-linecap).
+
+
+ Several paths containing a subpath with length zero are
+ stroked and some of them animated.
+
+
+ The zero length subpath is placed between two
+ other subpaths of finite length or before or after a
+ subpath of finite length or in one case the path consists of two
+ subpaths of length zero.
+ The behaviour is checked for stroke-linecap round,
+ square (subpath visible) and bevel (subpath not visible)
+ on the left.
+
+
+ On the right the behaviour is tested with simple
+ animations to check the correct alignment
+ or shrinking to zero length.
+ stroke-linecap is animated between round or square too
+ for some of them.
+
+
+ The behaviour is compared with similar paths with a
+ subpath of a very small length. Because the red stroked
+ paths have a slightly smaller stroke, they are always covered
+ by blue paths.
+ If something red gets visible, an error is occured.
+
+ Centering of stroke on the outline of rectangles.
+
+
+ The main indication for a failed test is the appearence of something red.
+
+
+ The width and position of the stroke centered on the outline of a rectangle is tested with four stroked rectangles,
+ one is the thin black stroked test frame rectangle, the second one a large blue rectangle, the third a rectangle
+ with rounded corners, looking like a circle and the fourth a small square.
+
+
+ The correct position is tested by a comparsion with several filled rectangles in the background or in the fourth case
+ covering the test square completely. The parts of the background covered with the blue test rectangles are filled red,
+ respectively the test square is stroked red too.
+ Therefore if something red gets visible, the position of the stroke of
+ the related test rectangle is wrong.
+
+
+ According to the conformance criteria all visual rendering should be accurate to within one px unit to the mathematically
+ correct result. Therefore possible residuals from the red background parts have to be in this
+ range of accuracy to pass the test.
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'silver'.
+ At the start the entire background should be a light grey.This should then change to aqua.
+ There are two reference squares in the center - silver and aqua.
+
+ Test on viewport-fill and viewport-fill-opacity.
+ Animates viewport-fill from yellow to blue over one second, and animates viewport-fill-opacity from 1.0 to 0.5.
+
+ Test on viewport-fill and viewport-fill-opacity. viewport-fill-opacity is set to 0.0 so the set viewport-fill
+ color should not be visible. The image has its viewport-fill set to "inherit" and viewport-fill-opacity to 1.0
+ so the image should show with a yellow viewport-fill and full opacity.
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'yellow'
+ with a 'viewport-fill-opacity' of 1. At the start the entire background should be solid yellow.
+ This should then change to a pale bluish gray. There are two reference squares in the center - solid yellow - to
+ match the background at the start and a pale yellow that should match the backgound after a few seconds.
+
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'path' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'rect' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
Verifies that shapes can be filled, stroked and the order of filling and stroking.
+
There is one pair of octagons. These are filled plus stroked.
+
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'rect' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). It also validates basic Shape, Image and text rendering.
+
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" should show through the rectangle and none of the rectangle should show through the image.
+
Prerequisites: the test assumes proper handling of the fill stroke, stroke-width, font-size rendering properties. It uses the rect, line, text and image elements, as well as all the elements required for the test template. To ensure that the text string is overlapped by the other elements and to avoid a dependency on system fonts, an SVG font is used.
+
The rendered image should match the reference image exactly.
Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). It also validates basic Shape, Image and text rendering.
+
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" should show through the rectangle and none of the rectangle should show through the image.
+
Prerequisites: the test assumes proper handling of the fill stroke, stroke-width, font-size rendering properties. It uses the rect, line, text and image elements, as well as all the elements required for the test template. To ensure that the text string is overlapped by the other elements and to avoid a dependency on system fonts, an SVG font is used.
+
The rendered image should match the reference image exactly.
+ Test that when a script element has both an xlink:href attribute and child character data,
+ the executable content for the script is retrieved from the IRI of the xlink:href attribute,
+ and the child content is not added to the scripting context.
+
+
+ The test loads an external script resource, which if executed sets the fill or the blue rect to green.
+ If the child content is executed the fill will be set to red and an alert will be displayed.
+
+
+ The test has passed if the rect is green after script execution has taken place and there has been no
+ alert displayed.
+
+ Test that scripts are not processed until added to the DOM tree. Also test that a function defined in a script
+ element can be called from a handler element in the same scripting context.
+
+
+ When the blue rect is clicked a script element is created. The script to be run must not be processed until
+ the script element is added to the tree. If it is processed before added to the tree, the rect that is
+ inserted into the document will be red. If not, then it will be green.
+
+
+ The test has passed if after clicking the blue rect a green rect is displayed in its place.
+
+ The test consists of 8 subtests, each testing requirements from the script processing section.
+ When the test is first loaded it shows 8 red circles. After the scripts have been executed the circles should all be green.
+
+
+ The test has passed if all 8 circles are green after the script processing has taken place.
+
Tests basic mouse event handler and DOM manipulation through ECMA script binding.
+
The test uses ECMA Script 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
+ This test tests the assertion from the Namespaces in XML specification,
+ "The namespace prefix, unless it is xml or xmlns, MUST have been declared
+ in a namespace declaration attribute in either the start-tag of the element
+ where the prefix is used or in an ancestor element (i.e. an element in whose content the prefixed markup occurs)."
+ The root element doesn't declare the XML Event namespace for the prefix "ev".
+
+
+ The test has passed if handlers are implemented (the handler with xml:id="passhandler" has run)
+ but the handler with xml:id="failhandler" has not run.
+ If the handler is run then the text in the testcase will show "Test failed: magic prefixes!".
+ If handlers are not implemented at all, the testcase will show "Test failed: handlers not implemented."
+
+
+ The test is also passed if the implementation states somehow that the test case is not namespace
+ well formed (by overlaying it on the image, informing the user in the error console, not
+ showing the document at all, etc.).
+
+ This test tests that a handler is not found when the 'handler' attribute contains
+ an IDREF. The test fails if a red rectangle covers the text content area or the string "Test failed" is displayed.
+
+ This test tests that an element with the name 'listener' is not interpreted as an svg element,
+ and that it's not the same as an element named 'listener' in the XML Events namespace.
+
+
+ The test has passed if handlers are implemented (the handler with xml:id="passhandler" has run)
+ but the handler with xml:id="failhandler" has not run.
+
+ If the handler is run then the text in the testcase will show "Test failed: 'listener' is not an svg element.".
+
+ The pass condition is indicated by two rects that must both be green after running the test, if
+ either of the rects is red then the test has failed.
+
+ This test tests the 'propagate' and 'defaultAction' attributes on the XML Event 'listener' element.
+
+
+ The test has passed if after clicking the each of the blue rects they both turn green and show the text "Passed",
+ and that clicking the leftmost rect doesn't traverse the link. If any of the rects are blue or red after clicking
+ them the test has failed.
+
Tests the degenerate cases of the basic shapes. The shapes are positioned within the black rectangles.
+
None of the shapes should be visible (each of the ten black rectangles should be empty). The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ For this test to pass the following lines must be drawn:
+ - Green line across the top from 480,0 to 0,0
+ - Red line across the left hand side from 0,0 to 0,360
+ - Blue line across the bottom from 480,360 to 0,360
+ - Purple line across the test from 480,85 to 0,0
+ - Fuchsia line across the test from 0,0 to 480,170
+ - Aqua line across the test from 0,360 to 480,170
+ - Teal line across the test from 480,256 to 0,360
+
+
+ If the x1, x2, y1, or y2 attribute is not specified the effect is as if
+ a value of "0" were specified.
+
+
+ The rendered picture should match the reference image, except for possible
+ variations in the labelling text (per CSS2 rules).
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+
Testing the default attributes on the rect element. There should be four rectangles. One should be placed on the left (default x), one on the top (default y). Two rounded rectangles should appear where rx and ry are of the same value (one of the two had been omitted).
Testing the correct stroking of the rect element. The blue lines indicate where a dash or gap should start and end. For the test to pass, it has to match the reference image.
+ Tests that the value of the 'class' attribute is included in the DOM,
+ including space-separated values, and values with extraneous spaces.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing three green circles, with text below each circle
+ reflecting the normalized space-separated values for the class of that
+ circle. The leftmost circle has the value "foo", the middle circle has
+ the value "bar baz", and the rightmost circle has the value
+ " funky spacing ", normalized to "funky spacing". If any of the
+ circles are red, the test has failed.
+
+ Tests that reading of IDs and modification of id and xml:id is conformant to the SVG and xml:id specifications. The test passes if four green circles are shown.
+
+
+ The first circle has an id only; the second, xml:id only. The third circle has both, with the same values; and the fourth has both, with different values. All four circles have a red fill; on loading the document, a script
+ gets each of the circles by its ID and then sets the fill to green. Lastly, the script attempts
+ to get the fourth circle by ID, using the value of the id attribute; this must fail. If the fourth
+ circle is dark red, the implementation is not giving priority to the value of xml:id.
+
This test evaluates a switch statement. The result should be a green rectangle in the lower left quarter of the output window.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
This tests ability to use the 'systemLanguage' as a test attribute within a switch element. To pass, either
+
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 requiredFeature. If a red rectangle with white text 'FAIL' is
+ displayed, the test fails. Otherwise, if a green rectangle is displayed in the lower part with the text '',
+ the test is passed.
+
+
+ The red rectangle and the white text each require a non-existent feature; the test attribute will thus
+ evaluate to false and neither element will be rendered by a compliant implementation.
+
+
+ The upper subtest is informative; it distinguishes between a purely SVG Tiny 1.2
+ implementation and others which also implement more (eg SVG Full 1.1, or
+ some profile of SVG 1.2 greater than Tiny). The results of this subtest
+ does not affect the pass/fail criteria.
+
+
+ Because SVG Tiny does not support for SVG Full DOM, an SVG Tiny implementation which
+ does not support other SVG Profiles should show a rectangle
+ like this.
+ If the application supports the DOM, meaning that it does more than just SVG Tiny, it
+ should show a rectangle like this.
+ Either result is a pass.
+
+
+ The lower subtest,has another switch. The first child has a requiredFeature
+ set to http://www.w3.org/TR/SVG11/feature#BasicText which all SVG Tiny implementations
+ must support. If the application does, the lower rectangle is displayed in green
+ like this. Otherwise, a red rectangle
+ indicates that the text has failed.
+
+ A series of switches are used to determine which Internet Media types ('MIME types')
+ are supported, using the 'requiredFormats' attribute,
+ displaying a 'yes' or 'no' as appropriate. The test is passed if there is text in
+ the second row of each column, and that text is only
+ green (in the top table)
+ or blueviolet (in the bottom table);
+ no red text is displayed.
+
+
+ The SVG Tiny 1.2 specification mandates certain formats, so these must be supported:
+ image/jpeg, image/png, image/svg+xml.
+ It is an error not to support them, therefore 'yes' is green and 'no' is red.
+
+
+ This test also checks for support of Internet Media types which are
+ assumed to not exist and are unlikely to ever be registered: garbage/garbage.
+ Therefore, 'yes' is red and 'no' is green.
+
+
+ Lastly, most media types are optional. For example, image/tiff may be
+ supported but support is not mandated by the SVG Tiny 1.2 specification.
+ The second table examines these optional formats.
+ Both 'yes' and 'no' are displayed in blueviolet. Whether the particular Internet Media type
+ is supported or not does not affect whether the test is passed or failed, but does provide useful
+ information about the optional capabilities of a particular implementation.
+
+ This test evaluates the effects of the 'display' or 'visibility'
+ attributes on a switch statement. The result should be a green circle
+ in the center of the output window.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing a green circle in the center of the image. If a
+ gray rectangle is visible, the test cannot be evaluated because the
+ 'display' attribute is not supported. If a blue rectangle is visible,
+ the test cannot be evaluated because the 'visibility' attribute is not
+ supported. If a red rectangle with a gray stroke is visible, the test
+ is failed because the switch is affected by the 'display' attribute.
+ If a red rectangle with a black stroke is visible, the test is failed
+ because the switch is affected by the 'display' attribute.
+
+
+ The test uses the 'rect' and 'circle' elements, as well as basic fill
+ (solid primary colors), stroke (black or gray 2-pixel lines), and the
+ 'display' and 'visibility' attributes.
+
+ This test evaluates the effects of the switch statement on referencing
+ content such as gradients or elements. The result should be a yellow
+ rectangle in the center of the output window, with green circles in
+ three of the corners of the rectangle.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing three circles, one solid green circle in upper
+ right corner of the rectangle, and a circle with a green gradient in
+ each of the bottom corners of the rectangle. If a red or black circle
+ is visible in the upper left corner of the rectangle, the test cannot
+ be evaluated because the 'switch' is not correctly supported. If any of
+ the upper-right or lower circles is not visible, or does not have the
+ correct fill, the test is failed. If the bottom-right circle is not
+ visible or does not have the gradient fill, then the 'switch' is not
+ correctly supported, and does not allow one conditionally hidden
+ resource to reference another.
+
+
+ The test uses the 'rect', 'circle', 'gradient', and 'use' elements, as
+ well as basic fill (solid primary colors) and radial gradients.
+
Test to verify that the defs element is used as a container correctly.
+
In this test a fill is created which is solid red. The view should be a solid red 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 green fill and the other to obscure most of the red rectangle. The green rectangles should not show in the view as defs are referenced items and are not rendered. No green should show.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
+ Tests that the value of the display property on the defs element or on its descendants
+ doesn't prevent the elements from being referenced.
+
+
+ The test has passed if the following conditions are met:
+
+
+
there are 8 big rects visible each of a different color.
+
on top of the 8 big rects there are 8 circles that contain the reference color, the color of each circle must match the color of the rect to the right of its center
+
from the top-left to the top-right corner the colors must be: green, lime, yellow, olive.
+
from the bottom-left to the bottom-right corner the colors must be: navy, teal, blue, fuchsia.
+ This test tests that discard acts the same as removeChild.
+ First two red rects and a blue circle should be seen. The blue circle has
+ its radius animated to 0 over the course of 3 seconds. At the point where
+ the blue circle disappears the two red rects should be removed from the
+ tree. This reveals two green circles.
+
+
+ The test has passed if in the interval 0-3 seconds there are two red rects and a blue circle, and after 3 seconds two green circles can be seen and the text at the bottom says "Test passed".
+
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.
+
Because preserveAspectRatio is set to 'none', the content should appear distorted: 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.
+
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's size is 480 by 360 with an x/y origin in (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. Changing the viewport size should have no effect on the placement or scale of the document's conten.
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.
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.
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 xml:id=allGs. The two red rectangles and the yellow are in the g labeled rects. The reds 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 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.
This test validates that properties are inherited (or not, depending on their defintion), from a group to its children.
+
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 basic image formats allowed in the tiny profile are supported. 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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
This test verifies the support for gamma correction of displayed PNG images. 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 the tiny profile 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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
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>.
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.
+ Tests progressive rendering. Progressive rendering is an optional feature.
+
+
+ On user agents which support progressive rendering, the test is passed
+ if the circles render progressively. The update frequency is
+ implementation dependant.
+
+
+ On user agents which do not support progressive rendering, the test is passed
+ if all the circles are all displayed in a single render.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the rectangle should be full of circles, rendered all at once because of forward use with externalResourcesRequired.
+ The update frequency is implementation dependant.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the rectangle should be full of circles, rendered progressively.
+ Images should appear as the circles pass the yellow dots.
+ The update frequency is implementation dependant.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the content should be rendered all at once due to forward use of externalResourcesRequired on top-level SVG.
+ The update frequency is implementation dependant.
+
+ This test tests that any <svg> elements that are encountered inside
+ an <svg> element are ignored, if the user agent supports SVG Tiny 1.2 only.
+
+
+ If the user agent can handle SVG 1.1 Basic or Full, then the test has passed
+ if only the string "This text should be visible if the viewer supports at least SVG 1.1 Basic."
+ is visible.
+
+
+ If the user agent supports only SVG 1.2 Tiny then the test has passed if
+ the svg element and it's contents have been ignored. Only the string
+ "This text should be visible if the viewer supports only SVG 1.2 Tiny." should
+ be visible.
+
+
+ If both strings are visible then the test has failed.
+
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).
+
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.
+ This tests a set of 'use' and 'rect' elements inside 'g' elements, with
+ each referencing the one before. For the test to pass, 5 nested
+ rectangles with a green stroke must be rendered, and no red rectangles
+ must be rendered.
+
+ This test tests reference restrictions on the use element. Each of the 5 different
+ restrictions is tested.
+
+
+ A compliant SVG Tiny 1.2 user agent must treat each of the invalid IRI:s as if the xlink:href
+ attribute hadn't been specified, which is the same as disabling rendering of the use element
+ in question. Thus for the test to pass none of the content that the use elements try to reference
+ must be visible, the end result should be 5 empty (white) rects.
+
+
+ For a user agent that handles at least SVG 1.1 Basic the testcase has still passed if the referenced
+ content in the rect that is labelled "B" is visible since this is allowed for 1.1.
+
+ This test tests the reference restriction B on the use element.
+
+
+ A compliant SVG Tiny 1.2 user agent must treat each of the invalid IRI:s as if the xlink:href
+ attribute hadn't been specified, which is the same as disabling rendering of the use element
+ in question. Thus for the test to pass the content that the use element tries to reference
+ must be invisible, the end result should be an empty (white) rect.
+
+
+ For a user agent that handles at least SVG 1.1 Basic the testcase has still passed if the referenced
+ content in the rect that is labelled "B" is visible since this is allowed for 1.1.
+ If the script in the external resource is executed then the color of the rect will be green.
+ If not then the rect will be red.
+
The intent of the file is to determine if the UA supports references to external SVG fragments. 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 object, the UA should display a semi transparent duplicate copy at an offset position. See referenced image.
The intent of the file is to determine if the UA supports references to external SVG fragments. 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 object, the UA should display a semi-transparent duplicate copy at an offset position. See referenced image.
+ This test checks some aspects of the SVGElementInstance with regards to events.
+
+
+ Four blue rects should be visible at first. To run the test each rect must be clicked a minimum of two times. Once
+ to run the basic test, and once to verify that the event handler was removed properly. The test has passed if after
+ clicking all the rects two times or more there are four green rects with the word "Passed" on them. If anything red
+ is visible or the text on any of the rects say "Failed" then the test has failed.
+
+
+ The top-left rect checks that correspondingUseElement and correspondingElement are returning the correct values, and
+ also that the currentTarget isn't the same as target here.
+
+
+ The top-right rect checks that events bubble the correct way when SVGElementInstance is involved. It's almost the same
+ as the first subtest, but uses another 'use' element.
+
+
+ The bottom-left rect doesn't use 'use' elements at all, it's to illustrate event bubbling in normal trees as compared
+ to SVGElementInstance trees.
+
+
+ The bottom-right rect uses nested 'use' elements. The event handler 'nestedhandler' should be executed first, and will
+ check some aspects of nested use elements. It will modify what it references, and that is checked in the 'h4' event
+ handler.
+
+ 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.
+
+
+ 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.
+
+ For this test to pass the green text "This text should be visible." must
+ be rendered. It is not an error if graphics are visible in addition to
+ the green text. It is not a requirement that graphics be rendered in
+ addition to the green text.
+
+ This test checks for recursion in 'use' elements. The passing conditions are that the browser does not crash, and that at least one orange circle, and one yellow circle, and a line of green text are rendered.
+ Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may not be rendered, depending upon when and how the implementation detects the circular reference,
+ with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation.
+
+ This test checks for recursion in 'use' elements with external references. The passing conditions are that the browser does not crash, and that the green test is rendered. The passing conditions are that the
+ browser does not crash, and that at least one orange circle and a line of green text are rendered. Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may
+ not be rendered, depending upon when and how the implementation detects the circular reference, with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation..
+
+
+ This test depends upon 'struct-use-recursion-03-t.svg'.
+
+ This test checks for recursion in 'use' elements with external references. The passing conditions are that the browser does not crash, and that at least one yellow circle and a line of green text are rendered.
+ Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may not be rendered, depending upon when and how the implementation detects the circular reference,
+ with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation.
+
+
+ This test depends upon 'struct-use-recursion-02-t.svg'. It differs from 'struct-use-recursion-02-t.svg' in that the 'use' element comes before the 'circle' element.
+
Verify property inheritance as required by 6.7 "Property inheritance".
+
For this test to pass:
+
At the center right, there is an ellipse. The fill color is not specified on that element but on its parent. The ellipse must 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 from the center to the edge.
+
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 from the center to the edge
+ Tests inheritance, animation and effect of display:none on stop-color. Three
+ rectangles are displayed. After a five second animation has completed,
+ the test is passed if all three rectangles display a green to blue gradient.
+
+
+ The stop-color property is not inherited by default, but the value 'inherit' forces it to
+ inherit the current animated value from its parent.
+
+
+ In the first subtest, the value of the stop-color property on the second stop is
+ 'inherit'. Its parent, linearGradient with id "MyGradient" also has stop-color set to
+ "inherit". The parent of this gradient is the group with id "g2" and the property
+ stop-color is animated on that group. Thus, after the animation finishes,
+ the inherited value is blue.
+
+
+ In the second subtest, the value of the stop-color property on the second stop is
+ 'currentColor'. Its parent, linearGradient with id "MyGradient" does not have the
+ color property set, but the property is inherited, so it inherits from the
+ parent - the group with id "g2". The property color is animated on that group.
+ Thus, after the animation finishes, the inherited value is again blue.
+
+
+ The third subtest is not animated. It checks that, per specification, the properties
+ on a gradient are inherited from the point of definition, not the point of use. An
+ implementation which does this incorrectly will show a green to red fill.
+
+ Tests inheritance, animation, currentColor on solid-color. Four
+ rectangles are displayed. After a five second animation has completed,
+ the test is passed if all four rectangles display a solid green fill.
+
+
+ Note: The solid-color property is not inherited by default, but the value 'inherit' forces it to
+ inherit the current animated value from its parent.
+
+
+
+ In the first subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent, a group, also has solid-color set to
+ "inherit". The parent of this group is another group, the property
+ solid-color is green on it.
+
+
+ In the second subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent has solid-color set to
+ "inherit". The parent of this group is another group whose solid-color
+ property is yellow.
+ The solid-color property on the solidColor element is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value is green.
+
+
+ In the third subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent has solid-color set to
+ "inherit". The parent of this group is another group whose solid-color
+ property is yellow.
+ The solid-color property on the outermost group is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value is green.
+
+
+ In the fourth subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'currentColor'. Its parent has color set to
+ "inherit". The parent of this group is another group whose color
+ property is yellow.
+ The color property on theoutermost group is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value of color, and thus the value used by currentColor, is green.
+
Check that !important in presentation attribute is an unsupported attribute value. To pass, two rectangles should be drawn. A black filled rectangle and a lime green stroked rectangle.
+
+ 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.
Test horizontal baselines across script and font size changes.
+
+ The dominant baseline should be alphabetic, so the 'ab' will be sitting
+ on the blue line, the japanese glyphs 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 'ab' on the blue line, the ideographic chars
+ slightly below the line and the devangari should be hanging from the
+ hanging baseline.
+
+ 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.
+
+
+ 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 (red) 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 for viewer capability to handle the basics of the 'textAnchor'
+ alignment property for 'text' when it has child elements.
+
+
+ The first line from the top tests that a 'tspan' element is rendered
+ after the text content of the parent 'text' element.
+
+
+ The second line from the top tests that all the text content, including
+ that of child 'tspan' elements, is taken into account when positioning
+ the text with respect to its alignment point.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the text fonts and layout (per CSS2 rules).
+
Testing 'textArea' with fixed 'width' and 'height'
+
+ Lines should break at character boundaries if there is not enough room to perform word breaks.
+ The 'height' of the first 'textArea' below (top-right) is less than that of the characters
+ so nothing should appear.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
Testing 'textArea' with fixed 'width' and 'height'
+
+ Three 'textArea' elements contain words which are increasing in 'font-size'.
+
+ To pass, no characters should appear in the top-right box since the 'height' of the 'textArea' is less
+ than that of the characters.
+
+ There should be no characters outside of the border of the larger bottom-left box.
+
+ In the left-side box, there may be characters outside of the border, depending on whether
+ the implementation breaks words or not.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+ A visible rectangle is drawn the same size as the textArea. The text
+ contained in the textArea should automatically wrap.
+
+
+ The textArea starts off as a 24x 24 square and is animated down to full
+ size. The text should continually rewrap as the textArea increases in
+ size.
+
+
+ The text is taken from "The Lost Princess of Oz" by Baum, L. Frank
+ (Lyman Frank), 1856-1919
+
+ The eight lines of numbers should not wrap. Each line is terminated by a tbreak element.
+ They have numbers from 0 to 50. Each line increases the 'font-size' by 25%.
+ The 'line-increment' attribute is not used.
+
+
+ This test is passed if eight lines of numbers are rendered and not
+ wrapped to a new line. Numbers displayed will decrease with each line.
+ Every line must begin with number 0.
+
+ Each word should break onto a new line. The left-hand 'textArea' has no 'tbreak' elements
+ while the right-hand one uses 'tbreak' after each word. Both should appear the same.
+
Testing 'tbreak' while animating the 'font-size' attribute in 'tspan' in 'textArea'
+
+ This test defines one 'textArea' element with a 'tspan' child. The 'tspan' has as red fill and also an animation
+ which animates the font-size from 0 to 20. The tspan element has a tbreak element before and after it.
+
+
+ To pass, the red text should both start and end on a new line, even when the font-size of the tspan is animated.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+ A visible rectangle is drawn the same size as the textArea. The text contained in the textArea should
+ automatically wrap.
+
+
+ The textArea starts off as a 24x 24 square and is animated down to full size. The text should continually
+ rewrap as the textArea increases in size.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+ This test checks basic text-editing capabilities.
+
+
+ Start editing by activating the textArea that has a green dashed outline.
+ This textArea has no child text content, but has a defined width and height.
+ Input the string "123 456" (one two three, space, space, four five six).
+
+ After input is complete, click the button labeled "Check #1". If the frame around
+ the textArea goes from being dashed to being solid then that part of the test has passed.
+ Another condition is that the text string "123 456" should look like it only has one space
+ and not two due to the whitespace handling rules.
+
+
+ Next activate the middle textArea that has a red dashed outline.
+ Input two spaces between 3 and 4. Now since this textArea has xml:space="preserve" those
+ two spaces should be rendered as two spaces, meaning it must look different from the first
+ textArea on the left. The textContent must be the same in both cases though, and this is
+ verified by clicking the button labeled "Check #2". If the test is successful the frame
+ will turn from dashed red to solid red.
+
+
+ Finally activate the rightmost textArea that has a blue dashed outline.
+ Then exit the editing mode without changing the text. The text must not change and the 'tbreak' element
+ must be kept in the position it's in. Now activate the textArea again and input an additional linebreak between 3 and 4.
+ The line "345" must now be on the third line, the second line being blank.
+ Click the button labeled "Check #3" to verify the result, the frame will turn from dashed
+ blue to solid blue if successful.
+
+
+ The test has passed if after inputting text according to the instructions above and clicking the three
+ buttons the rendered image matches the reference image exactly.
+
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.
+
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.
Testing font-family attribute. Two SVG fonts are defined. Various text elements are then used with varying values for the font-family attribute. 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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
+ Testing font-family attribute.
+ Various text elements are
+ used with varying values for the font-family attribute.
+ The first two text elements should display in their respective fonts,
+ Haettenschweiler and
+ ,
+ 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.
+
+
+ If the two named fonts are available on the system,
+ the rendered picture should match the reference image exactly,
+ except for possible
+ variations in the labelling text (per CSS2 rules)
+ and variations in text antialiasing or hinting.
+
+ 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
+ the platform supports installable opentype fonts, please download
+ Zalamander Caps
+ by Tim Ahrens of Just Another Foundry.
+
+
+ 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.
+
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.
+
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.
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.
+
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.
+
A future version of this test might include all necessary glyphs as an SVG font.
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.
Test text element, tspan element and various text styles.
+
The first group tests that text displays at all, that it displays in a straight line, and that the font style can be made italic or bold.
+
The second group tests that text can be treated as any other graphical element, with stroke and fill properties. The first word tests that fill color can be specified. The second word tests that stroke color can be specified in absence of fill. The third group tests the combination of all these effects. The final group tests positioning of 'text' elements.
The purpose of this test is to validate proper handling of the text element's x and y attributes. In the various samples, a red 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.
+
In all the above tests, blue markers represent the expected glyph positions. The red 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 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 red), 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.
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
+ 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.
+
+
+
+ The rendered picture should match the reference image exactly, except for possible
+ variations in the labelling text (per CSS2 rules).
+
+ This test demonstrates text selection of bidirectional text.
+
+
To pass the test the the first 9 characters in logical order starting from logical position 0 are to be selected. This must be done by the tester since there's no way to control the selection in DOM. The selection should be started at the letter 'a' and proceed to the number '1' as indicated by the arrows. Visually this makes the selection 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.
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;
+
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.
+
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.
+ This tests that the getTrait[NS] and setTrait[NS]
+ methods of the TraitAccess interface work for the special
+ '#text' trait on the desc, title,
+ metadata, text, tspan and textArea
+ elements.
+
+
+ The rectangle in the top left corner indicates whether the
+ getTrait and getTraitNS returned the expected
+ strings for each of the relevant elements; blue for pass,
+ red for fail. The four text strings below it indicate whether
+ setTrait and setTraitNS worked on the text
+ and textArea elements; they must all be the string “PASS”.
+
+ This tests that the Node interface attributes
+ namespaceURI, localName, parentNode
+ and ownerDocument are correct, for some simple cases.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the attributes being tested have the expected values; green for
+ pass, red for fail.
+
+ This tests that the textContent attribute of the
+ Node interface works correctly. The test is passed
+ if a blue square and two "PASS" are displayed.
+
+
+ The rectangle in the top left corner indicates whether the
+ behavior when manipulating the textContent attribute
+ on various elements.
+ The two text strings below it indicate whether setting
+ textContent on the text and textArea
+ elements succeeded.
+
+ This tests that the appendChild method of the
+ Node interface works correctly.
+
+
+ The test has been passed if six blue rectangles are displayed.
+ Each rectangle indicates the result of a different aspect of
+ appendChild behavior being tested:
+
+
+
+ The first is a test of appending a newly created rect that
+ is not yet in the document tree.
+
+
+ The second is a test of appending a rect that is already
+ somewhere else in the document tree. In its initial position, it
+ inherits fill='red', and in its new position, it inherits
+ fill='blue'.
+
+
+ The third is a test of appending a rect to its current
+ parent. This results in the rect being moved to the
+ final position in the list of child nodes. In its initial
+ position, a red rect occludes this blue one. In its final
+ position, this blue rect occludes the red one.
+
+
+ The fourth is a test of appending a second element to the document
+ node. This results in a DOMException being thrown with code
+ HIERARCHY_REQUEST_ERR. If this exception is thrown, the
+ rect is changed from red to blue.
+
+
+ The fifth is a test of appending an element to one of its
+ descendant elements. This also results in a DOMException being
+ thrown with code HIERARCHY_REQUEST_ERR. If this exception is
+ thrown, the rect is changed from red to blue.
+
+
+ The sixth is a test of appending an element from another document
+ into this document. The element from the other document is obtained
+ by calling parseXML. A DOMException must be thrown with
+ code WRONG_DOCUMENT_ERR. If this exception is thrown, the
+ rect is changed from red to blue.
+
+ This tests that the removeChild method of the
+ Node interface works correctly.
+
+
+ The test has three sub-tests, for different removeChild
+ behavior, which consist of a paired rectangle and circle:
+
+
+
+ The first is a test of successfully removing a single element
+ from the document. Initially, a red rectangle occludes a blue
+ rectangle. This red rectangle should then be removed by the
+ removeChild call, which results in the blue rectangle
+ becoming visible. The circle beneath it represents whether
+ removeChild returned the correct value (i.e., a reference
+ to the same red rectangle that was removed). If this return
+ value is incorrect, the circle will remain red. If it was
+ correct, the circle is changed to be blue.
+
+
+ The second is a test of successfully removing a subtree
+ from the document. The subtree is simply a g element
+ with a red rect as a child, which initially occludes
+ a blue rectangle. The group with the red rectangle should then be
+ removed by the removeChild call, which results in the blue
+ rectangle becoming visible. The circle beneath it represents
+ whether removeChild returned the correct value (i.e., a
+ reference to the g element that was removed). If this
+ return value is incorrect, the circle will remain red. If it was
+ correct, the circle is changed to be blue.
+
+
+ The third is a test of removeChild throwing a NOT_FOUND_ERR
+ DOMException when passed an element that is not a child of
+ the element on which the method was called. If the blue rectangle
+ remains, the implementation correctly did not remove it. The circle
+ indicates whether the exception was thrown as expected. If the
+ exception was not thrown, or the wrong is exception is thrown,
+ the circle will remain red. Otherwise, the circle will be changed
+ to be blue.
+
+
+
+ The test has been passed if the top row shows three blue rectangles
+ and the bottom row shows three blue circles.
+
+ This tests that the cloneNode method of the
+ Node interface works correctly.
+
+
+ The test has two sub-tests: one for a deep clone, and
+ one for a shallow clone.
+
+
+
+ The first row shows the deep clone sub-test. A group
+ containing three cascaded rectangles and a text
+ element are cloned and inserted into the document 180
+ user units to the right. The group inherits fill and
+ stroke colors from a parent element, and where the cloned
+ copy of the group is inserted, different colors are
+ inherited. The original group inherits a blue fill and
+ a light blue stroke, while the cloned group inherits an
+ orange fill and a light orange stroke. The text in both copies
+ of the group have a white fill and no stroke.
+
+
+ The second row shows the shallow clone sub-test. A circle
+ element with two child set elements (that set the fill to
+ blue and the stroke to light blue) is shallow cloned and inserted
+ into the document 100 user units to the right. Since it is a
+ shallow clone, the cloned circle does not have the
+ set element children, and inherits an orange fill
+ and a light orange stroke.
+
+ This tests that the createElementNS method on the
+ Document interface works correctly, for each SVG Tiny 1.2
+ element, and for some unknown elements.
+
+
+ There are four sub-tests (a rectangle for each). The test has been
+ passed if all four rectangles are blue.
+
+
+ Thes are:
+
+
+
Sub-test 1: test creating each SVG Tiny 1.2 element.
+
Sub-test 2: test creating an unknown element in no namespace.
+
Sub-test 3: test creating an unknown element in the SVG namespace.
+
Sub-test 4: test creating an unknown element in another namespace.
+ This tests that the firstElementChild,
+ lastElementChild, nextElementSibling and
+ previousElementSibling methods of the ElementTraversal
+ interface works correctly.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the attributes being tested have the expected values; green for
+ pass, red for fail.
+
+ This tests that the target, currentTarget,
+ type and cancelable
+ attributes of the Event interface work correctly.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and all of its ancestor nodes. Clicking on the
+ rectangle will test that the attribute of the Event object
+ all have expected values, for each invocation of an event listener.
+ It also tests whether each of the event listeners is indeed invoked.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ This tests the stopPropagation method of the
+ Event interface.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and some of its ancestor nodes. Clicking on the
+ rectangle will dispatch the click event. The listener on
+ the parent node of the rect calls stopPropagation().
+ The test checks that the listener for the grandparent node is not
+ dispatched.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ This tests the defaultPrevented attribute and the
+ preventDefault method of the Event interface.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and some of its ancestor nodes. Clicking on the
+ rectangle will dispatch the click event. The listener on
+ the grandparent node of the rect calls
+ preventDefault(). The test checks that the event object has
+ defaultPrevented set to true.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ This tests the clientX, clientY and button
+ attributes of the MouseEvent interface.
+
+
+ The test consists of three rectangles, one for each of the three
+ common mouse buttons. To perform the test, the user must move the
+ mouse cursor over a rectangle, press the mouse button down, then
+ move the mouse cursor out of the rectangle. If after this the
+ rectangle becomes blue, then that sub-test has been passed, indicating
+ that the clientX, clientY and button
+ attributes of the MouseEvent object had expected values for
+ the mouseover, mousedown and mouseout
+ events.
+
+
+ The test as a whole has been passed if, for each rectangle that
+ corresponds to a button on the pointing device that the user
+ agent supports, it becomes blue after performing the interaction.
+ If the user agent does not support a pointing device at all,
+ then the test is passed automatically without needing to
+ perform any interaction.
+
+ This tests the data attribute of the TextEvent
+ interface.
+
+
+ To perform the test, the user must input some text. This can be
+ from a variety of sources, such characters directly from a keyboard,
+ text pasted from the clipboard, input from an IME or input from a
+ speech recognizer.
+ Once the text has been input, the black rectangle should turn blue to
+ indicate that the test has been passed. In addition, the
+ text element below the rectangle will show the text that was
+ input.
+
+
+ If the rectangle becomes red, the test failed because the
+ data attribute had an invalid value. If the rectangle
+ remains black, the test failed because the textInput
+ event is not supported. If the text string does not appear,
+ or does not match the input text, the test failed because the
+ textInput event is not supported correctly (e.g. it
+ only tests for any keyboard activity).
+
+ This tests the detail attribute of the UIEvent
+ interface and the dispatch order of mouse events when clicking.
+
+
+ To perform the test, the user must triple click on the circle.
+ The nine rectangles to the right of the circle indicate whether the
+ detail attribute of the UIEvent object was correct
+ for the mousedown, click and mouseup
+ events. The first row of rectangles checks the three events when
+ detail = 1, the second row for detail = 2 and
+ the third row for detail = 3.
+
+
+ In addition, the circle should remain black after the nine rectangles
+ have become blue. If the circle becomes red, it indicates that
+ the test failed because the mousedown, click and
+ mouseup events were fired in an incorrect order.
+
+
+ The test has been passed if, after triple clicking the circle, all nine
+ rectangles are blue and the circle remains black.
+
+ This tests that the target, currentTarget,
+ type and cancelable
+ attributes of the Event interface work correctly. It
+ is the same as udom-event-202-t except that the event listener
+ is given by an ECMAScript object with a handleEvent
+ property, rather than by an ECMAScript Function object.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and all of its ancestor nodes. Clicking on the
+ rectangle will test that the attribute of the Event object
+ all have expected values, for each invocation of an event listener.
+ It also tests whether each of the event listeners is indeed invoked.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ The test at first should show a green rectangle.
+
+
+ Trigger some mousewheel events, for example by using a mouse with a scrollwheel
+ or a jog dial.
+ The test has passed if, when you scroll down, the rectangle rotates clockwise;
+ and when you scroll up, the rectangle rotates counter clockwise.
+ For reference the values of the Mousewheel event are displayed as text.
+
+ This tests that the gotoLocation method is present
+ and works for a simple case.
+
+
+ Once loaded, the SVG file will be replaced by the words success. Note that the
+ contents of this file may be displayed for a short interval until the new file is loaded.
+
+ This SVG will test the SVGGlobal's postURL() callback status. The test
+ is passed if, on each row, both squares have the same color.
+
+
+ There are multiple calls to postURL(), each with a different expected
+ HTTP return code.
+
+
+ The test works in conjunction with a JSP servlet called HttpCodeTest,
+ which will simulate the various HTTP return codes, based on the query
+ parameter from the client.
+
+
+ For each call to postURL(), two squares will appear. The first square
+ represents the "expected" status code. The second square represents the
+ "actual" status code that the callback function receives. The status
+ codes are color-coded.
+
+
+ Note that the status codes may take some time to update, due to the
+ asynchronous nature of the postURL() callback. Tester should allow some
+ time for all postURL() calls to receive ther return codes. The latency
+ will vary depending on the network environment, but normally, it should
+ only be a couple minutes at most.
+
+
+ 100-ranges status codes are not tested here because the spec states that
+ these status codes should be ignored. It is not clear what the expected
+ callback status should be in this case.
+
+ This SVG will test the SVGGlobal's getURL() callback status. The test is
+ passed if, on each row, both squares have the same color.
+
+
+ There are multiple calls to getURL(), each with a different expected
+ HTTP return code.
+
+
+ The test works in conjunction with a JSP servlet called HttpCodeTest,
+ which will simulate the various HTTP return codes, based on the query
+ parameter from the client.
+
+
+ For each call to getURL(), two squares will appear. The first square
+ represents the "expected" status code. The second square represents the
+ "actual" status code that the callback function receives. The status
+ codes are color-coded.
+
+
+ Note that the status codes may take some time to update, due to the
+ asynchronous nature of the getURL() callback. Tester should allow some
+ time for all getURL() calls to receive ther return codes. The latency
+ will vary depending on the network environment, but normally, it should
+ only be a couple minutes at most. Once all calls have returned, the text
+ "Callbacks now finished" will show, in green.
+
+
+ 100-ranges status codes are not tested here because the spec states that
+ these status codes should be ignored. It is not clear what the expected
+ callback status should be in this case.
+
+ Test with cloneNode on a use element. The red rect is cloned directly on the rect element.
+ The yellow rect is cloned on the use element. Two red and two yellow rects must be showing.
+
+ Testing CloneNode with different values of the "deep" parameter.
+ In this test an image with animations inside is cloned twice, one which should keep the animations and the second that should only clone image node.
+ The first and second image should animate from opacity 0 and width 20 to opacity 1 and width 100. The third image should not animate.
+
+ 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 root 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 createElementNS method.
+
+
+ If an implementation supports the ECMAScript DOM binding for SVG, then the image must show the following text:
+ "This document's root identifier is: svg-root" and a red rectangle with a black shadow rectangle. Otherwise, only a red rectangle will show.
+
+
The rendered picture should match the reference image.
+ This tests the beginElement and beginElementAt
+ methods of the ElementTimeControl interface.
+
+
+ The test consists of four animated rectangles, one pink, three blue.
+ To perform the test, the user must click the pink rectangle.
+ The pink rectangle is set to animate with begin='mousedown',
+ while the three blue rectangles have begin='indefinite',
+ and are begun with calls to methods on the ElementTimeControl
+ interface:
+
+
+
+ The first blue rectangle is begun with .beginElement().
+
+
+ The second blue rectangle is begun with .beginElementAt(0).
+
+
+ The third blue rectangle is begun with .beginElementAt(2.5).
+
+
+
+ The test has been passed if the three blue rectangles reach their
+ destination at the same time as the pink rectangle.
+
+ This tests the beginElement and beginElementAt
+ methods of the ElementTimeControl interface, with different
+ begin instance time lists.
+
+
+ The test has been passed if all the three rectangles and the circle
+ become blue one second after clicking the circle.
+
+
+ The test consists of a pink circle and three animated rectangles.
+ To perform the test, the user must click the pink circle.
+ The three rectangles all have animations that begin='0s'
+ and run indefinitely, and are also set to restart='none'.
+ Clicking the circle will attempt to begin the three animations as follows:
+
+
+
+ The first rectangle's animation has .beginElement() called.
+
+
+ The second rectangle's animation has .beginElementAt(0) called.
+
+
+ The third rectangle's animation has .beginElementAt(0.5) called.
+
+
+
+ All three animations should not begin with these method calls, since
+ the animations have already started and are set to restart='none'.
+ If an animation does restart, its endEvent will be captured
+ and the rectangle will become red. If the animation does not restart,
+ it will become blue one second after clicking the pink circle.
+
+
+ In addition, the circle should become blue one second after clicking
+ it. This indicates that the implementation correctly dispatches an
+ endEvent when an element restarts.
+
+ This tests the endElement and endElementAt
+ methods of the ElementTimeControl interface.
+
+
+ The test consists of four animated rectangles, one pink, three blue.
+ To perform the test, the user must click the pink rectangle.
+ The pink rectangle is set to animate with begin='mousedown'.
+ The three blue rectangles have two animations each: the first is
+ an animation element that moves the rectangle along its
+ corresponding line, with begin='0s' dur='5s'. After the
+ animation element is a set element with
+ end='indefinite'. Each set animation is ended with
+ calls to methods on the ElementTimeControl interface:
+
+
+
+ The first blue rectangle is ended with .endElement().
+
+
+ The second blue rectangle is ended with .endElementAt(0).
+
+
+ The third blue rectangle is end with .endElementAt(2.5).
+
+
+
+ The test has been passed if the first two blue rectangles follow the
+ animation of the pink rectangle, and the third blue rectangle follows
+ the animation of the pink rectangle after 2.5 seconds (i.e., half way
+ through the pink rectangle's animation).
+
+ This tests that the correspondingElement and
+ correspondingUseElement attributes of the
+ SVGElementInstance interface have expected values.
+
+
+ The test consists of a single rectangle that is a descendant
+ of a number of g elements and a couple of nested
+ use shadow trees. When the user clicks the rectangle,
+ a mousedown event is dispatched, which travels up
+ the nested shadow trees. If the correspondingElement and
+ correspondingUseElement attributes of the
+ SVGElementInstance object (which is the currentTarget
+ of the event) are correct, the rectangle becomes blue. Otherwise,
+ it becomes red.
+
+ This tests setting and getting the currentScale attribute of
+ the SVGSVGElement interface.
+
+
+ There are three sub-tests, each represented by a rectangle (blue for
+ pass, red for fail). The test has been passed if all three rectangles are blue, and
+ the test slide is shown at 90% of its regular size (i.e., the
+ range (0, 0) -> (533.333, 400) user units is shown).
+
+
+
+ The first sub-test checks that the initial value of
+ currentScale is 1. The second checks setting
+ currentScale to a valid value (in this case, 0.9), and
+ looks at the resulting screenCTM. The third exercises retrieving
+ the newly set value.
+
+ Test on SMIL with scripting. The animated bar should pause for 3s at 1.5s and resume at 4.5s.
+ The smaller rects should change color at the indicated times.
+
+ Test on SMIL with scripting. Animation should match the indicated begin- and end-values,
+ and should pause for three seconds when the pause-sign turn red.
+
+ Test on SMIL with scripting. Animation should match the indicated begin- and end-values,
+ and should pause for three seconds when the pause-sign turns red. restart is set to "never" so should NOT restart.
+
+ This tests that the getCurrentTime method of the
+ SVGSVGElement interface returns sensible values.
+
+
+ The test shows three rectangles. The test is passed if the first rectangle is blue, and after
+ clicking the second rectangle it turns blue, and after clicking
+ the third rectangle it also turns blue.
+
+
+ The first one represents
+ whether calling getCurrentTime before the load
+ event is dispatched returns 0. Clicking the second rectangle
+ (which is red to begin with) then tests that the current time is
+ greater than 0. Finally, clicking the third rectangle (which
+ also is red to begin with) tests that the current time is greater
+ than the time at which the second rectangle was clicked.
+
+
+ This tests the basic functionality of
+ SVGSVGElement.createSVGPath(). It
+ verifies that the returned path object has no path segments
+ initially, that a path segment can be added to the path object,
+ and that the object returned is actually
+ instanceof SVGPath.
+
+ This tests trait access methods on the TraitAccess interface
+ for the 'accumulate' trait. Each trait getter and setter method is called on
+ each applicable SVG Tiny 1.2 element.
+
+
+ The test is passed if the rendering matches the reference rendering.
+ The rectangle must be blue, and there must be a blue circle to the
+ right of it whose diameter is the same as the height of the rectangle.
+ There must be no text displayed below the rectangle.
+
+ This tests trait access methods on the TraitAccess interface
+ for the 'begin' trait. Each trait getter and setter method is called on
+ each applicable SVG Tiny 1.2 element.
+
+
+ The test is passed if, five seconds after the document begins:
+
+
+
the rectangle is blue,
+
+ there is a blue circle to the right of the rectangle whose
+ diameter is the same as the height of the rectangle,
+
+
an animation showing rotating rectangles to the right of the circle begins,
+
a video showing a dog to the right of the animation begins, and
+
an audio clip begins playing.
+
+
+ Also, there must be no text displayed inside the rounded green rectangle.
+
+ This test verifies that the CTM fetched by getScreenCTM is a snapshot value of the current animated state.
+
+ The CTM values are inspected on 'beginEvent', 'endEvent' and 'repeatEvent' times. The expected values are
+ calculated from the SMIL Animation equations and the current document time.
+
+ The test has passed if the testcase reports "Results match expected values." 8 times, and each such string
+ is prefixed with a green rectangle. When this happens the text in the rect with blue stroke changes from
+ 'failed' to 'passed'.
+
+ Four animations begin at time 0 and end at times 1, 2, 5 and 9 seconds. Event listeners are registered
+ for the "endEvent" event.
+ As each animation ends, getCurrentTime() is called and verified with the expected time. The expected time is compared with
+ the minimum time to take into account implementation-specific document time resolution.
+ If all times have the expected values, the text changes from 'testing' to 'passed'
+
+ Tests setCurrentTime. The test is passed if the the moving bar skips
+ from 2 to 4 , and from 5 to 8; and after the animation completes, the
+ text "passed" appears at the bottom right.
+
+
+ Four animations begin at time 0 and end at times 1, 2, 5 and 9 seconds.
+ Event listeners are registered for the "endEvent" event.
+ As each animation ends, getCurrentTime() is called to verify the expected current time, which
+ is them followed by a call to setCurrentTime.
+ If all times have the expected values, the text changes from 'testing' to 'passed'
+ The expected time is compared with
+ the minimum time to take into account implementation-specific document time resolution.
+
+ This tests setFocus and getCurrentFocusedObject, setting the focus and then checking that the correct element has focus. Successes are shown in green,
+ failures in red. If all subtests pass, the text in the blue box changes from "failed" to "passed".
+
+
+ A numeric keypad is shown. Focus starts on the "5" and is then moved programatically
+ to each of the other numbers, finally returning to "5". Since this happens on the load event, there is no indication of the focus moving.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test
+ various trait combinations with expected values. If a result is not as
+ expected, an error is displayed in red text, indicating the returned
+ result and what was expected. When all subtests have returned success,
+ the result is set to 'passed'. The pass condition for the test is that
+ all subtests are green, and the word 'passed' is at the bottom right.
+
+ This test creates an SVGColor object and verifies that the intial data is all zero. It then modifies the red, green, and blue attributes.
+ To pass, the resulting attributes should be as expected should be correct, and when this happens the text
+ changes from 'failed' to 'passed'
+
+
Note that, since the test does not insert this object into the document, it is not displayed. The test simply verifies that the object has been created correctly.
+ This test draws a few basic shapes and checks for correct values from getBBox().
+ 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'.
+
+ Note, this test does not have 100% for the svg width and height on purpose as to have exact
+ expected results for the screen bounding boxes
+
+
+ This test draws a few basic shapes and checks for correct values from getScreenBBox().
+ To pass, each returned bounding box must be correct (indicated by printing the values in green), and when this happens the text
+ changes from 'failed' to 'passed'
+
+ This test draws a few basic shapes and checks for correct values from getScreenCTM().
+ To pass, each returned CTM must be correct (indicated by printing the values in green),
+ and the string 'passed' appears in the lower right.
+
+
+ Note, this test does not have 100% for the svg width and height on purpose as to have exact
+ expected results for the screen CTM.
+
+ This test creates a SVGMatrix object and calls getComponent to verify the result
+ To pass, each returned component must be correct. To indicate a pass
+ the result of the test changes to green and the text at the bottom right
+ hand corner changes from "failed" to "passed".
+
+ This test creates two SVGMatrix objects and calls inverse on each.
+ The first matrix is invertable, but the second one is not, and should throw an exception when inverse() is called.
+ To pass, the inverted matrix must be correct, and the exception for the second matrix must be thrown.
+ To indicate a pass the result of the test changes to green and the text at the bottom right
+ hand corner changes from "failed" to "passed".
+
+ This test creates a few SVGMatrix objects and calls mMultiply.
+ To pass, the result matrices should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates some SVGMatrix objects and then calls mRotate.
+ To pass, the result matrices should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates an SVGMatrix object and calls mScale.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates an SVGMatrix object and calls mTranslate.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates path data using the SVGPath interface, with emphasis on support for close, moveTo and quadTo
+ To pass, the path data must match expected results for the text at the bottom of the test to read 'pass'.
+ The path data is verified by calling getSegment and getSegmentParam.
+ In addition, no red should be seen through the path element.
+
+ This test creates path data using the SVGPath interface, with emphasis on support for lineTo and curveTo
+ To pass, the path data must match expected results for the text at the bottom of the test to read 'pass'.
+ The path data is verified by calling getSegment and getSegmentParam.
+ In addition, no red should be seen through the path element.
+
+ This test creates SVGRect object and verifies that the initial data is all zero. It then modifies the x, y, width and height.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'
+
+ Tests access to textContent.
+ The only text that should be visible is the string "Rect Text and Rect Animate Text!" in green.
+ The set element that makes the element "setTextContent" hidden should be removed when setting the new textContent and therefore the text must be visible.
+
+ Tests trait access in uDOM.
+ The svg should look the same on both sides and the text
+ should read "Passed". Both the rects should link back to this test.
+
+ Test on solidColor solid-opacity trait access.
+ Test result are displayed within the test.
+ The first sub-test should display a number approximately equal to 0.2.
+ The second sub-test should display a number approximately equal to 0.5.
+ The third sub-test should display a number equal to 1.
+
+ Test on Ecma-script. Sets viewport-fill-opacity to 0.5 with setFloatTrait
+ (should show a red viewport with correct opacity, and the text 'viewport-fill-opacity="0.5"' should show).
+
+ 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.
+
+ 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.
+
+ An animation moves a triangle along a path. Reference rectangles, lines and text are provided to help show what the
+ correct behavior is. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'from' and 'to' attributes to define the 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. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'values' attribute to define the motion path, with a linear calcMode.
+ An animation moves a triangle along a path. Reference rectangles, lines and text are provided to help show what
+ the correct behavior is. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'path' attribute to define the 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. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'mpath' sub-element to define the motion path.
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+ 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.
+
+ 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 red text shows the attributes that were used for that particular animation.
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 test shows an animation with calcMode="discrete" (i.e., a jumping animation).
+ 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 test shows calcMode="paced" for an animation that has constant velocity, thus showing how 'values' and
+ 'keyTimes' are ignored.
+
+ 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.
+
+ 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".
+ 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 red square appearing, gradually and smoothly fading
+ from white to red over the course of three seconds.
+
+
+ The rendered picture should match the reference image, (except for possible variations in the labeling text
+ (per CSS2 rules)) after activating the link on the fade-in button the first time and waiting three seconds for the
+ animation to compete. The picture should remain looking the same way indefinitely, until another link is activated.
+
+
+ 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 red square goes from white to red. After the first click on "fade out", the red square goes from red
+ to white. After the second click on "fade in", however, the red square goes from white to red, and then goes back
+ from red to white. This is because of the hyperlinking rules as they relate to resolved start times in the SMIL
+ 2.1 specification.
+
+ Five orange rectangles have one animation each. When an
+ animation is active it moves its orange rectangle from its
+ left marker to its right marker. The active intervals
+ are [1-2], [4-6] and [8-10].
+
+ Precision test for accumulative animateMotion.
+
+
+ The main indication for a failed test is the appearence of something
+ red and that circles are not centered below the paths given in gray.
+
+
+ Circles are moved along squares given with the path attribute,
+ repeatDur and accumulate with a repeatDur of 30s and repetition.
+ Different values for the rotate attribute are given too, this has no visible effect,
+ because centered circles are moved.
+
+ Precision test for additive animateMotion using,
+ mpath element, path attribute, values, from-to.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the circle. A switch of the stroke of the circle from blue to gray indicates
+ the end of the test at 30s.
+
+
+ A circles is moved along some paths
+ (two of them indicated in gray) with
+ a duration of 30s using additive animateMotion.
+ The superposition is no motion.
+ The circle is positioned always at the bottom right.
+ The colour of the circle switches from blue to gray after
+ the animation is finished.
+ If the red center of the circle becomes visible, an error is
+ occured.
+
+ Precision test for linear animateMotion with separated path fragments,
+ mpath element, rotate auto.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the test circle. The circle has to follow exactly the paths given
+ in gray.
+
+
+ A linear animateMotion of a blue stroked square with a centered
+ circle is compared with four animateMotion of a red square
+ with a centered circle.
+ The motion of the red square is following the
+ combination of four animateMotion following on
+ each other and is the same as the motion of the blue
+ square, because the timing is choosen in such a way.
+ Therefore the blue square covers always the red one
+ completely.
+
+
+ The path is given in gray. The red fill of the circle
+ is always covered with the gray path.
+ Eight gray stroked markers are lightened, when the circle
+ is exactly above the marker. The red fill of the marker
+ is exactly covered by the blue stroked circle.
+ If something red gets visible, an error is occured
+ and the animateMotion is not linear.
+
+
+ The exact timing is calculated using an analytical
+ integration of the path length of the sub paths
+ (this is available for quadratic or linear curves).
+ With this method the path position and the
+ time can be determined as functions of the usual
+ parametrisation of the used Bézier curves.
+
+ Precision tests for animateMotion with animated mpath.
+
+
+ The main indication for a failed test is the appearence of something
+ red and that circles are not centered below the paths given in gray.
+
+
+ Blue rectangles and a red circles are moved along
+ light blue paths with a duration of 30s. The paths itself are animated.
+ This results in motions along the gray paths. The rectangles
+ are aligned along the animated light blue paths.
+ The circle is always covered by the path given in gray.
+ If something red gets visible, an error is occured.
+
+ Precision test for paced animateMotion with separated path fragments,
+ mpath element, rotate auto.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the test circle. The circle has to follow exactly the paths given
+ in gray.
+
+
+ A paced animateMotion of a blue stroked square with a centered
+ circle is compared with four animateMotion of a red square
+ with a centered circle.
+ The motion of the red square is following the
+ combination of four animateMotion following on
+ each other and is the same as the motion of the blue
+ square, because the timing is choosen in such a way.
+ Therefore the blue square covers always the red one
+ completely.
+
+
+ The path is given in gray. The red fill of the circle
+ is always covered with the gray path.
+ Eight gray stroked markers are lightened, when the circle
+ is exactly above the marker. The red fill of the marker
+ is exactly covered by the blue stroked circle.
+ If something red gets visible, an error is occured
+ and the animateMotion is not paced.
+
+
+ The exact timing is calculated using an analytical
+ integration of the path length of the sub paths
+ (this is available for quadratic or linear curves).
+ With this method the path position and the
+ time can be determined as functions of the usual
+ parametrization of the used Bézier curves.
+
Compare from-to, from-by and by animate with values animate.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ Additionally set animations can be replaced by values animations too.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
values="0;a" additive="sum"
+
+
+
set to="a"
+
values="a" additive="replace" accumulate="none"
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space.)
+
+
+ The from-to, from-by and by animations applied to the attributes x, y, width, height
+ of blue rectangles are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red rectangles. Additionally underlying dark red
+ rectangles simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The blue rectangles cover all red rectangles. Therefore if something
+ red gets visible, an error is occured. Because fill is always not set and therefore remove,
+ the final value is only that of the set animation, not very interesting for the test.
+
+ 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 red square appearing, gradually and smoothly fading
+ from white to red 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 red square.
+
+
+ The rendered picture should match the reference image, (except for possible variations in the labeling text
+ (per CSS2 rules)) after activating the link on the fade-in button the first time and waiting three seconds for the
+ animation to compete. The picture should remain looking the same way indefinitely, until another link is activated.
+
+
+ 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 red square goes from zero to 100% opacity. After the first click on "fade out", the red square goes
+ from red to white. After the second click on "fade in", however, the red square goes from white to red, and then
+ goes back from red to white. This is because of the hyperlinking rules as they relate to resolved start times in
+ the SMIL 2.1 specification.
+
Compare from-to, from-by and by animateColor with values animateColor and animate.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animations. Therefore they have to be the same as the related values animation.
+ Additionally set animations can be replaced by values animations too.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
values="0;a" additive="sum"
+
+
+
set to="a"
+
values="a" additive="replace" accumulate="none"
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. In the color space
+ 0 is represented by black, #000, #000000, rgb(0,0,0) etc. Addition is performed for each
+ of the three components of the color vector separately.)
+
+
+ The from-to, from-by and by animations applied to fill properties
+ of circles are compared with the related values animations including additive and
+ cumulative hehaviour for the stroke of the same circles. Additionally underlying
+ filled larger circles simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The fill of the background circle and stroke and fill of the smaller
+ test circle centered in it are always exactly the same. Therefore if
+ rings in each centered circle system with different color get visible, an error is occured.
+ But each separated circle system representing one of 12 subtests can have another color.
+ Because the fill attribute for animation is always not set and therefore remove,
+ the final value is only that of the set animation, not very interesting for the test.
+
Compare from-to, from-by and by animateMotion with values animateMotion.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateMotion
+ the '0' is no motion or is related to a translation given in coordinates: 0,0.)
+
+
+ The from-to, from-by and by are applied to animateMotion of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The blue paths cover all red paths. Therefore if something
+ red gets visible, an error is occured. Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateMotion, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform rotate (around zero) with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the rotate type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive rotate angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the rotate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform rotate with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the rotate type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive rotate angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the rotate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform scale with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the scale type this is a scaling with 0,0, this means no display if not added to another
+ value. Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive.)
+
+
+ The from-to, from-by and by are applied to animateTransform of the scale type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
+ Compare from-to, from-by and by animateTransform translate with values
+ animateTransform and animateMotion.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the translate type this is a translation given in coordinates: 0,0.)
+
+
+ The from-to, from-by and by are applied to animateTransform of the translate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform skewX with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the skewX type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive skewX angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the skewX type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform skewY with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the skewY type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive skewY angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the skewY type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
+ xml:id or id? Identification of the element, that is target of an animation.
+ For authors it is recommended not to use different for id and xml:id for the same
+ element and not the same value for id in one element and the same value for
+ xml:id in another element. This is done in this document only as a (stupid) test,
+ not as an application.
+
+
+ The main indication for a failed test is the appearance of red or no animation after 2s.
+
+
+ Because for historical reasons, SVG tiny 1.2 has two fragment identifiers.
+ It is recommended, that xml:id is used and not only id. As a consequence
+ it is possible to have two different identifier values for one element.
+ In such a case, id is skipped and only xml:id has to be choosen.
+
+ In this test the height of the blue rectangle is set to another value. This is compared
+ with a set animation of another red rectangle, having the same value for xml:id and
+ id. The blue rectangle has to cover always the red one. If something red is visible,
+ an error is occured.
+
+ Identify the attributeType and the priority of an animation.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ With the top triangle is tested, that the points attribute of a
+ polygon is animated using attributeType auto or XML and
+ is not animated if CSS is used, because there is no CSS property
+ points applicable for the polygon element.
+
+
+ The bottom triangles test the priority for an animation with
+ attributeType CSS or auto over an XML animation, all for the
+ stroke attribute. Even if the attributeType is completely ignored,
+ the priority should still work for the bottom right triangle,
+ because the priority is set here with a later begin.
+
+
+ In all cases the coloring or positioning of elements is choosen in
+ such a way, that normally not visible lower priority or not
+ applicable animations are indicated with a red stroke,
+ higher priority or applicable animations with a blue stroke
+ or an animation in the blue range.
+
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 to big.
+
+ 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.
+
+ Correct timing with begin, end, dur, fill, max.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ Simple from to animations for cx and cy of a blue stroked
+ circle are stopped with max attributes.
+ The gray path gives the correct trajectory.
+ If the red center of the circle becomes visible, an error is
+ occured.
+
+ Correct timing with begin, end, dur, fill, min.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ Simple from to animations for cx and cy of a blue stroked
+ circle are used with begin, dur, end, fill and min attributes and
+ correlated with syncbase values.
+ This is compared with simple animateMotion with the
+ same trajectory and timing.
+ The related red circle is always
+ covered by the blue stroke circle.
+ The gray path gives the correct trajectory.
+
+
+ The test is passed if the blue circle follows the defined path.
+ If part of the red circle becomes visible, the test is failed.
+
+ This test verifies that error handling for the begin attribute is working.
+ An error in the begin-value-list means that the attribute as a whole is in error, and
+ that is the same as if the value was set to 'indefinite'.
+
+
+ There should be three green rects visible. If any of them turns red the test has failed.
+
+ The test is passed if you see a large swirly blue image, outlined in green. Below,
+ two smaller copies also outlined in green. Below that, a thick red outline that does
+ not have an image inside it. All three blue images with green outlines animate over
+ ten seconds, alternating between a blue and a pink image.
+ The animations all finish at the same time and display the pink image thereafter.
+
+
+ This tests the resolving of QNames in the attributeName attribute value. The
+ attribute tested is href, in the XLink namespace.
+
+
+ If an image is displayed on top of the red rectangle, or if the large image is not shown, or a
+ purple image with 'FAIL' is shown rather than blue, the implementation is using magic prefixes
+ and is only looking for the string 'xlink:href' rather than following the Namespaces in
+ XML specification.
+
+
+ If the right-most of the two small images animates but the left-most does not,
+ the implementation is only handling animation elements that are a direct child of
+ the element to be animated, and does not implement animation specified by an
+ XLink href. In that case, the large image will not animate either, but this does
+ not necessarily mean that namespace resolution is incorrect. (It does mean that
+ the test is failed, however).
+
+
+ If the two small images animate correctly but the large one does not, then
+ resolution of QNames in the 'attributeName' attribute is not following the
+ Namespaces in XML specification as required by the SVG specification.
+
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.
+
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.
+
+
+ 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.
+
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.
+
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.
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 red and stroked with blue appear, each with width=100 and height=200.
+ Starting at time 3 seconds and ending at time 6 seconds, the height of the leftmost rectangle decreases from 200
+ to 50. Starting at time 6 seconds and ending at time 9 seconds, the rightmost rectangle decreases from 200 to 50.
+ Annotations on the picture show the correct positions at particular times.
+
+ A yellow happy face should be displayed. The stroke for the smile and yellow circle are both animated, the stroke
+ goes from "#F1E900" to "#FF0000".
+
+ 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 red 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 is composited on top of the animated red
+ square. Then, when you click on "fade out", the red 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 compete. The picture should remain looking the same way indefinitely, until another link is
+ activated.
+
+
+ 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 red square goes from zero to 100% opacity. After the first click on "fade out",
+ the red square goes from 100% to zero opacity. After the second click on "fade in", however, the red square goes
+ from zero to 100% opacity, and then goes back from 100% to zero opacity. This is because of the hyperlinking rules
+ as they relate to resolved start times in the SMIL 2.1 specification.
+
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).
+
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, red, blue, yellow, cyan) in 5 positions (blue and yellow
+ share position) that should be displayed during the test.
+
Tests the animation to and from the degenerate cases of the basic shapes. The shapes are drawn within the black rectangles.
+
+ The rendered picture should match the reference image at the end of the animation, except for possible variations in the
+ labelling text (per CSS2 rules).
+
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 16.2.13 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.
+
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.
+
+ 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.
+
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.
+
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. The static reference image shows the final state of the animation.
+
The purpose of this test is to test animation of the viewBox attribute.
+
+ This file tests animation of the viewBow attribute. 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.
+
+ 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.
+
+ 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.
+
+
+ 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. In most tests, 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.
+
+
+ The following animations should show continuous changes: fill, stroke, stroke-width, stroke-miterlimit,
+ stroke-dashoffset and color. Note that visually, stroke-miterlimit shows a sharp transition, but that is because
+ the miter is cut off when the animated miter limit reaches the test sharp angle's miter value. The stroke-miterlimit
+ value is changed continously but that is not visible in this test.
+
+
The following animations have a discrete behavior: fill-rule, stroke-linecap, stroke-linejoin, display and visibility.
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.
+
+ 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.
+
+
Only the animation of font-size should show a continuous change of the font size.
+
The following animations have a discrete behavior: text-anchor, font-family, font-style, font-weight.
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 SMIL 2.1 are relevant as
+ confirmation of this test:
+
+
+
+
+
+ 10.4.1
+ subsection "Event values"
+ states: "If the Eventbase-element
+ term is missing, the event-base element defaults to the element on
+ which the eventbase timing is specified (the current element)."
+
+
+
+ 3.5.1
+ subsection "The target element"
+ says that the animation target may
+ be defined explicitly through the targetElement="" IDREF or href=""
+ URI, according to the host language. SVG Tiny 1.2 uses the
+ xlink:href="" attribute to specify the target element, so in this
+ test, the animation target is defined through xlink:href="" and the
+ event base per definition is then also this referenced element.
+
+ 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 red 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 "red 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 calcMode="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 red squares which are animated with
+ calcMode="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 red square (LR) is animated just as the LG square but
+ with calcMode="paced". The same applies to the right red square (RR)
+ that has default calcMode ("paced" for animateMotion) compared to the
+ RG square that has calcMode="linear".
+ The calcMode for the scale of RR (and RG) is not important since
+ it's not a value list type of animation.
+
+ 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.
+
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.
+
+ 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.
+
+ 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[.
+
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.
+
+ 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).
+
+ 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).
+
+ 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.
+
+ 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.
+
+ 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> animations are applied. The first <set>
+ element acts directly on 'Basic Shape' elements. 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 'Basic Shape' element. All
+ the <set> elements have a begin attribute set to 0s with an offset of 1s after the 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.
+
+ 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.
+
+ This test validates the operation of the animateTransform's additive behavior, as described in the SVG 1.1
+ specification (see http://www.w3.org/TR/SVG11/animate.html#AnimateTransformElement).
+
+
+ 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
+ roduce 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(1,1)
+ 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 concatenated 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, so is the result of previous animation iterations.
+ Consequently, the transform goes from "skewX(30) scale(1,1)" to "skewX(30) scale(2,2)" for the first iteration
+ and then from "skewX(30) scale(2,2) scale(1,1)" to "skewX(30) scale(2,2) scale(2,2)" for the second iteration.
+
+ 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). The total length along the sx component is 2 + 2 = 4. The total length along the sy component is
+ 0 + 1 = 1. At 0s, the expected transform is scale(1,2). At 1.5s, the expected transform is scale(3,1.5) so that a
+ length of 2 has been run on the sx component and a length of 0.5 has been run on the sy component. At 3s, the
+ expected transform is scale(3,2).
+
+
+ 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).
+
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).
+
Test animation of color keywords that resolve to animatable RGB values.
+
+ Five black squares are shown. After two seconds, all five squares should turn red and then smoothly animate the
+ fill color to green over the next five seconds.
+
All four rectangles at the top must smoothly animate from black to green over 5 seconds.
+
+ During this time the bottom two rectangles must be red. Then, the bottom two rectangles must smoothly animate
+ from green( at five seconds), through khaki (at 7.5 seconds), to yellow (at 10 seconds and above). Colored
+ circles indicate the appropriate colors at these times.
+
+ This test tests fill="freeze" for the case where the duration has been constrained by an 'end' attribute
+ and calcMode="discrete".
+
+
+ The correct behaviour is defined by the SMIL time interval model.
+ Time intervals created by the test case from implicit begin, dur and calcMode discrete:
+
+
+
+ [0;2s) This means time including 0 seconds until (but not including) time 2 seconds
+
+
+ [2s;4s) Time including time 2 seconds until (but not including) time 4 seconds
+
+
+
+ Time intervals created by implicit begin and end:
+
+
+
[0;2s)
+
+
+ Therefore the frozen value will be 74, resulting in the purple fill
+ being in the right rectangle after 0 seconds.
+
+
+ The test has passed if the purple fill is on the right rect only after 0 seconds.
+ Fill must never be set to purple on the left rect, except for before the animation has begun.
+
+ 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.
+
+
+ The second subtest generates a new prefix string, and makes sure it's not equal to the first prefix string.
+ Then an svg fragment is generated as a string, to be parsed by a call to the parseXML method.
+ The 'xlink' prefix is bound to the "http://example.net/bar" namespace, and the generated prefix is bound to the XLink namespace.
+ Similar to the first subtest, the image has two references but only one attribute is actually in the XLink namespace.
+ The fragment is parsed and the result is inserted into the document, which should make the 'image' element visible.
+ If an exception is thrown during the parsing or the insertion of the result output will be shown in the status part of the testcase.
+
+
+ The testcase has passed if after the script execution has taken place these conditions are met:
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ The test will pass if, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+ The reference image displays the file after performing a user agent zoom.
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ An animation is applied to the viewBox attribute.
+ The test will pass if the circles are affected by the viewBox animation and, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ An animation is applied to the content group.
+ The test will pass if only the first circle is affected by the group animation and, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+
+ Animates a rect that has transform="ref" and tests that the animateMotion transform is supplemental.
+ The rects should follow a path diagonally from top-left to bottom-right.
+ The test is passed if a single green rectangle is visible across the screen if a red rectangle is seen
+ the test is failed.
+
Tests the default initial coordinate system used by renderer. Should be 0,0 if not specified.This is illustrated by comparing red boxes that are missing a coordinate or all coordinates with yellow boxes that have the correct coordinates specified. This test should produce three red boxes, with small yellow boxes rendered on top of them. These boxes should be placed along the origin, and x and y axis.
+ This test verifies the implementation of the viewBox and the preserveAspectRatio attribute on the animation element.
+ It exercises the various preserveAspectRatio values and uses a general entity definition in order to make reading of the SVG source easier.
+
+
+ For the test to pass the following criteria should be met:
+
+
+
the xMin* test image left edge should be on the left edge of the blue viewport rect
+
the xMid* test image should be centered in the blue viewport rect
+
the xMax* test image right edge should be on the right edge of the blue viewport rect
+
the yMin* test image top edge should be on the top edge of the blue viewport rect
+
the yMid* test image should be centered in the blue viewport rect
+
the yMax* test image bottom edge should be on the bottom edge of the blue viewport rect
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ The test uses the rect element, the fill color (solid primary colors) and transforms.
+
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ 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.
+
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ This test will check if the various matrix operations work
+
+ Verify the conversion processing of percentage and fraction values relative to object bounding boxes.
+ This is used when defining linear and radial gradients.
+
+
+ The test validates conversion for coordinates, width, height and length. The first test defines two
+ corresponding linear gradients, which specify coordinates using fractions for the first and user
+ coordinates for the second. The second test defines two corresponding radial gradients, which specify
+ a length (radius) using fractions for the first and user space for the second.
+
+
+ The rendered image should match the reference image.
+
+
+ The test also assumes that linear and radial gradients are implemented.
+
+ 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.
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.
+
+
+ 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.
+
This tests the behaviour of CSS font matching based on font-variant attribute.
+
The first line of text should be 'square' 'triangle'. The small-caps font should match the second text element.
+
The second line of text should be 'square' 'triangle'. The second line is used to ensure that the order of font specification does not effect the selection of these fonts.
+
The third line of text should be 'square', 'diamond', 'square', 'diamond'. This shows 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 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 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.
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. An implementation that passes this test should completely fill the cutout, leaving a solid black area (some slight antialiasing effects may remain).
+
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).
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.
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 adavance of 1000. Glyphs have no advance so the 1000 default should be used.
+
The second row shows a layout with a default adavance of 2000. Glyphs have no advance so the 2000 default should be used.
+
The last row shows a layout with a default adavance of 0. Glyphs have a specified advance so the 0 default should be ignored.
+
Reference blue markers show the expected glyph positions.
The first subtest tests the arabic-form attribute and should 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 is the same, but with glyphs for the letter khah. It should match the reference image.
+ 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.
+
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.
+ Test that ligatures are always used, and only used, when they occur before the
+ glyphs for characters they are ligatures of. The word "fjord" is displayed twice;
+ the top one must use the fj ligature and the bottom one must not; the top of the letter f overlaps the
+ dot of the letter i..
+
+
+ Two fonts are defined, almost identical; in one the fj ligature is the
+ first glyph defined, in the second one it is the last glyph.
+
+ Test that ligatures are always used, and only used, when they occur before the
+ glyphs for characters they are ligatures of. The word "fjord" is displayed twice;
+ the lower one must use the fj ligature and the upper one must not; the top of the letter f overlaps the
+ dot of the letter j..
+
+
+ Two fonts are defined, almost identical; in one the fj ligature is
+ defined after "f" but before "j"; in the second one it is the last glyph.
+ This tests longest-substring matching.
+
+ Test that all of the SVG path commands are accepted for defining glyphs. The upper,
+ black text must be a reflection of the lower, colored glyph shapes.
+
+
+ The letter A uses L commands, the letter H uses H and V commands, and
+ the letter B uses cubic beziers. The letter C uses a mix of quadratic beziers and vertical lines.
+
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".
+ This tests a range of values for the 'units per em' attribute. The
+ test is passed if the three letter β are all the same size.
+
+
+ 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.
+
+ 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 in changed to pink,
+ 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.
+
+
+ After clicking at least once on the button, the rendered image should be
+ exactly as the reference image, except for differences in text display.
+
+
This test requires that the user agent support scripting.
+ Testing event bubbling through 'use' elemnt.
+ Moving the mouse over the red 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 red/green rect should hide the rect underneath it again.
+
+ This test contains four cases. The cases must produce the following results for the test to pass.
+ Case 1: On a mouseover event on the top square, all four squares must turn blue.
+ Case 2: On a mouseover event on the top middle square, all four squares must turn blue and a black stroke
+ must appear on the referencing square (element).
+ Case 3: On a mouseover event on the bottom middle square, all four squares must turn blue and a black
+ stroke must appear on the referencing square (element).
+ Case 4: On a mouseover event on the bottom square, all four squares must turn blue, and on a mousedown event
+ a black stroke must appear on the referencing square (element).
+
+
+ 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.
+
Two rectangles and a text element are targets of animateColor elements which begin on focusin and end on focusout.
+
The top-level SVG has a nav-next attribute referencing the text element.
+
When loading the file, initial focus will go to the text element, which should be red.
+
Moving to the next focus will turn the text black while making the blue rectangle green.
+
Moving to the next focus will return the rectangle to blue and make the red rectangle green.
+
Moving to the next focus will return the rectangle to red and turn the text red.
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+ User agent dependent behavior is accepted with all focus tests. Focus can be given immediately to first element in the focus ring,
+ or held in the UA until focus is requested - then focus is given to the first element.
+
Testing the focusable property : its default value and animatability on text and anchor elements.
+
The 1st text is the target of animateColor which starts on focusin, and also has the focusable attribute set to false.
+
The 2nd text does not have a focusable attribute and is not the target of animations which start by focus events.
+
The 3rd text is the target of animateColor which starts on focusin.
+
The 4th text is the target of animateColor which starts on activate.
+
The 5th text is the child of an a element.
+
The 6th text is the child of an a element and also has the focusable attribute set to false.
+
The 7th text has the editable attribute set to simple.
+
The 8th text is the observer DOMFocusIn and DOMFocusOut handlers.
+
The 9th and 10th text elements are used to modify the focusable attribute of the 11th element.
+
+ The 11th text is the target of animateColor which starts on focusin, and also has the focusable attribute set to false.
+ The focusable attribute is modified by activate events on the 9th and 10th elements.
+
+
The 12th and 13th text elements are used to modify the focusable attribute of the 14th element.
+
+ The 14th text is the child of an a element - the a element also has the focusable attribute set to false.
+ The focusable attribute is modified by activate events on the 12th and 13th elements.
+
+
+
The focus ring will look like the following: 3, 4, 5, 7, 8, 9, 10, 12 and 13.
+
Activating the 9th text element will make the 11th element focusable.
+
Activating the 12th text element will make the 14th element focusable.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+ User interaction should navigate focus starting at 1 and go through 5.
+ This test applies only to user agents which locate to focus which is outside of the viewport, and
+ thus the pass criteria for this test is optional.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
This test tests initial focus within the svg document
+
+ The root SVG element has 'focusable' set to 'true'.
+ At start up an animation set element is used to change the poem
+ to red if the root element SVG has focus.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+ Each tspan has an animation that sets the fill to green upon receiving
+ focus. The focus should be moved in turn to "Old", "pond", "frogs",
+ "jumped", "in", "sound", "of" and then "water".
+
+
+ For the test to pass:
+
+
+
+ "Old", "pond", and "sound", "of" and "water" must each turn green
+ respectively when given focus.
+
+
+ "frogs" and "in" must both turn green at the same time when each is
+ given focus.
+
+
+ "jumped" must turn green when given focus and in addition "frogs" and
+ "in" must turn green at the same time due to focus bubbling.
+
+
+
+ In the 2nd phrase there are two nested tspan elements: "jumped" is in
+ the inner tspan, so focus should be received by the outer two words
+ "frogs", "in" and then by the word "jumped".
+
+
+ Focus navigation is user agent dependant but typically is navigated
+ with the keyboard keys.
+
+
+ TAB or arrow keys move the focus while the ENTER key activates the
+ focused element.
+
+ Each tspan has an animation that sets the fill to green upon receiving
+ focus. The focus should be moved in turn to "A", "lonely", "pond", "in",
+ "age-old", "stillness", "sleeps", "Apart,"
+ "unstirred by sound or motion", "... till", "Suddenly",
+ "into", "it", "a", "lithe", "frog" and then "leaps".
+
+
+ For the test to pass:
+
+
+
+ "A", "lonely", "pond", "in", "age-old", "stillness", "sleeps",
+ "Suddenly", "into", "it", "a", "lithe", "frog" and "leaps" must each
+ turn green respectively when given focus.
+
+
+ "Apart" and "... till" must both turn green at the same time when
+ each is given focus.
+
+
+ "unstirred by sound or motion" must turn green when given focus and
+ in addition "Apart" and "... till" must turn green at the same time
+ due to focus bubbling.
+
+
+
+ In the 2nd line there are two nested tspan elements - "unstirred by
+ sound or motion" is in the inner tspan, so focus should be received
+ first by the outer two words "Apart", "till" and then by the inner
+ phrase.
+
+
+ Focus navigation is user agent dependant but typically is navigated with
+ the keyboard keys.
+
+
+ TAB or arrow keys move the focus while the ENTER key activates the
+ focused element.
+
+ The first four occurrences of "focus next" will highlight all four top rects.
+ All four bottom rects should be able to receive the focus and be red when they have focus.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+ Test on focus with a use-element. Focus should move first to the "g" element and then to its children.
+ When it gets to the use-element focus is first set on the use (right column) and then its children.
+
+ 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 that the user agent support scripting.
+ 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. The supplemental
+ text next to the circles describes what should occur.
+
+
This test requires that the user agent support scripting.
+ 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. The supplemental
+ text below the text strings describes what should occur.
+
+
This test requires that the user agent support scripting.
+ 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 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: 1. all the 'O':s in the green rects have green
+ fill 2. there are no red 'O':s visible 3. there are 9 green 'O':s in the first and second rect, 4 in the third rect
+ and 6 in the fourth rect
+
Tests the pointer-events attribute with different 'visible' values
+
+ The test is passed if the following conditions are met:
+ - In the first row of squares, the fill and stroke of squares 1 and 3 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the second row of squares, the fill and stroke of squares 1 and 3 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the third row of squares, the fill only of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fourth row of squares, the stroke only of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fifth row of squares, the fill and stroke of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+
+
+ 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.
+
Tests the pointer-events attribute with different painting values
+
+ The test is passed if the following conditions are met:
+ - In the first row of squares, the fill and stroke of squares 1, 3 and 4 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the second row of squares, the fill only of all squares must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the third row of squares, the stroke only of all must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fourth row of squares, the fill and stroke of all squares must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fifth row of squares, nothing is to trigger on mouseover.
+
+
+ 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.
+
Tests when text is considered hit by pointer-events.
+
+ The test is passed if the following conditions are met:
+ - Any single character in either of the lines of text has 'mouseover' event and the fill of the
+ characters' assocated line of text is set to green.
+ - The fill of the characters' assocated text is set back to black on a 'mouseout' event.
+
+
+ The dy of the glyphs vary quite a bit, so it's easy to tell if an implementation uses the text
+ boundingbox for 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'.
+
+ Verify correct handling by Dynamic (interactive) viewers for the "zoomAndPan" attribute on the 'svg' element. This
+ is the first 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..
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ 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..
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ 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.
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ Test That UTF-16 is supported, as required by the XML specification. If the implementation
+ treats this file as UTF-8 then every second character will be treated as 0. This
+ will typically mean that the file will not load, since the XML elements and attributes
+ will not be reconginized.
+
+ This verifies the capability to handle links into SVG content, using the svgView fragment identifier form.
+ The test is passed if traversing this link shows a portion of the target
+ translated so that the green circle with id "circle-2" is in the top left corner of the viewer
+ frame.
+
+
The initial view of this test contains one green arrow plus labelling text. The arrow is a link - follow the link.
+
+ The arrow links to ./images/linkingCircle-f.svg#svgView(transform(translate(64,227)))".
+
+ 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'. Both must be working links.
+
+ Verify target attribute has priority over xlink attribute on the 'a' element. The destination expressed by
+ "xlink:href=" is overridden when 'target' is specified on the 'a' element.
+
+
+ For the test to pass; each arrow in the test, when clicked, must show the image of the
+ linkingToc-t.svg in a new frame.
+
+
+ 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.
+
+
+ This test was modified and renamed from linking-a-07-t.svg.
+
+ Testing Links to external and internal 'svgView' with Transforms.
+
+
+ The first part of the test is passed if the rect links on the top line go to the linking-frag-202-t.svg file and
+ adjust the resulting view according to their respective text;
+ - The rect with 'Rotate' must link to the linking-frag-202-t.svg file and rotate resulting view
+ - The rect with 'Shift' must link to the linking-frag-202-t.svg file and shitf the resulting view
+ - The rect with 'Scale' must link to the linking-frag-202-t.svg file and scale the resulting view
+ - The rect with 'skewX' must link to the linking-frag-202-t.svg file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to the linking-frag-202-t.svg file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to the linking-frag-202-t.svg file and restore the view to an identity transformation.
+
+
+ The second part of the test is passed if the rect links on the bottom line link to this file and adjust the
+ resulting view according to their respective text;
+ - The rect with 'Rotate' must link to this file and rotate resulting view
+ - The rect with 'Shift' must link to this file and shitf the resulting view
+ - The rect with 'Scale' must link to this file and scale the resulting view
+ - The rect with 'skewX' must link to this file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to this file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to this file and restore the view to an identity transformation.
+
+ Testing Links to external and internal 'svgView' with Transforms.
+
+
+ The first part of the test is passed if the rect links on the top line go to the linking-frag-202-t.svg file and
+ adjust the resulting view according to their respective text;
+ - The rect with 'Rotate' must link to the linking-frag-201-t.svg file and rotate resulting view
+ - The rect with 'Shift' must link to the linking-frag-201-t.svg file and shitf the resulting view
+ - The rect with 'Scale' must link to the linking-frag-201-t.svg file and scale the resulting view
+ - The rect with 'skewX' must link to the linking-frag-201-t.svg file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to the linking-frag-201-t.svg file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to the linking-frag-201-t.svg file and restore the view to an identity transformation.
+
+
+ The second part of the test is passed if the rect links on the bottom line link to this file and adjust the
+ resulting view according to their respective text;
+ - The rect with 'Rotate' must link to this file and rotate resulting view
+ - The rect with 'Shift' must link to this file and shitf the resulting view
+ - The rect with 'Scale' must link to this file and scale the resulting view
+ - The rect with 'skewX' must link to this file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to this file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to this file and restore the view to an identity transformation.
+
+ Activating the link on the red circle should pan the viewport to
+ center the orange circle (which is initially located outside the viewport).
+
+
+ Activating the link on the orange circle should pan the viewport to
+ center the yellow circle, and zoom out to show the entire yellow circle.
+
+
+ Activating the link on the yellow circle should pan the viewport to center
+ the red circle, but remain at the existing zoom level (i.e. not zoom in).
+
+
+ Note that the visual effect is only part of the pass criteria, and that the
+ changes in the viewport should be made using currentTranslate and currentScale,
+ not the viewBox; this part is currently not tested.
+
+ Tests various external fragments with 'use' element:
+ fill, stroke, text, group, multiple levels, name clash and circular references
+
+
+ SVG fragments defined in an external file are invoked with the 'use' element.
+ The test is passed if the following objects are rendered:
+ - Right top; square with a horizontal gradient fill from orange to yellow, diagonal gradient stroke from blue to pink
+ - Right middle top; square with a diagonal gradient fill from blue to pink, horizontal gradient stroke from orange to yellow
+ - Right middle bottom; the letters ABC in an SVG font
+ - Right bottom; the English alphabet a to j in the shape of a square
+ - Left Top; square with horizontal gradient fill from orange to yellow, and 3 circles all with a blue to red gradient fill
+ running diagonally inside the square
+ - Left middle top; green square with a yellow circle in the middle
+ - Left middle bottom; red square
+ - Left bottom; two identical squares with light blue fill.
+
+ Tests SVG fragments defined in an external file are invoked with the 'use' element.
+ The test is passed if the following objects are rendered:
+ - Right top; square with red fill and blue stroke
+ - Right middle; square with black fill
+ - Right bottom; the letters 'A' in blue, 'B' in red, 'C' in blue
+ - Left top; square with red fill and a circle in the middle with a blue fill
+ - Left middle; square with green fill
+ - Left bottom; square with green transparent fill with an overlapping circle with a blue transparent fill.
+
+ Tests a 'use' element referencing an 'image' element and an 'a' element with xml:base.
+
+
+ The test is passed if two identical images are displayed.
+
+
+ The image on the right is located in the images directory (../images/) while the
+ image on the left is located in image2 directory (../images/image2). The image on
+ the right is specified in the svglib3.svg file using an 'image' element. The image
+ on the left is specified in the svglib3.svg using an 'a' element. The 'a' element
+ contains a group around it that specifies the image2 directory using 'xml:base'.
+
+ Tests that values for the xlink role and arcrole attributes are stored in the DOM.
+ The test is passed if the raster image and the vector image both have dark
+ green and light green borders, same as the reference image.
+
+
+ The values for role and arcrole are based on the RDDL specifications of
+ well known link natures (role) and well known link purposes (arcrole). Roles uses the namespace URI (for XML content types) or the canonical IANA URI of the media type registration (for non-XML content).
+
+
+ A uDOM script reads the values of the xlink role and arcrole attributes,
+ checks that they are the correct values, and sets the fill colour of some rectangles
+ from shades of red (meaning incorrect) to shades of green (meaning correct).
+
+ 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.
+
+
+ There is a link on the triangle, pointing to an external SVG file, which is in the images directory (../images/).
+ The target file contains SVG 'text' elements which comprise a TOC and brief description of all of the SVG Tiny 1.2
+ 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 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. The results of executing the link
+ should be identical to executing the first (topmost) link of linking-uri-01-t.
+
+
+ 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.
+
Testing 'audio' Element with the 'audio-level' Attribute
+
+ The scale at the bottom of the slide uses a 'set' element to modify the 'audio-level' on the sample audio element.
+ The 'audio' element can be triggered by activating the current focus.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Test on audio level animation. audio-level is animated to many values between 0 and 1. The volume dial graphic animates to show the expected relative volume.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
+ Test on audio-level inheritance in several child elements. audio-level on the first element is 0.5. audio-level on the second sound is halved to 0.25. audio-level on the third and fourth sounds are halved agian to 0.125 and 0.0625 respectively.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
This test validates the Animation element with external references.
+
There are five references. Each one is a separate file.
+
The time scale loops from 0 to 10 seconds - the vertical red line pans from left to right.
+
In the first example the two rectangles are set to rotate 90 degrees alternatively.
+
In the second case the circle has focus. Since this is the only item that has focus it can not loose focus and should remain red even when an attempt is made to change focus.
+
The third example has a circle that is set to change to red on a mouseover event. On mouseout the circle should change back to grey.
+
The forth example invokes the same external file twice - two squares with a gradiant should be rotating in sync continously.
+
The last case calls an animation that should display a blue square with five gradiant circles all rotating continously.
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+ This is one of a series of test slides that exercise all the permitted values for the 'preserveAspectRatio'
+ attribute values.
+
+
+ The external resource referenced by the animation element has a viewport-fill defined with a solid color.
+ This should be ignored and the local color of blue should be used.
+
+
A semi-transparent yellow rectangle should be animating within each viewport.
This slide tests the 'viewport-fill' and 'viewport-fill-opacity' attributes defined locally.
+
+ The externally resource referenced by the animation element has a 'viewport-fill' defined with a black to yellow gradient.
+ This should be ignored and the local definitions should be used - red for the left, blue for the middle and semi-transparent black for the right.
+
+
A semi-transparent yellow rectangle should be animating within each viewport.
This slide applies different transformations to the animation element.
+
+ The externally resource referenced by the animation element has a viewport-fill defined with a black to yellow gradient.
+ This should be ignored and over ridden by the color aqua.
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+ This slide tests independent primary documents. Each referenced primary document has a separate script context.
+ This test is only applicable if application/ecmascript is available.
+
+
Four animation elements reference a document which has an activate handler on a circle.
+
Focus should start on the top-left circle and move to top-right, bottom-left and bottom-right.
+
Activating the circle will toggle its radius size, but for the currently focused circle only.
+
This is due to the fact that each primary document has a separate script context.
+ Animation Element with animating xlink:href
+ This slide tests animating the xlink:href attribute of animation elements
+ Every 2.5 seconds the animation will display a circle instead of a timeline.
+ The circle is focusable and as such should receive the focus and turn red.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
+ Tests the audio-level property for nested audio elements and clamping
+ of audio-level.
+
+
+ The test consists of 6 subtests. When each audio sub-test is executed a
+ corresponding rect will turn blue. When each audio sub-test is
+ finished the corresponding rect will turn gray again. For this test to pass, all subtests must
+ have a green rectangle next to them.
+
+ The audio must also be heard to pass this test. If the user agent does not support the WAV media format, the test is still a pass.
+
+
+ The 1st subtest has an audio-level = 1. To pass this subtest the audio
+ must be played at the system volume.
+
+
+ The 2nd subtest has an audio-level = 2. To pass this subtest the audio
+ must be played at the system volume.
+
+
+ The 3rd subtest has an audio element with an audio-level = 2. Within
+ the audio element there is a child audio element with an
+ audio-level = 0.5. The source audio is the child audio element. To pass
+ this subtest the audio must be played at 1/2 the system volume.
+
+
+ The 4th subtest has an audio element with an audio-level = 0.5. Within
+ the audio element there is a child audio element with an
+ audio-level = 2. The source audio is the child audio element. To pass
+ this subtest the audio must be played at 1/2 the system volume.
+
+
+ The 5th subtest has three audio elements. The first audio element has
+ an audio-level = 0.5 and is the parent audio element. The second audio
+ element has an audio-level = 2 and is a child to the first audio
+ element. The third audio element has an audio-level = 0.5 and is a
+ child to the second audio element. The source audio is third audio
+ element. To pass this subtest the audio must be played at 1/4 the
+ system volume.
+
+
+ The 6th subtest has four audio elements. The first audio element has
+ an audio-level = to the audio level of the 3rd audio element (0.5). The
+ second audio element references an audio element from another subtest
+ with an audio-level of 2. The second audio element is a child of the
+ first audio element. The third audio element has an audio-level = 0.5
+ and is a child of the second audio element. The fourth audio element
+ has an audio-level of 2 and is a child of the third audio element. The
+ source audio is the fourth audio element. To pass this subtest the
+ audio must be played at 1/4 the system volume.
+
+ This file tests the transformBehavior attribute set to 'pinned'.
+ The video should always overlap the two crossing lines, even during zoom/pan, proving it
+ is always rendered at its native resolution, and pinned at its the center (the blue dot).
+ If the video is rendered inside the small rotated rectangle, it means the transformBehavior
+ attribute is not applied / supported.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'none' on a video element. The width of
+ the video element has been made larger than the subsequent
+ preserveAspectRatio tets.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMin meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMidYMid meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMaxYMax meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMin meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMid meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMax meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'none' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Colored circles should maintain rendering order as marked on them.
+ Video is 10 seconds in length and should freeze at the end. The circles should continue to animate indefinitely
+ Bottom frame contains a jpeg reference image. The jpeg image is rendering order is on the top and the video
+ rendering order is on the bottom.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the case when type is set to 'rotate' in animateTransform. The test
+ contains two objects; one video and one image. Both are rotated about a
+ point definied by the center of the black circle. The video will rotate
+ clockwise, and the image will rotate anti-clockwise.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the rendering order of Video with other objects. Test contains
+ a video element with a polygon rendered over the top. The polygon has
+ a solid fill; no video should be visible through the polygon.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing and xlink href is changed the stream should change. The
+ new stream should start playing at the same position as the reference video, if the media play time cannot be controlled. Otherwise the media time will be re-started.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the different transformBehavior values on video.
+ Pinned, Pinned90, Pinned180, Pinned270
+
+
+ The 1st video element has transformBehavior set to pinned and is displayed in the top-left of a 4-video box.
+
+
+ The 2nd video element has transformBehavior set to pinned90 and is displayed in the top-right of a 4-video box.
+
+
+ The 3rd video element has transformBehavior set to pinned180 and is displayed in the bottom-left of a 4-video box.
+
+
+ The 4th video element has transformBehavior set to pinned270 and is displayed in the bottom-right of a 4-video box.
+
+
+ There are 4 green-stroked rectangles indicating the expected position and orientation, but not size.
+
+
+ The videos should display with the appropriate rotation, centered on the green rectangles but not bound by them in any way, since determining the exact pixel size of the rectangles is not possible.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ When no video element is displayable (visibility is hidden or display is none of the use element),
+ audio level should be set to 0 and video should not be rendered.
+ -Video1 should be displayed between 0-4s, not rendered between 4-6 s and displayed between 6-8s.
+ -Video2 should be displayed between 0-2s, not rendered between 2-6 s and displayed between 6-8s.
+ -The audio of the video should be muted between 4-6s as no video is then rendered.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing and it is repositioned by removing it's corresponding use
+ from tree and then reinserting it in tree the video should continue playing but change position
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing when it is removed from document tree
+ it should continue playing when re-inserted in tree.
+ - The video should change position at 2 seconds but continue playing.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ When xlink:href is animated on a use element between two different video elements, the
+ displayed video should change and it should play at the current time.
+ -video1 should be displayed between 0-2 and 4-6s and video2 between 2-4s.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
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 DTD, but is well formed.
+
The diagram on the table is a visualization of the RDF metadata in the graphic.
+
The rendered result should match the reference image and there should be no error messages or warnings
+ The purpose of this test is to determine if an application has the basic capability to process the 'color' property.
+ There are three subtests.
+
+
+ The first subtest, to the top left, is passed if the circle has a red fill. The second subtest, to the top right, is
+ passed if the circle has a red stroke. The third subtest shows a rectangle with a gradient fill, which has three stops.
+ The subtest is passed if central stop is red, fading off to blue to the left and pale yellow to the right.
+
+ Purpose of test is to determine 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 shapes in the group uses
+ one of the syntactical forms and all in the group should be identical in color.
+
+
+ The first row uses five forms - 3-digit hex, 6-digit hex, rbg() integer form, rgb() percentage form, and named
+ ('HTML') 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.
+
+ Tests system colors. 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. The user agent should render the rectangle with a RED fill.
+ This tests inheritance of three properties: "fill", "stroke" and "stroke-width". There is a "g" element (id="G1")
+ which sets fill="blue", stroke="red", 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="red" 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="red"
+ and stroke-width="5".
+
+
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.
+
+ 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.
+
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, red.
+ 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.
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling
+ text (per 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, red. 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
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
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 red (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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
Test that the viewer has basic capability to handle linear gradients on fills and stroke of 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 red (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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ Test that the viewer can handle the gradientUnits attribute on linear gradients. It tests the following values of
+ gradientUnits : default (objectBoundingBox), specifying objectBoundingBox, and specifying 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 (red). 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 red (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 red (left) to blue
+ (right).
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
+ 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 (red). 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 red (center) to blue (edge).
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
+ Test linear and radial gradient defaults. Includes testing defaults for linear grad x1,y1,y2 = 0.0, x2 = 1.0 and
+ testing defaults for radial grad cx,cy,r = 0.5
+
+
+ The top rectangle must be blue at the lefthand side and red at the right hand side, fading smoothly accross. The
+ lower rectangle must be red 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.
+
+
+ The top rectangle must have a red outline and no fill. The middle rectangle must have a solid black fill. The
+ lower rectangle must have a yellow to red 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.12.
+
+
+ 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. The result should be that the top-left rectangle is filled with a gradient from green to red since the stop-color is inherited from the location of the gradient definition.
+
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. The result should be that the top-right rectangle filled in green with a gradient 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. The result should be that the lower-left rectangle filled with a gradient going from fully-opaque green to fully-opaque black.
+
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 that the lower-right rectangle filled with a gradient going from fully-opaque green to fully-opaque yellow.
+ This test shows rectangles filled with animated gradient which inherits some of their properties: stop-color, stop-opacity.
+ The correct result must show: - the top-left rectangle filled initially with a linear green-to-red gradient and turning into
+ a solid green color after 5s. - the top-right rectangle filled initially with a green gradient fully opaque on the left and
+ half transparent on the right, but after 5s the rectangle must be filled with a fully opaque solid green. - the bottom-left
+ rectangle filled with a static green-to-black opaque gradient - the bottom-right rectangle initially filled with a green-to-yellow
+ fully-opaque gradient animated and turning into a fully-opaque green solid color. Animations numbered a4 to a7 must have no impact.
+
+ A linearGradient is defined with a stop-opacity of 0 that is also animated from 0 to 1 (clear to solid).
+ The yellow star must initially be visible through the gradient. After 5 seconds most of the start must
+ be covered by the linearGradient.
+
+ There are three lines of text. For this test to pass each line of text must have the same gradient
+ from green to blue all set to a 'stop-opacity' of 0.4 . The reference rect at the bottom has a
+ similar gradient but with 'stop-opacity set to 1. The text of the poem should be lighter than
+ the reference line.
+
+ Test on gradients with gradientUnits set. There are two rects, one using a gradient with gradientUnits set to "objectBoundingBox" and one with "userSpaceOnUse". Both rects contain a smaller rect to visualise the use of gradientUnits.
+ In the top rect, the small one should appear as a smaller version of the big rect.
+ In the bottom rect, the small one should just as a "frame" on the big rect.
+
+ Gradient with no stop-elements. The painting shall occur as if 'none' were specified
+ as the paint style, thus allowing the pale blue rectangle to be seen inside the square.
+
Testing non-scaling-stroke on basic shapes and text.
+
The bottom shapes - triangle and oval - also have a gradient applied to the outline stroke.
+
+ At the start the two sets of shapes may not appear identical - depending on viewport size.
+ As the geometric shapes are zoomed out the outline strokes of the left-hand set of shapes
+ should remain fixed while the strokes of the right-hand set should scale in proportion to the shapes.
+
+ Test solidColor animation. Animates solid-color and solid-opacity on two rects.
+
+
+ The test is passed if the following objects are displayed:
+ Rect 1
+ - Fill: blue animated to red, opacity 0 animated to 1
+ - Stroke: none
+
+ Rect 2 (roated -30 degrees)
+ - Fill: none
+ - Stroke: red animated to yellow, opacity 1 animated to 0
+
+
+ One rect animates its fill from blue to red over 3 seconds and has its solid-opacity animated from 0 to 1 over 5 seconds.
+ The other rect (no fill and rotated -30) has its stroke animated from red to yellow over 3s and solid-opacity from 1 to 0 over 5 seconds.
+
+ 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 red stroke.
+
+
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", stroke="red",
+ "font-family" (Arial) and "font-size" attributes.
+
+ Verify the basic capability to handle the stroke properties ("stroke", "stroke-width", "stroke-linejoin") in
+ combination with the "rect" element. The pair should be rendered as two red rectangles without an interior fill.
+ The upper rectangle should have a stroke width of 5 with sharp corners. The lower rectangle should have a stroke
+ width of 5 with round corners.
+
+
+ The test uses the "rect" element, as well as basic "fill" (solid primary colors), "stroke", stroke="red"
+ stroke-width="10" stroke-linejoin="round", "font-family" (Arial) and "font-size" properties.
+
+ Verify the basic capability to handle the stroke properties ("stroke", "stroke-width" "stroke-linejoin", "stroke-linecap",
+ "stroke-miter") in combination with straight-line path commands. The pair should be rendered as as two red line segments.
+ The upper segment should have round end caps. The lower segment should be chopped off where the two line segments meet.
+
+
+ The test uses the "path" element, as well as basic "fill" (solid primary colors), "stroke", "stroke-width",
+ "stroke-linejoin", "stroke-linecap", "stroke-miter", "font-family" (Arial) and "font-size" properties.
+
+ Verify the "stroke-dasharray" and "stroke-dashoffset" properties. Two lines are drawn, one red 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 help show this, the black line has a "stroke-dashoffset" so that the dashes in the black
+ line match up with the gaps in the red line.
+
+
+ The test uses the "path" element, "stroke", "stroke-width", "stroke-dasharray" and "stroke-dashoffset", "font-family"
+ (Arial) and "font-size" properties.
+
+ User agents may render graphical primitives with different levels of accurancy.
+ This test is aimed at determining how does a UA render thin strokes.
+
+
+ The test file contains a number of vertical and horizontal lines.
+ The stroke width of the vertical lines are increasing from left to right.
+ The stroke width of the horizontal lines are increasing from top to bottom.
+ The user should be able to see a smooth stroke width increment for the vertical and horizontal lines.
+
+ 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 red 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. Thus, 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.
+
+ Stroking for circle, large stroke-width, small r.
+
+
+ The main indication for a failed test is the appearence of something red.
+ A second indication is a thin white line inside a blue area.
+
+
+ For smaller circles the radius gets smaller than the half stroke-width, therefore the fill is not
+ visible anymore for them. Only the animated circle at the beginning and the next circle
+ on its right have a visible fill.
+
+
+ To test the correct rendering, the blue circles cover always red filled circles without a stroke.
+ Additionally the size of the circles is given with a thin white stroke on top. If something
+ red gets visible or blue parts of the stroke of the circle are outside of the related white
+ stroked circle, an error is occured. If the circles are not displayed as circles with an accuracy of
+ one device pixel, an error is occured too.
+
+ Direction of stroke-dasharray and stroke-dashoffset for basic shapes.
+
+
+ The main indication for a failed test is the appearence of a blue path on
+ a white background area. It is passed, if all blue paths are on a gray background area.
+
+
+ stroke-dasharray and stroke-dashoffset are tested on basic shapes circle, ellipse, rectangle,
+ rectangle with rounded corners, line, polyline and polygon. The test is sensitive to the
+ direction of stroke-dasharray and stroke-dashoffset and on the starting point on the basic
+ shape.
+
+
+ The dashes are positioned correctly, if they are only on a gray background area.
+ If there are dashes on a white background, this is an indication for an error.
+ Additional information given in the elements title and desc for the related subtest
+ may help to identify the tested shape and property combination and the error,
+ if there is one.
+
+ The main indication for a failed test is the appearence of something red.
+
+
+ stroke-linejoin is tested, using a comparsion with filled or stroked paths or shapes with the same appearance.
+ This is tested for different three miter angles for the values round, miter and bevel, for each of them one with
+ test path on top of the comparsion shapes and one with the path below.
+
+ The four paths top right test the inheritance either for the value explicitely set to 'inherit' or a missing stroke-linejoin property.
+
+
+
+ The top is always blue. If something
+ red gets visible, an error is occured.
+
+ Stroking for subpaths with path length zero, depending on stroke-linecap.
+
+
+ The main indication for a failed test is the appearence of something red
+ (this simple indication may fail itself, if the viewer does not support stroke-linecap).
+
+
+ Several paths containing a subpath with length zero are
+ stroked and some of them animated.
+
+
+ The zero length subpath is placed between two
+ other subpaths of finite length or before or after a
+ subpath of finite length or in one case the path consists of two
+ subpaths of length zero.
+ The behaviour is checked for stroke-linecap round,
+ square (subpath visible) and bevel (subpath not visible)
+ on the left.
+
+
+ On the right the behaviour is tested with simple
+ animations to check the correct alignment
+ or shrinking to zero length.
+ stroke-linecap is animated between round or square too
+ for some of them.
+
+
+ The behaviour is compared with similar paths with a
+ subpath of a very small length. Because the red stroked
+ paths have a slightly smaller stroke, they are always covered
+ by blue paths.
+ If something red gets visible, an error is occured.
+
+ Centering of stroke on the outline of rectangles.
+
+
+ The main indication for a failed test is the appearence of something red.
+
+
+ The width and position of the stroke centered on the outline of a rectangle is tested with four stroked rectangles,
+ one is the thin black stroked test frame rectangle, the second one a large blue rectangle, the third a rectangle
+ with rounded corners, looking like a circle and the fourth a small square.
+
+
+ The correct position is tested by a comparsion with several filled rectangles in the background or in the fourth case
+ covering the test square completely. The parts of the background covered with the blue test rectangles are filled red,
+ respectively the test square is stroked red too.
+ Therefore if something red gets visible, the position of the stroke of
+ the related test rectangle is wrong.
+
+
+ According to the conformance criteria all visual rendering should be accurate to within one px unit to the mathematically
+ correct result. Therefore possible residuals from the red background parts have to be in this
+ range of accuracy to pass the test.
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'silver'.
+ At the start the entire background should be a light grey.This should then change to aqua.
+ There are two reference squares in the center - silver and aqua.
+
+ Test on viewport-fill and viewport-fill-opacity.
+ Animates viewport-fill from yellow to blue over one second, and animates viewport-fill-opacity from 1.0 to 0.5.
+
+ Test on viewport-fill and viewport-fill-opacity. viewport-fill-opacity is set to 0.0 so the set viewport-fill
+ color should not be visible. The image has its viewport-fill set to "inherit" and viewport-fill-opacity to 1.0
+ so the image should show with a yellow viewport-fill and full opacity.
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'yellow'
+ with a 'viewport-fill-opacity' of 1. At the start the entire background should be solid yellow.
+ This should then change to a pale bluish gray. There are two reference squares in the center - solid yellow - to
+ match the background at the start and a pale yellow that should match the backgound after a few seconds.
+
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'path' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'rect' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
Verifies that shapes can be filled, stroked and the order of filling and stroking.
+
There is one pair of octagons. These are filled plus stroked.
+
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'rect' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). It also validates basic Shape, Image and text rendering.
+
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" should show through the rectangle and none of the rectangle should show through the image.
+
Prerequisites: the test assumes proper handling of the fill stroke, stroke-width, font-size rendering properties. It uses the rect, line, text and image elements, as well as all the elements required for the test template. To ensure that the text string is overlapped by the other elements and to avoid a dependency on system fonts, an SVG font is used.
+
The rendered image should match the reference image exactly.
Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). It also validates basic Shape, Image and text rendering.
+
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" should show through the rectangle and none of the rectangle should show through the image.
+
Prerequisites: the test assumes proper handling of the fill stroke, stroke-width, font-size rendering properties. It uses the rect, line, text and image elements, as well as all the elements required for the test template. To ensure that the text string is overlapped by the other elements and to avoid a dependency on system fonts, an SVG font is used.
+
The rendered image should match the reference image exactly.
+ Test that when a script element has both an xlink:href attribute and child character data,
+ the executable content for the script is retrieved from the IRI of the xlink:href attribute,
+ and the child content is not added to the scripting context.
+
+
+ The test loads an external script resource, which if executed sets the fill or the blue rect to green.
+ If the child content is executed the fill will be set to red and an alert will be displayed.
+
+
+ The test has passed if the rect is green after script execution has taken place and there has been no
+ alert displayed.
+
+ Test that scripts are not processed until added to the DOM tree. Also test that a function defined in a script
+ element can be called from a handler element in the same scripting context.
+
+
+ When the blue rect is clicked a script element is created. The script to be run must not be processed until
+ the script element is added to the tree. If it is processed before added to the tree, the rect that is
+ inserted into the document will be red. If not, then it will be green.
+
+
+ The test has passed if after clicking the blue rect a green rect is displayed in its place.
+
+ The test consists of 8 subtests, each testing requirements from the script processing section.
+ When the test is first loaded it shows 8 red circles. After the scripts have been executed the circles should all be green.
+
+
+ The test has passed if all 8 circles are green after the script processing has taken place.
+
Tests basic mouse event handler and DOM manipulation through ECMA script binding.
+
The test uses ECMA Script 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
+ This test tests the assertion from the Namespaces in XML specification,
+ "The namespace prefix, unless it is xml or xmlns, MUST have been declared
+ in a namespace declaration attribute in either the start-tag of the element
+ where the prefix is used or in an ancestor element (i.e. an element in whose content the prefixed markup occurs)."
+ The root element doesn't declare the XML Event namespace for the prefix "ev".
+
+
+ The test has passed if handlers are implemented (the handler with xml:id="passhandler" has run)
+ but the handler with xml:id="failhandler" has not run.
+ If the handler is run then the text in the testcase will show "Test failed: magic prefixes!".
+ If handlers are not implemented at all, the testcase will show "Test failed: handlers not implemented."
+
+
+ The test is also passed if the implementation states somehow that the test case is not namespace
+ well formed (by overlaying it on the image, informing the user in the error console, not
+ showing the document at all, etc.).
+
+ This test tests that a handler is not found when the 'handler' attribute contains
+ an IDREF. The test fails if a red rectangle covers the text content area or the string "Test failed" is displayed.
+
+ This test tests that an element with the name 'listener' is not interpreted as an svg element,
+ and that it's not the same as an element named 'listener' in the XML Events namespace.
+
+
+ The test has passed if handlers are implemented (the handler with xml:id="passhandler" has run)
+ but the handler with xml:id="failhandler" has not run.
+
+ If the handler is run then the text in the testcase will show "Test failed: 'listener' is not an svg element.".
+
+ The pass condition is indicated by two rects that must both be green after running the test, if
+ either of the rects is red then the test has failed.
+
+ This test tests the 'propagate' and 'defaultAction' attributes on the XML Event 'listener' element.
+
+
+ The test has passed if after clicking the each of the blue rects they both turn green and show the text "Passed",
+ and that clicking the leftmost rect doesn't traverse the link. If any of the rects are blue or red after clicking
+ them the test has failed.
+
Tests the degenerate cases of the basic shapes. The shapes are positioned within the black rectangles.
+
None of the shapes should be visible (each of the ten black rectangles should be empty). The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ For this test to pass the following lines must be drawn:
+ - Green line across the top from 480,0 to 0,0
+ - Red line across the left hand side from 0,0 to 0,360
+ - Blue line across the bottom from 480,360 to 0,360
+ - Purple line across the test from 480,85 to 0,0
+ - Fuchsia line across the test from 0,0 to 480,170
+ - Aqua line across the test from 0,360 to 480,170
+ - Teal line across the test from 480,256 to 0,360
+
+
+ If the x1, x2, y1, or y2 attribute is not specified the effect is as if
+ a value of "0" were specified.
+
+
+ The rendered picture should match the reference image, except for possible
+ variations in the labelling text (per CSS2 rules).
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+
Testing the default attributes on the rect element. There should be four rectangles. One should be placed on the left (default x), one on the top (default y). Two rounded rectangles should appear where rx and ry are of the same value (one of the two had been omitted).
Testing the correct stroking of the rect element. The blue lines indicate where a dash or gap should start and end. For the test to pass, it has to match the reference image.
+ Tests that the value of the 'class' attribute is included in the DOM,
+ including space-separated values, and values with extraneous spaces.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing three green circles, with text below each circle
+ reflecting the normalized space-separated values for the class of that
+ circle. The leftmost circle has the value "foo", the middle circle has
+ the value "bar baz", and the rightmost circle has the value
+ " funky spacing ", normalized to "funky spacing". If any of the
+ circles are red, the test has failed.
+
+ Tests that reading of IDs and modification of id and xml:id is conformant to the SVG and xml:id specifications. The test passes if four green circles are shown.
+
+
+ The first circle has an id only; the second, xml:id only. The third circle has both, with the same values; and the fourth has both, with different values. All four circles have a red fill; on loading the document, a script
+ gets each of the circles by its ID and then sets the fill to green. Lastly, the script attempts
+ to get the fourth circle by ID, using the value of the id attribute; this must fail. If the fourth
+ circle is dark red, the implementation is not giving priority to the value of xml:id.
+
This test evaluates a switch statement. The result should be a green rectangle in the lower left quarter of the output window.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
This tests ability to use the 'systemLanguage' as a test attribute within a switch element. To pass, either
+
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 requiredFeature. If a red rectangle with white text 'FAIL' is
+ displayed, the test fails. Otherwise, if a green rectangle is displayed in the lower part with the text '',
+ the test is passed.
+
+
+ The red rectangle and the white text each require a non-existent feature; the test attribute will thus
+ evaluate to false and neither element will be rendered by a compliant implementation.
+
+
+ The upper subtest is informative; it distinguishes between a purely SVG Tiny 1.2
+ implementation and others which also implement more (eg SVG Full 1.1, or
+ some profile of SVG 1.2 greater than Tiny). The results of this subtest
+ does not affect the pass/fail criteria.
+
+
+ Because SVG Tiny does not support for SVG Full DOM, an SVG Tiny implementation which
+ does not support other SVG Profiles should show a rectangle
+ like this.
+ If the application supports the DOM, meaning that it does more than just SVG Tiny, it
+ should show a rectangle like this.
+ Either result is a pass.
+
+
+ The lower subtest,has another switch. The first child has a requiredFeature
+ set to http://www.w3.org/TR/SVG11/feature#BasicText which all SVG Tiny implementations
+ must support. If the application does, the lower rectangle is displayed in green
+ like this. Otherwise, a red rectangle
+ indicates that the text has failed.
+
+ A series of switches are used to determine which Internet Media types ('MIME types')
+ are supported, using the 'requiredFormats' attribute,
+ displaying a 'yes' or 'no' as appropriate. The test is passed if there is text in
+ the second row of each column, and that text is only
+ green (in the top table)
+ or blueviolet (in the bottom table);
+ no red text is displayed.
+
+
+ The SVG Tiny 1.2 specification mandates certain formats, so these must be supported:
+ image/jpeg, image/png, image/svg+xml.
+ It is an error not to support them, therefore 'yes' is green and 'no' is red.
+
+
+ This test also checks for support of Internet Media types which are
+ assumed to not exist and are unlikely to ever be registered: garbage/garbage.
+ Therefore, 'yes' is red and 'no' is green.
+
+
+ Lastly, most media types are optional. For example, image/tiff may be
+ supported but support is not mandated by the SVG Tiny 1.2 specification.
+ The second table examines these optional formats.
+ Both 'yes' and 'no' are displayed in blueviolet. Whether the particular Internet Media type
+ is supported or not does not affect whether the test is passed or failed, but does provide useful
+ information about the optional capabilities of a particular implementation.
+
+ This test evaluates the effects of the 'display' or 'visibility'
+ attributes on a switch statement. The result should be a green circle
+ in the center of the output window.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing a green circle in the center of the image. If a
+ gray rectangle is visible, the test cannot be evaluated because the
+ 'display' attribute is not supported. If a blue rectangle is visible,
+ the test cannot be evaluated because the 'visibility' attribute is not
+ supported. If a red rectangle with a gray stroke is visible, the test
+ is failed because the switch is affected by the 'display' attribute.
+ If a red rectangle with a black stroke is visible, the test is failed
+ because the switch is affected by the 'display' attribute.
+
+
+ The test uses the 'rect' and 'circle' elements, as well as basic fill
+ (solid primary colors), stroke (black or gray 2-pixel lines), and the
+ 'display' and 'visibility' attributes.
+
+ This test evaluates the effects of the switch statement on referencing
+ content such as gradients or elements. The result should be a yellow
+ rectangle in the center of the output window, with green circles in
+ three of the corners of the rectangle.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing three circles, one solid green circle in upper
+ right corner of the rectangle, and a circle with a green gradient in
+ each of the bottom corners of the rectangle. If a red or black circle
+ is visible in the upper left corner of the rectangle, the test cannot
+ be evaluated because the 'switch' is not correctly supported. If any of
+ the upper-right or lower circles is not visible, or does not have the
+ correct fill, the test is failed. If the bottom-right circle is not
+ visible or does not have the gradient fill, then the 'switch' is not
+ correctly supported, and does not allow one conditionally hidden
+ resource to reference another.
+
+
+ The test uses the 'rect', 'circle', 'gradient', and 'use' elements, as
+ well as basic fill (solid primary colors) and radial gradients.
+
Test to verify that the defs element is used as a container correctly.
+
In this test a fill is created which is solid red. The view should be a solid red 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 green fill and the other to obscure most of the red rectangle. The green rectangles should not show in the view as defs are referenced items and are not rendered. No green should show.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
+ Tests that the value of the display property on the defs element or on its descendants
+ doesn't prevent the elements from being referenced.
+
+
+ The test has passed if the following conditions are met:
+
+
+
there are 8 big rects visible each of a different color.
+
on top of the 8 big rects there are 8 circles that contain the reference color, the color of each circle must match the color of the rect to the right of its center
+
from the top-left to the top-right corner the colors must be: green, lime, yellow, olive.
+
from the bottom-left to the bottom-right corner the colors must be: navy, teal, blue, fuchsia.
+ This test tests that discard acts the same as removeChild.
+ First two red rects and a blue circle should be seen. The blue circle has
+ its radius animated to 0 over the course of 3 seconds. At the point where
+ the blue circle disappears the two red rects should be removed from the
+ tree. This reveals two green circles.
+
+
+ The test has passed if in the interval 0-3 seconds there are two red rects and a blue circle, and after 3 seconds two green circles can be seen and the text at the bottom says "Test passed".
+
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.
+
Because preserveAspectRatio is set to 'none', the content should appear distorted: 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.
+
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's size is 480 by 360 with an x/y origin in (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. Changing the viewport size should have no effect on the placement or scale of the document's conten.
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.
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.
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 xml:id=allGs. The two red rectangles and the yellow are in the g labeled rects. The reds 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 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.
This test validates that properties are inherited (or not, depending on their defintion), from a group to its children.
+
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 basic image formats allowed in the tiny profile are supported. 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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
This test verifies the support for gamma correction of displayed PNG images. 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 the tiny profile 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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
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>.
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.
+ Tests progressive rendering. Progressive rendering is an optional feature.
+
+
+ On user agents which support progressive rendering, the test is passed
+ if the circles render progressively. The update frequency is
+ implementation dependant.
+
+
+ On user agents which do not support progressive rendering, the test is passed
+ if all the circles are all displayed in a single render.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the rectangle should be full of circles, rendered all at once because of forward use with externalResourcesRequired.
+ The update frequency is implementation dependant.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the rectangle should be full of circles, rendered progressively.
+ Images should appear as the circles pass the yellow dots.
+ The update frequency is implementation dependant.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the content should be rendered all at once due to forward use of externalResourcesRequired on top-level SVG.
+ The update frequency is implementation dependant.
+
+ This test tests that any <svg> elements that are encountered inside
+ an <svg> element are ignored, if the user agent supports SVG Tiny 1.2 only.
+
+
+ If the user agent can handle SVG 1.1 Basic or Full, then the test has passed
+ if only the string "This text should be visible if the viewer supports at least SVG 1.1 Basic."
+ is visible.
+
+
+ If the user agent supports only SVG 1.2 Tiny then the test has passed if
+ the svg element and it's contents have been ignored. Only the string
+ "This text should be visible if the viewer supports only SVG 1.2 Tiny." should
+ be visible.
+
+
+ If both strings are visible then the test has failed.
+
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).
+
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.
+ This tests a set of 'use' and 'rect' elements inside 'g' elements, with
+ each referencing the one before. For the test to pass, 5 nested
+ rectangles with a green stroke must be rendered, and no red rectangles
+ must be rendered.
+
+ This test tests reference restrictions on the use element. Each of the 5 different
+ restrictions is tested.
+
+
+ A compliant SVG Tiny 1.2 user agent must treat each of the invalid IRI:s as if the xlink:href
+ attribute hadn't been specified, which is the same as disabling rendering of the use element
+ in question. Thus for the test to pass none of the content that the use elements try to reference
+ must be visible, the end result should be 5 empty (white) rects.
+
+
+ For a user agent that handles at least SVG 1.1 Basic the testcase has still passed if the referenced
+ content in the rect that is labelled "B" is visible since this is allowed for 1.1.
+
+ This test tests the reference restriction B on the use element.
+
+
+ A compliant SVG Tiny 1.2 user agent must treat each of the invalid IRI:s as if the xlink:href
+ attribute hadn't been specified, which is the same as disabling rendering of the use element
+ in question. Thus for the test to pass the content that the use element tries to reference
+ must be invisible, the end result should be an empty (white) rect.
+
+
+ For a user agent that handles at least SVG 1.1 Basic the testcase has still passed if the referenced
+ content in the rect that is labelled "B" is visible since this is allowed for 1.1.
+ If the script in the external resource is executed then the color of the rect will be green.
+ If not then the rect will be red.
+
The intent of the file is to determine if the UA supports references to external SVG fragments. 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 object, the UA should display a semi transparent duplicate copy at an offset position. See referenced image.
The intent of the file is to determine if the UA supports references to external SVG fragments. 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 object, the UA should display a semi-transparent duplicate copy at an offset position. See referenced image.
+ This test checks some aspects of the SVGElementInstance with regards to events.
+
+
+ Four blue rects should be visible at first. To run the test each rect must be clicked a minimum of two times. Once
+ to run the basic test, and once to verify that the event handler was removed properly. The test has passed if after
+ clicking all the rects two times or more there are four green rects with the word "Passed" on them. If anything red
+ is visible or the text on any of the rects say "Failed" then the test has failed.
+
+
+ The top-left rect checks that correspondingUseElement and correspondingElement are returning the correct values, and
+ also that the currentTarget isn't the same as target here.
+
+
+ The top-right rect checks that events bubble the correct way when SVGElementInstance is involved. It's almost the same
+ as the first subtest, but uses another 'use' element.
+
+
+ The bottom-left rect doesn't use 'use' elements at all, it's to illustrate event bubbling in normal trees as compared
+ to SVGElementInstance trees.
+
+
+ The bottom-right rect uses nested 'use' elements. The event handler 'nestedhandler' should be executed first, and will
+ check some aspects of nested use elements. It will modify what it references, and that is checked in the 'h4' event
+ handler.
+
+ 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.
+
+
+ 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.
+
+ For this test to pass the green text "This text should be visible." must
+ be rendered. It is not an error if graphics are visible in addition to
+ the green text. It is not a requirement that graphics be rendered in
+ addition to the green text.
+
+ This test checks for recursion in 'use' elements. The passing conditions are that the browser does not crash, and that at least one orange circle, and one yellow circle, and a line of green text are rendered.
+ Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may not be rendered, depending upon when and how the implementation detects the circular reference,
+ with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation.
+
+ This test checks for recursion in 'use' elements with external references. The passing conditions are that the browser does not crash, and that the green test is rendered. The passing conditions are that the
+ browser does not crash, and that at least one orange circle and a line of green text are rendered. Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may
+ not be rendered, depending upon when and how the implementation detects the circular reference, with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation..
+
+
+ This test depends upon 'struct-use-recursion-03-t.svg'.
+
+ This test checks for recursion in 'use' elements with external references. The passing conditions are that the browser does not crash, and that at least one yellow circle and a line of green text are rendered.
+ Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may not be rendered, depending upon when and how the implementation detects the circular reference,
+ with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation.
+
+
+ This test depends upon 'struct-use-recursion-02-t.svg'. It differs from 'struct-use-recursion-02-t.svg' in that the 'use' element comes before the 'circle' element.
+
Verify property inheritance as required by 6.7 "Property inheritance".
+
For this test to pass:
+
At the center right, there is an ellipse. The fill color is not specified on that element but on its parent. The ellipse must 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 from the center to the edge.
+
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 from the center to the edge
+ Tests inheritance, animation and effect of display:none on stop-color. Three
+ rectangles are displayed. After a five second animation has completed,
+ the test is passed if all three rectangles display a green to blue gradient.
+
+
+ The stop-color property is not inherited by default, but the value 'inherit' forces it to
+ inherit the current animated value from its parent.
+
+
+ In the first subtest, the value of the stop-color property on the second stop is
+ 'inherit'. Its parent, linearGradient with id "MyGradient" also has stop-color set to
+ "inherit". The parent of this gradient is the group with id "g2" and the property
+ stop-color is animated on that group. Thus, after the animation finishes,
+ the inherited value is blue.
+
+
+ In the second subtest, the value of the stop-color property on the second stop is
+ 'currentColor'. Its parent, linearGradient with id "MyGradient" does not have the
+ color property set, but the property is inherited, so it inherits from the
+ parent - the group with id "g2". The property color is animated on that group.
+ Thus, after the animation finishes, the inherited value is again blue.
+
+
+ The third subtest is not animated. It checks that, per specification, the properties
+ on a gradient are inherited from the point of definition, not the point of use. An
+ implementation which does this incorrectly will show a green to red fill.
+
+ Tests inheritance, animation, currentColor on solid-color. Four
+ rectangles are displayed. After a five second animation has completed,
+ the test is passed if all four rectangles display a solid green fill.
+
+
+ Note: The solid-color property is not inherited by default, but the value 'inherit' forces it to
+ inherit the current animated value from its parent.
+
+
+
+ In the first subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent, a group, also has solid-color set to
+ "inherit". The parent of this group is another group, the property
+ solid-color is green on it.
+
+
+ In the second subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent has solid-color set to
+ "inherit". The parent of this group is another group whose solid-color
+ property is yellow.
+ The solid-color property on the solidColor element is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value is green.
+
+
+ In the third subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent has solid-color set to
+ "inherit". The parent of this group is another group whose solid-color
+ property is yellow.
+ The solid-color property on the outermost group is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value is green.
+
+
+ In the fourth subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'currentColor'. Its parent has color set to
+ "inherit". The parent of this group is another group whose color
+ property is yellow.
+ The color property on theoutermost group is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value of color, and thus the value used by currentColor, is green.
+
Check that !important in presentation attribute is an unsupported attribute value. To pass, two rectangles should be drawn. A black filled rectangle and a lime green stroked rectangle.
+
+ 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.
Test horizontal baselines across script and font size changes.
+
+ The dominant baseline should be alphabetic, so the 'ab' will be sitting
+ on the blue line, the japanese glyphs 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 'ab' on the blue line, the ideographic chars
+ slightly below the line and the devangari should be hanging from the
+ hanging baseline.
+
+ 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.
+
+
+ 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 (red) 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 for viewer capability to handle the basics of the 'textAnchor'
+ alignment property for 'text' when it has child elements.
+
+
+ The first line from the top tests that a 'tspan' element is rendered
+ after the text content of the parent 'text' element.
+
+
+ The second line from the top tests that all the text content, including
+ that of child 'tspan' elements, is taken into account when positioning
+ the text with respect to its alignment point.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the text fonts and layout (per CSS2 rules).
+
Testing 'textArea' with fixed 'width' and 'height'
+
+ Lines should break at character boundaries if there is not enough room to perform word breaks.
+ The 'height' of the first 'textArea' below (top-right) is less than that of the characters
+ so nothing should appear.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
Testing 'textArea' with fixed 'width' and 'height'
+
+ Three 'textArea' elements contain words which are increasing in 'font-size'.
+
+ To pass, no characters should appear in the top-right box since the 'height' of the 'textArea' is less
+ than that of the characters.
+
+ There should be no characters outside of the border of the larger bottom-left box.
+
+ In the left-side box, there may be characters outside of the border, depending on whether
+ the implementation breaks words or not.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+ A visible rectangle is drawn the same size as the textArea. The text
+ contained in the textArea should automatically wrap.
+
+
+ The textArea starts off as a 24x 24 square and is animated down to full
+ size. The text should continually rewrap as the textArea increases in
+ size.
+
+
+ The text is taken from "The Lost Princess of Oz" by Baum, L. Frank
+ (Lyman Frank), 1856-1919
+
+ The eight lines of numbers should not wrap. Each line is terminated by a tbreak element.
+ They have numbers from 0 to 50. Each line increases the 'font-size' by 25%.
+ The 'line-increment' attribute is not used.
+
+
+ This test is passed if eight lines of numbers are rendered and not
+ wrapped to a new line. Numbers displayed will decrease with each line.
+ Every line must begin with number 0.
+
+ Each word should break onto a new line. The left-hand 'textArea' has no 'tbreak' elements
+ while the right-hand one uses 'tbreak' after each word. Both should appear the same.
+
Testing 'tbreak' while animating the 'font-size' attribute in 'tspan' in 'textArea'
+
+ This test defines one 'textArea' element with a 'tspan' child. The 'tspan' has as red fill and also an animation
+ which animates the font-size from 0 to 20. The tspan element has a tbreak element before and after it.
+
+
+ To pass, the red text should both start and end on a new line, even when the font-size of the tspan is animated.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+ A visible rectangle is drawn the same size as the textArea. The text contained in the textArea should
+ automatically wrap.
+
+
+ The textArea starts off as a 24x 24 square and is animated down to full size. The text should continually
+ rewrap as the textArea increases in size.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+ This test checks basic text-editing capabilities.
+
+
+ Start editing by activating the textArea that has a green dashed outline.
+ This textArea has no child text content, but has a defined width and height.
+ Input the string "123 456" (one two three, space, space, four five six).
+
+ After input is complete, click the button labeled "Check #1". If the frame around
+ the textArea goes from being dashed to being solid then that part of the test has passed.
+ Another condition is that the text string "123 456" should look like it only has one space
+ and not two due to the whitespace handling rules.
+
+
+ Next activate the middle textArea that has a red dashed outline.
+ Input two spaces between 3 and 4. Now since this textArea has xml:space="preserve" those
+ two spaces should be rendered as two spaces, meaning it must look different from the first
+ textArea on the left. The textContent must be the same in both cases though, and this is
+ verified by clicking the button labeled "Check #2". If the test is successful the frame
+ will turn from dashed red to solid red.
+
+
+ Finally activate the rightmost textArea that has a blue dashed outline.
+ Then exit the editing mode without changing the text. The text must not change and the 'tbreak' element
+ must be kept in the position it's in. Now activate the textArea again and input an additional linebreak between 3 and 4.
+ The line "345" must now be on the third line, the second line being blank.
+ Click the button labeled "Check #3" to verify the result, the frame will turn from dashed
+ blue to solid blue if successful.
+
+
+ The test has passed if after inputting text according to the instructions above and clicking the three
+ buttons the rendered image matches the reference image exactly.
+
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.
+
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.
Testing font-family attribute. Two SVG fonts are defined. Various text elements are then used with varying values for the font-family attribute. 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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
+ Testing font-family attribute.
+ Various text elements are
+ used with varying values for the font-family attribute.
+ The first two text elements should display in their respective fonts,
+ Haettenschweiler and
+ ,
+ 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.
+
+
+ If the two named fonts are available on the system,
+ the rendered picture should match the reference image exactly,
+ except for possible
+ variations in the labelling text (per CSS2 rules)
+ and variations in text antialiasing or hinting.
+
+ 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
+ the platform supports installable opentype fonts, please download
+ Zalamander Caps
+ by Tim Ahrens of Just Another Foundry.
+
+
+ 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.
+
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.
+
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.
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.
+
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.
+
A future version of this test might include all necessary glyphs as an SVG font.
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.
Test text element, tspan element and various text styles.
+
The first group tests that text displays at all, that it displays in a straight line, and that the font style can be made italic or bold.
+
The second group tests that text can be treated as any other graphical element, with stroke and fill properties. The first word tests that fill color can be specified. The second word tests that stroke color can be specified in absence of fill. The third group tests the combination of all these effects. The final group tests positioning of 'text' elements.
The purpose of this test is to validate proper handling of the text element's x and y attributes. In the various samples, a red 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.
+
In all the above tests, blue markers represent the expected glyph positions. The red 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 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 red), 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.
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
+ 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.
+
+
+
+ The rendered picture should match the reference image exactly, except for possible
+ variations in the labelling text (per CSS2 rules).
+
+ This test demonstrates text selection of bidirectional text.
+
+
To pass the test the the first 9 characters in logical order starting from logical position 0 are to be selected. This must be done by the tester since there's no way to control the selection in DOM. The selection should be started at the letter 'a' and proceed to the number '1' as indicated by the arrows. Visually this makes the selection 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.
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;
+
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.
+
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.
+ This tests that the getTrait[NS] and setTrait[NS]
+ methods of the TraitAccess interface work for the special
+ '#text' trait on the desc, title,
+ metadata, text, tspan and textArea
+ elements.
+
+
+ The rectangle in the top left corner indicates whether the
+ getTrait and getTraitNS returned the expected
+ strings for each of the relevant elements; blue for pass,
+ red for fail. The four text strings below it indicate whether
+ setTrait and setTraitNS worked on the text
+ and textArea elements; they must all be the string “PASS”.
+
+ This tests that the Node interface attributes
+ namespaceURI, localName, parentNode
+ and ownerDocument are correct, for some simple cases.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the attributes being tested have the expected values; green for
+ pass, red for fail.
+
+ This tests that the textContent attribute of the
+ Node interface works correctly. The test is passed
+ if a blue square and two "PASS" are displayed.
+
+
+ The rectangle in the top left corner indicates whether the
+ behavior when manipulating the textContent attribute
+ on various elements.
+ The two text strings below it indicate whether setting
+ textContent on the text and textArea
+ elements succeeded.
+
+ This tests that the appendChild method of the
+ Node interface works correctly.
+
+
+ The test has been passed if six blue rectangles are displayed.
+ Each rectangle indicates the result of a different aspect of
+ appendChild behavior being tested:
+
+
+
+ The first is a test of appending a newly created rect that
+ is not yet in the document tree.
+
+
+ The second is a test of appending a rect that is already
+ somewhere else in the document tree. In its initial position, it
+ inherits fill='red', and in its new position, it inherits
+ fill='blue'.
+
+
+ The third is a test of appending a rect to its current
+ parent. This results in the rect being moved to the
+ final position in the list of child nodes. In its initial
+ position, a red rect occludes this blue one. In its final
+ position, this blue rect occludes the red one.
+
+
+ The fourth is a test of appending a second element to the document
+ node. This results in a DOMException being thrown with code
+ HIERARCHY_REQUEST_ERR. If this exception is thrown, the
+ rect is changed from red to blue.
+
+
+ The fifth is a test of appending an element to one of its
+ descendant elements. This also results in a DOMException being
+ thrown with code HIERARCHY_REQUEST_ERR. If this exception is
+ thrown, the rect is changed from red to blue.
+
+
+ The sixth is a test of appending an element from another document
+ into this document. The element from the other document is obtained
+ by calling parseXML. A DOMException must be thrown with
+ code WRONG_DOCUMENT_ERR. If this exception is thrown, the
+ rect is changed from red to blue.
+
+ This tests that the removeChild method of the
+ Node interface works correctly.
+
+
+ The test has three sub-tests, for different removeChild
+ behavior, which consist of a paired rectangle and circle:
+
+
+
+ The first is a test of successfully removing a single element
+ from the document. Initially, a red rectangle occludes a blue
+ rectangle. This red rectangle should then be removed by the
+ removeChild call, which results in the blue rectangle
+ becoming visible. The circle beneath it represents whether
+ removeChild returned the correct value (i.e., a reference
+ to the same red rectangle that was removed). If this return
+ value is incorrect, the circle will remain red. If it was
+ correct, the circle is changed to be blue.
+
+
+ The second is a test of successfully removing a subtree
+ from the document. The subtree is simply a g element
+ with a red rect as a child, which initially occludes
+ a blue rectangle. The group with the red rectangle should then be
+ removed by the removeChild call, which results in the blue
+ rectangle becoming visible. The circle beneath it represents
+ whether removeChild returned the correct value (i.e., a
+ reference to the g element that was removed). If this
+ return value is incorrect, the circle will remain red. If it was
+ correct, the circle is changed to be blue.
+
+
+ The third is a test of removeChild throwing a NOT_FOUND_ERR
+ DOMException when passed an element that is not a child of
+ the element on which the method was called. If the blue rectangle
+ remains, the implementation correctly did not remove it. The circle
+ indicates whether the exception was thrown as expected. If the
+ exception was not thrown, or the wrong is exception is thrown,
+ the circle will remain red. Otherwise, the circle will be changed
+ to be blue.
+
+
+
+ The test has been passed if the top row shows three blue rectangles
+ and the bottom row shows three blue circles.
+
+ This tests that the cloneNode method of the
+ Node interface works correctly.
+
+
+ The test has two sub-tests: one for a deep clone, and
+ one for a shallow clone.
+
+
+
+ The first row shows the deep clone sub-test. A group
+ containing three cascaded rectangles and a text
+ element are cloned and inserted into the document 180
+ user units to the right. The group inherits fill and
+ stroke colors from a parent element, and where the cloned
+ copy of the group is inserted, different colors are
+ inherited. The original group inherits a blue fill and
+ a light blue stroke, while the cloned group inherits an
+ orange fill and a light orange stroke. The text in both copies
+ of the group have a white fill and no stroke.
+
+
+ The second row shows the shallow clone sub-test. A circle
+ element with two child set elements (that set the fill to
+ blue and the stroke to light blue) is shallow cloned and inserted
+ into the document 100 user units to the right. Since it is a
+ shallow clone, the cloned circle does not have the
+ set element children, and inherits an orange fill
+ and a light orange stroke.
+
+ This tests that the createElementNS method on the
+ Document interface works correctly, for each SVG Tiny 1.2
+ element, and for some unknown elements.
+
+
+ There are four sub-tests (a rectangle for each). The test has been
+ passed if all four rectangles are blue.
+
+
+ Thes are:
+
+
+
Sub-test 1: test creating each SVG Tiny 1.2 element.
+
Sub-test 2: test creating an unknown element in no namespace.
+
Sub-test 3: test creating an unknown element in the SVG namespace.
+
Sub-test 4: test creating an unknown element in another namespace.
+ This tests that the firstElementChild,
+ lastElementChild, nextElementSibling and
+ previousElementSibling methods of the ElementTraversal
+ interface works correctly.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the attributes being tested have the expected values; green for
+ pass, red for fail.
+
+ This tests that the target, currentTarget,
+ type and cancelable
+ attributes of the Event interface work correctly.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and all of its ancestor nodes. Clicking on the
+ rectangle will test that the attribute of the Event object
+ all have expected values, for each invocation of an event listener.
+ It also tests whether each of the event listeners is indeed invoked.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ This tests the stopPropagation method of the
+ Event interface.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and some of its ancestor nodes. Clicking on the
+ rectangle will dispatch the click event. The listener on
+ the parent node of the rect calls stopPropagation().
+ The test checks that the listener for the grandparent node is not
+ dispatched.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ This tests the defaultPrevented attribute and the
+ preventDefault method of the Event interface.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and some of its ancestor nodes. Clicking on the
+ rectangle will dispatch the click event. The listener on
+ the grandparent node of the rect calls
+ preventDefault(). The test checks that the event object has
+ defaultPrevented set to true.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ This tests the clientX, clientY and button
+ attributes of the MouseEvent interface.
+
+
+ The test consists of three rectangles, one for each of the three
+ common mouse buttons. To perform the test, the user must move the
+ mouse cursor over a rectangle, press the mouse button down, then
+ move the mouse cursor out of the rectangle. If after this the
+ rectangle becomes blue, then that sub-test has been passed, indicating
+ that the clientX, clientY and button
+ attributes of the MouseEvent object had expected values for
+ the mouseover, mousedown and mouseout
+ events.
+
+
+ The test as a whole has been passed if, for each rectangle that
+ corresponds to a button on the pointing device that the user
+ agent supports, it becomes blue after performing the interaction.
+ If the user agent does not support a pointing device at all,
+ then the test is passed automatically without needing to
+ perform any interaction.
+
+ This tests the data attribute of the TextEvent
+ interface.
+
+
+ To perform the test, the user must input some text. This can be
+ from a variety of sources, such characters directly from a keyboard,
+ text pasted from the clipboard, input from an IME or input from a
+ speech recognizer.
+ Once the text has been input, the black rectangle should turn blue to
+ indicate that the test has been passed. In addition, the
+ text element below the rectangle will show the text that was
+ input.
+
+
+ If the rectangle becomes red, the test failed because the
+ data attribute had an invalid value. If the rectangle
+ remains black, the test failed because the textInput
+ event is not supported. If the text string does not appear,
+ or does not match the input text, the test failed because the
+ textInput event is not supported correctly (e.g. it
+ only tests for any keyboard activity).
+
+ This tests the detail attribute of the UIEvent
+ interface and the dispatch order of mouse events when clicking.
+
+
+ To perform the test, the user must triple click on the circle.
+ The nine rectangles to the right of the circle indicate whether the
+ detail attribute of the UIEvent object was correct
+ for the mousedown, click and mouseup
+ events. The first row of rectangles checks the three events when
+ detail = 1, the second row for detail = 2 and
+ the third row for detail = 3.
+
+
+ In addition, the circle should remain black after the nine rectangles
+ have become blue. If the circle becomes red, it indicates that
+ the test failed because the mousedown, click and
+ mouseup events were fired in an incorrect order.
+
+
+ The test has been passed if, after triple clicking the circle, all nine
+ rectangles are blue and the circle remains black.
+
+ This tests that the target, currentTarget,
+ type and cancelable
+ attributes of the Event interface work correctly. It
+ is the same as udom-event-202-t except that the event listener
+ is given by an ECMAScript object with a handleEvent
+ property, rather than by an ECMAScript Function object.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and all of its ancestor nodes. Clicking on the
+ rectangle will test that the attribute of the Event object
+ all have expected values, for each invocation of an event listener.
+ It also tests whether each of the event listeners is indeed invoked.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+ The test at first should show a green rectangle.
+
+
+ Trigger some mousewheel events, for example by using a mouse with a scrollwheel
+ or a jog dial.
+ The test has passed if, when you scroll down, the rectangle rotates clockwise;
+ and when you scroll up, the rectangle rotates counter clockwise.
+ For reference the values of the Mousewheel event are displayed as text.
+
+ This tests that the gotoLocation method is present
+ and works for a simple case.
+
+
+ Once loaded, the SVG file will be replaced by the words success. Note that the
+ contents of this file may be displayed for a short interval until the new file is loaded.
+
+ This SVG will test the SVGGlobal's postURL() callback status. The test
+ is passed if, on each row, both squares have the same color.
+
+
+ There are multiple calls to postURL(), each with a different expected
+ HTTP return code.
+
+
+ The test works in conjunction with a JSP servlet called HttpCodeTest,
+ which will simulate the various HTTP return codes, based on the query
+ parameter from the client.
+
+
+ For each call to postURL(), two squares will appear. The first square
+ represents the "expected" status code. The second square represents the
+ "actual" status code that the callback function receives. The status
+ codes are color-coded.
+
+
+ Note that the status codes may take some time to update, due to the
+ asynchronous nature of the postURL() callback. Tester should allow some
+ time for all postURL() calls to receive ther return codes. The latency
+ will vary depending on the network environment, but normally, it should
+ only be a couple minutes at most.
+
+
+ 100-ranges status codes are not tested here because the spec states that
+ these status codes should be ignored. It is not clear what the expected
+ callback status should be in this case.
+
+ This SVG will test the SVGGlobal's getURL() callback status. The test is
+ passed if, on each row, both squares have the same color.
+
+
+ There are multiple calls to getURL(), each with a different expected
+ HTTP return code.
+
+
+ The test works in conjunction with a JSP servlet called HttpCodeTest,
+ which will simulate the various HTTP return codes, based on the query
+ parameter from the client.
+
+
+ For each call to getURL(), two squares will appear. The first square
+ represents the "expected" status code. The second square represents the
+ "actual" status code that the callback function receives. The status
+ codes are color-coded.
+
+
+ Note that the status codes may take some time to update, due to the
+ asynchronous nature of the getURL() callback. Tester should allow some
+ time for all getURL() calls to receive ther return codes. The latency
+ will vary depending on the network environment, but normally, it should
+ only be a couple minutes at most. Once all calls have returned, the text
+ "Callbacks now finished" will show, in green.
+
+
+ 100-ranges status codes are not tested here because the spec states that
+ these status codes should be ignored. It is not clear what the expected
+ callback status should be in this case.
+
+ Test with cloneNode on a use element. The red rect is cloned directly on the rect element.
+ The yellow rect is cloned on the use element. Two red and two yellow rects must be showing.
+
+ Testing CloneNode with different values of the "deep" parameter.
+ In this test an image with animations inside is cloned twice, one which should keep the animations and the second that should only clone image node.
+ The first and second image should animate from opacity 0 and width 20 to opacity 1 and width 100. The third image should not animate.
+
+ 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 root 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 createElementNS method.
+
+
+ If an implementation supports the ECMAScript DOM binding for SVG, then the image must show the following text:
+ "This document's root identifier is: svg-root" and a red rectangle with a black shadow rectangle. Otherwise, only a red rectangle will show.
+
+
The rendered picture should match the reference image.
+ This tests the beginElement and beginElementAt
+ methods of the ElementTimeControl interface.
+
+
+ The test consists of four animated rectangles, one pink, three blue.
+ To perform the test, the user must click the pink rectangle.
+ The pink rectangle is set to animate with begin='mousedown',
+ while the three blue rectangles have begin='indefinite',
+ and are begun with calls to methods on the ElementTimeControl
+ interface:
+
+
+
+ The first blue rectangle is begun with .beginElement().
+
+
+ The second blue rectangle is begun with .beginElementAt(0).
+
+
+ The third blue rectangle is begun with .beginElementAt(2.5).
+
+
+
+ The test has been passed if the three blue rectangles reach their
+ destination at the same time as the pink rectangle.
+
+ This tests the beginElement and beginElementAt
+ methods of the ElementTimeControl interface, with different
+ begin instance time lists.
+
+
+ The test has been passed if all the three rectangles and the circle
+ become blue one second after clicking the circle.
+
+
+ The test consists of a pink circle and three animated rectangles.
+ To perform the test, the user must click the pink circle.
+ The three rectangles all have animations that begin='0s'
+ and run indefinitely, and are also set to restart='none'.
+ Clicking the circle will attempt to begin the three animations as follows:
+
+
+
+ The first rectangle's animation has .beginElement() called.
+
+
+ The second rectangle's animation has .beginElementAt(0) called.
+
+
+ The third rectangle's animation has .beginElementAt(0.5) called.
+
+
+
+ All three animations should not begin with these method calls, since
+ the animations have already started and are set to restart='none'.
+ If an animation does restart, its endEvent will be captured
+ and the rectangle will become red. If the animation does not restart,
+ it will become blue one second after clicking the pink circle.
+
+
+ In addition, the circle should become blue one second after clicking
+ it. This indicates that the implementation correctly dispatches an
+ endEvent when an element restarts.
+
+ This tests the endElement and endElementAt
+ methods of the ElementTimeControl interface.
+
+
+ The test consists of four animated rectangles, one pink, three blue.
+ To perform the test, the user must click the pink rectangle.
+ The pink rectangle is set to animate with begin='mousedown'.
+ The three blue rectangles have two animations each: the first is
+ an animation element that moves the rectangle along its
+ corresponding line, with begin='0s' dur='5s'. After the
+ animation element is a set element with
+ end='indefinite'. Each set animation is ended with
+ calls to methods on the ElementTimeControl interface:
+
+
+
+ The first blue rectangle is ended with .endElement().
+
+
+ The second blue rectangle is ended with .endElementAt(0).
+
+
+ The third blue rectangle is end with .endElementAt(2.5).
+
+
+
+ The test has been passed if the first two blue rectangles follow the
+ animation of the pink rectangle, and the third blue rectangle follows
+ the animation of the pink rectangle after 2.5 seconds (i.e., half way
+ through the pink rectangle's animation).
+
+ This tests that the correspondingElement and
+ correspondingUseElement attributes of the
+ SVGElementInstance interface have expected values.
+
+
+ The test consists of a single rectangle that is a descendant
+ of a number of g elements and a couple of nested
+ use shadow trees. When the user clicks the rectangle,
+ a mousedown event is dispatched, which travels up
+ the nested shadow trees. If the correspondingElement and
+ correspondingUseElement attributes of the
+ SVGElementInstance object (which is the currentTarget
+ of the event) are correct, the rectangle becomes blue. Otherwise,
+ it becomes red.
+
+ This tests setting and getting the currentScale attribute of
+ the SVGSVGElement interface.
+
+
+ There are three sub-tests, each represented by a rectangle (blue for
+ pass, red for fail). The test has been passed if all three rectangles are blue, and
+ the test slide is shown at 90% of its regular size (i.e., the
+ range (0, 0) -> (533.333, 400) user units is shown).
+
+
+
+ The first sub-test checks that the initial value of
+ currentScale is 1. The second checks setting
+ currentScale to a valid value (in this case, 0.9), and
+ looks at the resulting screenCTM. The third exercises retrieving
+ the newly set value.
+
+ Test on SMIL with scripting. The animated bar should pause for 3s at 1.5s and resume at 4.5s.
+ The smaller rects should change color at the indicated times.
+
+ Test on SMIL with scripting. Animation should match the indicated begin- and end-values,
+ and should pause for three seconds when the pause-sign turn red.
+
+ Test on SMIL with scripting. Animation should match the indicated begin- and end-values,
+ and should pause for three seconds when the pause-sign turns red. restart is set to "never" so should NOT restart.
+
+ This tests that the getCurrentTime method of the
+ SVGSVGElement interface returns sensible values.
+
+
+ The test shows three rectangles. The test is passed if the first rectangle is blue, and after
+ clicking the second rectangle it turns blue, and after clicking
+ the third rectangle it also turns blue.
+
+
+ The first one represents
+ whether calling getCurrentTime before the load
+ event is dispatched returns 0. Clicking the second rectangle
+ (which is red to begin with) then tests that the current time is
+ greater than 0. Finally, clicking the third rectangle (which
+ also is red to begin with) tests that the current time is greater
+ than the time at which the second rectangle was clicked.
+
+
+ This tests the basic functionality of
+ SVGSVGElement.createSVGPath(). It
+ verifies that the returned path object has no path segments
+ initially, that a path segment can be added to the path object,
+ and that the object returned is actually
+ instanceof SVGPath.
+
+ This tests trait access methods on the TraitAccess interface
+ for the 'accumulate' trait. Each trait getter and setter method is called on
+ each applicable SVG Tiny 1.2 element.
+
+
+ The test is passed if the rendering matches the reference rendering.
+ The rectangle must be blue, and there must be a blue circle to the
+ right of it whose diameter is the same as the height of the rectangle.
+ There must be no text displayed below the rectangle.
+
+ This tests trait access methods on the TraitAccess interface
+ for the 'begin' trait. Each trait getter and setter method is called on
+ each applicable SVG Tiny 1.2 element.
+
+
+ The test is passed if, five seconds after the document begins:
+
+
+
the rectangle is blue,
+
+ there is a blue circle to the right of the rectangle whose
+ diameter is the same as the height of the rectangle,
+
+
an animation showing rotating rectangles to the right of the circle begins,
+
a video showing a dog to the right of the animation begins, and
+
an audio clip begins playing.
+
+
+ Also, there must be no text displayed inside the rounded green rectangle.
+
+ This test verifies that the CTM fetched by getScreenCTM is a snapshot value of the current animated state.
+
+ The CTM values are inspected on 'beginEvent', 'endEvent' and 'repeatEvent' times. The expected values are
+ calculated from the SMIL Animation equations and the current document time.
+
+ The test has passed if the testcase reports "Results match expected values." 8 times, and each such string
+ is prefixed with a green rectangle. When this happens the text in the rect with blue stroke changes from
+ 'failed' to 'passed'.
+
+ Four animations begin at time 0 and end at times 1, 2, 5 and 9 seconds. Event listeners are registered
+ for the "endEvent" event.
+ As each animation ends, getCurrentTime() is called and verified with the expected time. The expected time is compared with
+ the minimum time to take into account implementation-specific document time resolution.
+ If all times have the expected values, the text changes from 'testing' to 'passed'
+
+ Tests setCurrentTime. The test is passed if the the moving bar skips
+ from 2 to 4 , and from 5 to 8; and after the animation completes, the
+ text "passed" appears at the bottom right.
+
+
+ Four animations begin at time 0 and end at times 1, 2, 5 and 9 seconds.
+ Event listeners are registered for the "endEvent" event.
+ As each animation ends, getCurrentTime() is called to verify the expected current time, which
+ is them followed by a call to setCurrentTime.
+ If all times have the expected values, the text changes from 'testing' to 'passed'
+ The expected time is compared with
+ the minimum time to take into account implementation-specific document time resolution.
+
+ This tests setFocus and getCurrentFocusedObject, setting the focus and then checking that the correct element has focus. Successes are shown in green,
+ failures in red. If all subtests pass, the text in the blue box changes from "failed" to "passed".
+
+
+ A numeric keypad is shown. Focus starts on the "5" and is then moved programatically
+ to each of the other numbers, finally returning to "5". Since this happens on the load event, there is no indication of the focus moving.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test
+ various trait combinations with expected values. If a result is not as
+ expected, an error is displayed in red text, indicating the returned
+ result and what was expected. When all subtests have returned success,
+ the result is set to 'passed'. The pass condition for the test is that
+ all subtests are green, and the word 'passed' is at the bottom right.
+
+ This test creates an SVGColor object and verifies that the intial data is all zero. It then modifies the red, green, and blue attributes.
+ To pass, the resulting attributes should be as expected should be correct, and when this happens the text
+ changes from 'failed' to 'passed'
+
+
Note that, since the test does not insert this object into the document, it is not displayed. The test simply verifies that the object has been created correctly.
+ This test draws a few basic shapes and checks for correct values from getBBox().
+ 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'.
+
+ Note, this test does not have 100% for the svg width and height on purpose as to have exact
+ expected results for the screen bounding boxes
+
+
+ This test draws a few basic shapes and checks for correct values from getScreenBBox().
+ To pass, each returned bounding box must be correct (indicated by printing the values in green), and when this happens the text
+ changes from 'failed' to 'passed'
+
+ This test draws a few basic shapes and checks for correct values from getScreenCTM().
+ To pass, each returned CTM must be correct (indicated by printing the values in green),
+ and the string 'passed' appears in the lower right.
+
+
+ Note, this test does not have 100% for the svg width and height on purpose as to have exact
+ expected results for the screen CTM.
+
+ This test creates a SVGMatrix object and calls getComponent to verify the result
+ To pass, each returned component must be correct. To indicate a pass
+ the result of the test changes to green and the text at the bottom right
+ hand corner changes from "failed" to "passed".
+
+ This test creates two SVGMatrix objects and calls inverse on each.
+ The first matrix is invertable, but the second one is not, and should throw an exception when inverse() is called.
+ To pass, the inverted matrix must be correct, and the exception for the second matrix must be thrown.
+ To indicate a pass the result of the test changes to green and the text at the bottom right
+ hand corner changes from "failed" to "passed".
+
+ This test creates a few SVGMatrix objects and calls mMultiply.
+ To pass, the result matrices should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates some SVGMatrix objects and then calls mRotate.
+ To pass, the result matrices should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates an SVGMatrix object and calls mScale.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates an SVGMatrix object and calls mTranslate.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates path data using the SVGPath interface, with emphasis on support for close, moveTo and quadTo
+ To pass, the path data must match expected results for the text at the bottom of the test to read 'pass'.
+ The path data is verified by calling getSegment and getSegmentParam.
+ In addition, no red should be seen through the path element.
+
+ This test creates path data using the SVGPath interface, with emphasis on support for lineTo and curveTo
+ To pass, the path data must match expected results for the text at the bottom of the test to read 'pass'.
+ The path data is verified by calling getSegment and getSegmentParam.
+ In addition, no red should be seen through the path element.
+
+ This test creates SVGRect object and verifies that the initial data is all zero. It then modifies the x, y, width and height.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'
+
+ Tests access to textContent.
+ The only text that should be visible is the string "Rect Text and Rect Animate Text!" in green.
+ The set element that makes the element "setTextContent" hidden should be removed when setting the new textContent and therefore the text must be visible.
+
+ Tests trait access in uDOM.
+ The svg should look the same on both sides and the text
+ should read "Passed". Both the rects should link back to this test.
+
+ Test on solidColor solid-opacity trait access.
+ Test result are displayed within the test.
+ The first sub-test should display a number approximately equal to 0.2.
+ The second sub-test should display a number approximately equal to 0.5.
+ The third sub-test should display a number equal to 1.
+
+ Test on Ecma-script. Sets viewport-fill-opacity to 0.5 with setFloatTrait
+ (should show a red viewport with correct opacity, and the text 'viewport-fill-opacity="0.5"' should show).
+
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.
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-02-t.png
new file mode 100755
index 00000000..06d411ef
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-03-t.png
new file mode 100755
index 00000000..5afa9edd
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-04-t.png
new file mode 100755
index 00000000..308cfd06
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-05-t.png
new file mode 100755
index 00000000..e71aeccb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-06-t.png
new file mode 100755
index 00000000..067aac70
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-07-t.png
new file mode 100755
index 00000000..13d9fab9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-08-t.png
new file mode 100755
index 00000000..e5e2e187
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-09-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-09-t.png
new file mode 100755
index 00000000..d42baeea
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-09-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-10-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-10-t.png
new file mode 100755
index 00000000..d61c634d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-10-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-11-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-11-t.png
new file mode 100755
index 00000000..5887bacb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-11-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-12-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-12-t.png
new file mode 100755
index 00000000..b9982cd8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-12-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-13-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-13-t.png
new file mode 100755
index 00000000..5f9c0b1d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-13-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-14-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-14-t.png
new file mode 100755
index 00000000..8e6d4cfc
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-14-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-15-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-15-t.png
new file mode 100755
index 00000000..42e9fb74
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-15-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-17-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-17-t.png
new file mode 100755
index 00000000..82b77d26
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-17-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-19-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-19-t.png
new file mode 100755
index 00000000..b33f766d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-19-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-20-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-20-t.png
new file mode 100755
index 00000000..c71f2611
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-20-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-201-t.png
new file mode 100755
index 00000000..74ec290b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-202-t.png
new file mode 100755
index 00000000..bdc2b98a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-203-t.png
new file mode 100755
index 00000000..1aeffbdc
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-205-t.png
new file mode 100755
index 00000000..cd5f541b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-206-t.png
new file mode 100755
index 00000000..847136d9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-207-t.png
new file mode 100755
index 00000000..acee2a48
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-209-t.png
new file mode 100755
index 00000000..b5f668d1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-21-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-21-t.png
new file mode 100755
index 00000000..7d2de934
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-21-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-210-t.png
new file mode 100755
index 00000000..c4dab6c0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-211-t.png
new file mode 100755
index 00000000..2b564c70
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-212-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-212-t.png
new file mode 100755
index 00000000..a427233b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-212-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-213-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-213-t.png
new file mode 100755
index 00000000..18fd7c06
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-213-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-214-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-214-t.png
new file mode 100755
index 00000000..df142839
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-214-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-215-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-215-t.png
new file mode 100755
index 00000000..819d010e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-215-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-216-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-216-t.png
new file mode 100755
index 00000000..abcb0d9b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-216-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-217-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-217-t.png
new file mode 100755
index 00000000..1ab3dbb5
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-217-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-218-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-218-t.png
new file mode 100755
index 00000000..08e970bf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-218-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-219-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-219-t.png
new file mode 100755
index 00000000..1a8bff44
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-219-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-22-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-22-t.png
new file mode 100755
index 00000000..c37f9fb0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-22-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-221-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-221-t.png
new file mode 100755
index 00000000..5626ebb7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-221-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-222-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-222-t.png
new file mode 100755
index 00000000..f14f212a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-222-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-225-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-225-t.png
new file mode 100755
index 00000000..6f2675bc
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-225-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-226-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-226-t.png
new file mode 100755
index 00000000..67e3e8ab
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-226-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-227-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-227-t.png
new file mode 100755
index 00000000..60bbe765
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-227-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-23-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-23-t.png
new file mode 100755
index 00000000..99d78234
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-23-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-24-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-24-t.png
new file mode 100755
index 00000000..084d07a3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-24-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-25-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-25-t.png
new file mode 100755
index 00000000..f74ea22c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-25-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-26-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-26-t.png
new file mode 100755
index 00000000..4af9010b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-26-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-27-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-27-t.png
new file mode 100755
index 00000000..0d76d509
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-27-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-28-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-28-t.png
new file mode 100755
index 00000000..df29f5e9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-28-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-29-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-29-t.png
new file mode 100755
index 00000000..7d2de934
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-29-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-30-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-30-t.png
new file mode 100755
index 00000000..e61b1b0e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-30-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-31-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-31-t.png
new file mode 100755
index 00000000..63a2815b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-31-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-32-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-32-t.png
new file mode 100755
index 00000000..477dd58d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-32-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-33-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-33-t.png
new file mode 100755
index 00000000..06dac6e1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-33-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-34-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-34-t.png
new file mode 100755
index 00000000..f1749cff
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-34-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-35-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-35-t.png
new file mode 100755
index 00000000..78b060fe
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-35-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-36-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-36-t.png
new file mode 100755
index 00000000..94771226
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-36-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-37-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-37-t.png
new file mode 100755
index 00000000..18d6884e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-37-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-38-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-38-t.png
new file mode 100755
index 00000000..4b4fa9b5
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-38-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-39-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-39-t.png
new file mode 100755
index 00000000..2ee685a3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-39-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-40-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-40-t.png
new file mode 100755
index 00000000..c805ab7b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-40-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-41-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-41-t.png
new file mode 100755
index 00000000..b2eda253
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-41-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-44-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-44-t.png
new file mode 100755
index 00000000..d48a7d6c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-44-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-46-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-46-t.png
new file mode 100755
index 00000000..f2ee4d2b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-46-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-52-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-52-t.png
new file mode 100755
index 00000000..5b2803e7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-52-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-53-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-53-t.png
new file mode 100755
index 00000000..a7610865
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-53-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-61-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-61-t.png
new file mode 100755
index 00000000..64ca8c22
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-61-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-64-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-64-t.png
new file mode 100755
index 00000000..671f2121
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-64-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-65-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-65-t.png
new file mode 100755
index 00000000..1de58f77
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-65-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-66-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-66-t.png
new file mode 100755
index 00000000..becd0866
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-66-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-67-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-67-t.png
new file mode 100755
index 00000000..87d6a0e0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-67-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-68-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-68-t.png
new file mode 100755
index 00000000..53b0bed2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-68-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-69-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-69-t.png
new file mode 100755
index 00000000..cc649bbf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-69-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-70-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-70-t.png
new file mode 100755
index 00000000..b109407a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-70-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-77-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-77-t.png
new file mode 100755
index 00000000..547b7623
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-77-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-78-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-78-t.png
new file mode 100755
index 00000000..722d702c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-78-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-80-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-80-t.png
new file mode 100755
index 00000000..b885f320
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-80-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-81-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-81-t.png
new file mode 100755
index 00000000..f6bc32ea
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-81-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-82-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-82-t.png
new file mode 100755
index 00000000..cfe073bb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-82-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-83-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-83-t.png
new file mode 100755
index 00000000..c09c7a6b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-83-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-84-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-84-t.png
new file mode 100755
index 00000000..8ebd1ae3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-84-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-85-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-85-t.png
new file mode 100755
index 00000000..da371cbb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-85-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-86-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-86-t.png
new file mode 100755
index 00000000..174e7bab
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/animate-elem-86-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/conf-reader-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/conf-reader-201-t.png
new file mode 100755
index 00000000..7d5955eb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/conf-reader-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-201-t.png
new file mode 100755
index 00000000..f93408c2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-202-t.png
new file mode 100755
index 00000000..9c4a534b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-203-t.png
new file mode 100755
index 00000000..b594aa4a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-204-t.png
new file mode 100755
index 00000000..39529dd3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-constr-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-coord-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-coord-01-t.png
new file mode 100755
index 00000000..b6e3c093
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-coord-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-pAR-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-pAR-201-t.png
new file mode 100755
index 00000000..95a29f6d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-pAR-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-01-t.png
new file mode 100755
index 00000000..a2823354
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-02-t.png
new file mode 100755
index 00000000..7e5ba74a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-03-t.png
new file mode 100755
index 00000000..75233de7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-04-t.png
new file mode 100755
index 00000000..c6fc002d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-05-t.png
new file mode 100755
index 00000000..16e9cc0b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-06-t.png
new file mode 100755
index 00000000..ed86cf17
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-07-t.png
new file mode 100755
index 00000000..c21d9a6c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-08-t.png
new file mode 100755
index 00000000..46cff6f8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-09-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-09-t.png
new file mode 100755
index 00000000..8e2eb21a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-trans-09-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-units-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-units-01-t.png
new file mode 100755
index 00000000..1dcae09f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-units-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-viewattr-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-viewattr-05-t.png
new file mode 100755
index 00000000..92f21273
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/coords-viewattr-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/extend-namespace-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/extend-namespace-02-t.png
new file mode 100755
index 00000000..1d1f555d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/extend-namespace-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-desc-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-desc-02-t.png
new file mode 100755
index 00000000..d8177875
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-desc-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-01-t.png
new file mode 100755
index 00000000..76622802
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-02-t.png
new file mode 100755
index 00000000..6b1beda9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-03-t.png
new file mode 100755
index 00000000..bb1cedad
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-06-t.png
new file mode 100755
index 00000000..0aea0f72
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-elem-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-02-t.png
new file mode 100755
index 00000000..8ca78931
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-03-t.png
new file mode 100755
index 00000000..b70b0ea2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-04-t.png
new file mode 100755
index 00000000..2e5d26bd
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-201-t.png
new file mode 100755
index 00000000..a0ba0938
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-202-t.png
new file mode 100755
index 00000000..0df793e2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-203-t.png
new file mode 100755
index 00000000..546097b2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-glyph-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-kern-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-kern-01-t.png
new file mode 100755
index 00000000..26a55e29
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-kern-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-overview-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-overview-201-t.png
new file mode 100755
index 00000000..c1a9fae9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/fonts-overview-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-dom-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-dom-02-t.png
new file mode 100755
index 00000000..6bbf9829
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-dom-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-201-t.png
new file mode 100755
index 00000000..74f23f8a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-202-t.png
new file mode 100755
index 00000000..3105be71
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-203-t.png
new file mode 100755
index 00000000..ee67e690
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-event-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-201-t.png
new file mode 100755
index 00000000..e72ec0c2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-202-t.png
new file mode 100755
index 00000000..0a2c4c1a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-203-t.png
new file mode 100755
index 00000000..e9c42324
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-204-t.png
new file mode 100755
index 00000000..b871fa0b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-205-t.png
new file mode 100755
index 00000000..7c09bb58
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-206-t.png
new file mode 100755
index 00000000..0829fa2e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-207-t.png
new file mode 100755
index 00000000..771dc3f6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-208-t.png
new file mode 100755
index 00000000..d3bcda71
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-209-t.png
new file mode 100755
index 00000000..589df465
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-210-t.png
new file mode 100755
index 00000000..bd8b8740
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-211-t.png
new file mode 100755
index 00000000..718f6475
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-212-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-212-t.png
new file mode 100755
index 00000000..688f96ce
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-focus-212-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-04-t.png
new file mode 100755
index 00000000..9ee10594
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-05-t.png
new file mode 100755
index 00000000..2eb2dbc5
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-06-t.png
new file mode 100755
index 00000000..46e9c316
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-order-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-02-t.png
new file mode 100755
index 00000000..bdc11dc0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-05-t.png
new file mode 100755
index 00000000..3e4b2392
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-06-t.png
new file mode 100755
index 00000000..e34479e7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-07-t.png
new file mode 100755
index 00000000..3761f633
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-08-t.png
new file mode 100755
index 00000000..83f21f0a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-pevents-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-01-t.png
new file mode 100755
index 00000000..9bebc0f9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-02-t.png
new file mode 100755
index 00000000..fa8f76d6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-03-t.png
new file mode 100755
index 00000000..237d06dc
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/interact-zoom-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/intro-compat-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/intro-compat-201-t.png
new file mode 100755
index 00000000..ae915605
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/intro-compat-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-201-t.png
new file mode 100755
index 00000000..e2fbd038
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-202-t.png
new file mode 100755
index 00000000..6d818bed
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-203-t.png
new file mode 100755
index 00000000..7b7d7d05
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-204-t.png
new file mode 100755
index 00000000..af74f971
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-205-t.png
new file mode 100755
index 00000000..9779a85b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-206-t.png
new file mode 100755
index 00000000..ff9a3a1e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-207-t.png
new file mode 100755
index 00000000..4b687aee
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-208-t.png
new file mode 100755
index 00000000..ca3baf95
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-209-t.png
new file mode 100755
index 00000000..cfe1531a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/jpeg-required-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-03-t.png
new file mode 100755
index 00000000..261fec3d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-08-t.png
new file mode 100755
index 00000000..1ae55606
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-201-t.png
new file mode 100755
index 00000000..0c32cd0b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-a-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-201-t.png
new file mode 100755
index 00000000..1ae55606
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-202-t.png
new file mode 100755
index 00000000..347f2909
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-203-t.png
new file mode 100755
index 00000000..b4af39e5
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-204-t.png
new file mode 100755
index 00000000..f0bb96b0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-frag-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-201-t.png
new file mode 100755
index 00000000..a0c54a4a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-202-t.png
new file mode 100755
index 00000000..9fdd11e3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-203-t.png
new file mode 100755
index 00000000..cae515ff
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-204-t.png
new file mode 100755
index 00000000..e235cc00
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-205-t.png
new file mode 100755
index 00000000..7e1e6625
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-206-t.png
new file mode 100755
index 00000000..f48cf76d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-refs-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-uri-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-uri-03-t.png
new file mode 100755
index 00000000..1ae55606
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/linking-uri-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-201-t.png
new file mode 100755
index 00000000..87f86aef
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-202-t.png
new file mode 100755
index 00000000..5f0c01a8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-203-t.png
new file mode 100755
index 00000000..a6e0552c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-204-t.png
new file mode 100755
index 00000000..a7e98584
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-205-t.png
new file mode 100755
index 00000000..8205be9e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-206-t.png
new file mode 100755
index 00000000..f9456ee6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-207-t.png
new file mode 100755
index 00000000..034eb93a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-208-t.png
new file mode 100755
index 00000000..9519bfa5
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-alevel-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-201-t.png
new file mode 100755
index 00000000..5d58595d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-202-t.png
new file mode 100755
index 00000000..6115d015
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-203-t.png
new file mode 100755
index 00000000..c9d55ea6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-204-t.png
new file mode 100755
index 00000000..4140ff94
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-205-t.png
new file mode 100755
index 00000000..b97743d0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-206-t.png
new file mode 100755
index 00000000..8ab05a0e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-207-t.png
new file mode 100755
index 00000000..a8cc40fd
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-208-t.png
new file mode 100755
index 00000000..b619a247
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-209-t.png
new file mode 100755
index 00000000..5869748f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-210-t.png
new file mode 100755
index 00000000..36d1b015
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-211-t.png
new file mode 100755
index 00000000..abeb5ab4
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-212-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-212-t.png
new file mode 100755
index 00000000..7a01dca4
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-212-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-213-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-213-t.png
new file mode 100755
index 00000000..b8036fbb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-anim-213-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-201-t.png
new file mode 100755
index 00000000..d2d49d8f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-202-t.png
new file mode 100755
index 00000000..2f351a43
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-203-t.png
new file mode 100755
index 00000000..acb99b47
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-204-t.png
new file mode 100755
index 00000000..0a35e401
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-205-t.png
new file mode 100755
index 00000000..0f37e5c8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-206-t.png
new file mode 100755
index 00000000..090e12ea
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-207-t.png
new file mode 100755
index 00000000..655636fe
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-208-t.png
new file mode 100755
index 00000000..b659c66c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-209-t.png
new file mode 100755
index 00000000..fd1682b7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-210-t.png
new file mode 100755
index 00000000..e36dd576
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-211-t.png
new file mode 100755
index 00000000..203e2653
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-212-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-212-t.png
new file mode 100755
index 00000000..ec37d1ce
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-212-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-213-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-213-t.png
new file mode 100755
index 00000000..f81ec524
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-213-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-214-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-214-t.png
new file mode 100755
index 00000000..228713d8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-214-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-215-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-215-t.png
new file mode 100755
index 00000000..d1b7494e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-audio-215-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-201-t.png
new file mode 100755
index 00000000..f44781ac
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-202-t.png
new file mode 100755
index 00000000..d53b7261
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-203-t.png
new file mode 100755
index 00000000..96c5d0bf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-204-t.png
new file mode 100755
index 00000000..6a630f99
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-205-t.png
new file mode 100755
index 00000000..5c2193ea
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-206-t.png
new file mode 100755
index 00000000..22bd54af
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-207-t.png
new file mode 100755
index 00000000..a8d616e7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-208-t.png
new file mode 100755
index 00000000..8e733f72
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-209-t.png
new file mode 100755
index 00000000..47398e21
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-210-t.png
new file mode 100755
index 00000000..f76f96f7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-211-t.png
new file mode 100755
index 00000000..4646f944
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-212-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-212-t.png
new file mode 100755
index 00000000..0e2cbe50
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-212-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-213-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-213-t.png
new file mode 100755
index 00000000..e6c2cb09
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-213-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-214-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-214-t.png
new file mode 100755
index 00000000..02921f70
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-214-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-215-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-215-t.png
new file mode 100755
index 00000000..ea848082
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-215-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-216-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-216-t.png
new file mode 100755
index 00000000..5b3bfe6a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-216-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-218-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-218-t.png
new file mode 100755
index 00000000..2310885b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-218-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-219-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-219-t.png
new file mode 100755
index 00000000..dd0af1b8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-219-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-220-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-220-t.png
new file mode 100755
index 00000000..0af47342
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-220-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-221-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-221-t.png
new file mode 100755
index 00000000..6be4eeb0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-221-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-222-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-222-t.png
new file mode 100755
index 00000000..6ce29e27
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/media-video-222-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/metadata-example-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/metadata-example-01-t.png
new file mode 100755
index 00000000..82cc9370
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/metadata-example-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-01-t.png
new file mode 100755
index 00000000..dd803f22
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-03-t.png
new file mode 100755
index 00000000..4042f7ed
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-04-t.png
new file mode 100755
index 00000000..e0909487
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-05-t.png
new file mode 100755
index 00000000..e3a5d241
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-201-t.png
new file mode 100755
index 00000000..fb1166d2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-color-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-01-t.png
new file mode 100755
index 00000000..98295535
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-02-t.png
new file mode 100755
index 00000000..48da1fe1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-03-t.png
new file mode 100755
index 00000000..8052d9ea
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-04-t.png
new file mode 100755
index 00000000..f5ae8fa0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-05-t.png
new file mode 100755
index 00000000..c3c57244
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-fill-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-04-t.png
new file mode 100755
index 00000000..55043fec
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-05-t.png
new file mode 100755
index 00000000..e52f0a7c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-07-t.png
new file mode 100755
index 00000000..a5d4893a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-08-t.png
new file mode 100755
index 00000000..c9c1a54d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-09-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-09-t.png
new file mode 100755
index 00000000..412cab65
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-09-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-11-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-11-t.png
new file mode 100755
index 00000000..d47f9e8c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-11-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-12-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-12-t.png
new file mode 100755
index 00000000..b1b7032f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-12-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-15-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-15-t.png
new file mode 100755
index 00000000..31091162
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-15-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-16-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-16-t.png
new file mode 100755
index 00000000..2febd9c3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-16-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-17-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-17-t.png
new file mode 100755
index 00000000..12153649
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-17-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-18-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-18-t.png
new file mode 100755
index 00000000..068dbc7c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-18-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-19-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-19-t.png
new file mode 100755
index 00000000..428e2447
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-19-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-201-t.png
new file mode 100755
index 00000000..e5cfc6d2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-202-t.png
new file mode 100755
index 00000000..69521572
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-203-t.png
new file mode 100755
index 00000000..c0e0e360
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-204-t.png
new file mode 100755
index 00000000..c4e27d8b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-205-t.png
new file mode 100755
index 00000000..834c91dd
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-grad-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-nsstroke-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-nsstroke-201-t.png
new file mode 100755
index 00000000..b1ec6785
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-nsstroke-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-nsstroke-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-nsstroke-203-t.png
new file mode 100755
index 00000000..caed69f8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-nsstroke-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-other-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-other-201-t.png
new file mode 100755
index 00000000..a5b89e55
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-other-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-other-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-other-203-t.png
new file mode 100755
index 00000000..eb2fe856
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-other-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-01-t.png
new file mode 100755
index 00000000..2faa9616
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-02-t.png
new file mode 100755
index 00000000..015aa84f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-03-t.png
new file mode 100755
index 00000000..c82fbe47
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-04-t.png
new file mode 100755
index 00000000..c9983ee1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-05-t.png
new file mode 100755
index 00000000..8e41cb86
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-06-t.png
new file mode 100755
index 00000000..623064cc
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-07-t.png
new file mode 100755
index 00000000..62a53eed
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-08-t.png
new file mode 100755
index 00000000..dc194c50
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-201-t.png
new file mode 100755
index 00000000..0da4a4d9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-202-t.png
new file mode 100755
index 00000000..b304236a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-204-t.png
new file mode 100755
index 00000000..f03d9f27
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-205-t.png
new file mode 100755
index 00000000..30859291
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-207-t.png
new file mode 100755
index 00000000..5c1386f9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-stroke-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-201-t.png
new file mode 100755
index 00000000..8532a1d0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-202-t.png
new file mode 100755
index 00000000..6c4e1877
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-203-t.png
new file mode 100755
index 00000000..67bd3fc3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-204-t.png
new file mode 100755
index 00000000..05c62371
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-205-t.png
new file mode 100755
index 00000000..4de96945
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-206-t.png
new file mode 100755
index 00000000..4831b262
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paint-vfill-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-01-t.png
new file mode 100755
index 00000000..0763b115
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-02-t.png
new file mode 100755
index 00000000..e71ac990
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-04-t.png
new file mode 100755
index 00000000..308d9a22
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-05-t.png
new file mode 100755
index 00000000..eaacddff
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-06-t.png
new file mode 100755
index 00000000..1264a2ae
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-07-t.png
new file mode 100755
index 00000000..98bed0e8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-08-t.png
new file mode 100755
index 00000000..a7cc2650
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-09-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-09-t.png
new file mode 100755
index 00000000..d42f8368
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-09-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-10-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-10-t.png
new file mode 100755
index 00000000..aeaa7457
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-10-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-12-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-12-t.png
new file mode 100755
index 00000000..04bbf33f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-12-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-13-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-13-t.png
new file mode 100755
index 00000000..7d163065
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-13-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-14-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-14-t.png
new file mode 100755
index 00000000..e643351e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-14-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-15-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-15-t.png
new file mode 100755
index 00000000..7743c18f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/paths-data-15-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-01-t.png
new file mode 100755
index 00000000..f96a57b3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-02-t.png
new file mode 100755
index 00000000..9bfc6c49
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-03-t.png
new file mode 100755
index 00000000..6e0021fe
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-06-t.png
new file mode 100755
index 00000000..ad601eb0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-07-t.png
new file mode 100755
index 00000000..b15148ad
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-08-t.png
new file mode 100755
index 00000000..87a4fcee
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-elems-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-groups-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-groups-01-t.png
new file mode 100755
index 00000000..65dd2eaf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-groups-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/render-groups-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-groups-03-t.png
new file mode 100755
index 00000000..872ec6e0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/render-groups-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-201-t.png
new file mode 100755
index 00000000..1211836d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-202-t.png
new file mode 100755
index 00000000..c3d84eb7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-203-t.png
new file mode 100755
index 00000000..6aaa9971
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-element-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-05-t.png
new file mode 100755
index 00000000..24f4169f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-06-t.png
new file mode 100755
index 00000000..d01a19fb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-07-t.png
new file mode 100755
index 00000000..b5691c4c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-08-t.png
new file mode 100755
index 00000000..7f01cc62
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-201-t.png
new file mode 100755
index 00000000..7c957366
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-202-t.png
new file mode 100755
index 00000000..bffb79b3
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-handle-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-201-t.png
new file mode 100755
index 00000000..f6d35345
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-202-t.png
new file mode 100755
index 00000000..e21d7a67
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-203-t.png
new file mode 100755
index 00000000..421dd420
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-204-t.png
new file mode 100755
index 00000000..77106829
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/script-listener-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-01-t.png
new file mode 100755
index 00000000..fc736c18
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-02-t.png
new file mode 100755
index 00000000..5e8821da
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-03-t.png
new file mode 100755
index 00000000..89274c19
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-circle-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-01-t.png
new file mode 100755
index 00000000..d61784ce
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-02-t.png
new file mode 100755
index 00000000..678a10ca
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-03-t.png
new file mode 100755
index 00000000..ca1d2690
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-ellipse-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-intro-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-intro-01-t.png
new file mode 100755
index 00000000..1f26cfae
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-intro-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-line-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-line-01-t.png
new file mode 100755
index 00000000..2d67bdc6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-line-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-line-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-line-02-t.png
new file mode 100755
index 00000000..7805e20d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-line-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polygon-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polygon-01-t.png
new file mode 100755
index 00000000..a40d1e0d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polygon-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polygon-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polygon-02-t.png
new file mode 100755
index 00000000..55589a9e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polygon-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polyline-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polyline-01-t.png
new file mode 100755
index 00000000..5809ec3f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polyline-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polyline-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polyline-02-t.png
new file mode 100755
index 00000000..780b549b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-polyline-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-01-t.png
new file mode 100755
index 00000000..97332cba
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-02-t.png
new file mode 100755
index 00000000..97ff79e4
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-03-t.png
new file mode 100755
index 00000000..3ee8a450
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/shapes-rect-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-class-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-class-201-t.png
new file mode 100755
index 00000000..aa396188
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-class-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-common-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-common-201-t.png
new file mode 100755
index 00000000..2b76df40
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-common-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-01-t.png
new file mode 100755
index 00000000..013bfcd8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-02-t.png
new file mode 100755
index 00000000..129d396e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-03-t.png
new file mode 100755
index 00000000..365c5c47
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-204-t.png
new file mode 100755
index 00000000..b0b45471
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-205-t.png
new file mode 100755
index 00000000..8b870624
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-209-t.png
new file mode 100755
index 00000000..59336c55
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-210-t.png
new file mode 100755
index 00000000..e1827f50
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-cond-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-defs-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-defs-01-t.png
new file mode 100755
index 00000000..78289bb9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-defs-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-defs-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-defs-201-t.png
new file mode 100755
index 00000000..58d6a62f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-defs-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-201-t.png
new file mode 100755
index 00000000..ca4098dc
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-204-t.png
new file mode 100755
index 00000000..5f0f66ef
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-205-t.png
new file mode 100755
index 00000000..1ef7306d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-206-t.png
new file mode 100755
index 00000000..fe001cab
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-207-t.png
new file mode 100755
index 00000000..dd3e77ee
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-discard-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-02-t.png
new file mode 100755
index 00000000..f664dccf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-03-t.png
new file mode 100755
index 00000000..f664dccf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-04-t.png
new file mode 100755
index 00000000..f664dccf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-05-t.png
new file mode 100755
index 00000000..4a67b668
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-06-t.png
new file mode 100755
index 00000000..a2536157
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-frag-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-group-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-group-01-t.png
new file mode 100755
index 00000000..b6ed68a1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-group-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-group-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-group-03-t.png
new file mode 100755
index 00000000..33af2e4b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-group-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-01-t.png
new file mode 100755
index 00000000..fe72ad91
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-03-t.png
new file mode 100755
index 00000000..851e0621
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-04-t.png
new file mode 100755
index 00000000..14db00cb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-06-t.png
new file mode 100755
index 00000000..1dcc496e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-07-t.png
new file mode 100755
index 00000000..fc03c92d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-08-t.png
new file mode 100755
index 00000000..a45e4383
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-09-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-09-t.png
new file mode 100755
index 00000000..4dd9d24e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-09-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-10-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-10-t.png
new file mode 100755
index 00000000..26565842
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-image-10-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-201-t.png
new file mode 100755
index 00000000..2eda2641
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-202-t.png
new file mode 100755
index 00000000..98344163
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-203-t.png
new file mode 100755
index 00000000..85bf2e2c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-204-t.png
new file mode 100755
index 00000000..ce5bee7d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-progressive-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-201-t.png
new file mode 100755
index 00000000..26c2c487
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-202-t.png
new file mode 100755
index 00000000..d3af90c6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-203-t.png
new file mode 100755
index 00000000..0d30b65a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-204-t.png
new file mode 100755
index 00000000..5163766f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-svg-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-01-t.png
new file mode 100755
index 00000000..2d0b0d49
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-03-t.png
new file mode 100755
index 00000000..7b279d81
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-09-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-09-t.png
new file mode 100755
index 00000000..da362eec
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-09-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-201-t.png
new file mode 100755
index 00000000..bb6d4fbd
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-202-t.png
new file mode 100755
index 00000000..a6922007
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-203-t.png
new file mode 100755
index 00000000..edbe10d4
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-204-t.png
new file mode 100755
index 00000000..edbe10d4
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-205-t.png
new file mode 100755
index 00000000..fcfb6ca2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-206-t.png
new file mode 100755
index 00000000..cf87b28b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-207-t.png
new file mode 100755
index 00000000..38616b14
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-208-t.png
new file mode 100755
index 00000000..88a9cae6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-209-t.png
new file mode 100755
index 00000000..8631317d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-01-t.png
new file mode 100755
index 00000000..a855e41b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-02-t.png
new file mode 100755
index 00000000..656f6587
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-03-t.png
new file mode 100755
index 00000000..7b5419f1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/struct-use-recursion-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-01-t.png
new file mode 100755
index 00000000..a200f371
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-02-t.png
new file mode 100755
index 00000000..231433bd
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-03-t.png
new file mode 100755
index 00000000..8ccffe9a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-inherit-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-pres-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-pres-01-t.png
new file mode 100755
index 00000000..388090e1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/styling-pres-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-01-t.png
new file mode 100755
index 00000000..defff52d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-07-t.png
new file mode 100755
index 00000000..2b9dbe3d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-08-t.png
new file mode 100755
index 00000000..6d4eca3c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-201-t.png
new file mode 100755
index 00000000..d01c521d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-202-t.png
new file mode 100755
index 00000000..83a2f6f7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-align-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-201-t.png
new file mode 100755
index 00000000..67d2fa20
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-202-t.png
new file mode 100755
index 00000000..7b2392fb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-203-t.png
new file mode 100755
index 00000000..86ce9ed6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-204-t.png
new file mode 100755
index 00000000..6f1602b5
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-205-t.png
new file mode 100755
index 00000000..c07e8f4d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-206-t.png
new file mode 100755
index 00000000..db87c484
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-207-t.png
new file mode 100755
index 00000000..833a976d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-208-t.png
new file mode 100755
index 00000000..d672a2b8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-209-t.png
new file mode 100755
index 00000000..e36e24ef
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-210-t.png
new file mode 100755
index 00000000..a1708c9f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-211-t.png
new file mode 100755
index 00000000..01a5a342
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-213-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-213-t.png
new file mode 100755
index 00000000..4075ce66
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-213-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-220-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-220-t.png
new file mode 100755
index 00000000..e5553e4c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-220-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-221-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-221-t.png
new file mode 100755
index 00000000..34f9ef96
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-221-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-222-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-222-t.png
new file mode 100755
index 00000000..26e2f5d1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-area-222-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-edit-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-edit-201-t.png
new file mode 100755
index 00000000..ea486df7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-edit-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-01-t.png
new file mode 100755
index 00000000..100fac66
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-02-t.png
new file mode 100755
index 00000000..eaa35c9c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-03-t.png
new file mode 100755
index 00000000..53af40fe
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-04-t.png
new file mode 100755
index 00000000..3ff82d99
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-202-t.png
new file mode 100755
index 00000000..a5700b3b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-fonts-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-01-t.png
new file mode 100755
index 00000000..acc22b65
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-04-t.png
new file mode 100755
index 00000000..6e66dd7c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-05-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-05-t.png
new file mode 100755
index 00000000..1e2e7844
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-05-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-06-t.png
new file mode 100755
index 00000000..73fe921a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-201-t.png
new file mode 100755
index 00000000..9698ab07
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-intro-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-04-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-04-t.png
new file mode 100755
index 00000000..7e42e78a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-04-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-06-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-06-t.png
new file mode 100755
index 00000000..5527e310
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-06-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-07-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-07-t.png
new file mode 100755
index 00000000..52f846f1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-07-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-08-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-08-t.png
new file mode 100755
index 00000000..4bdfda2c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-08-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-09-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-09-t.png
new file mode 100755
index 00000000..7c4ce3aa
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-text-09-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-tselect-03-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-tselect-03-t.png
new file mode 100755
index 00000000..53ef3160
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-tselect-03-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-ws-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-ws-01-t.png
new file mode 100755
index 00000000..6cb19868
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-ws-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/text-ws-02-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-ws-02-t.png
new file mode 100755
index 00000000..4ba9c1a7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/text-ws-02-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-conform-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-conform-201-t.png
new file mode 100755
index 00000000..c1824fc6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-conform-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-201-t.png
new file mode 100755
index 00000000..779e82b4
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-202-t.png
new file mode 100755
index 00000000..1b4b8360
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-203-t.png
new file mode 100755
index 00000000..ca850099
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-204-t.png
new file mode 100755
index 00000000..868f2797
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-206-t.png
new file mode 100755
index 00000000..9a713444
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-207-t.png
new file mode 100755
index 00000000..51c76caa
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-209-t.png
new file mode 100755
index 00000000..bfe2d4e6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-210-t.png
new file mode 100755
index 00000000..cface29c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-211-t.png
new file mode 100755
index 00000000..0d3ec84b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-213-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-213-t.png
new file mode 100755
index 00000000..51b42a69
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-dom-213-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-201-t.png
new file mode 100755
index 00000000..05c1755e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-202-t.png
new file mode 100755
index 00000000..3d4b7635
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-203-t.png
new file mode 100755
index 00000000..ed01767e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-204-t.png
new file mode 100755
index 00000000..10aeee5e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-205-t.png
new file mode 100755
index 00000000..975bbfa0
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-207-t.png
new file mode 100755
index 00000000..414cb766
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-208-t.png
new file mode 100755
index 00000000..6805d364
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-209-t.png
new file mode 100755
index 00000000..3d4b7635
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-210-t.png
new file mode 100755
index 00000000..c627a909
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-event-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-201-t.png
new file mode 100755
index 00000000..02b16ec7
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-202-t.png
new file mode 100755
index 00000000..1d7e8baf
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-203-t.png
new file mode 100755
index 00000000..227b950a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-204-t.png
new file mode 100755
index 00000000..e14cc46a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-glob-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-201-t.png
new file mode 100755
index 00000000..84d0b5bc
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-202-t.png
new file mode 100755
index 00000000..e4921eae
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-204-t.png
new file mode 100755
index 00000000..d71ae48d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-node-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-over-01-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-over-01-t.png
new file mode 100755
index 00000000..efba2e8d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-over-01-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-201-t.png
new file mode 100755
index 00000000..d0cf6572
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-202-t.png
new file mode 100755
index 00000000..1eab626e
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-203-t.png
new file mode 100755
index 00000000..92985b0d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-smil-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-201-t.png
new file mode 100755
index 00000000..506bc119
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-202-t.png
new file mode 100755
index 00000000..a4b22324
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-204-t.png
new file mode 100755
index 00000000..1cf7ad5f
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-205-t.png
new file mode 100755
index 00000000..093f6c0b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-206-t.png
new file mode 100755
index 00000000..2250f7a9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-208-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-208-t.png
new file mode 100755
index 00000000..e4bcd487
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-208-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-209-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-209-t.png
new file mode 100755
index 00000000..2ea6e49d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-209-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-210-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-210-t.png
new file mode 100755
index 00000000..ca263ac8
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-210-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-211-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-211-t.png
new file mode 100755
index 00000000..28e2ebff
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-211-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-213-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-213-t.png
new file mode 100755
index 00000000..dd2de5ef
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-213-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-216-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-216-t.png
new file mode 100755
index 00000000..3aea2390
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-216-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-218-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-218-t.png
new file mode 100755
index 00000000..0873092a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-218-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-220-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-220-t.png
new file mode 100755
index 00000000..ec9a5787
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-220-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-224-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-224-t.png
new file mode 100755
index 00000000..d72c198c
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-224-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-225-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-225-t.png
new file mode 100755
index 00000000..415822b2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-225-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-226-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-226-t.png
new file mode 100755
index 00000000..e98c779a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-226-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-227-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-227-t.png
new file mode 100755
index 00000000..c7726b89
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-227-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-228-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-228-t.png
new file mode 100755
index 00000000..918162ff
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-228-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-231-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-231-t.png
new file mode 100755
index 00000000..e1c18076
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-231-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-232-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-232-t.png
new file mode 100755
index 00000000..0f13a00a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-232-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-233-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-233-t.png
new file mode 100755
index 00000000..d0e453d9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-233-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-236-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-236-t.png
new file mode 100755
index 00000000..9f6b6b1b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-236-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-237-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-237-t.png
new file mode 100755
index 00000000..661bdfec
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svg-237-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgcolor-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgcolor-201-t.png
new file mode 100755
index 00000000..fe2d4d6a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgcolor-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-201-t.png
new file mode 100755
index 00000000..c2650293
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-202-t.png
new file mode 100755
index 00000000..f3e78818
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-203-t.png
new file mode 100755
index 00000000..2d6ce11a
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svglocatable-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-201-t.png
new file mode 100755
index 00000000..b5eb7b7b
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-202-t.png
new file mode 100755
index 00000000..bfdb1729
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-203-t.png
new file mode 100755
index 00000000..b8e006d9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-204-t.png
new file mode 100755
index 00000000..5e5ed2e9
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-205-t.png
new file mode 100755
index 00000000..e4eed813
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-206-t.png
new file mode 100755
index 00000000..46982fba
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgmatrix-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpath-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpath-201-t.png
new file mode 100755
index 00000000..92dfbcc1
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpath-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpath-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpath-202-t.png
new file mode 100755
index 00000000..a061ecda
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpath-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpoint-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpoint-201-t.png
new file mode 100755
index 00000000..3cefc99d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgpoint-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgrect-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgrect-201-t.png
new file mode 100755
index 00000000..a4c72ff5
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-svgrect-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-textcontent-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-textcontent-201-t.png
new file mode 100755
index 00000000..be16c665
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-textcontent-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-textcontent-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-textcontent-202-t.png
new file mode 100755
index 00000000..79e848bb
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-textcontent-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-201-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-201-t.png
new file mode 100755
index 00000000..020a2591
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-201-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-202-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-202-t.png
new file mode 100755
index 00000000..837b4908
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-202-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-203-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-203-t.png
new file mode 100755
index 00000000..fffd8e2d
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-203-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-204-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-204-t.png
new file mode 100755
index 00000000..290d97b6
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-204-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-205-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-205-t.png
new file mode 100755
index 00000000..79c04bf2
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-205-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-206-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-206-t.png
new file mode 100755
index 00000000..ddc9ac47
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-206-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-207-t.png b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-207-t.png
new file mode 100755
index 00000000..cc71e091
Binary files /dev/null and b/test/W3C_SVG_12_TinyTestSuite_beta/png/udom-traitaccess-207-t.png differ
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/resources/http_php.txt b/test/W3C_SVG_12_TinyTestSuite_beta/resources/http_php.txt
new file mode 100755
index 00000000..1d2a7197
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/resources/http_php.txt
@@ -0,0 +1,53 @@
+ "OK",
+ 201 => "Created",
+ 202 => "Accepted",
+ 203 => "Non-Authoritative Information",
+ 204 => "No Content",
+ 205 => "Reset Content",
+ 206 => "Partial Content",
+ 300 => "Multiple Choices",
+ 301 => "Moved Permanently",
+ 302 => "Found",
+ 303 => "See Other",
+ 304 => "Not Modified",
+ 305 => "Use Proxy",
+ 307 => "Temporary Redirect",
+ 400 => "Bad Request",
+ 401 => "Unauthorized",
+ 402 => "Payment Required",
+ 403 => "Forbidden",
+ 404 => "Not Found",
+ 405 => "Method Not Allowed",
+ 406 => "Not Acceptable",
+ 407 => "Proxy Authentication Required",
+ 408 => "Request timeout",
+ 409 => "Conflict",
+ 410 => "Gone",
+ 411 => "Length Required",
+ 412 => "Precondition failed",
+ 413 => "Request entityt too large",
+ 414 => "Request-URI too long",
+ 415 => "Unsupported Media Type",
+ 416 => "Requested Range Not Satisfiable",
+ 417 => "Expectation Failed",
+ 500 => "500 Internal Server Error",
+ 501 => "Not Implemented",
+ 502 => "Bad Gateway",
+ 503 => "Service Unavailable",
+ 504 => "Gateway Timeout",
+ 505 => "HTTP Version not Supported");
+ if (array_key_exists($_REQUEST["rc"],$allowedCodes)) {
+ header("HTTP/1.1 ".$_REQUEST["rc"]." ".$allowedCodes[$_REQUEST["rc"]]);
+ }
+ if (array_key_exists("redirect",$_REQUEST) && array_key_exists($_REQUEST["redirect"],$allowedCodes)) {
+ header("Location: http://www.w3.org/2008/04/http?rc=".$_REQUEST["redirect"]);
+ }
+}
+if (array_key_exists("content",$_REQUEST)) {
+ header("Content-Type: text/plain");
+ echo "ABCDEFGHI";
+}
+?>
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-02-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-02-t.svg
new file mode 100755
index 00000000..ea4d4593
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-02-t.svg
@@ -0,0 +1,83 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+ 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.
+
+ An animation moves a triangle along a path. Reference rectangles, lines and text are provided to help show what the
+ correct behavior is. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'from' and 'to' attributes to define the 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. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'values' attribute to define the motion path, with a linear calcMode.
+ An animation moves a triangle along a path. Reference rectangles, lines and text are provided to help show what
+ the correct behavior is. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'path' attribute to define the 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. The red text shows the way that the motion path is specified.
+
+
This animation uses the 'mpath' sub-element to define the motion path.
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+ $RCSfile: animate-elem-10-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ at 0 sec.
+ at 3 sec.
+ at 6 sec.
+ 9+ sec.
+
+
+
+
+
+
+
+
+
+
+
+
+ at 0 sec.
+ at 3 sec.
+ at 6 sec.
+ 9+ sec.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.9 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-11-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-11-t.svg
new file mode 100755
index 00000000..cc96d1b0
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-11-t.svg
@@ -0,0 +1,77 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+ $RCSfile: animate-elem-11-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ at 0 sec.
+ at 3 sec.
+ at 6 sec.
+ 9+ sec.
+
+
+
+
+
+
+
+
+
+
+
+ at 0 sec.
+ at 3 sec.
+ at 6 sec.
+ 9+ sec.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-12-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-12-t.svg
new file mode 100755
index 00000000..87bcec12
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-12-t.svg
@@ -0,0 +1,80 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+
+ $RCSfile: animate-elem-12-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ at 0 sec.
+ at 3 sec.
+ at 6 sec.
+ 9+ sec.
+
+
+
+
+
+
+
+
+
+
+
+ at 0 sec.
+ at 3 sec.
+ at 6 sec.
+ 9+ sec.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-13-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-13-t.svg
new file mode 100755
index 00000000..c8e696cf
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-13-t.svg
@@ -0,0 +1,88 @@
+
+
+
+
+
+
+
+
+
+
+
+
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 red text shows the attributes that were used for that particular animation.
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 test shows an animation with calcMode="discrete" (i.e., a jumping animation).
+ 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 test shows calcMode="paced" for an animation that has constant velocity, thus showing how 'values' and
+ 'keyTimes' are ignored.
+
+ 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.
+
+ 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".
+ 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 red square appearing, gradually and smoothly fading
+ from white to red over the course of three seconds.
+
+
+ The rendered picture should match the reference image, (except for possible variations in the labeling text
+ (per CSS2 rules)) after activating the link on the fade-in button the first time and waiting three seconds for the
+ animation to compete. The picture should remain looking the same way indefinitely, until another link is activated.
+
+
+ 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 red square goes from white to red. After the first click on "fade out", the red square goes from red
+ to white. After the second click on "fade in", however, the red square goes from white to red, and then goes back
+ from red to white. This is because of the hyperlinking rules as they relate to resolved start times in the SMIL
+ 2.1 specification.
+
+ Five orange rectangles have one animation each. When an
+ animation is active it moves its orange rectangle from its
+ left marker to its right marker. The active intervals
+ are [1-2], [4-6] and [8-10].
+
+ Precision test for accumulative animateMotion.
+
+
+ The main indication for a failed test is the appearence of something
+ red and that circles are not centered below the paths given in gray.
+
+
+ Circles are moved along squares given with the path attribute,
+ repeatDur and accumulate with a repeatDur of 30s and repetition.
+ Different values for the rotate attribute are given too, this has no visible effect,
+ because centered circles are moved.
+
+ Precision test for additive animateMotion using,
+ mpath element, path attribute, values, from-to.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the circle. A switch of the stroke of the circle from blue to gray indicates
+ the end of the test at 30s.
+
+
+ A circles is moved along some paths
+ (two of them indicated in gray) with
+ a duration of 30s using additive animateMotion.
+ The superposition is no motion.
+ The circle is positioned always at the bottom right.
+ The colour of the circle switches from blue to gray after
+ the animation is finished.
+ If the red center of the circle becomes visible, an error is
+ occured.
+
+ Precision test for linear animateMotion with separated path fragments,
+ mpath element, rotate auto.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the test circle. The circle has to follow exactly the paths given
+ in gray.
+
+
+ A linear animateMotion of a blue stroked square with a centered
+ circle is compared with four animateMotion of a red square
+ with a centered circle.
+ The motion of the red square is following the
+ combination of four animateMotion following on
+ each other and is the same as the motion of the blue
+ square, because the timing is choosen in such a way.
+ Therefore the blue square covers always the red one
+ completely.
+
+
+ The path is given in gray. The red fill of the circle
+ is always covered with the gray path.
+ Eight gray stroked markers are lightened, when the circle
+ is exactly above the marker. The red fill of the marker
+ is exactly covered by the blue stroked circle.
+ If something red gets visible, an error is occured
+ and the animateMotion is not linear.
+
+
+ The exact timing is calculated using an analytical
+ integration of the path length of the sub paths
+ (this is available for quadratic or linear curves).
+ With this method the path position and the
+ time can be determined as functions of the usual
+ parametrisation of the used Bézier curves.
+
+ Precision tests for animateMotion with animated mpath.
+
+
+ The main indication for a failed test is the appearence of something
+ red and that circles are not centered below the paths given in gray.
+
+
+ Blue rectangles and a red circles are moved along
+ light blue paths with a duration of 30s. The paths itself are animated.
+ This results in motions along the gray paths. The rectangles
+ are aligned along the animated light blue paths.
+ The circle is always covered by the path given in gray.
+ If something red gets visible, an error is occured.
+
+ Precision test for paced animateMotion with separated path fragments,
+ mpath element, rotate auto.
+
+
+ The main indication for a failed test is the appearence of the red fill
+ of the test circle. The circle has to follow exactly the paths given
+ in gray.
+
+
+ A paced animateMotion of a blue stroked square with a centered
+ circle is compared with four animateMotion of a red square
+ with a centered circle.
+ The motion of the red square is following the
+ combination of four animateMotion following on
+ each other and is the same as the motion of the blue
+ square, because the timing is choosen in such a way.
+ Therefore the blue square covers always the red one
+ completely.
+
+
+ The path is given in gray. The red fill of the circle
+ is always covered with the gray path.
+ Eight gray stroked markers are lightened, when the circle
+ is exactly above the marker. The red fill of the marker
+ is exactly covered by the blue stroked circle.
+ If something red gets visible, an error is occured
+ and the animateMotion is not paced.
+
+
+ The exact timing is calculated using an analytical
+ integration of the path length of the sub paths
+ (this is available for quadratic or linear curves).
+ With this method the path position and the
+ time can be determined as functions of the usual
+ parametrization of the used Bézier curves.
+
Compare from-to, from-by and by animate with values animate.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ Additionally set animations can be replaced by values animations too.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
values="0;a" additive="sum"
+
+
+
set to="a"
+
values="a" additive="replace" accumulate="none"
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space.)
+
+
+ The from-to, from-by and by animations applied to the attributes x, y, width, height
+ of blue rectangles are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red rectangles. Additionally underlying dark red
+ rectangles simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The blue rectangles cover all red rectangles. Therefore if something
+ red gets visible, an error is occured. Because fill is always not set and therefore remove,
+ the final value is only that of the set animation, not very interesting for the test.
+
+
+
+ $RCSfile: animate-elem-209-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ dark red values comparsion for from-to animations - if visible fail
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ red values comparsion for from-to animations - if visible fail
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blue from-to animations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ dark red values comparsion for from-by animations - if visible fail
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ red values comparsion for from-by animations - if visible fail
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blue from-by animations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ dark red values comparsion for by animations - if visible fail
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ red values comparsion for by animations - if visible fail
+
+
+
+
+
+
+
+
+
+
+
+
+
+ blue by animations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ compare by, from-by, from-to
+ with values animations
+ red=wrong
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-21-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-21-t.svg
new file mode 100755
index 00000000..5467c090
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-21-t.svg
@@ -0,0 +1,84 @@
+
+
+
+
+
+
+
+
+
+
+
+
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 red square appearing, gradually and smoothly fading
+ from white to red 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 red square.
+
+
+ The rendered picture should match the reference image, (except for possible variations in the labeling text
+ (per CSS2 rules)) after activating the link on the fade-in button the first time and waiting three seconds for the
+ animation to compete. The picture should remain looking the same way indefinitely, until another link is activated.
+
+
+ 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 red square goes from zero to 100% opacity. After the first click on "fade out", the red square goes
+ from red to white. After the second click on "fade in", however, the red square goes from white to red, and then
+ goes back from red to white. This is because of the hyperlinking rules as they relate to resolved start times in
+ the SMIL 2.1 specification.
+
Compare from-to, from-by and by animateColor with values animateColor and animate.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animations. Therefore they have to be the same as the related values animation.
+ Additionally set animations can be replaced by values animations too.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
values="0;a" additive="sum"
+
+
+
set to="a"
+
values="a" additive="replace" accumulate="none"
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. In the color space
+ 0 is represented by black, #000, #000000, rgb(0,0,0) etc. Addition is performed for each
+ of the three components of the color vector separately.)
+
+
+ The from-to, from-by and by animations applied to fill properties
+ of circles are compared with the related values animations including additive and
+ cumulative hehaviour for the stroke of the same circles. Additionally underlying
+ filled larger circles simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The fill of the background circle and stroke and fill of the smaller
+ test circle centered in it are always exactly the same. Therefore if
+ rings in each centered circle system with different color get visible, an error is occured.
+ But each separated circle system representing one of 12 subtests can have another color.
+ Because the fill attribute for animation is always not set and therefore remove,
+ the final value is only that of the set animation, not very interesting for the test.
+
Compare from-to, from-by and by animateMotion with values animateMotion.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateMotion
+ the '0' is no motion or is related to a translation given in coordinates: 0,0.)
+
+
+ The from-to, from-by and by are applied to animateMotion of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace. The blue paths cover all red paths. Therefore if something
+ red gets visible, an error is occured. Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateMotion, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform rotate (around zero) with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the rotate type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive rotate angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the rotate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform rotate with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the rotate type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive rotate angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the rotate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform scale with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the scale type this is a scaling with 0,0, this means no display if not added to another
+ value. Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive.)
+
+
+ The from-to, from-by and by are applied to animateTransform of the scale type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
+ Compare from-to, from-by and by animateTransform translate with values
+ animateTransform and animateMotion.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the translate type this is a translation given in coordinates: 0,0.)
+
+
+ The from-to, from-by and by are applied to animateTransform of the translate type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform skewX with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the skewX type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive skewX angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the skewX type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
Compare from-to, from-by and by animateTransform skewY with values animateTransform.
+
+ The main indication for a failed test is the appearance of red.
+
+
+ SMIL 2 specifies, how from-to, from-by and by animations have to be converted into
+ values animation. Therefore they have to be the same as the related values animation.
+ The conversion is as follows:
+
+
+
+
used
+
converted
+
+
+
from="a" to="b"
+
values="a;b"
+
+
+
from="a" by="b"
+
values="a;a+b"
+
+
+
by="a"
+
+ values="0;a" additive="sum"
+
+
+
+
+ (by and from-by animations have only a meaning, if values can be added somehow.
+ '0' is used as a general symbol for the neutral element of addition for the related attribute,
+ this means 0 + a = a + 0 = a. And '0' is not equal to the symbol '1' as the basic unit of the
+ related attribute, '0' is a predecessor of '1' in the related attribute space. For animateTransform
+ the '0' is the same as the zero matrix, not the unity or identity matrix.
+ For the skewY type this is a skew with an angle of 0.
+ Deviating from SMIL 2 in SVG it is specified, that for animateTranform the animation
+ effect has to be postmultiplied to the underlying value, if the animation is additive. Note
+ that for two additive skewY angles a, b the resulting angle is not a+b but atan(tan(a)+tan(b)).
+
+
+ The from-to, from-by and by are applied to animateTransform of the skewY type
+ of different blue stroked
+ paths and are compared with the related values animations including additive and
+ cumulative hehaviour for underlying red paths. Additionally underlying dark red
+ paths simulate the same behaviour using always the defaults additive replace and
+ accumulate replace with animateMotion. The blue paths cover all red paths.
+ Therefore if something red gets visible, an error is occured.
+ Because fill is always not set and therefore remove,
+ the final value is the value at 2s given with a simple values animateTransform, not very
+ interesting for the test.
+
+ xml:id or id? Identification of the element, that is target of an animation.
+ For authors it is recommended not to use different for id and xml:id for the same
+ element and not the same value for id in one element and the same value for
+ xml:id in another element. This is done in this document only as a (stupid) test,
+ not as an application.
+
+
+ The main indication for a failed test is the appearance of red or no animation after 2s.
+
+
+ Because for historical reasons, SVG tiny 1.2 has two fragment identifiers.
+ It is recommended, that xml:id is used and not only id. As a consequence
+ it is possible to have two different identifier values for one element.
+ In such a case, id is skipped and only xml:id has to be choosen.
+
+ In this test the height of the blue rectangle is set to another value. This is compared
+ with a set animation of another red rectangle, having the same value for xml:id and
+ id. The blue rectangle has to cover always the red one. If something red is visible,
+ an error is occured.
+
+ Identify the attributeType and the priority of an animation.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ With the top triangle is tested, that the points attribute of a
+ polygon is animated using attributeType auto or XML and
+ is not animated if CSS is used, because there is no CSS property
+ points applicable for the polygon element.
+
+
+ The bottom triangles test the priority for an animation with
+ attributeType CSS or auto over an XML animation, all for the
+ stroke attribute. Even if the attributeType is completely ignored,
+ the priority should still work for the bottom right triangle,
+ because the priority is set here with a later begin.
+
+
+ In all cases the coloring or positioning of elements is choosen in
+ such a way, that normally not visible lower priority or not
+ applicable animations are indicated with a red stroke,
+ higher priority or applicable animations with a blue stroke
+ or an animation in the blue range.
+
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 to big.
+
+ 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.
+
+
+
+ $RCSfile: animate-elem-22-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Yellow rect at time 0s
+
+ Yellow rect at time 3s
+
+ Yellow rect at time 9s
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.11 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-221-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-221-t.svg
new file mode 100755
index 00000000..181c07cc
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-221-t.svg
@@ -0,0 +1,98 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Correct timing with begin, end, dur, fill, max.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ Simple from to animations for cx and cy of a blue stroked
+ circle are stopped with max attributes.
+ The gray path gives the correct trajectory.
+ If the red center of the circle becomes visible, an error is
+ occured.
+
+ Correct timing with begin, end, dur, fill, min.
+
+
+ The main indication for a failed test is the appearance of red.
+
+
+ Simple from to animations for cx and cy of a blue stroked
+ circle are used with begin, dur, end, fill and min attributes and
+ correlated with syncbase values.
+ This is compared with simple animateMotion with the
+ same trajectory and timing.
+ The related red circle is always
+ covered by the blue stroke circle.
+ The gray path gives the correct trajectory.
+
+
+ The test is passed if the blue circle follows the defined path.
+ If part of the red circle becomes visible, the test is failed.
+
+
+
+ $RCSfile: animate-elem-222-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+ red comparison using animateMotion
+
+
+
+
+
+
+
+
+
+
+
+
+ blue test using from-to animate with begin, end, dur, min, fill
+
+
+
+
+
+
+
+
+
+
+
+
+ begin, end, dur, min
+ red=wrong
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-225-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-225-t.svg
new file mode 100755
index 00000000..e18811b7
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-225-t.svg
@@ -0,0 +1,64 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test verifies that error handling for the begin attribute is working.
+ An error in the begin-value-list means that the attribute as a whole is in error, and
+ that is the same as if the value was set to 'indefinite'.
+
+
+ There should be three green rects visible. If any of them turns red the test has failed.
+
+ The test is passed if you see a large swirly blue image, outlined in green. Below,
+ two smaller copies also outlined in green. Below that, a thick red outline that does
+ not have an image inside it. All three blue images with green outlines animate over
+ ten seconds, alternating between a blue and a pink image.
+ The animations all finish at the same time and display the pink image thereafter.
+
+
+ This tests the resolving of QNames in the attributeName attribute value. The
+ attribute tested is href, in the XLink namespace.
+
+
+ If an image is displayed on top of the red rectangle, or if the large image is not shown, or a
+ purple image with 'FAIL' is shown rather than blue, the implementation is using magic prefixes
+ and is only looking for the string 'xlink:href' rather than following the Namespaces in
+ XML specification.
+
+
+ If the right-most of the two small images animates but the left-most does not,
+ the implementation is only handling animation elements that are a direct child of
+ the element to be animated, and does not implement animation specified by an
+ XLink href. In that case, the large image will not animate either, but this does
+ not necessarily mean that namespace resolution is incorrect. (It does mean that
+ the test is failed, however).
+
+
+ If the two small images animate correctly but the large one does not, then
+ resolution of QNames in the 'attributeName' attribute is not following the
+ Namespaces in XML specification as required by the SVG specification.
+
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.
+
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.
+
+
+ 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.
+
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.
+
+
+
+ $RCSfile: animate-elem-25-t.svg,v $
+
+
+
+
+
+
+
+
+ Test animation options for specifying the target attribute/property.
+
+ 0-3 sec.
+
+ at 6 sec.
+
+
+
+
+ 0-6 sec.
+
+ at 9 sec.
+
+
+
+
+
+
+
+ $Revision: 1.9 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-26-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-26-t.svg
new file mode 100755
index 00000000..ebbd598c
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-26-t.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
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 red and stroked with blue appear, each with width=100 and height=200.
+ Starting at time 3 seconds and ending at time 6 seconds, the height of the leftmost rectangle decreases from 200
+ to 50. Starting at time 6 seconds and ending at time 9 seconds, the rightmost rectangle decreases from 200 to 50.
+ Annotations on the picture show the correct positions at particular times.
+
+
+
+ $RCSfile: animate-elem-27-t.svg,v $
+
+
+
+
+
+
+
+
+ Test animation options for specifying the target element.
+
+ 0 to 3 sec.
+
+ at 6 sec.
+
+
+
+ 0 to 6 sec.
+
+ at 9 sec.
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-28-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-28-t.svg
new file mode 100755
index 00000000..fc41580e
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-28-t.svg
@@ -0,0 +1,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test inheritance of animated properties.
+
+ A yellow happy face should be displayed. The stroke for the smile and yellow circle are both animated, the stroke
+ goes from "#F1E900" to "#FF0000".
+
+ 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 red 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 is composited on top of the animated red
+ square. Then, when you click on "fade out", the red 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 compete. The picture should remain looking the same way indefinitely, until another link is
+ activated.
+
+
+ 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 red square goes from zero to 100% opacity. After the first click on "fade out",
+ the red square goes from 100% to zero opacity. After the second click on "fade in", however, the red square goes
+ from zero to 100% opacity, and then goes back from 100% to zero opacity. This is because of the hyperlinking rules
+ as they relate to resolved start times in the SMIL 2.1 specification.
+
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).
+
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, red, blue, yellow, cyan) in 5 positions (blue and yellow
+ share position) that should be displayed during the test.
+
Tests the animation to and from the degenerate cases of the basic shapes. The shapes are drawn within the black rectangles.
+
+ The rendered picture should match the reference image at the end of the animation, except for possible variations in the
+ labelling text (per CSS2 rules).
+
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 16.2.13 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.
+
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.
+
+ 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.
+
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.
+
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. The static reference image shows the final state of the animation.
+
The purpose of this test is to test animation of the viewBox attribute.
+
+ This file tests animation of the viewBow attribute. 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.
+
+ 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.
+
+ 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.
+
+
+ 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. In most tests, 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.
+
+
+ The following animations should show continuous changes: fill, stroke, stroke-width, stroke-miterlimit,
+ stroke-dashoffset and color. Note that visually, stroke-miterlimit shows a sharp transition, but that is because
+ the miter is cut off when the animated miter limit reaches the test sharp angle's miter value. The stroke-miterlimit
+ value is changed continously but that is not visible in this test.
+
+
The following animations have a discrete behavior: fill-rule, stroke-linecap, stroke-linejoin, display and visibility.
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.
+
+
+
+ $RCSfile: animate-elem-44-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Animation on the 'd' attribute of path.
+ Digit should match outline at indicated time.
+ Filled circle should follow morphing digit discretely.
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-46-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-46-t.svg
new file mode 100755
index 00000000..4a4063a9
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-46-t.svg
@@ -0,0 +1,203 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
+
Only the animation of font-size should show a continuous change of the font size.
+
The following animations have a discrete behavior: text-anchor, font-family, font-style, font-weight.
+
+
+ $RCSfile: animate-elem-46-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ A
+
+ A
+
+ A
+
+
+
+
+
+
+
+
+ A
+ A
+ A
+
+
+
+
+ A
+ A
+ A
+
+
+
+
+ A
+ A
+ A
+
+
+
+
+ A
+ A
+ A
+
+
+
+
+ text-anchor
+ font-size
+ font-family
+ font-style
+ font-weight
+
+
+ <text>
+ <g>
+ <a>
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+ A
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+ A
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+ A
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+ A
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+ A
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-52-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-52-t.svg
new file mode 100755
index 00000000..edf26afa
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-52-t.svg
@@ -0,0 +1,103 @@
+
+
+
+
+
+
+
+
+
+
+
+
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 SMIL 2.1 are relevant as
+ confirmation of this test:
+
+
+
+
+
+ 10.4.1
+ subsection "Event values"
+ states: "If the Eventbase-element
+ term is missing, the event-base element defaults to the element on
+ which the eventbase timing is specified (the current element)."
+
+
+
+ 3.5.1
+ subsection "The target element"
+ says that the animation target may
+ be defined explicitly through the targetElement="" IDREF or href=""
+ URI, according to the host language. SVG Tiny 1.2 uses the
+ xlink:href="" attribute to specify the target element, so in this
+ test, the animation target is defined through xlink:href="" and the
+ event base per definition is then also this referenced element.
+
+
+
+
+
+ $RCSfile: animate-elem-52-t.svg,v $
+
+
+
+
+
+
+
+
+ A
+ B
+ C
+ D
+
+
+
+ click A
+
+
+
+ click B+2
+
+
+
+ click C+4
+
+
+
+ never
+
+
+
+
+
+ Test of Eventbase targets.
+ Note that clicking rect D should give no result.
+ Clicking a rectangle should change its color at the
+ time for the click + delay as indicated in each rect.
+
+
+ $Revision: 1.10 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-53-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-53-t.svg
new file mode 100755
index 00000000..b00a2452
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-53-t.svg
@@ -0,0 +1,127 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 red 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 "red 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 calcMode="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 red squares which are animated with
+ calcMode="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 red square (LR) is animated just as the LG square but
+ with calcMode="paced". The same applies to the right red square (RR)
+ that has default calcMode ("paced" for animateMotion) compared to the
+ RG square that has calcMode="linear".
+ The calcMode for the scale of RR (and RG) is not important since
+ it's not a value list type of animation.
+
+
+
+ $RCSfile: animate-elem-53-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0s
+
+ 3s
+
+ 6s
+
+ 9s
+
+
+
+
+
+
+
+
+
+
+
+
+ 0s
+
+ 2.22s
+
+ 6.66s
+
+ 8s
+
+
+
+
+
+
+
+
+
+
+ Animation on: 'points' with 'calc-mode'.
+ Colored and black squares should match at indicated time.
+ Same colored squares (green and red) should match at all times
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-61-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-61-t.svg
new file mode 100755
index 00000000..3d196447
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-61-t.svg
@@ -0,0 +1,140 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
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.
+
+ 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.
+
+ 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[.
+
+
+
+ $RCSfile: animate-elem-66-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ max
+ min & max
+
+
+ no max / media
+ invalid max values
+ max < active dur
+ max > active dur
+ min < max
+ min = max
+ min > max (both ignored)
+
+
+ > 5s
+ 0s-5s
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-67-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-67-t.svg
new file mode 100755
index 00000000..3eeda464
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-67-t.svg
@@ -0,0 +1,137 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+ 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).
+
+ 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).
+
+ 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.
+
+ 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.
+
+
+
+ $RCSfile: animate-elem-77-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ A
+ A
+
+
+
+
+ A
+ A
+
+
+
+
+ A
+ A
+
+
+
+
+ A
+ A
+
+
+
+
+ A
+ A
+
+
+
+
+ A
+ A
+
+
+ text
+
+
+ transform
+ text-anchor
+ font-size
+ font-family
+ font-style
+ font-weight
+
+
+ <text>
+ <g>
+ <a>
+
+
+ A
+
+
+
+
+ A
+
+
+
+
+ A
+
+
+
+ A
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+ A
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-78-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-78-t.svg
new file mode 100755
index 00000000..392220d2
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/animate-elem-78-t.svg
@@ -0,0 +1,427 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ 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> animations are applied. The first <set>
+ element acts directly on 'Basic Shape' elements. 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 'Basic Shape' element. All
+ the <set> elements have a begin attribute set to 0s with an offset of 1s after the 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.
+
+ 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.
+
+ This test validates the operation of the animateTransform's additive behavior, as described in the SVG 1.1
+ specification (see http://www.w3.org/TR/SVG11/animate.html#AnimateTransformElement).
+
+
+ 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
+ roduce 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(1,1)
+ 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 concatenated 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, so is the result of previous animation iterations.
+ Consequently, the transform goes from "skewX(30) scale(1,1)" to "skewX(30) scale(2,2)" for the first iteration
+ and then from "skewX(30) scale(2,2) scale(1,1)" to "skewX(30) scale(2,2) scale(2,2)" for the second iteration.
+
+ 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). The total length along the sx component is 2 + 2 = 4. The total length along the sy component is
+ 0 + 1 = 1. At 0s, the expected transform is scale(1,2). At 1.5s, the expected transform is scale(3,1.5) so that a
+ length of 2 has been run on the sx component and a length of 0.5 has been run on the sy component. At 3s, the
+ expected transform is scale(3,2).
+
+
+ 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).
+
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).
+
Test animation of color keywords that resolve to animatable RGB values.
+
+ Five black squares are shown. After two seconds, all five squares should turn red and then smoothly animate the
+ fill color to green over the next five seconds.
+
All four rectangles at the top must smoothly animate from black to green over 5 seconds.
+
+ During this time the bottom two rectangles must be red. Then, the bottom two rectangles must smoothly animate
+ from green( at five seconds), through khaki (at 7.5 seconds), to yellow (at 10 seconds and above). Colored
+ circles indicate the appropriate colors at these times.
+
+ This test tests fill="freeze" for the case where the duration has been constrained by an 'end' attribute
+ and calcMode="discrete".
+
+
+ The correct behaviour is defined by the SMIL time interval model.
+ Time intervals created by the test case from implicit begin, dur and calcMode discrete:
+
+
+
+ [0;2s) This means time including 0 seconds until (but not including) time 2 seconds
+
+
+ [2s;4s) Time including time 2 seconds until (but not including) time 4 seconds
+
+
+
+ Time intervals created by implicit begin and end:
+
+
+
[0;2s)
+
+
+ Therefore the frozen value will be 74, resulting in the purple fill
+ being in the right rectangle after 0 seconds.
+
+
+ The test has passed if the purple fill is on the right rect only after 0 seconds.
+ Fill must never be set to purple on the left rect, except for before the animation has begun.
+
+ 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.
+
+
+ The second subtest generates a new prefix string, and makes sure it's not equal to the first prefix string.
+ Then an svg fragment is generated as a string, to be parsed by a call to the parseXML method.
+ The 'xlink' prefix is bound to the "http://example.net/bar" namespace, and the generated prefix is bound to the XLink namespace.
+ Similar to the first subtest, the image has two references but only one attribute is actually in the XLink namespace.
+ The fragment is parsed and the result is inserted into the document, which should make the 'image' element visible.
+ If an exception is thrown during the parsing or the insertion of the result output will be shown in the status part of the testcase.
+
+
+ The testcase has passed if after the script execution has taken place these conditions are met:
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ The test will pass if, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+ The reference image displays the file after performing a user agent zoom.
+
+
+
+ $RCSfile: coords-constr-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Constrained Transformations
+
+
+
+ Can be panned, rotated and scaled by the user agent transform.
+
+
+
+ Cannot be transformed by the user agent transform.
+
+
+
+ Cannot be transformed by the user agent transform.
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-202-t.svg
new file mode 100755
index 00000000..0e32e297
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-202-t.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ An animation is applied to the viewBox attribute.
+ The test will pass if the circles are affected by the viewBox animation and, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+
+
+
+ $RCSfile: coords-constr-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Constrained Transformations
+ Animation of the viewBox. Nothing should be constrained during the animation.
+
+
+
+ Can be panned, rotated and scaled by the user agent transform.
+
+
+
+ Cannot be transformed by the user agent transform.
+
+
+
+ Cannot be transformed by the user agent transform.
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-203-t.svg
new file mode 100755
index 00000000..254da470
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-203-t.svg
@@ -0,0 +1,76 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test Constrained Transformations
+ There are three lines of text in this test.
+ The first is not constrained.
+ The second is constrained with a x and y offset.
+ The third is constrained.
+ An animation is applied to the content group.
+ The test will pass if only the first circle is affected by the group animation and, after applying user agent transforms, the circles behave as defined.
+ The test will pass if the three circles align vertically.
+
+
+
+ $RCSfile: coords-constr-203-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Constrained Transformations
+ Animation of the slide's body. Only the first line should be moving during the animation.
+
+
+
+ Can be panned, rotated and scaled by the user agent transform.
+
+
+
+ Cannot be transformed by the user agent transform.
+
+
+
+ Cannot be transformed by the user agent transform.
+
+
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-204-t.svg
new file mode 100755
index 00000000..33afd96b
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/coords-constr-204-t.svg
@@ -0,0 +1,56 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Animates a rect that has transform="ref" and tests that the animateMotion transform is supplemental.
+ The rects should follow a path diagonally from top-left to bottom-right.
+ The test is passed if a single green rectangle is visible across the screen if a red rectangle is seen
+ the test is failed.
+
Tests the default initial coordinate system used by renderer. Should be 0,0 if not specified.This is illustrated by comparing red boxes that are missing a coordinate or all coordinates with yellow boxes that have the correct coordinates specified. This test should produce three red boxes, with small yellow boxes rendered on top of them. These boxes should be placed along the origin, and x and y axis.
+ This test verifies the implementation of the viewBox and the preserveAspectRatio attribute on the animation element.
+ It exercises the various preserveAspectRatio values and uses a general entity definition in order to make reading of the SVG source easier.
+
+
+ For the test to pass the following criteria should be met:
+
+
+
the xMin* test image left edge should be on the left edge of the blue viewport rect
+
the xMid* test image should be centered in the blue viewport rect
+
the xMax* test image right edge should be on the right edge of the blue viewport rect
+
the yMin* test image top edge should be on the top edge of the blue viewport rect
+
the yMid* test image should be centered in the blue viewport rect
+
the yMax* test image bottom edge should be on the bottom edge of the blue viewport rect
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
The test uses the rect element, the fill color (solid primary colors) and transforms.
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ The test uses the rect element, the fill color (solid primary colors) and transforms.
+
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ 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.
+
+ 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 rendered picture should match the reference image exactly except for variations in the labeling text.
+
+
+ This test will check if the various matrix operations work
+
+ Verify the conversion processing of percentage and fraction values relative to object bounding boxes.
+ This is used when defining linear and radial gradients.
+
+
+ The test validates conversion for coordinates, width, height and length. The first test defines two
+ corresponding linear gradients, which specify coordinates using fractions for the first and user
+ coordinates for the second. The second test defines two corresponding radial gradients, which specify
+ a length (radius) using fractions for the first and user space for the second.
+
+
+ The rendered image should match the reference image.
+
+
+ The test also assumes that linear and radial gradients are implemented.
+
+ 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.
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.
+
+
+ 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.
+
+
+
+ $RCSfile: extend-namespace-02-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ onLoad(evt);
+
+
+
+
+
+
+
+
+
+ East
+ 3
+
+
+ North
+ 4
+
+
+ West
+ 5
+
+
+ Central
+ 3.2
+
+
+ South
+ 6
+
+
+ Pie chart built from data in a different namespace.
+
+
+ Pie chart is built within this 'g' element
+
+
+
+ $Revision: 1.9 $
+
+
+
+
+
+ DRAFT
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-desc-02-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-desc-02-t.svg
new file mode 100755
index 00000000..0bbd8678
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-desc-02-t.svg
@@ -0,0 +1,99 @@
+
+
+
+
+
+
+
+
+
+
+
+
This tests the behaviour of CSS font matching based on font-variant attribute.
+
The first line of text should be 'square' 'triangle'. The small-caps font should match the second text element.
+
The second line of text should be 'square' 'triangle'. The second line is used to ensure that the order of font specification does not effect the selection of these fonts.
+
The third line of text should be 'square', 'diamond', 'square', 'diamond'. This shows 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 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.
+
+
+ $RCSfile: fonts-desc-02-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ a
+ a
+
+ a
+ a
+
+ a
+ a
+ a
+ a
+
+ a
+ a
+ a
+ a
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-elem-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-elem-01-t.svg
new file mode 100755
index 00000000..29fe2a00
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-elem-01-t.svg
@@ -0,0 +1,94 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
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. An implementation that passes this test should completely fill the cutout, leaving a solid black area (some slight antialiasing effects may remain).
+
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).
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.
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 adavance of 1000. Glyphs have no advance so the 1000 default should be used.
+
The second row shows a layout with a default adavance of 2000. Glyphs have no advance so the 2000 default should be used.
+
The last row shows a layout with a default adavance of 0. Glyphs have a specified advance so the 0 default should be ignored.
+
Reference blue markers show the expected glyph positions.
The first subtest tests the arabic-form attribute and should 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 is the same, but with glyphs for the letter khah. It should match the reference image.
+ 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.
+
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.
+ Test that ligatures are always used, and only used, when they occur before the
+ glyphs for characters they are ligatures of. The word "fjord" is displayed twice;
+ the top one must use the fj ligature and the bottom one must not; the top of the letter f overlaps the
+ dot of the letter i..
+
+
+ Two fonts are defined, almost identical; in one the fj ligature is the
+ first glyph defined, in the second one it is the last glyph.
+
+
+
+ $RCSfile: fonts-glyph-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ fjord
+ fjord
+
+ The Fjord fonts
+ are derived from
+ Gladiator
+ by Bert Bos
+ and are used
+ by kind permission.
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-glyph-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-glyph-202-t.svg
new file mode 100755
index 00000000..49562235
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-glyph-202-t.svg
@@ -0,0 +1,175 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test that ligatures are always used, and only used, when they occur before the
+ glyphs for characters they are ligatures of. The word "fjord" is displayed twice;
+ the lower one must use the fj ligature and the upper one must not; the top of the letter f overlaps the
+ dot of the letter j..
+
+
+ Two fonts are defined, almost identical; in one the fj ligature is
+ defined after "f" but before "j"; in the second one it is the last glyph.
+ This tests longest-substring matching.
+
+
+
+ $RCSfile: fonts-glyph-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ fjord
+ fjord
+
+ The Fjord fonts
+ are derived from
+ Gladiator
+ by Bert Bos
+ and are used
+ by kind permission.
+
+
+
+
+
+ $Revision: 1.11 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-glyph-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-glyph-203-t.svg
new file mode 100755
index 00000000..803bfb36
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/fonts-glyph-203-t.svg
@@ -0,0 +1,97 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test that all of the SVG path commands are accepted for defining glyphs. The upper,
+ black text must be a reflection of the lower, colored glyph shapes.
+
+
+ The letter A uses L commands, the letter H uses H and V commands, and
+ the letter B uses cubic beziers. The letter C uses a mix of quadratic beziers and vertical lines.
+
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".
+ This tests a range of values for the 'units per em' attribute. The
+ test is passed if the three letter β are all the same size.
+
+
+ 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.
+
+ 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 in changed to pink,
+ 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.
+
+
+ After clicking at least once on the button, the rendered image should be
+ exactly as the reference image, except for differences in text display.
+
+
This test requires that the user agent support scripting.
+ Test on event bubbling. Moving focus should make a red rect visible/invisible
+
+
+
+ $RCSfile: interact-event-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ r1.setTrait("visibility", "visible");
+
+
+ r1.setTrait("visibility", "hidden");
+
+
+
+ moving focus should make a red rect visible/invisible
+
+
+ $Revision: 1.7 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-event-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-event-202-t.svg
new file mode 100755
index 00000000..a72ce99e
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-event-202-t.svg
@@ -0,0 +1,86 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Testing event bubbling through 'use' elemnt.
+ Moving the mouse over the red 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 red/green rect should hide the rect underneath it again.
+
+
+
+ $RCSfile: interact-event-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ g4.setTrait("visibility", "visible");
+
+
+ g4.setTrait("visibility", "hidden");
+
+
+
+
+
+
+
+
+
+
+ Moving the mouse over the red 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 red/green rect should hide
+ the rect underneath it again.
+
+
+ $Revision: 1.6 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-event-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-event-203-t.svg
new file mode 100755
index 00000000..8c9ef963
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-event-203-t.svg
@@ -0,0 +1,104 @@
+
+
+
+
+
+
+
+
+
+
+
+
Tests 'mouseover' event on SVGElementInstance
+
+ This test contains four cases. The cases must produce the following results for the test to pass.
+ Case 1: On a mouseover event on the top square, all four squares must turn blue.
+ Case 2: On a mouseover event on the top middle square, all four squares must turn blue and a black stroke
+ must appear on the referencing square (element).
+ Case 3: On a mouseover event on the bottom middle square, all four squares must turn blue and a black
+ stroke must appear on the referencing square (element).
+ Case 4: On a mouseover event on the bottom square, all four squares must turn blue, and on a mousedown event
+ a black stroke must appear on the referencing square (element).
+
+
+ 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.
+
+
+
+ $RCSfile: interact-event-203-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+ Shadow tree event listener chain
+
+
+
+ Case 1: on mouseover all squares must turn blue
+
+
+
+
+
+
+
+
+ Case 2: on mouseover all squares must turn blue
+ and a black stroke must appear on reference square
+
+
+
+
+
+
+
+
+
+
+
+ Case 3: on mouseover all squares must turn blue
+ and a black stroke must appear on reference square
+
+
+
+
+
+
+
+
+
+ Case 4: on mouseover all squares must turn blue
+ and on mousedown a black stroke must appear on reference square
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-201-t.svg
new file mode 100755
index 00000000..d9b80083
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-201-t.svg
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusable Property on Animated Elements.
+
Two rectangles and a text element are targets of animateColor elements which begin on focusin and end on focusout.
+
The top-level SVG has a nav-next attribute referencing the text element.
+
When loading the file, initial focus will go to the text element, which should be red.
+
Moving to the next focus will turn the text black while making the blue rectangle green.
+
Moving to the next focus will return the rectangle to blue and make the red rectangle green.
+
Moving to the next focus will return the rectangle to red and turn the text red.
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+ User agent dependent behavior is accepted with all focus tests. Focus can be given immediately to first element in the focus ring,
+ or held in the UA until focus is requested - then focus is given to the first element.
+
Testing the focusable property : its default value and animatability on text and anchor elements.
+
The 1st text is the target of animateColor which starts on focusin, and also has the focusable attribute set to false.
+
The 2nd text does not have a focusable attribute and is not the target of animations which start by focus events.
+
The 3rd text is the target of animateColor which starts on focusin.
+
The 4th text is the target of animateColor which starts on activate.
+
The 5th text is the child of an a element.
+
The 6th text is the child of an a element and also has the focusable attribute set to false.
+
The 7th text has the editable attribute set to simple.
+
The 8th text is the observer DOMFocusIn and DOMFocusOut handlers.
+
The 9th and 10th text elements are used to modify the focusable attribute of the 11th element.
+
+ The 11th text is the target of animateColor which starts on focusin, and also has the focusable attribute set to false.
+ The focusable attribute is modified by activate events on the 9th and 10th elements.
+
+
The 12th and 13th text elements are used to modify the focusable attribute of the 14th element.
+
+ The 14th text is the child of an a element - the a element also has the focusable attribute set to false.
+ The focusable attribute is modified by activate events on the 12th and 13th elements.
+
+
+
The focus ring will look like the following: 3, 4, 5, 7, 8, 9, 10, 12 and 13.
+
Activating the 9th text element will make the 11th element focusable.
+
Activating the 12th text element will make the 14th element focusable.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+ User interaction should navigate focus starting at 1 and go through 5.
+ This test applies only to user agents which locate to focus which is outside of the viewport, and
+ thus the pass criteria for this test is optional.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+
+ $RCSfile: interact-focus-203-t.svg,v $
+
+
+
+
+
+
+
+
+ Test Focusable Elements Outside the Viewport
+ User interaction should navigate focus starting at 1 and go through 5.
+ This test applies only to user agents which
+ locate to focus which is outside of the viewport.
+
+
+
+
+
+
+
+ 1
+
+
+
+
+ 2
+
+
+
+
+ 3
+
+
+
+
+ 4
+
+
+
+
+ 5
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-204-t.svg
new file mode 100755
index 00000000..b7517946
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-204-t.svg
@@ -0,0 +1,127 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusable Elements - Focus Direction
+
Focused text should be red. The default focus is the number 5.
+
Cardinal focus changes should work as expected, with wrapping.
+
Next/Previous go to next/prev numerical value.
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+
+ $RCSfile: interact-focus-204-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Test Focusable Elements - Focus Direction
+
+
+ Focused text should be red. The default focus is the number 5.
+
+
+ Cardinal focus changes should work as expected, with wrapping.
+
+
+ Next/Previous go to next/prev numerical value.
+
+
+
+
+ 7
+
+
+
+
+
+
+ 8
+
+
+
+
+
+
+ 9
+
+
+
+
+
+
+ 4
+
+
+
+
+
+
+ 5
+
+
+
+
+
+
+ 6
+
+
+
+
+
+
+ 1
+
+
+
+
+
+
+ 2
+
+
+
+
+
+
+ 3
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-205-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-205-t.svg
new file mode 100755
index 00000000..410945c6
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-205-t.svg
@@ -0,0 +1,75 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusable Elements - Nested Elements
+
The circle should first be focused (red), then each square should stay red, due to bubbling.
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+
+ $RCSfile: interact-focus-205-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test Focusable Elements - Nested Elements
+ The circle should first be focused (red),
+ then each square should stay red, due to bubbling
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-206-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-206-t.svg
new file mode 100755
index 00000000..4c0d3727
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-206-t.svg
@@ -0,0 +1,75 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusable Elements - Invisible Items
+
+ Lines 1 to 3 should show up when receiving the focus.
+ Fill-opacity and visibility attributes are animated accordingly to show text.
+
+
Line 4 should never receive the focus.
+
+
+ $RCSfile: interact-focus-206-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test Focusable Elements - Invisible Items
+ Lines 1 to 3 should show up when receiving the focus.
+ Line 4 should never receive the focus.
+
+ 1
+ This text is 100% transparent
+
+
+
+
+ 2
+ This text is invisible
+
+
+ 3
+ This text covered by a white rect
+
+
+
+
+ 4
+
+ This text has display="none"
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-207-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-207-t.svg
new file mode 100755
index 00000000..5abffe95
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-207-t.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+
+
This test tests initial focus within the svg document
+
+ The root SVG element has 'focusable' set to 'true'.
+ At start up an animation set element is used to change the poem
+ to red if the root element SVG has focus.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+
+ $RCSfile: interact-focus-207-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test Focusable Elements - Root SVG Element
+ The poem should be red,
+ showing that the top-level SVG element has the focus.
+
+ The old pond
+ A frog jumped in,
+ Kerplunk!
+
+
+
+ Frog Haiku by Matsuo Basho (1686), translated by Allen Ginsberg
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-208-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-208-t.svg
new file mode 100755
index 00000000..972c9657
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-208-t.svg
@@ -0,0 +1,122 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusable Elements - tspan Element
+
+ Each tspan has an animation that sets the fill to green upon receiving
+ focus. The focus should be moved in turn to "Old", "pond", "frogs",
+ "jumped", "in", "sound", "of" and then "water".
+
+
+ For the test to pass:
+
+
+
+ "Old", "pond", and "sound", "of" and "water" must each turn green
+ respectively when given focus.
+
+
+ "frogs" and "in" must both turn green at the same time when each is
+ given focus.
+
+
+ "jumped" must turn green when given focus and in addition "frogs" and
+ "in" must turn green at the same time due to focus bubbling.
+
+
+
+ In the 2nd phrase there are two nested tspan elements: "jumped" is in
+ the inner tspan, so focus should be received by the outer two words
+ "frogs", "in" and then by the word "jumped".
+
+
+ Focus navigation is user agent dependant but typically is navigated
+ with the keyboard keys.
+
+
+ TAB or arrow keys move the focus while the ENTER key activates the
+ focused element.
+
+
+
+ $RCSfile: interact-focus-208-t.svg,v $
+
+
+
+
+
+
+
+
+ Test Focusable Elements - tspan Element
+
+ Give focus to each word.
+
+
+
+ Old
+
+
+
+
+ pond
+
+
+
+ -
+
+ frogs
+
+ jumped
+
+
+
+ in
+
+
+
+ -
+
+ sound
+
+
+
+
+ of
+
+
+
+
+ water
+
+
+
+
+ Frog Haiku by Matsuo Basho (1686), translated by Lafcadio Hearn
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-209-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-209-t.svg
new file mode 100755
index 00000000..0d369ad8
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-209-t.svg
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusable Elements - tspan in a textArea
+
+ Each tspan has an animation that sets the fill to green upon receiving
+ focus. The focus should be moved in turn to "A", "lonely", "pond", "in",
+ "age-old", "stillness", "sleeps", "Apart,"
+ "unstirred by sound or motion", "... till", "Suddenly",
+ "into", "it", "a", "lithe", "frog" and then "leaps".
+
+
+ For the test to pass:
+
+
+
+ "A", "lonely", "pond", "in", "age-old", "stillness", "sleeps",
+ "Suddenly", "into", "it", "a", "lithe", "frog" and "leaps" must each
+ turn green respectively when given focus.
+
+
+ "Apart" and "... till" must both turn green at the same time when
+ each is given focus.
+
+
+ "unstirred by sound or motion" must turn green when given focus and
+ in addition "Apart" and "... till" must turn green at the same time
+ due to focus bubbling.
+
+
+
+ In the 2nd line there are two nested tspan elements - "unstirred by
+ sound or motion" is in the inner tspan, so focus should be received
+ first by the outer two words "Apart", "till" and then by the inner
+ phrase.
+
+
+ Focus navigation is user agent dependant but typically is navigated with
+ the keyboard keys.
+
+
+ TAB or arrow keys move the focus while the ENTER key activates the
+ focused element.
+
+
+
+ $RCSfile: interact-focus-209-t.svg,v $
+
+
+
+
+
+
+
+
+ Test Focusable Elements - tspan in a textArea
+
+ Give focus to each word.
+
+
+ Frog Haiku by Matsuo Basho (1686), translated by Curtis Hidden Page
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-210-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-210-t.svg
new file mode 100755
index 00000000..9f738105
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-210-t.svg
@@ -0,0 +1,107 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusability with the 'use' Element
+
+ The first four occurrences of "focus next" will highlight all four top rects.
+ All four bottom rects should be able to receive the focus and be red when they have focus.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+
+ $RCSfile: interact-focus-210-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Test Focusability with the 'use' Element
+
+ Each rectangle should be able to turn red individually upon receiving focus.
+
+
+ The top four test the multiple use of a focusable element
+
+
+ The bottom four test 'focusable' property on <use> element
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-211-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-211-t.svg
new file mode 100755
index 00000000..e1702271
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-211-t.svg
@@ -0,0 +1,76 @@
+
+
+
+
+
+
+
+
+
+
+
+
Test Focusability with the 'use' Element
+
+ There are three 'use' copies of the poem arranged diagonally.
+ As each poem receives focus it should become highlighted.
+
+
Focus navigation is user agent dependant but typically is navigated with the keyboard keys.
+
TAB or arrow keys move the focus while the ENTER key activates the focused element.
+
+
+ $RCSfile: interact-focus-211-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test Focusability with the 'use' Element
+
+ There are three 'use' copies of the poem arranged diagonally.
+
+
+ As each poem receives focus it should become highlighted.
+
+
+
+
+
+
+
+
+
+
+
+ Frog Haiku by Matsuo Basho (1686), translated by Alfred H. Marks
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-212-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-212-t.svg
new file mode 100755
index 00000000..6e1143b5
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-focus-212-t.svg
@@ -0,0 +1,84 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test on focus with a use-element. Focus should move first to the "g" element and then to its children.
+ When it gets to the use-element focus is first set on the use (right column) and then its children.
+
+
+
+ $RCSfile: interact-focus-212-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ text
+
+
+
+
+
+
+
+ use
+ Test on focus with a use-element.
+ Focus should move first to the "g" element and
+ then to its children. When focus is trans-
+ ferred to the use-element focus is first
+ set on the use (whole right column) and
+ then its children.
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-order-04-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-order-04-t.svg
new file mode 100755
index 00000000..ae18bd42
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-order-04-t.svg
@@ -0,0 +1,111 @@
+
+
+
+
+
+
+
+
+
+
+
+
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 that the user agent support scripting.
+ 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. The supplemental
+ text next to the circles describes what should occur.
+
+
This test requires that the user agent support scripting.
+ 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. The supplemental
+ text below the text strings describes what should occur.
+
+
This test requires that the user agent support scripting.
+ 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 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: 1. all the 'O':s in the green rects have green
+ fill 2. there are no red 'O':s visible 3. there are 9 green 'O':s in the first and second rect, 4 in the third rect
+ and 6 in the fourth rect
+
+
+
+ $RCSfile: interact-pevents-02-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test pointer-events on text
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+
+
+
+
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+ O
+
+
+
+
+
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+
+
+
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+ O
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.9 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-05-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-05-t.svg
new file mode 100755
index 00000000..2dc27c31
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-05-t.svg
@@ -0,0 +1,211 @@
+
+
+
+
+
+
+
+
+
+
+
+
Tests the pointer-events attribute with different 'visible' values
+
+ The test is passed if the following conditions are met:
+ - In the first row of squares, the fill and stroke of squares 1 and 3 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the second row of squares, the fill and stroke of squares 1 and 3 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the third row of squares, the fill only of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fourth row of squares, the stroke only of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fifth row of squares, the fill and stroke of squares 1, 2 and 3 must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+
+
+ 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.
+
+
+
+ $RCSfile: interact-pevents-05-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Testing pointer-events - pale RED rect should appear on mouseover.
+
+
+ 2nd and 3rd columns represent respectively rects with no fill/stroke and transparent fill/stroke
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ default :
+ fill and stroke of rects 1 and 3 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ visiblePainted :
+ fill and stroke of rects 1 and 3 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ visibleFill :
+ only fill of rects 1 to 3 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ visibleStroke :
+ only stroke of rects 1 to 3 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ visible :
+ fill and stroke of rects 1 to 3 must trigger
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-06-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-06-t.svg
new file mode 100755
index 00000000..817e8822
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-06-t.svg
@@ -0,0 +1,200 @@
+
+
+
+
+
+
+
+
+
+
+
+
Tests the pointer-events attribute with different painting values
+
+ The test is passed if the following conditions are met:
+ - In the first row of squares, the fill and stroke of squares 1, 3 and 4 only must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the second row of squares, the fill only of all squares must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the third row of squares, the stroke only of all must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fourth row of squares, the fill and stroke of all squares must trigger a pale red rectangle to appear
+ over the squares on mouseover.
+ - In the fifth row of squares, nothing is to trigger on mouseover.
+
+
+ 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.
+
+
+
+ $RCSfile: interact-pevents-06-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Testing pointer-events - pale RED rect should appear on mouseover.
+
+
+ 2nd and 3rd columns represent respectively rects with no fill/stroke and transparent fill/stroke
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ painted :
+ fill and stroke of rects 1, 3 and 4 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ fill :
+ fill of rects 1 to 4 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ stroke :
+ stroke of rects 1 to 4 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ all :
+ stroke and fill of rects 1 to 4 must trigger
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ none :
+ nothing is to trigger
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-07-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-07-t.svg
new file mode 100755
index 00000000..26b93a20
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-07-t.svg
@@ -0,0 +1,110 @@
+
+
+
+
+
+
+
+
+
+
+
+
Testing pointer-events and rendering order
+
+ Rectangles should turn RED on mouseover Ovals should turn RED if Pointer-Events are set to "ALL"
+
+
+
+ $RCSfile: interact-pevents-07-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Testing pointer-events and rendering order
+ Rectangles should turn RED on mouseover
+ Ovals should turn RED if Pointer-Events are set to "ALL"
+
+
+
+ Change "Pointer-Events" of
+ ovals from "ALL" to "NONE"
+
+
+
+
+ Purple ovals have "Pointer-Events" set to "ALL".
+ Purple ovals have Pointer-Events set to "NONE".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-08-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-08-t.svg
new file mode 100755
index 00000000..0a5d7d90
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/interact-pevents-08-t.svg
@@ -0,0 +1,120 @@
+
+
+
+ init(evt);
+
+
+
+
+
+
+
+
+
+
+
Tests when text is considered hit by pointer-events.
+
+ The test is passed if the following conditions are met:
+ - Any single character in either of the lines of text has 'mouseover' event and the fill of the
+ characters' assocated line of text is set to green.
+ - The fill of the characters' assocated text is set back to black on a 'mouseout' event.
+
+
+ The dy of the glyphs vary quite a bit, so it's easy to tell if an implementation uses the text
+ boundingbox for 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'.
+
+ Verify correct handling by Dynamic (interactive) viewers for the "zoomAndPan" attribute on the 'svg' element. This
+ is the first 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..
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ 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..
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ 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.
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ This verifies the capability to handle links into SVG content, using the svgView fragment identifier form.
+ The test is passed if traversing this link shows a portion of the target
+ translated so that the green circle with id "circle-2" is in the top left corner of the viewer
+ frame.
+
+
The initial view of this test contains one green arrow plus labelling text. The arrow is a link - follow the link.
+
+ The arrow links to ./images/linkingCircle-f.svg#svgView(transform(translate(64,227)))".
+
+ 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'. Both must be working links.
+
+
+
+ $RCSfile: linking-a-08-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Link inside text
+
+
+ Link around text
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-a-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-a-201-t.svg
new file mode 100755
index 00000000..83b2f5b5
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-a-201-t.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Verify target attribute has priority over xlink attribute on the 'a' element. The destination expressed by
+ "xlink:href=" is overridden when 'target' is specified on the 'a' element.
+
+
+ For the test to pass; each arrow in the test, when clicked, must show the image of the
+ linkingToc-t.svg in a new frame.
+
+
+ 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.
+
+
+ This test was modified and renamed from linking-a-07-t.svg.
+
+ Testing Links to external and internal 'svgView' with Transforms.
+
+
+ The first part of the test is passed if the rect links on the top line go to the linking-frag-202-t.svg file and
+ adjust the resulting view according to their respective text;
+ - The rect with 'Rotate' must link to the linking-frag-202-t.svg file and rotate resulting view
+ - The rect with 'Shift' must link to the linking-frag-202-t.svg file and shitf the resulting view
+ - The rect with 'Scale' must link to the linking-frag-202-t.svg file and scale the resulting view
+ - The rect with 'skewX' must link to the linking-frag-202-t.svg file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to the linking-frag-202-t.svg file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to the linking-frag-202-t.svg file and restore the view to an identity transformation.
+
+
+ The second part of the test is passed if the rect links on the bottom line link to this file and adjust the
+ resulting view according to their respective text;
+ - The rect with 'Rotate' must link to this file and rotate resulting view
+ - The rect with 'Shift' must link to this file and shitf the resulting view
+ - The rect with 'Scale' must link to this file and scale the resulting view
+ - The rect with 'skewX' must link to this file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to this file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to this file and restore the view to an identity transformation.
+
+
+
+ $RCSfile: linking-frag-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Testing Links to External 'svgView' with Transforms
+
+ First line links to an svgView in an external file (linking-frag-202-t.svg)
+
+
+ Second line links to an svgView in the local file
+
+
+
+
+
+
+
+
+
+ Rotate
+
+
+
+ Shift
+
+
+
+ Scale
+
+
+
+ skewX
+
+
+
+ skewY
+
+
+
+ identity
+
+
+
+
+ Rotate
+
+
+
+ Shift
+
+
+
+ Scale
+
+
+
+ skewX
+
+
+
+ skewY
+
+
+
+ identity
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-frag-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-frag-202-t.svg
new file mode 100755
index 00000000..6c66c096
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-frag-202-t.svg
@@ -0,0 +1,153 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Testing Links to external and internal 'svgView' with Transforms.
+
+
+ The first part of the test is passed if the rect links on the top line go to the linking-frag-202-t.svg file and
+ adjust the resulting view according to their respective text;
+ - The rect with 'Rotate' must link to the linking-frag-201-t.svg file and rotate resulting view
+ - The rect with 'Shift' must link to the linking-frag-201-t.svg file and shitf the resulting view
+ - The rect with 'Scale' must link to the linking-frag-201-t.svg file and scale the resulting view
+ - The rect with 'skewX' must link to the linking-frag-201-t.svg file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to the linking-frag-201-t.svg file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to the linking-frag-201-t.svg file and restore the view to an identity transformation.
+
+
+ The second part of the test is passed if the rect links on the bottom line link to this file and adjust the
+ resulting view according to their respective text;
+ - The rect with 'Rotate' must link to this file and rotate resulting view
+ - The rect with 'Shift' must link to this file and shitf the resulting view
+ - The rect with 'Scale' must link to this file and scale the resulting view
+ - The rect with 'skewX' must link to this file and skew the resulting view along the X axis
+ - The rect with 'skewY' must link to this file and skew the resulting view along the Y axis
+ - The rect with 'identity' must link to this file and restore the view to an identity transformation.
+
+
+
+ $RCSfile: linking-frag-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Testing Links to External 'svgView' with Transforms
+
+ First line links to an svgView in an external file (linking-frag-201-t.svg)
+
+
+ Second line links to an svgView in the local file
+
+
+
+
+
+
+
+
+ Rotate
+
+
+
+ Shift
+
+
+
+ Scale
+
+
+
+ skewX
+
+
+
+ skewY
+
+
+
+ identity
+
+
+
+
+ Rotate
+
+
+
+ Shift
+
+
+
+ Scale
+
+
+
+ skewX
+
+
+
+ skewY
+
+
+
+ identity
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-frag-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-frag-203-t.svg
new file mode 100755
index 00000000..f720357f
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-frag-203-t.svg
@@ -0,0 +1,72 @@
+
+
+
+
+
+
+
+
+
+
+
+
Tests links to internal fragment identifiers.
+
+ Activating the link on the red circle should pan the viewport to
+ center the orange circle (which is initially located outside the viewport).
+
+
+ Activating the link on the orange circle should pan the viewport to
+ center the yellow circle, and zoom out to show the entire yellow circle.
+
+
+ Activating the link on the yellow circle should pan the viewport to center
+ the red circle, but remain at the existing zoom level (i.e. not zoom in).
+
+
+ Note that the visual effect is only part of the pass criteria, and that the
+ changes in the viewport should be made using currentTranslate and currentScale,
+ not the viewBox; this part is currently not tested.
+
+ Tests various external fragments with 'use' element:
+ fill, stroke, text, group, multiple levels, name clash and circular references
+
+
+ SVG fragments defined in an external file are invoked with the 'use' element.
+ The test is passed if the following objects are rendered:
+ - Right top; square with a horizontal gradient fill from orange to yellow, diagonal gradient stroke from blue to pink
+ - Right middle top; square with a diagonal gradient fill from blue to pink, horizontal gradient stroke from orange to yellow
+ - Right middle bottom; the letters ABC in an SVG font
+ - Right bottom; the English alphabet a to j in the shape of a square
+ - Left Top; square with horizontal gradient fill from orange to yellow, and 3 circles all with a blue to red gradient fill
+ running diagonally inside the square
+ - Left middle top; green square with a yellow circle in the middle
+ - Left middle bottom; red square
+ - Left bottom; two identical squares with light blue fill.
+
+
+
+ $RCSfile: linking-refs-203-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ External Fragments with 'use' Element
+
+
+
+ Rect using external gradients
+ for fill and stroke
+
+
+
+ Rect using external fill gradient
+ gradient & local stroke gradient
+
+
+
+ Text using SVG font
+
+
+
+ Alphabet a to j
+
+
+
+
+
+ Group using a rect and
+ 3 circles using gradients
+
+
+
+ 2 levels of external <use> A green
+ rect, yellow circle must appear
+
+
+
+ Testing id name clash.
+ Rect must be red
+
+
+
+
+ External circular reference
+ Two identical rectangles must appear,
+ proving the circular reference didn't loop
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-204-t.svg
new file mode 100755
index 00000000..33ce1c72
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-204-t.svg
@@ -0,0 +1,91 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ External Fragments with 'use' Element.
+
+
+ Tests SVG fragments defined in an external file are invoked with the 'use' element.
+ The test is passed if the following objects are rendered:
+ - Right top; square with red fill and blue stroke
+ - Right middle; square with black fill
+ - Right bottom; the letters 'A' in blue, 'B' in red, 'C' in blue
+ - Left top; square with red fill and a circle in the middle with a blue fill
+ - Left middle; square with green fill
+ - Left bottom; square with green transparent fill with an overlapping circle with a blue transparent fill.
+
+
+
+ $RCSfile: linking-refs-204-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+ External Fragments with 'use' Element
+
+
+
+ Red rect, blue stroke
+
+
+
+ Black rect
+
+
+
+ Blue-red-blue letters
+
+
+
+
+
+ Group, red rect, blue circle
+
+
+
+ Green rect,
+ "externally defined in this file"
+
+
+
+ Test id clash - must show
+ transparent blue circle & green rect
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-205-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-205-t.svg
new file mode 100755
index 00000000..5c766b52
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-205-t.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Tests a 'use' element referencing an 'image' element and an 'a' element with xml:base.
+
+
+ The test is passed if two identical images are displayed.
+
+
+ The image on the right is located in the images directory (../images/) while the
+ image on the left is located in image2 directory (../images/image2). The image on
+ the right is specified in the svglib3.svg file using an 'image' element. The image
+ on the left is specified in the svglib3.svg using an 'a' element. The 'a' element
+ contains a group around it that specifies the image2 directory using 'xml:base'.
+
+
+
+ $RCSfile: linking-refs-205-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Images with external 'use' Element
+
+ Testing xml:base. The two images must appear identical.
+
+
+ Click to execute link
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-206-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-206-t.svg
new file mode 100755
index 00000000..98b7fd12
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/linking-refs-206-t.svg
@@ -0,0 +1,91 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Tests that values for the xlink role and arcrole attributes are stored in the DOM.
+ The test is passed if the raster image and the vector image both have dark
+ green and light green borders, same as the reference image.
+
+
+ The values for role and arcrole are based on the RDDL specifications of
+ well known link natures (role) and well known link purposes (arcrole). Roles uses the namespace URI (for XML content types) or the canonical IANA URI of the media type registration (for non-XML content).
+
+
+ A uDOM script reads the values of the xlink role and arcrole attributes,
+ checks that they are the correct values, and sets the fill colour of some rectangles
+ from shades of red (meaning incorrect) to shades of green (meaning correct).
+
+ 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.
+
+
+ There is a link on the triangle, pointing to an external SVG file, which is in the images directory (../images/).
+ The target file contains SVG 'text' elements which comprise a TOC and brief description of all of the SVG Tiny 1.2
+ 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 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. The results of executing the link
+ should be identical to executing the first (topmost) link of linking-uri-01-t.
+
+
+ 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.
+
+
+
+ $RCSfile: linking-uri-03-t.svg,v $
+
+
+
+
+
+
+
+
+ Simple exercise of xlink attributes on the 'a' element.
+
+
+
+ Click for TOC
+ Link to local file
+ linkingToc-t.svg.
+
+ xlink:type="simple"
+ xlink:show="replace"
+ xlink:actuate="onRequest"
+ xlink:href="linkingToc-t.svg"
+ xlink:role="figure-out-a-role"
+ xlink:title="TOC of Linking BE tests."
+ target="_self"
+
+
+ $Revision: 1.9 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-201-t.svg
new file mode 100755
index 00000000..ed0fe2d8
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-201-t.svg
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+
+
+
+
+
+
Testing 'audio' Element with the 'audio-level' Attribute
+
+ The scale at the bottom of the slide uses a 'set' element to modify the 'audio-level' on the sample audio element.
+ The 'audio' element can be triggered by activating the current focus.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
Testing 'video' Element with the 'audio-level' Attribute
+
+ The scale at the bottom of the slide uses a 'set' element to modify the 'audio-level' on the sample video element.
+
+
+ The 'video' element can also be triggered by activating the current focus.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+
+
+ $RCSfile: media-alevel-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Audio Level
+
+
+ The scale at the bottom uses 'set' to modify the 'audio-level' on the sample video element.
+
+
+ The video element can be triggered by activating the current focus.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 0
+ volume
+ 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.10 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-203-t.svg
new file mode 100755
index 00000000..4a02f0a4
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-203-t.svg
@@ -0,0 +1,67 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test on audio level animation. audio-level is animated to many values between 0 and 1. The volume dial graphic animates to show the expected relative volume.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
+ Test on audio-level inheritance in several child elements. audio-level on the first element is 0.5. audio-level on the second sound is halved to 0.25. audio-level on the third and fourth sounds are halved agian to 0.125 and 0.0625 respectively.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
+
+
+ $RCSfile: media-alevel-206-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Test on audio-level inheritance in child elements.
+ An audio file is played four times. Each time the audio-level should be cut in half.
+ The four audio-level values should be: 0.5 , 0.25 , 0.125 , 0.0625
+ A very noticeable difference in audio level should be heard!
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-207-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-207-t.svg
new file mode 100755
index 00000000..3a8bb23e
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-207-t.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test on audio. audio-level is set to "0" so no sound should be heard.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
+
+
+ $RCSfile: media-alevel-207-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test on audio-level
+ audio-level="0"
+ An audio file is repeated for 10 seconds,
+ should NOT be audible!
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-208-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-208-t.svg
new file mode 100755
index 00000000..ef405e5a
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-alevel-208-t.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test on audio. audio-level is set to "1" so a audio-file being repeated for 10s should be heard.
+
+
+ If the user agent does not support the WAV media format, the test is still a pass.
+
+
+
+ $RCSfile: media-alevel-208-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test on audio-level
+ audio-level="1"
+ An audio file is repeated for 10 seconds,
+ should be audible!
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-201-t.svg
new file mode 100755
index 00000000..fe704115
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-201-t.svg
@@ -0,0 +1,98 @@
+
+
+
+
+
+
+
+
+
+
+
+
This test validates the Animation element with external references.
+
There are five references. Each one is a separate file.
+
The time scale loops from 0 to 10 seconds - the vertical red line pans from left to right.
+
In the first example the two rectangles are set to rotate 90 degrees alternatively.
+
In the second case the circle has focus. Since this is the only item that has focus it can not loose focus and should remain red even when an attempt is made to change focus.
+
The third example has a circle that is set to change to red on a mouseover event. On mouseout the circle should change back to grey.
+
The forth example invokes the same external file twice - two squares with a gradiant should be rotating in sync continously.
+
The last case calls an animation that should display a blue square with five gradiant circles all rotating continously.
+
+
+ $RCSfile: media-anim-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Animation Elements with External References
+
+
+
+
+
+
+
+
+
+
+ Reference Timeline : starts at 0, goes through the scale in 10s.
+ Squares should rotate indefinetly.
+
+
+ 1.
+ Reference to external dual-chained animation.
+ Rects should spin alternatively.
+
+
+
+
+ 2.
+ Reference to focusable circle. Should start as red and
+ remain red even when an attempt is made to move focus.
+
+
+
+ 3.
+ Reference to mouseoverable circle.
+ Should be grey and turn red on mousover then back to grey.
+
+
+
+ 4.
+ Reference to animated rect with gradient fill - twice.
+
+
+
+
+
+ 5.
+ Reference to animated group rect using circles with gradients.
+
+
+
+
+
+
+ $Revision: 1.11 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-202-t.svg
new file mode 100755
index 00000000..9a7bf038
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-202-t.svg
@@ -0,0 +1,108 @@
+
+
+
+
+
+
+
+
+
+
+
+
Animation Elements with External References
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+
+
+ $RCSfile: media-anim-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Animation Elements with External References
+
+ Testing time-base animation control. Every time a scale shows up, its own time should be 0
+
+
+
+
+
+
+
+
+
+
+
+ Reference Timeline : starts at 0, goes through the scale in 10s
+
+
+
+ 1.
+ Full Animation : starts at 0, stops at 10
+
+
+
+ 2.
+ Shorter Animation used : appears at 2, stops at 6
+
+
+
+ 3.
+ Longer Animation (14s) : appears at 0, stops at 10
+
+
+
+ 4.
+ Short repeatCount animation : goes 5 times from 0 to 2,
+ stops at 10
+
+
+
+ 5.
+ Short repeatDur animation : same as above
+
+
+
+ 6.
+ Frozen animation : appears at 4, freezes on 4 at 8
+
+
+
+ 7.
+ Interrupted animation : should stop at 4 because of
+ "end" attribute
+
+
+
+
+ $Revision: 1.11 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-203-t.svg
new file mode 100755
index 00000000..87d9d694
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-203-t.svg
@@ -0,0 +1,96 @@
+
+
+
+
+
+
+
+
+
+
+
+
Animation Elements with External References
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+
+
+ $RCSfile: media-anim-203-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Animation Elements with External References
+
+ Testing time-base animation control. Every time a scale shows up, its own time should be 0
+
+
+
+
+
+
+
+
+
+
+
+ Reference Timeline : starts at 0, goes through the scale in 10s,
+
+
+
+ 1.
+ Animation events, runs for 2s at time 0 and when (4) ends
+
+
+
+ 2.
+ Animation events, runs for 2s when (1) ends
+
+
+
+ 3.
+ Animation events, runs for 2s when (2) ends
+
+
+
+ 4.
+ Animation events, runs for 2s when (3) ends
+
+
+
+ 5.
+ Animation events, starts at 0 and loops every two seconds.
+
+
+
+
+ $Revision: 1.11 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-204-t.svg
new file mode 100755
index 00000000..22709954
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-204-t.svg
@@ -0,0 +1,132 @@
+
+
+
+
+
+
+
+
+
+
+
+
Animation Elements with External References
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+
+ $RCSfile: media-anim-204-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Animation Elements with External References
+
+ Testing time-base animation control. Every time a scale shows up, its own time should be 0
+
+
+
+
+
+
+
+
+
+
+
+ Reference Timeline: starts at 0, goes through the scale in 10s,
+
+
+
+
+ 1.
+ User event driven animation: appears upon
+ text focusing, stops after 2s or focus lost
+
+
+
+
+
+
+
+
+ 2.
+ User event driven animation: starts upon
+ text focusing, stops after 2s or focus lost
+
+
+
+
+
+
+
+
+
+ 3.
+ User event driven animation: appears upon
+ mouseover, stops after 2s or mouseout
+
+
+
+
+
+
+
+
+
+ 4.
+ User event driven animation: appears upon
+ mouseover. Stops after 10s
+
+
+
+
+
+
+
+
+ 5.
+ User event/animation event driven: starts and runs
+ for 2s when animation (3) or (4) begins.
+
+
+
+
+
+ 6.
+ User event/animation event driven: appears and runs
+ for 2s when animation (1) through (5) ends.
+
+
+
+ 7.
+ Animation events: starts at 0 and loops every two seconds.
+
+
+
+
+ $Revision: 1.13 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-205-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-205-t.svg
new file mode 100755
index 00000000..13872bd3
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-205-t.svg
@@ -0,0 +1,86 @@
+
+
+
+
+
+
+
+
+
+
+
+
Animation Elements with External References
+
+ This is one of a series of test slides that exercise all the permitted values for the 'preserveAspectRatio'
+ attribute values.
+
+
+ The external resource referenced by the animation element has a viewport-fill defined with a solid color.
+ This should be ignored and the local color of blue should be used.
+
+
A semi-transparent yellow rectangle should be animating within each viewport.
This slide tests the 'viewport-fill' and 'viewport-fill-opacity' attributes defined locally.
+
+ The externally resource referenced by the animation element has a 'viewport-fill' defined with a black to yellow gradient.
+ This should be ignored and the local definitions should be used - red for the left, blue for the middle and semi-transparent black for the right.
+
+
A semi-transparent yellow rectangle should be animating within each viewport.
+
+
+ $RCSfile: media-anim-206-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Animation Elements with External References
+ Testing 'viewport-fill' and 'viewport-fill-opacity' defined locally.
+
+
+ red background fill
+
+
+
+
+ blue background fill
+
+
+
+
+ transparent
+ black background
+
+
+
+
+
+
+ $Revision: 1.10 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-207-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-207-t.svg
new file mode 100755
index 00000000..e60bf3f2
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-207-t.svg
@@ -0,0 +1,83 @@
+
+
+
+
+
+
+
+
+
+
+
+
Animation Elements with External References
+
This slide applies different transformations to the animation element.
+
+ The externally resource referenced by the animation element has a viewport-fill defined with a black to yellow gradient.
+ This should be ignored and over ridden by the color aqua.
+
+ This test validates the animation element with external references with emphases on time based animations.
+ The same external file is used for all seven tests.
+
+
+ The 'initialVisibility' attribute is not specified so the default should apply - 'whenStarted'.
+ In other words the animations should not be visible until they start and then they should disappear as the
+ fill is not set to 'freeze' so the initial state should be re-instated.
+
+
+
+ $RCSfile: media-anim-208-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Animation Elements testing initialVisibility
+
+ Testing time-base animation control. Every time a scale shows up, its own time should be 0
+
+
+
+
+
+
+
+
+
+
+
+ Reference Timeline: starts at 0, goes through the scale in 10s,
+
+
+
+
+ 1.
+ User event driven animation: starts upon
+ text focusing, stops after 2s or focus lost
+
+
+
+
+
+
+
+
+ 2.
+ User event driven animation: starts upon
+ text focusing, stops after 2s or focus lost
+
+
+
+
+
+
+
+
+
+ 3.
+ User event driven animation: starts upon
+ mouseover, stops after 2s or mouseout
+
+
+
+
+
+
+
+
+
+ 4.
+ User event driven animation: starts upon
+ mouseover. Stops after 10s
+
+
+
+
+
+
+
+
+ 5.
+ User event/animation event driven: runs
+ for 2s when animation (3) or (4) begins.
+
+
+
+
+
+
+
+ 6.
+ User event/animation event driven: runs
+ for 2s when animation (1) through (5) ends.
+
+
+
+ 7.
+ Animation events: starts at 0 and loops every two seconds.
+
+
+
+
+ $Revision: 1.12 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-209-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-209-t.svg
new file mode 100755
index 00000000..6634ca5d
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-209-t.svg
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+
+
+
+
+
+
Animation Elements with Discard
+
Four animation elements reference struct-discard-201.svg.
+
Each animation element is a target of a discard, at 6, 10, 14 and 18s.
+
To pass each animation element should discard at the specified time.
+
In addition, each referenced file should behave as indicated in the test struct-discard-201.
+ This slide tests independent primary documents. Each referenced primary document has a separate script context.
+ This test is only applicable if application/ecmascript is available.
+
+
Four animation elements reference a document which has an activate handler on a circle.
+
Focus should start on the top-left circle and move to top-right, bottom-left and bottom-right.
+
Activating the circle will toggle its radius size, but for the currently focused circle only.
+
This is due to the fact that each primary document has a separate script context.
+ Animation Element with animating xlink:href
+ This slide tests animating the xlink:href attribute of animation elements
+ Every 2.5 seconds the animation will display a circle instead of a timeline.
+ The circle is focusable and as such should receive the focus and turn red.
+
+
+
+ $RCSfile: media-anim-212-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Animation Element with animating xlink:href.
+ This slide tests animating the xlink:href attribute of animation elements.
+
+
+
+
+
+
+
+ Reference Timeline : starts at 0, goes through the scale in 10s.
+
+
+
+
+
+ Reference to external animation.
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-213-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-213-t.svg
new file mode 100755
index 00000000..608ed590
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-anim-213-t.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+
+
+
+
+
+
The file is a basic test of animation element.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
+ Audio Elements with Incorrect xlink:href.
+ This slide tests the audio xlink:href attribute with invalid values.
+
+
+ The test will pass if no audio can be heard.
+
+
+
+ $RCSfile: media-audio-214-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Audio element with invalid xlink:href.
+ Each audio element has a xlink:href reference to media
+ other than a supported audio file.
+
+
+
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-audio-215-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-audio-215-t.svg
new file mode 100755
index 00000000..444a5990
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-audio-215-t.svg
@@ -0,0 +1,249 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Tests the audio-level property for nested audio elements and clamping
+ of audio-level.
+
+
+ The test consists of 6 subtests. When each audio sub-test is executed a
+ corresponding rect will turn blue. When each audio sub-test is
+ finished the corresponding rect will turn gray again. For this test to pass, all subtests must
+ have a green rectangle next to them.
+
+ The audio must also be heard to pass this test. If the user agent does not support the WAV media format, the test is still a pass.
+
+
+ The 1st subtest has an audio-level = 1. To pass this subtest the audio
+ must be played at the system volume.
+
+
+ The 2nd subtest has an audio-level = 2. To pass this subtest the audio
+ must be played at the system volume.
+
+
+ The 3rd subtest has an audio element with an audio-level = 2. Within
+ the audio element there is a child audio element with an
+ audio-level = 0.5. The source audio is the child audio element. To pass
+ this subtest the audio must be played at 1/2 the system volume.
+
+
+ The 4th subtest has an audio element with an audio-level = 0.5. Within
+ the audio element there is a child audio element with an
+ audio-level = 2. The source audio is the child audio element. To pass
+ this subtest the audio must be played at 1/2 the system volume.
+
+
+ The 5th subtest has three audio elements. The first audio element has
+ an audio-level = 0.5 and is the parent audio element. The second audio
+ element has an audio-level = 2 and is a child to the first audio
+ element. The third audio element has an audio-level = 0.5 and is a
+ child to the second audio element. The source audio is third audio
+ element. To pass this subtest the audio must be played at 1/4 the
+ system volume.
+
+
+ The 6th subtest has four audio elements. The first audio element has
+ an audio-level = to the audio level of the 3rd audio element (0.5). The
+ second audio element references an audio element from another subtest
+ with an audio-level of 2. The second audio element is a child of the
+ first audio element. The third audio element has an audio-level = 0.5
+ and is a child of the second audio element. The fourth audio element
+ has an audio-level of 2 and is a child of the third audio element. The
+ source audio is the fourth audio element. To pass this subtest the
+ audio must be played at 1/4 the system volume.
+
+ The frame contains a video with width and height not specified - these should default
+ to 0 and nothing should be rendered.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+
+
+ $RCSfile: media-video-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Video Width and Height
+
+
+ The frame contains a video with width and height not specified - these should default
+
+
+ to 0 and nothing should be rendered.
+
+
+
+
+
+ $Revision: 1.9 $
+
+
+
+
+
+ DRAFT
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-202-t.svg
new file mode 100755
index 00000000..fe4a131d
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-202-t.svg
@@ -0,0 +1,55 @@
+
+
+
+
+
+
+
+
+
+
+
+
Video Width and Height
+
The video should play immediately and disappear once complete.
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+
+
+ $RCSfile: media-video-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Video Width and Height
+
+
+ The video should play immediately and disappear once complete.
+
+
+
+
+
+ $Revision: 1.10 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-203-t.svg
new file mode 100755
index 00000000..e5c47ffb
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-203-t.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
Video with TransformBehavior Set to Pinned
+
+ This file tests the transformBehavior attribute set to 'pinned'.
+ The video should always overlap the two crossing lines, even during zoom/pan, proving it
+ is always rendered at its native resolution, and pinned at its the center (the blue dot).
+ If the video is rendered inside the small rotated rectangle, it means the transformBehavior
+ attribute is not applied / supported.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+
+
+ $RCSfile: media-video-203-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Video with TransformBehavior Set to Pinned
+
+ The video should exactly overlap the two wide crossing lines, proving it is pinned on the blue dot
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-204-t.svg
new file mode 100755
index 00000000..993a750a
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-204-t.svg
@@ -0,0 +1,68 @@
+
+
+
+
+
+
+
+
+
+
+
+
Video with PreserveAspectRatio Attribute
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'none' on a video element. The width of
+ the video element has been made larger than the subsequent
+ preserveAspectRatio tets.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMin meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMidYMid meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMaxYMax meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMin meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMid meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'xMinYMax meet' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Testing variations of preserveAspectRatio attribute with viewports
+ having different aspect ratios. More specifically tests the case
+ of preserveAspectRatio set to 'none' on a video element.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Colored circles should maintain rendering order as marked on them.
+ Video is 10 seconds in length and should freeze at the end. The circles should continue to animate indefinitely
+ Bottom frame contains a jpeg reference image. The jpeg image is rendering order is on the top and the video
+ rendering order is on the bottom.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+
+
+ $RCSfile: media-video-212-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Video with rendering order
+
+ Colored circles should maintain rendering order as marked on them. Video should freeze at the end
+
+
+ Bottom frame contains a jpeg reference image. The jpeg image is rendering order is on the top and the video
+ rendering order is on the bottom.
+
+
+
+
+ BEHIND
+
+
+
+
+ BEHIND
+
+
+
+
+
+
+
+
+ BETWEEN
+
+
+
+
+ BETWEEN
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ON TOP
+
+
+
+
+ ON TOP
+
+
+
+
+
+ $Revision: 1.10 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-213-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-213-t.svg
new file mode 100755
index 00000000..5f276f44
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-213-t.svg
@@ -0,0 +1,77 @@
+
+
+
+
+
+
+
+
+
+
+
+
Rotation with Video and Image
+
+ Tests the case when type is set to 'rotate' in animateTransform. The test
+ contains two objects; one video and one image. Both are rotated about a
+ point definied by the center of the black circle. The video will rotate
+ clockwise, and the image will rotate anti-clockwise.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the rendering order of Video with other objects. Test contains
+ a video element with a polygon rendered over the top. The polygon has
+ a solid fill; no video should be visible through the polygon.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing and xlink href is changed the stream should change. The
+ new stream should start playing at the same position as the reference video, if the media play time cannot be controlled. Otherwise the media time will be re-started.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ Tests the different transformBehavior values on video.
+ Pinned, Pinned90, Pinned180, Pinned270
+
+
+ The 1st video element has transformBehavior set to pinned and is displayed in the top-left of a 4-video box.
+
+
+ The 2nd video element has transformBehavior set to pinned90 and is displayed in the top-right of a 4-video box.
+
+
+ The 3rd video element has transformBehavior set to pinned180 and is displayed in the bottom-left of a 4-video box.
+
+
+ The 4th video element has transformBehavior set to pinned270 and is displayed in the bottom-right of a 4-video box.
+
+
+ There are 4 green-stroked rectangles indicating the expected position and orientation, but not size.
+
+
+ The videos should display with the appropriate rotation, centered on the green rectangles but not bound by them in any way, since determining the exact pixel size of the rectangles is not possible.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ When no video element is displayable (visibility is hidden or display is none of the use element),
+ audio level should be set to 0 and video should not be rendered.
+ -Video1 should be displayed between 0-4s, not rendered between 4-6 s and displayed between 6-8s.
+ -Video2 should be displayed between 0-2s, not rendered between 2-6 s and displayed between 6-8s.
+ -The audio of the video should be muted between 4-6s as no video is then rendered.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+
+
+ $RCSfile: media-video-218-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Video 1
+
+
+
+ Video 2
+
+
+
+
+ Animated display and visibility with use
+
+
+ Video 1 should be hidden and muted between 4-6s
+
+
+ Video 2 should be hidden and muted between 2-6s
+
+
+
+
+
+ 0-2(s)
+
+
+
+
+ 2-4(s)
+
+
+
+
+ 4-6(s)
+
+
+
+
+ 6-8(s)
+
+ 0123456789(s)
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-219-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-219-t.svg
new file mode 100755
index 00000000..5ffed231
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-219-t.svg
@@ -0,0 +1,82 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ If a video is playing and it is repositioned by removing it's corresponding use
+ from tree and then reinserting it in tree the video should continue playing but change position
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ If a video is playing when it is removed from document tree
+ it should continue playing when re-inserted in tree.
+ - The video should change position at 2 seconds but continue playing.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+ When xlink:href is animated on a use element between two different video elements, the
+ displayed video should change and it should play at the current time.
+ -video1 should be displayed between 0-2 and 4-6s and video2 between 2-4s.
+
+
+ If the user agent does not support the 3GP media format, the test is still a pass.
+
+
+
+ $RCSfile: media-video-221-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Animated xlink:href on use
+
+ Stream should be switched at 2s and back again at 4s
+
+
+
+
+
+ 0-2(s)
+ Video 1
+
+
+
+
+ 2-4(s)
+ Video 2
+
+
+
+
+ 4-6(s)
+ Video 1
+
+
+
+
+ 6-8(s)
+ End
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-222-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-222-t.svg
new file mode 100755
index 00000000..a63dab69
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/media-video-222-t.svg
@@ -0,0 +1,57 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Video Elements with Incorrect xlink:href
+ This slide tests the video xlink:href attribute with invalid values
+
+
+
+ $RCSfile: media-video-222-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Video element with invalid xlink:href
+ Each video element has a xlink:href reference to media other than a supported video file.
+ The test will pass if no video is heard or seen.
+
+
+
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/metadata-example-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/metadata-example-01-t.svg
new file mode 100755
index 00000000..d1166b22
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/metadata-example-01-t.svg
@@ -0,0 +1,138 @@
+
+
+
+
+
+
+
+
+
+
+
+
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 DTD, but is well formed.
+
The diagram on the table is a visualization of the RDF metadata in the graphic.
+
The rendered result should match the reference image and there should be no error messages or warnings
+ The purpose of this test is to determine if an application has the basic capability to process the 'color' property.
+ There are three subtests.
+
+
+ The first subtest, to the top left, is passed if the circle has a red fill. The second subtest, to the top right, is
+ passed if the circle has a red stroke. The third subtest shows a rectangle with a gradient fill, which has three stops.
+ The subtest is passed if central stop is red, fading off to blue to the left and pale yellow to the right.
+
+ Purpose of test is to determine 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 shapes in the group uses
+ one of the syntactical forms and all in the group should be identical in color.
+
+
+ The first row uses five forms - 3-digit hex, 6-digit hex, rbg() integer form, rgb() percentage form, and named
+ ('HTML') 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.
+
+ Tests system colors. 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.
+
+
+
+ $RCSfile: paint-color-04-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
+ Vestibulum pulvinar. Duis laoreet, nunc vitae facilisis
+ tristique, pede sem iaculis mi, non consectetuer lorem
+ libero et est. Donec imperdiet purus sed odio. Duis
+ venenatis tortor eu lectus. Suspendisse sed metus at
+ metus viverra ultricies. Mauris porttitor, justo a vulputate
+
+
+
+
+ Load
+
+ Save
+
+
+
+
+
+
+
+ File
+ Edit
+
+
+
+ Lorem
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-color-05-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-color-05-t.svg
new file mode 100755
index 00000000..dbc13f98
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-color-05-t.svg
@@ -0,0 +1,44 @@
+
+
+
+
+
+
+
+
+
+
+
+
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. The user agent should render the rectangle with a RED fill.
+ This tests inheritance of three properties: "fill", "stroke" and "stroke-width". There is a "g" element (id="G1")
+ which sets fill="blue", stroke="red", 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="red" 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="red"
+ and stroke-width="5".
+
+
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.
+
+ 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.
+
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, red.
+ 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.
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling
+ text (per 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, red. 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
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
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 red (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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
Test that the viewer has basic capability to handle linear gradients on fills and stroke of 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 red (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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+
+
+ $RCSfile: paint-grad-08-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Gradient on fill
+ Linear gradient on filled text
+
+
+
+ Gradient on stroke
+ Linear gradient on stroke of text
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-09-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-09-t.svg
new file mode 100755
index 00000000..efbd623c
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-09-t.svg
@@ -0,0 +1,92 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test that the viewer can handle the gradientUnits attribute on linear gradients. It tests the following values of
+ gradientUnits : default (objectBoundingBox), specifying objectBoundingBox, and specifying 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 (red). 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 red (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 red (left) to blue
+ (right).
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
+
+
+ $RCSfile: paint-grad-09-t.svg,v $
+
+
+
+
+
+
+
+
+ Testing gradientUnits attribute
+
+
+
+
+
+
+
+
+ Linear gradient with default attributes (thus, same as objectBoundingBox)
+
+ Gradient is from the object left edge (red) to object right edge (blue)
+
+
+
+
+
+
+
+
+ gradientUnits=objectBoundingBox
+ Gradient is from the object top edge (blue) to object bottom edge (red)
+
+
+
+
+
+
+
+
+ gradientUnits=userSpaceOnUse
+ Gradient is from the object left edge (red) to object right edge (blue)
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-11-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-11-t.svg
new file mode 100755
index 00000000..de0e835e
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-11-t.svg
@@ -0,0 +1,95 @@
+
+
+
+
+
+
+
+
+
+
+
+
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 black(in) to red(outside). The gradiant 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
+ red(in) to yellow (out).
+
+
The next item is a text with a radial gradient on the fill. The gradient goes from black (in) to yellow (out).
+
The last item is a text with a 2 user unit stroke on which a black (in) to red (out) linear gradient is applied.
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
+
+
+ $RCSfile: paint-grad-11-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Radial gradient on fill of rectangle
+
+
+
+
+
+
+
+
+ Radial gradient on stroke of rectangle
+
+
+
+
+
+
+
+ Gradient on text fill
+ Radial gradient on text, black to yellow
+
+
+
+
+
+
+
+ Gradient on text stroke
+ Radial gradient on stroke of text, black to red
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-12-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-12-t.svg
new file mode 100755
index 00000000..965d3564
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-12-t.svg
@@ -0,0 +1,93 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 (red). 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 red (center) to blue (edge).
+
+
+ The rendered picture should match the reference image exactly, except for possible variations in the labelling text
+ (per CSS2 rules).
+
+
+
+ $RCSfile: paint-grad-12-t.svg,v $
+
+
+
+
+
+
+
+
+ Testing gradientUnits attribute
+
+
+
+
+
+
+
+
+ Radial gradient with default attributes (from blue to red)
+ Gradient is blue at the object center and red at the object edges
+
+
+
+
+
+
+
+
+ gradientUnits=objectBoundingBox
+ cx=.2, cy=.2, r=.5
+
+
+
+
+
+
+
+
+ gradientUnits=userSpaceOnUse
+ Gradient is red to blue radial gradiant from center to horizontal bounds
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-15-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-15-t.svg
new file mode 100755
index 00000000..16055231
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-15-t.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test linear and radial gradient defaults. Includes testing defaults for linear grad x1,y1,y2 = 0.0, x2 = 1.0 and
+ testing defaults for radial grad cx,cy,r = 0.5
+
+
+ The top rectangle must be blue at the lefthand side and red at the right hand side, fading smoothly accross. The
+ lower rectangle must be red 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.
+
+
+ The top rectangle must have a red outline and no fill. The middle rectangle must have a solid black fill. The
+ lower rectangle must have a yellow to red 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.12.
+
+
+ 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. The result should be that the top-left rectangle is filled with a gradient from green to red since the stop-color is inherited from the location of the gradient definition.
+
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. The result should be that the top-right rectangle filled in green with a gradient 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. The result should be that the lower-left rectangle filled with a gradient going from fully-opaque green to fully-opaque black.
+
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 that the lower-right rectangle filled with a gradient going from fully-opaque green to fully-opaque yellow.
+ This test shows rectangles filled with animated gradient which inherits some of their properties: stop-color, stop-opacity.
+ The correct result must show: - the top-left rectangle filled initially with a linear green-to-red gradient and turning into
+ a solid green color after 5s. - the top-right rectangle filled initially with a green gradient fully opaque on the left and
+ half transparent on the right, but after 5s the rectangle must be filled with a fully opaque solid green. - the bottom-left
+ rectangle filled with a static green-to-black opaque gradient - the bottom-right rectangle initially filled with a green-to-yellow
+ fully-opaque gradient animated and turning into a fully-opaque green solid color. Animations numbered a4 to a7 must have no impact.
+
+ A linearGradient is defined with a stop-opacity of 0 that is also animated from 0 to 1 (clear to solid).
+ The yellow star must initially be visible through the gradient. After 5 seconds most of the start must
+ be covered by the linearGradient.
+
+ There are three lines of text. For this test to pass each line of text must have the same gradient
+ from green to blue all set to a 'stop-opacity' of 0.4 . The reference rect at the bottom has a
+ similar gradient but with 'stop-opacity set to 1. The text of the poem should be lighter than
+ the reference line.
+
+
+
+ $RCSfile: paint-grad-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Stop Opacity Attribute with Text
+
+ All three lines of text must have the same transparent gradient -
+ from green to blue, set at 0.4 'stop-opacity'. The reference rect at
+ the bottom has a similar gradient but with 'stop-opacity set to 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ old pond
+ a frog leaps in -
+ a moment after, silence
+
+
+
+
+
+ Frog Haiku by Matsuo Basho (1686), translated by Ross Figgins
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-203-t.svg
new file mode 100755
index 00000000..351e3379
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-grad-203-t.svg
@@ -0,0 +1,77 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test on gradients with gradientUnits set. There are two rects, one using a gradient with gradientUnits set to "objectBoundingBox" and one with "userSpaceOnUse". Both rects contain a smaller rect to visualise the use of gradientUnits.
+ In the top rect, the small one should appear as a smaller version of the big rect.
+ In the bottom rect, the small one should just as a "frame" on the big rect.
+
+ Gradient with no stop-elements. The painting shall occur as if 'none' were specified
+ as the paint style, thus allowing the pale blue rectangle to be seen inside the square.
+
Testing non-scaling-stroke on basic shapes and text.
+
The bottom shapes - triangle and oval - also have a gradient applied to the outline stroke.
+
+ At the start the two sets of shapes may not appear identical - depending on viewport size.
+ As the geometric shapes are zoomed out the outline strokes of the left-hand set of shapes
+ should remain fixed while the strokes of the right-hand set should scale in proportion to the shapes.
+
+
+
+ $RCSfile: paint-nsstroke-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+ As the geometric shapes are zoomed out the outline strokes of the left-hand set of shapes
+ should remain fixed while the strokes of the right-hand set should scale in proportion to the shapes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ABCDE
+
+ ABCDE
+
+
+
+
+
+
+
+
+ Non-Scaling Stroke
+ Scaling Stroke
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-nsstroke-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-nsstroke-203-t.svg
new file mode 100755
index 00000000..3b63163c
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-nsstroke-203-t.svg
@@ -0,0 +1,116 @@
+
+
+
+
+
+
+
+
+
+
+
+
Non-scaling Stroke
+
Testing "non-scaling-stroke" on basic shapes with "animate" and "animateTranform".
Test solidColor paint server with 'solid-opacity' attribute.
+
+ There are three 'solidColor' definitions - red, green, blue.
+ These are used for both the fill and outlines of the rectangle and circle.
+
+
+
+ $RCSfile: paint-other-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Solid Color Paint Server
+
+ There are three 'solidColor' definitions - red, green, blue.
+
+
+ These are used for both the fill and outlines of the rectangle and circle.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-other-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-other-203-t.svg
new file mode 100755
index 00000000..a0da3443
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-other-203-t.svg
@@ -0,0 +1,75 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test solidColor animation. Animates solid-color and solid-opacity on two rects.
+
+
+ The test is passed if the following objects are displayed:
+ Rect 1
+ - Fill: blue animated to red, opacity 0 animated to 1
+ - Stroke: none
+
+ Rect 2 (roated -30 degrees)
+ - Fill: none
+ - Stroke: red animated to yellow, opacity 1 animated to 0
+
+
+ One rect animates its fill from blue to red over 3 seconds and has its solid-opacity animated from 0 to 1 over 5 seconds.
+ The other rect (no fill and rotated -30) has its stroke animated from red to yellow over 3s and solid-opacity from 1 to 0 over 5 seconds.
+
+ 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 red stroke.
+
+
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", stroke="red",
+ "font-family" (Arial) and "font-size" attributes.
+
+ Verify the basic capability to handle the stroke properties ("stroke", "stroke-width", "stroke-linejoin") in
+ combination with the "rect" element. The pair should be rendered as two red rectangles without an interior fill.
+ The upper rectangle should have a stroke width of 5 with sharp corners. The lower rectangle should have a stroke
+ width of 5 with round corners.
+
+
+ The test uses the "rect" element, as well as basic "fill" (solid primary colors), "stroke", stroke="red"
+ stroke-width="10" stroke-linejoin="round", "font-family" (Arial) and "font-size" properties.
+
+ Verify the basic capability to handle the stroke properties ("stroke", "stroke-width" "stroke-linejoin", "stroke-linecap",
+ "stroke-miter") in combination with straight-line path commands. The pair should be rendered as as two red line segments.
+ The upper segment should have round end caps. The lower segment should be chopped off where the two line segments meet.
+
+
+ The test uses the "path" element, as well as basic "fill" (solid primary colors), "stroke", "stroke-width",
+ "stroke-linejoin", "stroke-linecap", "stroke-miter", "font-family" (Arial) and "font-size" properties.
+
+ Verify the "stroke-dasharray" and "stroke-dashoffset" properties. Two lines are drawn, one red 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 help show this, the black line has a "stroke-dashoffset" so that the dashes in the black
+ line match up with the gaps in the red line.
+
+
+ The test uses the "path" element, "stroke", "stroke-width", "stroke-dasharray" and "stroke-dashoffset", "font-family"
+ (Arial) and "font-size" properties.
+
+ User agents may render graphical primitives with different levels of accurancy.
+ This test is aimed at determining how does a UA render thin strokes.
+
+
+ The test file contains a number of vertical and horizontal lines.
+ The stroke width of the vertical lines are increasing from left to right.
+ The stroke width of the horizontal lines are increasing from top to bottom.
+ The user should be able to see a smooth stroke width increment for the vertical and horizontal lines.
+
+ 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 red 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. Thus, 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.
+
+ Stroking for circle, large stroke-width, small r.
+
+
+ The main indication for a failed test is the appearence of something red.
+ A second indication is a thin white line inside a blue area.
+
+
+ For smaller circles the radius gets smaller than the half stroke-width, therefore the fill is not
+ visible anymore for them. Only the animated circle at the beginning and the next circle
+ on its right have a visible fill.
+
+
+ To test the correct rendering, the blue circles cover always red filled circles without a stroke.
+ Additionally the size of the circles is given with a thin white stroke on top. If something
+ red gets visible or blue parts of the stroke of the circle are outside of the related white
+ stroked circle, an error is occured. If the circles are not displayed as circles with an accuracy of
+ one device pixel, an error is occured too.
+
+ Direction of stroke-dasharray and stroke-dashoffset for basic shapes.
+
+
+ The main indication for a failed test is the appearence of a blue path on
+ a white background area. It is passed, if all blue paths are on a gray background area.
+
+
+ stroke-dasharray and stroke-dashoffset are tested on basic shapes circle, ellipse, rectangle,
+ rectangle with rounded corners, line, polyline and polygon. The test is sensitive to the
+ direction of stroke-dasharray and stroke-dashoffset and on the starting point on the basic
+ shape.
+
+
+ The dashes are positioned correctly, if they are only on a gray background area.
+ If there are dashes on a white background, this is an indication for an error.
+ Additional information given in the elements title and desc for the related subtest
+ may help to identify the tested shape and property combination and the error,
+ if there is one.
+
+
+
+ $RCSfile: paint-stroke-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+ background of filled rectangles indicating stroking areas in gray
+
+
+
+
+
+
+
+
+
+
+
+
+ testing stroke-dasharray for circle, rectangle with rounded corners, ellipse
+
+ stroke-dasharray on circle without stroke-dashoffset
+ Note that the pathLength of the circle is exactly 560
+
+
+ stroke-dasharray on rect with rounded corners without stroke-dashoffset
+ Note that the pathLength of the rect is exactly 560
+
+
+ stroke-dasharray on ellipse without stroke-dashoffset
+ Note that the pathLength of the ellipse is exactly 560
+
+
+
+
+ stroke-dasharray on circle without negative stroke-dashoffset
+ Note that the pathLength of the circle is exactly 560
+
+
+ stroke-dasharray on rect with rounded corners with negative stroke-dashoffset
+ Note that the pathLength of the rect is exactly 560
+
+
+ stroke-dasharray on ellipse with positive stroke-dashoffset
+ Note that the pathLength of the ellipse is exactly 560
+
+
+
+
+
+ testing stroke-dasharray for line, polyline, polygon
+
+
+
+ stroke-dasharray on line with stroke-dashoffset set to 0
+
+
+ stroke-dasharray on polyline with stroke-dashoffset set to 0
+
+
+ stroke-dasharray on polygon with stroke-dashoffset set to 0
+
+
+
+
+
+
+ stroke-dasharray on line with stroke-dashoffset
+
+
+ stroke-dasharray on polyline with negative stroke-dashoffset
+
+
+ stroke-dasharray on polygon with stroke-dashoffset
+
+
+
+
+
+ testing stroke-dasharray for rectangles
+
+ stroke-dasharray on rect with positive stroke-dashoffset
+
+
+
+ stroke-dasharray on rect with rounded corners with positive stroke-dashoffset
+ Note that the pathLength of the rectangle is exactly 560, the round parts are 2pi*rx
+
+
+
+ stroke-dasharray on rect with negative stroke-dashoffset
+
+
+
+
+
+ position of the dashes:
+ blue on gray: ok
+ blue on white: fail
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-stroke-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-stroke-204-t.svg
new file mode 100755
index 00000000..ba49de73
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-stroke-204-t.svg
@@ -0,0 +1,181 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Precision tests for stroke-linejoin.
+
+
+ The main indication for a failed test is the appearence of something red.
+
+
+ stroke-linejoin is tested, using a comparsion with filled or stroked paths or shapes with the same appearance.
+ This is tested for different three miter angles for the values round, miter and bevel, for each of them one with
+ test path on top of the comparsion shapes and one with the path below.
+
+ The four paths top right test the inheritance either for the value explicitely set to 'inherit' or a missing stroke-linejoin property.
+
+
+
+ The top is always blue. If something
+ red gets visible, an error is occured.
+
+ Stroking for subpaths with path length zero, depending on stroke-linecap.
+
+
+ The main indication for a failed test is the appearence of something red
+ (this simple indication may fail itself, if the viewer does not support stroke-linecap).
+
+
+ Several paths containing a subpath with length zero are
+ stroked and some of them animated.
+
+
+ The zero length subpath is placed between two
+ other subpaths of finite length or before or after a
+ subpath of finite length or in one case the path consists of two
+ subpaths of length zero.
+ The behaviour is checked for stroke-linecap round,
+ square (subpath visible) and bevel (subpath not visible)
+ on the left.
+
+
+ On the right the behaviour is tested with simple
+ animations to check the correct alignment
+ or shrinking to zero length.
+ stroke-linecap is animated between round or square too
+ for some of them.
+
+
+ The behaviour is compared with similar paths with a
+ subpath of a very small length. Because the red stroked
+ paths have a slightly smaller stroke, they are always covered
+ by blue paths.
+ If something red gets visible, an error is occured.
+
+
+
+ $RCSfile: paint-stroke-205-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+
+
+
+
+ linecap square - zero path visible
+
+
+
+ Blue testcase 3
+
+
+
+
+ linecap round - zero path visible
+
+
+
+
+ linecap butt - zero path not visible, blue covers all red
+
+
+
+
+
+
+
+
+ linecap square - zero path visible
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+
+ Red comparison - if visible - error
+
+
+ Blue testcase covers all red if correct
+
+
+
+
+
+ stroking of path fragments
+ with length zero
+ red = wrong
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-stroke-207-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-stroke-207-t.svg
new file mode 100755
index 00000000..22a36a1f
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-stroke-207-t.svg
@@ -0,0 +1,106 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Centering of stroke on the outline of rectangles.
+
+
+ The main indication for a failed test is the appearence of something red.
+
+
+ The width and position of the stroke centered on the outline of a rectangle is tested with four stroked rectangles,
+ one is the thin black stroked test frame rectangle, the second one a large blue rectangle, the third a rectangle
+ with rounded corners, looking like a circle and the fourth a small square.
+
+
+ The correct position is tested by a comparsion with several filled rectangles in the background or in the fourth case
+ covering the test square completely. The parts of the background covered with the blue test rectangles are filled red,
+ respectively the test square is stroked red too.
+ Therefore if something red gets visible, the position of the stroke of
+ the related test rectangle is wrong.
+
+
+ According to the conformance criteria all visual rendering should be accurate to within one px unit to the mathematically
+ correct result. Therefore possible residuals from the red background parts have to be in this
+ range of accuracy to pass the test.
+
+
+
+ $RCSfile: paint-stroke-207-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ background of filled rectangles indicating the position of the stroked test rectangles
+
+
+
+
+
+
+
+
+
+
+
+
+ large blue stroked test rectangle
+
+
+ small blue stroked test rectangle with rounded corners looking like a circle
+
+
+
+
+
+
+ small red stroked test rectangle
+
+
+ small blue rectangles to cover the small red stroked test rectangle
+
+
+
+
+
+
+
+
+ position of the stroke:
+ red = wrong
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-vfill-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-vfill-201-t.svg
new file mode 100755
index 00000000..26551402
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-vfill-201-t.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
Viewport Fill Attribute
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'silver'.
+ At the start the entire background should be a light grey.This should then change to aqua.
+ There are two reference squares in the center - silver and aqua.
+
+
+
+ $RCSfile: paint-vfill-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Viewport Fill Attribute
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'silver'.
+
+
+ At the start the entire background should be a light grey.This should then change to aqua.
+
+
+ There are two reference squares in the center - silver and aqua.
+
+
+
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-vfill-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-vfill-202-t.svg
new file mode 100755
index 00000000..f93aa1d9
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paint-vfill-202-t.svg
@@ -0,0 +1,50 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Tests viewport-fill and viewport-fill-opacity.
+ The image should show the correct viewport-fill (green).
+
+ Test on viewport-fill and viewport-fill-opacity.
+ Animates viewport-fill from yellow to blue over one second, and animates viewport-fill-opacity from 1.0 to 0.5.
+
+ Test on viewport-fill and viewport-fill-opacity. viewport-fill-opacity is set to 0.0 so the set viewport-fill
+ color should not be visible. The image has its viewport-fill set to "inherit" and viewport-fill-opacity to 1.0
+ so the image should show with a yellow viewport-fill and full opacity.
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'yellow'
+ with a 'viewport-fill-opacity' of 1. At the start the entire background should be solid yellow.
+ This should then change to a pale bluish gray. There are two reference squares in the center - solid yellow - to
+ match the background at the start and a pale yellow that should match the backgound after a few seconds.
+
+
+
+ $RCSfile: paint-vfill-206-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Viewport Fill Opacity Attribute
+
+ The root SVG element of this test slide has a 'viewport-fill' attribute set to 'yellow'
+
+
+ with a 'viewport-fill-opacity' of 1. At the start the entire background should be solid yellow.
+
+
+ This should then change to a pale bluish gray. There are two reference squares in the center.
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.9 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/paths-data-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paths-data-01-t.svg
new file mode 100755
index 00000000..407a70ac
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/paths-data-01-t.svg
@@ -0,0 +1,132 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'path' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'rect' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
Verifies that shapes can be filled, stroked and the order of filling and stroking.
+
There is one pair of octagons. These are filled plus stroked.
+
The rendered image should match the reference image except for the text which may show minor layout differences.
+
The test uses the 'rect' element, as well as basic fill (solid primary colors), stroke (primary color 1-pixel and wide lines), font-family (Arial) and font-size properties - the common prerequisites.
Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). It also validates basic Shape, Image and text rendering.
+
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" should show through the rectangle and none of the rectangle should show through the image.
+
Prerequisites: the test assumes proper handling of the fill stroke, stroke-width, font-size rendering properties. It uses the rect, line, text and image elements, as well as all the elements required for the test template. To ensure that the text string is overlapped by the other elements and to avoid a dependency on system fonts, an SVG font is used.
+
The rendered image should match the reference image exactly.
Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4). It also validates basic Shape, Image and text rendering.
+
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" should show through the rectangle and none of the rectangle should show through the image.
+
Prerequisites: the test assumes proper handling of the fill stroke, stroke-width, font-size rendering properties. It uses the rect, line, text and image elements, as well as all the elements required for the test template. To ensure that the text string is overlapped by the other elements and to avoid a dependency on system fonts, an SVG font is used.
+
The rendered image should match the reference image exactly.
+ Test that when a script element has both an xlink:href attribute and child character data,
+ the executable content for the script is retrieved from the IRI of the xlink:href attribute,
+ and the child content is not added to the scripting context.
+
+
+ The test loads an external script resource, which if executed sets the fill or the blue rect to green.
+ If the child content is executed the fill will be set to red and an alert will be displayed.
+
+
+ The test has passed if the rect is green after script execution has taken place and there has been no
+ alert displayed.
+
+ Test that scripts are not processed until added to the DOM tree. Also test that a function defined in a script
+ element can be called from a handler element in the same scripting context.
+
+
+ When the blue rect is clicked a script element is created. The script to be run must not be processed until
+ the script element is added to the tree. If it is processed before added to the tree, the rect that is
+ inserted into the document will be red. If not, then it will be green.
+
+
+ The test has passed if after clicking the blue rect a green rect is displayed in its place.
+
+ The test consists of 8 subtests, each testing requirements from the script processing section.
+ When the test is first loaded it shows 8 red circles. After the scripts have been executed the circles should all be green.
+
+
+ The test has passed if all 8 circles are green after the script processing has taken place.
+
Tests basic mouse event handler and DOM manipulation through ECMA script binding.
+
The test uses ECMA Script 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
The test shows a target that can be used to generate the various kinds of mouse and keyboard 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.
+ Test of script handlers for SMIL events. A red square should flash on the screen six times.
+
+
+
+ $RCSfile: script-handle-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+ Test of script handlers for SMIL events. A red square should flash on the screen six times.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ flipVisibility(evt);
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/script-listener-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/script-listener-201-t.svg
new file mode 100755
index 00000000..94847683
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/script-listener-201-t.svg
@@ -0,0 +1,83 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test tests the assertion from the Namespaces in XML specification,
+ "The namespace prefix, unless it is xml or xmlns, MUST have been declared
+ in a namespace declaration attribute in either the start-tag of the element
+ where the prefix is used or in an ancestor element (i.e. an element in whose content the prefixed markup occurs)."
+ The root element doesn't declare the XML Event namespace for the prefix "ev".
+
+
+ The test has passed if handlers are implemented (the handler with xml:id="passhandler" has run)
+ but the handler with xml:id="failhandler" has not run.
+ If the handler is run then the text in the testcase will show "Test failed: magic prefixes!".
+ If handlers are not implemented at all, the testcase will show "Test failed: handlers not implemented."
+
+
+ The test is also passed if the implementation states somehow that the test case is not namespace
+ well formed (by overlaying it on the image, informing the user in the error console, not
+ showing the document at all, etc.).
+
+ This test tests that a handler is not found when the 'handler' attribute contains
+ an IDREF. The test fails if a red rectangle covers the text content area or the string "Test failed" is displayed.
+
+ This test tests that an element with the name 'listener' is not interpreted as an svg element,
+ and that it's not the same as an element named 'listener' in the XML Events namespace.
+
+
+ The test has passed if handlers are implemented (the handler with xml:id="passhandler" has run)
+ but the handler with xml:id="failhandler" has not run.
+
+ If the handler is run then the text in the testcase will show "Test failed: 'listener' is not an svg element.".
+
+ The pass condition is indicated by two rects that must both be green after running the test, if
+ either of the rects is red then the test has failed.
+
+ This test tests the 'propagate' and 'defaultAction' attributes on the XML Event 'listener' element.
+
+
+ The test has passed if after clicking the each of the blue rects they both turn green and show the text "Passed",
+ and that clicking the leftmost rect doesn't traverse the link. If any of the rects are blue or red after clicking
+ them the test has failed.
+
Tests the degenerate cases of the basic shapes. The shapes are positioned within the black rectangles.
+
None of the shapes should be visible (each of the ten black rectangles should be empty). The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+
+
+ $RCSfile: shapes-intro-01-t.svg,v $
+
+
+
+
+
+
+
+
+ Testing the degenerate cases of the basic shapes; attribute values set to zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Stroked
+ Unstroked
+ Zero width rect
+ Zero height rect
+ Zero radius circle
+ Zero x radius ellipse
+ Zero y radius ellipse
+ Zero length line
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-line-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-line-01-t.svg
new file mode 100755
index 00000000..e5c6525c
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-line-01-t.svg
@@ -0,0 +1,68 @@
+
+
+
+
+
+
+
+
+
+
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ For this test to pass the following lines must be drawn:
+ - Green line across the top from 480,0 to 0,0
+ - Red line across the left hand side from 0,0 to 0,360
+ - Blue line across the bottom from 480,360 to 0,360
+ - Purple line across the test from 480,85 to 0,0
+ - Fuchsia line across the test from 0,0 to 480,170
+ - Aqua line across the test from 0,360 to 480,170
+ - Teal line across the test from 480,256 to 0,360
+
+
+ If the x1, x2, y1, or y2 attribute is not specified the effect is as if
+ a value of "0" were specified.
+
+
+ The rendered picture should match the reference image, except for possible
+ variations in the labelling text (per CSS2 rules).
+
+ Testing different points attribute syntaxes, empty and invalid points
+ attributes (e.g. odd number of coordinates).
+
+
+ Only three identical polygon elements should be rendered down the
+ right hand side of the test.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules).
+
+
+
+ $RCSfile: shapes-polygon-02-t.svg,v $
+
+
+
+
+
+
+
+
+ Test that empty and invalid points attributes don't result in rendering 'polygon' elements.
+ Only three similar <polygon /> elements should be rendered.
+ Three different syntaxes in the points attribute.
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-polyline-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-polyline-01-t.svg
new file mode 100755
index 00000000..1ee881c7
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-polyline-01-t.svg
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+
+
+
+
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+ Testing different points attribute syntaxes, empty and invalid points
+ attributes (e.g. odd number of coordinates).
+
+
+ Only three identical polygon elements should be rendered down the
+ right hand side of the test.
+
+
+ The rendered picture should match the reference image, except for possible
+ variations in the labelling text (per CSS2 rules).
+
+
+
+ $RCSfile: shapes-polyline-02-t.svg,v $
+
+
+
+
+
+
+
+
+ Test that empty and invalid points attributes result in not rendering <polyline /> elements.
+ Only three similar <polyline /> elements should be rendered.
+ Two different syntaxes in the points attribute.
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.4 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-rect-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-rect-01-t.svg
new file mode 100755
index 00000000..3e5deec8
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/shapes-rect-01-t.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
+
Testing the default attributes on the rect element. There should be four rectangles. One should be placed on the left (default x), one on the top (default y). Two rounded rectangles should appear where rx and ry are of the same value (one of the two had been omitted).
Testing the correct stroking of the rect element. The blue lines indicate where a dash or gap should start and end. For the test to pass, it has to match the reference image.
+ Tests that the value of the 'class' attribute is included in the DOM,
+ including space-separated values, and values with extraneous spaces.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing three green circles, with text below each circle
+ reflecting the normalized space-separated values for the class of that
+ circle. The leftmost circle has the value "foo", the middle circle has
+ the value "bar baz", and the rightmost circle has the value
+ " funky spacing ", normalized to "funky spacing". If any of the
+ circles are red, the test has failed.
+
+ Tests that reading of IDs and modification of id and xml:id is conformant to the SVG and xml:id specifications. The test passes if four green circles are shown.
+
+
+ The first circle has an id only; the second, xml:id only. The third circle has both, with the same values; and the fourth has both, with different values. All four circles have a red fill; on loading the document, a script
+ gets each of the circles by its ID and then sets the fill to green. Lastly, the script attempts
+ to get the fourth circle by ID, using the value of the id attribute; this must fail. If the fourth
+ circle is dark red, the implementation is not giving priority to the value of xml:id.
+
+
+
+ $RCSfile: struct-common-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ id only
+ xml:id only
+ id and
+ xml:id, same
+ values
+ id and
+ xml:id, different
+ values
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-01-t.svg
new file mode 100755
index 00000000..5e473174
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-01-t.svg
@@ -0,0 +1,46 @@
+
+
+
+
+
+
+
+
+
+
+
+
This test evaluates a switch statement. The result should be a green rectangle in the lower left quarter of the output window.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
This tests ability to use the 'systemLanguage' as a test attribute within a switch element. To pass, either
+
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).
+
+
+ $RCSfile: struct-cond-02-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Waarom kan hulle nie net doodgewoon Afrikaans praat nie?
+ Afrikaans
+
+
+ ለምንድነው አማርኛ የማይናገሩት፧
+ Amharic
+
+
+
+ لماذا لا يتكلمون اللّغة العربية فحسب؟
+ Arabic (SA)
+
+
+ Защо те просто не могат да говорят български ?
+ Bulgarian
+
+
+ ওরা েকন বাংলা বলেত পাের না ?
+ Bengali
+
+
+
+ Per què no poden simplement parlar en català ?
+ Catalan
+
+
+ Proč prostě nemluví česky ?
+ Czech
+
+
+ Pam dydyn nhw ddim yn siarad Cymraeg ?
+ Welsh
+
+
+ Hvorfor kan de ikke bare tale dansk ?
+ Danish
+
+
+
+ Warum sprechen sie nicht einfach Deutsch ?
+ German (DE)
+
+
+ Μα γιατί δεν μπορούν να μιλήσουν Ελληνικά ;
+ Greek (modern, GR)
+
+
+ Why can't they just speak English ?
+ English (US)
+
+
+ ¿Por qué no pueden simplemente hablar en castellano ?
+ Spanish (ES)
+
+
+ Zergatik ezin dute Euzkeraz bakarrik hitzegin?
+ Basque
+
+
+ خب، چرا فارسى صحبت نمى كنند؟
+ Farsi
+
+
+ Miksi he eivät yksinkertaisesti puhu suomea ?
+ Finnish
+
+
+
+ Pourquoi, tout simplement, ne parlent-ils pas en Français ?
+ French (FR)
+
+
+ Carson nach eil iad a'bruidhinn na Gàidhlige ?
+ Scots Gaelic
+
+
+ બદ્ધા લોકો ગુજરાતી કૅમ નથી બોલતા?
+ Gujarti (IN)
+
+
+
+ למה הם פשוט לא מדברים עברית ?
+ Hebrew (modern)
+
+
+ यह लोग हिन्दी क्यों नहीं बोल सकते हैं ?
+ Hindi
+
+
+ Zašto jednostavno ne govore hrvatski ?
+ Croatian
+
+
+ Miért nem beszélnek egyszerűen magyarul ?
+ Hungarian
+
+
+ Ինչու՞ նրանք չեն խոսում Հայերեն
+ Armenian
+
+
+ Mengapa mereka tidak bisa bicara bahasa Indonesia ?
+ Indonesian
+
+
+ Hvers vegna geta þeir ekki réttlátur tala Íslenska ?
+ Icelandic
+
+
+ Perchè non possono semplicemente parlare italiano ?
+ Italian
+
+
+
+ ᓱᒻᒪᓂᒃᑯᐊ ᐃᓄᒃᑎᑐ ᑐᐃᓐᓇᔭᙱᓚᑦ
+ Inuktitut
+
+
+ なぜ、みんな日本語を話してくれないのか?
+ Japanese (JP)
+
+
+ Kenapa kok ora nganggo basa Jawa wae?
+ Javanese
+
+
+ რატომ არ ლაპარაკობენ ისინი ქართულად ?
+ Georgian
+
+
+ Олар неге қазақ тiлiнде сойлемейдi?
+ Kazakh
+
+
+ ಅವರು ಕನ್ನಡ ಮಾತನಾಡಬಹುದಲ್ಲಾ?
+ Kannada
+
+
+ 세계의 모든 사람들이 한국어 를 이해한다면 얼마나 좋을까?
+ Korean
+
+
+ Емне үчүн алар кыргызча сүйлбйт?
+ Kirghiz
+
+
+ Kodėl gi jie nekalba lietuviškai ?
+ Lithuanian
+
+
+ Зошто тие едноставно не говорат македонски ?
+ Macedonian
+
+
+ लोकांना मराठी का बोलता येत नाही?
+ Marathi
+
+
+ Waarom spreken ze niet gewoon Nederlands ?
+ Dutch
+
+
+ Hvorfor kan de ikke bare snakke norsk ?
+ Norwegian
+
+
+ ସେମାନେ ଉଡିଯା ରେ କହିନ୍କି କହିବେ ନହିଁ?
+ Oriya
+
+
+ Dlaczego oni nie mówią po polsku ?
+ Polish
+
+
+
+ Porque é que eles não falam simplesmente em Português ?
+ Portugese (PT)
+
+
+ Porque é que eles não falam em Português (do Brasil) ?
+ Portugese (BR)
+
+
+ Porque é que eles não falam simplesmente em Português ?
+ Portugese
+
+
+ De ce ei nu vorbesc moldoveneşte ?
+ Romanian
+
+
+ Почему же они не говорят по-русски ?
+ Russian
+
+
+ ते किं संस्कृतः माम वदन्ति ?
+ Sanskrit
+
+
+ Zašto jednostavno ne govore srpski ?
+ Serbian
+
+
+ අැයි ඔවුන්ට ඉංගරිස කතා ෛනබ ?
+ Sinhalese
+
+
+
+ Zakaj vendar ne govorijo slovensko ?
+ Slovenian
+
+
+ Pse nuk duan të flasin vetëm shqip ?
+ Albanian
+
+
+ Varför pratar dom inte bara svenska ?
+ Swedish
+
+
+ அவர்கள் ஏன் தமிழில் பேசக்கூடாது ?
+ Tamil
+
+
+ తెలుగు లో ఎందుకు మాట్లాడరు?
+ Telugu
+
+
+ Čaro onho ba zaboni točiki gap namezanand?
+ Tajik
+
+
+ ทำไมเขาถึงไม่พูด ภาษาไทย
+ Thai
+
+
+ Bakit hindi na lang sila magsalita ng Tagalog ?
+ Tagalog (Filipino)
+
+
+ Neden Türkçe konuşamıyorlar?
+ Turkish
+
+
+ Нишләп олар татарча сүләша алмыйлар?
+ Tatar
+
+
+ Чому б їм не розмовляти українською ?
+ Ukranian
+
+
+ ﻦﻴﻫ ﻰﺘﻠﻭﺒ ﻦﻴﻬﻨ ﻦﻭﻴﻜ ﻮﺪﺭﺃ بس ﻮﻩ ﻟﻮﮒ؟
+ Urdu (IN)
+
+
+ ﻦﻴﻫ ﻰﺘﻠﻭﺒ ﻦﻴﻬﻨ ﻦﻭﻴﻜ ﻮﺪﺭﺃ بس ﻮﻩ ﻟﻮﮒ؟
+ Urdu (PK)
+
+
+
+ Nega ular uzbek tilinda gapirmaidilar?
+ Uzbek
+
+
+ Tại sao họ không thể chỉ nói tiếng Việt ?
+ Vietnamese
+
+
+ פֿאַרװאָס רעדט מען ניט פּשוט ייִדיש ?
+ Yiddish
+
+
+ 他们为什么不说中文 (中国) ?
+ Chinese (CN)
+
+
+ 他們爲什麽不說中文(台灣)?
+ Chinese (TW)
+
+
+
+ You have no (matching) language preference set
+ なぜ、みんな日本語を話してくれないのか?
+ Why can't they just speak English ?
+ Pourquoi, tout simplement, ne parlent-ils pas en Français ?
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-03-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-03-t.svg
new file mode 100755
index 00000000..df18dcb1
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-03-t.svg
@@ -0,0 +1,97 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Tests the <switch> element with requiredFeature. If a red rectangle with white text 'FAIL' is
+ displayed, the test fails. Otherwise, if a green rectangle is displayed in the lower part with the text '',
+ the test is passed.
+
+
+ The red rectangle and the white text each require a non-existent feature; the test attribute will thus
+ evaluate to false and neither element will be rendered by a compliant implementation.
+
+
+ The upper subtest is informative; it distinguishes between a purely SVG Tiny 1.2
+ implementation and others which also implement more (eg SVG Full 1.1, or
+ some profile of SVG 1.2 greater than Tiny). The results of this subtest
+ does not affect the pass/fail criteria.
+
+
+ Because SVG Tiny does not support for SVG Full DOM, an SVG Tiny implementation which
+ does not support other SVG Profiles should show a rectangle
+ like this.
+ If the application supports the DOM, meaning that it does more than just SVG Tiny, it
+ should show a rectangle like this.
+ Either result is a pass.
+
+
+ The lower subtest,has another switch. The first child has a requiredFeature
+ set to http://www.w3.org/TR/SVG11/feature#BasicText which all SVG Tiny implementations
+ must support. If the application does, the lower rectangle is displayed in green
+ like this. Otherwise, a red rectangle
+ indicates that the text has failed.
+
+
+
+ $RCSfile: struct-cond-03-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ This viewer does more than SVG Tiny 1.2
+
+
+
+
+ This viewer
+ does not implement SVG Full DOM
+
+
+
+
+
+
+ SVG Basic Text feature supported
+
+
+
+ Fail: Basic Text feature not supported
+
+
+
+
+ FAIL
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-204-t.svg
new file mode 100755
index 00000000..80a82878
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-204-t.svg
@@ -0,0 +1,150 @@
+
+
+
+
+
+
+
+
+
+
+
+
Required Formats Attribute
+
+ A series of switches are used to determine which Internet Media types ('MIME types')
+ are supported, using the 'requiredFormats' attribute,
+ displaying a 'yes' or 'no' as appropriate. The test is passed if there is text in
+ the second row of each column, and that text is only
+ green (in the top table)
+ or blueviolet (in the bottom table);
+ no red text is displayed.
+
+
+ The SVG Tiny 1.2 specification mandates certain formats, so these must be supported:
+ image/jpeg, image/png, image/svg+xml.
+ It is an error not to support them, therefore 'yes' is green and 'no' is red.
+
+
+ This test also checks for support of Internet Media types which are
+ assumed to not exist and are unlikely to ever be registered: garbage/garbage.
+ Therefore, 'yes' is red and 'no' is green.
+
+
+ Lastly, most media types are optional. For example, image/tiff may be
+ supported but support is not mandated by the SVG Tiny 1.2 specification.
+ The second table examines these optional formats.
+ Both 'yes' and 'no' are displayed in blueviolet. Whether the particular Internet Media type
+ is supported or not does not affect whether the test is passed or failed, but does provide useful
+ information about the optional capabilities of a particular implementation.
+
+ Tests all the SVG Tiny 1.2 feature strings using requiredFeatures.
+
+
+
+ $RCSfile: struct-cond-205-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Required Features Attribute
+
+ A series of switches are used to determine which 'requiredFeatures' are supported.
+
+
+
+ Feature
+ Supported?
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-static
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-static-DOM
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-animated
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#SVG-all
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#CoreAttribute
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#NavigationAttribute
+
+ Yes
+ No
+
+ garbage
+
+ Yes
+ No (expected)
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#NavigationAttribute
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#Structure
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#structure
+
+ Yes
+ No (expected)
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#ConditionalProcessing
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#ConditionalProcessingAttribute
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#Image
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#Prefetch
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#Discard
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#Shape
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#Text
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#PaintAttribute
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#OpacityAttribute
+
+ Yes
+ No
+
+ http://www.w3.org/Graphics/SVG/feature/1.2/#GraphicsAttribute
+
+ Yes
+ No
+
+
+
+
+
+ $Revision: 1.4 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-209-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-209-t.svg
new file mode 100755
index 00000000..c9cd0546
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-cond-209-t.svg
@@ -0,0 +1,74 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test evaluates the effects of the 'display' or 'visibility'
+ attributes on a switch statement. The result should be a green circle
+ in the center of the output window.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing a green circle in the center of the image. If a
+ gray rectangle is visible, the test cannot be evaluated because the
+ 'display' attribute is not supported. If a blue rectangle is visible,
+ the test cannot be evaluated because the 'visibility' attribute is not
+ supported. If a red rectangle with a gray stroke is visible, the test
+ is failed because the switch is affected by the 'display' attribute.
+ If a red rectangle with a black stroke is visible, the test is failed
+ because the switch is affected by the 'display' attribute.
+
+
+ The test uses the 'rect' and 'circle' elements, as well as basic fill
+ (solid primary colors), stroke (black or gray 2-pixel lines), and the
+ 'display' and 'visibility' attributes.
+
+ This test evaluates the effects of the switch statement on referencing
+ content such as gradients or elements. The result should be a yellow
+ rectangle in the center of the output window, with green circles in
+ three of the corners of the rectangle.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the labelling text (per CSS2 rules). The pass
+ condition is seeing three circles, one solid green circle in upper
+ right corner of the rectangle, and a circle with a green gradient in
+ each of the bottom corners of the rectangle. If a red or black circle
+ is visible in the upper left corner of the rectangle, the test cannot
+ be evaluated because the 'switch' is not correctly supported. If any of
+ the upper-right or lower circles is not visible, or does not have the
+ correct fill, the test is failed. If the bottom-right circle is not
+ visible or does not have the gradient fill, then the 'switch' is not
+ correctly supported, and does not allow one conditionally hidden
+ resource to reference another.
+
+
+ The test uses the 'rect', 'circle', 'gradient', and 'use' elements, as
+ well as basic fill (solid primary colors) and radial gradients.
+
Test to verify that the defs element is used as a container correctly.
+
In this test a fill is created which is solid red. The view should be a solid red 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 green fill and the other to obscure most of the red rectangle. The green rectangles should not show in the view as defs are referenced items and are not rendered. No green should show.
+
The rendered picture should match the reference image, except for possible variations in the labelling 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.
+ Tests that the value of the display property on the defs element or on its descendants
+ doesn't prevent the elements from being referenced.
+
+
+ The test has passed if the following conditions are met:
+
+
+
there are 8 big rects visible each of a different color.
+
on top of the 8 big rects there are 8 circles that contain the reference color, the color of each circle must match the color of the rect to the right of its center
+
from the top-left to the top-right corner the colors must be: green, lime, yellow, olive.
+
from the bottom-left to the bottom-right corner the colors must be: navy, teal, blue, fuchsia.
+ This test tests that discard acts the same as removeChild.
+ First two red rects and a blue circle should be seen. The blue circle has
+ its radius animated to 0 over the course of 3 seconds. At the point where
+ the blue circle disappears the two red rects should be removed from the
+ tree. This reveals two green circles.
+
+
+ The test has passed if in the interval 0-3 seconds there are two red rects and a blue circle, and after 3 seconds two green circles can be seen and the text at the bottom says "Test passed".
+
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.
+
Because preserveAspectRatio is set to 'none', the content should appear distorted: 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.
+
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's size is 480 by 360 with an x/y origin in (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. Changing the viewport size should have no effect on the placement or scale of the document's conten.
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.
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.
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 xml:id=allGs. The two red rectangles and the yellow are in the g labeled rects. The reds 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 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.
This test validates that properties are inherited (or not, depending on their defintion), from a group to its children.
+
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 basic image formats allowed in the tiny profile are supported. 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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
This test verifies the support for gamma correction of displayed PNG images. 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 the tiny profile 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.
+
The rendered picture should match the reference image, except for possible variations in the labelling text (per CSS2 rules).
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>.
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.
+ Tests progressive rendering. Progressive rendering is an optional feature.
+
+
+ On user agents which support progressive rendering, the test is passed
+ if the circles render progressively. The update frequency is
+ implementation dependant.
+
+
+ On user agents which do not support progressive rendering, the test is passed
+ if all the circles are all displayed in a single render.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the rectangle should be full of circles, rendered all at once because of forward use with externalResourcesRequired.
+ The update frequency is implementation dependant.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the rectangle should be full of circles, rendered progressively.
+ Images should appear as the circles pass the yellow dots.
+ The update frequency is implementation dependant.
+
+ Tests progressive rendering. On user agents which support progressive rendering,
+ the content should be rendered all at once due to forward use of externalResourcesRequired on top-level SVG.
+ The update frequency is implementation dependant.
+
+ This test tests that any <svg> elements that are encountered inside
+ an <svg> element are ignored, if the user agent supports SVG Tiny 1.2 only.
+
+
+ If the user agent can handle SVG 1.1 Basic or Full, then the test has passed
+ if only the string "This text should be visible if the viewer supports at least SVG 1.1 Basic."
+ is visible.
+
+
+ If the user agent supports only SVG 1.2 Tiny then the test has passed if
+ the svg element and it's contents have been ignored. Only the string
+ "This text should be visible if the viewer supports only SVG 1.2 Tiny." should
+ be visible.
+
+
+ If both strings are visible then the test has failed.
+
+
+
+ $RCSfile: struct-svg-203-t.svg,v $
+
+
+
+
+
+
+
+
+
+ This text should be visible if the viewer supports only SVG 1.2 Tiny.
+
+
+
+ This text should be visible if the viewer supports at least SVG 1.1 Basic.
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-svg-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-svg-204-t.svg
new file mode 100755
index 00000000..263d5c70
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-svg-204-t.svg
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test is passed if nothing is rendered as the SVG root element
+ contains negative values for the width and height.
+
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).
+
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.
+ This tests a set of 'use' and 'rect' elements inside 'g' elements, with
+ each referencing the one before. For the test to pass, 5 nested
+ rectangles with a green stroke must be rendered, and no red rectangles
+ must be rendered.
+
+ This test tests reference restrictions on the use element. Each of the 5 different
+ restrictions is tested.
+
+
+ A compliant SVG Tiny 1.2 user agent must treat each of the invalid IRI:s as if the xlink:href
+ attribute hadn't been specified, which is the same as disabling rendering of the use element
+ in question. Thus for the test to pass none of the content that the use elements try to reference
+ must be visible, the end result should be 5 empty (white) rects.
+
+
+ For a user agent that handles at least SVG 1.1 Basic the testcase has still passed if the referenced
+ content in the rect that is labelled "B" is visible since this is allowed for 1.1.
+
+
+
+ $RCSfile: struct-use-201-t.svg,v $
+
+
+
+
+
+
+
+
+ Test <use> reference restrictions
+
+
+
+
+
+
+ A
+
+
+
+
+
+
+ B
+
+
+
+
+
+
+ C
+
+
+
+
+
+
+ D
+
+
+
+
+
+
+ E
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-202-t.svg
new file mode 100755
index 00000000..8333f771
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-202-t.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test tests the reference restriction B on the use element.
+
+
+ A compliant SVG Tiny 1.2 user agent must treat each of the invalid IRI:s as if the xlink:href
+ attribute hadn't been specified, which is the same as disabling rendering of the use element
+ in question. Thus for the test to pass the content that the use element tries to reference
+ must be invisible, the end result should be an empty (white) rect.
+
+
+ For a user agent that handles at least SVG 1.1 Basic the testcase has still passed if the referenced
+ content in the rect that is labelled "B" is visible since this is allowed for 1.1.
+ If the script in the external resource is executed then the color of the rect will be green.
+ If not then the rect will be red.
+
+
+
+ $RCSfile: struct-use-202-t.svg,v $
+
+
+
+
+
+
+
+
+ Test <use> reference restriction B
+
+
+
+
+
+
+ B
+
+
+
+ $Revision: 1.4 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-203-t.svg
new file mode 100755
index 00000000..3efca16d
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-203-t.svg
@@ -0,0 +1,47 @@
+
+
+
+
+
+
+
+
+
+
+
+
The intent of the file is to determine if the UA supports references to external SVG fragments. 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 object, the UA should display a semi transparent duplicate copy at an offset position. See referenced image.
The intent of the file is to determine if the UA supports references to external SVG fragments. 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 object, the UA should display a semi-transparent duplicate copy at an offset position. See referenced image.
+ This test checks some aspects of the SVGElementInstance with regards to events.
+
+
+ Four blue rects should be visible at first. To run the test each rect must be clicked a minimum of two times. Once
+ to run the basic test, and once to verify that the event handler was removed properly. The test has passed if after
+ clicking all the rects two times or more there are four green rects with the word "Passed" on them. If anything red
+ is visible or the text on any of the rects say "Failed" then the test has failed.
+
+
+ The top-left rect checks that correspondingUseElement and correspondingElement are returning the correct values, and
+ also that the currentTarget isn't the same as target here.
+
+
+ The top-right rect checks that events bubble the correct way when SVGElementInstance is involved. It's almost the same
+ as the first subtest, but uses another 'use' element.
+
+
+ The bottom-left rect doesn't use 'use' elements at all, it's to illustrate event bubbling in normal trees as compared
+ to SVGElementInstance trees.
+
+
+ The bottom-right rect uses nested 'use' elements. The event handler 'nestedhandler' should be executed first, and will
+ check some aspects of nested use elements. It will modify what it references, and that is checked in the 'h4' event
+ handler.
+
+
+
+ $RCSfile: struct-use-205-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test SVGElementInstance and events
+
+
+
+
+ Click here
+
+
+
+
+ Failed
+
+
+
+ Passed
+
+
+
+
+
+
+
+
+ Click here
+
+
+ var status = "Failed";
+ // This subtest is included to show the how target and currentTarget works on normal elements.
+ if(event.target != event.currentTarget)
+ {
+ if(event.target == document.getElementById("r3"))
+ {
+ if(event.currentTarget == document.getElementById("g3"))
+ {
+ status = "Passed";
+ }
+ }
+ }
+ document.getElementById("r3").setAttributeNS(null, "fill", status == "Passed" ? "green" : "red");
+ document.getElementById("t3").textContent = status;
+
+ // Remove the handler, so that clicking again does nothing
+ document.getElementById("g3").removeChild(document.getElementById("h3"));
+
+
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-206-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-206-t.svg
new file mode 100755
index 00000000..8265b32e
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-206-t.svg
@@ -0,0 +1,48 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ If the user agent supports referencing external content you should see three green rects.
+
+ 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.
+
+
+ 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.
+
+ For this test to pass the green text "This text should be visible." must
+ be rendered. It is not an error if graphics are visible in addition to
+ the green text. It is not a requirement that graphics be rendered in
+ addition to the green text.
+
+ This test checks for recursion in 'use' elements. The passing conditions are that the browser does not crash, and that at least one orange circle, and one yellow circle, and a line of green text are rendered.
+ Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may not be rendered, depending upon when and how the implementation detects the circular reference,
+ with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation.
+
+
+
+ $RCSfile: struct-use-recursion-01-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This text should be visible.
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-recursion-02-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-recursion-02-t.svg
new file mode 100755
index 00000000..b5856c8e
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-recursion-02-t.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test checks for recursion in 'use' elements with external references. The passing conditions are that the browser does not crash, and that the green test is rendered. The passing conditions are that the
+ browser does not crash, and that at least one orange circle and a line of green text are rendered. Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may
+ not be rendered, depending upon when and how the implementation detects the circular reference, with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation..
+
+
+ This test depends upon 'struct-use-recursion-03-t.svg'.
+
+
+
+ $RCSfile: struct-use-recursion-02-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This text should be visible.
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-recursion-03-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-recursion-03-t.svg
new file mode 100755
index 00000000..ca2329f3
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/struct-use-recursion-03-t.svg
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test checks for recursion in 'use' elements with external references. The passing conditions are that the browser does not crash, and that at least one yellow circle and a line of green text are rendered.
+ Also, on an implementation-specific basis, additional orange and yellow circles with a dashed gray stroke may or may not be rendered, depending upon when and how the implementation detects the circular reference,
+ with the number of dashed circles of a given color indicating now many times the level of recurrsion permitted by the implementation.
+
+
+ This test depends upon 'struct-use-recursion-02-t.svg'. It differs from 'struct-use-recursion-02-t.svg' in that the 'use' element comes before the 'circle' element.
+
+
+
+ $RCSfile: struct-use-recursion-03-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This text should be visible.
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/styling-inherit-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/styling-inherit-01-t.svg
new file mode 100755
index 00000000..d05e8f13
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/styling-inherit-01-t.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+
+
Verify property inheritance as required by 6.7 "Property inheritance".
+
For this test to pass:
+
At the center right, there is an ellipse. The fill color is not specified on that element but on its parent. The ellipse must 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 from the center to the edge.
+
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 from the center to the edge
+ Tests inheritance, animation and effect of display:none on stop-color. Three
+ rectangles are displayed. After a five second animation has completed,
+ the test is passed if all three rectangles display a green to blue gradient.
+
+
+ The stop-color property is not inherited by default, but the value 'inherit' forces it to
+ inherit the current animated value from its parent.
+
+
+ In the first subtest, the value of the stop-color property on the second stop is
+ 'inherit'. Its parent, linearGradient with id "MyGradient" also has stop-color set to
+ "inherit". The parent of this gradient is the group with id "g2" and the property
+ stop-color is animated on that group. Thus, after the animation finishes,
+ the inherited value is blue.
+
+
+ In the second subtest, the value of the stop-color property on the second stop is
+ 'currentColor'. Its parent, linearGradient with id "MyGradient" does not have the
+ color property set, but the property is inherited, so it inherits from the
+ parent - the group with id "g2". The property color is animated on that group.
+ Thus, after the animation finishes, the inherited value is again blue.
+
+
+ The third subtest is not animated. It checks that, per specification, the properties
+ on a gradient are inherited from the point of definition, not the point of use. An
+ implementation which does this incorrectly will show a green to red fill.
+
+ Tests inheritance, animation, currentColor on solid-color. Four
+ rectangles are displayed. After a five second animation has completed,
+ the test is passed if all four rectangles display a solid green fill.
+
+
+ Note: The solid-color property is not inherited by default, but the value 'inherit' forces it to
+ inherit the current animated value from its parent.
+
+
+
+ In the first subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent, a group, also has solid-color set to
+ "inherit". The parent of this group is another group, the property
+ solid-color is green on it.
+
+
+ In the second subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent has solid-color set to
+ "inherit". The parent of this group is another group whose solid-color
+ property is yellow.
+ The solid-color property on the solidColor element is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value is green.
+
+
+ In the third subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'inherit'. Its parent has solid-color set to
+ "inherit". The parent of this group is another group whose solid-color
+ property is yellow.
+ The solid-color property on the outermost group is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value is green.
+
+
+ In the fourth subtest, the rectangle has a solid fill.
+ On the solidColor element, the value of the solid-color property is
+ 'currentColor'. Its parent has color set to
+ "inherit". The parent of this group is another group whose color
+ property is yellow.
+ The color property on theoutermost group is
+ animated from yellow to green. Thus, after the animation finishes,
+ the inherited value of color, and thus the value used by currentColor, is green.
+
Check that !important in presentation attribute is an unsupported attribute value. To pass, two rectangles should be drawn. A black filled rectangle and a lime green stroked rectangle.
+
+ 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.
Test horizontal baselines across script and font size changes.
+
+ The dominant baseline should be alphabetic, so the 'ab' will be sitting
+ on the blue line, the japanese glyphs 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 'ab' on the blue line, the ideographic chars
+ slightly below the line and the devangari should be hanging from the
+ hanging baseline.
+
+ 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.
+
+
+ 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 (red) 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 for viewer capability to handle the basics of the 'textAnchor'
+ alignment property for 'text' when it has child elements.
+
+
+ The first line from the top tests that a 'tspan' element is rendered
+ after the text content of the parent 'text' element.
+
+
+ The second line from the top tests that all the text content, including
+ that of child 'tspan' elements, is taken into account when positioning
+ the text with respect to its alignment point.
+
+
+ The rendered picture should match the reference image, except for
+ possible variations in the text fonts and layout (per CSS2 rules).
+
+
+
+ $RCSfile: text-align-201-t.svg,v $
+
+ Test of 'text-anchor'
+ text-anchor, text and tspan
+
+
+
+
+ start text
+ red tspan
+
+
+ first text first tspanlast tspan last text
+
+
+
+
+ $Revision: 1.4 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-align-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-align-202-t.svg
new file mode 100755
index 00000000..7510cdf3
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-align-202-t.svg
@@ -0,0 +1,895 @@
+
+
+
+
+
+
+
+
+
+
+
+
This test checks for text alignment on right-to-left text.
+
The first subtest has the word for 'Egypt', مص
+
The second subtest has the hebrew text פעילות
+
Text-anchor values of start are black, middle are maroon and end are dark blue.
Testing 'textArea' with fixed 'width' and 'height'
+
+ Lines should break at character boundaries if there is not enough room to perform word breaks.
+ The 'height' of the first 'textArea' below (top-right) is less than that of the characters
+ so nothing should appear.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+ TextArea with Fixed Width and Height
+
+ Lines should break at character boundaries if there is not enough room to perform word breaks.
+
+
+ The 'height' of the first 'textArea' below (top-right) is less than that of the characters
+
+
+ so nothing should appear.
+
+
+
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-202-t.svg
new file mode 100755
index 00000000..56581ac3
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-202-t.svg
@@ -0,0 +1,152 @@
+
+
+
+
+
+
+
+
+
+
+
+
Testing 'textArea' with fixed 'width' and 'height'
+
+ Three 'textArea' elements contain words which are increasing in 'font-size'.
+
+ To pass, no characters should appear in the top-right box since the 'height' of the 'textArea' is less
+ than that of the characters.
+
+ There should be no characters outside of the border of the larger bottom-left box.
+
+ In the left-side box, there may be characters outside of the border, depending on whether
+ the implementation breaks words or not.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+ TextArea with Fixed Width and Height
+
+
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-203-t.svg
new file mode 100755
index 00000000..e998f8f9
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-203-t.svg
@@ -0,0 +1,74 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea with Animated Width and Height
+
+ A visible rectangle is drawn the same size as the textArea. The text
+ contained in the textArea should automatically wrap.
+
+
+ The textArea starts off as a 24x 24 square and is animated down to full
+ size. The text should continually rewrap as the textArea increases in
+ size.
+
+
+ The text is taken from "The Lost Princess of Oz" by Baum, L. Frank
+ (Lyman Frank), 1856-1919
+
+
+
+ $RCSfile: text-area-203-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea with Animated Width and Height
+
+ The text should continually rewrap as the 'textArea' decreases and increases in size.
+
+
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-204-t.svg
new file mode 100755
index 00000000..0b667a58
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-204-t.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea with Animated Font-size
+
The font-size is animated from 32 to 8.5 - text should continually rewrap as the font-size decreases in size.
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-204-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea with Animated Font-size
+ The text should continually rewrap as the 'font-size' decreases and increases in size.
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-205-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-205-t.svg
new file mode 100755
index 00000000..777fdbc9
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-205-t.svg
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea with Height Set to Auto
+
Text should wrap at the right-hand margin and continue to the end of the paragraph.
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-205-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea with Height Set to Auto
+ Text should wrap at the right-hand margin and continue to the end of the paragraph.
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-206-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-206-t.svg
new file mode 100755
index 00000000..079f337a
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-206-t.svg
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea with Line-increment and Tbreak
+
The blue lines should appear below each of the five text lines in the 'textArea'.
+
+
+ $RCSfile: text-area-206-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea with Line-increment and Tbreak
+
+ The blue lines should appear below each of the five text lines in the 'textArea'.
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-207-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-207-t.svg
new file mode 100755
index 00000000..51e109a5
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-207-t.svg
@@ -0,0 +1,88 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea Transformed by Rotation
+
The three 'textArea's should be rotated by 35, 90 and 180 degrees.
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-207-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea Transformed by Rotation
+
+ The three textArea's should be rotated by 35, 90 and 180 degrees.
+
+
+ Excerpts from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-208-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-208-t.svg
new file mode 100755
index 00000000..06f8491f
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-208-t.svg
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea with Both Width and Height Set to Auto
+
+ The eight lines of numbers should not wrap. Each line is terminated by a tbreak element.
+ They have numbers from 0 to 50. Each line increases the 'font-size' by 25%.
+ The 'line-increment' attribute is not used.
+
+
+ This test is passed if eight lines of numbers are rendered and not
+ wrapped to a new line. Numbers displayed will decrease with each line.
+ Every line must begin with number 0.
+
+
+
+ $RCSfile: text-area-208-t.svg,v $
+
+ TextArea with Both Width and Height Set to Auto
+
+ The following eight lines of numbers should not wrap. They have numbers from 0 to 50.
+
+
+ Each line increases the 'font-size' by 25%. The 'line-increment' attribute is not used.
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-209-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-209-t.svg
new file mode 100755
index 00000000..bdd468e4
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-209-t.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea Testing Word Breaks and Tbreak
+
+ Each word should break onto a new line. The left-hand 'textArea' has no 'tbreak' elements
+ while the right-hand one uses 'tbreak' after each word. Both should appear the same.
+
+
+
+ $RCSfile: text-area-209-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea Testing Word Breaks and Tbreak
+
+ Each word should break onto a new line. The left-hand 'textArea' has no 'tbreak' elements
+
+
+ while the right-hand one uses 'tbreak' after each word. Both should appear the same.
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-210-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-210-t.svg
new file mode 100755
index 00000000..bc2c8c69
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-210-t.svg
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
Testing 'tbreak' while animating the 'font-size' attribute in 'tspan' in 'textArea'
+
+ This test defines one 'textArea' element with a 'tspan' child. The 'tspan' has as red fill and also an animation
+ which animates the font-size from 0 to 20. The tspan element has a tbreak element before and after it.
+
+
+ To pass, the red text should both start and end on a new line, even when the font-size of the tspan is animated.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-211-t.svg,v $
+
+
+
+
+
+
+
+
+
+ TextArea with Line-increment and Tbreak
+
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-213-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-213-t.svg
new file mode 100755
index 00000000..10c2b968
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-213-t.svg
@@ -0,0 +1,94 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea with Animated Width and Height
+
+ A visible rectangle is drawn the same size as the textArea. The text contained in the textArea should
+ automatically wrap.
+
+
+ The textArea starts off as a 24x 24 square and is animated down to full size. The text should continually
+ rewrap as the textArea increases in size.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-213-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea with display-align
+
+ The text should be clipped properly for each display-align value, as height animates
+
+
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+ default
+
+
+
+ auto
+
+
+
+ before
+
+
+
+ center
+
+
+
+ after
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-220-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-220-t.svg
new file mode 100755
index 00000000..2e781c2a
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-220-t.svg
@@ -0,0 +1,59 @@
+
+
+
+
+
+
+
+
+
+
+
+
Testing "textArea"
+
A visible rectangle is drawn the same size as the textArea. The text contained in the textArea should automatically wrap.
+
The textArea starts off as a 24x 24 square and is animated down to full size. The text should continually rewrap as the textArea increases in size.
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-220-t.svg,v $
+
+
+
+
+
+
+
+
+ 'textArea' with 'text-align' set to 'end'
+ All text should be right-justified. Each paragraph is terminated with a double 'tbreak'.
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-221-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-221-t.svg
new file mode 100755
index 00000000..146b26d5
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-221-t.svg
@@ -0,0 +1,72 @@
+
+
+
+
+
+
+
+
+
+
+
+
TextArea with line-increment, text-align and display-align
+
+ All text should be centered vertically and horizontally.
+ The 'font-size' is varied along with 'line-increment'.
+
+
The text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-221-t.svg,v $
+
+
+
+
+
+
+
+
+ TextArea with line-increment, text-align and display-align
+
+ All text should be centered horizontally and vertically.
+
+
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-222-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-222-t.svg
new file mode 100755
index 00000000..3f36221f
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-area-222-t.svg
@@ -0,0 +1,63 @@
+
+
+
+
+
+
+
+
+
+
+
+
Testing 'textArea' with editable attribute
+
Activating a textArea element should bring up UI asking for new text
+
The initial text is taken from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+ $RCSfile: text-area-222-t.svg,v $
+
+
+
+
+
+
+
+
+
+ TextArea with editable attribute
+
+ Activating a textArea element should allow edit of textArea contents.
+
+
+
+ Excerpt from "The Lost Princess of Oz" by Baum, L. Frank (Lyman Frank), 1856-1919
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-edit-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-edit-201-t.svg
new file mode 100755
index 00000000..55455682
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-edit-201-t.svg
@@ -0,0 +1,130 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test checks basic text-editing capabilities.
+
+
+ Start editing by activating the textArea that has a green dashed outline.
+ This textArea has no child text content, but has a defined width and height.
+ Input the string "123 456" (one two three, space, space, four five six).
+
+ After input is complete, click the button labeled "Check #1". If the frame around
+ the textArea goes from being dashed to being solid then that part of the test has passed.
+ Another condition is that the text string "123 456" should look like it only has one space
+ and not two due to the whitespace handling rules.
+
+
+ Next activate the middle textArea that has a red dashed outline.
+ Input two spaces between 3 and 4. Now since this textArea has xml:space="preserve" those
+ two spaces should be rendered as two spaces, meaning it must look different from the first
+ textArea on the left. The textContent must be the same in both cases though, and this is
+ verified by clicking the button labeled "Check #2". If the test is successful the frame
+ will turn from dashed red to solid red.
+
+
+ Finally activate the rightmost textArea that has a blue dashed outline.
+ Then exit the editing mode without changing the text. The text must not change and the 'tbreak' element
+ must be kept in the position it's in. Now activate the textArea again and input an additional linebreak between 3 and 4.
+ The line "345" must now be on the third line, the second line being blank.
+ Click the button labeled "Check #3" to verify the result, the frame will turn from dashed
+ blue to solid blue if successful.
+
+
+ The test has passed if after inputting text according to the instructions above and clicking the three
+ buttons the rendered image matches the reference image exactly.
+
+
+
+ $RCSfile: text-edit-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+ Test editable text in textArea
+
+
+ Input the string "123 456" (two spaces).
+
+
+
+
+
+
+ if(document.getElementById("ta1").textContent == "123 456")
+ document.getElementById("r1").setAttributeNS(null, "stroke-dasharray", "none");
+
+
+ Check #1
+
+
+ Insert two spaces between 3 and 4.
+
+
+
+
+
+
+ if(document.getElementById("ta2").textContent == "123 456")
+ document.getElementById("r2").setAttributeNS(null, "stroke-dasharray", "none");
+
+
+ Check #2
+
+
+ Insert an additional linefeed between 3 and 4.
+
+
+
+
+
+
+
+
+
+ Check #3
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-01-t.svg
new file mode 100755
index 00000000..debda5cb
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-01-t.svg
@@ -0,0 +1,52 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
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.
+
+
+ $RCSfile: text-fonts-01-t.svg,v $
+
+
+
+
+
+
+
+
+
+ A serifed face 画像
+ A sans-serif face 画像
+ A mono (iW) face 画像
+
+ A serifed face 画像
+ A sans-serif face 画像
+ A mono (iW) face 画像
+
+ This must be displayed
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-02-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-02-t.svg
new file mode 100755
index 00000000..8816e869
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-02-t.svg
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+ $RCSfile: text-fonts-02-t.svg,v $
+
+
+
+
+
+
+
+
+
+ 100
+ 200
+ 300
+ 400
+ 500
+ 600
+ 700
+ 800
+ 900
+ This is bold
+ This is normal
+
+ Blue is bolder
+
+
+ Blue is lighter
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-03-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-03-t.svg
new file mode 100755
index 00000000..7c56a30e
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-fonts-03-t.svg
@@ -0,0 +1,62 @@
+
+
+
+
+
+
+
+
+
+
+
+
Testing font-family attribute. Two SVG fonts are defined. Various text elements are then used with varying values for the font-family attribute. 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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
+ Testing font-family attribute.
+ Various text elements are
+ used with varying values for the font-family attribute.
+ The first two text elements should display in their respective fonts,
+ Haettenschweiler and
+ ,
+ 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.
+
+
+ If the two named fonts are available on the system,
+ the rendered picture should match the reference image exactly,
+ except for possible
+ variations in the labelling text (per CSS2 rules)
+ and variations in text antialiasing or hinting.
+
+ 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
+ the platform supports installable opentype fonts, please download
+ Zalamander Caps
+ by Tim Ahrens of Just Another Foundry.
+
+
+ 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.
+
+
+
+ $RCSfile: text-fonts-202-t.svg,v $
+
+
+
+
+
+
+
+
+
+ 100
+ 200
+ 300
+ 400
+ 500
+ 600
+ 700
+ 800
+ 900
+ This is bold
+ This is normal
+
+ Blue is bolder
+
+
+ Blue is lighter
+
+
+ ZalamanderCaps is an OpenType font
+ by Tim Ahrens of Just Another Foundry
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-01-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-01-t.svg
new file mode 100755
index 00000000..175ba5e4
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-01-t.svg
@@ -0,0 +1,61 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
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.
+
+
+ $RCSfile: text-intro-01-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Test left-to-right text.
+
+ Polish: Mogę jeść szkło, i mi ...
+ Russian: Я могу есть стекло, ...
+ Greek: Μπορώ να φάω ...
+ Hebrew: אני יכול לאכול זכוכית ...
+ Yiddish: איך קען עסן גלאָז און ...
+
+
+ Chinese:我能吞下玻璃而不伤身体。
+
+
+ Japanese: 私はガラスを食べます。
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-04-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-04-t.svg
new file mode 100755
index 00000000..ba6c44ad
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-04-t.svg
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
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.
+
A future version of this test might include all necessary glyphs as an SVG font.
+
+
+ $RCSfile: text-intro-04-t.svg,v $
+
+
+
+
+
+
+
+
+ Test horizontal text.
+
+ Polish: Mogę jeść szkło, i mi nie szkodzi.
+ Russian: Я могу есть стекло, это мне не вредит.
+ Greek: Μπορώ να φάω σπασμένα γυαλιά χωρίς να πάθω τίποτα.
+
+ Text "אני יכול לאכול זכוכית וזה לא מזיק לי" is in Hebrew
+ Yiddish: איך קען עסן גלאָז און עס טוט מיר נישט װײ.
+ Chinese:我能吞下玻璃而不伤身体。
+ Japanese: 私はガラスを食べられます。それは私を傷つけません。
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-05-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-05-t.svg
new file mode 100755
index 00000000..cc9d7b79
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-05-t.svg
@@ -0,0 +1,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+ $RCSfile: text-intro-05-t.svg,v $
+
+
+
+
+
+
+
+
+ لماذا لا يتكلمون اللّغة العربية فحسب؟
+
+ لماذا لا يتكلمون اللّغة العربية فحسب؟
+
+ لماذا لا يتكلمون اللّغة العربية فحسب؟
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-06-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-06-t.svg
new file mode 100755
index 00000000..a85cda8a
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-intro-06-t.svg
@@ -0,0 +1,56 @@
+
+
+
+
+
+
+
+
+
+
+
+
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.
+
+
+ The test is passed if subtests are displayed as following:
+
+
+
The first subtest has the word for 'tools', آلات
+
The second subtest has the word for 'three', ثلاثة
Test text element, tspan element and various text styles.
+
The first group tests that text displays at all, that it displays in a straight line, and that the font style can be made italic or bold.
+
The second group tests that text can be treated as any other graphical element, with stroke and fill properties. The first word tests that fill color can be specified. The second word tests that stroke color can be specified in absence of fill. The third group tests the combination of all these effects. The final group tests positioning of 'text' elements.
+
+
+ $RCSfile: text-intro-201-t.svg,v $
+
+
+
+
+
+
+
+
+ Plain
+ Italic
+ Bold
+ fill only
+ stroke only
+ Bold, italic, fill and stroke
+
+
+
+ Each line of text which flows in a
+ rectangular box has to be broken
+ into separated lines.
+
+
+
+
+ $Revision: 1.4 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-text-04-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-text-04-t.svg
new file mode 100755
index 00000000..17b9b170
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-text-04-t.svg
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+
+
+
+
+
+
The purpose of this test is to validate proper handling of the text element's x and y attributes. In the various samples, a red 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.
+
In all the above tests, blue markers represent the expected glyph positions. The red 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 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 red), 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.
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.
+
The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).
+
+
+ $RCSfile: text-text-07-t.svg,v $
+
+
+
+
+
+
+
+
+ Multi X Y
+ ROTATE
+ Both Together
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-text-08-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-text-08-t.svg
new file mode 100755
index 00000000..0a8418f3
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-text-08-t.svg
@@ -0,0 +1,42 @@
+
+
+
+
+
+
+
+
+
+
+
+
Two opacity properties (fill-opacity and stroke-opacity) of 'text' elements are covered in this test.
+ 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.
+
+
+
+ The rendered picture should match the reference image exactly, except for possible
+ variations in the labelling text (per CSS2 rules).
+
+
+
+ $RCSfile: text-text-09-t.svg,v $
+
+
+
+
+
+
+
+
+ Multi X Y
+ ROTATE
+ Both Together
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-tselect-03-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-tselect-03-t.svg
new file mode 100755
index 00000000..34fc8adc
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/text-tselect-03-t.svg
@@ -0,0 +1,87 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This test demonstrates text selection of bidirectional text.
+
+
To pass the test the the first 9 characters in logical order starting from logical position 0 are to be selected. This must be done by the tester since there's no way to control the selection in DOM. The selection should be started at the letter 'a' and proceed to the number '1' as indicated by the arrows. Visually this makes the selection 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.
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;
+
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.
+
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.
+ This tests that the getTrait[NS] and setTrait[NS]
+ methods of the TraitAccess interface work for the special
+ '#text' trait on the desc, title,
+ metadata, text, tspan and textArea
+ elements.
+
+
+ The rectangle in the top left corner indicates whether the
+ getTrait and getTraitNS returned the expected
+ strings for each of the relevant elements; blue for pass,
+ red for fail. The four text strings below it indicate whether
+ setTrait and setTraitNS worked on the text
+ and textArea elements; they must all be the string “PASS”.
+
+
+
+ $RCSfile: udom-conform-201-t.svg,v $
+
+
+
+
+
+
+
+
+ #text trait access test
+
+
+ This is the desc.
+ This is the title.
+ This is the metadata.
+
+ This is the text and this is the tspan.
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-201-t.svg
new file mode 100755
index 00000000..a2f29ae3
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-201-t.svg
@@ -0,0 +1,93 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests that the DOMException interface is present
+ and that all of its constant fields exist and are correct.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the constant fields are correct; green for pass, red for fail.
+
+ This tests that the Node interface attributes
+ namespaceURI, localName, parentNode
+ and ownerDocument are correct, for some simple cases.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the attributes being tested have the expected values; green for
+ pass, red for fail.
+
+ This tests that the textContent attribute of the
+ Node interface works correctly. The test is passed
+ if a blue square and two "PASS" are displayed.
+
+
+ The rectangle in the top left corner indicates whether the
+ behavior when manipulating the textContent attribute
+ on various elements.
+ The two text strings below it indicate whether setting
+ textContent on the text and textArea
+ elements succeeded.
+
+
+
+ $RCSfile: udom-dom-203-t.svg,v $
+
+
+
+
+
+
+
+
+ Node.textContent test
+
+ This is the desc.
+ This is the title.
+ This is the metadata.
+
+
+ This is the text and this is the tspan.
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-204-t.svg
new file mode 100755
index 00000000..2f3c909d
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-204-t.svg
@@ -0,0 +1,159 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests that the appendChild method of the
+ Node interface works correctly.
+
+
+ The test has been passed if six blue rectangles are displayed.
+ Each rectangle indicates the result of a different aspect of
+ appendChild behavior being tested:
+
+
+
+ The first is a test of appending a newly created rect that
+ is not yet in the document tree.
+
+
+ The second is a test of appending a rect that is already
+ somewhere else in the document tree. In its initial position, it
+ inherits fill='red', and in its new position, it inherits
+ fill='blue'.
+
+
+ The third is a test of appending a rect to its current
+ parent. This results in the rect being moved to the
+ final position in the list of child nodes. In its initial
+ position, a red rect occludes this blue one. In its final
+ position, this blue rect occludes the red one.
+
+
+ The fourth is a test of appending a second element to the document
+ node. This results in a DOMException being thrown with code
+ HIERARCHY_REQUEST_ERR. If this exception is thrown, the
+ rect is changed from red to blue.
+
+
+ The fifth is a test of appending an element to one of its
+ descendant elements. This also results in a DOMException being
+ thrown with code HIERARCHY_REQUEST_ERR. If this exception is
+ thrown, the rect is changed from red to blue.
+
+
+ The sixth is a test of appending an element from another document
+ into this document. The element from the other document is obtained
+ by calling parseXML. A DOMException must be thrown with
+ code WRONG_DOCUMENT_ERR. If this exception is thrown, the
+ rect is changed from red to blue.
+
+ This tests that the removeChild method of the
+ Node interface works correctly.
+
+
+ The test has three sub-tests, for different removeChild
+ behavior, which consist of a paired rectangle and circle:
+
+
+
+ The first is a test of successfully removing a single element
+ from the document. Initially, a red rectangle occludes a blue
+ rectangle. This red rectangle should then be removed by the
+ removeChild call, which results in the blue rectangle
+ becoming visible. The circle beneath it represents whether
+ removeChild returned the correct value (i.e., a reference
+ to the same red rectangle that was removed). If this return
+ value is incorrect, the circle will remain red. If it was
+ correct, the circle is changed to be blue.
+
+
+ The second is a test of successfully removing a subtree
+ from the document. The subtree is simply a g element
+ with a red rect as a child, which initially occludes
+ a blue rectangle. The group with the red rectangle should then be
+ removed by the removeChild call, which results in the blue
+ rectangle becoming visible. The circle beneath it represents
+ whether removeChild returned the correct value (i.e., a
+ reference to the g element that was removed). If this
+ return value is incorrect, the circle will remain red. If it was
+ correct, the circle is changed to be blue.
+
+
+ The third is a test of removeChild throwing a NOT_FOUND_ERR
+ DOMException when passed an element that is not a child of
+ the element on which the method was called. If the blue rectangle
+ remains, the implementation correctly did not remove it. The circle
+ indicates whether the exception was thrown as expected. If the
+ exception was not thrown, or the wrong is exception is thrown,
+ the circle will remain red. Otherwise, the circle will be changed
+ to be blue.
+
+
+
+ The test has been passed if the top row shows three blue rectangles
+ and the bottom row shows three blue circles.
+
+
+
+ $RCSfile: udom-dom-206-t.svg,v $
+
+
+
+
+
+
+
+
+ Node.removeChild test
+ All three rects and three circles must be blue.
+
+
+
+ remove single element
+ remove subtree
+ remove incorrect element
+
+
+ removeChild operation
+ removeChild return value
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-207-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-207-t.svg
new file mode 100755
index 00000000..8330228a
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-dom-207-t.svg
@@ -0,0 +1,116 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests that the cloneNode method of the
+ Node interface works correctly.
+
+
+ The test has two sub-tests: one for a deep clone, and
+ one for a shallow clone.
+
+
+
+ The first row shows the deep clone sub-test. A group
+ containing three cascaded rectangles and a text
+ element are cloned and inserted into the document 180
+ user units to the right. The group inherits fill and
+ stroke colors from a parent element, and where the cloned
+ copy of the group is inserted, different colors are
+ inherited. The original group inherits a blue fill and
+ a light blue stroke, while the cloned group inherits an
+ orange fill and a light orange stroke. The text in both copies
+ of the group have a white fill and no stroke.
+
+
+ The second row shows the shallow clone sub-test. A circle
+ element with two child set elements (that set the fill to
+ blue and the stroke to light blue) is shallow cloned and inserted
+ into the document 100 user units to the right. Since it is a
+ shallow clone, the cloned circle does not have the
+ set element children, and inherits an orange fill
+ and a light orange stroke.
+
+ This tests that the createElementNS method on the
+ Document interface works correctly, for each SVG Tiny 1.2
+ element, and for some unknown elements.
+
+
+ There are four sub-tests (a rectangle for each). The test has been
+ passed if all four rectangles are blue.
+
+
+ Thes are:
+
+
+
Sub-test 1: test creating each SVG Tiny 1.2 element.
+
Sub-test 2: test creating an unknown element in no namespace.
+
Sub-test 3: test creating an unknown element in the SVG namespace.
+
Sub-test 4: test creating an unknown element in another namespace.
+ This tests that the firstElementChild,
+ lastElementChild, nextElementSibling and
+ previousElementSibling methods of the ElementTraversal
+ interface works correctly.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the attributes being tested have the expected values; green for
+ pass, red for fail.
+
+ This tests that the methods of the EventTarget interface work
+ correctly.
+
+
+ There are three sub-tests (a rectangle for each). These are:
+
+
+
Sub-test 1: test adding a listener with addEventListener.
+
+ Sub-test 2: test adding a listener with addEventListener then
+ removing it with removeEventListener.
+
+
+ Sub-test 3: test adding a listener for an event type with incorrect
+ casing.
+
+
+
+ The test has been passed if all three rectangles are blue.
+
+
+
+ $RCSfile: udom-event-201-t.svg,v $
+
+
+
+
+
+
+
+
+ EventTarget interface test
+ All three rectangles must be blue.
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-202-t.svg
new file mode 100755
index 00000000..f34f0ce5
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-202-t.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests that the target, currentTarget,
+ type and cancelable
+ attributes of the Event interface work correctly.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and all of its ancestor nodes. Clicking on the
+ rectangle will test that the attribute of the Event object
+ all have expected values, for each invocation of an event listener.
+ It also tests whether each of the event listeners is indeed invoked.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+
+
+ $RCSfile: udom-event-202-t.svg,v $
+
+
+
+
+
+
+
+
+ Event interface attributes test
+ Click the black rectangle above.
+ If it turns blue, the test has been passed.
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-203-t.svg
new file mode 100755
index 00000000..dff635f1
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-203-t.svg
@@ -0,0 +1,97 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests the stopPropagation method of the
+ Event interface.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and some of its ancestor nodes. Clicking on the
+ rectangle will dispatch the click event. The listener on
+ the parent node of the rect calls stopPropagation().
+ The test checks that the listener for the grandparent node is not
+ dispatched.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+
+
+ $RCSfile: udom-event-203-t.svg,v $
+
+
+
+
+
+
+
+
+ Event.stopPropagation test
+ Click the rectangle above.
+ If it turns blue, the test has been passed.
+
+
+
+
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-204-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-204-t.svg
new file mode 100755
index 00000000..a8753443
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-204-t.svg
@@ -0,0 +1,120 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests the defaultPrevented attribute and the
+ preventDefault method of the Event interface.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and some of its ancestor nodes. Clicking on the
+ rectangle will dispatch the click event. The listener on
+ the grandparent node of the rect calls
+ preventDefault(). The test checks that the event object has
+ defaultPrevented set to true.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+
+
+ $RCSfile: udom-event-204-t.svg,v $
+
+
+
+
+
+
+
+
+ Event interface preventDefault/defaultPrevented test
+ Click the rectangle above.
+ If it turns blue, the test has been passed.
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-205-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-205-t.svg
new file mode 100755
index 00000000..790869e1
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-205-t.svg
@@ -0,0 +1,164 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests the clientX, clientY and button
+ attributes of the MouseEvent interface.
+
+
+ The test consists of three rectangles, one for each of the three
+ common mouse buttons. To perform the test, the user must move the
+ mouse cursor over a rectangle, press the mouse button down, then
+ move the mouse cursor out of the rectangle. If after this the
+ rectangle becomes blue, then that sub-test has been passed, indicating
+ that the clientX, clientY and button
+ attributes of the MouseEvent object had expected values for
+ the mouseover, mousedown and mouseout
+ events.
+
+
+ The test as a whole has been passed if, for each rectangle that
+ corresponds to a button on the pointing device that the user
+ agent supports, it becomes blue after performing the interaction.
+ If the user agent does not support a pointing device at all,
+ then the test is passed automatically without needing to
+ perform any interaction.
+
+
+
+ $RCSfile: udom-event-205-t.svg,v $
+
+
+
+
+
+
+
+
+ MouseEvent interface test
+
+ For each rectangle below, move the mouse over the
+ rectangle, click, then move the mouse out of the rectangle.
+ The text underneath the rectangle indicates which mouse
+ button to use.
+ If each rectangle (for which there exists the corresponding
+ button that the user agent supports) turns blue, the test has been passed.
+
+
+
+
+
+ primary
+ (usually left)
+ extra
+ (usually middle)
+ secondary
+ (usually right)
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-207-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-207-t.svg
new file mode 100755
index 00000000..c8286241
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-207-t.svg
@@ -0,0 +1,93 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests the data attribute of the TextEvent
+ interface.
+
+
+ To perform the test, the user must input some text. This can be
+ from a variety of sources, such characters directly from a keyboard,
+ text pasted from the clipboard, input from an IME or input from a
+ speech recognizer.
+ Once the text has been input, the black rectangle should turn blue to
+ indicate that the test has been passed. In addition, the
+ text element below the rectangle will show the text that was
+ input.
+
+
+ If the rectangle becomes red, the test failed because the
+ data attribute had an invalid value. If the rectangle
+ remains black, the test failed because the textInput
+ event is not supported. If the text string does not appear,
+ or does not match the input text, the test failed because the
+ textInput event is not supported correctly (e.g. it
+ only tests for any keyboard activity).
+
+
+
+ $RCSfile: udom-event-207-t.svg,v $
+
+
+
+
+
+
+
+
+ TextEvent interface test
+ Input some text. The rectangle below should become blue
+ to indicate that the test has been passed.
+
+
+ Text input: []
+
+
+
+
+ $Revision: 1.9 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-208-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-208-t.svg
new file mode 100755
index 00000000..d0e38ff6
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-208-t.svg
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests the detail attribute of the UIEvent
+ interface and the dispatch order of mouse events when clicking.
+
+
+ To perform the test, the user must triple click on the circle.
+ The nine rectangles to the right of the circle indicate whether the
+ detail attribute of the UIEvent object was correct
+ for the mousedown, click and mouseup
+ events. The first row of rectangles checks the three events when
+ detail = 1, the second row for detail = 2 and
+ the third row for detail = 3.
+
+
+ In addition, the circle should remain black after the nine rectangles
+ have become blue. If the circle becomes red, it indicates that
+ the test failed because the mousedown, click and
+ mouseup events were fired in an incorrect order.
+
+
+ The test has been passed if, after triple clicking the circle, all nine
+ rectangles are blue and the circle remains black.
+
+
+
+ $RCSfile: udom-event-208-t.svg,v $
+
+
+
+
+
+
+
+
+ UIEvent interface and mouse event dispatch order test
+ Triple click the circle. The nine rectangles below should turn blue and the
+ circle should remain black to indicate that the test has been passed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-209-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-209-t.svg
new file mode 100755
index 00000000..52eb14bd
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-209-t.svg
@@ -0,0 +1,101 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests that the target, currentTarget,
+ type and cancelable
+ attributes of the Event interface work correctly. It
+ is the same as udom-event-202-t except that the event listener
+ is given by an ECMAScript object with a handleEvent
+ property, rather than by an ECMAScript Function object.
+
+
+ The test consists of a single rectangle, which has event listeners
+ registered on it and all of its ancestor nodes. Clicking on the
+ rectangle will test that the attribute of the Event object
+ all have expected values, for each invocation of an event listener.
+ It also tests whether each of the event listeners is indeed invoked.
+
+
+ The test has been passed if the rectangle becomes blue when clicking
+ it.
+
+
+
+ $RCSfile: udom-event-209-t.svg,v $
+
+
+
+
+
+
+
+
+ Event interface attributes test
+ Click the black rectangle above.
+ If it turns blue, the test has been passed.
+
+
+
+
+ $Revision: 1.8 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-210-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-210-t.svg
new file mode 100755
index 00000000..a9bd77a1
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-event-210-t.svg
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ The test at first should show a green rectangle.
+
+
+ Trigger some mousewheel events, for example by using a mouse with a scrollwheel
+ or a jog dial.
+ The test has passed if, when you scroll down, the rectangle rotates clockwise;
+ and when you scroll up, the rectangle rotates counter clockwise.
+ For reference the values of the Mousewheel event are displayed as text.
+
+
+
+ $RCSfile: udom-event-210-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+ 0)
+ angle++;
+ else
+ angle--;
+ if(angle<0)
+ angle=360;
+ if(angle>360)
+ angle=0;
+ ]]>
+
+
+ Mouseover the rect and use the scrollwheel
+
+
+
+
+
+
+
+ $Revision: 1.6 $
+
+
+
+
+
\ No newline at end of file
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-glob-201-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-glob-201-t.svg
new file mode 100755
index 00000000..009090e6
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-glob-201-t.svg
@@ -0,0 +1,87 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests that the GlobalException interface is present
+ and that all of its constant fields exist and are correct.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the constant fields are correct; green for pass, red for fail.
+
+ This tests that the gotoLocation method is present
+ and works for a simple case.
+
+
+ Once loaded, the SVG file will be replaced by the words success. Note that the
+ contents of this file may be displayed for a short interval until the new file is loaded.
+
+ This SVG will test the SVGGlobal's postURL() callback status. The test
+ is passed if, on each row, both squares have the same color.
+
+
+ There are multiple calls to postURL(), each with a different expected
+ HTTP return code.
+
+
+ The test works in conjunction with a JSP servlet called HttpCodeTest,
+ which will simulate the various HTTP return codes, based on the query
+ parameter from the client.
+
+
+ For each call to postURL(), two squares will appear. The first square
+ represents the "expected" status code. The second square represents the
+ "actual" status code that the callback function receives. The status
+ codes are color-coded.
+
+
+ Note that the status codes may take some time to update, due to the
+ asynchronous nature of the postURL() callback. Tester should allow some
+ time for all postURL() calls to receive ther return codes. The latency
+ will vary depending on the network environment, but normally, it should
+ only be a couple minutes at most.
+
+
+ 100-ranges status codes are not tested here because the spec states that
+ these status codes should be ignored. It is not clear what the expected
+ callback status should be in this case.
+
+ This SVG will test the SVGGlobal's getURL() callback status. The test is
+ passed if, on each row, both squares have the same color.
+
+
+ There are multiple calls to getURL(), each with a different expected
+ HTTP return code.
+
+
+ The test works in conjunction with a JSP servlet called HttpCodeTest,
+ which will simulate the various HTTP return codes, based on the query
+ parameter from the client.
+
+
+ For each call to getURL(), two squares will appear. The first square
+ represents the "expected" status code. The second square represents the
+ "actual" status code that the callback function receives. The status
+ codes are color-coded.
+
+
+ Note that the status codes may take some time to update, due to the
+ asynchronous nature of the getURL() callback. Tester should allow some
+ time for all getURL() calls to receive ther return codes. The latency
+ will vary depending on the network environment, but normally, it should
+ only be a couple minutes at most. Once all calls have returned, the text
+ "Callbacks now finished" will show, in green.
+
+
+ 100-ranges status codes are not tested here because the spec states that
+ these status codes should be ignored. It is not clear what the expected
+ callback status should be in this case.
+
+ Test with cloneNode on a use element. The red rect is cloned directly on the rect element.
+ The yellow rect is cloned on the use element. Two red and two yellow rects must be showing.
+
+
+
+ $RCSfile: udom-node-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Test with cloneNode on a use element.
+ Two red and two yellow rects must be visible!
+ Rect
+ Used rect
+ Clone
+ Clone
+
+
+ $Revision: 1.4 $
+
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-node-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-node-202-t.svg
new file mode 100755
index 00000000..0b951cd9
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-node-202-t.svg
@@ -0,0 +1,85 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Testing CloneNode with different values of the "deep" parameter.
+ In this test an image with animations inside is cloned twice, one which should keep the animations and the second that should only clone image node.
+ The first and second image should animate from opacity 0 and width 20 to opacity 1 and width 100. The third image should not animate.
+
+ 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 root 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 createElementNS method.
+
+
+ If an implementation supports the ECMAScript DOM binding for SVG, then the image must show the following text:
+ "This document's root identifier is: svg-root" and a red rectangle with a black shadow rectangle. Otherwise, only a red rectangle will show.
+
+
The rendered picture should match the reference image.
+ This tests the beginElement and beginElementAt
+ methods of the ElementTimeControl interface.
+
+
+ The test consists of four animated rectangles, one pink, three blue.
+ To perform the test, the user must click the pink rectangle.
+ The pink rectangle is set to animate with begin='mousedown',
+ while the three blue rectangles have begin='indefinite',
+ and are begun with calls to methods on the ElementTimeControl
+ interface:
+
+
+
+ The first blue rectangle is begun with .beginElement().
+
+
+ The second blue rectangle is begun with .beginElementAt(0).
+
+
+ The third blue rectangle is begun with .beginElementAt(2.5).
+
+
+
+ The test has been passed if the three blue rectangles reach their
+ destination at the same time as the pink rectangle.
+
+ This tests the beginElement and beginElementAt
+ methods of the ElementTimeControl interface, with different
+ begin instance time lists.
+
+
+ The test has been passed if all the three rectangles and the circle
+ become blue one second after clicking the circle.
+
+
+ The test consists of a pink circle and three animated rectangles.
+ To perform the test, the user must click the pink circle.
+ The three rectangles all have animations that begin='0s'
+ and run indefinitely, and are also set to restart='none'.
+ Clicking the circle will attempt to begin the three animations as follows:
+
+
+
+ The first rectangle's animation has .beginElement() called.
+
+
+ The second rectangle's animation has .beginElementAt(0) called.
+
+
+ The third rectangle's animation has .beginElementAt(0.5) called.
+
+
+
+ All three animations should not begin with these method calls, since
+ the animations have already started and are set to restart='none'.
+ If an animation does restart, its endEvent will be captured
+ and the rectangle will become red. If the animation does not restart,
+ it will become blue one second after clicking the pink circle.
+
+
+ In addition, the circle should become blue one second after clicking
+ it. This indicates that the implementation correctly dispatches an
+ endEvent when an element restarts.
+
+
+
+ $RCSfile: udom-smil-202-t.svg,v $
+
+
+
+
+
+
+
+
+ ElementTimeControl.beginElement(At) test 2
+ Click the pink circle. The test has passed if the rectangles
+ and the circle become blue one second after clicking the circle.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-smil-203-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-smil-203-t.svg
new file mode 100755
index 00000000..abf81b7f
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-smil-203-t.svg
@@ -0,0 +1,125 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests the endElement and endElementAt
+ methods of the ElementTimeControl interface.
+
+
+ The test consists of four animated rectangles, one pink, three blue.
+ To perform the test, the user must click the pink rectangle.
+ The pink rectangle is set to animate with begin='mousedown'.
+ The three blue rectangles have two animations each: the first is
+ an animation element that moves the rectangle along its
+ corresponding line, with begin='0s' dur='5s'. After the
+ animation element is a set element with
+ end='indefinite'. Each set animation is ended with
+ calls to methods on the ElementTimeControl interface:
+
+
+
+ The first blue rectangle is ended with .endElement().
+
+
+ The second blue rectangle is ended with .endElementAt(0).
+
+
+ The third blue rectangle is end with .endElementAt(2.5).
+
+
+
+ The test has been passed if the first two blue rectangles follow the
+ animation of the pink rectangle, and the third blue rectangle follows
+ the animation of the pink rectangle after 2.5 seconds (i.e., half way
+ through the pink rectangle's animation).
+
+ This tests that the correspondingElement and
+ correspondingUseElement attributes of the
+ SVGElementInstance interface have expected values.
+
+
+ The test consists of a single rectangle that is a descendant
+ of a number of g elements and a couple of nested
+ use shadow trees. When the user clicks the rectangle,
+ a mousedown event is dispatched, which travels up
+ the nested shadow trees. If the correspondingElement and
+ correspondingUseElement attributes of the
+ SVGElementInstance object (which is the currentTarget
+ of the event) are correct, the rectangle becomes blue. Otherwise,
+ it becomes red.
+
+
+
+ $RCSfile: udom-svg-204-t.svg,v $
+
+
+
+
+
+
+
+
+ SVGElementInstance interface test
+ Click the rectangle. The test has passed if it turns blue.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-205-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-205-t.svg
new file mode 100755
index 00000000..d3a828ea
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-205-t.svg
@@ -0,0 +1,86 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests that the NAV_* constants on the
+ SVGSVGElement exist.
+
+
+ The rectangle in the top left corner indicates whether all
+ of the constant fields are correct; green for pass, red for fail.
+
+ This tests setting and getting the currentScale attribute of
+ the SVGSVGElement interface.
+
+
+ There are three sub-tests, each represented by a rectangle (blue for
+ pass, red for fail). The test has been passed if all three rectangles are blue, and
+ the test slide is shown at 90% of its regular size (i.e., the
+ range (0, 0) -> (533.333, 400) user units is shown).
+
+
+
+ The first sub-test checks that the initial value of
+ currentScale is 1. The second checks setting
+ currentScale to a valid value (in this case, 0.9), and
+ looks at the resulting screenCTM. The third exercises retrieving
+ the newly set value.
+
+
+
+ $RCSfile: udom-svg-206-t.svg,v $
+
+
+
+
+
+
+
+
+ SVGSVGElement.currentScale test
+ All three rectangles must be blue.
+
+
+ Initial value
+
+
+ Set value
+
+
+ Get new value
+
+
+
+
+
+ $Revision: 1.7 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-208-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-208-t.svg
new file mode 100755
index 00000000..4b8bb4e8
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-208-t.svg
@@ -0,0 +1,257 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Test on SMIL with scripting. The animated bar should pause for 3s at 1.5s and resume at 4.5s.
+ The smaller rects should change color at the indicated times.
+
+ Test on SMIL with scripting. Animation should match the indicated begin- and end-values,
+ and should pause for three seconds when the pause-sign turn red.
+
+ Test on SMIL with scripting. Animation should match the indicated begin- and end-values,
+ and should pause for three seconds when the pause-sign turns red. restart is set to "never" so should NOT restart.
+
+ This tests that the getCurrentTime method of the
+ SVGSVGElement interface returns sensible values.
+
+
+ The test shows three rectangles. The test is passed if the first rectangle is blue, and after
+ clicking the second rectangle it turns blue, and after clicking
+ the third rectangle it also turns blue.
+
+
+ The first one represents
+ whether calling getCurrentTime before the load
+ event is dispatched returns 0. Clicking the second rectangle
+ (which is red to begin with) then tests that the current time is
+ greater than 0. Finally, clicking the third rectangle (which
+ also is red to begin with) tests that the current time is greater
+ than the time at which the second rectangle was clicked.
+
+
+ This tests the basic functionality of
+ SVGSVGElement.createSVGPath(). It
+ verifies that the returned path object has no path segments
+ initially, that a path segment can be added to the path object,
+ and that the object returned is actually
+ instanceof SVGPath.
+
+ This test some more complex invocations of SVGGlobal.getURL().
+
+
+ The test contains 3 subtests. The test is passed if all 3 rectangles
+ relating to a respective subtest turn green upon test completion.
+
+
+ The first subtest tests fetching a text/plain resource via a 3xx
+ redirection status code using SVGGlobal.getURL().
+
+
+ The second subtest tests a text/plain resource returned with status
+ code 403 using SVGGlobal.getURL().
+
+
+ The third subtest tests a text/plain resource returned with status
+ code 500 using SVGGlobal.getURL().
+
+
+
+ $RCSfile: udom-svg-218-t.svg,v $
+
+
+
+
+
+
+
+
+ More SVGSVGElement.getURL() tests
+
+
+
+
+ Fetch a text/plain resource via a 3xx
+ redirection status code
+
+ A text/plain resource returned with
+ status code 403.
+
+ A text/plain resource returned with
+ status code 500.
+
+
+
+ Test Running...
+
+
+
+
+ $Revision: 1.5 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-220-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-220-t.svg
new file mode 100755
index 00000000..c5c9884a
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-svg-220-t.svg
@@ -0,0 +1,231 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ This tests trait access methods on the TraitAccess interface
+ for the 'accumulate' trait. Each trait getter and setter method is called on
+ each applicable SVG Tiny 1.2 element.
+
+
+ The test is passed if the rendering matches the reference rendering.
+ The rectangle must be blue, and there must be a blue circle to the
+ right of it whose diameter is the same as the height of the rectangle.
+ There must be no text displayed below the rectangle.
+
+ This tests trait access methods on the TraitAccess interface
+ for the 'begin' trait. Each trait getter and setter method is called on
+ each applicable SVG Tiny 1.2 element.
+
+
+ The test is passed if, five seconds after the document begins:
+
+
+
the rectangle is blue,
+
+ there is a blue circle to the right of the rectangle whose
+ diameter is the same as the height of the rectangle,
+
+
an animation showing rotating rectangles to the right of the circle begins,
+
a video showing a dog to the right of the animation begins, and
+
an audio clip begins playing.
+
+
+ Also, there must be no text displayed inside the rounded green rectangle.
+
+ This test verifies that the CTM fetched by getScreenCTM is a snapshot value of the current animated state.
+
+ The CTM values are inspected on 'beginEvent', 'endEvent' and 'repeatEvent' times. The expected values are
+ calculated from the SMIL Animation equations and the current document time.
+
+ The test has passed if the testcase reports "Results match expected values." 8 times, and each such string
+ is prefixed with a green rectangle. When this happens the text in the rect with blue stroke changes from
+ 'failed' to 'passed'.
+
+ Four animations begin at time 0 and end at times 1, 2, 5 and 9 seconds. Event listeners are registered
+ for the "endEvent" event.
+ As each animation ends, getCurrentTime() is called and verified with the expected time. The expected time is compared with
+ the minimum time to take into account implementation-specific document time resolution.
+ If all times have the expected values, the text changes from 'testing' to 'passed'
+
+ Tests setCurrentTime. The test is passed if the the moving bar skips
+ from 2 to 4 , and from 5 to 8; and after the animation completes, the
+ text "passed" appears at the bottom right.
+
+
+ Four animations begin at time 0 and end at times 1, 2, 5 and 9 seconds.
+ Event listeners are registered for the "endEvent" event.
+ As each animation ends, getCurrentTime() is called to verify the expected current time, which
+ is them followed by a call to setCurrentTime.
+ If all times have the expected values, the text changes from 'testing' to 'passed'
+ The expected time is compared with
+ the minimum time to take into account implementation-specific document time resolution.
+
+ This tests setFocus and getCurrentFocusedObject, setting the focus and then checking that the correct element has focus. Successes are shown in green,
+ failures in red. If all subtests pass, the text in the blue box changes from "failed" to "passed".
+
+
+ A numeric keypad is shown. Focus starts on the "5" and is then moved programatically
+ to each of the other numbers, finally returning to "5". Since this happens on the load event, there is no indication of the focus moving.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test various trait combinations with expected values. If a result is not as expected, an error is displayed in red text, indicating the returned result and what was expected. When all subtests have returned success, the result is set to 'passed'. The pass condition for the test is that all subtests are green, and the word 'passed' is at the bottom right.
+
+ The TraitAccess tests uses a set of common ECMAScript code to test
+ various trait combinations with expected values. If a result is not as
+ expected, an error is displayed in red text, indicating the returned
+ result and what was expected. When all subtests have returned success,
+ the result is set to 'passed'. The pass condition for the test is that
+ all subtests are green, and the word 'passed' is at the bottom right.
+
+ This test creates an SVGColor object and verifies that the intial data is all zero. It then modifies the red, green, and blue attributes.
+ To pass, the resulting attributes should be as expected should be correct, and when this happens the text
+ changes from 'failed' to 'passed'
+
+
Note that, since the test does not insert this object into the document, it is not displayed. The test simply verifies that the object has been created correctly.
+ This test draws a few basic shapes and checks for correct values from getBBox().
+ 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'.
+
+ Note, this test does not have 100% for the svg width and height on purpose as to have exact
+ expected results for the screen bounding boxes
+
+
+ This test draws a few basic shapes and checks for correct values from getScreenBBox().
+ To pass, each returned bounding box must be correct (indicated by printing the values in green), and when this happens the text
+ changes from 'failed' to 'passed'
+
+ This test draws a few basic shapes and checks for correct values from getScreenCTM().
+ To pass, each returned CTM must be correct (indicated by printing the values in green),
+ and the string 'passed' appears in the lower right.
+
+
+ Note, this test does not have 100% for the svg width and height on purpose as to have exact
+ expected results for the screen CTM.
+
+ This test creates a SVGMatrix object and calls getComponent to verify the result
+ To pass, each returned component must be correct. To indicate a pass
+ the result of the test changes to green and the text at the bottom right
+ hand corner changes from "failed" to "passed".
+
+ This test creates two SVGMatrix objects and calls inverse on each.
+ The first matrix is invertable, but the second one is not, and should throw an exception when inverse() is called.
+ To pass, the inverted matrix must be correct, and the exception for the second matrix must be thrown.
+ To indicate a pass the result of the test changes to green and the text at the bottom right
+ hand corner changes from "failed" to "passed".
+
+ This test creates a few SVGMatrix objects and calls mMultiply.
+ To pass, the result matrices should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates some SVGMatrix objects and then calls mRotate.
+ To pass, the result matrices should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates an SVGMatrix object and calls mScale.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates an SVGMatrix object and calls mTranslate.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'.
+
+ This test creates path data using the SVGPath interface, with emphasis on support for close, moveTo and quadTo
+ To pass, the path data must match expected results for the text at the bottom of the test to read 'pass'.
+ The path data is verified by calling getSegment and getSegmentParam.
+ In addition, no red should be seen through the path element.
+
+ This test creates path data using the SVGPath interface, with emphasis on support for lineTo and curveTo
+ To pass, the path data must match expected results for the text at the bottom of the test to read 'pass'.
+ The path data is verified by calling getSegment and getSegmentParam.
+ In addition, no red should be seen through the path element.
+
+ This test creates SVGRect object and verifies that the initial data is all zero. It then modifies the x, y, width and height.
+ To pass, the result matrix should be correct, and when this happens the text
+ changes from 'failed' to 'passed'
+
+ Tests retrieving nested text using textContent.
+
+
+ For this test to pass the text "Not changed yet!" in red must be
+ replaced by the text "Rect Text and Rect Animate Text!" in green.
+
+
+ textContent is used in the following ways:
+
+
+
+
+ to retrieve the text nested within the rect element "sourceTextRect"
+
+
+ to set the text in the "originalText" text element to ""
+
+
+ to set the text in the "destinationText" text element to the text
+ retrieved from the rect element "sourceTextRect"
+
+
+
+
+
+ $RCSfile: udom-textcontent-201-t.svg,v $
+
+
+
+
+
+
+
+
+
+
+
+ Not changed yet!
+
+
+
+
+
+
+
+
+
+
+ Rect Text
+
+
+
+
+ and Rect Animate Text!
+
+
+
+
+
+
+
+
+
+ textContent(evt);
+
+
+
+ Test on textContent
+ The text "Not changed yet!" (in red) that is located just below the rect
+ must be replaced after 1s by
+ "Rect Text and Rect Animate Text!" (in green)
+
+
+ $Revision: 1.9 $
+
+
+
+
+
diff --git a/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-textcontent-202-t.svg b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-textcontent-202-t.svg
new file mode 100755
index 00000000..093fcb3c
--- /dev/null
+++ b/test/W3C_SVG_12_TinyTestSuite_beta/svg/udom-textcontent-202-t.svg
@@ -0,0 +1,79 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ Tests access to textContent.
+ The only text that should be visible is the string "Rect Text and Rect Animate Text!" in green.
+ The set element that makes the element "setTextContent" hidden should be removed when setting the new textContent and therefore the text must be visible.
+
+ Tests trait access in uDOM.
+ The svg should look the same on both sides and the text
+ should read "Passed". Both the rects should link back to this test.
+
+ Test on solidColor solid-opacity trait access.
+ Test result are displayed within the test.
+ The first sub-test should display a number approximately equal to 0.2.
+ The second sub-test should display a number approximately equal to 0.5.
+ The third sub-test should display a number equal to 1.
+
+ Test on Ecma-script. Sets viewport-fill-opacity to 0.5 with setFloatTrait
+ (should show a red viewport with correct opacity, and the text 'viewport-fill-opacity="0.5"' should show).
+