Painting with SVG, a primer
Jake Howlett, 22 June 2002; Article: EPSD-5B4PLK; Area: XML
Doubtless you've heard me going on and on about SVG in the past month
or so. Why? Because I think it's an amazing addition to our skills toolbox.
Until I learnt of SVG I would have said that creating data-driven graphics
in a webpage is a costly/painful affair involving the likes of, the now defunct,
Macromedia Generator Server. With SVG, it couldn't get much cheaper or easier.
In fact, I just checked with a rocket scientist and he agrees, it isn't rocket
science.
What is SVG:
Officialy, SVG is a language for describing two-dimensional graphics in XML.
It is also described as an "XML application". What that means is up to you.
To me, it makes more sense if you read is as "an application of XML". Indeed,
SVG is merely XML and therefore plain text that you can write in any old
text editor. This means we can get Domino to create it on the fly. Hence
my excitement.
It may help you to think of SVG as an extension of the HTML that we already
know so well. Think of it like this - In HTML we have a set of tags that
we use to layout and present information in our pages. Things like <table>
and <hr> and <ul> are all used to create a certain look. Think
what it would be like if, in amongst all of this, there were extra tags like
<circle>, <rect>, <line>, <polygon> and <path>.
You can use combinations of these and other elements to draw a picture of
absolutley anything. In other words:
Using SVG on your pages:
Because SVG is one of the W3C's Web standards, it's as much as part of
the Web as XML and HTML are. It doesn't belong to a corporation who can pick
and choose what they do with it. It's completely open. For this reason you
can expect to see a variety of methods by which you can make it available
in the browser and a variety of software environments you can use for its
creation.
As hard as it is to try and predict the future of the internet, I like
to think there will come a day where SVG lives alongside HTML as part of
a page's source. In fact there is already a project underway within Mozilla
to support inline SVG.
Until the day that they all do we have to rely on the browser using a plugin
that is capable of rendering the SVG in the page. At the moment the defacto
is Adobe's and is currently in version 3.
If you haven't already, then download yourself the plugin as you'll find it hard to carry on without it. Now have a look at their section showing SVG "in action". You shouldn't need any more convincing after that. I was sold anyway, as was my boss.
To include an SVG image in your page you use an <embed> tag like below.
<embed src="simple.svg" width="300" height="300" type="image/svg+xml" />
No harder than adding a normal image to a page is it ...
There is a myriad of stuff out there so I won't bother to go in to much
more detail as I'm sure you want me to get to the point. A good starting
point for anything else you want to know is the SVG Wiki.
A nice little example:
The image on the left is of the SVG code from the boxed area below. I used
this as I often see these three symbols used to represent a database and
that's what Domino is, is it not. It's also a nice simple example of using
three of the SVG elements. Click on the image to open the actual SVG in your
browser.
<?xml version="1.0" encoding="utf-8"?>
<svg width="300" height="300">
<g id="db-symbol" style="stroke:#000000">
<rect x="20" y="130" width="140" height="140" fill="#41B8D4"/>
<circle cx="200" cy="200" r="70" fill="#FFFF5C"/>
<path d="M 150,60 L 60,180 L 240,180 Z" fill="#F555A8"/>
</g>
</svg>
So, what does it all mean? Well, the format of the code should look familiar
to us all. After all it's in SGML format, the same as any HTML and XML is.
The purpose of each element and its attributes should also be fairly obvious.
Note that the order in which each object appears in the code dictates its
z-index in the image.
The only element that may not be so obvious is the <g> element.
This is used to group all the objects that it contains in to one component.
It's then easier to do things like applying the same styling to lots of objects,
as I've done in the above.
The most important of the above objects is the <path> element which
is the most versatile. We can use it to draw pretty much any shape. The main
paramater to it is "d" which takes a value in a format similar to:
M 150,60 L 60,180 L 240,180 Z
Where, M = Move to, L = Line to & Z = Close. So here we have - Move
to the x,y coordinates 150,60. Draw a line from there to the x,y coordinate
60,180 and from there another line to 240,180. Finally, close the shape,
to make a triangle. This is only a simple example and It's well worth learning
how it works in more detail. Especially if you're interested in following
any future article I write on this subject as the path object will feature
heavily in all of it. Also get to know more about how the whole coordiante
system works as it's not quite as straight-forward as it might appear.
Using it all with our old friend Domino:
Domino is a database and hence it stores data. Having racked my brains,
the only logical application of SVG with Domino that I can think of is the
graphical representation of this data, i.e
charts.
They may sound like the most boring of all the things we could use this new
technology for but they are probably the most useful. If for nothing else,
think of how happy they will make your boss. Bosses love charts, as do most
end-users who have to deal with data on a day-to-day basis. If we can give
them what makes them happy then that can't be bad can it.
To create a chart of any kind we simply have to take the data we have
and turn it in to pieces of an SVG image. In the case of a chart this is
simply a case of creating a path for each segment of data. Let's take an
example of a bar chart and see how we would create it.
Imagine a database which contains documents that record the sales of
each region per month. So, for a year, there are twelve documents, each with
a field to record the sales in North, East, South and West regions. An example
of the data in such a document would be:
North |
East |
South |
West |
€30,000 |
€20,000 |
€40,000 |
€15,000 |
To draw the chart we first have to find out which region has the largest
sale. If the chart is 200 pixels high and the largest region is South with
€40,000 then 40,000 is equivalent to 200 pixels as we want the largest bar
to take up the maximmum height. Now we make all other regions relative to
the heigh of this one. For example, the North region had sales of €30,000
so it will only be 3/4 the height of the largest - or (200*30,000)/40,000,
which makes it 150 pixels high compared to the tallest bar which is 200 pixels.
Likewise, the East region is half the height and the West is (200*15,000)/40,000,
or 75 pixels high.
So, if x is the value we want to represent and max is the greatest of
all the values then the height of any bar can be worked out using ((height*x)/max)
where height is the available height of the chart.
You can see this simple theory in practice in the chart I used to represent
the distribution of goals scored for each group of this year's World Cup
in Japan & Korea. It's online
here
and I will describe how I achieved this using just simple @Formulae in a
future article. Drawing chart like line and pie charts is a different matter
but the theory is equally as simple and that too will be covered in future
articles.
How can we actually do this:
All this is very well but it doesn't really prove much does it. The proof
of the pudding, as they say, is in the eating. Well, you'll have to stay
hungry for a little bit longer as this article is long enough as it is. Hopefully
it's been enough to illustrate why I am so excited about it and why I think
it's worth our time looking at it.
The way in which you actually create the chart that you require depends
on how complicated it is and on how comforatable you feel with different
technologies. The methods we have available to us as Domino develoeprs range
from using simple @Functions or slightly more complex LotuScript to parsing
the data as XML with XSL Transformations.
In the next group of articles I've got planned I want to try and talk
about them all, starting with simple methods and moving on to the more powerful.
Which one you choose to use is down to you.
Resources:
Whilst there are not nearly as many resources out there as there is with
Flash, there is still quite a few and interest continues to grow. Here are
a couple to get you started:
The SVG-Wiki -
http://www.protocol7.com/svg-wiki/
Adobe's KnowledgeBase -
http://support.adobe.com/devsup/devsup.nsf/svgkb.htm
In the same way that you would find the majority of Notes developers on the LDD you will find most SVG developers are at the
SVG Developers Yahoo group. They are a very helpful bunch, as are those at LDD.
. . Applets (dicky, 23/06)
. . . . Re: Applets (Jake Howlett, 24/06)
. . Great (thomas ozenne, 24/06)
. . . . Re: Great (Alex Hernandez, 24/06)
. . . . . . Re: Great (Jake Howlett, 24/06)
. . . . . . . . Re: Great (Alex Hernandez, 24/06)
. . . . . . . . Re: Great (James Naidoo, 24/06)
. . Is it practical? (lee gardner, 25/06)
. . . . Re: Is it practical? (Jake Howlett, 25/06)
. . . . . . why not give both!? Re: Is it practical? (Brandon, 26/06)
. . surely there's more to SVG than charts!? (Brandon, 26/06)
. . . . Here's a clock I built in SVG! (Brandon, 26/06)
. . . . Re: surely there's more to SVG than charts!? (Jake Howlett, 27/06)
. . . . . . Of course you are right, but... (Brandon, 29/06)
. . P.S. a better resource for SVG (Brandon, 26/06)
. . Vertical alignment? (John Hunter, 28/06)
. . . . Re: Vertical alignment? (Jake Howlett, 28/06)
. . . . . . Re: Vertical alignment? (John Hunter, 28/06)
. . . . . . . . Re: Vertical alignment? (Jake Howlett, 28/06)
. . . . . . . . . . Re: Vertical alignment? (John Hunter, 03/07)
. . Notes Forms (Maria Daniela Capurro, 28/06)
. . . . Re: Notes Forms (Jake Howlett, 01/07)
. . . . . . Re: Notes Forms (M. Müller, 11/07)