- From: Alex Danilo <alex@abbra.com>
- Date: Mon, 11 Jul 2011 12:32:51 +1000
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Hi All, I won't be able to make the F2F after all due to other commitments:-( I will try to attend relevant sessions by phone if there is one available. Regarding the SVG 2.0 discussions, it would be nice to have the group take up the "what do we do with Tiny 1.2" subject. What I mean is that we had SVG 1.0, which begat the modularized 1.1 which begat the Tiny 1.1, Basic 1.1 and Full 1.1 profiles, all of which were upwardly compatible. Then we had a long drawn out design process that developed a bunch of features for 1.2 Full, like text wrapping in shapes, etc. but eventually completed a single profile - Tiny 1.2. Opera is the only mainstream browser that supports the Tiny 1.2 feature set, however as we saw at SVG/Open last year there are a number of other web engines being used in different areas that use Tiny 1.2 but don't have visibility cause they're not browsers. For example: RIM's Blackberry uses Tiny 1.2 for UI and most of the display as far as I understand, a fairly large install base there. QuickOffice used the Bitflash Tiny 1.2 engine for rendering of their product which reportedly has shipped > 350 million units. A number of (large) companies in the IPTV space are planning to use Tiny 1.2 for their embedded TV offerings, and there are shipping devices in some countries already. So, when moving forward on 2.0 - what do we expect as far as backward/forward compatibility goes? There have been many slice and dice F2F discussions over the years. Like or dislike of the uDOM is a bit of a distraction, since removing the uDOM makes Tiny 1.2 very compatible with 1.1 - adding nice things like non-scaling stroke amongst other things for example. Moving forward it would be nice to see a clear plan that makes sure we don't fragment into Tiny vs. Full flavours. I agree with JonF's comment at SVG/Open in 2009 that mobile devices should support Full moving forward, but things like filters may not work well with current GPU or OpenGL/ES or OpenVG silicon implementations. So we need a proper plan that makes sure we can have a unified set of features that can increase in complexity without sacrificing compatibility (i.e. the interoperable subset plus extensions sort of thing). Anyway, just my 2c to get you all thinking before the meeting. Cheers, Alex
Received on Monday, 11 July 2011 02:33:16 UTC