W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Re: ISSUE-2113 (animate-elem-35): animate-elem-35 [Test Suite - SVG Tiny 1.2]

From: Alex Danilo <alex@abbra.com>
Date: Sat, 11 Oct 2008 16:08:51 +1100
Message-Id: <RA6K8K.ZSJJAK75DUM7@abbra.com>
To: SVG Working Group WG <public-svg-wg@w3.org>

In regard to this issue:

--Original Message--:
>ISSUE-2113 (animate-elem-35): animate-elem-35 [Test Suite - SVG Tiny 1.2]
>Raised by: Doug Schepers
>On product: Test Suite - SVG Tiny 1.2
>Piers Wombwell
>Just had a quick glance at your test suite results, and noticed a  
>comment against test animate-elem-35.
>The problem here is down to fixed point maths. The inside of the 'A'  
>is made from a path using relative co-ordinates which don't map well  
>to fixed point maths. So when it draws the horizontal line to complete  
>the path in the bottom-right, the end point doesn't quite match the  
>start point. The closepath then expects the current point to be equal  
>to the start point, but they aren't quite, and so it draws a sub-one- 
>pixel line -- and so the line joins aren't as expected. Rather than  
>one line join between the last and first lines (_ and \), there will  
>be two line joins, one between the _ and the short closepath, and one  
>between the short closepath and the first line \.
>I assume the problem is the same on the outer part of the 'A', but  
>haven't confirmed this.
>I'm not sure what precision you need for the test to pass, but  
>floating point tends to pass and fixed point (24.8) fails in my  

SVG Tiny 1.2 Section 4 'Data Types' clearly states:

"<number> values in conforming SVG Tiny 1.2 content must have no more than 4 decimal digits in the fractional part of their decimal expansion and must be in the range -32,767.9999 to +32,767.9999, inclusive. It is recommended that higher precision floating point storage and computation be performed on operations such as coordinate system transformations to provide the best possible precision and to prevent round-off errors."

This is based on 1.1 Tiny and the discussion at  the time mandated 16.16 as the precision for
fixed point implementations. Ikivo passes and I recall it's fixed point internally.

4 decimal digits after the decimal point requires 16 bits. A 24.8 format can at best represent
2 digits after the decimal point.

Failures due to a 24.8 fixed point implementation unfortunately can't be used as a failure
due to the lack of support for the required accuracy mandated in section 4.

Received on Saturday, 11 October 2008 05:09:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:40 UTC