Re: Proposal: <star> element

Stephen Chenney:
...
> To have an effective discussion, it would be good if we
> agreed on the costs and benefits.
>
> Recent emails have muddied this. Maybe I can add some clarity:
>
> Benefit: Authors who want to draw stars (nobody knows what proportion of
> all authors) will have smaller, simpler files if this element is available.
> The subset of those who author by hand (nobody knows what proportion that
> is) will spend less time authoring.
>
> Cost: The spec will be more complicated, which costs everyone trying to
> understand that portion of the spec (nobody knows how many people read the
> spec, or for what reasons). The implementation will be more complex, which
> adds a very small cost to everybody using SVG, or in fact using any web
> browser (billions of people). There is also the opportunity cost of
> discussing and writing spec when there are other things that might have
> more benefit.
>

But this does not define a measure or unit of 'cost', can you suggest
some definition to have a quantitative meaning for this?
Things you mention as costs can be interpreted as benefits as well,
point of view. As well some mentioned benefits can be interpreted
as costs.
For example due to huge hard discs bigger programs are no problem
for most people today, else something like Microsofts windows or 
Adobes Acrobat-reader would not be so often in use ;o)
Some people prefer to play games with the size of a complete
operating system. If they believe, size matters, a big program can
be seen as a good program ;o)
Or if authors can do everything on their own easily, there is no need 
to provide specific programs anymore, not a benefit for people
providing specific programs ;o)


> This assumes all vendors implement the element. If only some vendors
> implement it, then the existence of the element will likely add to the
> authoring cost.

As already mentioned, this applies to all new features and some established as 
well. For example there is still a lot of trouble with user-agents not 
interpreting the SVG font section or several features from SVG tiny 1.2.

>
> Can anyone provide data to quantify the unknowns? Many of the discussions
> on the SVG working group would be helped by knowing the hand- vs tool-
> authored breakdown.

These are not necessarily excluding alternatives. For example for each file
created by programs like potrace or inkscape I use other programs or own
scripts and additional changes with a text editor  to get it ready for 
publication.

Some people at wikimedia commons spend a lot of time optimising program
outputs by replacing ineffective fragments by hand coded fragments, I have
seen this for star like objects as well. 


>
> Can anyone provide a use case that is not possible today, that would be
> enabled by a star element?
>

The star element due to the proposal of Paul LeBeau  is for most applications
simple enough to be replaced with a path or polygon element.
Even for animation this works:
Attributes cx, cy can be replaced by two additive translation animations.
Attributes points, density and type result effectively in discrete animations,
for this one can animate in the worst case the attribute XLink:href from a
use element to reference static path elements within a defs element.
If the SVG 2 draft would align for the animation of the path d attribute
with the advanced approach from SVG tiny 1.2, there would be a
simpler replacement as well.
Only the attributes rx, ry are more problematic, if both have the same
value, this can be replaced by a combined animation of transform scale
and stroke-width. If not, one is in trouble, but if vector-effect 
non-scaling-stroke is available, this might avoid this problem.

Therefore such simple constructs are not really important concerning
file size, maybe only saving a factor of about two.
Therefore maybe nice to have such simple elements, but this is nothing
really exciting for authors.

Concerning my polar proposal - this is designed in a way, that a static
object can by replaced always by a relatively simple path element
(therefore an implementation can be considered to be simple and the
contribution to the source code of a user-agent should be small).
But concerning animation, there is no way to simulate this completely,
for some features only a discrete animation is possible
as approximation (animating for example again XLink:href from a use 
element with 20 to 50 values a second).
But the current proposal is not yet optimal for animation, would be
better to use instead of lists of items for some attributes sub elements
of the polar for each list item to be able to animate this independently.
This would be an impressive improvement for the elements polyline and
polygon as well, the same for other attributes with lists as values like
transform, stroke-dasharry etc. For polyline and polygon this would
be a significant token to make them superior  to the general path element
containing only straight lines.

Once one starts to approximate, the difference in file size will be soon
several orders of magnitude, effectively with the result, that the author
will not publish such a huge file, of if generated with scripts on the server,
typically the audience will stop the download of the output after a few 
minutes before it is complete for presentation.
For some combinations the size of an approximation will increase to
arbitrary huge size (if all durations of attribute animations are in such a
way different, that the animation effect for the complete document will not
repeat within days).

Concering star elements like that from inkscape (as far as I understand
this), this can have almost the complexity of the polar, maybe slightly
less, but with similar consequences concering animation.
And to code those static objects by hand or own script requires some
mathematical skills as well (analysis and vector algebra). 


Therefore it depends on the proposal, whether it provides 
new options in concept, in practice new options or not. 
If the proposal is too simple (only regular polygons), 
it only saves some typically simple calculations done by hand 
or script for the author - therefore, if we assume some
knowledge and education for the author, nothing really exciting.
With more complex structures this changes dramatically, but for a
subset of problems this can be done by improving the functionality
of elements line polyline and polygon by sub elements as well 
(comparable to the gradient elements having stop elements as children).

For a new path element with notation in polar coordinates this
is another dramatic changes, here the difference applies already
for static objects. 
This is comparable to the problem with the A/a commands,
in SVG tiny without it, one cannot draw elliptical arcs, one can only 
approximate them. 
In both cases this requires mathematical skills in analysis and 
vector algebra (people with only 10 years of  school will not have this, 
in practice even with only 13 years of school they may have trouble 
to get it right).


Olaf

Received on Tuesday, 15 April 2014 09:50:07 UTC