Re: implementation size for SVG Tiny

On Thursday, March 11, 2004, 10:33:32 PM, Jean-Claude wrote:


JCD> 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.
>>
JCD> So, are they used ?

I don't have any deployment figures. You could ask them.

JCD> My feeling is: not massively. The reason could be that a 500K installer
JCD> means even more RAM usage and that would be too much compared to what
JCD> the phone manufacturers are ready to dedicate to SVG.

It could, but that is two unsubstantiated guesses (not much deployed,
and that is because of the filesize); its less information than I am
happy with to draw a conclusion.

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

I would be interested to hear where this 50k size comes from. Which
manufacturer gives this as a desirable size?

>>Where does it say in the SVG specification that device fonts must be
>>supported?
>>
JCD> This comes as a shock to me.  I would think that a requirement of SVG
JCD> Mobile would be to use the device fonts, if only to be able to save
JCD> space.

It comes as something of a shock to imagine that the (often
raster-based) system fonts, which are impossible to stroke, difficult
to scale or rotate with any fidelity, and often available only at
certain pixel sizes, and frequently with very limited Unicode
coverage, would be of much use for SVG renderers.

Implementors are not *prevented* from using them, of course. But their
limitations make them fairly unattractive.

JCD>  Device fonts are optimized for small screens and much more
JCD> readable than other fonts at sizes compatible with those small screens,
JCD> according to a font specialist from Agfa Monotype.

(I am familiar with the ESQ work that Agfa Monotype do for Microsoft)

>>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
>>
JCD> The Tinyline author, in his element support table, put "no" in front of
JCD> foreignObject. I trusted that.

Did you read the specification section I quoted?

>>The actual executable tinylines60.jar is 117k.
>>
JCD> The generic jar is 95Kb, of which 28Kb must be his Tinyline2D graphics
JCD> library, available separately in one of the Tinyline packages.
JCD> 67Kb of jar for SVG Tiny parsing and compositing, that is amazingly compact.

If you consider 67k to be amazingly compact, I wonder why you propose
a figure of 50k (assuming your intent is to get an implementation
under this size, rather than to show that Tiny cannot be implemented).

>>JCD> However, how much of property inheritance (the ability to put a property
>>JCD> like color anywhere above your rectangle) does the test suite test ?
>>
>>(I assume from this comment that you have not looked at the test
>>suite)
>>
JCD> Indeed, I used it but did not read the SVG sources. You have to read it
JCD> closely to find this out.

I agree that some of the test descriptions could use a little work.
Some of the tests that I mentioned give property inheritance as the
reason for the test; others happen to use it but are not explicitly
testing for it(although implementations that fail to use it will
fail).

Might I be correct in inferring that a particular binary packetisation
of XML has difficulty dealing with inheritance of attributes and
properties from arbitrary tree ancestors, perhaps because the tree
structure and the tree contents are stored separately?

>>http://www.w3.org/Graphics/SVG/Test/
>>
>>see for example
>>http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-painting-fill-02-t.html
>>http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-painting-fill-04-t.html
>>http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-painting-marker-02-f.html
>>http://www.w3.org/Graphics/SVG/Test/20030813/htmlframe/full-styling-inherit-01-b.html
>>
JCD> Thanks a lot. OK, Tinyline fails on the first, but does the second
JCD> correctly. It does property inheritance.

Yes, it fails the first one because it does not understand the
specific value 'inherit'. It inherits correctly if the property is
unspecified. This should be very easy to fix.

>>JCD> Or is this an optional feature ?
>>
>>What part of the SVG specification leads you to believe that this is
>>optional?
>>  
>>
JCD> Nothing. I just hoped it was. Conversion from SVG to Flash or BIFS is
JCD> hell because of such things.

Aha (realization dawns)

Conversion from Flash (SWF) is problematic anyway because the one
authoring tool creates frame-based inbetweens and puts them all in the
file, bloating the file size compared to SVG. The FLA authoring format
holds the keyframe geometry and the interpolation information, so
would be much better for converting to SVG,were the format to be
adequately documented. Conversion from SVG to SWF is possible, but is
perhaps best implemented by conversion to FLA and exporting to SWF
from the Flash authoring tool.

I don't know enough about BIFS to comment about conversion to or from
SVG, but hope that you will enlighten us.


JCD> The implementation of a property cannot be
JCD> straightforwardly tied to the 
JCD> elements that use it.

The implementation is not tied to the elements that use it; the
declaration of property values to the eements that use it is very plain
and straightforward.

JCD> This extra level of abstraction does not feel worth the extra cost,
JCD> given my current knowledge of SVG.

I suggest you implement a transformer which takes an SVG document, and
then outputs a fully decorated tree where each element has all the
attributes it could possibly have, including the values that would
have been inherited from the parents and the initial values if
unspecified in the source document, and then take a look at the size
of the result.

You could also imagine the cumbersome nature of the manipulations that
would be needed to change a given value, traversing all the child nodes
and changing them too. This would be massively unwieldy.

JCD> ( I have to think about Robin's remark on animating multiple objects)

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Thursday, 11 March 2004 18:21:48 UTC