Re: [SVG 2] bearing path command and simple drawing of objects with discrete rotation symmetry

Cameron McCormack:

...
>
> You're right there would be an advantage to allowing fractions in here
> for values like 1/7.  On the other hand we don't allow numbers to be
> expressed like this anywhere else in SVG.

Well due to CSS one can already note font-size/line-height for font with
similar syntax, but different meaning of course. 

>
> For stars, pie charts, etc., which are the kinds of things that I'm
> thinking the bearing commands will be used for, fractions of the form
> 1/n would be appropriate. 

For the B command m/n would be needful anyway, maybe only for
b 1/n would be sufficient for a larger amount of use cases, but because
something like a star like object can have more structure around the 1/n
direction, one might need m/n for b as well.
And for example with 2/5 or 3/5 you get a star that already has a name,
something like 2/7, 3/7, 4/7, 5/11, 7/13 etc are relatives with just another 
discrete rotation symmetry. 

> I wonder though whether people would want to 
> have more complex expressions, like "0.5 + 1/7".  (Of course they can
> just compute that to "8/14".)

I think, it is reasonable to say, that authors can calculate 1/2 + 1/7 = 9/14 
in most cases on their own without the help of a computer ;o) - especially 
if they have the graphical representation as a check. 
Therefore no urgent need for this and if they need to use something
like 1/7 + 1/sqrt(17)  it is ok to use a rounded value anyway - 
or they can use two values for b  or one B and a b to ensure with 1/3 the 
main symmetry and with the numerical value (in degree) the fine structure left 
and right from 1/7.

>
> People have previously asked to be able to use CSS length values in the
> middle of path data strings, and <polygon> points attributes.  Although
> we hadn't planned on doing that right now, as it's quite a change, it
> would let you do fractions using calc().

To have it for already established commands will be more problematic,
because 'calc' represents already four path commands, even more
problematic than b, B without a reasonable fall back mechanism for
current viewers, scripts and programs. 
And the parsing might get slower, if a program has to take into account, 
that each number can be a calculable expression -
this means effectively something completely new to analyse path data.
The addition of b, B with only degree or with fractions like m/n as well only 
require some addition to a currently already working algorithm, and there
will be no big complication due to the fraction notation here.
However, if we forget about a notation in degree, we could 
say one has to note pairs of numbers instead of a fraction:
B 3,7 instead of B 3/7 - this would align better with current notations.
The disadvantage of this approach is, that due to current use in SVG, 
a notation in degree is what people already know and expect, if they do 
not think in specific symmetries.

But of course, if there is such an addition as b, B in SVG 2 anyway,
it will be highly desireable, to have all new commands and syntaxes
in SVG 2,  just to avoid yet another backwards incompatibility for path
elements with SVG 3.
Basically with each change this might mean, that the analysis of
path data has to be written from scratch - not only for viewers,
but as well for scripts and programs, that only optimise or manipulate
SVG path data.

>
> I think if we allowed fraction values, implementations wouldn't
> necessarily perform their path/bearing calculations using fraction
> values but instead still work with floating point.

If implementations approximate 3/7 with 154.285714286 degree 
just for presentation, this is in practice no real problem, because if 
they use sufficient digits, the deviation is within the required accurary
anyway, therefore for the presentation there is no difference, this is more 
to keep the document small and better understandable  and 
(because for example SVG tiny 1.2 restricts the digits to a maximum of 
four after the dot) one avoids unsufficient  rounding already by the author 
or maybe future versions of programs like scour (or simple scripts I and
others have in use to reduce the file size by scaling and rounding) ;o)



Olaf

Received on Thursday, 13 February 2014 15:01:52 UTC