The coming of SVG

[Mark Waddingham]

Hi all,

My most recent talk at LCG (in October) was 'Building an SVG Widget' and 
in order to talk about such a thing, I needed to actually build one - so 
I did :)

So, we are now firmly on the road to full SVG support in LiveCode!

At the moment the implementation only supports geometric shape tags, 
paths, and solid color fills. However, it supports the standard 
fill/stroke attributes and should work with any SVG file - anything 
which isn't supported just doesn't get rendered (so you have a modicum 
of graceful degradation in terms of features). In particular, you don't 
need to preprocess your SVG file to pull out incompatible tags / 
attributes, or just extract the path (as you do for the SVGIcon widget).

The current implementation successfully renders quite a wide range of 
simple SVGs (simple in the features they use, rather than how they 
look!). Indeed, it happily renders the (quite widely known) Tiger and 
Lion SVGs, and has been tested on quite a few random SVGs I managed to 
find on Wikipedia. It is certainly more than capable if you want to use 
simply coloured multi-path SVGs.

LCG attendees got a prototype of a widget to play with - called 
vectoricon - and integrating this initial version this into the product 
has now got to the top of my work-list :)

The principal thing which I'd like some feedback on right now is the 
name of the widget/control - I think we have a good one, but wanted to 
see what you all thought before committing us to it forever and a day.

Before getting to that though, I should perhaps explain what a potential 
path for the evolution of this new feature in LiveCode could look like.

SVG as a concept allows arbitrary collections of vector shapes, images 
and text to be represented in a single high-level way as XML - in 
particular, you can express geometric shapes, raster images and text all 
in one unified form.

Previously we had proposed producing a 'shape' object which would be a 
'graphic object on steroids' - allowing affine transformation, higher 
fidelity specification of geometric objects and groups of them; 
providing an 'svgText' interface similar to htmlText on the field. 
Essentially, the proposed 'shape' object would have used a subset of SVG 
to allow easy interchange of what it represents.

That notion of 'shape' object (and thus the current 'graphic' object) 
can be subsumed into the SVG implementation in an obvious way - if you 
ask your SVG object to be a rectangle, it creates (notionally) the SVG 
for a rectangle internally and uses that - which you would see via the 
svgText.

Similarly, as SVG can represent raster images too, we can fold the 
current behavior of the 'image' object into it to - in a similar way.

The end result here would be a single object which is a generalization 
of two existing objects - image and graphic - but without the 
backwards-compatibility baggage we currently have.

In terms of using this new object in a consistent way to our current 
model, we propose (subsequently) to generalize the types of objects 
which can be referenced by imageSource and icon properties - allowing 
them to use any object which 'knows how to be used as an icon'. 
Currently, only the image object has this knowledge - but we can extend 
to other objects by getting them to implement the appropriate internal 
interface. This would mean that you could just replace the images you 
use currently for icons and such, with the new control which supports 
SVG and use SVG instead.

Given the potential future path of this particular feature, we also 
propose to eventually give it an actual control type - rather than 
widget (although it will still be a widget). i.e. We think it is has 
such future potential that being able to do '<noun> "foo"' in script 
will be very useful (this is almost a requirement if it is to eventually 
'replace' the image and graphic objects). [ Note: we have also been 
considering this for the browser widget too! ].

Thus with all that in mind - we are proposing 'picture' as the name of 
the new SVG capable control, with the following ideal roadmap:

   a) we would integrate the 'prototype' implemented for SVG as 
'com.livecode.widget.picture'

   b) we would add a 'picture' noun to the language as the control type 
for that widget

   c) we would add icon reference support, allowing it to be used in 
place of an image

   d) we would add graphic-like shape properties, allowing you to use it 
in place of a graphic

   e) we would add support to the image tag in svg, and image-like image 
properties, allowing it to be used in place of an image

   f) we would gradually expand support for the range of SVG it can 
directly render (gradients and layers are high on the hit list here)

In terms of timescale, we are currently looking at delivering 'just' (a) 
for 9.0 (although I do have my eye on at least (c) too - we'll have to 
see how other things we still need to finish for 9 go). The rest all 
break down into bite-sized chunks which I'd hope we could iterate on it 
periodically after that.

It goes without saying that we are interested in any and all feedback 
you might have on this idea; however, right now, our top priority is 
naming.

As I said above 'picture' is our current top (and perhaps only!) 
contender - it says what SVG does (it represents pictures of things), 
can subsume the idea of image and graphic naturally, and is 
human-friendly. It is also a single word which is a current requirement 
if it is to be used as a chunk noun (like 'image', and 'graphic' etc.).

I look forward to reading any feedback you might have!

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps