Re: Proposal: <star> element

> Adding <star> means every SVG user/implementation will need to carry
around the star generation code. This will be a
> net-negative for users unless we have data showing hand-authored stars
are sufficiently popular[1].

The code is pretty simple.  It's a lot less ambitious than the <polar>
element.  And for shapes with more than a few points, I would expect it
would be quicker than parsing the equivalent path element.

The bearing path commands can be used for producing these shapes, but
working out the angles and getting the positioning right is going to be
tricky for a lot of people.

Paul



On 11 April 2014 12:16, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:

>
> Philip Rogers wrote:
> ...
>
> >My worry is that these proposals make SVG larger, slower, and
> >more complex in order to support a small subset of users.
>
> This applies for all new elements.
> But for documents, where this element is not used at all, there should be
> no relevant difference, only due to the increase of the number of elements,
> a viewer has to distinguish.
>
> Well, if this new element is used in a document, indeed processing
> can be much faster, because to simulate several issues, the file
> size can increase dramatially by orders of magnitude.
> Typically authors will not publish such large documents at all -
> if you do not find it, it is no indication, that authors would not
> use it, if it would be possible to have documents at normal size.
>
> Currently you will see almost no SVG documents simulating more
> complex gradients as well for a similar reason.
> For fun once I tried this with methods used in quantum chemistry
> to guess initial charge distributions for atoms and molecules
> as a start for numerical calculation of realistic distributions,
> but the results became very big files, not worth to care about.
> But there are now ideas to have elements and structures
> for more complex gradients in SVG 2 - maybe those will help
> some subset of authors to solve problems with acceptable
> file size as well.
>
>
> >Do you think we
> >might be able to extract out a subset of your request (possibly as a tool
> >or separate spec module) that would benefit SVG authors without burdening
> >existing tools and implementations?
>
> Stars or objects with rotation symmetry or broken rotation symmetry are
> surely
> popular, but many of this can be covered with the new path command - and
> what is not covered, will often not be published, if the simulation is too
> complex or difficult, therefore difficult to say - counting the new path
> command in file in five years for five years to see the relevance and
> introducing this element in maybe fifteen or twenty years with SVG 4
> is a quite frustrating promise for authors wanting to use it maybe
> already now or a least in a few years ;o)
>
> About path data in polar coordinates - on the one hand, it is quite common
> to use this for problems related to such symmetries, but beyond pie charts
> -
> maybe nobody knows, if people will really use Bezier curves in polar
> coordinates to solve problems. This would be a nice and interesting
> experiment. Here applies: No risk, no fun. As for many 'inventions'
> and improvements, the future will show.
> If we take a laser, today many people have some in daily use.
> An old professor (atomic and molecular spectroscopy) told me once,
> if they had seen, that this is somehow useful for everyone, they had
> invented
> something like dye lasers much earlier than the first laser was invented
> (Maser/Laser ~1950/1960) -  they already had all devices and the light in
> daily use,  they just did not see applications beyond their analysis of
> atomic and molecular spectra and structures ;o)
>
> If the SVG group cares only about known applications and use cases,
> there will be no surprising and exciting 'inventions' in SVG content.
>
> ...
>
> > >
> > > [1] One way to collect this data would be to scrape Wikipedia's SVG
> > > corpus and determine what percentage includes non-trivial paths with
> > > radial symmetry.
>
> Not necessarily - if the simulation is too big or complex, you will see
> PNG or
> JPEG/JIF instead.
> If you only look on what already is and what you know, you will miss, what
> could be in the future ;o)
>
>
> Tab Atkins Jr. wrote:
> > Also, note that Web Components, when applied to SVG, allow authors to
> > use their own <star-> elements (or whatever name you want) with
> > whatever semantics and abilities they want. They're sharable, too.  We
> > can then lean on that data in the future to see what kinds of
> > components are really popular, to see what is useful to bake into SVG
> > proper.
> >
>
> Well, as far as I understand this draft, there is no declarative method
> to provide information about functionality and how to animate, therefore
> this is of limited use for authors interested in declarative methods and
> accessible documents. Therefore I think, we can neglect this for this
> purpose. This is maybe more for fun, styling and decoration, not content.
>
> And a related declarative method for content should not differ a lot from
> the
> general XML concept, and this requires, that the user-agent indentifies the
> namespace and interpretes the language to get a meaningful presentation,
> therefore no need to reinvent this already existing concept ;o)
>
>
> > (That said, stars and regular polygons really are common.  I avoid
> > using them in my SVG because they're so *frustrating* to write - I
> > have to do freaking trig to make a pentagon, and that's ridiculous.
> > However, <path> with the new bearing commands makes it a lot less
> > annoying to write, so maybe it's sufficient to lean on that for a
> > while instead of making a new element.  I dunno.)
> >
> > ~TJ
>
> Well, it is not so difficult to create some paths with rotation symmetry
> or going from this to broken rotation symmetry (take into account, that
> more exciting 'star' appear to have no exact rotation symmetry).
> I have many PHP-scripts (the simulations in the proposals are just two
> examples, there are much more in my art gallery)
> for different purposes to generate this at least for static files and
> for some simple animations, but it really gets difficult for some kind of
> animation, that would be easy with thought through attributes,
> but without you get this Megabytes of data per animation element soon.
> The new path command helps to get alternative, not really simpler
> PHP-scripts
> or to do simpler cases by hand, but this will be not a big change for
> authors,
> they still need knowledge in polar coordinates and vector algebra to get
> what
> they want from such PHP-scripts.
> With such new elements there should be an easier access to this type of
> shapes
> for other authors as well.
>
> A specific element for only regular polygons can already help to animate
> this
> type of shape better than having only a path command, but still you are in
> trouble, if you want to be slightly more creative or flexible and to differ
> from others with 'your own' shape.
> And to what yet another 10 or 20 years to be 'more creative' here, is just
> frustrating ...
>
>
> Olaf
>
>
>
>