RE: Request for Future Feature: Star Element

Hi, bulia -

| > 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, 

Let's put this into perspective. The entire page for basic shapes is only
one of 23 in SVG1.1. In fact, it is one of the shortest normative sections
in the entire Spec, comprising rather less than 5% of the length of the
document. This is split up into roughly 6 sections, one each for 'rect',
'circle', 'ellipse', 'line', 'polyline', and 'polygon'. So, each of those is
less than 1% of the Spec. Add to this the fact that they all inherit from
the Shape Module, and you have a very compact footprint for each of those
shapes. You could add half a dozen more and it would still be a very minor
part of the Spec. There is no additional complexity necessary, such as
dealing with transformations, viewboxes, etc. It's just a simple shape.


| 2 the complexity of implementations, 

This would be trivial to add.

 
| 3 the level of use this feature would get, 

Quite a lot, I suspect.


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

I think that my definition, with the possible addition of rounding (as with
rectangles, and as seen in some of your examples), covers the vast majority
of use cases.


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

As I've said before, it's not very easy to manage in a dynamic fashion.


| 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.

I would find it difficult to disagree more.


| > 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. 

Arguably, the more elaborate versions of these couldn't really be called
stars at all. They bear none of the classic properties of stellation (they
don't have radial symmetry, nor are the points and polygon bodies relatively
prime); they aren't even as star-like as the looser definition that I put
forward, which is really more like regular-pointy-things (but which most
people would say are stars). 

Don't get me wrong, your graphics are cool. But I wouldn't call them stars.
A glassblower I know calls glass stuff like that "art blobs." The randomness
could be done with a filter, and some transformations could account for
others of them, but many of them are simply funky shapes... Thus, best
described by a path, with has no semantic baggage.


| 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.)

I don't think we need to cover every conceivable case, nor is that what I'm
proposing. I think we need to cover the most common cases. Your funky art
blobs are cool, but I think that they use case for most of those variations
is very small. By contrast, I think the use case for regular polygons and
simple stars is quite high. Like I said, use 'path' when you're not really
making a star. 


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

Your reasons may be valid, but I think they highlight problems in the Spec,
not ideal cases. But this kinda makes an argument against your stance. You
don't use the ellipse element, even though SVG provides one, because you
want to use your enhanced features. So, if you really don't want to use
'star' because you want more features... Then keep doing what you're doing.
Noone can force you to make your authoring tool use rich semantics.


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

Yes, that is a limitation of markers, which many feel is a bit broken.


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

Another omission, in my opinion.


| These restrictions directly follow from SVG standard, but for 
| an average user they just don't make any sense. 

I agree.


| 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, 

Very sad, but I see why you were driven to that.


| 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.

That, on the other hand, is a poor choice, in my opinion.


| 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>.

An elliptical arc segment is not an ellipse, which is why it's totally
appropriate for you to use 'path'. I just don't think you should use it
exclusively.


| > 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?

I think you missed what I'm saying here. This has nothing to do with an
editor, it has to do with a (theoretical) UA that can read SVG files and
describe them to sight-impaired users. Alternately, search engines with
image indexing could easily index a document with a 'star' element (or any
other semantic shape) as a search term, just as they now look for plain
text. Do they do this now? No. Will they in the future. Not if we don't
provide the groundwork for they by providing semantic content, they won't.


| > | 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 

Amen.

 
| (2) the ellipses are made a bit richer to be able to create 
| arcs and segments.

Not sure I agree there.


| > 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.

Then why fight adding features to the language that are
1) easy to implement; and
2) fit a good amount of your common use cases?


| 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.

Well, that depends on your license (could Abode or EvolGraphix redistribute
your code without recontributing their changes?), but that's neither here
nor there. If it's a feature that's widely desirable, why not standardize
it? 


| 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?


I think this is an interesting idea, but I'll have to think about it more
before I comment. Prima facie, this is what might already be done by a
renderer anyway. It also smacks of what sXBL is promising. I think it would
be pretty complex to do right, however, especially in the case of SMIL
animation. I think it is wholly appropriate for a geometrical graphics XML
to have geometrical semantics, and would be loathe to discard them. Also, I
would fear the "soft" extensions would beget yet another browser war. 


Regards-
Doug

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

Received on Friday, 26 August 2005 00:10:49 UTC