\n This test verifies the implementation of the preserveAspectRatio attribute on <image>\n referencing raster content.\n
\n\n This is a modified version of the sample file included in the SVG specification.\n It exercises the various preserveAspectRatio values and uses a general entity definition\n in order to make reading of the SVG source easier.\n
\n\n The rendered picture should match the reference image exactly except for variations in the labeling text.\n
\n\n This file tests the allowed syntax of the viewBox attribute. The viewBox attribute is a list of\n four numbers min-x, min-y, width and height, separated by whitespace and/or a comma.\n
\n\n Run the test. No interaction required.\n
\n\n In the rendered result, you should see 6 identical light blue shapes.\n
\n\n Tests that markers are drawn on zero-length \'path\' and \'line\' segments.\n
\nRun the test. No interaction required.
\n\n Test passes if there are two blue boxes, positioned as in the reference image.\n
\n\n This tests that the \'filter\' property does not apply to \'mask\'.\n
\n\n The mask \'m\' covers a rectangular area (200 x 200) except for a window\n (100 x 100) in the top left hand corner. Initially the mask window is\n set on top of the green square. Hence, the green square is shown and\n the red square is covered. If filters are supported the window within\n the mask will be shifted by an offset of 100,100 placing it on top of\n the red square.\n
\n\n Run the test. No interaction required.\n
\n\n The test passes if a green square is shown. If any\n red shows, the test has failed.\n
\n\n The rules are different regarding the geometry of a shape when clipping and masking.\n For example, a clip-path does not take into account the stroke of the shape used for clipping.\n It is however, used when masking.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are two identical darkblue circles at the top of the illustration, and\n below those two circles, two more circles should appear. They are of lighter appearance,\n the one on the left has a darker and thick stroke.\n
\n\n Test to see if the masking features using the mask element and mask\n property are available.\n
\n\n A red rectangle is displayed in the background to help view the result\n of transparency and masking.\n
\n\n From top to bottom, the tests are as follows.\n
\n\n In the top test, a linear gradient is used inside the mask to change the opacity\n of the rectangle from 1.0 (at the top) to 0.5 (at the bottom).\n
\n\n In the second test, a simple 50% opaque rectangle is used as a mask.\n
\n\n In the third test, no mask is used, but a rectangle is shown with 50% opacity.\n The second and third test should look the same.\n
\n\n Lastly, a string of text has a mask applied to it. The mask only covers a partial\n area of the text, so the text should only be half visible. Also the mask consists\n of 4 rectangles with various levels of opacity.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image, except\n variations are possible in the labelling text (per CSS2 rules).\n
\n\n If the \'mask\' property references a \'mask\' element containing no children, the element referencing it is not rendered.\n
\nRun the test. No interaction required.
\n\n Test passes if there is a single green rectangle, with no red visible on the page.\n
\n\n Test to see the effect of applying an opacity property to a group.\n
\n\n A blue rectangle with a green rectangle on top are contained in a\n group. This opacity of the group and the opacity of the rectangles are\n changed in this test. A red rectangle is provided in the background so\n that opacity changes are obvious visually.\n
\n\n From top to bottom, the tests are as follows.\n
\n\n In the top test, the opacities of the group and the individual rectangles are\n all set to 1. \n
\n\n In the second test, the group is given an opacity of 0.5. \n
\n\n In the third test, the group maintains a group opacity of 1 whereas each individual\n rectangle is given an opacity of 0.5 in the group. \n
\n\n Lastly, the group and individual rectangles are all given an opacity of 0.5.\n
\n\n\n\n Run the test. No interaction required.\n
\n\n In the top test, the green rectangle should appear on top of the blue\n rectangle.\n
\n\n In the second test, the blue\n rectangle should not show through in the region where the green and blue overlap.\n
\n\n In the third test, the blue rectangle\n should show through in the overlap region.\n
\n\n Lastly, the\n result should be similar to the previous test only fainter (because the opacity) is\n resulting in less contribution.\n
\n\n The rendered picture should match the reference image exactly, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n Test to see if the basic clipping works using the clipPath element\n and the clip-path property.\n
\n\n This test uses the following elements : <clipPath> and the following\n properties : clip-path.\n
\n\n Run the test. No interaction required.\n
\n\n The test at the top shows an orange rectangle (with black stroke) being clipped by another rectangle.\n So only the middle portion of the orange rectangle should be visible. Also the black stroke should\n only be visible along the top and bottom edge of the rectangle.\n
\n\n The example at the bottom has a group containing a text string and two rectangles. The group\n has a clipping path defined using two overlapping rectangles. Of concern is the overlapping area\n shared by the two rectangles. There should not be holes in this overlapping area, the\n clip region is the union of the two rectangles. For clarity,\n guide rectangles in grey show the position of the clipping rectangles.\n
\n\n The rendered picture should match the reference image exactly, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n Test to see if clipPathUnits attribute is handled properly on a\n clipPath element. Only tests the userSpaceOnUse and\n objectBoundingBox items of the clipPathUnits. userSpace has been\n tested by the previous test as it is the default.\n
\n\n The test at the top shows a pink rectangle that has been clipped by a\n rectangular clipping path. The clipping path is defined using clipPathUnits=objectBoundingBox.\n \n
\n\n The example at the bottom a rotated blue rectangle that has been clipped by a\n rectangular clipping path. The clipping path is defined using clipPathUnits=userSpaceOnUse.\n \n
\n\n The rendered picture should match the reference image exactly, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n Run the test. No interaction required.\n
\n\n The test passes if the pink rectangle and blue diamond do not have any\n color painted outside of their black borders.\n
\n\n Test \'overflow\'/\'clip\' on outermost and inner \'svg\' elements.\n
\n\n There are two parts to the test. The first part tests viewport clipping\n on outermost \'svg\' elements. The second part tests viewport clipping\n on inner \'svg\' elements.\n
\n\n The test case also tests the initial value of the \'overflow\' property\n to ensure that it is set to \'hidden\' for all \'svg\' elements.\n Tester should zoom out and/or pan to check this.\n
\n\n To test clipping to the outermost \'svg\' element,\n a rectangle with a light blue interior, a light red border and a black\n string that says "Clip to outer \'svg\'" is painted four times such that\n it will overflow each of the top, left, right and bottom\n sides of the bounds of the outermost \'svg\' element, respectively.\n
\n\n To test clipping to inner \'svg\' elements, a rectangle with a light red\n interior, a light blue border and a black string that says "Clip to\n inner \'svg\'" is painted four times such that it will overflow each of\n the top, left, right and bottom sides of the bounds of an inner \'svg\'\n element, respectively. \n
\n\n Note that minor text layout differences, as are permissible under CSS2\n rules, can lead to slightly different visual results regarding where\n the text strings get clipped.\n
\n\n Run the test. No interaction required.\n
\nThe test passes if:
\n\n This test exercises basic user-specified clip paths, using a text\n string (i.e., content of a \'text\' element) as the clip path.\n
\n\n There is a rectangular image of a swirly blue pattern with large\n yellow text, "Clip Test" superimposed. The image is a PNG file,\n imported into the picture via the \'image\' element.\n
\n\n The test uses the \'rect\' element, as well as basic fill (solid primary\n colors), stroke (black 1-pixel lines), font-family (Arial and\n Impact) and font-size properties.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image, except for\n possible variations in the labelling text (per CSS2 rules).\n
\n\n Test to see if clip-rule property has been implemented properly.\n
\n\n The test at the top shows a red rectangle that has been clipped by a\n clipping path that overlaps itself.\n
\n\n The test at the bottom shows a blue rectangle that has been clipped by a\n clipping path that overlaps itself.\n
\n\n The rendered picture should match the reference image exactly, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n Run the test. No interaction required.\n
\n\n In the first rectangle, the clip-rule is defined to be evenodd so the overlap should have a hole in it.\n The clip-rule is defined to be nonzero so the overlap should be filled.\n
\n\n This tests that \'clipPath\' elements can be used together and how the clipping paths are intersected.\n
\n\n There is a gray-white pattern as a background for the two subtest rectangles. This is to show that the holes that are cut out using clip-paths are transparent.\n The first subtest verifies that when you use the \'clip-path\' property on a child element inside a \'clipPath\' element the child element is clipped correctly.\n The second subtest verifies that when a \'clipPath\' element has a \'clip-path\' property the result is the intersection of the two clip paths.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if the following conditions are met:\n
\n\n This tests a few \'clip-path\' cases to see that clipping paths are applied and constructed properly.\n
\n\n Run the test. No interaction required.\n
\n\n There are nine subtests in this test. There should be a big stroked rectangle with nine smaller rectangles inside. If all of the smaller rectangles are green the test has passed.\n
\n\n The test has passed if:\n
\n\n This tests a few \'mask\' cases to see that masks are applied and constructed properly.\n
\n\n There are nine subtests in this test. There should be a big stroked rectangle with nine smaller rectangles inside. If all of the smaller rectangles are green the test has passed.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if:\n
\n\n Test the mask element with child elements with white and black fills,\n to create a mask that clips out some text in the middle.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if the letters \'ABC\' are visible inside a blue\n circle, and the letters are transparent, showing the checkered\n background image.\n
\n\n Test that the children of the \'clipPath\' element are not rendered directly.\n
\n\n Test passes if there is a green rectangle, and no red visible on the page.\n
\n\n The \'clipPath\' element itself and its children elements do not inherit clipping paths from ancestors of the \'clipPath\' element.\n
\n\n Overlay a red \'rect\' with a black \'rect\' of a larger size. Define a \'clipPath\' with a \'rect\' of the same size as the red \'rect\', but different \'x\' and \'y\' offsets. Reference that \'clipPath\' from a \'g\' element containing another \'clipPath\' element. In this latter \'clipPath\', specify a \'rect\' of the same size and same \'x\' and \'y\' offsets as the red \'rect\', and reference it from the black \'rect\' element. Reference the same \'clipPath\' elements, but this time with a black \'rect\' which overlays a red \'rect\' of a larger size. If there is no red on the page, the first \'clipPath\' was not inherited by the second \'clipPath\'.\n
\n\n Run the test. No interaction required\n
\n\n Test passes if there are two black rectangles, and there is no red visible on the page.\n
\n\n Check that metadata in a variety of namespaces, inside a metadata\n element, does not affect rendering in any way. The file is not valid to \n the SVG 1.1 DTD, but is well formed.\n
\nThe diagram on the table is, by the way, a visualization of the \n RDF metadata in the graphic.
\n\n Run the test. No interaction required.\n
\n\n The rendered result should match the reference image and there should be\n no error messages or warnings\n
\n\n Elements are rendered when the \'display\' attribute is set to any valid value other than \'none\'.\n
\n\n For each valid \'display\' value (except none), the test creates a \'rect\' element with that \'display\' value assigned. Under that \n element, a red \'rect\' is placed at the exact same \'x\', \'y\' position with the same height and width. Test passes if the \'rect\' \n with \'display\' covers the red \'rect\'.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if 16 black rectangles are shown and there is no red visible on the page.\n
\n\n \'Stroke\' attributes affected by directionality start at the point at which the graphics element starts.\n
\n\n The test creates two \'path\' elements that have the same \'stroke-dasharray\' assignment. The paths will create the same visual shape,\n but the start and end points will be opposite. Test passes if the \'stroke-dasharray\' of each path is drawn differently.\n Second subtest is the same but with stroke-dashoffset.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if there are two lines, each composed of alternating black and orange boxes.\n
\n\n Open polyline and path elements are filled as if they were closed with the last point linked to the first point.\n
\n\n The test specifies two polylines and two paths on the page with five points each. One polyline/path closes the shape with the fifth\n point linking to the first. One polyline/path is open (no link from fifth point to first). Both polylines/paths are filled.\n The open subpath is placed over the closed one. Test passes if the open subpath fills over the closed path.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if two black shapes are shown and no red visible on the page.\n
\n\n A zero length subpath with \'stroke-linecap\' set to \'square\' or \'round\' is stroked, but not stroked when \'stroke-linecap\' is set to \'butt\'.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if there is a blue circle, a blue square, and no red on the page.\n
\n\n This tests setting the \'display\' property to \'none\' on an element that is a child of a \'mask\' or \'clipPath\' element, which should cause the element to not be\n included in the \'mask\' or \'clip\' region.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are 8 green rectangles visible, and no red.\n
\n\n Setting the \'visibility\' property to \'hidden\' on a \'g\' tag will affect its children, unless the children of the \'g\' tag override the parent setting.\n
\n\n Have a \'g\' tag with an red filled shape as a child. Set \'visibility: hidden\' on the \'g\' tag. Verify no red is on the page.\n Also, have a \'g\' tag with a green filled shape as a child. Set \'visibility: hidden\' on the \'g\' tag. Set \'visibility: visible\' on\n the child tag. Verify that the green \'rect\' renders on the page.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are two green squares visible on the page, and no red.\n
\n\n Verify the basic capability to handle the fill properties fill:none,\n and fill with a color (fill:green)\n
\n\n Run the test. No interaction required.\n
\n\n There should be two rectangles, the rectangle on the left hollow (fill:none) and the rectangle on the right filled with green.\n
\n\n The test uses the "currentColor" value for the "fill" attribute.\n
\n\n Run the test. No interaction required.\n
\n\n The rectangle on the left should be green filled, the rectangle on the right should be blue.\n The text above the rectangles should be black.\n
\n\n Verify the basic capability to handle the fill rule properties evenodd and nonzero\n
\n\n Run the test. No interaction required.\n
\n\n There should be two green filled stars, the leftmost star should be unfilled in the very center.\n
\n\n This tests inheritance of three properties: "fill", "stroke" and "stroke-width". There is a "g" element (id="G1") which\n sets fill="blue", stroke="purple", and stroke-width="5". The first two rectangles on top should inherit all those\n properties. The middle left rectangle has fill="yellow" and stroke-width="2", it should inherit the stroke="purple"\n from the parent container. The middle rectangle on the right has stroke="yellow", it should inherit fill and\n stroke-width from the parent "g". The bottom two rectangles are in another "g" element (id="G2") which is a child\n of "G1". "G2" sets fill="yellow". It should inherit the stroke and stroke width from the parent "G1". The two\n bottom rectangles set no fill or stroke properties, they should inherit through the parents, stroke="purple"\n and stroke-width="5".\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image, except for possible\n variations in the labeling text (per CSS2 rules).\n
\n\n The test uses the "rect" element, as well as basic fill (solid primary colors),\n stroke (black 1-pixel lines), font-family (Arial) and font-size properties.\n
\n\n Test using "fill-opacity" values for "rect" element.\n This test verifies that opacity is clamped to the\n specified range.\n
\n\n Run the test. No interaction required.\n
\n\n The six rect elements on the left have varying \'fill-opacity\' values\n within the valid range of 0 to 1. The six elements on the right have\n \'fill-opacity\' values outside the 0 to 1 range, and must be clamped.\n The top three rect elements on the right must have their \'fill-opacity\'\n clamped to 0, while the bottom three rect elements on the right must\n be clamped to 1.\n
\n\n Tests the basic support for markers. \n
\n\n The top test examines the basic support for the marker element and style. The markers are purple rectangles.\n
\n\n The middle test examines the support for the different styles of marker properties. The\n "marker-start" property defines the marker to use at the first vertex of the marked path,\n in this case a purple rectangle. The "marker-end" property defines the marker to use at the\n last vertex of the marked path, in this case a blue triangle. The "marker-mid" property\n defines the marker to use at all vertices, other than the first and last, of the marked path,\n in this case a green circle.\n
\n\n The bottom test examines the support for marker orientation along the\n path direction. The second vertex, the top right corner of the path, has a marker that\n is rotated 45 degrees, since that is the average of the horizontal and vertical segments\n each side. The last vertex, the bottom right corner of the path, has a marker rotated 90\n degrees since that is the direction of the last path segment.\n
\n\n Run the test. No interaction required.\n
\n\n For the three tests, there should be two identical paths with markers drawn. \n The path on the left is rendered using the marker elements. The path on the \n right is rendered using the equivalent SVG, showing what the marked path should \n look like.\n
\n\n The rendered picture should match the reference image, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n Tests the rendering of markers, specifically property inheritance. For the four tests, there should\n be two identical paths with markers drawn. \n
\n\n The top two tests examine the rendering of markers when the marker and the path\n referencing it share the same parent and all painting properties are specfied on\n that parent. The first test show inheritance of the \'fill\' property and the\n second the inheritance of the \'paint\' property. In both tests, the marker\n is painting using the same properties as the referencing object. Because of\n scaling transformations on the marker, the stroke on the second test is thinner\n than on the referencing object.\n
\n\n The third and fourth tests examine the rendering of markers in a situation where the\n marker and referencing path do NOT share the same parent and painting\n properties are specified both on the parent of the marked path and on the contents\n of the marker itself. In both cases, the marker\'s parent specifies\n fill="green" stroke="blue" stroke-width="8". For the third test, the marker contents\n override with stroke="black". For the fourth test, the marker contents\n override with fill="black". In neither case should you see\n fill="orange" or stroke="blue" or "stroke="purple" on the markers as these properties\n are specified on the ancestor of the referencing object or the referencing object itself\n and thus shouldn\'t affect the marker.\n
\n\n Run the test. No interaction required.\n
\n\n The path on the left is rendered using the marker elements. \n The path on the right is rendered using the equivalent SVG, \n showing what the marked path should look like. These should be \n identical and match the image to the right.\n
\n\n The SVG specification defines three properties to reference markers: marker-start, marker-mid,\n marker-end. It also provides a shorthand property,marker. Using the marker property from a style sheet\n is equivalent to using all three (start, mid, end). However, shorthand properties cannot be used as presentation attributes.\n
\n\n Run the test. No interaction required.\n
\n\n The test passes if the shapes in the top row have no markers,\n while the shapes in the bottom rom have small blue markers\n (26 in total).\n
\n\n Tests the basic support for markers. For the three tests, there\n should be two identical paths with markers drawn. The path on the left is\n rendered using the marker elements. The path on the right is rendered using\n the equivalent SVG, showing what the marked path should look like.\n
\n\n This test is similar to the painting-marker-01-f.svg test, but has some viewBox attributes\n that have a non-zero offset.\n
\n\n The top test examines the basic support for the marker element and style. The markers are purple rectangles.\n
\n\n The middle test examines the support for the different styles of marker properties. The\n "marker-start" property defines the marker to use at the first vertex of the marked path,\n in this case a purple rectangle. The "marker-end" property defines the marker to use at the\n last vertex of the marked path, in this case a blue triangle. The "marker-mid" property\n defines the marker to use at all vertices, other than the first and last, of the marked path,\n in this case a green circle.\n
\n\n The bottom test examines the support for marker orientation along the\n path direction. The second vertex, the top right corner of the path, has a marker that\n is rotated 45 degrees, since that is the average of the horizontal and vertical segments\n each side. The last vertex, the bottom right corner of the path, has a marker rotated 90\n degrees since that is the direction of the last path segment.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n A \'marker\' element with \'display\' set to \'none\' on that\n element or any ancestor is rendered when referenced by another element.\n
\n\n Run the test. No interaction required\n
\n\n Test passes if there are two green triangles visible on the page.\n
\n\n Verify the basic capability to handle the stroke properties ("stroke")\n in combination with the "rect" element .\n The pair should be rendered as two blue rectangles,\n the upper one without a stroke and the lower with a green stroke.\n
\n\n The test uses the "rect" element, as well as basic "fill" (solid primary colors),\n "stroke", stroke="green", "font-family" and "font-size" attributes.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image, except for possible\n variations in the labeling text (per CSS2 rules).\n
\n\n Verify the basic capability to handle the stroke properties ("stroke", "stroke-width",\n "stroke-linejoin") in combination with the "rect" element.\n
\n\n Run the test. No interaction required.\n
\n\n The pair should be rendered as two blue rectangles without an interior fill.\n The upper rectangle should have a thick stroke and sharp corners.\n The lower rectangle should have a thick stroke and round corners.\n
\n\n This test checks the basic capability of handling the stroke properties ("stroke", "stroke-width"\n "stroke-linejoin", "stroke-linecap", "stroke-miterlimit")\n with straight-line path commands.\n
\n\n Run the test. No interaction required.\n
\n\n The two paths should be rendered as two blue line segments.\n The upper segment should have round end caps. The lower segment\n should be chopped off where the two line segments meet.\n
\n\n This test checks the "stroke-dasharray" and "stroke-dashoffset" properties. Two lines are drawn, one blue\n and one black. Both have a "stroke-dasharray" of "10,10" giving a dashed appearance\n where the size of the gaps and the size of the dash is equal.\n
\n\n The black line is lower than but parallel to the blue line. The "stroke-dashoffset" on each line should make the dashes of each line line up with the gaps in the other line.\n
\n\n User agents may render graphical primitives with different levels of accuracy.\n This test is aimed at determining how a UA renders thin strokes.\n
\n\n The test file contains a number of vertical and horizontal lines.\n The stroke width of the vertical lines increase from left to right.\n The stroke width of the horizontal lines increase from top to bottom.\n
\n\n The test is passed if user is able to see a smooth stroke width\n increment for the vertical and horizontal lines. The top left hand\n corner should contain strokes that are very thin in width and the bottom\n right hand corner should contain thick strokes.\n
\n\n Test default effects of stroke-dasharray.\n
\n\n This specifically tests the values of none and 0.\n This also tests an odd number of values in a dash-array attribute\n and in combination with an offset.\n
\n\n The top two lines must be solid black. The next line shows a thick\n black line with a thinner blue line on top; both must have the same\n dash pattern. The bottom two lines, one black and one blue, must render\n so that the gaps of one correspond to the dashes of the other.\n
\n\n Test effect of different stroke-miterlimits. For this particular combination of\n stroke width and angle, the cut off value of stroke-miterlimit is 18.028.\n
\n\n Run the test. No interaction required.\n
\n\n The first and second subtests should not truncate the stroke, and all the rest must truncate it.\n
\n\n Test effects of stroke-opacity range. Values\n outside the range 0-1.0 must be clamped.\n
\n\n There must be no blue bars visible beside the three pink dots.\n Four semitransparent blue bars, increasingly more opaque,\n must line up with the yellow dots. Three fully opaque\n blue bars must line up with the green dots.\n
\n\n This tests that the "stroke-dasharray" property accepts values\n that are separated by white space.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if it matches the reference rendering\n by showing a thick stroke with alternating long and short\n stroke dashes.\n
\n\n This tests that stroking of zero length subpaths will result in\n some rendering if the \'stroke-linecap\' property is set to\n \'square\' or \'round\', but not if it is set to \'butt\'.\n
\n\n Simply load the test. Two rows of shapes should be presented,\n with a text label describing the row.\n
\n\n Run the test. No interaction required.\n
\n\n Simply load the test. Two rows of shapes should be presented,\n with a text label describing the row.\n
\n\n Test that the viewer has the basic capability to handle the \'path\'\n element and its data (d) attribute in combination with the cubic\n Bezier curveto commands, C, c, S, s (plus Mm and Zz).\n
\n\n There are 8 subtests, each composed from the cubic Bezier path commands per\n the label by the subtest. On-curve control points (i.e., the curve position)\n are marked by small blue squares. Subtests are filled, or stroked, or\n both, using simple style properties and colors.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Test that the viewer has the basic capability to handle the \'path\'\n element and its data (d) attribute in combination with the quadratic\n Bezier curveto commands, Q, q, T, t (plus Mm and Zz).\n
\n\n There are 7 subtests, each composed from the quadric Bezier path commands per\n the label by the subtest. On-curve control points (i.e., the curve position)\n are marked by small colored squares. Subtests are filled, or stroked, or\n both, using simple style properties and colors.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Test that the viewer has the basic capability to handle the \'path\'\n element and its data (d) attribute in combination with the elliptical\n arc curveto commands, A, a (plus Mm and Zz).\n
\n\n There are 6 subtests, each composed from the elliptical arc path commands per\n the label by the subtest. The curve positions\n are marked by small colored squares. Subtests are filled, or stroked, or\n both, using simple style properties and colors.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Verify the basic capability to handle the \'path\' element, and its data attribute (d)\n in combination with the straight-line path commands.\n Two pairs of concentric equilateral triangles are drawn using respectively\n M,L,Z and m,l,z. The shapes are identical, with one stroked and\n one filled. The fill-mode default of "even-odd" means that\n the inner triangle is hollow.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Verify the basic capability to handle the \'path\' element, and its data attribute (d)\n in combination with the straight-line path commands.\n Two pairs of concentric equilateral triangles are drawn using respectively\n M,L,Z and m,l,z. The shapes in each pair are identical, with one stroked and\n one filled. The fill-mode default of "even-odd" means that\n the inner triangle is hollow.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Verify the basic capability to handle the \'path\' element, and its data attribute (d)\n in combination with the straight-line path commands.\n Two pairs of staircase figures are drawn using\n respectively M,H,V,Z and m,h,v,z. The shapes in each pair are identical, with one stroked and\n one filled.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Verify the basic capability to handle the \'path\' element, and its data attribute (d)\n in combination with the straight-line path commands.\n Two pairs of staircase figures are drawn using\n respectively M,H,V,Z and m,h,v,z. The shapes in each pair are identical, with one stroked and\n one filled.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Verify the basic capability to handle the \'path\' element, and its data attribute (d)\n in combination with the straight-line path commands.\n Two pairs of concentric equilateral triangles are drawn using\n M and Z. No L commands are used in this test as they are implied after\n an M or Z command. The shapes are identical, with one stroked and\n one filled. The fill-mode default of "even-odd" means that\n the inner triangle is hollow.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Verify the basic capability to handle the \'path\' element, and its data attribute (d)\n in combination with the straight-line path commands.\n Two pairs of concentric equilateral triangles are drawn using\n m and z. No l commands are used in this test as they are implied after\n an m or z command. The shapes are identical, with one stroked and\n one filled. The fill-mode default of "even-odd" means that\n the inner triangle is hollow.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Verify that the viewer renders the line caps and line joins for\n open and closed paths properly.\n Verify that the open triangular paths are stroked differently at\n ends of the path than they are at their intermediate corners.\n In contrast, the corners of a closed path should all appear the\n same.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image exactly\n
\n\n Test using multiple coord sets to build a polybeizer, and implicit values for initial S.\n
\n\n The rendered picture should match the reference image exactly, except for possible variations in the labelling text (per CSS2 rules).\n
\n\n\n The rendered picture should match the reference image.\n
\n\n Test multiple coordinates for V and H. \n
\n\n Run the test. No interaction required.\n
\nThe test is passed if there is one horizontal green line and one vertical blue line.\n
\n\n Test implicit values for moveto. If the first command is \'m\' it should be taken as an absolute moveto, plus implicit lineto.\n
\nRun the test. No interaction required.
\nThe test is passed if the three triangles are shown: two concentric, unfilled\n triangles with black strokes on the left, and one unfilled triangle with\n a thick blue stroke on the right.
\n\n Test using multiple coord sets to build a polybezier, then T with no preceding Q or T.\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, apart from any allowable font selection differences due to CSS2.
\nA purple wavy line above a short, blue horizontal line must be shown.\n Small black triangles pointing to the start, middle and end of the blue\n line must also be shown.
\n\n This tests that any implicit lineto commands that result from an\n \'M\' or \'m\' command with more than one pair of coordinates are absolute\n if the moveto was specified with \'M\' and relative if the moveto was\n specified with \'m\'.\n
\n\n Run the test. No interaction required.\n
\n\n After loading the test, the test is passed if two yellow\n triangles with black borders are shown. Otherwise, the\n test has failed.\n
\n\n Test that the \'z\' and \'Z\' command have the same effect.\n
\n\n Specify four \'path\' elements that each use three \'L\' commands to draw three sides of a square. The fourth line of each\n square is drawn via a \'closepath\' command. A red square closed via \'z\' is covered with a black square closed via \'Z\' and\n vice versa.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if two black-stroked, unfilled squares are visible and\n there is no red visible on the page.\n
\n\n The \'path\' element\'s \'d\' attribute ignores additional whitespace, newline characters, and commas, and BNF processing consumes as much content as possible, stopping as soon as a character that doesn\'t satisfy the production is encountered.\n
\n\n Various black path segments are rendered that each demonstrate one of the parsing rules. Each path segment is placed on top\n of a similar path segment that lacks the particular parsing rule that is being tested. Test passes if no red is visible.\n
\n\n Run the test. No interaction required.\n
\n\n The test passes if seven thick black horizontal lines are shown with corresponding\n gold horizontal lines just above them, and the black and gold lines are all of the\n same length and horizontal position.\n
\n\n Test that additional parameters to pathdata commands are treated as additional calls to the most recent command.\n
\n\n Each of the applicable \'pathdata\' commands are used in separate \'path\' elements. Each command is repeated in red and\n overlayed with another \'path\' element with identical coordinates specified but without the repeated command in black.\n Commands that do not render or do not take parameters are omitted.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there is no red visible on the page.\n
\n\n Tests parsing of the elliptical arc path syntax.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if the image looks as if there are eight green circles that have\n two white rectangles overlapping them, like in the reference image. If any red is visible\n the test has failed.\n
\n\n Test that the viewer can handle the xlink:href attribute on\n linear gradients. The top rectangle has a simple\n blue (left) to lime (right) linear gradient. The lower one\n has a different gradient definition, but\n should look the same as the one above, because the gradient makes a\n reference to the first gradient, without modifying any attribute.\n
\n\nRun the test. No interaction required.\n
\n\n The test is passed if there are two rectangles, both with a blue to lime gradient. \n
\n\n Test that the viewer can handle the xlink:href attribute on\n radial gradients.\n
\n\n There are two rectangles. The top one has\n a radial gradient (black to orange) that should appear elliptical\n to fit the aspect ratio of the rectangle. The units are\n specified in objectBoundingBox space. The gradient\n on the lower one\n references the gradient of the top rectangle, but modifies\n the units to use userSpace instead. So it is only using the\n stops from the gradient to the left, with a different geometry. The radial gradient appears circular.\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, except\n for any differences in text due to CSS2 rules. Specifically:
\n\n Test that the viewer can handle the xlink:href attribute on\n patterns.\n
\n\n There are two rectangles with a pattern fill made\n up of 4 rectangles. The pattern definition of the lower one references the pattern definition\n of the upper one, using the xlink:href attribute. Because\n the particular way that the patterns and rectangles are\n defined in this test case, the two fills will appear the\n same - the rectangles are positioned on pattern-size\n boundaries, so that the offsets into the pattern at the left\n edges of the respective rectangles is identical.\n
\n\n Run the test. No interaction required.\n
\nThe test passes if the rendering matches the reference image, except\n for any differences in text due to CSS2 rules. Note that the top rectangle must\n look identical to the bottom rectangle.
\n\n Test that checks the capability of the stop element in linear and radial\n gradients.\n
\n\n The first rectangle has a linear gradient fill with a vector starting at top left\n and going to bottom right. The stop colors are at 20% spacing apart and are in the\n following order : violet, blue, lime, yellow, orange, green.\n Because the gradient vector vector goes from (0,0) to (1,1) in object bounding box space\n and because the object bounding box has a larger width than height, the gradient vector\n is skewed off of a pure 45 degree angle. The gradient stripes are also skewed\n so that they are no longer perpendicular to the gradient vector.\n
\n\n The next rectangle has a radial gradient fill with a multi-color stops from innermost\n to outermost in the following order: black, yellow, orange, blue, white, green.\n
\n\n Run the test. No interaction required.\n
\nThe test passes if the rendering matches the reference image, except for\n any differences in text due to CSS2 rules.
\n\n Test that checks the capability of the stop opacity in linear and radial\n gradients.\n
\n\n There are two tests which contain rectangles with gradients using stop-opacity properties.\n A cyan color text string "Background" is put behind both of the rectangles to help\n demonstrate the opacity concept.\n
\n\n From top-down the appearance of objects is as follows.\n
\n\n The first rectangle has a linear gradient fill with a vector starting at top left\n and going to bottom right. The stop colors are at 20% spacing apart and are in the\n following order : violet, blue, lime, yellow, orange, black.\n Also a stop opacity is given to the colors in the following order: 1, 0.2, 0.5, 0, 0.8, 1\n Because the gradient vector vector goes from (0,0) to (1,1) in object bounding box space\n and because the object bounding box has a larger width than height, the gradient vector\n is skewed off of a pure 45 degree angle. The gradient stripes are also skewed\n so that they are no longer perpendicular to the gradient vector.\n
\n\n The next rectangle has a radial gradient fill with a multi-color stops from innermost\n to outermost in the following order: black, yellow, red, blue, white, green.\n Also a stop opacity is given to the colors in the following order: 1, 0.2, 0.5, 0, 0.8, 1\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, except for\n any differences in text due to CSS2 rules.
\n\n Test that the viewer can handle the gradientTransform and the patternTransform\n attribute on gradients and patterns respectively.\n
\n\n From top-down the appearance of objects is as follows.\n
\n\n The top rectangle has a linear gradient whose coordinate system has been scaled down by\n a half. So the gradient travelling from left to right (from blue to green to lime) should\n only occuply the left half the rectangle.\n
\n\n The next rectangle has radial gradient that has been translated to the center and skewed\n in the positive X direction by 45 degrees. Therefore the gradient should appear\n ellipltical and rotated around the center.\n
\n\n The last row contains a rectangle with pattern on the fill. The transformation on the\n pattern moves the coordinate system to the top left of the rectangle and then scales it\n by a factor of 2 and then skew\'s it in the X direction by 45 degrees. The pattern\n consists of a 2 by 2 array of colored rectangles.\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, apart\n from any differences in font choice due to CSS2 rules. Specifically:
\n\n Test that the viewer has basic capability to handle linear gradients\n on fills and stroke of objects and text.\n
\n\n This test uses the following elements : <linearGradient>, <stop>\n and the following properties : stop-color, fill:url(# ), stroke(url# )\n
\n\n Both elements in this test use the same simple gradient. It is a linear gradient from\n blue (left) to lime (right). From top-down the appearance of objects is as follows.\n
\n\n The top rectangle should be filled with the gradient.\n
\n\n The next rectangle has no fill, but has a thick stroke on which the gradient is\n applied.\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, apart\n from any differences in font choice due to CSS2 rules. Specifically:
\n\n Test that the viewer has basic capability to handle linear gradients\n on fills and stroke of text.\n
\n\n Both elements in this test use the same simple gradient. It is a linear gradient from blue (left) to lime (right). From top-down the appearance of objects is as follows.\n
\n\n The first item is a text string "Gradient on fill" with the gradient on the fill of the text.\n
\n\n The second item is a text string that is not filled. It has a 2 user unit stroke on which the gradient is applied.\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, apart\n from any differences in font choice due to CSS2 rules. Specifically:
\n\n Test that the viewer can handle the gradientUnits attribute on linear gradients.\n It tests the following values of gradientUnits: default (userSpace), objectBoundingBox,\n and userSpaceOnUse.\n
\n\n From top-down the appearance of objects is as follows.\n
\n\n The first rectangle uses the default attributes on the linearGradient element.\n Therefore the linear gradient should default to objectBoundingBox. It should appear\n from the left edge of the rectangle (blue) to the right edge of the rectangle (lime).\n The rectangle is smaller than the viewport, because a previous version of the SVG spec had the default value be \'viewport\'.\n The test fails if only a portion of the gradient is shown.\n
\n\n The next rectangle uses gradientUnits=objectBoundingBox. The linear gradient should\n travel from blue (top) to lime (bottom).\n
\n\n The last rectangle uses gradientUnits=userSpaceOnUse. The rectangle element is given it\'s\n own transformation and the gradient is assumed to be in this user space.\n The gradient should appear as a linear gradient from lime (left) to blue (right).\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, apart\n from any differences in font choice due to CSS2 rules. Specifically:
\n\n Test that the viewer can handle the spreadMethod attribute on linear gradients.\n
\n\n Run the test. No interaction required.\n
\nThe test passes if the rendering matches the reference image, apart\n from any differences in font choice due to CSS2 rules. Each of the\n three rectangles is filled with a linear gradient from blue on the left\n to lime on the right. The width of the gradient is only a fifth of\n the width of the rectangle, so:
\n\n Test that the viewer has basic capability to handle radial gradients\n on fills and stroke of objects and text.\n
\n\n This test uses the following elements : <radialGradient>, <stop>\n and the following properties : stop-color, fill:url(# ), stroke(url# )\n
\n\n From top-down (left to right) the appearance of objects is as follows.\n
\n\n The top left rectangle should be a radial gradient from dark blue (in) to lime (outside).\n The gradient is applied to the fill of the rectangle.\n
\n\n The next rectangle has no fill, but has a thick stroke on which the gradient is\n applied. The gradient goes from dark orange(in) to pale yellow (out).\n
\n\n The next item is a text with a radial gradient on the fill. The gradient goes\n from green (in) to yellow (out).\n
\n\n The last item is a text with a 2 user unit stroke on which a black (in) to magenta\n (out) linear gradient is applied.\n
\nRun the test. No interaction required.
\nThe test passes if the rendering matches the reference image, apart\n from any differences in font choice due to CSS2 rules. Specifically:
\n\n Test that the viewer can handle the gradientUnits attribute on radial gradients.\n It tests the following values of gradientUnits: default (objectBoundingBox), objectBoundingBox,\n and userSpaceOnUse.\n
\n\n From top-down the appearance of objects is as follows.\n
\n\n The first rectangle uses the default attributes on the radialGradient element.\n Therefore the radial gradient should be relative to the object bounding box. It should appear\n from the center of the viewport (blue) to the edges of the viewport (lime).\n The rectangle is wider than tall so it the gradient should be elliptical, not circular.\n
\n\n The next rectangle uses gradientUnits=objectBoundingBox. The radial gradient should\n travel from a center of 20%, 20% of the rectangle with a radius of 50%.\n
\n\n The last rectangle uses gradientUnits=userSpaceOnUse. The rectangle element is given it\'s\n own transformation and the gradient is assumed to be in this user space.\n The gradient should appear in the center of the rectangle as a radial gradient from yellow (center) to blue (edge).\n
\nRun the test. No interaction required.
\nThe test passes if the rendering of the three rectangles matches those\n in the reference image. Specifically:
\n\n The purpose of this file is to test several values for focal points of radial gradients.\n
\nRun the test. No interaction required.
\nThe test passes if the rendered image matches the reference image, except\n for any differences in font choice due to CSS2.
\n\n The intent of this file is to test the 4 allowed spread methods for linear and radial gradients.\n The 4 values (pad, reflect, repeat and default) are available for both types of gradients.\n On the left side are the linear gradient results, and on the right, the radial results.\n The UA should render a result equivalent to the reference image.\n
\nRun the test. No interaction required.
\nThe test passes if the rendered image matches the reference image, except\n for any differences in font choice due to CSS2.
\n\n Test linear and radial gradient defaults. Includes\n testing defaults for linear grad x1,y1,y2 = 0%, x2 = 100%.\n and testing defaults for radial grad cx,cy,r = 50%, fx,fy = cx,cy.\n
\n\n Run the test. No interaction required.\n
\n\n The top rectangle must be blue at the lefthand side and fuchsia at the right\n hand side, fading smoothly accross. The lower rectangle must be fuchsia at\n the edges with a black centre to the radial gradient at the centre of the\n rectangle, and the gradient occupying the whole rectangle.\n
\n\n Test gradient stop rules. Including:\n No stops, like fill = none.\n One stop, like fill = black.\n If a stop less than all previous stops, it is set equal to the largest stop.\n If two stops are equal the last stop controls the color at the overlap point.\n
\n\n [[\n Describe how to use the here. The instructions should specify any\n steps requied to run the test or any manual operation that need\n to be performed to run the test.\n ]]\n
\n\n The top rectangle must have a pink outline and no fill. The middle rectangle must have a\n solid black fill. The lower rectangle must have a yellow to pink to green\n linear gradient on the left-hand half and a solid blue fill for the right hand half.\n
\n\n This test has a gradient with gradientUnits=\'objectBoundingBox\' which is a fade from black to white.\n The gradient is used for the stroke of a line. Vertical and horizontal lines don\'t have a boundingbox,\n since they are one-dimensional, even though the\n stroke-width makes it look like they should have a boundingbox with non-zero width and height.\n See the coordinate chapter, last paragraph of 7.11.\n
\n\n [[\n Describe how to use the here. The instructions should specify any\n steps requied to run the test or any manual operation that need\n to be performed to run the test.\n ]]\n
\n\n The left rectangle has four \'line\' elements rotated in different ways. The stroke for the lines have a green solid stroke fallback which\n 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\n (from bottom left to top right) with a gradient stroke, visible in the rectangle.\n
\n\n The right rectangle is the same as the left rectangle except that the stroke paintservers don\'t have a fallback specified.\n 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.\n
\n\n This test shows rectangles filled with gradient.\n Several gradients are defined, with two stops:\n
\n\n For the top-left rectangle\'s gradient:\n The first stop defines a fully-opaque green color.\n The second stop explicitly inherits (i.e. using the \'inherit\' keyword) its stop-color. \n
\n\n For the top-right rectangle\'s gradient:\n The first stop defines a fully-opaque green color.\n The second stop defines a green stop-color but explicitly inherits (i.e. using the \'inherit\' keyword) the stop-opacity. \n
\n\n For the bottom-left rectangle\'s gradient:\n The first stop defines a fully-opaque green color.\n The second stop does not specify the stop-color and the stop-opacity.\n Since both properties are not inherited, the initial value should be used. \n
\n\n For the bottom-right rectangle\'s gradient:\n The first stop defines a fully-opaque green color.\n The second stop specifies the stop-color using the \'currentColor\' keyword. \n
\n\n The result should be:\n
\n\n The top-left rectangle is filled with a gradient from green to pink since\n the stop-color is inherited from the location of the gradient definition.\n
\n\n The top-right rectangle filled in green with a gradient opacity.\n
\n\n The lower-left rectangle filled with a gradient going from fully-opaque green to fully-opaque black.\n
\n\n The lower-right rectangle filled with a gradient going from fully-opaque green to fully-opaque yellow.\n
\n\n This test has a gradient with gradientUnits=\'objectBoundingBox\' which is a fade from black to white.\n 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\n stroke-width makes it look like they should have a boundingbox with non-zero width and height.\n See the coordinate chapter, last paragraph of 7.11.\n
\n\n The left rectangle has four \'line\' elements rotated in different ways. The stroke for the lines have a green solid stroke fallback which\n should be used if the gradient should be ignored.\n\n The right rectangle is the same as the left rectangle except that the stroke paintservers don\'t have a fallback specified.\n
\n\n The test is passed if\n
\n\n Test the inheritance of radial gradient attributes. The test has six ellipses with blue stroke, each filled\n with two gradients. \n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if:\n
\n\n Tests that transforms affect the rendering of a gradient.\n
\n\n Run the test. No interaction required.\n
\n\n The test passes if each of the two gradient-filled rectangles\n towards the top of the test slide is identical to the one below it.\n
\n\n \n
\n\n \n
\n\n Run the test. No interaction required\n
\n\n \n
\n\n \n
\n\n Test that the \'linearGradient\' and \'radialGradient\' elements are neither rendered directly nor via the \'use\' element.\n
\n\n The test defines \'linearGradient\' and \'radialGradient\' elements with a red \'stop\' and references them from a \'use\' element. \'linearGradient\'\n and \'radialGradient\' elements with a red \'stop\' are also specified outside of a \'defs\' tag as if they were regular graphical elements.\n
\nRun the test. No interaction required.
\n\n Test passes if there is no red visible on the page.\n
\n\n Test that gradient offset values less than zero are rounded up to zero and values more than one are rounded down to one.\n
\n\n The test defines four gradients, each with a single stop where the \'stop-color\' is set to \'blue\'.\n The four gradients have \'offset\' set to \'-1\', \'-1%\', \'101%\' and \'2\'. Four rectangles reference\n the gradients. All of these should render as if they have plain blue fills.\n
\nRun the test. No interaction required.
\n\n The test passed if there are four blue boxes on the page.\n
\n\n Test that the viewer has basic capability to handle patterns\n on fills and stroke of objects and text.\n
\n\nRun the test. No interaction required.\n
\n\n From top-down the appearance of objects is as follows.\n
\n\n The top rectangle should be filled with a pattern composed of a green\n rectangle on top of yellow rectangle. A default stroke has been applied to the original\n rectangle to see the boundary of the rectangle.\n
\n\n The next rectangle has no fill, but has a thick stroke on which the pattern is\n applied. The pattern consists of 4 colored rectangles.\n
\n\n The next item is a text with a pattern on the fill. The pattern appears as\n alternating rows of orange and green.\n
\n\n The last item is a text with a 2 user unit stroke on which a pattern is applied.\n The pattern appears as alternating columns of maroon and blue.\n
\n\n Test that the \'patternTransform\' attribute has an effect on the \'pattern\' element.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if the testframe is filled with a blue and white\n diamond pattern.\n
\n\n Test that empty patterns are not rendered, and that the fallback color is used instead.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are 8 green rectangles visible, and no red.\n
\n\n Inherited attributes from a referenced \'pattern\' are not applied if they are already defined on the referencing \'pattern\' element.\n
\n\n Define a pattern \'pattern1\' with circles that have red fill. Inherit \'pattern1\' into \'pattern2\' and add circles at different \'y\'\n attribute and with \'fill\' set to \'lime\' on \'pattern2\'. Reference \'pattern1\' from a square using \'fill\' attribute. Reference \'pattern2\'\n from a different square using \'fill\' attribute. Position the second square directly over the first square. Verify that there is green visible.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are four green circles visible on the page, and no red.\n
\n\n Test that a \'pattern\' element can inherit attributes through multiple levels of\n \'xlink:href\' referencing.\n
\n\n The test defines a pattern \'pattern1\' with some attributes that scale the contents. The attributes on\n \'pattern1\' are inherited into \'pattern2\' and then inherited from \'pattern2\'\n into \'pattern3\'. \'pattern3\' has a green circle as its graphical content.\n A \'rect\' uses \'pattern3\' as its fill, if the attributes are correctly inherited into\n \'pattern3\', then the green circle will occlude a red circle in the same position.\n
\nRun the test. No interaction required.
\n\n The test passed if there is no red visible on the page.\n
\n\n \n
\n\n \n
\n\n \n
\n\n Test that an invalid xlink:href on a \'pattern\' element has no effect on the pattern.\n The pattern dimensions and coordinate-system are defined completely on the pattern that has the invalid xlink:href,\n to test that they\'re not overridden by the non-existant pattern that is referenced.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are four green circles visible on the page.\n
\n\n Test that an invalid xlink:href on a \'pattern\' element has no effect on the pattern.\n This test specifies only \'width\' and \'height\' on the pattern that is tested in order to catch \n incorrectly overridden values from a non-existant pattern. The result is tested\n with a reference pattern using slightly different syntax.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are four green circles visible on the page, and no red.\n
\n\n Test that an invalid xlink:href on a \'pattern\' element has no effect on the pattern, and that the\n pattern isn\'t rendered since the default \'width\' and \'height\' is 0.\n A subtest that explicitly specifies \'width\' and \'height\' as 0 is added as a reference. \n Both of these cases should result in the fallback color being used.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there is a green rectangle visible on the page, and no red.\n
\n\n Verifies that shapes can be filled.\n
\n\nRun the test. No interaction required.\n
\n\n There is one pair of octagons. These are filled.\n
\n\n Verifies that shapes can be stroked.\n
\n\nRun the test. No interaction required.\n
\n\n There is one pair of octagons. These are stroked.\n
\n\n Verifies that shapes can be filled, stroked and the order of filling and stroking.\n
\n\nRun the test. No interaction required.\n
\n\n There is one pair of octagons. These are filled plus stroked.\n
\n\n Verifies that text can be filled. \n
\n\nRun the test. No interaction required.\n
\n\nThe\n test shows two \'G\' characters that are filled \n (green to the left, and with navy to the right) and not stroked.\n
\n\n Verifies that text can be stroked. The\n \n
\n\nRun the test. No interaction required.\n
\n\n The test shows two characters that are stroked and not filled.\n
\n\n Verifies that text can be stroked.\n \n
\n\nRun the test. No interaction required.\n
\n\n The test shows two \'G\' characters that are both stroked and filled.\n
\n\n Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4).\n It also validates basic Shape, Image and text rendering.\n
\n\nRun the test. No interaction required.\n
\n\n The rendered image should match the reference image exactly.\n
\n\n This test renders 3 elements: a text string "SVG", then\n a shape, then an image. Because of their definition order and coordinates, the image\n should be on top of the rectangle and the rectangle on top of the text. The\n test validates that groups are conceptually rendered offscreen before being\n rendered on the canvas. This is done by grouping the same overlapping objects and\n rendering the group at half opacity. The background pattern (vertical stripes) should\n show through all the group elements. However, none of the "SVG" text string should show through the\n rectangle and none of the rectangle should show through the image.\n
\n\n Verifies implicit rendering order (paragraph 3.3) and grouping mechanism (paragraphs 3.4).\n It also validates basic Shape, Image and text rendering.\n
\n\nRun the test. No interaction required.\n
\n\n The rendered image should match the reference image exactly.\n
\n\n This test renders 3 elements: a text string "SVG", then\n a shape, then an image. Because of their definition order and coordinates, the image\n should be on top of the rectangle and the rectangle on top of the text. None\n of the "SVG" text string should show through the\n rectangle and none of the rectangle should show through the image.\n
\n\nTests the circle element\n
\n\nRun the test. No interaction required.\n
\n\n Six circles are displayed, with position, size, fill and stroke matching the reference image\n
\n\n Default attributes test with circle.\n
\n\n Run the test. No interaction required\n
\n\n The test is passed if a group of four circles is displayed, arranged as shown in the reference image.\n
\n\n Test the ellipse element.\n
\n\nRun the test. No interaction required.\n
\n\n Seven ellipses are displayed, with position, size, fill and stroke matching the reference image\n
\n\n Defaults test with ellipse.\n
\nRun the test. No interaction required.
\nThe test passes if one blue ellipse is shown completely within the test slide,\n and a quarter ellipse is shown in the top-left corner of the test slide.
\n\n The \'ellipse\' element defines an ellipse which is axis-aligned with the current user coordinate system when it is not the initial user coordinate system.\n
\n\n The test shows an \'ellipse\' element originating at (0,0) of the current user coordinate system, which has been altered via \'transform\' from\n the initial user coordinate system. Two perpendicular lines which also originate at (0,0) and advance along the x and y axes of \n the current user coordinate system are shown. These lines overlap the top and left edges of the ellipse and verifies that the ellipse is \n thus axis-aligned with its current user coordinate system.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if both ellipses are divided into four equal parts by two sets of crossing lines, and the rightmost ellipse and crossing lines are rotated together. \n
\n\nCheck that negative second coordinate in a coordinate pair does not need separating wsp-comma.\n
\n\n Run the test. No interaction required.\n
\n\nThe test is passed if each shape seems to have a double stroke, dark green and light green.\n
\n\n Tests the degenerate cases of the basic shapes. The shapes are positioned\n within the black rectangles.\n
\nRun the test. No interaction required.
\nThe test passes if the 11 rectangles are empty.
\n\n Test that basic shape elements are equivalent to a \'path\' element that constructs the same shape.\n
\n\n For each basic shape, a \'path\' reference element that is red is created.\n A basic shape is then placed on top of the \'path\' element. \n For each basic shape there\'s also a reverse test that uses the shape as a reference for the \'path\' element.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there is no red visible on the page.\n
\n\nTests the line element.\n
\n\nRun the test. No interaction required.\n
\n\nThe test is passed if five diagonal lines are displayed on the top row. On the bottom row, a square wave pattern is displayed. The position, size, fill and stroke of the lines matches the reference image.\n
\n\n The \'fill\' attribute has no effect on the \'line\' element.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if there is no red visible on the page.\n
\n\n This test draws six different polygons excercising portions of the path attribute.\n
\n\n Run the test. No interaction required.\n
\n\n The six polygons drawn should match the reference image.\n
\n\nChecks that polygons and the equivalent paths are indeed equivalent.\n
\n\n Run the test. No interaction required.\n
\n\nThe test is passed if each shape seems to have a double stroke, dark green and light green.\n
\n\n Test that \'polyline\' and \'polygon\' elements with an odd number of coordinates render up to the invalid coordinate.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if four green triangles are visible on the page, and no red.\n
\n\nTests the polyline element.\n
\n\nRun the test. No interaction required.\n
\n\n The test is passed if polylines are displayed whose position, size, fill and stroke matches the reference image.\n
\n\nChecks that polylines and the equivalent paths are indeed equivalent.\n
\n\n Run the test. No interaction required.\n
\n\nThe test is passed if each shape seems to have a double stroke, dark green and light green.\n
\n\n This is a simple test of the rect element.\n
\n\n Run the test. No interaction required.\n
\n\n The test passes if all four sets of two rectangles are drawn and\n they match the reference image.\n
\n\n Test x, y, width, height, rx and ry default/lacuna values on a rect element.\n
\n\n Run the test. No interaction required.\n
\n\n There should be four green rectangles visible, two of them should have rounded corners.\n
\n\n Tests rx and ry clamping and aliasing.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if:\n
\n\n \'Rect\' elements with unspecified \'rx\' and \'ry\' attributes will use the specified \'rx\' and \'ry\' value if the other one is specified; if neither is specified, the \'rect\' has square edges. \n
\n\n Creates one \'rect\' element with an unspecified \'ry\'. Places it over a red \'rect\' element with both \'rx\' and \'ry\' specified. Repeat with unspecified \'rx\'. Finally creates a \'rect\' element that has neither \'rx\' or\n \'ry\' specified.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if the two shapes on top are rounded rectangles, the shape below has square corners, and no red is visible on the page.\n
\n\n The \'rect\' element defines a rect which is axis-aligned with the default user coordinate system when it is not the initial user coordinate system.\n
\n\n Draws a \'rect\' element originating at (0,0) of the current user coordinate system, which has been altered via \'transform\' from the\n initial user coordinate system. Draws perpendicular lines which also originate at (0,0) and advance along the x and y axes of the\n current user coordinate system. Verifies that the lines overlap the top and left edges of the rectangle and that the rectangle is\n thus axis-aligned with its current user coordinate system.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if the top and left of the rectangle is black while the right and bottom are orange, and the right half of the diamond is orange and the left half is black.\n
\n\n When \'rect\' attributes \'rx\' and \'ry\' have a value greater than half of the width/height of the rectangle, they are treated as half the width/height of the rectangle.\n
\n\n The test creates one \'rect\' element with \'rx\' greater than 1/2 the \'rect\' width. Underneath that element, it creates a red \'rect\' element with\n \'rx\' set to 1/2 the width. Repeats with \'ry\' attribute.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if there is no red visible on the page.\n
\n\n Checks that unspecified \'ry\' and \'rx\' attributes are copied from each other before their values are clamped.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if there is no red visible on the page.\n
\n\n Test to verify that the defs element is used as a container correctly.\n
\n\n In this test a fill is created which is solid green. The view should be a solid green rectangle\n centered in the viewport 100 pixels from from left,top and right,bottom. Also, in the\n defs sections there are rectangle defined, one to paint over the entire canvas with\n a red fill and the other to obscure most of the green rectangle.\n
\n\n The rendered picture should match the reference image, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n A green rectangle should be visible, and no red.\n
\n\n This is an empty SVG document. \n
\n\n Run the test. No interaction required.\n
\n\n Nothing should be rendered by the User Agent.\n
\n\n This test validates the use of the preserveAspectRatio attribute on the\n root svg element in an SVG Tiny document. In this document, preserveAspectRatio\n is set to none and the width and height of the document set to 100%.\n
\n\n The document\'s viewBox is defined to be 100 by 100 with an origin\n in (100, 100). The content is made of 2 red squares and 2\n orange circles.\n
\n\n Run the test. No interaction required.\n
\n\n Because preserveAspectRatio is set to \'none\', the content should\n appear distorted (if the aspect ratio is not 1): squares show as rectangles and circles show as\n ellipses.\n
\n\n This test validates the use of the preserveAspectRatio attribute on the\n root svg element in an SVG Tiny document. In this document, preserveAspectRatio\n is set to \'xMidYMid meet\' and the width and height of the document set to 100%.\n
\n\n The document\'s viewBox is defined to be 100 by 100 with an origin\n in (100, 100). The content is made of 2 red squares and 2\n orange circles.\n
\n\n Run the test. No interaction required.\n
\n\n Because preserveAspectRatio is set to \'xMidYMid meet\', the content should\n appear centered within the viewport: squares show as squares (and not\n rectangles) and circles show as circles (and not ellipses).\n
\n\n This test validates the operation of the svg element when there is no\n viewbox. \n
\n\n The document has x/y attributes set to (1000, 1000). Because \n x/y are ignored on the root svg element, the x/y origin should have no \n effect on the drawing.\n
\n\n The document contains squares and circles between the\n (100,100) and (200, 200) coordinates. \n
\nRun the test. No interaction required. If the test is run outside of the harness, the operator may resize the viewport.
\nThe rendered picture should match the reference image. Changing the viewport\n size should have no effect on the placement or scale of the document\'s content.
\n\n This test adds testing of some basic XML features SVG User Agents\n should support.\n
\n\n First, the test checks support for the default entities amp, lt, gt, apos\n and quot. This is what the first line shows in gray.\n
\n\n Second, the test checks support for hexadecimal and decimal character\n entities, as shown in the second line, again in gray\n
\n\n Finally, the last line shows usage of an entity defined in the\n document\'s internal DTD subset. The same geometry (a path) is\n reused twice, once filled in gray and ones stroked in gray.\n
\nRun the test. No interaction required.
\nThe test passes if the following conditions are met:
\n\n The test checks to see that graphics elements (g) can be nested and that the like attributes can be passed to the children.\n All the g elements for this test are in the g element whose id=allGs.\n
\n\n The test uses the \'rect\' element, as well as basic fill (solid primary colors),\n stroke (black 1-pixel lines), font-family and font-size properties.\n
\n\n The two blue rectangles and the yellow are in the g labeled rects.\n The blue rectangles inherit a fill color the green rect has a fill specified and it should not be overwritten.\n The two yellow rectangles should inherit the fill color and the transform attribute, they should be\n yellow and rotated at -20 degrees. These two rectangles are in g "yellowNrotate", that g is nested\n inside g "gratuitiousG". The black rectangle in the upper right, has no attributes inherited from its parent.\n The focus is nesting of g elements and passing on of attributes.\n
\n\n The rendered picture should match the reference image, except for possible\n variations in the labelling text (per CSS2 rules).\n
\n\n The purpose of this test is to check the nesting of SVG elements.\n
\n\n The test uses the \'rect\' element, as well as basic fill (solid primary colors),\n stroke (black 1-pixel lines), font-family and font-size properties.\n
\n\n There are 4 svg elements in the test.\n The first defines the outer square at 480x360.\n The second whose id is lowerRight defines a green rectangle which is 1/4 of the outer svg element.\n The third svg whose id is upperLeft defines a region that is the upper 1/4 of the outer svg,\n it is filled with a blue rectangle. It has a child svg element that defines an area\n half again the size of its parent but sharing the same center point, it is filled with a yellow rectangle.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if:\n
\n\n This test validates that properties are inherited (or not, depending on\n their defintion), from a group to its children.\n
\n\n [[\n Describe how to use the here. The instructions should specify any\n steps requied to run the test or any manual operation that need\n to be performed to run the test.\n ]]\n
\n\n The two rows displayed in this test should be identical. In the top row,\n each property is set to the value \'inherit\'. In the bottom row, which is\n the reference, each property is set to the value that should be inherited\n in the top row.\n
\n\n Test nested svg elements.\n
\n\n Run the test. No interaction required.\n
\n\n Passed if there are two green rectangles visible, and no red.\n
\n\n The purpose of the symbol test case is to create some symbols and then\n have them rendered when instantiated by the use element.\n
\n\n This file contains 3 symbol definitions. Only two are ever rendered.\n There is a viewport defined to be 0,0,1000,1000 on the svg element.\n Each symbol has is own viewport of the same dimensions. The symbols are\n scaled when they are instantiated by the use element, The first set\n of symbols is 4 squares, blue and yellow in color they should appear\n in the lower right of the view arranged in a checkerboard fashion.\n The second symbol to be used is an image which should appear in the\n upper left of the view area. The symbol that is not used and should\n not be rendered is a large black rectangle. If the symbols don\'t\n appear, there is something askew with the use statement, if they\n appear but either overlap each other or in some way aren\'t in the\n correct positions they have not honored either their viewport or\n were not scaled when placed by the use element in the area defined by\n it. If everything is black then perhaps a symbol was rendered that\n should not have been.\n
\n\n Run the test. No interaction required.\n
\nThe test passes if:
\n\n The purpose of this test is to validate proper handling of\n the use element. In particular, the test checks the proper inheritance\n of properties through the shadow tree (rather than through the document\n tree).\n
\n\n Run the test. No interaction required.\n
\n\n The test should display various elements in different shades of green.\n If an element is not displayed in green, but in red fill and/or yellow\n stroke, then it is in error.\n
\n\n The purpose of this test is to validate proper handling of\n the x/y attributes on the use element.\n
\n\n The test shows a <use> element displayed on the right.\n On the left, a group built as described in section\n 5.6 of the SVG 1.1 specification validates that the\n <use element is properly processed.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if there are two identical diamond shapes visible.\n
\n\n This tests the use element inside a symbol definition.\n
\nRun the test. No interaction required.
\n\n For the test to pass, 5 nested rectangles with different coloured strokes\n (black, yellow, orange, purple and blue) must be rendered.\n
\n\n Tests that recursive \'use\' instances do not block rendering.\n
\n\n Various scenarios that directly and indirectly create circular references via the \'use\' tag. A \'g\' element is used when \n structural elements are necessary. None of the \'use\' scenarios render anything. \'useLongCycle\' tests a chain of recursive \n \'use\' instances that eventually cycles back to the first element. In \'useNested\' \'use\' elements are nested, with the child \n referring to the parent. In \'useNestedGroup\' a \'use\' instance references a parent \'g\' element. In \'useIndirectNestedGroup\' \n a \'use\' instance indirectly references its own parent \'g\'. In \'useMultipleIndirectNestedGroup\', two \'use\' instances \n reference their parent \'g\' elements, and additional \'use\' instances refer to these self-referencing \'use\' elements. A green \n \'rect\' is used to verify that rendering was processed up to that point.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if there is green visible on the page.\n
\n\n Verify property inheritance as required by 6.15 "Property\n inheritance". Since all implementations are required to do this, only\n presentation attributes are used.\n
\n\nRun the test. No interaction required.\n
\n\n At the center right, there is an ellipse. The fill color is not\n specified on that element but on its parent. The ellipse should be filled a solid yellow\n
\n\n At the top left, an oval shape is formed from a rectangle\n with a radial gradient. The color of the middle stop uses the keyword \'inherit\'\n and thus takes its parent\'s value of green, giving a yellow, green, white gradient.\n
\n\n At the bottom left, an oval shape is formed from a rectangle\n with a radial gradient. The color of the middle stop uses the value \'currentColor\'\n and thus takes the value its parent\'s color property, a dark red,\n giving a yellow, dark red, white gradient.\n
\n\n Tests that !important in a presentation attribute is an unsupported value\n
\n\n A fill attribute is set to red with !important. This is an unsupported attribute value,\n consequently the fill attribute should be the lacuna value, which is black. Therefore, to pass, the rectangle should be filled with black.\n
\nA lime green border is also drawn, to check that rendering continues after the element with the unsupported value.
\n\n Run the test. No interaction required.\n
\n\n The rectangle should be filled with black, with a lime green border.\n
\n\n Test \'text-anchor\' property (horizontal).\n
\n\n The three lines test the three values for property \'text-anchor\': start, middle and end.\n
\n\n Run the test. No interaction required.\n
\n\n The lines in pink, \'text-anchor:none\' and \'text-anchor:start\', should both start from the same horizontal position (indicated by the black circle on each line) and extend to the right.\n The green line, \'text-anchor:middle\', should be centered horizontally around the black circle.\n The blue line, \'text-anchor:end\', should be aligned such that the end of the text meets the black circle.\n
\n\n Test the \'baseline-shift\' property (horizontal).\n
\n\n Run the test. No interaction required.\n
\n\n This three lines test property \'baseline-shift\'.\n The first line tests \'baseline-shift:7\' (i.e., a length for \'baseline-shift\').\n The pink text should be shifted upwards by an amount approximately half of the height of the text.\n The second line tests \'baseline-shift:-70%\' (i.e., a percentage for \'baseline-shift\').\n The pink text should shift downward by about the height of the text.\n The third line tests the three keywords \'sub\', \'super\' and \'normal\'.\n The string "sub" should be shifted downwards, the string "super" shifted upwards,\n and the string "te" (in blue) aligned with the remainder of the text in the line.\n
\n\n Test for viewer capibility to handle the basics of the \'textAnchor\'\n alignment property for \'text\' and related elements.\n
\n\n This test verify that\n the interpreter correctly handles and applies the text-anchor\n properties when present on "chunks", which are comprised of tspan elements\n with absolute positioning, within the containing \'text\' element.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if\n
\n\n Test for viewer capibility to handle the basics of the \'text-anchor\'\n alignment property for \'text\' and related elements.\n
\n\n The second group from the top contains sub-tests to verify that the\n interpreter handles text-anchor when the text is comprised of other\n text related elements, \'tspan\', \'tref\', and \'textPath\'.\n The text-anchor property is present on the containing \'text\' element\n in these cases, not on the contained child elements.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if:\n
\n\n Test \'text-anchor\' property (vertical).\n
\n\n This tests the three values for property \'text-anchor\': start, middle and end.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if three vertical lines of text are displayed with\n each line containing a single black dot.\n
\n\n Tests various ways that the \'baseline-shift\' property (vertical) can be\n altered.\n
\n\n The first sub test sets the \'baseline-shift\' to an absolute unit. The\n second sub test sets the \'baseline-shift\' to a percentage. The third sub\n test sets the \'baseline-shift\' to "sub". The fourth sub test sets the\n \'baseline-shift\' to "super".\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if four lines of vertical text are rendered.\n
\nISSUE - http://www.w3.org/2011/02/27-svg-irc#T22-20-51
\n\n Test horizontal baselines across script and font size changes.\n
\n\n Original test authored by Rodney Hardy at CISRA and modified by\n Anthony Grasso. \n
\n\n Run the test. No interaction required.\n
\n\n The dominant baseline should be alphabetic, so the \'a\' will be sitting\n on the blue line, the Japanese character \'犜\' will be on the ideographic baseline\n and \'ण\' is a Devangari character and will use the hanging baseline. The\n smaller versions of the characters should be aligned to the same baselines.\n So the \'a\'s on the blue line, the Japanese characters slightly below the line\n and the Devangari characters should be hanging from the hanging baseline.\n
\nISSUE - http://www.w3.org/2011/02/27-svg-irc#T22-20-51
\n\n Test horizontal baselines across script and font size changes. It uses an SVG Font, where\n the Latin letter "a" is a rectangle, the Japanese letter "犜" is an upward-pointing triangle,\n and the Devanagari letter "ण" is a downward-pointing triangle.\n
\n\n Original test authored by Rodney Hardy at CISRA.\n
\n\n Run the test. No interaction required.\n
\n\n The dominant baseline should be alphabetic, so the \'a\' will be sitting on the alphabetic (blue) line,\n the Japanese glyph (upward pointing triangle) will be aligned on the ideographic (pink) baseline\n and \'ण\' is a Devangari character (downward pointing triangle) and will use the hanging baseline (green).\n The smaller versions of the characters should be aligned to the same baselines as the respective larger\n characters, so all like shapes align to the same baseline.\n
\n\n Test directional type, ltr context, arabic.\n Assertion: In a left-to-right context, without markup, styling or special characters, a sequence of Arabic characters and spaces will progress from right to left.\n
\nYou will need a font that allows you to distinguish Arabic characters.
\n\n Run the test. No interaction required.\n
\n\n Test passes if the characters follow the same order.\n
\n\n Test the \'text-decoration\' property.\n
\n\n Run the test. No interaction required.\n
\nThe test has passed if:
\n\n Purpose of test is to determine if the font family is being\n correctly selected. The top two lines of text test serif fonts;\n the top line in maroon tests the generic font family \'serif\'\n and the second line in black tests a selection of commonly\n available named serif fonts. The next two lines of text test\n sans-serif fonts;\n the top line in maroon tests the generic font family \'sans-serif\'\n and the second line in black tests a selection of commonly\n available named sans serif fonts. The following two lines\n of text test monospaced fonts;\n the top line in maroon tests the generic font family \'monospaced\'\n and the second line in black tests a selection of commonly\n available named monospaced fonts. The lowercase \'i\' and uppercase\'W\'\n should be the same width,for monospaced fonts.\n
\n\n The seventh line of text, in green, tests for\n three non-existent fonts (nonsense names). There is no fallback\n generic font specified. The text must be displayed anyway.\n
\n\n Run the test. No interaction required.\n
\n\n The first six lines contain two Japanese characters (画像)\n at the end of the line. Both of these characters must be displayed,\n although it is compliant to display them with the \'missing glyph\'\n if no suitable font containing Japanese characters can be found.\n Most but not all fonts have a visible missing glyph character.\n If the selected font has a visible missing glyph character, it should appear\n wherever the corresponding glyph is not available.\n
\n\n Purpose of test is to determine if the font weight is being\n correctly rendered. A number of font families are specified. The\n numerical weight values (100 to 900) should show the lighter weights\n on the lower numbers and the heavier weights on the larger numbers.\n Heavier is defined to mean \'no lighter\'.\n
\n\n If only one font weight is available, they should all display at the\n same weight. The transition from black to green figures shows the\n correct light to bold transition for the common case where two\n weights are available. If three or more weights are available, see\n the CSS2 specification for how these are allocated to the nine\n weight numbers.\n
\n\n The absolute keywords \'normal\' and bold\' are tested\n by the first two lines on the right hand side of the test,\n the third line of text tests the to \'bolder\'\n relative keyword and the fourth tests the\n \'lighter\' relative keyword.\n
\n\n Run the test. No interaction required.\n
\n\n The numerical weight values (100 to 900) should show the lighter weights on the\n lower numbers and the heavier weights on the larger numbers. Heavier is defined\n to mean \'no lighter\'.\n
\n\n Testing font-family attribute.\n Two SVG fonts are defined. Various text elements are then\n used with varying values for the font-family attribute.\n
\n\n Run the test. No interaction required.\n
\n\n The first two text elements should display in their respective fonts,\n the last two should be displayed using the system font since the\n value specified for font-family is either invalid or not specified.\n
\n\n Testing font-family attribute.\n Various text elements are\n used with varying values for the font-family attribute.\n
\n\n Run the test. No interaction required.\n
\n\n The first two text elements should display in their respective fonts,\n Haettenschweiler and\n Charlesworth,\n if they are installed on the target system. Otherwise, simply\n displaying the text in some fallback font is enough to pass the test.\n The last two should be displayed using a fallback font since the\n value specified for font-family is either invalid or not specified.\n Failing to display the text means the test is not passed.\n
\n\n Test that the \'line-height\' property has no effect on text layout.\n
\n\n Run the test. No interaction required.\n
\n\n Test passes if the three blue instances of \'Filler Text\' all have the same vertical position on the page.\n
\n\n This tests the \'font-weight\' property when multiple weights are available. A\n font family with six weights is specified, with a fallback to \'serif\'.\n
\n\n If only one font weight is available, they should all display at the same weight.\n The transition from black to green figures shows the correct light to bold transition\n for the common case where two weights are available. If three or more weights are\n available, see the CSS2 specification for how these are allocated to the nine weight\n numbers. The specified font has six weights.\n
\n\n The absolute keywords \'normal\' and bold\' are tested by the first two lines on the\n right hand side of the test, the third line of text tests the to \'bolder\' relative\n keyword and the fourth tests the \'lighter\' relative keyword.\n
\n\n If the platform supports installable opentype fonts, please download and install\n Zalamander Caps\n by Tim Ahrens of Just Another Foundry.\n Then, view this test.\n
\n\n The numerical weight values (100 to 900) should show the lighter weights on the\n lower numbers and the heavier weights on the larger numbers. Heavier is defined\n to mean \'no lighter\'.\n
\n\n This tests the \'font-weight\' property when multiple weights are available. A\n font family with five weights is specified, with a fallback to \'serif\'.\n
\n\n The specified font family has five weights - 300, 400, 600, 700 and 800. \n See the CSS3 Font specification \n for how these are allocated to the nine weight numbers.\n
\n\n The absolute keywords \'normal\' and bold\' are tested by the first two lines on the\n right hand side of the test, the third line of text tests the to \'bolder\' relative\n keyword and the fourth tests the \'lighter\' relative keyword.\n
\nThe fonts are SVG fonts convertted, with the author\'s explicit permission, \n from Zalamander Caps\n by Tim Ahrens of Just Another Foundry.\n An ASCII subset has been generated for this test. The font names have been \n obfuscated, to deter \n user agent sniffing for keywords like "Ultrabold". All weights in this generated\n family are multiples of 100 and greater or equal to 300.
\n\n Run the test. No interaction required.\n
\n\n The numerical weight values (100 to 900) should show the lighter weights on the\n lower numbers and the heavier weights on the larger numbers. Heavier is defined\n to mean \'no lighter\'.\n
\n\n This tests the \'font-weight\' property when multiple weights are available. A\n font family with five weights is specified, with a fallback to \'serif\'.\n
\n\n The specified font family has five weights - 300, 400, 600, 700 and 800. \n See the CSS3 Font specification \n for how these are allocated to the nine weight numbers.\n
\n\n The absolute keywords \'normal\' and bold\' are tested by the first two lines on the\n right hand side of the test, the third line of text tests the to \'bolder\' relative\n keyword and the fourth tests the \'lighter\' relative keyword.\n
\nThe fonts are WOFF fonts convertted, with the author\'s explicit permission, \n from Zalamander Caps\n by Tim Ahrens of Just Another Foundry.\n The font names have been obfuscated, to deter \n user agent sniffing for keywords like "Ultrabold". All weights in this generated\n family are multiples of 100 and greater or equal to 300.
\n\n Run the test. No interaction required.\n
\n\n The numerical weight values (100 to 900) should show the lighter weights on the\n lower numbers and the heavier weights on the larger numbers. Heavier is defined\n to mean \'no lighter\'.\n
\n\n Test left-to-right aspect of internationalized text.\n
\n\n Various text strings in various languages appear. The main\n purpose of the test is to verify that the correct characters\n appear and that they appear in the correct order and orientation, even\n though the first choice font does not have the right glyphs.\n
\n\n Run the test. No interaction required.\n
\n\n Correct rendering requires that each character is rendered. It may be rendered\n with the \'missing glyph\' if no\n glyphs are found in the fonts listed in the content, or in any fallback font\n that is available. The first choice font\n is a special SVG font that only contains the \'missing glyph\'. Missing glyph from\n other fonts may conformantly be used, however.\n
\n\n The test is passed if the lines of text appear as follows:\n
\n\n Test various aspects of internationalized text, including\n left-to-right, right-to-left, and the\n following properties: \'writing-mode\',\n \'direction\' and \'unicode-bidi\'.\n
\n\n Various text strings in various languages appear. Ttest of bidi algorithms and support of \'unicode-bidi\' and\n \'direction\' properties.\n
\n\n This test requires installation of a system font that supports\n the various international characters used in this test case. A\n suitable font should be used by the SVG renderer if none of the\n specified font families are available (or if they are available but do\n not have the required glyphs). \n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if the correct characters\n appear and they appear in the correct order and orientation.\n Ensure that the three lines with Hebrew are ordered\n correctly, as shown in the reference image.\n
\n\n Test top-to-bottom internationalized text and the\n following properties: \'writing-mode\',\n \'glyph-orientation-vertical\', \'glyph-orientation-horizontal\'.\n
\n\n Various text strings in various languages appear. The main\n purpose of the test is to verify that the correct characters\n appear and that they appear in the correct order and orientation.\n Ensure that the two lines of\n vertical Japanese text have the proper orientation\n (test of \'glyph-orientation-vertical\' property).\n
\n\n This test requires installation of a system font that supports\n the various international characters used in this test case. A\n suitable font should be used by the SVG renderer if none of the\n specified font families are available (or if they are available but do\n not have the required glyphs). To\n minimize system dependencies, a future version of this test\n might include all necessary glyphs as an SVG font.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if first line of text has the english text "Text" and\n "in Chinese" rotated 270 degrees and the Chinese text displayed top to\n bottom. The second line of text has the english text "Japanese:" rotated\n 270 degrees and the Japanese text displayed top to bottom. The third\n line of text has the letters in the english text "Japanese:" displayed\n vertically and the Japanese text displayed top to bottom.\n
\n\n Test basic aspect of internationalized text.\n
\n\n Various text strings in various languages appear. The main\n purpose of the test is to verify that the correct characters\n appear and that they appear in the correct order and orientation.\n
\n\n A future version of this test\n might include all necessary glyphs as an SVG font.\n
\n\n Run the test. No interaction required.\n
\n\n Correct rendering requires that each character is rendered. It is not required that a given character\n be rendered with any particular font; just that it is rendered.\n It may be rendered with the \'missing glyph\' if no\n glyphs are found in the fonts listed in the content, or in any fallback font that is available.\n
\n\n Tests Arabic text using various platform fonts. If these fonts are not available,\n a fallback font should be used that has Arabic glyphs. If such a font is not available,\n the \'missing glyph\' (typically an open rectangle) should be displayed. It is an error\n to display the wrong Arabic glyphs, for example to display all isolate forms.\n
\n\n Run the test. No interaction required.\n
\n\n The text should be positioned such that the begining of the start of the\n Arabic text is at very right of the test and runs towards the left of\n the test border.\n
\n\n This test ensures that mandatory ligatures in Arabic are displayed.\n This test uses WOFF fonts for rendering, with platform fonts for fallback.\n
\n\n There are two subtests. The first\n requires an isolate lam-alef ligature and the second requires\n a right-joining lam-alef ligature.\n
\n\n The first subtest has the word for \'tools\', آلات\n 0622: آ ARABIC LETTER ALEF WITH MADDA ABOVE\n 0644: ل ARABIC LETTER LAM\n 0627: ا ARABIC LETTER ALEF\n 062A: ت ARABIC LETTER TEH\n
\n\n The second subtest has the word for \'three\', ثلاثة\n 062B: ث ARABIC LETTER THEH\n 0644: ل ARABIC LETTER LAM\n 0627: ا ARABIC LETTER ALEF\n 062B: ث ARABIC LETTER THEH\n 0629: ة ARABIC LETTER TEH MARBUTA\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if subtests are displayed as following:\n
\nIn the first subtest, there must be an isolate lam-alef ligature \n and in the second subtest there must be a right-joining lam-alef \n ligature, (so that them, lam and alef are all connected), as in the reference image.\n
\nThe precise glyph shapes will depend on which font was used for rendering,\n and do not affect the pass criteria. Only the presence of the \n mandatory ligatures is tested here.
\nThis test ensures that mandatory ligatures in Arabic are displayed.
\n\n There are two subtests. The first requires an isolate lam-alef ligature\n and the second requires a right-joining lam-alef ligature.\n
\nRun the test. No interaction required.
\n\n The test is passed if subtests are displayed as following:\n
\n\n Test various aspects of internationalized text, including\n left-to-right, right-to-left, and the\n following properties: \'writing-mode\',\n \'direction\' and \'unicode-bidi\'.\n
\n\n Various text strings in various languages appear. Test of bidi algorithms and support of \'unicode-bidi\' and\n \'direction\' properties. Uses Webfonts.\n
\n\n This test uses Webfonts; both SVG and WOFF fonts are provided.\n
\n\n Run the test. No interaction required. Make sure scripting is enabled.\n
\n\n The test is passed if the correct characters\n appear and they appear in the correct order and orientation.\n Ensure that the three lines with Hebrew are ordered\n correctly, as shown in the reference image.\n
\n\n Tests Arabic text using various platform fonts. If these fonts are not available,\n a fallback font should be used that has Arabic glyphs. If such a font is not available,\n the \'missing glyph\' (typically an open rectangle) should be displayed. It is an error\n to display the wrong Arabic glyphs, for example to display all isolate forms.\n
\nThis test uses writing-mode and direction to set the text as right-to-left.
\n\n Run the test. No interaction required.\n
\n\n The text should be positioned such that the begining of the start of the\n Arabic text is at very right of the test and runs towards the left of\n the test border.\n
\n\n This test ensures that mandatory ligatures in Arabic are displayed.\n Three values for text-anchor are also tested;\n middle,\n start and\n end.\n This test uses platform fonts for rendering.\n
\n\n There are two subtests. The first\n requires an isolate lam-alef ligature and the second requires\n a right-joining lam-alef ligature.\n
\n\n The first subtest has the word for \'tools\', آلات\n 0622: آ ARABIC LETTER ALEF WITH MADDA ABOVE\n 0644: ل ARABIC LETTER LAM\n 0627: ا ARABIC LETTER ALEF\n 062A: ت ARABIC LETTER TEH\n
\n\n The second subtest has the word for \'three\', ثلاثة\n 062B: ث ARABIC LETTER THEH\n 0644: ل ARABIC LETTER LAM\n 0627: ا ARABIC LETTER ALEF\n 062B: ث ARABIC LETTER THEH\n 0629: ة ARABIC LETTER TEH MARBUTA\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if the blue glyphs آ and ث touch the first vertical\n line. The second vertical line falls in middle of the brown glyphs\n inbetween آلا and ت and inbetween ثلا and ثة. The black glyphs ت and ة\n touch the last vertical line.\n
\n\n This test ensures that mandatory ligatures in Arabic are displayed.\n This test uses downloaded WOFF fonts for rendering.\n
\n\n There are two subtests. The first\n requires an isolate lam-alef ligature and the second requires\n a right-joining lam-alef ligature.\n
\n\n The first subtest has the word for \'tools\', آلات\n 0622: آ ARABIC LETTER ALEF WITH MADDA ABOVE\n 0644: ل ARABIC LETTER LAM\n 0627: ا ARABIC LETTER ALEF\n 062A: ت ARABIC LETTER TEH\n
\n\n The second subtest has the word for \'three\', ثلاثة\n 062B: ث ARABIC LETTER THEH\n 0644: ل ARABIC LETTER LAM\n 0627: ا ARABIC LETTER ALEF\n 062B: ث ARABIC LETTER THEH\n 0629: ة ARABIC LETTER TEH MARBUTA\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if subtests are displayed as following:\n
\nIn the first subtest, there must be an isolate lam-alef ligature \n and in the second subtest there must be a right-joining lam-alef \n ligature, as in the reference image.\n
\n\n Test textPath element in combination with the tspan element. Properties\n of the text on a path are changed using the tspan element.\n
\n\n Run the test. No interaction required. Make sure scripting is enabled.\n
\n\n For this test to pass the rendered output must match the reference\n image. The letters "Te" in first "Text on a path" sentence must be\n colored pink and offset from the path in the y direction.\n
\n\n This tests the \'textPath/startOffset\' with both negative and positive values, and\n compares it to the case where a \'tspan/dx\' attribute is used with the same values.\n
\n\n Run the test. No interaction required. Make sure scripting is enabled.\n
\n\n You should see four paths with text following each path.\n The top two paths should show the text "Negative offset", and the bottom two paths should show the text\n "Positive offset".\n
\n\n The test has passed if:\n
\n\n Test properties \'letter-spacing\' and \'word-spacing\'\n
\n\n The first three lines test property \'letter-spacing\', with\n values 0, -1 and .3em respectively.\n
\n\n The next three lines test property \'word-spacing\', with\n values 0, -3 and 3em respectively.\n
\n\n Run the test. No interaction required.\n
\n\n This test is passed if:\n
\n\n Test viewer capibility to handle basic use of \'textLength\'\n and \'lengthAdjust\' attributes.\n
\n\n There are four pairs of sub-tests. Each pair of sub-tests consists\n of the same two strings: "Line to Stretch" on the left, and "this is\n a line to squeeze" on the right.\n
\n\n The first (topmost) pair contains no occurrences of the textLength and\n lengthAdjust attributes in the \'text\' elements.\n The pink reference line under each of the top\n two strings indicates the approximate length of the strings. Since\n the lengths are not constrained by the \'textLength\' attribute, small\n variations of the lengths are permissible.\n
\n\n The remaining three pairs each applies \'textLength\' attributes to the\n strings. In the leftmost sub-test of each pair, the \'textLength\' value\n will cause a stretching of the string of approximately 25% over the\n "normal" length. In the rightmost sub-test of each pair, the \'textLength\' value\n will cause a squeezing of the string of approximately 20% under the\n "normal" length for the string.\n
\n\n In each of the sub-tests with an application of \'textLength\', the\n pink reference lines indicate the exact extent of the rendered text.\n The rendered text should fit snugly just within the ticks at the end of\n the pink lines.\n
\n\n The second pair from the top contains \'textLength\' but no \'lengthAdjust\'\n attributes. In this case, the effect should be as if the value "spacing"\n were specified. Only the inter-character advancement and inter-word spacing\n should change. The aspect ratio of the glyphs should be unaffected. The\n reference image illustrates one valid way to achieve this, by a\n uniform increase or decrease of inter-character advancement.\n
\n\n The third pair from the top explicitly sets \'lengthAdjust\' value\n to "spacing". Therefore it should be rendered identically to the second pair.\n
\n\n The fourth (bottommost) sub-test pair explicitly sets \'lengthAdjust\' value\n to "spacingAndGlyphs". The advancements between characters and words, as well as\n the glyph aspect ratios should be affected.\n The reference image illustrates one valid way to achieve\n this, by a uniform expansion or compression of the string as a whole.\n This effect is equivalent to application of a "scale(xfactor, 1.0)" transformation\n to the \'text\' elements.\n
\n\n Run the test. No interaction required.\n
\n\n The rendered picture should match the reference image, except as noted in the Test Description.\n In particular, the \'textLength\' constraint must be satisfied precisely,\n and the basic rules associated with the "spacing" and "spacingAndGlyphs" values\n of \'lengthAdjust\' must be met, but the precise algorithm for meeting all\n of the required contraints is otherwise unspecified.\n
\n\n Test text element, tspan element and various text decorations\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if:\n
\n\n The purpose of this test is to validate proper handling of\n the text element\'s x and y attributes.\n In the various samples, a orange marker shows the text\'s (0,0)\n coordinate. The blue markers show the current text positions.\n These are either defined by absolute x/y positioning or they\n are computed from the embeded font\'s glyphs advances.\n
\n\n The first text sample shows a reference piece of text.\n
\n\n The second text sample (x all) shows a piece of text where\n all the glyphs are positioned along the x axis.\n
\n\n The third text sample (x more) is a text element where there\n are more x values than characters (5 values for 4 characters).\n The last x value should be ignored and the result should\n be the same as the third sample.\n
\n\n The fourth text sample (x fewer) is a text element where there\n are fewer x values than characters (3 values for 4 characters).\n The last character should not be positioned but laid out normally,\n following its previous character sibling.\n
\n\n The fifth (y all), sixth (y more) and seventh (y fewer) text sample\n parallel the second,\n third and fourth test, but for the y attribute values.\n
\n\n The samples in the right column show combinations of x/y\n value sets.\n
\n\n Run the test. No interaction required.\n
\n\n In all the above tests, blue markers represent the expected glyph\n positions. The orange markers are showing positions where no glyph\n should appear. The glyphs are black squares of increasing sizes.\n
\n\n The purpose of this test is to validate the interaction of text-anchor\n and x/y glyph positioning.\n
\n\n Each row shows a different combination of x/y values: 1, more than characters,\n fewer than characters. This tests the anchor value: start.\n
\n\n The blue markers show the various x/y absolute positions around which text\n chunks should be anchored. The glyphs are black squares of increasing sizes.\n
\n\n Run the test. No interaction required.\n
\n\n Rendered output must match the reference image for the test to pass.\n
\n\n The purpose of this test is to validate the interaction of x/y\n glyph positioning and ligatures.\n
\n\n The first line shows an example where there is a ligature (fi) which\n should be accounted for before breaking into text chunks (see specification\n section 10.5, additional x/y/dx/dy processing rules, bullet discussing\n ligatures). In this first line, the ligatures cause the x position 180\n (shown in orange), to be ignored. As a result, a glyph should be shown over\n each pale blue square markers. The glyphs are black squares of increasing sizes\n except for the initial ligature which has the form of two small black triangles\n joined at their tops. The ligature should show on the first pale blue\n marker position.\n
\n\n The second line shows the same test but using multiple y positions.\n
\n\n The third line shows the same test but using multiple x and y\n positions.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if:\n
\n\n Tests multiple x, y, rotate, with various combinations. Since an\n array of values is given, each glyph must use the value from the\n corresponding character in the list.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if:\n
\n\n The three opacity properties (fill-opacity,\n stroke-opacity, and opacity) of \'text\' elements are\n covered in this test.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if:\n
\n\n Tests multiple x, y, rotate, with various combinations. Since an\n array of values is given, each glyph must use the value from the\n corresponding character in the list. In this test, there are less values\n in the array than there are characters.\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if:\n
\n\n Test rendering of text rotated by a transform attribute.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if the image shows text rotated by various different angles, the result should closely match the reference image.\n
\n\n Test rendering of text rotated by a transform attribute, same as the text-text-10-t test but not using an SVGFont.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if the image shows text rotated by various different angles, the result should closely match the reference image, but note that the font is allowed\n be different from the font used in the reference image.\n
\nISSUE: the glyphs don\'t cover the entire em-cell, and the spec doesn\'t require visual alignment - text adjustments are based on advances
\n\n The purpose of this test is to validate the interaction of text-anchor\n and x/y glyph positioning.\n
\n\n Each row shows a different combination of x/y values: 1, more than characters,\n fewer than characters. Each column shows different anchor values: middle\n and end.\n
\n\n The blue markers show the various x/y absolute positions around which text\n chunks should be anchored. The glyphs are black squares of increasing sizes.\n
\n\n Run the test. No interaction required.\n
\n\n Rendered output must match the reference image for the test to pass.\n
\n\n Test tspan element styling and relative position adjustments.\n
\n\n Run the test. No interaction required.\n
\n\n The test has passed if:\n
\n\n Tests the rotate attribute in the tspan element.\n
\n\n Run the test. No interaction required.\n
\n\n For this test to pass the text "Not all characters in the text have a\n specified rotation" must be displayed in green without any red showing.\n If any red shows the test is a fail.\n
\n\n Rotation values:\n
\n\n Test for viewer correct handling of whitespace and the \'xml:space\' attribute.\n There are two sub-tests, for xml:space value "default".\n In each test, the content of the \'text\' element is written on\n multiple lines. The first test of each pair has indented text with leading\n space characters, tabs, etc. The second has no indentation, but a line break\n before the content and after it. There are no space (or other whitespace)\n characters at the ends of the lines.\n
\n\n The two test cases are self-descriptive. From the top;\n first, "default" value applied to 3 lines of content with indents, space characters, tabs, etc;\n second, "default" applied to two lines content with no indent;\n
\n\n Run the test. No interaction required.\n
\n\n In each test, the test string is in blue and the reference\n image is in black.\n The rendered picture should approximately match the reference image,\n however there is some question in the reference image concerning the\n exact amount of space in the long-space areas. The third test uses the nbsp unicode character\n to force the reference white spaces display, which provides an accurate match if the font in use\n has the same metrics for that character and the default white space.\n Also, variations are possible in the text fonts and layout (per CSS2 rules).\n
\n\n The test also uses the \'rect\' element,\n as well as basic fill (solid primary colors),\n stroke (black 1-pixel lines), font-family (Arial)\n and font-size properties.\n
\n\n Test for viewer correct handling of whitespace and the \'xml:space\' attribute.\n There are two sub-tests, for value "preserve".\n In each test, the content of the \'text\' element is written on\n multiple lines. The first test of each pair has indented text with leading\n space characters, tabs, etc. The second has no indentation, but a line break\n before the content and after it. There are no space (or other whitespace)\n characters at the ends of the lines.\n
\n\n The two test cases are self-descriptive. From the top;\n first, "preserve" applied to essentially the same content as first;\n second, "preserve" applied to essentially the same content as second.\n
\n\n Run the test. No interaction required.\n
\n\n In each test, the test string is in blue and the reference\n image is in black.\n The rendered picture should approximately match the reference image,\n however there is some question in the reference image concerning the\n exact amount of space in the long-space areas. The third test uses the nbsp unicode character\n to force the reference white spaces display, which provides an accurate match if the font in use\n has the same metrics for that character and the default white space.\n Also, variations are possible in the text fonts and layout (per CSS2 rules).\n
\n\n The test also uses the \'rect\' element,\n as well as basic fill (solid primary colors),\n stroke (black 1-pixel lines), font-family\n and font-size properties.\n
\n\n This tests that an \'xml:space\' attribute on a text element child\n will be honored.\n
\n\n Run the test. No interaction required.\n
\n\n After loading the test, four blue text strings and\n four orange text strings should be presented.\n
\n\n The test is passed if all four blue text strings appear\n identical (with a large space between the "b" and the "c"\n on each line), and all four orange text strings appear\n identical (with a small space between the "b" and the "c"\n on each line).\n
\n\n Tests scientific notation in attribute values; in particular, that numbers \n of the form .n with a leading decimal point, are supported\n
\n\n Run the test. No interaction required.\n
\n\n The test is passed if all the coloured rectangles are of the same height \n and line up with each other and \n with the grey marker lines. If any red is visible, the test fails.\n
\n