Re: [Fwd: ACID3 test submissions]

Doug,

well I loved the apparent overt simplicity of the Acid2 test.
ie at least when launched any mortal could see if something was amiss.

I'd prefer something less overtly technical and 'standards' in your  
face.
something amusing that appealed to a wider audience, raising the  
popularity of SVG.
A short story perhaps.

It seems the test halts, could it not be designed to complete  
sections and continue in any case?

Could accessibility tests to be included, including mousewheel,  
keyboard etc.

xmlhttprequest and more....

on this basis Acid 3 appears to fail to live up to Acid 2.
it's not amusing, nut none the less a significant development.

Might a short youtube animation be helpful in determining errors and  
generating interest.

regards


Jonathan Chetwynd
Accessibility Consultant on Media Literacy and the Internet



On 21 Jan 2008, at 05:46, Doug Schepers wrote:

Hi, SVG Community-

Given the popularity of the ACID tests for browser interoperability,  
we'd like to get some SVG tests in there for the next version.  A few  
of us on the SVG WG put together some tests, and I thought some of  
your might be interested in them as well.  I'm forwarding on  Erik  
Dahlstrom's explanatory email, with the tests attached.  If anyone  
has any suggestions for good SVG interoperability tests, either for  
the official ACID tests or for a dedicated "SVG ACID Test", feel free  
to let us know.

I'll also blog about this on the W3C QA Blog [1], for those  
interested in some more details.

[1] http://www.w3.org/QA/

Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

-------- Original Message --------
Subject: ACID3 test submissions
Date: Sun, 20 Jan 2008 23:02:57 +0100
From: Erik Dahlstrom <ed@opera.com>
Organization: Opera Software
To: ian@hixie.ch
CC: w3c-svg-wg@w3.org <w3c-svg-wg@w3.org>

Hello Ian,

see attached files for a submission of svg tests for the ACID3 test
competition. The tests have been added to the acid3 framework as  
tests 65
- 69.
Comments and links to relevant parts of the SVG spec have been  
included in
each subtest in the framework.

The acid3-framework.html is a modified version of the unfinished  
draft of
ACID3[1], with a few minor modifications:
a) there is an <object> element that references an svg
b) there is an <iframe> element referencing the same svg

These two ways of referencing svg should both work, and there is a test
that checks this (#69).
In addition to this one svg file (empty.svg) which contains a few  
lines of
helper code, it in turn references an external svgfont file
(acid3font.svg). This is intentional to test that external svgfonts are
supported (#67).

Brief comments about each test:
#65: This test is meant to be a very basic test for declarative (SMIL)
animation in SVG.

The test begins by creating a few elements, among those is a <set>
element. This element is prevented from running by setting
begin="indefinite", which means that the animation doesn't start  
until the
'beginElement' DOM method is called on the <set> element. The  
animation is
a simple animation that sets the value of the width attribute to 0. The
duration of the animation is 'indefinite' which means that the value  
will
stay 0 indefinitely. The target of the animation is the 'width'  
attribute
of the <rect> element that is the parent of the <set> element. When
'width' is 0 the rect is not rendered according to the spec[7].

Some properties of the SVGAnimatedLength[2] and SVGLength[8] are also
inspected. Before the animation starts both baseVal and animVal contain
the same values[2]. Then the animation is started by calling the
beginElement method[9]. To make sure that time passes between the
triggering of the animation and the time that the values are read out  
(in
test #66), the current time is set to 1000 seconds using the
setCurrentTime method[10].

#66: This test checks the results of test #65, to check that the animVal
syntax is supported and working.

About animVal[2]: "If the given attribute or property is being animated,
contains the current animated value of the attribute or property, and  
both
the object itself and its contents are readonly. If the given  
attribute or
property is not currently being animated, contains the same value as
'baseVal'."
Since the duration of the animation is indefinite the value is still  
being
animated at the time it's queried. Now since the 'width' attribute was
animated from its original value of "100" to the new value of "0" the
animVal property must contain the value 0.

#67: This test tests that external SVGFonts are supported.

SVGFonts are described here[3], and the relevant DOM methods used in the
test are defined here[4].
Note that in order to be more predictable the svg should be visible  
(which
it is in this framework), so that clause "For non-rendering  
environments,
the user agent shall make reasonable assumptions about glyph metrics."
doesn't influence the results. The font-size 4000 was chosen because  
that
matches the unitsPerEm value in the svgfont, which makes it easy to  
check
the glyph advances since they will then be exactly what was specified in
the svgfont.

#68: Tests that textPath in svg is supported by checking that the
getRotationOfChar DOM method works.

The getRotationOfChar[4] method fetches the midpoint rotation of a glyph
defined by a character (in this testcase there is a simple 1:1
correspondence between the two). The path is defined in the empty.svg
file, and consists of first a line going down, then followed by a line
that has a 45 degree slope and then followed by a horizontal line. The
length of each path segment have been paired with the advance of each
glyph, so that each glyph will be on each of the three different path
segments (see text on a path layout rules[5]). Thus the rotation of the
first glyph is 90 degrees, the second 45 degrees and the third 0  
degrees.

#69: Tests that the getSVGDocument interface[6] is available on the
<object> and <iframe> elements.

GetSVGDocument[6]: "In the case where an SVG document is embedded by
reference, such as when an XHTML document has an 'object' element whose
href (or equivalent) attribute references an SVG document (i.e., a
document whose MIME type is "image/svg+xml" and whose root element is  
thus
an 'svg' element), the SVG user agent is required to implement the
GetSVGDocument interface for the element which references the SVG  
document
(e.g., the HTML 'object' or comparable referencing elements)."

The method is called and then compared to the contentDocument attribute.

===

Results from running the tests 65-69:

Firefox 3.0 nightly (Gecko/2008011604 Minefield/3.0b3pre):
Test 65: getSVGDocument not supported.
Test 66: Failed to find <rect> element in svg document.
Test 67: expected 4776, got: 2776 - getComputedTextLength failed.
Test 68: expected 90, got: 0 - getRotationOfChar(0) failed.
Test 69: getSVGDocument missing on <object> element.

Webkit nightly (r29673):
Test 65: SMIL::ElementTimeControl not supported.
Test 66: expected 0, got: 100 - Incorrect animVal value after svg
animation.
Test 67: expected 4776, got: 5550 - getComputedTextLength failed.
Test 68: expected 90, got: 0 - getRotationOfChar(0) failed.
Test 69: getSVGDocument missing on <iframe> element.

Cheers
/Erik

[1]
http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html
[2] http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedLength
[3] http://www.w3.org/TR/SVG11/fonts.html
[4] http://www.w3.org/TR/SVG11/text.html#InterfaceSVGTextContentElement
[5] http://www.w3.org/TR/SVG11/text.html#TextpathLayoutRules
[6] http://www.w3.org/TR/SVG11/struct.html#InterfaceGetSVGDocument
[7] http://www.w3.org/TR/SVG11/shapes.html#RectElement
[8] http://www.w3.org/TR/SVG11/types.html#InterfaceSVGLength
[9] http://www.w3.org/TR/SVG11/animate.html#DOMInterfaces
[10] http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGSVGElement

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
http://my.opera.com/macdev_ed

-- <empty.svg><acid3font.svg>
Acid3






JS/?


FAIL
To pass the test, a browser must use its default settings, the  
animation has to be smooth, the score has to end on 100/100, and the  
final page has to look exactly, pixel for pixel, like this reference  
rendering.

Scripting must be enabled to use this test.

<empty.png>
<!DOCTYPE HTML><html><head><title>FAIL</title><style>
<!-- this file is sent as text/html, not text/css, which is why it is
      called "empty.css" despite the following lines -->

   body { background: white; color: black; }
   h1 { color: red; }

</style><body><h1>FAIL</h1></body></html>

Received on Monday, 21 January 2008 09:40:52 UTC