- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Thu, 13 Feb 2014 16:01:22 +0100
- To: www-svg@w3.org
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