Loading ...
Sorry, an error occurred while loading the content.
 

Metaphorical Web 19: SVG 1.2

Expand Messages
  • Kurt Cagle
    The Metaphorical Web #19 O Canada I came back from the SVG Open conference in Vancouver, British Columbia a few days ago, and am still sorting through a number
    Message 1 of 3 , Aug 3, 2003

      The Metaphorical Web #19

      O Canada

      I came back from the SVG Open conference in Vancouver, British Columbia a few days ago, and am still sorting through a number of things in my head. As you may guess, most of this particular issue will be devoted to SVG, specifically SVG 1.2, some of its new features, and where I see the technology going. However, I also have a few general thoughts, which I’ll try to cover here.

       

      I’m beginning to become convinced that Americans are by and large insane, or at the very least we are living in a remarkably oppressive environment. One of these days, perhaps in the not too terribly distant future, I think that I will cross over the border at Blaine, within sight of the Pacific Ocean, with my family and possessions in tow, and I will not come back. The week that I spent in Vancouver was one of the first I’ve had in a long time where I felt like the world wasn’t tilting madly out of control, where I could talk intelligently to people I met in coffee shop about movie scripts and writing books rather than the wealth one-upmanship that so permeates discussions south of the border. I saw a guy sitting on a bench, reading a comic book and smoking a joint, and a pair of cops walked by him without more than a brief glance.

       

      At the conference, Canadians were much more heavily represented than Americans – indeed, the number of Americans at this conference was surprisingly low. SVG is very much an effort that, while it is attracting US interest, is being driven significantly by a very international sensibility. The attitude about the language was also very much Canadian – which is to say, very much European: there is a fundamental rightness to SVG that opens all kinds of interesting possibilities, and you should look at work being done with the language as being an investment that will benefit whole generations. It’s a very long term vision, something that seems to be lacking in the American “gotta show a profit this quarter or we’re toast” business culture.

       

      I saw this more long term world viewpoint expressed over and over again in Vancouver. Social investments such as health care and education are made with the realization that people who are healthy and well-educated are generally more prosperous, and will typically return that investment into them several-fold over their lifetimes. The city had, after several attempts, secured the Winter 2010 Olympic Games, and already this has led to some very serious thinking about how they will be able to shape the future evolution of the city around the structures that will be built to host the games. This forward thinking attitude has held constant through both leftist and rightist administrations, and to me seems very much consistent with something that is very endemic to the culture itself.

       

      That SVG, and for that matter XML, has taken off in the fertile soil of Vancouver, Toronto, and Ottawa doesn’t surprise me in the least. Tim Bray, the editor of the original XML specification, is a Vancouverite, and the Canadians have been remarkably patient in working with the rest of the world to show that XML is more than just a convenient format for brokering COM objects. It’s a long term language, one that is changing the way that we work in profound ways, but its subtlety is hard for those who are concentrating on the short term gain. As a consequence XML’s a very Canadian thing, not terribly flashy or loud, but with an understated elegance to it that will make it the principle language of the 21st Century.

       

      Consequently, if any of you reading this are in Vancouver and are looking to hire an XML philosopher, drop me a line. There are times, especially lately, when I feel like a stranger in a strange land, and I would like to come home.

       

      Before getting into this issue of The Metaphorical Web, I need to explain something – this was intended as a general (and fairly brief) overview of the SVG 1.2 spec and the conference, but brevity is not my strong suit. This issue is long. I did a cut and paste into MS word to get a sense of its size, and was astonished to find that it’s weighing in at around forty pages. Part of this can be attributed to the inline code, part of it to my trying to explore some of the implications of the code. I will be posting a version of this on my website at http://www.metaphoricalweb.com, along with the code contained herein where applicable. If you have any comments about it (especially any inaccuracies, as I’m still trying to get my head wrapped around this), please contact me directly at kurt@... . Thanks.

      A Few Notes on Conference People

      I wanted to extend a note of thanks to Dr. Philip Mansfield for inviting me to the SVG Open conference and giving me a chance to both given a class and speak. In addition to being the host and sponsor of the conference this year, he is also the President of SchemaSoft, a company that has done a great deal of work in the SVG arena, and has been behind the SPARK initiative, something I’ll discuss in greater detail below.

       

      I met a number of fascinating people at the conference, although because I was also with my wife and daughters (t’was our anniversary last week, and as a descendent of French Canadian trappers, my wife Anne has as strong a pull toward Canada as I do) I didn’t get a chance to spend nearly enough time with them as I’d hoped.

       

      I did get to meet Paul Prescod in person for the first time, a very soft spoken and intelligent man who has become something of a legend in both the Python and web services arenas, and his presence at this conference to me was a very telling indication that SVG is attracting the attention of those people who live about five years in the future.

       

      Chris Lilley is almost the archetypal vision of the romantic artist or poet, and it is odd to see him at the helm of the SVG working group, though I will be the first to admit that he is doing a remarkable job, given the complexity of the process. Again, a very intelligent man, though I was  able to talk with him for only a few minutes. I also saw Chris's counterpart Dean Jackson, the editor for the SVG 1.2 draft, and was able to catch one of his sessions, but sadly I was not able to talk with him for more than a couple of minutes.

       

      Gordon Bowman of Corel and I had a chance to talk over lunch, and his thoughts were most illuminating. Gordon is the chief architect of SVG for Corel, and his vision definitely shows through in a number of aspects of the language, including the belief (which I echo) that the SVG specification will soon need to be split between interactive and non-interactive versions if it is going to succeed in any meaningful fashion.  I also talked with a number of others from Corel, including Benoît Bézaire and Rob Williams concerning how they see the evolution of the language (and giving a certain amount of justified criticism that the samples in my SVG book were not completely compliant with the spec – which I’ll readily admit).  To that end, I’m re-evaluating a lot of the material I have in the book at this point, and will try to post revised samples that take advantage of both new technologies (SVG 1.2 makes some of my work obsolete) and focus more on the Corel dSVG work.

       

      I spent a long time talking with Michael Bolger of the SVG Foundation, a tall, lanky man with a good-humored view of the world and the bulldog persistence that marks true journalists everywhere. Michael became the de-facto videographer for the conference, and managed to cover the presentations or get interviews from many of the key people present. I was rather honored to be asked to do an interview with him as the conference was winding up, even if we did end up spending a great deal of time glaring at the hotel cleaning staff as they steadfastly refused to be quiet while we were recording. Ah well. I'll provide a link to all of the interviews in the next issue of METAWeb.

       

      There was a surreal sense to the conference itself. As Michael and I were talking on Thursday, we got into the question of SVG's role vis-à-vis the browser, which attracted the attention of another speaker at the conference, Ronan Oger. Ronan is a fixture on the SVG-Developer list, and is quite possibly one of the most adept programmers that I've ever known. Again, one of those people who lives about five years in the future, and is back in our time on an extended visa.

       

      Jon Ferraiolo of Adobe and I talked between sessions – I was breaking down one session as a session chairman just as Jon was setting up. As Adobe's current point-man on SVG he was able to play the magician with the Adobe SVG 6.0 Viewer (more on that below) and at least a partial implementation of the SVG 1.2 specification. Unfortunately, I had missed the announcement of the release of the SVG 1.2 working draft on Tuesday (I had driven back to Seattle to pick up wife and kids, and we got off to a much later start than I had planned), so I was singularly uninformed when I talked to him Wednesday morning. Adobe's relationship with SVG is an odd one, and I suspect that there is internally a fairly heated debate about the degree to which Adobe should embrace SVG. I don't envy Jon his job as a consequence because there are a number of issues about SVG that Adobe has some right to be concerned about, though I think that in the long term it will be extremely beneficial for the company if it does in fact go down that route wholeheartedly.

       

      Sara Kubik, also a well-known name on the SVG-Developer's list, is putting together a program at Purdue University to teach SVG and get students thinking about it in the role of commercial graphics, CAD, and design. Sara and I spent the lunch break on Sunday talking about everything from dealing with the academic community to the future of programming, getting XML adopted by non-technical users and the truly fascinating crew of people that make up the SVG community. I suspect I may have come off as slightly deranged at times – I tend to be a little too opinionated for my own good, as this newsletter amply demonstrates – but it was an enjoyable talk.

       

      I was a little bummed about missing both Michael Bierman (who was there but somehow we never happened to cross paths) and David Dodds (who came to meet me on Tuesday afternoon, while I was unfortunately stuck in traffic outside of Seattle about 100 miles to the south). David, I WILL get the book to you one of these days, I promise.

       

      I unfortunately was able to attend relatively few of the sessions, both because I had committed the afternoons and evenings to being with my wife and because I chaired a number of the morning sessions. The ones I did see were quite fascinating however, especially those focusing on the capabilities inherent in SVG 1.2.  Of lesser interest to me was the GIS/mapping sessions, though this is obviously a niche that has adopted SVG in a big way. This is not to denigrate this group, by the way – mapping is perhaps one of the most obvious uses for SVG as its structure provides a rich admixture of symbol creation and reuse, content driven graphics, meta-data, and interconnectivity. Process and monitoring graphics are perhaps a close second in this regard, since they are in essence maps as well, albeit more abstract ones. In both cases SVG has a lot of advantages over traditional graphics formats, and I don't find it at all surprising that representatives to the conference included officials from the US Geological Survey Department.

       

      I don't care where it is next year, I will attend SVG Open 2004. The sense that I had of this conference was that it was 1993 all over again, a time when HTML was just coming into its own and the field of experts with HTML experience could easily fit into a small hotel, yet everyone there definitely felt the same buzz that the field is poised to explode within the next 12 to 24 months. We're close to the tipping point with SVG, and what I saw at that conference makes me convinced that SVG's future is bright indeed.

       SVG 1.2: Scalable Vector Graphics Grows Up

      The Scalable Vector Graphics 1.2 Working Draft, even partially implemented as it is within the Adobe SVG 6.0 browser, will likely have a profound affect upon the web and desktop applications alike, leading in all likelihood to the final denouement of HTML and the integration of SVG into at least a major portion of all distributed Internet applications as the primary format.

       

      The notion of a vector graphics based architecture as a solution for HTML has been kicking around for a long time. HTML has evolved through necessity to be the general purpose format for displaying textual content on the web, but this was more a matter of historical accident. Everything within HTML is geared toward working within the confines of rectangles in a rectilinear grid, and worse there is very little control over that grid. It is possible with proprietary extensions to change that, of course, either through Macromedia Shockwave or certain Microsoft DHTML extensions, but there are obvious problems with both cases. With Shockwave, to be a content creator, you generally need to have access to Macromedia tools to build this web, though it is possible to do so through proprietary third party applications as well. DHTML places requirements upon the web page, and unless the code involved deals strictly with the CSS+DOM+HTML subset that other browsers such as Mozilla or Opera currently support, the applications will have relatively little portability.

       

      The web first emerged not long after the graphical GUI had made the jump to the PC -- first through the GEM system, then Microsoft Windows 3, in about the same time frame as the X Windows architecture on Unix based systems. The graphical effects that were possible in any of these systems were limited and expensive, and it is not really that surprising that what came first was a very primitive page formatting application. Graphics, when first introduced into web pages via applications such as Mosaic, were most often the focus of the application rather than navigational or presentation elements – bandwidth was just too expensive to spend a lot of time on downloading pictures of buttons, let along full-bore applications. Even throughout the mid-1990s, as bandwidth continued to climb, graphics often had to compromise by being scaled back to eight bit depth at a time when 24 bits were common within desktop applications.

       

      Flash of course changed the equation completely. Originally Future Splash (from the now long bought out company of the same name), Flash married the concept of vector graphics that worked so effectively in the printing world (via Postscript) with the notion that by changing the positions or other characteristics of these elements you could create sophisticated animations at a small fraction of the download cost of bitmaps, and at a greater fidelity (and far less bandwidth) than digital video.

       

      SVG arose after Flash had first been established, and was basically an attempt at making a richer, web based vector graphics format which would do for web graphics what HTML did for web text. However, even from its inception, SVG has been something of a hot potato. An animated graphics format, built upon XML, means that it is possible for a person with a text editor to create a rich, animated graphics presentation or application, something which many of these companies had built very successful products (and very profitable) products around. A precise graphics format also makes it possible to establish very tight text layout, especially when tied into some kind of paging mechanism, and makes it possible as well to specify pieces of desktop architecture if it is rich enough. In other words, SVG had the potential to significantly harm the bottom lines of a number of software vendors, and perhaps it is not surprising that SVG has always been something of a back-burner for these companies, if it was worked on at all.

       

      Yet for all of that, the SVG recommendation was established in the W3C. It had a number of limitations to it, limitations which stemmed in part from needing to get the spec out the door and into the hands of implementers, though there may have been politico-business aspects to the language’s limitations as well.  Even given that, SVG 1.0 and 1.1 are surprisingly powerful languages that help SVG transcend the role of being yet another graphics format (even if it is one of the few that are XML based) and move it towards being useful for basic application development. In my book SVG Programming for Apress, I cover this in greater depth, though I also indicate that there are enough limitations within SVG as to make building complex applications difficult.

       

      In the July SVG 1.2 Working Draft, which represents the first of probably four revisions and additions to the SVG 1.1 Recommendation passed earlier this year, there are several new sets of elements introduced which significantly enhance the capability of the language, so much so in fact that the language begins to show its true potential as a potent vehicle for first enhancing, then probably replacing HTML altogether.

      Adobe’s and Corel’s Curious Relationship with SVG

      Before going into detail about these features, I want to bring up the Adobe SVG Viewer 6.0 Beta (ASV 6.0), which was also released at the SVGOpen conference, and which implements a portion of the items contained within the specification. This release came as something of a surprise to the SVG community, which has been speculating for some time on whether Adobe would actually release a follow-up to their 3.0 viewer at all, or whether SVG was no longer part of the Adobe plan. With its release, I think a lot of SVG developers are even more confused, albeit pleasantly.

       

      I am not privy to the inner workings of Adobe. The features embedded within SVG 1.2 could very easily end up significantly replicating portions of their mainstay Acrobat 6.0 browser, or other tools they have, including Illustrator and perhaps FrameMaker. Thus the following is pure speculation on my part, and should be taken as such. I would guess that Adobe has been more than a little surprised at how rapidly SVG has managed to take hold, with essentially no marketing and precious little in the way of product support. The mapping community, which has had a long history of working with different types of graphical formats, has adopted SVG in a big way, and it is making its way into a number of different lightweight architectures such as Nokia telephones and similar embedded systems. This makes sense to those of us who’ve been playing with SVG for a while, as SVG eliminates the need of maintaining libraries of bitmaps in ROM, even for core functions such as interface displays.

       

      Moreover, Corel has announced support for SVG in a big way with Smart Graphics Studio and Corel Draw 11 both built with strong SVG support – I’ll be doing a review on both and about my conversations with the wonderful people there. Additionally Microsoft’s Visio 2003 supports SVG both inbound and outbound, and there are even some interesting Macromedia Flash to SVG converters (and vice versa) appearing, though not officially supported by Macromedia. In short, SVG is becoming a phenomenon.

       

      Earlier variations of SVG 1.2 have been incorporated into Adobe Acrobat 6.0, which is Adobe’s current “killer-app”. Given that Acrobat is built around Postscript, which is quite adequate as a graphics rendering engine, why would the work be expended to put ASV into this context. I suspect the answer is simple – it wasn’t for the basic rendering capabilities, but was instead useful as a vehicle for getting the rich animation and interactivity capabilities of SVG into as ubiquitous a mode as their browsers. SVG (especially 1.2) supports web services, can effectively custom render any markup in consistent ways, can perform rich text layout, can handle multiple layers, can invoke LOD, has animation support, and (again with 1.2) has rich audio and video support as well. In other words, once SVG 1.2 is fully complete, you will have a standard for specifying everything that would be contained within a windowed environment, or a web browser. If Adobe incorporates these features into Acrobat, then Acrobat becomes that browsing platform, quite probably displacing Macromedia Flash and possibly even Microsoft Internet Explorer.

       

      Yet if one can do all that outside of the Acrobat browser with the plug-in, then what would you gain with Acrobat? A conversation I had with an Adobe rep about a year and a half ago tipped me off to one possible resolution of this conundrum. It is possible with any number of viewers to read a postscript file by itself, and the Adobe PDF format is essentially a Postscript file with a few additional headers, wrapped up in a binary. Yet the advantage that Postscript brings to the mix is that it can be used to encapsulate the various binary objects that may be associated with that file, in effect bundling and caching them.

       

      Multimedia is not hard, but it is at the same time not a trivial undertaking either. A great deal of multimedia development goes into finding effective means to cache synchronous content such as video or audio resources. SVG is only a specification, and while it does contain a number of SMIL primitives giving the instructions on what to cache for consumption when, it contains no implementation details. A PDF format could easily encapsulate an SVG description and its associated media while holding that content in some kind of internally condensed form. Macromedia already uses this approach for their own Flash and Director applications.

       

      Moreover, because there is a significant amount of legacy PDF content out there already, the Acrobat Reader can continue to perform as a legitimate PDF display or editor device, and can coincidentally use the same SVG engine to build its own forms engine. As I suspect that the video/audio capabilities of SVG 1.2 will find their way into general use (I was able to simultaneously display Quicktime movies and AVI files in the same application – and what’s more was able to make one translucent so that it played on top of the other), the idea of being able to encapsulate these resources into special “pdx” files makes a great deal of sense.

       

      For this to happen, though, SVG will need to become more readily available in general, and the best way for Adobe to do that is to push the standard through its own products and through browser components. Note again that this is solely a guess, and I may be very much off-base. If someone from Adobe wants to contact me about this, I’d love to chat and clear things up.

       

      For reference, as a chance to test out much of the code in this section, you can get the Adobe SVG 1.2 viewer (what I refer to henceforth as ASV 6) at http://www.adobe.com/svg/viewer/install/beta.html. Keep in mind that this is beta code, and if you use ASV 3.0 in production, you will want to move to this only on test machines.

       

      On to SVG 1.2: within the working draft the changes fall into a number of different areas:

       

      Flowing Text/ Multiple Pages

      Accesing External SVG Resources

      Rendering Custom Content

      Live Templates, dSVG, XForms Support

      Drawing Order/z-index

      Video and Audio

      DOM Enhancements

       

      This article follows the general flow of this as well. Additionally, I want to offer my own interpretations about what I saw in a sort of Crystal Ball view.

       

      Flowing Text & Multiple Pages

      The flowing text model is the most immediately welcome aspect of the WD, and the one that I suspect will have the biggest effect upon HTML. In essence with flowing text you can specify one or more shapes – regions, into which text can be poured. These shapes do not have to be rectangular, by the way – I did a very nice flow into an hourglass shape, for instance. The text will flow to fill the width of the shape then will wrap around, just as you would expect in a text layout package. When it fills to the extent of one shape it will flow into the next shape in a region. Any text that remains will simply not be displayed, though it’s still available in memory.

       

      Related to this is the introduction of a page. A page is a container that will display only the content contained within that page. Currently the page specification is not complete (and is not yet implemented in ASV6), but even given that the implications are pretty easy to draw – you can define multiple layout regions that span multiple pages. An abbreviated example of both is shown in Listing 1:

      Listing 1. A sample SVG document with flow text layout and paging.

      <svg  xmlns="http://www.w3.org/2000/svg"

            xmlns:xlink="http://www.w3.org/1999/xlink"

            version="1.2"

            streamable="true">

       

         <defs>

           <!-- definitions here are always available -->

            <style type="text/css">

      .articleStyle1 {font-size:11pt;font-family:Garamond}

      .articleStyle1 {font-size:11pt;font-family:Verdana}

      .header1 {font-size:24pt;font-family:Times New Roman;}

            </style>

         </defs>

       

         <g>

           <!-- graphics here are always visible -->

         </g>

       

         <pageSet>

            <page>

            <rect x="0in" y="0in" fill="white" width="2in" height="8in" id="article1_Column1"/>

            <rect x="2.5in" y="0in" fill="white" width="2in" height="4in" id="article1_Column2"/>

            <rect x="2.5in" y="4.5in" fill="white" width="2in" height="3.5in" id="article2_Column1"/>

            </page>

       

            <page>

            <rect x="0in" y="0in" fill="white" width="4.5in" height="3in" id="article2_Column2"/>

            <rect x="0in" y="3.5in" fill="white" width="2in" height="4.5in" id="article3_Column1"/>

            <rect x="2.5in" y="3.5in" fill="white" width="2in" height="3.5in" id="article3_Column2"/>

            </page>

            <page>

            <!-- more pages go here -->

            </page>

         </pageSet>

         <flow class="articleStyle1">

            <flowRegion>

                  <region xlink:href="#article1_Column1"/>

                  <region xlink:href="#article1_Column2"/>

              </flowRegion>

            <flowDiv>

                  <flowPara class="header1">SVG 1.2: Scalable Vector Graphics Grows Up</flowPara>

                  <flowPara>I have a prediction – in five years time ...</flowPara>

                  <flowPara>The notion of a vector graphics based architecture as a solution for HTML...</flowPara>

            </flowDiv>

         </flow>

         <flow class="articleStyle1">

            <flowRegion>

                  <region xlink:href="#article2_Column1"/>

                  <region xlink:href="#article2_Column2"/>

              </flowRegion>

            <flowDiv>

                  <flowPara class="header1">A Few Notes on Conference People</flowPara>

                  <flowPara>I wanted to extend a note of thanks to Dr. Philip Mansfield for inviting me to ....</flowPara>

                  <flowPara>I met a number of fascinating people at the conference, although because I was also ...</flowPara>

            </flowDiv>

         </flow>

      </svg>

       

      This capability would make it possible to create an entire newspaper or newsletter within a single XML document, with multiple articles per page, laid out in typographic fashion, with headers and footers. Moreover, this content can be linked information, located somewhere else on the web. The regions are dynamic – you can expand or contract them (currently only through code, but eventually likely through markup).

       

      Currently the flow regions do not allow for inline graphics, though there is the ability to define exclusion regions which will prevent text from flowing within. Similarly, CSS formatting properties such as margins and padding are not yet a part of the specification, though that will definitely change. One problem that I did notice with the current implementation was that there was no way to get the bounding box of a flow paragraph, something that would have been useful for assigning bullets and other resources tagged to the text. This was a known bug, however, and it is likely that this will change in the next ASV 6.0 release.

       

      In the present ASV6 implementation (and in the 1.2 specification) the flow elements are read only – you can change them via DOM manipulation, but there is no exposed method for allowing the users to change this. In discussion with people on both the ASV6 and W3C sides, this is temporary; the next release of both spec and viewer will incorporate an editable attribute that will let you type into both straight <text> elements and <flow> elements. However, while this functionality was apparently present in a pre-beta, it has been disabled in the most recent implementation of ASV6 pending approval by the W3C.

       

      Navigation will be defined both in declarative tags (though the formal mechanisms are still under discussion) and via SVG DOM Code. In all likelihood, such pages will be identified via id elements, so that the XPointer format used elsewhere within SVG (i.e., http://www.myserver.com/myDoc.svg#myPage) would also be used here.

      Improved USE functionality

       

      The adoption of XPointer here is significant for another reason – one change in the SVG 1.1 specification that had not been reflected in the Adobe SVG Viewer until the 6.0 beta release was the ability to use external graphics in <use> references. One major limitation faced by earlier versions of SVG was the inability to create external resource libraries – any graphics that you created had to be present within the SVG.

       

      This limitation is dropped in SVG 1.2. Via a <use> element’s xlink:href tag, you can reference an external SVG file and have it appear as a fully functional inline unit, replete with animation and interactivity, even if this file is located on an external web server. What’s more, you can also identify a piece of a graphic with a specific identifier (id) attribute in the external file resource, and just that graphic will be instantiated. For instance, the file penta.svg draws a mixed pentagon/pentagram within a circle over the space of 12 seconds, and is part of the graphic that I will be using for my Metaphorical Web site

       

      Listing 2. Penta.svg

      <svg  xmlns="http://www.w3.org/2000/svg" version="1.2" xmlns:ev="http://www.w3.org/2001/xml-events"

      xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 1000 750">

            <rect x="0" y="0" width="1000" height="750" id="backgroundRect"/>

            <svg id="penta" viewBox="-300 -300 600 600">

                  <circle cx="0" cy="0" r="300" stroke="white" stroke-width="3" stroke-opacity="0" fill="none">

                        <animate attributeName="stroke-opacity" attributeType="CSS" begin="10s" dur="2s" to="1" fill="freeze"/>

                  </circle>

                  <line x1="0" y1="-300" x2="0" y2="-300" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="0s" dur="4s" fill="freeze" from="0" to="176.3"/>

                        <animate attributeName="y2" attributeType="XML" begin="0s" dur="4s" fill="freeze" from="-300" to="242.7"/>

                  </line>

                  <line x1="0" y1="-300" x2="0" y2="-300" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="0s" dur="2s" fill="freeze" from="0" to="285.3"/>

                        <animate attributeName="y2" attributeType="XML" begin="0s" dur="2s" fill="freeze" from="-300" to="-92.71"/>

                  </line>

                  <line x1="285.3" y1="-92.71" x2="285.3" y2="-92.71" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="2s" dur="2s" fill="freeze" to="176.3"/>

                        <animate attributeName="y2" attributeType="XML" begin="2s" dur="2s" fill="freeze" to="242.7"/>

                  </line>

                  <line x1="285.3" y1="-92.71" x2="285.3" y2="-92.71" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="2s" dur="4s" fill="freeze" to="-176.3"/>

                        <animate attributeName="y2" attributeType="XML" begin="2s" dur="4s" fill="freeze" to="242.7"/>

                  </line>

                  <line x1="176.3" y1="242.7" x2="176.3" y2="242.7" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="4s" dur="2s" fill="freeze" to="-176.3"/>

                        <animate attributeName="y2" attributeType="XML" begin="4s" dur="2s" fill="freeze" to="242.7"/>

                  </line>

                  <line x1="176.3" y1="242.7" x2="176.3" y2="242.7" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="4s" dur="4s" fill="freeze" to="-285.3"/>

                        <animate attributeName="y2" attributeType="XML" begin="4s" dur="4s" fill="freeze" to="-92.7"/>

                  </line>

                  <line x1="-176.3" y1="242.7" x2="-176.3" y2="242.7" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="6s" dur="2s" fill="freeze" to="-285.3"/>

                        <animate attributeName="y2" attributeType="XML" begin="6s" dur="2s" fill="freeze" to="-92.7"/>

                  </line>

                  <line x1="-176.3" y1="242.7" x2="-176.3" y2="242.7" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="6s" dur="4s" fill="freeze" to="0"/>

                        <animate attributeName="y2" attributeType="XML" begin="6s" dur="4s" fill="freeze" to="-300"/>

                  </line>

                  <line x1="-285.3" y1="-92.7" x2="-285.3" y2="-92.7" stroke="white" stroke-width="3">

                        <animate attributeName="x2" attributeType="XML" begin="8s" dur="2s" fill="freeze" to="0"/>

                        <animate attributeName="y2" attributeType="XML" begin="8s" dur="2s" fill="freeze" to="-300"/>

                  </line>

                  <line x1=&qu

      (Message over 64 KB, truncated)

    • Chris Harrington
      Awesome stuff Kurt. The information obtained per minute spent reading KPI of your blog is way high! And I concur on Vancouver - spent a week there (ten
      Message 2 of 3 , Aug 4, 2003
        Awesome stuff Kurt. The "information obtained per minute spent reading"
        KPI of your blog is way high! And I concur on Vancouver - spent a week
        there (ten years ago) on business with my wife and totally fell in
        love. Stupid me for not taking a job when it was offered.

        Where can one obtain the Adobe beta viewer? I didn't see any info on their
        web site.

        And (the really important question) when do you think one will be able to
        migrate from DHTML to SVG as a client-side development platform? I hunger
        for the best features of both. Clearly incredible things are in store, but
        I don't want to jump too soon. My app sells for high six figures, so
        customers expect it to be solid.


        Chris Harrington
        chris@...
      • Kurt Cagle
        Chris, Much thanks. The Adobe viewer is at http://www.adobe.com/svg/viewer/install/beta.html . I d say that we re probably about eighteen to twenty four months
        Message 3 of 3 , Aug 4, 2003
          Chris,

          Much thanks. The Adobe viewer is at
          http://www.adobe.com/svg/viewer/install/beta.html .

          I'd say that we're probably about eighteen to twenty four months out from
          real stability -- the spec will be finalized as a guess this time next year,
          with multiple viewers coming online about six months after that. In other
          words, it's something that I'd put into the pipeline for development in
          projects that have that kind of timeframe, possibly (if the option is
          available) of maintaining a running beta to get your clients acclimated to
          the possibilities.

          -- Kurt Cagle
          Kurt@...

          -----Original Message-----
          From: Chris Harrington [mailto:chris@...]
          Sent: Monday, August 04, 2003 6:47 PM
          To: metaphorical@yahoogroups.com
          Subject: Re: [metaphorical] Metaphorical Web 19: SVG 1.2



          Awesome stuff Kurt. The "information obtained per minute spent reading"
          KPI of your blog is way high! And I concur on Vancouver - spent a week
          there (ten years ago) on business with my wife and totally fell in
          love. Stupid me for not taking a job when it was offered.

          Where can one obtain the Adobe beta viewer? I didn't see any info on their
          web site.

          And (the really important question) when do you think one will be able to
          migrate from DHTML to SVG as a client-side development platform? I hunger
          for the best features of both. Clearly incredible things are in store, but
          I don't want to jump too soon. My app sells for high six figures, so
          customers expect it to be solid.


          Chris Harrington
          chris@...




          To unsubscribe from this group, send an email to:
          metaphorical-unsubscribe@yahoogroups.com



          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        Your message has been successfully submitted and would be delivered to recipients shortly.