Very insightful piece by Kurt Cagle on the long tail. Great read even if you think you've got the general idea of the long tail already.
Here's an interesting statement he makes on applying standards:
What this points to then is a point that standards developers themselves should take away with them - it is not necessary for a standard to be highly technically sophisticated, and indeed this may very well work against the adoption of the standard (which will take place first within the tail, not the head). It should rather be sufficient that it can be adopted (with some effort perhaps) by tail companies. It also points out that it is generally not in the best interest of tail projects to eschew those standards, as this effectively cuts them off from intercommunication with a "majority" of the tail.
It made me think, and it's a great way to explain why I like XML and not YAML.
I want to make another simple example of XSLT and SVG today. So I'm going to do another XML document and transformation. The mechanism is similar to my last example, but I'm not using any of the same SVG. Today, instead, I'm going to show an example with a textPath for making some wavy prose.
It also happens that the Mozilla team just landed support for textPath last night for Firefox trunk builds. I developed today's example in Internet Explorer with Adobe SVG Viewer 6 preview, but I'll be testing later with Firefox. If you want to use the latest trunk build of Firefox for testing, get it here.
I was thinking over the SVG lighting examples that I presented over the weekend and I wanted a clean way to produce something more complex that utilizes the lighting effect that I came up with. Examples are easiest to learn from when the information can be presented in small chunks. I think that logic carries through to code analysis. If there's no good reason to make big long functions then I stick to what fits on my screen. That's very developer-centric of me, but I am a developer.
So the way that I know to keep things small when it comes to XML is XSLT. That might sound backwards since XSLT and XML can be very verbose, but what I mean is that units can be independently analyzed. Large and complicated functionality can be elegantly composed from many small blocks. Chunks of code that I've produced with XSLT tend to be quite digestable - so far.
I'm going to continue from the last example I posted with the shading under the sphere. To see how I got this far, read yesterday's post: Fake Lighting Without Filters in SVG. Dark is the opposite of light, so as a first approximation, I'll try just applying a gradient that's conceptually opposite to the one I made for the light effect. The size of the shading gradient will be the same as the light, but it will be black instead of white. The focal point will also be moved; to the exact opposite side. So the (fx,fy) of (70%,15%) maps to (30%,85%).
Looks like there's a whole lot more info at the SVG Open site. I was just looking over the schedule, lamenting that it's too far away from me this year, and I see there are links for some of the content that's being presented. I'll be looking over the SVG/XAML comparison presentation. The Cartoon Oriented User Interfaces presentation sounds interesting, I hope they'll post some info later.
Kurt Cagle has posted a summary of his keynote speech from SVG Open 2005. He covers a lot of ground on XML and the next generation of GUI. Pretty inspiring stuff as an SVG enthusiast. The amazing part is that even though we've all been hearing about subscribing to software since the 90's, this time I can see it coming. Not soon like next month, but soon like in a couple years.
Humour me if you're an Eclipse expert already, but I've been taking my time about getting familiar with it. I tried the compound XML document editor a little while back and was less than impressed with it's SVG editing ability. As far as I could tell it didn't even respect the encoding I specified (I couldn't change from the default to UTF-8). Maybe I missed the point of that plugin, though.
So tinkering a bit with a new project in Eclipse recently, I noticed that there's CVS support built in. I like Subversion and have a couple projects stored in Jeff's subversion repository. I love the almost seemless integration of the Tortoise SVN client into Windows Explorer. So seeing the CVS support in Eclipse got me wondering about SVN support. Sure enough, the good people at Tigris.org have an Eclipse plugin called Subclipse.
I just got my dinner: a slice of raspberry-lemon loaf and a "grande no bovine-growth-hormone mocha" (the barrista's words, not mine). I'm settling down to try and deal with the fact that I'd better get to work on my next little project.
Maybe it's motivated by guilt from my persisent preference for the Adobe SVG viewer, but I decided to take the new Firefox Deer Park Alpha 1.1 through the W3C SVG test suite and see how it does. That way I can do what you're supposed to do with Alpha builds: find bugs and report them.
So, as I was saying yesterday, I wrote a simple Firefox extension that just turns the about:config preference for svg.enabled on or off.
Read on to download it.