- From: David Dailey <ddailey@zoominternet.net>
- Date: Tue, 29 Apr 2014 22:41:10 -0400
- To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'Dr. Olaf Hoffmann'" <Dr.O.Hoffmann@gmx.de>
- Cc: "'Dirk Schulze'" <dschulze@adobe.com>, "'www-svg'" <www-svg@w3.org>
Hi all, I was a bit surprised to find this discussion of stars re-emerge. And then surprised at my surprise, naturally, contemplation arose. And I had a few thoughts that were new to me. First, there have been, over the years, many discussions of stars, and at least three proposals I'm aware of: Doug Schepers had one maybe five years ago; Dr. Olaf proposed one a bit later, as per recollection; and then Paul LeBeau, most recently. Maybe others... I'm not trying for exhaustive accuracy. It strikes me as though a) the proposals differ in terms of what is meant by a "star" -- generally something with radial symmetry, but lots of differences in terms of the power, expressiveness, and even the ease of use by a novice. And then the opposition to the concept emerges with lots of relatively impassioned plea for moderation in our concept of what SVG might ever be. Initially, I sort of thought that the addition of the <star> element was a bit unnecessary since there were so many other more important things that SVG needed. But realizing that progress in SVG itself has been (is it okay to say) slowed by cross-integration with CSS and HTML, the more adventurous things of SVG1.2 (like vector effects) seem now like distant dreams held only by progressives (like me), I came to think that maybe little incremental things like star made sense -- easy to spec, easy to implement. And the arguments that stars and other things of radial symmetry are pretty darn ubiquitous in a physical world that seems to favor reuse, whence perhaps symmetry arises, as that world is viewed by minds that seem to favor parsimony (whence symmetry appeals), <star> came, once more, to seem worthwhile. A lot of authors (if indeed markup languages still matter) might find the trig for drawing a star thorny. But then, (surprises abound), the idea of adding more subcommands to <path> seemed to gain traction at least in the public discussions here and so, since that would provide so much new expressiveness, stars seemed to fade in importance once more. So here are the new thoughts (that others may already have expressed): 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. 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. 3. And just as there seem to be different ideas on what a star is, there are also differing concepts as to what an irregular star might be, or on what a star might not be. Tab wrote: " Irregular stars can't be handled in any meaningfully simpler way than just using a <path>" Well, I suppose it depends, perhaps, on what we mean by an irregular star. There are lots of predictable deviations from symmetry which are characterizable through elegant and concise formulations. Witness how group theory and fractals interplay so nicely, giving us tessellations both periodic and nonperiodic! Merely introducing a bit of randomness into stars could, I think, provide exactly that. Here's just a bit of simple play with "irregular stars" (using paths that were given their coordinates with a we bit of trig and then randomized and replicated): The core code should be tractable to an eight year old with the exception of the d attribute that requires trig: <path stroke = "black" stroke-width = "6" d = "M 329 194 149 136 260 290 260 99 149 253 z" > <random attributeName="d" min="M 319 184 129 126 240 280 250 89 139 243 z" max="M 339 204 169 146 280 300 270 109 159 263 z" /> </path> http://cs.sru.edu/~ddailey/svg/randomstars.svg cheers David
Received on Wednesday, 30 April 2014 02:41:44 UTC