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

In regard to this issue:

--Original Message--:
>ISSUE-2113 (animate-elem-35): animate-elem-35 [Test Suite - SVG Tiny 1.2]
>
>http://www.w3.org/Graphics/SVG/WG/track/issues/2113
>
>Raised by: Doug Schepers
>On product: Test Suite - SVG Tiny 1.2
>
>Piers Wombwell
><http://lists.w3.org/Archives/Public/www-svg/2008Oct/0039.html>:
>[[
>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  
>experience.
>]]

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.

Alex

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