TestCoverage/C-Implementation-Requirements

From SVG

This page is an archive of the previous Group's wiki from http://www.w3.org/Graphics/SVG/Group/wiki.


Test coverage for SVG Tiny 1.2 Appendix C: Implementation Requirements

[1]

Legend:

 - is a comment or note
  is an assertion or feature that is fully covered in the test suite
 # is an assertion or feature that is partially or not covered in the test suite

C.1 Introduction

- Nothing to test.

C.2 Unsupported elements, attributes, properties, attribute values and property values

imp-unsup-*

# Within an SVG document fragment, any subtree that is rooted by an unknown element (including those in the SVG or XML Events namespaces) or a known element that occurs in unexpected location, is not rendered.
 - imp-unsup-201-t.svg test has some renderable content which is a child of
  • foo in foo NS
  • g in foo NS
  • foo in SVG NS
  • linearGradient (unexpected), in svg NS
  • foo in XMLEvents NS. Test is passed if none of it renders.


# The nodes in the subtree are not processed beyond including the relevant DOM objects in the document tree. Those DOM objects will still implement the DOM interfaces appropriate for the element type, however.
 - imp-unsup-202-t.svg similar test as above, with multiple 'unknown or unexpected' parents and some children in the SVG NS. Test checks that the expected methods are known.


# For known elements in the SVG or XML Events namespaces, unknown attributes that have no namespace and known attributes with unsupported values are treated as if they hadn't been specified when rendering. Unsupported values are defined in the definitions section.
 - imp-unsup-203-t.svg test unknown attrs in no namespace. Passed if there is no effect on rendering and no error.
 - imp-unsup-204-t.svg test known attrs in no namespace. Passed if there is no effect on rendering, any default rendering is used (same  as not specifying it) and no error. Best to have pairs of subtests, one with no attr and one with an attr with unsupported value. This might need two tests to avoid being crowded, so reserve imp-unsup-205-t.svg as well.
 - imp-unsup-206-t.svg tests inherited properties with unsupported values where the parent has a supported value (like the example in the spec).
 - unknown global attrs (ie, they have a ns) are not covered by the spec. They should be, and should be the same as unknown attrs in no ns.


# Attributes put in the SVG namespace on any element are processed as unknown attributes.
 - imp-unsup-207-t.svg test unknown attrs in SVG namespace. Passed if there is no effect on rendering and no error


# For unknown attributes in the XLink or XML Events namespaces, or known attributes in the XLink or XML Events namespaces with unsupported values, the user agent must process the element with regards to, respectively, linking or event handling, as if the attributes had not been specified.
 - imp-unsup-208-t.svg copy an XLink test and sprinkle with unknown attrs and known attrs with unsupported values.
 - imp-unsup-209-t.svg copy an XML Events test and sprinkle with unknown attrs and known attrs with unsupported values.


# The user agent must not stop processing or rendering under any of the above situations, but at user option it may alert, log, or otherwise provide a notification that unsupported content was encountered.
 - The 'not stop processing' is covered by earlier tests, and the 'may' is not testable.

C.3 Error processing

imp-error-*

# There are various scenarios where an SVG document fragment  must be considered technically in error:
[...]
When a document is in error the SVG User Agent must provide a highly perceivable indication of error. 
When the content is not well-formed according to the version of XML used (either the XML 1.0 [XML10] or XML 1.1 specifications [XML11])
 - imp-error-201-t.svg non-well-formed XML 1.0. Test is passed if its displayed up to the error, not displayed after the error, and a highly perceivable indication is given. NOTE that this test will need to be exempted from the svg to svggen processing and processed manually, because the wf error will prevent normal processing.
 - imp-error-202-t.svg same as 201 but XML 1.1


# When the content is not namespace-well-formed according to the Namespaces in XML 1.0 specification [XML-NS10] or the Namespaces in XML 1.1 specification [XML-NS11] (depending on the version of XML used as per the previous bullet).
 - imp-error-203-t.svg non-NS-well-formed XML 1.0. Test is passed if its displayed up to the error, not displayed after the error, and a highly perceivable indication is given.
 - imp-error-204-t.svg same as 203 but XML 1.1.


# Other situations that are described as being in error in this specification
 - if they are described as being in error in other chapters, the test coverage analysis should have noted them. Are there any? Chapter 5 has "A negative value for width/height on 'svg' is an error." but we were talking about removing that one ... circular dependencies is another error.


# A document can go in and out of error over time. For example, document changes from the SVG uDOM or from animation can cause a document to become in error and a further change can cause the document to become correct again.
 - imp-error-205-t.svg Test starts off not in error, then is put into error, displays indication, then goes out of error again.
 - NOTE its not clear that the uDOM can actually create non-wf, or non-ns-wf content, so this test would need to use one of the other error condition (if there are any left!). Creating a circular dependency from a chain of use elements, by altering an href, then removing the dependency by altering it back (or altering another one, to break the circle), would be a suitable test.

C.4 Namespace, version, baseProfile, requiredFeatures and requiredExtensions

imp-nsetc-*

# User Agents must only consider elements explicitly placed in the SVG namespace by XML Namespace declarations in the document (e.g., <svg xmlns="http://www.w3.org/2000/svg">) as being SVG elements.
 - I tried to think of some likely 'shortcuts' that implementations might take, and test for them.
 - imp-nsetc-201-t.svg tests a selection of svg elements, but the ns declaration is missing. passed if they are not displayed.
 - imp-nsetc-202-t.svg tests a selection of svg elements, but the ns declaration is not the SVG one. Passed if they are not displayed.
 - imp-nsetc-203-t.svg tests a selection of svg elements, with a ns prefix; the default ns is not the SVG one, but the SVG elements are indeed in the SVG ns so must be displayed.
 - imp-nsetc-204-t.svg tests a selection of svg elements, with a ns prefix; the SVG ns is declared, but the SVG elements are not in the SVG ns. Passed if they are not displayed.
 - imp-nsetc-205-t.svg tests a selection of svg elements, each with a different with a ns prefix; the SVG ns is bound to each of these prefixes so the elements are indeed in the SVG ns so must be displayed.


 SVG content can use attributes  'requiredFeatures' and  'requiredExtensions'  to provide explicit indication of the minimal features that must be supported by the SVG User Agent in order to render the SVG content correctly.
 - requiredFeatures tested by media-video-216-t.svg, struct-cond-03-t.svg, struct-cond-205-t.svg and so forth.
 - requiredExtensions tested by struct-cond-01-t.svg


# SVG content can also use attributes 'version' in conjunction with 'baseProfile' to provide explicit indication of the minimal features that must be supported. For example, if 'version' is 1.2 and 'baseProfile' is tiny, then these attributes indicate that the content requires a SVG User Agent that minimally supports the SVG Tiny 1.2 specification. If an SVG User Agent does not support the minimal required feature set, then the user agent should alert or otherwise provide a highly visible notification to the user that it may not be able to render the content correctly.
 - imp-nsetc-206-t.svg tests version="1.1" and baseProfile="tiny", test must be rendered
 - imp-nsetc-207-t.svg tests version="1.1" and baseProfile="full", test is informative. If the content (choose stuff in 1.1 full and not in Tiny 1.2, like patterns, markers and masks) is rendered then great, the Tiny 1.2 user agent also supports Full 1.1. If not rendered, thats fine too but "the user agent should alert or otherwise provide a highly perceivable notification to the user that it may not be able to render the content correctly".
 - imp-nsetc-206-t.svg tests version="1.2" and baseProfile="tiny", test must be rendered because its a 1.2T testsuite
 - imp-nsetc-207-t.svg tests version="1.2" and baseProfile="whatever", test must not rendered because we won't create a profile called "whatever". So "the user agent should alert or otherwise provide a highly perceivable notification to the user that it may not be able to render the content correctly."


# However, SVG content that provides a specified value for 'version' but does not provide a specified value for 'baseProfile' simply indicates to the user agent the specification level (1.0, 1.1, 1.2) to which the content conforms. If 'version' is specified but not 'baseProfile', the SVG content does not provide sufficient information to the user agent to determine the minimum feature set that is required to render the content; the user agent can only know that the author might be using SVG language features that were not defined in earlier versions of the language. Therefore, if the SVG content specifies a version of the SVG language unknown to the user agent, then the user agent should alert or otherwise provide a highly perceivable notification to the user that it may not be able to render the content correctly.
 - imp-nsetc-208-t.svg tests version="999.73" and no baseProfile, test must not rendered because we won't get to SVG 999.73 before the heat death of the universe and if we do, we can always change the test. So "the user agent should alert or otherwise provide a highly perceivable notification to the user that it may not be able to render the content correctly." The test doesn't actually contain any elements from future svg specifications.


- When SVG content specifies SVG language versions, profiles, features or extensions not supported by the currently installed user agent, the user agent may notify the user how to update the SVG User Agent should a newer version be available which does support these features.
 - not testable, because of the optionality from 'may' and because we can't say how to download implementations of specs we haven't written yet
 - appears to contradict the stuff about version with no baseProfile.

C.5 Clamping of Color and Opacity Values

imp-clamp-*

- Some numeric attribute and property values have restricted ranges, such as color component values. When out-of-range color or opacity values are provided, the user agent should defer any error checking until after presentation time, as composited actions might produce intermediate values which are out-of-range but final values which are within range.
 - not testable in a purely SVGT user agent; would be testable in one that also does advanced compositing.


# Color values are not in error if they are out-of-range, even if final computations produce an out-of-range color value at presentation time. User agents should clamp color values to the nearest color value (possibly determined by simple clipping) which the system should process as late as possible (e.g., presentation time), although it is acceptable for SVG User Agents to clamp color values as early as parse time. 
 - we should really not have a 'should' that requires clamping or requires the geometrically 'nearest' value; a gamut mapping transform might do a better job but not use the nearest value (eg to prevent hue shifts). Also, 'closest' requires specifying what color space the distance is measured in and what the distance metric is (euclidean distance, or something more complex like CMC values).
 - imp-clamp-201-t.svg has pairs of color patches, one out of range and one which is the closest in-range color. Test is passed if there is no error message and the two patches are displayed in 'similar' colors (where similar is deliberately vague, but displaying as, say, black is clearly not 'similar'.


# Opacity values out-of-range are not in error and should be clamped to the range 0 to 1 at the time which opacity values have to be processed (e.g., at presentation time or when it is necessary to perform intermediate filter effect calculations).
 - we can't test filter effects in the Tiny profile
 - imp-clamp-201-t.svg shuld test some out of range opacity values for fill opacity, stroke-opacity, opacity on image, stop-opacity. Both negative values and values greater that 1. test is passed if there is no error and the clamped values are used (ie zero for negative, or 1 for greater than 1)
 - either early or late clamping is allowed, this will look very different. so avoid testing nested group opacities, although Tiny doesn't have those (eg a group with opacity 4.0 inside a group with opacity 0.3, will give 0.3 with early clamping and 1.0 with late clamping)
 - 'processed' is vague, the intent of the section is late clamping but 'processed' could imply early clamping.

C.6 'path' element implementation notes

imp-path-*

# Directionality and zero-length path segments:
Certain line-capping and line-joining situations require that a path segment have directionality at its start and end points. Zero-length path segments have no directionality. In these cases, the following algorithm must be used to establish directionality: to determine the directionality of the start point of a zero-length path segment, go backwards in the path data specification within the current subpath until you find a segment which has directionality at its end point (e.g., a path segment with non-zero length) and use its ending direction; otherwise, temporarily consider the start point to lack directionality. Similarly, to determine the directionality of the end point of a zero-length path segment, go forwards in the path data specification within the current subpath until you find a segment which has directionality at its start point (e.g., a path segment with non-zero length) and use its starting direction; otherwise, temporarily consider the end point to lack directionality. If the start point has directionality but the end point doesn't, then the end point uses the start point's directionality. If the end point has directionality but the start point doesn't, then the start point uses the end point's directionality. Otherwise, set the directionality for the path segment's start and end points to align with the positive x-axis in user space.
 - Didn't Dr Olaf have some zero length line directionality tests? but grepping for 'zero-length' or 'direction' in the svg files does not turn anything up.
 - see also ISSUE-254
 - see also http://lists.w3.org/Archives/Member/w3c-svg-wg/2006AprJun/0021.html
 - paint-stroke-205-t.svg tests some of this
 - as discussed on 5 June SVG f2f, Zurich http://www.w3.org/2007/06/05-svg-irc
 - imp-path-201-t.svg a new test with three columns of subtest - before, after, both - and three rows - defined on immediately previous/next subpath, defined on and earlier/later subpath, not defined at all. 
 - Dr. Olaf says this is already tested: http://lists.w3.org/Archives/Member/w3c-svg-wg/2007AprJun/0573.html
 - imp-path-202-t.svg tests with no defined start or end direction, one subtest has no transformation and the other subtests have rotation or skew to check that its the local positive x-axis being correctly applied.


# The S/s commands indicate that the first control point of the given cubic Bézier segment is calculated by reflecting the previous path segments second control point relative to the current point. The exact math must be as follows. If the current point is (curx, cury) and the second control point of the previous path segment is (oldx2, oldy2), then the reflected point (i.e., (newx1, newy1), the first control point of the current path segment) is:
 - paths-data-01-t.svg and paths-data-12-t.svg test the S path command.


# Unrecognized contents within a path data stream (i.e., contents that are not part of the path data grammar) must be considered an error.
 - imp-path-203-t.svg has a path with real data followed by rubbish followed by more real data. test is passed if the first part of the path is displayed, followed by an error indication, and the second part of the path is not displayed.

C.7 Text selection implementation notes

imp-text-*

 The following implementation notes describe the algorithm that must be used for deciding which characters are selected during a text selection  operation. A conforming SVG User Agent must implement the behaviour specified by this algorithm. [.... and so on down to ...] When the user agent is implementing selection of bidirectional text, and when the selection starts (or ends) between characters which are not contiguous in logical order, then there may be multiple potential combinations of characters that can be considered part of the selection. The algorithms to choose among the combinations of potential selection options shall choose the selection option which most closely matches the text string's visual rendering order.
 - tested by text-tselect-03-t.svg 
 - test needs to be completely rewritten for manual selection by the user rather than (svg 1.1) dom-driven selection. It should thus be renamed to imp-text-201-t.svg.


# When multiple characters map inseparably to a given set of one or more glyphs, the user agent may either disallow the selection to start in the middle of the glyph set or may attempt to allocate portions of the area taken up by the glyph set to the characters that correspond to the glyph.
 - imp-text-202-t.svg should copy text-tselect-03-t.svg but add some ligatures.


# For systems which support selection, the user agent must provide a mechanism for selecting text with a full range of available UI devices (e.g. keyboard, mouse, pen, or any other pointer device) as a default, even when the given text is part of a link. 
 - imp-text-203-t.svg tests text selection in the presence of a link, both text with a link as part of it and text where the entire text element is inside the link. Needs to test 
  • a then text
  • text then immediately a
  • text, some content, then a
  • text, a, tspan
  • text, tspan, immediately a
  • text, tspan, some content then a
 - imp-text-204-t.svg tests text selection in the presence of a link as above, and also asks the user to confirm that they can select with a keyboard if the device has a keyboard.


# Additionally, the user agent must allow scripted or programmatic DOM access to all text content, and specifically any selected or focused content, at all times.
 - its not clear the uDOM gives you access to all of that. you can have a script set for the focus event. It doesn't tell you the range of characters selected.
 - Have a test that copies the text contents and places them in other text elements to show its been accessed. test should include some tspans in different color to show flattened text contents.

C.8 Printing implementation notes

imp-print-*

# Conforming SVG User Agents which support both zooming on display devices and printing, the default printing option should produce printed output that reflects the display device's current view of the current SVG document fragment (assuming there is no media-specific styling), taking into account any zooming and panning done by the user, the current state of animation, and any document changes due to DOM and scripting . Thus, if the user zooms into a particular area of a map on the display device and then requests a hardcopy, the hardcopy should show the same view of the map as appears on the display device. If a user pauses an animation and prints, the hardcopy should show the same graphics as the currently paused picture on the display device. If scripting has added or removed elements from the document, then the hardcopy should reflect the same changes that would be reflected on the display.
When an SVG document is rendered on a static-only device such as a printer which does not support SVG's animation and scripting and facilities, then the user agent shall ignore any animation and scripting elements in the document and render the remaining graphics elements according to the rules in this specification.
 - imp-print-201-t.svg test has some graphics content and some animations. The initial text says "before animations and script". If a static device prints this, it passes. Animations and script start after a couple of seconds. It has a script that changes the viewBox. After these changes, the text "print now" is displayed. If the implementation has a print capability, the test is passed if the correct animated, script-modified, zoomed view is printed.