From: Piers Wombwell <piers@ekioh.com>

Date: Sat, 11 Oct 2008 11:30:51 +0100

Message-Id: <9D65ECA9-A950-4114-8F91-60B45935D1D5@ekioh.com>

To: Alex Danilo <alex@abbra.com>

Cc: www-svg@w3.org

Date: Sat, 11 Oct 2008 11:30:51 +0100

Message-Id: <9D65ECA9-A950-4114-8F91-60B45935D1D5@ekioh.com>

To: Alex Danilo <alex@abbra.com>

Cc: www-svg@w3.org

> 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. Hi Alex, I was explaining why implementations are failing the test rather than claiming the test is invalid. I haven't tried it with 16.16 precision so I don't know if that's enough to pass. Given the precision of a number in base 10 number doesn't map directly to the number of bits in fixed point, there's a chance it doesn't. Our implementation has chosen to ignore the 16.16 precision rule because it doesn't provide enough range on a TV. A HD screen can be 1920 pixels wide, which only gives you a range of 17 screenfuls horizontally before it wraps. This isn't enough for things like scrolling EPGs and the like which need at least 24 hours of data. I appreciate on a mobile phone the screen is a fraction of the width so it is much less of a problem. Piers.Received on Saturday, 11 October 2008 10:57:37 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:29:38 UTC
*