Re: Pieslice

MWhisman@aol.com wrote:

> In general, wouldn't it be nicest to offer a full range of predefined shapes,
> including triangles, regular polygons, and starbursts, along with shapes
> common to various kinds of diagrams, such as organizational charts,
> flowcharts, maps, and engineering and electrical diagrams? 

So, an implementation would be non-conformant if it didn't have a
predefined "thyristor with tuning capacitor" shape? It is difficult to
come up with a set that pleases everyone - there will always be one
symbol missing, and pleas to add it to the specification, and (equally)
complaintrs about how big these implementations are getting ...

While it is certainly convenient to hava access to predrawn shapes which
are simply arranged into composite diagrams, these need not be defined
in the specification.

Indeed, it is advantageous that they are not so defined. It means that
the code and data that are needed for the implementation is smaller; it
means that the shapes used can be modified and improved over time, and
it gives greater flexibility.

In SVG, it is possible to define a shape and then use it one or many
times ina drawing. The definition can be, but does not need to be, in
the same file as the diagram which uses it.

SVG can thus provide an infinite variety of symbols, without requiring
them to be defined in the specification. Given that the Web is a natural
distribution mechanism, and that different communities of users will
tend to want different symbols, and that cacheing will tend to make
popular symbol libraries rapidly available, this seesm to be a better
approach.


>These would offer
> ease of use for new, non-artist, users. These would provide structures within
> the language that support and mirror features in many common software packages
> (insert favorite drawing/publishing/office program here).

I agree in terms of the advantages, but with the different
interpretation that these advantages are even greater when the symbol
libraries are linked rather than codified. That way, when a new
drawing/publishing/office program appears, it can have its own symbols
on the vendors Web site, everyone using that package links to those
symbols, and cacheing does the rest.


> After all, isn't the idea behind SVG and other web formats to provide standard
> file formats in which all applications can transfer information? 

Yes, so long as they are transferring it over the Web. (Other forms of
transport are possible, but W3C does not address those).

> It seems to
> me that someday programs might use HTML, XML, CSS, SVG, PNG, or other formats
> as their primary, native file formats.

There are already programs which use some of these as their primary,
native file formats; in particular there are wordprocessors which use
HTML and CSS as their native format, raster graphics programs which use
PNG as the native format, and increasingly many programs which use XML
for, well, just about anything.

Yes, I expect that SVG will find a use as a native format too, in future
applications.


> Specifically for pieslice:
> 
> I'd think most designers would want the ability to specify a pieslice by a
> bounding box that defines the circle or ellipse and center point, as well as
> entering the starting and ending angles of the slice's arc.

If it is being used *as a pie slice*, then I would have thought that a
natural representation would be a pie angle (0 to 360 degrees), an
angular rotation from horizontal, and a radius. There are many
possibilities.

> Alternatively, a designer might want to enter the three points (center point,
> starting point, and ending point) that define the pieslice. The relationship
> of the starting and ending points to the center point would determine whether
> the slice looks more like a triangle or like a circle minus a triangle.

Yes, that is another possibility.

I wonder how many pie-diagrams in actual use are flat, rather than being
pseudo-3D?


--
Chris

Received on Wednesday, 24 February 1999 22:24:11 UTC