Re: Request for Future Feature: Star Element

Doug,

> It has nothing to do with the size (though that would be a benefit, too).
> It's about being intuitive, animatable, and semantic.

I'm not saying we should not be semantic. I just think that we must
try to balance this against:

1 the size and complexity of the standard, 

2 the complexity of implementations, 

3 the level of use this feature would get, 

4 the level of _completeness_ with which you can define this feature
(and thus remove the motivation for further proprietary extensions),
and

5 the ease with which the same feature can be done by other means. 

With all this taken into account, I think that rectangles and ellipses
do have a place in the standard (with some reservations, see below),
but more complex shapes do not.

> | http://inkscape.org/screenshots/gallery/inkscape-0.39-CVS-linux-stars.png
> | http://inkscape.org/screenshots/gallery/inkscape-0.40-CVS-linux-randomize.png
> 
> I just checked those out... Very cool features! Clearly, you saw the need
> for stars and regular polygons, so I don't understand why you would object
> to having them in the Spec.

Exactly because the Spec would not allow _these_ kinds of stars
(rounded and randomized) anyway. This has to do with my point 4 above:
a star is just a too complex beast to be described completely. No
matter how rich are the SVG-standardized stars, someone will come up
with a nice way to make them even richer and more complex. And that
would mean, basically, abandoning <star> and going with <path> again.
(You can try to describe the entire range of capabilities of current
Inkscape stars in a standard, but it would take many and many
paragraphs to cover it all, and there's no guarantee we would not want
to make something more with stars in a future version.)

> | Which means that, to maintain those features, Inkscape will
> | still be unable to use a <star> even if it is introduced.
> 
> Huh? You would still have your custom code that renders stars and various
> funky shapes as 'path' elements... There would still be a need for them.
> Just as some authoring tools render rectangles as 'path' elements, stars and
> polygons could be rendered that way too... I just don't see why you'd want
> to. 

Actually, we do use <path> not only for stars or spirals, but for
ellipses and (soon) rects too. Reasons are simple:

1 You cannot put markers on an SVG shape, only on a <path>.

2 You cannot put text along an SVG shape, only a <path>.

These restrictions directly follow from SVG standard, but for an
average user they just don't make any sense. So we decided that it's
better to lose some level of semanticity in the SVG code that we
produce than to subject the user to the restrictions that look
completely arbitrary, or than to implement a complex "smart switching"
code to store shapes either as shapes or as paths, depending on what
is done to them.

With ellipses, there's also the problem of completeness again: our
ellipses are richer than the standard, as we can make an ellipse into
an arc or segment easily, keeping it the same type of object. Another
reason to use <path>.

> Without doing a lot of unnecessary math, a screen reader could not "look
> at" a path or polygon and determine that it is a pentagon or a 6-pointed
> star, whereas with an element known to produce only regular polygons and
> stars, with constrained syntax to differentiate them, a screen reader would
> know exactly what was being rendered. That's what I mean by semantics.

In other words, an SVG editor must know that this is a star in order
to be able to edit it as a star. This is true, but notice that this
only affects SVG _editors_. For simple renderers (which I think are by
far a majority), this semantic is of no use at all. Why burden them
with it?

> | In general, let's not bloat the standard. If something can be
> | trivially done from the existing primitives, leave it to the
> | implementors to do it.
> 
> By that line of reasoning, we should take out all basic primatives except
> for 'path'. 

No, I'm not that extremist :)  As I said, rects and ellipses are way
too common, so they do deserve an element in the standard. And we
(Inkscape)  would be glad to use these elements, if (1) the above
problems with markers and text-on-path are fixed, and (2) the ellipses
are made a bit richer to be able to create arcs and segments.

> It's not a good idea to rely too much on proprietary features by
> implementors on an open standard. Surely an open-source project sees the
> danger of tool lock-in?

Certainly we would not advocate relying on proprietary features. _If_
there was a standard rich enough for our needs, we would use it. And
our features are in no way proprietary - we're open source, so
everyone is welcome to consult our code and implement the same shape
tweaking tools in their software.

In fact, you gave me an idea. What if we split the SVG standard into
two layers, the lower layer containing a strict and compact set of
features that is sufficient to build a complete SVG _renderer_, and an
upper "semantic" layer which would add stuff necessary for rich
_editing_ of SVG? Then at a lower level, a star would be just a
<path>, but at the upper level it would contain (in attributes in
another namespace) all the semantic info on the number of rays, radii,
rounding etc. This would be similar to what Inkscape does currently,
except that the upper layer would use a standardized set of attributes
in a standardized namespace, instead of the inkscape: namespace as
now. This would bring a number of advantages:

- Implementing a simple SVG _renderer_ would become easier.

- All SVG _editors_ would get a standard set of "rich" controls to
use, compatible across implementations.

- Being a separate layer, the "semantic SVG" would hopefully be easier
and faster to update, and any problems with it or with its
implementations would be much less critical because they would only
affect editing SVG, not (dis)playing it.

- This "semantic SVG" layer would allow "soft" extensions by vendors.
By this I mean that if you invent a new way to tweak a star, for
example, you can still add it as a single proprietary-namespaced
attribute, while using all other standardized semantic attributes.
This will never affect rendering and will affect other SVG editors
only in this one aspect of editing, while all other aspects will be
preserved. This is in contrast to the current situation where you have
to either use the semantic but limited <ellipse>, or go with a
semanticless but rich <path>, tertium non datur.

Naturally, when there's a mismatch between the basic <path> and its
higher level semantic attributes, the former has precedence.

What do you think?

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

Received on Thursday, 25 August 2005 02:57:07 UTC