Re: implementation size for SVG Tiny

Jean-Claude,

Jean-Claude Dufourd wrote:
> Chris Lilley a écrit:
>> However, I can confirm that both their Tiny and their Basic
>> players work fine on current Symbian phones such as are commercially
>> available.
>>
> So, are they used ?
> My feeling is: not massively. The reason could be that a 500K installer 
> means even more RAM usage and that would be too much compared to what 
> the phone manufacturers are ready to dedicate to SVG.

I don't have the numbers for BitFlash deployment so I can't provide you 
with an answer, but I know they've been rolled out in production Sharp 
phones. I don't know the exact size of Zoomon's implementation(s) but 
they target low to mid end devices and have rolled out their players 
phones, for instance in Siemens phones. Some of those newsbits are 
available from the SVG WG's public page:

   http://www.w3.org/Graphics/SVG/

> Which brings me back to my question about size.
> As some people's analysis of the "right size" points  at 50K, the 
> question is really: can SVG Tiny be implemented in 50Kb.

I can't speak for the Tiny implementors (though I'd like them to show 
some numbers :) but I've seen indication that something close to Tiny 
(and featuring extra stuff) could be done in 30K.

It would be valuable to know which people analyse the right size as 
being 50K. If you could provide us with details in this direction, it 
would definitely be helpful for the work of the WG.

>> Where does it say in the SVG specification that device fonts must be
>> supported?
>>
> This comes as a shock to me.  I would think that a requirement of SVG 
> Mobile would be to use the device fonts, if only to be able to save 
> space. Device fonts are optimized for small screens and much more 
> readable than other fonts at sizes compatible with those small screens, 
> according to a font specialist from Agfa Monotype.

I assume that by space you mean file size. Obviously, not having to send 
font information alongside SVG document would save space, but given the 
current state of device font availability accross platforms (Mobile and 
Desktop), relying on device fonts tends to be a bit like entrusting your 
life to russian roulette. The current feedback I heard from people 
thinking that SVG fonts would be hard to implement is that it turned out 
to be fairly easier than they thought. It is very much possible to write 
SVG fonts that are very readable at small screen sizes.

>> TinyLine seems to conform to what SVG Mobile says regarding how an SVG
>> renderer deals with foreignObject.
>> http://www.w3.org/TR/SVGMobile/#sec-extensibility
>>
> The Tinyline author, in his element support table, put "no" in front of 
> foreignObject. I trusted that.

Well, not doing anything with it is pretty much conformant to SVG Mobile ;)

>> JCD> Or is this an optional feature ?
>>
>> What part of the SVG specification leads you to believe that this is
>> optional?
>
> Nothing. I just hoped it was. Conversion from SVG to Flash or BIFS is 
> hell because of such things.
> The implementation of a property cannot be straightforwardly tied to the 
> elements that use it.

If you are writing an SVG to (SWF|BIFS) converter, there's nothing 
keeping you from munging the SVG data before it is turned into the new 
format. And at least as of SVG 1.1 Tiny (I'll have to look into what 1.2 
and the uDOM *may* change there) you could simply implement that 
inheritance in the converter, and add as many animation elements as you 
need to make it work on individual elements.

> This extra level of abstraction does not feel worth the extra cost, 
> given my current knowledge of SVG.
> ( I have to think about Robin's remark on animating multiple objects)

It is a very worthwhile feature to have when you are dealing with some 
properties such as opacity where you almost always want a single 
animation to operate on an entire subtree. For SVG Tiny, it might be 
less useful, but removing that would likely be a fairly surprising 
change for anyone trying to author SVG content for a that profile. As I 
said in the previous paragraph, the features that make SVG easy to 
author and generate lend themselves to being transformed into a simpler, 
less authoring-friendly but perhaps more 'canonical' SVG that can then 
be transcoded.

Even if you add some form of scripting support to Tiny so long as your 
'simplifications' are well and cleanly defined content producers will be 
able to generate SVG Tiny documents that will be convertible to the 
formats you mention. And the ability to do that would certainly be of 
great value in a number of situations.

-- 
Robin Berjon

Received on Thursday, 11 March 2004 17:50:40 UTC