RE: Request for Future Feature: Star Element

Hi, bulia-

| On 8/24/05, Doug Schepers <doug@schepers.cc> wrote:
| > <star id='pentagram' cx='300' cy='100' r='40' r2='20' points='5'
| > orient='point'/>
| 
| Inserting all kinds of fancy things into the standard does 
| not sound like a good idea to me.

I don't think that stars and regular polygons are fancy at all. I think they
are very basic shapes that everyone is familiar with, and would expect in a
2D graphics language. As I understand it, there was originally supposed to
be a regular polygon shape in SVG but it was accidentally left out.


| What would you save with 
| the above, compared to a simple <path> that draws the same 
| shape? A few bytes? 

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


| Is this worth the trouble you'll be 
| giving all implementors?

Yes. I implemented it in an afternoon. You are free to use my code... JS is
close enough to C++ that it should translate easily. The drawing code is
less than 20 verbose lines.


| Moreover, those implementor that need stars, have already 
| implemented them via <path>. For example Inkscape can not 
| only do arbitrary stars, but it can also round them:
| 
| http://inkscape.org/screenshots/gallery/inkscape-0.39-CVS-linu
| x-stars.png
| 
| and even randomize them:
| 
| http://inkscape.org/screenshots/gallery/inkscape-0.40-CVS-linu
| x-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.


| 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. 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 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'. And as I explained on my page (referenced in the original
email), and in my previous replies, only the very basic use case of a static
shape is easily done.

In terms of authoring and roundtripping, there are major benefits to having
a star/regular polygon element. If I wanted to tweak an image done in one
authoring tool, making a star a bit smaller or larger or with different
concavity (inradius), it would only be possible if:
1) I were using an authoring tool (not a text editor, as I normally do);
2) The authoring tool was the same as the one used to create the shape (or
used exactly the same feature set with exactly the same algorithm); and
3) The roundtripping data (telling the tool what the shape is supposed to
be) was preserved in the drawing (which is routinely stripped out in
production code).

That's a lot of trouble for a lot of authors just to add an few pixels to
the size of a shape when they need it; much better that a few implementors
spend an hour implementing something that will save much more time in the
future.

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? I think the Spec should address the basic needs of
the authoring community, and I think that this proposal does just that.

Regards-
Doug

doug . schepers  @ vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Thursday, 25 August 2005 01:22:14 UTC