W3C home > Mailing lists > Public > www-svg@w3.org > March 1999

Re: SVG Questions

From: Jon Ferraiolo <jferraio@Adobe.COM>
Date: Thu, 11 Mar 1999 11:45:29 -0800
Message-Id: <199903111942.LAA09662@mail-345.corp.Adobe.COM>
To: Justin Higgins <jhiggins@dn.net>
Cc: www-svg@w3.org
At 10:47 AM 3/11/99 -0500, Justin Higgins wrote:
>Hi,
>
>Just a few questions about possible raster support with the SVG
>language:
>
>1) Do you think it would be a good idea to allow the use of embedded
>raster images within a defined svg?  In particularly, allowing the use of
>raster images as tiles, which could serve as textures/covers/etc. tiled
>onto existing
>vector graphics....this could also apply later on to 3d svg's.

Raster images can be used within an SVG. There is an <image> element for
this purpose. Images can be used for pattern fills for text, paths and
shapes and serve as input to whatever filter effects go into the language.

Right now, all images must be external (i.e., use an href), just like in HTML.

>2) Similarly, could people define texture maps for existing vector
>graphics, which could be used to add effects like rough paper, grass,
>stone, marble, etc.  

Such capabilities are the intent of the filter effects section of the draft
spec.

>In general it seems like this could make for much richer possibilities for
>vector graphics, especially for applications such as logos and charts and
>graphs.

I'm a big fan of client-side filter effects. Don't forget web buttons,
banner ads and fancy H1/H2/H3 text strings.

>3) Would it be possible to allow developers to designate within the code
>GIFs and JPEGs to display in place of an svg of the web browser didn't
>support XML or vector graphics?  It might help in quickening the adoption
>of vector graphics if there was a built in way to support older browsers.

We are very aware of this requirement.

There was an attempt in the current draft spec to address this issue with
the <althtml> element. There is likely to be a different approach in the
next draft spec.

>Seperately, would it be possible to define a standard set of possible
>gradients (rainbow, starburst, slight gradient, etc.) as well as the
>ability to define new gradients? 

For this particular case (i.e., gradient libraries), I would argue that a
good approach would be some sort of a standard gradient library posted
separately from the SVG specification which could be referenced via URL by
SVG drawings interested in using such a standard library. In the current
draft spec, you reference a gradient by <uri>, which means it can be
defined locally or externally. For example:

http://MyWebSite/StandardGradientLibrary.svg:
<svg .... >
   <defs>
      <lineargradient id="RainbowGradient" ...>
         <!-- Definition of the gradient -->
      </lineargradient>
   </defs>
</svg>

MyFile.svg:
<svg ...>
   <rect style="fill:
url(http://MyWebSite/StandardGradientLibrary.svg#RainbowGradient)" ... />
</svg>



Jon Ferraiolo
Adobe Systems Incorporated
Member SVG working group
Received on Thursday, 11 March 1999 14:42:24 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:17 GMT