Re: Proposal: <star> element

David Dailey:

...
>
> 1. Relying on <path> with rotational subcommands may not, in fact make
> stars. Rotating 72 degrees and than walking forward a unit and doing this
> four times followed by a "z" subcommand, would, mathematically get us a
> five pointed star, but owing to rounding error, as drawn on a screen, it
> will be off by a bit (probably not noticeable). But then doing the same
> thing to draw one of the 105 (if my mental arithmetic is right) different
> unicursal 211 pointed stars, those rounding errors might just accumulate so
> that the final leg of the star would be perceptually asymmetrical. A
> properly spec-ed <star> would presumably avoid the rounding error
> associated with numerously pointed stars and provide the 2Pi/211 (x,y)
> pairs appropriate for a given screen resolution.
>

If one uses absolute path commands, the inaccuracy will not accumulate
(I think, somewhere it is mentioned, that implementations have to transform
relative path commands to absolute ones anyway, one remaining problem
for authors is, that for example scour transforms absolute path commands to
relative ones to reduce file size. This is in most cases a good idea, but 
typically not for star like shapes with long straight lines or long curves.)
Currently one typically uses scripts, that calculate a corner with 
trigonometric functions independently from the previous corner.


> 2. It might make sense for the various star-advocates to combine proposals
> into one. Of course the hassle here is "why make the effort?" if it is a
> non-starter to begin with.

Star like elements were already rejected in the requirements for SVG2,
therefore from this point of view nothing to discuss for SVG2.
It was accepted to provide path commands in polar coordinates - but 
nothing seems to be done yet by the working group to put something
like my proposal or something better into the current draft unfortunately.
Because path commands in polar coordinates cover much more general
use cases, they have not much to do with the star element proposals and
they are often not very useful to draw the typical simple star shapes.

If star like elements are considered for SVG 2.1 or SVG 3, one can
discuss (as already done) what is useful: 
regular polygons (convex and non convex) only have a small mightiness 
- if one does not want to approximate circles in low quality, there are 
maybe only 1000 to 10000 relevant shapes. This is approximately covered
by the simple approach from Paul LeBeau. Because a larger amount
of content only uses maybe a subset of about 10 of these shapes,
this covers already, what many authors seem to need, but it is not
worth to name it 'star', because it excludes other traditionally used
simple star like objects (with discrete rotation symmetry using only straight
lines) due to the limitation of one radius parameter.
The old proposal from Doug Schepers allows two radii, therefore the
mightiness of this proposal is already much larger (but does not 
include some meaningful simplifications for some popular shapes 
included in Paul LeBeau approach - the author has to calculate this
on his own). Questionable, why only to allow two radii.
 
The approach of inkscape for example is much more flexible and
it uses cubic curves, therefore the mightiness is even higher 
(would be interesting to see a proposal for this approach), but as
far as I understand this, covers all options of Doug Schepers approach,
includes as well the option to break the mirror symmetries (the random
function seems only to allow to break the rotation symmetry in an
arbitrary way, nothing the author can specify in detail and in a predictable 
way).

My proposal tries to be quite simple to use for simple shapes, but 
allows with more optional attributes/parameters to note much more
complex shapes in a relatively simple way - but it does not include
currently those simplifications for some popular simple shapes as
Paul LeBeaus approach does, therefore it could be surely improved 
somehow for those use cases as Paul LeBeaus can be to cover other 
traditional star like shapes (with discrete rotation symmetry and
only straight lines) to align at least  with Doug Schepers approach.
It could be interesting to explore, if all inkscape star shapes are
a subset of this approach or not.

If one really wants to put something like a 'star' element into a
recommendation, one has to decide, if one wants only something 
with mainly a semantical meaning like the line element, 
something like the rect element with rounded corners to simplify
the notation of a few specific often needed use cases, something 
with almost the mightiness of the polygon element or something 
even more flexible and powerful, that allows authors to note a 
huge amount of different  specific shapes in a relatively simple way.

If one has this decision, one can think about the question, how
to combine or reformulate a proposal for the related element to
cover the needs and how to name it properly to indicate, 
what it is and what can be expected - an element named 'star' 
should be a powerful tool to avoid an empty promise by the name, 
something like 'regularPolygon' can be a quite simple tool with mainly
a semantical meaning, you know already by the name what you get 
and you will not expect a powerful tool.
Something comparable to the complexity of the rect element could 
have for example the name 'flagStar' (to be careful, one should 
ensure, that the proposal covers at least all star like shapes on flags
and in heraldry etc).

Olaf

Received on Wednesday, 30 April 2014 10:05:11 UTC